Get Registration Offsets (Code+Metadata) 1.0.0

Not sure but is this supposed to be the metadata/lib registration of when you extract the files from the apk instead of dumping with GG at runtime? If it's supposed to be at runtime these offsets are not correct. It's a 64 bit game

13 minutes ago, nok1a said:

Not sure but is this supposed to be the metadata/lib registration of when you extract the files from the apk instead of dumping with GG at runtime? If it's supposed to be at runtime these offsets are not correct. It's a 64 bit game

please double check the script is working correctly,  by comparing the offsets from the script with a game you are able to dump. (as shown in my second and thirds picture )

2 hours ago, APEXggV2 said:

please double check the script is working correctly,  by comparing the offsets from the script with a game you are able to dump. (as shown in my second and thirds picture )

Yes, and it doesn't match.

2 hours ago, nok1a said:

Yes, and it doesn't match.

ohhh that's not good.  thanks.  I will fix it and update 

10 hours ago, APEXggV2 said:

ohhh that's not good.  thanks.  I will fix it and update 

Oke, i think there is a lot to fix. I can test it if needed before you update.

This code is for sure ruining the result it self:

code=code[1].value-xAPEXx[*****] 
code=string.format("%X",tostring(code)) 
    if not v.x64 then
        code=string.sub(code,-8,-1)
        find0=nil find0=string.find(code,"0")
            if find0~=nil and find0==1 then
                code=string.sub(code,-7,-1)
            end
        find0=nil find0=string.find(code,"0")
            if find0~=nil and find0==1 then
                code=string.sub(code,-6,-1)
            end
    end 
print("Code = 0x"..code) 

meta=meta[1].value-xAPEXx[*****]  
meta=string.format("%X",tostring(meta)) 
    if not v.x64 then
        meta=string.sub(meta,-8,-1)
        find0=nil find0=string.find(meta,"0")
            if find0~=nil and find0==1 then
                meta=string.sub(meta,-7,-1)
            end
        find0=nil find0=string.find(meta,"0")
            if find0~=nil and find0==1 then
                meta=string.sub(meta,-6,-1)
            end
    end 
print("Meta = 0x"..meta) 

Also why checking if the libil2cpp.so library exists. It's irrelevant i think because your only using the global-metadata.dat.

 

Edited April 16 by nok1a

2 hours ago, nok1a said:

Oke, i think there is a lot to fix. I can test it if needed before you update.

This code is for sure ruining the result it self:

code=code[1].value-xAPEXx[*****] 
code=string.format("%X",tostring(code)) 
    if not v.x64 then
        code=string.sub(code,-8,-1)
        find0=nil find0=string.find(code,"0")
            if find0~=nil and find0==1 then
                code=string.sub(code,-7,-1)
            end
        find0=nil find0=string.find(code,"0")
            if find0~=nil and find0==1 then
                code=string.sub(code,-6,-1)
            end
    end 
print("Code = 0x"..code) 

meta=meta[1].value-xAPEXx[*****]  
meta=string.format("%X",tostring(meta)) 
    if not v.x64 then
        meta=string.sub(meta,-8,-1)
        find0=nil find0=string.find(meta,"0")
            if find0~=nil and find0==1 then
                meta=string.sub(meta,-7,-1)
            end
        find0=nil find0=string.find(meta,"0")
            if find0~=nil and find0==1 then
                meta=string.sub(meta,-6,-1)
            end
    end 
print("Meta = 0x"..meta) 

Also why checking if the libil2cpp.so library exists. It's irrelevant i think because your only using the global-metadata.dat.

 

I've tested on 6 games,  3 64bit and 3 32bit.  I started by seeing what the registration offsets are from the dumper apk (as in 3rd pic) , then just started experimenting..  I saw someone else say something about pointer search from metadata start. after search,  there will be results that are :

pointer to code +0x4

pointer to meta +0x4

pointer to start metadata +0x4

pointer to start metadata 

going to those pointer addresses and -0x the offset shown in the dumper always took me to the start address of the libil2cpp.so 

1 hour ago, APEXggV2 said:

I've tested on 6 games,  3 64bit and 3 32bit.  I started by seeing what the registration offsets are from the dumper apk (as in 3rd pic) , then just started experimenting..  I saw someone else say something about pointer search from metadata start. after search,  there will be results that are :

pointer to code +0x4

pointer to meta +0x4

pointer to start metadata +0x4

pointer to start metadata 

going to those pointer addresses and -0x the offset shown in the dumper always took me to the start address of the libil2cpp.so 

 

Yeah but your script finds the right address but it does not display the value correctly for 64 bit. And probably it also won't display the value always correctly for 32 bit. 

Edited April 16 by nok1a

1 hour ago, nok1a said:

Yeah but your script finds the right address but it does not display the value correctly for 64 bit. And probably it also won't display the value always correctly for 32 bit. 

maybe not always..  I just tested on 4 more games..  10 games total, all showing correct offset as in the dumper..  

there must be something I just can't see on my own device that would cause a problem on others 

2 hours ago, APEXggV2 said:

maybe not always..  I just tested on 4 more games..  10 games total, all showing correct offset as in the dumper..  

there must be something I just can't see on my own device that would cause a problem on others 

It won't work always. Like for protected games might not work. I guess, but the code in the script is wrong i think. Will check to. Might i know whats the purpose of the code i just shared from your script?

5 hours ago, nok1a said:

It won't work always. Like for protected games might not work. I guess, but the code in the script is wrong i think. Will check to. Might i know whats the purpose of the code i just shared from your script?

limits the length of the hex..  sometimes in 32bit, you'll get a hex of FFFFFFFF0ABCDEAB,  and we don't want to copy all the "F" or the "zero" if there are any 

3 hours ago, APEXggV2 said:

limits the length of the hex..  sometimes in 32bit, you'll get a hex of FFFFFFFF0ABCDEAB,  and we don't want to copy all the "F" or the "zero" if there are any 

Three optimizations about GG (#2szp4nqr)

 

 

Personally i think it's more easy readable to do offsets in hex then in decimal.

if v.x64 then t=32 o=8 o2=16 o3=24 else t=4 o=4 o2=8 o3=12 end

Since your working with memory addresses which are all visually shown in hexadecimal, and when doing offset calculation with GG it displays in hexadecimal as well. Better get used to it.

Why are you calling 2 times same table?

 code=gg.getValues(code) 
 meta=gg.getValues(meta) 
    if #(code)==0 or #(meta)==0 then
        print("×× ERROR FINDING CORRECT POINTERS ××")
        gg.setVisible(true) os.exit()
        return
    end 
    
code=gg.getValues(code) 
meta=gg.getValues(meta) 

It won't change anything, if the length of the table is 0. If it would be 0 the script exits. And if not 0, table will remain same as before your if statement.

12 hours ago, nok1a said:

 

Personally i think it's more easy readable to do offsets in hex then in decimal.

if v.x64 then t=32 o=8 o2=16 o3=24 else t=4 o=4 o2=8 o3=12 end

Since your working with memory addresses which are all visually shown in hexadecimal, and when doing offset calculation with GG it displays in hexadecimal as well. Better get used to it.

Why are you calling 2 times same table?

 code=gg.getValues(code) 
 meta=gg.getValues(meta) 
    if #(code)==0 or #(meta)==0 then
        print("×× ERROR FINDING CORRECT POINTERS ××")
        gg.setVisible(true) os.exit()
        return
    end 
    
code=gg.getValues(code) 
meta=gg.getValues(meta) 

It won't change anything, if the length of the table is 0. If it would be 0 the script exits. And if not 0, table will remain same as before your if statement.

I can add and subtract in my head easily with decimal values...  not so much with hex