Leaderboard

In this topic will be published various useful information.

In some virtual spaces, a memory card can also be virtualized. That's why you need to download files from within the virtual space. Then they should definitely be available to other applications from the virtual space.

Hello world I am "ANONYMOUS 1000 HACKER" and I have created this theme for those people who wish to enjoy modified games. To install them is very simple. If your "mod" game does not have "obb" you just have to install it, open it and have an amazing time. @Anonymous1000 ?????

Yep, got that. Illustrated the example with "Parallel Space" as it might be useful for someone who is interested in this, also maybe for the creator of this topic.

Ok, I figured it out, correcting my conclusion from the previous post. Applications that are run from "Parallel Space" app does not access device's "/sdcard/" (or "/storage/emulated/0") folder directly. Instead of this, they use "parallel_intl" folder, which selectively replicates the structure of "/sdcard/" folder (some important folders are being copied I guess). All apps that are run inside of virtual space can read/write (if have such permission) from/to that "parallel_intl" folder, and it is seen as "/sdcard/" from them. Here is the SS of that folder's contents: I guess that @Enyby and @NoFear meant same thing. I am just not that good at terminology.

Did a try on my device, no root. Using Parallel Space and ES File Explorer apps. Dark theme for original app, bright - for the cloned one. Landscape mode to be able to see full path. Here are the results: As we can see, both paths lead to the same location, but, in my case, not all folders and files are visible in app that is run from virtual space.

Install as the "VIDEO" shows and you will have the best "Mod", because it is not necessary to uninstall the apk from the play store and to add it is linked to your google account, the "Apk vqs" will update the "Mod" when new versions come out. This mod is the best.

It's in my list of games to hack next...

neverming i forget to root my phone sorry for that...

Address can be any number. 0xFF is same as 255. So you can load number from memory and set it to address. 0x is just form. local t = {} t[1] = {} t[1].address = 0x18004030 -- some desired address t[1].flags = gg.TYPE_DWORD t = gg.getValues(t) print(t) -- use value as pointer t[1].address = t[1].value t = gg.getValues(t) print(t)

I do not see any concrete example from you. You say: Approve this by _______________________________________________ added 2 minutes later Search ac 8b r; EF EF r: 4 With type word.

Can not be. Give me concrete examples. What you search, and what you get. And what you expected.

Yes the problem remains, the precision of grouped search. Even if its a qword + dword search its displays any number of bytes those are somewhere near each other. So we can't get what we want. So its my humble request to developers that please consider adding AOB search. Thanks

Currently you can search 8 bytes as qword. GG support hex input for numbers and reverse-hex for big-endian. For example you can search BAADBEEFr as Dword. It is mean search {BA AD BE EF} byte array. It is 4 bytes. If you choice qword - you can search sequence of 8 bytes. You can use group search for find up to 8*8 = 64 bytes. Group search do not respect order of numbers, but if do not use common values then give needed results. You can combine different data type for search need amount of data. For example search 12 bytes can be done with qword + dword in group search. _______________________________________________ added 0 minutes later You can try describe its here.

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.

Because who is talking do not know what is that. Everyone mean it different. May knowledge say me: impossible. And word offset can mean too many: offset between values, offset from pointer, offset in structure and so on. I do not see any case who worked in general terms with pointers. May be I do not understand something. Explain to me of that happens. You are not logged in or you do not have permission to access this page. This could be due to one of several reasons: