Enyby

They rewrite all to Java timers. Java in ART can not be speedhacked.

I do not know. May be "lbmain".

Another option, which affects the speed of search - access to memory. It has three values: Normal - the usual option, suitable for most cases. Extended - can sometimes speed up access to memory or cause a hang-up and reset. Experimental - the same as above, but more options. All except the first, can cause problems. Try at your own risk.

Attach apk from game.

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.

Reason is simple: "Hide" worked as pause process on any attach to game. "Freeze" worked as attach to process every 30 ms and rewrite values. Combine them and you get pause/unpause process every 30 ms. It is extremely hard and cause lags. _______________________________________________ added 1 minute later "Hide" in most cases is useless. But people once setup it to "yes" and after use freeze. And complain about "bad freeze in GG" over Internet.

Bypass - no.

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.

I found one interested link: https://nethackwiki.com/wiki/Negative_gold

LOL. I'm happy for you. You solved your problem. It is a pity that you not learned read anything from what write to you. Yes I have this too many times. Here proof: https://www.youtube.com/watch?v=OVB3ZP3b6As Hint: gold located on top center of screen. And it is negative. https://www.youtube.com/watch?v=ahWHBs2CsjU And last one is Windows. Even not Android. You can search by self on Youtube and Google by query "hack negative gold".

I read your posts very carefully "smart boy": I doubt on it... Try read my posts. Not only post and edit own posts. Joke in topic: Man buy electronic watch. Walk to street. Small boy ask: - What time? - I do not know. I try divide 12 to 34 but can not get result.

Because it is not method. Because it is data type. Because data type can be signed. Because signed data type can store negative numbers. Not, problem with you. Because you do not make difference between "-" and " - ". Space you see it? With spaces around it is dash. Read next: 2–3 weeks Or you think this mean 40 and -50 people? 2 and -3 weeks? Or may be subtraction? 40-50 = -10 peoples? 2-3 = -1 weeks? ROFL. _______________________________________________ added 1 minute later But in change log of 8.6.0 written:

-2 billion (lowest signed) and +4 billion (highest unsigned). Read in wiki about signed numbers. I do not see any problem.

Everybody collect data. This forum too. It is common practice. You can not change this. But you put in web match more from collected.

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.

What you problem?

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.

Not all. Look precisely. "-" is sign, " - " is interval.

Unfortunately dev of this forums (IPS) support only Chrome. We already have issues with AOSP browser and they deny support it. Very bad practice. _______________________________________________ added 2 minutes later No. It is more dev problems. They support only Chrome. They ignore all others browsers. They use doubt solutions worked only on Chrome. But we need deal with this. We can not rewrite forums.

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: