nok1a

Are you sure it starts in Xa and not in Cd ? I never saw the start of the library being anything else then starting with the magical bytes of ELF. PRess that arrow to see the path names and double check which range your lib start.

The class and field should be the same. Is it not working anymore?

Yes, it can be a mess with decimal points. Have you tried all possible data types. Or do something like 165~166 float. 16596~16696

Create new post. Select help.

Not sure, have you checked on the forum: Art of War Legions (#96kqpt2t) Not sure if it still works.

Welcome!

That's odd if it worked for you before, do you get any results if you manually search libRealRacing3.so in UTF8 in region code app ?

Script pointerTest.lua

That's not my script. You changed the search string and added your own string in it. It's also not how you implement it in the chainer and removed the function to i guess? Also i did not read the full chainer script which was very big mistake of me, so i did not knew you needed to load results in order for it to work. I do now. So will implement the function in the chainer script.

Personally with my current knowledge on the topic i just think that finding some unique values in the executable is enough. Search unique value. Then call gg.getRangesList(). All ranges will be displayed with there start and end address. In my case i know that the UTF8 string "libRealRacing3.so" resides in the Xa region of the executable. So i just search it and then get the first address of that char. So i know that's the right executable. But since lack of infomration on what your script does i adjusted my function getLib() for it to work with getRanges() by calling gg.getRangeList() to obtain the start address of the executable in which the string i just searched is located. Since the getRanges() function expects a table from gg.getRangeList(). Then knowing that the executable is divided in to 4 segments but the chainer only will take the first segment that includes the "w" permission i just increment the table i took from gg.getRangeList() by 3 since the third segment is the one the chainer use since it has the "w" permission. I test on 2 emulators that are 32 bit and on the 64 bit as well. Both worked. And as you can see in the post of Game lib (#c64p69nw) It worked for Count_Nosferatu after executing the script as expected.

To be honest i don't think it can work using size calculation. You will get all the BSS parts. But the size could differ. Did some tests: 32 bit 64 bit And then you have your size which is 32000

I only edited part of the chainer script since i dunno which part are used in the script. But i guess the issue is with the getRanges() function since you have to input the path name to get right executable.

Yes, for the chainer it is.

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!