CmP

Because string concatenation produces new string and there are multiple usages of it in the code. Mostly yes, but format strings don't need to be passed as parameters in this case and instead of separate call to format address, do it in the same one.

This is misunderstanding from my side. Table-only solution isn't an option for this case, because of requirement to have structure number in name. So solutions can be only function-based (table may be used in the function, but there is no gain from it in this case), but there is indeed some room for performance improvement in my example above - by avoiding string concatenation and using "string.format" instead.

Feel free to do that. And there is no need for any credits in this case, but you can do however you prefer. No, it shouldn't, but if you have millions of iterations, then the difference between function and lookup table might become noticeable, in which case it may make sense to go with lookup table. Yes, looks correct.

It looks like you need not a table, but function that returns name for value according to two parameters: structure offset and structure count. Here is an example of such function: function getNameForValue(structOffset, structCount) local name = "Structure (" .. structCount .. ")" if structOffset == 1 then name = name .. " :Unknown: " elseif structOffset == 2 then name = name .. " :Field offset: " elseif structOffset == 3 then name = name .. " :Field amount: " end return name end

What's the point of "auto-destruction" of the file that is executed, if it can be simply backed up before executing it? There are no ways (without using server) to prevent script from being executed more than one time that couldn't be easily bypassed, but if you still need to have that for some reason, basic approach is to check presence of certain file and only continue execution if the file is not present and to create that file right after the check has been passed.

Sorry, the answers to the questions above are present in your video. In your locale comma is decimal separator and for your values the search range that I suggested above is too narrow. Try the following search string: "1,19999~1,20001"

Could it be that you use incorrect decimal separator with respect to locale that you have selected in GG? There can be 2 options of the decimal separator: dot (.) and comma (,) . Try with dot first, then with comma.

This is correct approach, use range search, but make the range smaller. For example, for 1.2 search for "1.199999999~1.200000001".

This is limitation of particular variant of LDR instruction, it doesn't mean that it's not possible anyhow. But to be able to provide you reasonable answer, one needs to know what you want to achieve, why do you need to use LDR in the first place. So provide the following information (preferably in new topic): - what you are working with (function(s) name, description and instructions that it contains); - which modification you want to implement (for example, make the function return fixed value).

Either with 3 instructions as @XEKEX has described in his post or with 1 instruction and 4 bytes for address that need to be not far from the instruction as I have mentioned in this post.

There are 12 bits in the instruction that are used for encoding offset from PC in bytes, so the limit is from -4095 to 4095. Reference: https://developer.arm.com/documentation/ddi0406/cb/Application-Level-Architecture/Instruction-Details/Alphabetical-list-of-instructions/LDR--literal-?lang=en

As other have mentioned above, such case requires more than one instruction. At least 8 bytes are required: 4 for LDR instruction and 4 for your new address that needs to be placed somewhere not far from LDR instruction. For example: Address | Instruction/Value 12345678 | LDR R0, [PC, #-4] 1234567C | 0xAFFDACA4

It can't be used, because it is a pseudo-instruction that requires more space than single instruction. Description and examples of LDR pseudo-instruction are present in ARM documentation: https://developer.arm.com/documentation/dui0802/b/A32-and-T32-Instructions/LDR-pseudo-instruction

Just presence of two base64url-encoded parts separated by dot is not enough to conclude that string is JSON Web Token. In fact, your string isn't valid JWT as per step 4 of "Validating a JWT" section of RFC 7519 (https://www.rfc-editor.org/rfc/rfc7519#section-7.2).

And loading saved list with option to set values can't really be faster than setting values directly by definition, since loading list in this case includes setting values. Also what makes loading saved list significantly slower than directly setting values is not setting values part, it's everything that needs to be done before that: reading and parsing saved list file, populating saved list with items.

Then I can do it for you, since it turns out that you are not only wrong about performance of loading saved list and setting values, but are terribly wrong. Code that has been used for test: local savedListFilePath = "/mnt/windows/BstSharedFolder/com.cxinventor.file.explorer.txt" gg.clearList() local clockStart = os.clock() gg.loadList(savedListFilePath, gg.LOAD_VALUES) local loadListTime = os.clock() - clockStart local values = gg.getListItems() clockStart = os.clock() gg.setValues(values) local setValuesTime = os.clock() - clockStart print("gg.loadList time: " .. string.format("%.3f", loadListTime)) print("gg.setValues time: " .. string.format("%.3f", setValuesTime)) Saved list file that has been used for test: com.cxinventor.file.explorer.txt Result of the test: Interpretation of result: Loading list of 8192 4-byte values with option to set values with "loadList" API function took around 100x more time than setting the same values with "setValues" API function. So it's not a question of which method works faster. The question that remains is why did you, @zolotov_official0, post nonsense results instead of doing proper test.

Do you even understand yourself these "results"? They are beyond nonsense. Loading list with 100000 values took less than a millisecond? Setting 100000 values took 5699 seconds? At least include the code that has been used for "testing".

Only because it's a suitable name for the variable, could have been any other suitable name with the same success. As for the reason of having the variable, it's a small optimization to not have to get the same value from table two times.

Is this opinion based on facts or your subjective preferences? Almost all claims don't correspond to reality. 1. "ancient methods of patching". Restoring saved list has been there before scripts, so it's clearly the other way around. 2. "loadlists are faster". Based on what? Where are the results of performance tests? What's obvious without tests is that both methods are "instant" for editing hundreds or even few thousands values. 3. "loadlists are easier to update". Nothing prevents one from writing script in a way to be as easy updatable as possible, for example, with configuration table. And format of saved lists is far from being comfortable to work with manually. 4. "loadlists take less code". They do, at cost of losing all flexibility. How to restore only some of patched values with saved lists? To keep saved list for each desired state of values? What if there are tens of such states? And for some reason one of the most obvious disadvantages of saved lists isn't mentioned. It is required to (at least temporary) have a file for each one. So instead of directly patching values you suggest to create a file with saved list data and load it only to accomplish the same. If that isn't highly redundant approach, then I don't know what is.

Rewrite of the loop with inner loops with comments to main fixed issues (one mistake and one statement misplacement): local executable = {} for i = 1, #exe do local stringBytes = {} local startAddress = strPointer[i].value - 1 for j = 1, 150 do stringBytes[j] = {address = startAddress + j, flags = gg.TYPE_BYTE} end stringBytes = gg.getValues(stringBytes) local stringChars = {} for index, byte in ipairs(stringBytes) do local value = byte.value if value == 0 then -- comparison to string "0" is a mistake since value field is a number break end stringChars[index] = string.char(value & 0xFF) end local str = table.concat(stringChars) -- get final string only once after construction of table with characters is finished executable[i] = {address = exe[i].address, flags = gg.TYPE_DWORD, name = str} end gg.addListItems(executable)

Before you proceed to try different or modified apks of the games, consider checking structure of installed files of games for which SH loads and for which doesn't to see, whether there are any patterns there. Root folder to start checking and comparing from is game's folder (or rather sub-folder that includes package name) in /data/app.

I confirm this observation, "Stop, but not a breakpoint" seems to be unintended result. The logs also contain some details about what goes wrong when this happens. The first difference of interest is on the line that starts with "breakpoint:". "WSTOPSIG(5)" in logs with loaded SH means that process has been stopped because it received SIGTRAP signal, i.e. a breakpoint has been encountered. "WSTOPSIG(11)" in logs with failure, on the other hand, means that process has been stopped because it received SIGSEGV signal which is caused by invalid memory access. The second difference of interest, that allows to understand what caused invalid memory access, is on the following line that starts with "aarch64:" and contains information about values in registers. In logs with loaded SH value in "pc" (program counter) register is some existing address in process memory, for example, 0x703142802c from "loaded_shatteredpixel.txt". In logs with failure it is different, value in "pc" register is not an existing address in process memory, since it is clearly too small for that (for example, 0x8be3f0 from "failed_dreadrune.txt"). One possible interpretation of the differences described above is that in cases of failure to load SH something (maybe injected code) for some reason causes jump to invalid address that, as has been mentioned, causes SIGSEGV. Unfortunately, the logs by themselves don't allow to investigate further, that would most likely require using a debugger and would be significantly more complicated than analysis of logs.

String contents doesn't matter. If two strings are compared, they are compared accordingly. It's a simple system. It gets more complicated (and confusing) when variety of implicit conversions may be involved, like for example in JavaScript.

For "equal" it doesn't matter much, since comparison of strings will work as well. For "greater than" and "less than" it is correct solution and string comparison is not. String comparison works by comparing strings character-by-character in alphabetical order, so it's not applicable for comparing strings that represent versions.