Finding real offsets of IDA

[iAndroHacker]

Is it possible to find real offsets of IDA when i found an address to hack a value with GG without debugging with PC?

 

I know that Cheat Engine does have an ability to find real offsets so that peoples could use it in their trainer tools

[Enyby]

What do you mean on "real offset"?

[geribaldi]

  On 10/15/2016 at 2:50 PM, Enyby said:

What do you mean on "real offset"?

Expand  

 

@Enyby

 

Lol, everytime anybody is talking about offsets, you ask the same question.

 

I would say, "" learn more about pointers c, c+ and you understand what a offset is.....but i think you know what it is, but maybe u use any other word for it

 

http://www.unknowncheats.me/forum/search.php?searchid=6422707

 

 

 

 

[Enyby]

  On 10/15/2016 at 4:11 PM, geribaldi said:

Lol, everytime anybody is talking about offsets, you ask the same question.

Expand  

Because who is talking do not know what is that. Everyone mean it different.

 

  On 10/15/2016 at 4:11 PM, geribaldi said:

I would say, "" learn more about pointers c, c+ and you understand what a offset is.....but i think you know what it is, but maybe u use any other word for it

Expand  

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.

 

  On 10/15/2016 at 4:11 PM, geribaldi said:

http://www.unknowncheats.me/forum/search.php?searchid=6422707

Expand  

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

[iAndroHacker]

i mean these.

 

GDB and LLDB can get real offsets in IDA of value address found in-game while doing watchpoint but watchpoint does not work on any Android versions. Only work for iOS devices

 

[Enyby]

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.

 

 

[Enyby]

  On 10/15/2016 at 5:04 PM, iAndroHacker said:

GDB and LLDB can get real offsets in IDA of value address found in-game while doing watchpoint but watchpoint does not work on any Android versions. Only work for iOS devices

Expand  

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.

[geribaldi]

For me is a offset a known memory adress for a value like playerspeed, colors, amm, bulletspeed//spread etc.

 

 

for example here for battlefield 1. the offset is everywhere the same, on ever pc until the the game is updated.

 

So coders can code one hack for on game and everyone can use this

 

 

  Quote

Expand  

Some of the addresses that I use:

#define OFFSET_MAIN 0x1430E8C48 //48 89 1D ?? ?? ?? ?? 48 8B 77 70 - Relative

	#define OFFSET_GAMERENDERER 0x1435B1708 //48 8B 0D ? ? ? ? 4D 89 63 20 - Relative

	#define CLIENT_GAME_CONTEXT 0x1433C9670 //48 8B 0D ? ? ? ? 48 83 C1 10 48 8D 95 ? ? ? ? E8 ? ? ? ? 90 48 8D 8D ? ? ? ? E8 ? ? ? ? 48 8B 8E ? ? ? ? - Relative

	#define BORDER_INPUT_NODE 0x143050CB8 //48 8B 0D ?? ?? ?? ?? 48 83 C7 08 - Relative & xref from

	#define GET_ENTITY_LIST 0x144AC1260 //48 63 42 28 48 83 C0 06 

	#define CLIENT_GAME_WORLD 0x1433C1C30 //48 8B 0D ?? ?? ?? ?? E8 ?? ?? ?? ?? 48 89 D9 E8 ?? ?? ?? ?? 90 48 8B 93 ?? ?? ?? ?? - Relative



	//UNSURE

	#define OFFSET_DEBUGRENDERER 0x14427B9C0 //48 8B 0D ? ? ? ? 48 85 C9 75 04 

	#define OFFSET_DRAW_ENGINE_TEXT 0x14427DED0 //48 89 5C 24 ? 48 89 6C 24 ? 48 89 74 24 ? 57 48 83 EC 20 4C 89 CF 44 89 C6

	#define OFFSET_DRAW_ENGINE_LINE 0x14427DA40 //48 89 5C 24 ?? 44 89 4C 24 ?? 57 48 83 EC 20 48 89 D3

	//END-UNSURE



	#define OFFSET_DX11_SCREENSHOT 0x144F6A380 //57 48 83 EC 30 48 C7 44 24 ? ? ? ? ? 48 89 5C 24 ? 48 8B 99 ? ? ? ? 

	#define OFFSET_REQUEST_BITBLT_SS_1 0x14567A840 //48 89 5C 24 ? 55 56 57 41 54 41 55 41 56 41 57 48 81 EC ? ? ? ? 48 8B 05 ? ? ? ? 48 31 E0 48 89 84 24 ? ? ? ? 8B 9C 24 ? ? ? ?

	#define OFFSET_REQUEST_BITBLT_SS_2 0x145636780 //48 89 5C 24 ? 55 56 57 41 54 41 55 41 56 41 57 48 81 EC ? ? ? ? 48 8B 05 ? ? ? ? 48 31 E0 48 89 84 24 ? ? ? ? 44 8B B4 24 ? ? ? ?

	#define OFFSET_GET_HARDWARE_INFO 0x1455640D0 //55 56 57 41 54 41 55 41 56 41 57 48 8D AC 24 ? ? ? ? 48 81 EC ? ? ? ? 48 C7 44 24 ? ? ? ? ? 48 89 9C 24 ? ? ? ? 48 8B 05 ? ? ? ? 48 31 E0 48 89 85 ? ? ? ? 4C 89 C7 49 89 D4 

	#define OFFSET_REQUEST_CAMERA_INFO_MESSAGE 0x145633480 //53 48 81 EC ? ? ? ? 48 C7 44 24 ? ? ? ? ? 48 8B 0D ? ? ? ?



	variables::m_ShowCursor = 0x144B06A3D; //88 4B 7C 40 88 7B 7A

	variables::m_CursorMode = variables::m_ShowCursor + 3;[/CODE]

ClientSoldierEntity changed a lot

[CODE]class ClientSoldierEntity
{
public:
    char _0x0000[448];
     BFClientSoldierHealthComponent* m_pHealthComponent; //0x01C0 [BFClientSoldierHealthComponent]
    char _0x01C8[664];
    BoneCollisionComponent* m_pBoneCollisionComponent; //0x0460 
    char _0x0468[304];
    ClientSoldierPrediction* m_pClientSoldierPrediction; //0x0598 
    char _0x05A0[20];
    float m_AuthorativeYaw; //0x05B4 
    char _0x05B8[44];
    float m_AuthorativePitch; //0x05E4 
    BYTE m_PoseState; //0x05E8 
    char _0x05E9[95];
    ClientSoldierWeaponsComponent* m_pClientSoldierWeaponsComponent; //0x0648 [ClientSoldierWeaponsComponent]
    ClientSoldierBodyComponent* m_pClientSoldierBodyComponent; //0x0650 [ClientSoldierBodyComponent]
    ClientSoldierBreathControlComponent* m_pClientSoldierBreathControlComponent; //0x0658 [ClientSoldierBreathControlComponent]
    char _0x0660[8];
    ClientAimEntity* m_pClientAimEntity; //0x0668 [ClientAimEntity]
    ClientSoldierWeapon* m_pClientSoldierWeapon; //0x0670 [ClientSoldierWeapon]
    char _0x0678[32];
    BYTE m_Sprinting; //0x0698 
    BYTE m_Occluded; //0x0699 
    char _0x069A[118];
    ClientSpottingTargetComponent* m_pClientSpottingTargetComponent; //0x0710 [ClientSpottingTargetComponent]
    char _0x0718[648];
    ClientBoneComponent* m_pClientBoneComponent; //0x09A0 [ClientBoneComponent]
char _0x09A8[8];

};//Size=0x09B0

class ClientSoldierPrediction
{
public:
    char _0x0000[64];
    Vector4 m_Position; //0x0040 
    char _0x0050[16];
    Vector4 m_Velocity; //0x0060 
    char _0x0070[68];
    BYTE m_PositionState; //0x00B4 
char _0x00B5[7];

};//Size=0x00BC

class GameRenderer
{
public:
    char _0x0000[64];
    __int64 m_pGameRenderSettings; //0x0040 [GameRenderSettings]
    char _0x0048[24];
    RenderView* m_pRenderView; //0x0060 

};//Size=0x0068 [/CODE]

Haven't tested it all[/QUOTE]

[Enyby]

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.

[Enyby]

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?

[NoFear]

  On 10/15/2016 at 11:17 PM, Enyby said:

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?

Expand  

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. 

[iAndroHacker]

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

Edited October 16, 2016 by iAndroHacker

[Enyby]

Bypass - no.

[geribaldi]

I love this constructive diskussions i miss on other forums. that's great gentlemens

[iAndroHacker]

ok

[Skullboyq]

  On 10/16/2016 at 12:06 PM, iAndroHacker said:

ok

Expand  

"Constructive discussions"