Leaderboard

thanks a lot!worked!

No. But I do not see any problem. Most of game do not trace attach to self. Or trace from separate process. In both cases option "Hide" useless. It is same as shot in leg and after that complain on pain. Or ask about how shoot in leg without pain. LOL.

"Constructive discussions"

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.

To start, you need to draw a pentagram with the correct spells. Then kill the victim on the altar. Sprinkle the blood of the victim pentagram. Then say the spell. Well, or something like that.

I tried double and qword and both failed for me....

0 Gold 1 Diamond 2 Weapon Material 3 Armor Material 4 Shield Material 5 Helmet Material 6 Auto Skills 7 Auto Breath 8 Auto Heal 9 GameSpeed 2X 10 Gold Get 2X 11 Korean Gold (Will Crash your Game) 12 Same (11) 13 Same (11) [...] You get the idea

So what you have to do is edit the play reward as Dword really if you want a video i can show you how to hack EVERYTHING (not only gold and diamonds) The reason you cant edit gold and diamond directly is because it has hard encryption + fake values that crash when you edit them (i tried every value 1 by 1 still didnt work) so you need to hack Play Reward But first ill show Diamond and Gold 1. Press on Play Reward 2. Search how much gold you will get next in play reward, if you dont have gold then do it as long as gold is on top of play reward. (For me gold was 10000 and on top) 3. Edit all of them and Increment (press More when you press known) by 1 so you can revert all of them later 4. Close the GG Tab and look at your gold, remember that number and open gg. For example instead of 10000 its now 10060 so remember 10060 5. Select all Values EXCEPT the one you remembered. (10060 in my case) 7. Revert all of them and delete selected. 8. now you only have 1 gold value edit that to 2,123,456,789 and now Play or speedhack until you can get the Play Reward 9.Click on it and get 2billion gold Diamonds (for this you need to first have hacked gold) 1. You need to press on the Gold Value you just edited (save the value you will need it) 2. press go to and move around 30 Lines up, there you will find your new Play Reward 3. If you want diamonds change the value above the number of items you will get next as reward (for me it was 20000 Gold) Edit the value above 20000 to 1 and the 20000 to 2123456789 and you have 2 bil diamonds i will provide a item id list now so look out for that

ok

Bypass - no.

too confusing for me... but is it possble to bypass ALSR on Android like they did on iOS?

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?

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.

Okey. Let go with example. We have class Player with field "gold". Field stored at 0x140 from object begin. Then if object have pointer = 0x123000, then gold have address = 0x123140. Pointer + offset. Now we have one object of player. It created with operator "new" of C. This operator create new or use exists anonymous memory region and allocate on it memory. Because of ALSR it can be in any place of memory. Because of operator "new" it do not have any concrete name or have common name like "malloc". Pointer to this memory can be saved in stack of main loop or in .bss or .data segment of memory. This too present some offset from start of memory region. 0x140 not present in memory in most cases. It is hard-coded in assembler operands. Like "mov r0, [r3, 0x140]" We can find value of gold in memory. Okey. We find it in some way. It is have address 0x4567890. Now we need find pointer but how? We do not know need offset in Player object. If we known it we can calculate 0x4567890 - 0x140 and search this value in memory, but we do not know it. And in next build of game this offset can be different. And this I only show general problem. Let go deeper. Assembler. In arm assembler all offset calculated from current point. In x86 we can use on base for all offsets. Arm. load string look like: get pc register + some offset constant - result put in register. It will pointer to string. Because offset rely on PC register - then offset for one string in different places is different. Okey. X86. Load string look like: get segment address + some offset constant - result put in constant. it will be pointer of string. Because offset rely to segment address (they stay same in most cases) - then offset to one string in different places will be same. Okey. Return to Arm. Arm have limitations to load big numbers in one instructions. If offset too big it can not be loaded with one instructions. It can be loaded with two instructions: 1. Or as load low part + load high part - data stored in instructions. 2. Or as load small offset to number placed near (usually after function code) and second command used this loaded number as relative offset. both of them rely to PC register. Both of them rely to position of current command. Nice things? Tell me what you mean by offset in this case and how we can found it.