nok1a

Actually, i downloaded BadCase script, this one worked for me BadCase's Toolbox (#9ptv7xz2)

I'm not sure because i do it all manually and then make script for it. Is the script your using open source? If so send link. Perhaps it need a small adjustment. Not sure. These offset scripts i think more advanced Lua scripting then i know. They are really great scripts. I can understand why you use them with dump.cs. If the script is obfuscated then don't bother, won't be able to help because know nothing about deobfuscating and probably means the creator doesn't want anyone to modify his script.

I thought you wanted to know "how" to dump it. If you just want the dump.cs you can get it but in a few weeks this game updates again so you need new dump so you will ask again. Better I think to know how to dump this game so that you won't have to ask again.

That's quite a stretch but would be nice to have. Will "try" to look in to it.

I'm quite positive it is a matter of selecting the right metadata. If it works for me it needs to work for you. Make a short video of when you dump libil2cpp.so and global-metadata.dat with Gameguardian and when you transfer the files from the emulator to the PC to then load it in il2cppDumper. Also open the metadata that you uploaded in il2cppDumper with HxD and send screenshot of the start of file. If possible upload it to a YouTube channel because downloading video will take long time. I have very slow internet.

If the one that you uploaded here is the same file as the one that you placed in il2cppDumper as in the screenshot than it means you placed the wrong metadata.dat file. It also says that it does not recognize it as a valid metadata. So if you dumped correctly with GG it means you selected the wrong file.

You loaded the wrong metadata file in il2cppDumper. the one you gave me was the protected one. You need to load the metadata that you just dumped with gameguardian.

Sure, if any questions just post.

Liapp doesn't appear if i open GG just before the game opens. Has to be timed right. Then you can see that it takes the game longer before it loads. Dunno why. But Liapp will not appear. Here, hope it helps. I took 32 bit in particular.

Magic bytes can often be used to find the global-metadata in running process, see here more info: https://en.wikipedia.org/wiki/Magic_number_(programming)#In_files. In this case it is the first 4 bytes of the metadata.dat. Should be like this: Your case when you opened the global-metadata.dat from the directory the first 4 bytes where not AF 1B B1 FA, which is the magical bytes for global.metadata.dat. So it was encrypted or obfuscated or they did some changes with the header...etc, see here explanation about obfuscated/encrypted metadata. If your not familiar with encryption/obfuscation you have to check for the metadata.dat and libil2cpp.so at runtime. Searching for the magical bytes is a alternative way of searching for the correct global-metadata.dat (although this not work for every game, like genshin impact). I open the game and then directly hide it on the background.

Can you send screenshots of the stats of helmets? Low levels can't have it. And I dunno if it is server sided. You will have to test it.

Hi, (having account auth sign-in problems, so messaging for now through other account, the administrator have been informed. Not sure how the issue will be fixed) Can't help you with explaining about how encryption works but dumped the game for 64 bit, so the method i explain is for 64 bit. Have no idea if this works on other games. The actual metadata was located in other memory region then where the metadata path name was shown. Don't let it mislead you. Did like the following. Search metadata.dat magic bytes. Forgot how to accurately look for the correct metadata.dat size, so i did pointer search on the first(start) address, the offset +0x08 in data type Dword. One of the values is the metadata offset you can use for dump with GG. Don't use the values that are shown negative because metadata doesn't get that large(or have not seen yet) So the two that make most sense for try are the postivevalues with offset 0x0091C000 and 0x00A00000 Use offset calculation on start address and save the address you jump to. If you go a few address up, you can see already the end of the metadata.dat. So your offset 0x0091C000 was correct. copy start address and address you jumped to, then dump it. Also dump the libil2cpp.so file. Then use Il2CppDumperGUI.1.8.0 to get dump.cs. For input dump address you use start of libil2cpp.so address.

View File King of Thieves Teleport / Insta win Only for 64bit. Submitter Platonic Submitted 02/28/2023 Category LUA scripts  

I use x8 as well. But not get any problems. Try. com.gameinsight.gobandroid (1).lua Currently i have no way to add the nicknames to the players you teleport to. But perhaps something i can find in the future. I could be wrong but on the background your activating the script while the game is still loading all data. Activate script when your signed in to your account.

Error has for now no sense. Was the script able to fully open? Perhaps. Can you copy the error and post. Some extra info of when the error appeared would be more efficient for troubleshooting. Thanks.

I only familiar with very little about "Reverse Engineering" game apk's. I also would need to know what i be looking for which i don't think i do. Or perhaps yes, but its not on client. its on server because that token is generated server sided as you said. Itried dumping but could not find anything which can help me figuring out that check algorithm. I also believe token generating is happening server sided and client just using it to get response from server for sign in. I tried making 2 new accounts at the same time to see if i could find some similarity on the check algorithm between both setCookie's while having a near identical user/ctime info: VAFN4XG9Usx1pW3oo8tnMbR8E3apWJQJgMvMNAEFpXM.eyJpZCI6OTI2MDU5MzEsImN0aW1lIjoxNjc2ODM0MDE2fQ LbuRCOPZ1mW1a34TnYJVBdG9AHJP05M88y3Iu7v7jhA.eyJpZCI6OTI2MDU5MzIsImN0aW1lIjoxNjc2ODM0MDE2fQ So if i make changes to the token and send to server i will get a error at the validation part: I'm only "assuming" that the issue is with wrong checksum. It can be worst, that it also requires the right ctime, ctime of other players is something which i have not been able to find on my client with GG nor checking the packages with wireshark that are transmitted using TCP protocol. The first part of the token is always 43 characters long. I am not sure if this reasonable but perhaps i need to make a script that kind of calculates all possible check algorithms? But i have no idea if it is still reasonable at that point. base64URL has 62 different chars, by the power of 43 it be a absurd amount of trials. I don't even think GG is build for it. Perhaps need to use something more suitable for this thing and then make the result of it compatible with GG. Dunno.

Thanks lot for the info. Pointing specifically to the userCookie. You can reuse the same token, It stays valid. This is a authentication request that is used to sign in to your in-game account. By changing the userCookie token you can change the account you can login to(for example). Ok, so i understand that it comes down to a token with some check algorithm to make sure there is no tempering on the user ID and session time. So what i want is to modify that user info in the userCookie token and send to the server and have it being received as valid by the server. This can't work if i do not know the appropriate check algorithm used. I try to understand that check algorithm. Any thoughts on how the check could work.

I don't have acess to the tools. Response. Through GG. Hope it has the needed info. Script ended: { -- table(ffbb891) ['code'] = 200, ['content'] = ' %setCookie[account]�/DEvIPj54NwK5EI5vW8_k4iwcV6_rWDABEIvvgcXpso8.eyJpZCI6NTE5NDk2NTQsImVtYWlsIjoiMTE2MTE1MjQ0Mzg0MTA3NzMyOTUzQGdhLmZ1bnpheS5jb20iLCJzb2NpYWxOZXR3b3JrcyI6eyJnYSI6IjExNjExNTI0NDM4NDEwNzczMjk1MyJ9LCJjdGltZSI6MTY3NjQ2MzMzNX0setCookie[user]�5MUbMehx_aPdSzp1LcRpEoHMRvC_Sw_XLHwEtPB98k40.eyJpZCI6OTEwNjA2MTksImN0aW1lIjoxNjc2NDYzMzM1fQinitTimeA��39�timezoneOffset�0contentDomain/gobmobile.akamaized.netconfigs ruYshared/as/ru/contextConfig.amf?ux=1676462708enYshared/as/en/contextConfig.amf?ux=1676462707trYshared/as/tr/contextConfig.amf?ux=1676462708frYshared/as/fr/contextConfig.amf?ux=1676462707itYshared/as/it/contextConfig.amf?ux=1676462707deYshared/as/de/contextConfig.amf?ux=1676462706esYshared/as/es/contextConfig.amf?ux=1676462707ptYshared/as/pt/contextConfig.amf?ux=1676462708pt-BR_shared/as/pt-BR/contextConfig.amf?ux=1676462708nlYshared/as/nl/contextConfig.amf?ux=1676462708koYshared/as/ko/contextConfig.amf?ux=1676462707jaYshared/as/ja/contextConfig.amf?ux=1676462707ltYshared/as/lt/contextConfig.amf?ux=1676462708zh-Hanscshared/as/zh-Hans/contextConfig.amf?ux=1676462709zh-Hantcshared/as/zh-Hant/contextConfig.amf?ux=1676462709remoteIp185.124.28.154cidUser.91060619env mainkeyA50d53aca6c02795f355bd3284e4207c2 langlevel nickPlayer 91060619tcp%35.246.142.97:7712seq4 status', ['contentLength'] = -1, ['contentType'] = 'application/octet-stream', ['date'] = 1676463335000.0, ['expiration'] = 869893200000.0, ['headers'] = { -- table(18ff3f6) ['Cache-Control'] = { -- table(e552264) [1] = 'no-store, no-cache, must-revalidate', [2] = 'post-check=0, pre-check=0', }, ['Connection'] = { -- table(6bf5982) [1] = 'keep-alive', }, ['Content-Transfer-Encoding'] = { -- table(8124ccd) [1] = 'binary', }, ['Content-Type'] = { -- table(c7400d0) [1] = 'application/octet-stream', }, ['Date'] = { -- table(86ae801) [1] = 'Wed, 15 Feb 2023 12:15:35 GMT', }, ['Expires'] = { -- table(ce403f7) [1] = 'Mon, 26 Jul 1997 05:00:00 GMT', }, ['Keep-Alive'] = { -- table(85719e8) [1] = 'timeout=20', }, ['Last-Modified'] = { -- table(444d70b) [1] = 'Wed, 15 Feb 2023 12:15:35 GMT', }, ['Pragma'] = { -- table(b8d8bce) [1] = 'no-cache', }, ['Server'] = { -- table(9fb46a6) [1] = 'nginx/1.18.0', }, ['Transfer-Encoding'] = { -- table(b6059fc) [1] = 'chunked', }, ['X-Android-Received-Millis'] = { -- table(b317aef) [1] = '1676463335138', }, ['X-Android-Response-Source'] = { -- table(dfa96da) [1] = 'NETWORK 200', }, ['X-Android-Selected-Protocol'] = { -- table(683e8c9) [1] = 'http/1.1', }, ['X-Android-Sent-Millis'] = { -- table(94ae893) [1] = '1676463335010', }, ['null'] = { -- table(8594885) [1] = 'HTTP/1.1 200 OK', }, }, ['lastModified'] = 1676463335000.0, ['message'] = 'OK', ['requestMethod'] = 'GET', ['url'] = 'http://game.www.gobmobile.com/api/auth.enter?output=amf&clientData={"deviceModel"%3A"Asus ASUS_Z01QD"%2C"connectionType"%3A"WIFI"%2C"graphicsDeviceName"%3A"Adreno (TM) 640"%2C"graphicsDeviceVersion"%3A"OpenGL ES 3.0"%2C"graphicsMemorySize"%3A1024%2C"operatingSystem"%3A"Android OS 7.1.2 %2F API-25 (N2G48H%2Frel.se.infra.20200730.150525)"%2C"processorCount"%3A4%2C"processorType"%3A"ARMv7 VFPv3 NEON VMH"%2C"systemMemorySize"%3A3546%2C"gitRevision"%3A"f227fba487d904c2e6e4d71828b5754ca355ab2a-207"%2C"version"%3A"24.1.207"%2C"deviceId"%3A"08eca84316b4153c1670a5717cdcafed"%2C"googleAdvertisingId"%3A"44c43f7e-a2ff-4333-ac7b-b221f219fb04"%2C"googleAndroidId"%3A"cd4d354f1ef238b4"%2C"piracy"%3A{"licensing"%3A"retryChecking"%2C"installerId"%3A"true"%2C"signingCertificate"%3A"true"}}&platform=android&deviceId=08eca84316b4153c1670a5717cdcafed&setCookie[account]=ZUs8TGBcN6FR7kjJrql343FfwPHRYnlobtJyxmAByB4.eyJpZCI6NTE5NDk2NTQsImVtYWlsIjoiMTE2MTE1MjQ0Mzg0MTA3NzMyOTUzQGdhLmZ1bnpheS5jb20iLCJzb2NpYWxOZXR3b3JrcyI6eyJnYSI6IjExNjExNTI0NDM4NDEwNzczMjk1MyJ9LCJjdGltZSI6MTYyMzA4NTI3MX0&setCookie[user]=VaLciho_OwEwXdjIHdDbsoR4KYTtYV06b9bwtdm9ceQ.eyJpZCI6OTEwNjA2MTksImN0aW1lIjoxNjc1NjE4NzE4fQ&resolution=hd&lang=en&returnCookies=1&seq=4', ['usingProxy'] = false, }

Guns Of Boom web debugging proxy -> fiddler Full request: http://game.www.gobmobile.com/api/auth.enter?output=amf&clientData={"deviceModel"%3A"Asus ASUS_Z01QD"%2C"connectionType"%3A"WIFI"%2C"graphicsDeviceName"%3A"Adreno (TM) 640"%2C"graphicsDeviceVersion"%3A"OpenGL ES 3.0"%2C"graphicsMemorySize"%3A1024%2C"operatingSystem"%3A"Android OS 7.1.2 %2F API-25 (N2G48H%2Frel.se.infra.20200730.150525)"%2C"processorCount"%3A4%2C"processorType"%3A"ARMv7 VFPv3 NEON VMH"%2C"systemMemorySize"%3A3546%2C"gitRevision"%3A"f227fba487d904c2e6e4d71828b5754ca355ab2a-207"%2C"version"%3A"24.1.207"%2C"deviceId"%3A"08eca84316b4153c1670a5717cdcafed"%2C"googleAdvertisingId"%3A"44c43f7e-a2ff-4333-ac7b-b221f219fb04"%2C"googleAndroidId"%3A"cd4d354f1ef238b4"%2C"piracy"%3A{"licensing"%3A"retryChecking"%2C"installerId"%3A"true"%2C"signingCertificate"%3A"true"}}&platform=android&deviceId=08eca84316b4153c1670a5717cdcafed&setCookie[account]=ZUs8TGBcN6FR7kjJrql343FfwPHRYnlobtJyxmAByB4.eyJpZCI6NTE5NDk2NTQsImVtYWlsIjoiMTE2MTE1MjQ0Mzg0MTA3NzMyOTUzQGdhLmZ1bnpheS5jb20iLCJzb2NpYWxOZXR3b3JrcyI6eyJnYSI6IjExNjExNTI0NDM4NDEwNzczMjk1MyJ9LCJjdGltZSI6MTYyMzA4NTI3MX0&setCookie[user]=VaLciho_OwEwXdjIHdDbsoR4KYTtYV06b9bwtdm9ceQ.eyJpZCI6OTEwNjA2MTksImN0aW1lIjoxNjc1NjE4NzE4fQ&resolution=hd&lang=en&returnCookies=1&seq=4

The thing is, i am not sure what causes the wrong signature error. I almost assuming that the scrambled part is some kind of check algorithm for the readable part. So that if there is tempering to the readable part the server will know because the algorithm and readable info are not compatible anymore. Just a bit like a FCS would work(i guess).

Done that, but have no idea about how unicode character will help me. Perhaps you can refine "This may indicate something". I'm not fully following. I assume the client will send a authentication request to the server in which the userCookie token is complete. I don't yet understand what i need to look for in memory. This token is the way it is stored on ones device when making an account. If modified and send to server you get an error responds back saying wrong signature. For it to be encrypted would it still require to follow the 2+ dots? Because this one only has one. I checked the doc that CmP gave in his explanation, but then for the encryption part. but all types of JWP token talk about encryptions which at the minimum causes the token to have 2 dots in it.