Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 06/18/2021 in all areas

  1. 3,380 downloads

    Hello Guys . Today i will show you simple file rename blocker for GG Lua Script . It is by me ( no coyright ) . If you have any questions ask me in comments . Also Guys here is small variant of this script : if gg.getFile():match('[^/]+$') == 'Block Rename.lua' then else print('⚠ File Rename Is Detected ⚠') return end
    1 point
  2. 1 point
  3. I love this constructive diskussions i miss on other forums. that's great gentlemens
    1 point
  4. This is EXACTLY what I would love to have added to GG. Most games the distance between certain key values will always be the same. Location won't always be the same. Pewdiepie game is perfect example. Finding one value can sometimes be easy, then use offset to find difficult to search values. Another benefit to using offset/distance is patterns. Ex: Hp->Atk is 32bytes Atk->Def is 32bytes Then sometimes going - 32 from HP and 32 from Def you can find more. Great example is This War of Mine. That game has offset pattern between items ID values. @Enyby If you want, contact me, I have ideas for adding offset calc and making it simple/seamless.
    1 point
  5. For @NoFear need next offset I suppose: He find level, gold, and tokens in previous searches. And now want after find gold fast go to level and tokens with known offsets. For this he need calculator of offset. I am right, @NoFear?
    1 point
  6. It is only for PC. On Android ASLR. For working this offset you need persistent address or offset between two address. Base entry point for example and your value. Now I check one thing. I use Zombie Hive game. It have gold value. it can be easy finded. I search gold and get next data for two different runs: 31BF2C38 3D6E1408 313b8000-3198a000 rw-p 00000000 00:04 2134 /dev/ashmem/dalvik-heap (deleted) 3198a000-31c9a000 rw-p 005d2000 00:04 2134 /dev/ashmem/dalvik-heap (deleted) 31c9a000-34bb8000 ---p 008e2000 00:04 2134 /dev/ashmem/dalvik-heap (deleted) 34bb8000-34c98000 rw-p 00000000 00:04 2135 /dev/ashmem/dalvik-bitmap-1 (deleted) 34c98000-34d78000 rw-p 00000000 00:04 2136 /dev/ashmem/dalvik-bitmap-2 (deleted) 3d066000-3d69e000 r-xp 00000000 08:11 8089 /data/data/com.mobirix.zombiehive/lib/libcocos2dcpp.so 3d69e000-3d69f000 r-xp 00000000 00:00 0 3d69f000-3d6e2000 rw-p 00638000 08:11 8089 /data/data/com.mobirix.zombiehive/lib/libcocos2dcpp.so 3d6e2000-3d719000 rw-p 00000000 00:00 0 3db19000-3db1d000 rw-p 00000000 00:00 0 31BF2C38 - 3198a000 = 268C38 3D6E1408 - 3d69f000 = 42408 31C01720 3CAED408 313b8000-3198a000 rw-p 00000000 00:04 2134 /dev/ashmem/dalvik-heap (deleted) 3198a000-31c9a000 rw-p 005d2000 00:04 2134 /dev/ashmem/dalvik-heap (deleted) 31c9a000-34bb8000 ---p 008e2000 00:04 2134 /dev/ashmem/dalvik-heap (deleted) 34bb8000-34c98000 rw-p 00000000 00:04 2135 /dev/ashmem/dalvik-bitmap-1 (deleted) 34c98000-34d78000 rw-p 00000000 00:04 2136 /dev/ashmem/dalvik-bitmap-2 (deleted) 3c472000-3caaa000 r-xp 00000000 08:11 8089 /data/data/com.mobirix.zombiehive/lib/libcocos2dcpp.so 3caaa000-3caab000 r-xp 00000000 00:00 0 3caab000-3caee000 rw-p 00638000 08:11 8089 /data/data/com.mobirix.zombiehive/lib/libcocos2dcpp.so 3caee000-3cb25000 rw-p 00000000 00:00 0 3cd25000-3cd29000 rw-p 00000000 00:00 0 31C01720 - 3198a000 = 277720 3CAED408 - 3caab000 = 42408 3CAED408 - 3c472000 = 67B408 Now we get next results: First value is from Java and stored by different offsets. I think it is cache of loaded data. Second value is real data and stored as global variable in C lib. Because of that it have persistent offset from lib base. I try check this on Droid4X: 14000000-14638000 r-xp 00000000 08:13 868382 /data/app-lib/com.mobirix.zombiehive-1/libcocos2dcpp.so 14638000-14639000 r-xp 00000000 00:00 0 14639000-1466f000 r--p 00638000 08:13 868382 /data/app-lib/com.mobirix.zombiehive-1/libcocos2dcpp.so 1466f000-1467c000 rw-p 0066e000 08:13 868382 /data/app-lib/com.mobirix.zombiehive-1/libcocos2dcpp.so 1467c000-146b3000 rw-p 00000000 00:00 0 146b3000-14800000 ---p 00000000 00:00 0 1466f000 + 42408 = 146B1408 - no luck. May be different? I search value. 1467b408 1467b408 - 1466f000 = C408 Hmm. 1467b408 - 14639000 = 42408 1467b408 - 14000000 = 67B408 Results: different firmwares use different regions names. But idea can be used. This is very lucky case because data stored as global variable of shared lib. In this case it work. In another - not. Currently we have case with Gold1 and offset1. It is easy case. But for Gold2 or Gold3 we do not have any information about offset2-offset7.
    1 point
  7. It is only offset from begin load ELF in most cases. You can call cat /proc/pid/maps from root and get first address of ELF file (lib*.so). After that you can substract this address from any memory address and get same of IDA value. _______________________________________________ added 1 minute later But I do not see any practical sense in these numbers. You can go to HEX tabs to ida, copy 16 bytes and search them as group search on code region. it wiil be find need place very fast.
    1 point
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.