CmP

For GG you should only use optimized versions of virtual space applications from this forum. Parallel Space: Parallel Space + 32-Bit Support + 64-Bit Support (#rjx0v91) Parallel Space Pro: Parallel Space Pro + 32-Bit Support + 64-Bit Support (#4doyid1r)

Current capabilities of GG are more than enough to find values that meet this condition. There are 2 main approaches for this case: - ordered group search with "placeholder" values; - searching for target value and checking whether found results meet the condition(s) (like whether value at offset X is equal to Y). So the task is to find all float values equal to 15.0 for which float value at offset -16 (-0x10) is equal to 2.0. With the first approach the code may be next: gg.clearResults() gg.searchNumber("2.0F;0D~~0D;0D~~0D;0~~0D;15.0F::17") gg.refineNumber("15.0", gg.TYPE_FLOAT) And the second approach can be implemented, for example, like this: gg.clearResults() gg.searchNumber("15.0", gg.TYPE_FLOAT) local results = gg.getResults(gg.getResultsCount()) local checkValues = {} for i, v in ipairs(results) do checkValues[i] = {address = v.address - 0x10, flags = gg.TYPE_FLOAT} end checkValues = gg.getValues(checkValues) for i, v in ipairs(checkValues) do if v.value ~= 2.0 then -- exact comparison of float values should be avoided in general, but for particular case of value "2.0" it will work results[i] = nil end end gg.loadResults(results)

I haven't found any records that would help with understanding the problem (what and why happens) in the log, so there may be 2 main possibilities: either they are present in the log but haven't been noticed or recognized as being related to the problem or log doesn't contain them. However, it seems worth to note that around 2 minutes and 17 seconds have passed between the moment when process has been selected in GG: 12-22 13:05:18.975 14480 14480 E AndroidService: used: ProcessInfo [cmdline=com.fungames.sniper3d, name=Sniper 3D, packageName=com.fungames.sniper3d, icon=android.graphics.drawable.BitmapDrawable@8ef34cd, pid=10179, uid=10275, isSystem=false, isGame=true, weight=0, main=true, order=0, x64=false, rss=359392, getTracer()=0, getTrace()=-1] and the last record in the log: 12-22 13:07:35.649 20370 20370 I SoundAlivePolicyManager: isGlobalEffectSupportCurrentAudioPath, currentDeviceType : 2 This doesn't quite correspond to your description of steps that you do to reproduce the problem. Was process selection really the last action that you performed in GG that caused device to become unresponsive and to reboot after ~10 seconds? One thing that would greatly help with analyzing recorded logcat is to specify when certain actions have been performed. For example: 11:04:32 - "Start" button in GG's start screen was pressed 11:04:38 - Process selection dialog was opened 11:04:41 - Target process was selected 11:04:55 - Device automatically initiated it's restart Time moments don't have to be exact, since it's not easy to precisely check when something is done, but even if it's +- 5 seconds, that's still significantly better than having no such information at all. For example, to illustrate, the log you provided is ~27 MB, but only ~2 MB from it is most likely to contain any information of interest, since other records are from before the moment of time when you initiated recording logcat in GG. And with information about when actions relevant to the problem have been performed, only, for example, ~200 kB of log records are most likely to contain any information of interest.

Whatever compression method was used, it is not supported by 7-Zip, so the file can't be decompressed. Which software did you use to create the archive?

I meant to attempt to check folder contents with file chooser, but there is no need anymore, since the situation supposedly became clear enough. GG doesn't use root to access file, path to which is provided by user in input field of "Execute script" dialog (nor does it for file chooser functionality in general). In most cases it works fine: just place script file(s) that needs to be executed in a folder that can be accessed without root and it will work. However, if target file is located in folders that require root to be accessed, GG may not be able to access it. In Android 11, as part of it's privacy-oriented changes, applications have been restricted from accessing other applications' data on external storage, i.e. contents of "/Android/data" and "/Android/obb" folders (source). So when GG runs on device with Android 11, it doesn't have access to those folders (with exception of it's own folder in "/Android/data"). For GG to be able to access files without restrictions, it most likely needs to delegate this functionality to it's daemon that runs with root, but there are security concerns related with such solution, so there need to be solid reasons to implement it. Actual question that needs to be asked in current case is why you need to be able to access contents of "/Android/data" with GG. For most use cases there should be alternatives that don't require accessing restricted folders, so it's not unlikely that there is an alternative for your case as well.

@CheatTester record logcat from attempt to access "/storage/emulated/0/Android/data" folder with GG's file chooser.

Better to just use gg.EXT_STORAGE.

Let's not forget what scripts for GG are. They are automation of methods for certain modifications in games via process memory editing. Authorship of scripts essentially boils down to authorship of methods implemented in them, since value of scripts lies exactly in them. If methods are public, particular scripts that implement them in most cases aren't important, because methods can be applied manually and/or can be implemented in other scripts. So for authorship of scripts to be relevant, methods need to be not public, but this leads to contradiction: public release of scripts for GG fundamentally can't co-exist with keeping implemented methods private. Therefore, authorship of scripts for GG the way you want it to be can't exist. However, it can (and does) exist the same way as authorship of methods for using GG to achieve certain result in certain game that get published at this forum or anywhere else. It doesn't matter whether methods are published in form of text, video or script, their authors most often get the popularity they deserve (even though some of them don't even care about it). But popularity/recognition by themselves is a wrong goal, instead one should strive to become better at activities of one's interest.

Thanks for the details. With them it appeared to be quite easy to find the answer. The value is tagged pointer that actually points to valid address in process address space. Top byte in tagged pointers is "implementation defined tag" that needs to be ignored to get the real address that pointer holds. More information about tagged pointers is present in Android documentation: https://source.android.com/devices/tech/debug/tagged-pointers So when you encounter such pointers, discard the top byte of their hex value (or replace it with "00") when navigating to the address to get to the correct address.

I don't have any explanation for described behavior, but it may help, if you provide details regarding finding the value in problematic region. Which game/application is that? What is the algorithm to find any value from problematic region?

My guess is that the values are actually from this region: 6e36d4b000-6e36dcb000 rw-p 00000000 00:00 0 [anon:scudo:primary] but for some reason the address in GG starts with "B40000" instead of "000000". You should be able to check this assumption by navigating to presumably correct address (that starts with zeros) in GG's memory viewer.

You provided logcat, but for such cases region log is needed. In settings tab there is "Write region log" option for creating it.

It seems to be some kind of global state variable to control whether main menu should be opened immediately after execution returns to main loop. But more often than not such behavior isn't needed and when it is so, the variable becomes redundant and can be removed. Main loop can be then replaced with the following typical one: while true do if gg.isVisible() gg.setVisible(false) Test() end gg.sleep(100) end

The problem is because you use comma (",") as decimal separator. Use dot (".") instead. gg.searchNumber('2.38220739e-44', gg.TYPE_FLOAT) This is also mentioned in documentation: https://gameguardian.net/help/scripts_locale.html

Such script is pretty simple, just need to call several functions of GG API: gg.clearResults() -- Clear results list to ensure that new search will be started gg.searchNumber("17", gg.TYPE_DWORD) -- Search for the value gg.getResults(100) -- Load first 100 results gg.editAll("0", gg.TYPE_DWORD) -- Edit loaded results Information about GG API functions including descriptions and examples of usage can be found in the documentation, link to which is in the post above by @blocx.

Yes, use string concatenation. For example: local str1 = "Value " .. "123" -- "Value 123" local str2 = 456 .. " value" -- "456 value" print(str1 .. str2) -- "Value 123456 value"

Alright, here is an example of function with parameter: -- Function to do a new search for dword value passed to the function through parameter "value" function search(value) gg.clearResults() gg.searchNumber(value, gg.TYPE_DWORD) end -- Example of function usages search("123") search("500600") Same way your "ModAPet" function can accept that id as parameter.

Try this option first. If it works, you don't necessarily need to change the code further.

The problem is because you use global variable without previously assigning a value to it. By default global variables have value "nil", a special value that means absence of value. So when nil is passed to "refineNumber" function, it raises an error, because it expected first argument to be string. A simple way of fixing the problem (with minimal changes to the code) may be to assign needed value to global variable "IDAP" before "ModAPet" function is called: if choice ~= nil then IDAP = menuID[choice] menuFunctions[choice]() end A better option may be to refactor the code to make "ModAPet" function accept parameter of search string to use for the call to "refineNumber".

Only as long as you keep GG running. To freeze values from script there is "addListItems" function. Set "freeze" field of tables to "true" for them to be frozen after the call to the function. For example: local results = gg.getResults(10) local values = {} for i, v in ipairs(results) do values[i] = {address = v.address + 0x1234, flags = gg.TYPE_DWORD, value = "4321", freeze = true} -- value will be frozen to 4321 end gg.addListItems(values)

Don't call "setValues" function in loop. The code above from @HEROGAMEOfficial's post illustrates the approach that should be used instead: construct table with all desired values and pass it to "setValues" function. Something like this: gg.searchNumber("2219816;6::25", gg.TYPE_DWORD) gg.refineNumber("2219816", gg.TYPE_DWORD) local count = gg.getResultsCount() local results = gg.getResults(count) local values = {} for i, v in ipairs(results) do local index = (i - 1) * 4 local addr = v.address values[index + 1] = {address = addr + 64, flags = gg.TYPE_DWORD, value = "7"} values[index + 2] = {address = addr + 80, flags = gg.TYPE_DWORD, value = "8"} values[index + 3] = {address = addr + 96, flags = gg.TYPE_DWORD, value = "9"} values[index + 4] = {address = addr + 112, flags = gg.TYPE_DWORD, value = "10"} end gg.setValues(values)

Regarding the needed details about "IsMatchHash" function in the variant of the library for arm64-v8a. The function is located at offset 0x18E078 from the start of the library. Here is the result of decompilation of function's code: The assignment on line 23 can be modified to achieve desired result (for function to always return 1). The assignment is performed by this instruction at offset 0x18E0EC from library start ("this" is a label for x0/w0 register): Modification of this instruction to MOV W0, #1 (hex bytes: 20 00 80 52) will cause the function to return 1 even when computed hash doesn't match stored hash. This modification of function's behavior is sufficient for bypassing in-memory data integrity check.

You missed one important detail: The offset from library start to instructions of the function and new values for them that were mentioned are only applicable for library of the game for x86. On your device library for arm64-v8a is expected to be used, so the offset to the function and which instructions to modify in it need to be located exactly in this variant of library.

No, with root in most cases something can be done. In this case, for example, you can modify file of installed library for the game to use it. Installed library is (should be) located at the following path: "/data/app/com.happylabs.hotelstory/lib/".

Rooted devices usually don't have such limitation of not being able to modify values in memory ranges with application's code (or maybe in any memory range that doesn't have "w" permission). Possibly that it is somehow related with security improvements in android 11, but this is just a guess.