nok1a

Not sure which part of the chainer script that has been included in the script, but i modified the getRanges() function little bit. function getLib() gg.setRanges(gg.REGION_CODE_APP) gg.searchNumber(":libRealRacing3.so", gg.TYPE_BYTE) local a = gg.getResults(1) gg.clearResults() local t = gg.getRangesList() local startAddress = {} for i, v in ipairs(t) do if ((a[1].address > v["start"]) and (a[1].address < v["end"])) then startAddress = {t[i], t[i+1], t[i+2]} end end return startAddress end function getRanges() local archs = {[0x3] = 'x86', [0x28] = 'ARM', [0x3E] = 'x86-64', [0xB7] = 'AArch64'} local ranges = {} local t = getLib() local arch = 'unknown' for i, v in ipairs(t) do if v.type:sub(2, 2) == '-' then local t = gg.getValues({{address = v.start, flags = gg.TYPE_DWORD}, {address = v.start + 0x12, flags = gg.TYPE_WORD}}) if t[1].value == 0x464C457F then arch = archs[t[2].value] if arch == nil then arch = 'unknown' end end end if v.type:sub(2, 2) == 'w' then v.arch = arch table.insert(ranges, v) end end return ranges end local ranges = getRanges() print(ranges) Hope it works.

Actually...i am not sure if you even need strings a pointers. The size of the executable is the same for everyone that has exact same game version. So what you could do is use gg.getRangeList() and check if the END address minus START address is equal to the size of your executable(only the Xa part of the executable) because the chance that there are 2 executables of the same size is really low. If size is same then that's your correct executable. Edit: This doesn't work

The value is 18 bytes away from your pointer ? In games that aren't Unity i would advice to use the pointer that is at the start of the allocated block. Not the one that is at the middle of the block because they are used a lot by the game, and that's perhaps why you get a lot of results. But the pointer at the start of the block of where your value of interest is located usually only has pointers relevant to that block it's located in. This is not accurate i think but for me to decide start of the block of which your value of interest is located i perform pointer search with a offset of 200~800 bytes but it can usually be more. The size of the block can be 3k bytes or more. Then the values that point the most to one address "but" is the nearest to your value should be start of the block. And it needs to be a pointer that directly points to your executable. Make sure it's not a purple one. Then from there do as you did and go to the pointer. This could be a approach.

Yeah, i had this issue as well and had to tackle it somehow using strings and pointers so that script works for all. Also, i downloaded your game and it's not a issue of split apk. But it uses the executables that are located at base.apk. So the issue is the same. No executable name What's the name of the executable you working with?

Oke, try moving all the files that you find in the lib of installation apk to /data/app/com.game/.../ and see if works.

If you referring to split apk that is showing in the process/range list. You have to place the executables from the apk in to the /data/game/lib/ folder. Then GG will find the right executable.

Found this offset in the modded apk. It's part of the network class. So it could be that one. Compared both instructions at the given offset of modded and original(play store) APK and it looks like this: Original: Modded: So i guess as far as edits in the libil2cpp.so goes this could be it. If he did some other things to the game for make the adds work, i do not know. It could also be that this offset is irrelevant and has nothing to do with the removal of adds. Use a offset patcher or something similar and edit the value.

if it uses hex patching..

If it is a mod menu and we can install it we can probably take the values from it.

Can you give the modmenu? Oh oke. Did not knew. Should have installed the app and run some tests before making the comment.

It's possible, seen it for few games but Enyby advices to use Lucky Patcher: Remove ads (#49005xf4)

Welcome!

We can proceed for sure. PM totally fine.

Choice totally up to you

Oke so you tried to do the group search manually and after restarting of the game that group search done manually doesn't work. It's fine, i won't try to convince you in anything. Well regardless in any script you make use the print() function to see what your script is doing and if it's really doing same thing as what you did manually.

The group search -1,049,624,576A;1,092,616,192A;1,082,130,432A;1,056,964,608A;1,062,333,317A::73 ?

You will always do that if you not try to use the print() function to resolve the possible issue. Which is really not much of work since you already now how to find the value and how the script is made.

Same for you to, welcome back.

It's not a 100% rule. I only said that using two devices can confirm the possibility that the group search is static. But im not sure if they really randomly change. That's a huge assumption. You could only be sure after first checking how the scripts behave and which addresses it gives you and performs actions on using the print() function before claiming the values change.

Welcome

A post about this game exist: hello can someone help me change the level of this game? (#nsbqjbd)

I guess it all comes down to finding patterns in anything and use some logic with it based on the knowledge you have of that something. I mean, if your gold is 20 and on another device the gold is 20 to. Then i guess that on both devices there is a number 20 in memory...so something is same on both devices. I mean this pattern makes sense i guess if you do not know about encryption yet. But even with knowing it i think it's a logical thing.

Aright, i hope it helped. Take the time and play around with it. At some point it will make sense. And use the print() function see what your script is doing. Like that you don't need to guess or assume.

If your not finding the group search it means your using the wrong range to search in. Well, when the script doesn't work have you tried testing at which part it stopped working?

Well, gg.searchPointer(0) is not that lazy. But gg.searchPointer(500) with ridiculous big offsets is for sure lazy.