Walk Function & PlayerObjectManager

05/28/2023 23:15 ManuLeLe#1

Hi!
I'm starting to learn again about in-memory cheats and I've managed to find by myself the walk function.

[Only registered and activated users can see links. Click Here To Register...]

I managed to find a working pattern:
8b43??3b43??0f95??8843??84c074??6a??33c9

Code:

8b43??  mov eax, [ebx+04] (currentX)
3b43??  cmp eax, [ebx+08] (destinationX)
0f95??   setne al
8843??  mov [ebx+1c], al
84c0      test al, al
74??      je NostaleClientX.exe 123
6a??      push 01
33c9     xor ecx,ecx
            mov edx, [ebx+08] (basically (y << 16 | x))
(BP)      mov eax, ebx      (ebx is the pointer to the player object (?))
            call NostaleClientX.exe+14F940

I've put a breakpoint to the line where you can see (BP) to obtain the ebx value that contains the pointer to the player object and by searching its value I found a single address that points to the player object pointer.

[Only registered and activated users can see links. Click Here To Register...]

I've added it to the table of values and set it as a pointer and found the address of 00548FB0 which I guess should be the pointer to the PlayerObject?
I've found by dissecting the structure in Cheat Engine that there's an actual string called PlayerObjManager in memory, so you're telling me that they actually put the string of their classes also in the released binary? Is it a normal thing?

Also, do you have any idea on how I could easily find an instruction that uses the PlayerObjManager pointer so I can easily retrieve it and use the walk function?
I really don't know much about PlayerObjManager, I've trying to explore the memory around it but nothing changes when my HP/MP decrease or increase, neither if my position or gold amount change.

I'm using this code to call the walk function, but the game crashes instantly:

Code:

_asm {
push 1
xor ecx, ecx
mov edx, position
mov eax, addressOfPlayerObjManager
call walkFunctionAddress
};

05/29/2023 02:06 romdrak#2

Quote:

I've found by dissecting the structure in Cheat Engine that there's an actual string called PlayerObjManager in memory, so you're telling me that they actually put the string of their classes also in the released binary? Is it a normal thing?

No they don't, it's virtual table which is autogenerated by the compiler, it's used for dynamic method calling. It contains pointers to some virtual methods, class name, object size, ptr to parent class etc.

Quote:

Also, do you have any idea on how I could easily find an instruction that uses the PlayerObjManager pointer so I can easily retrieve it and use the walk function?

If you're using cheat engine then just find the TPlayerObjManager object, add some of its fields to the address list and use the "Find what accesses this ptr" or something like that. (or just go to the function that calls the walk function you found) and just backtrack how was the pointer accessed, you're looking for something like "mov REG_A, 0xXXXXX" "mov REG_A, REG_A".

Quote:

I really don't know much about PlayerObjManager, I've trying to explore the memory around it but nothing changes when my HP/MP decrease or increase, neither if my position or gold amount change.

That's because TPlayerObjManager doesn't hold any of those values, just explore to what structures does the TPlayerObjManager point to (from vtables) and I'm pretty sure something will catch your eye.

Quote:

I'm using this code to call the walk function, but the game crashes instantly:

Sadly this doesn't give us enough info for us to be able to help you. My guess is that you're passing addressOfPlayerObjManager.vtable to the EAX instead.

05/29/2023 10:15 JONNST4R#3

hey,

on the right picture you can see "P->00549020" it should be "P->11AB0EB0" this means its not the pointer to "PlayerObjManager". And put the breakpoint in the line with the call because else you get the value in eax before the mov operation which is wrong.

To find the correct pointer follow these steps:
Scan for the address in the eax register (its not the register address) then you see a green address thats the pointer you are looking for. Paste this green address into "Dissect data/structures" and write -100 to the address now define the new structure. Now you see it points to the right address.

Because you have a pointer you have to write the assembly code like this:

Code:

push 01
xor ecx, ecx
mov edx, 00010001 // coords
mov eax, NostaleClientX.exe+4BA4E8 //TPlayerObjManager
mov eax, [eax] // 
call 0054F940 //function
ret

And yes

Code:

 mov eax, [NostaleClientX.exe+4BA4E8]

is not working

05/29/2023 18:48 ManuLeLe#4

As a reply to @[Only registered and activated users can see links. Click Here To Register...] :

Quote:

If you're using cheat engine then just find the TPlayerObjManager object, add some of its fields to the address list and use the "Find what accesses this ptr" or something like that. (or just go to the function that calls the walk function you found) and just backtrack how was the pointer accessed, you're looking for something like "mov REG_A, 0xXXXXX" "mov REG_A, REG_A".

Quote:

Sadly this doesn't give us enough info for us to be able to help you. My guess is that you're passing addressOfPlayerObjManager.vtable to the EAX instead.

Thank you so much for the thorough reply!
That's what I've came up to and this is the pattern I've found, along with the code I'm using to test:

Code:

//a1????????8b70??85f674??807b + 0x19
//WalkFunctionPattern + 0x19 + 0x1 (1 for skipping E8 as it is the CALL's opcode)
auto addr = FindPattern(moduleBase, mod.SizeOfImage, "\x8b\x43\x00\x3b\x43\x00\x0f\x95\x00\x88\x43\x00\x84\xc0\x74\x00\x6a\x00\x33\xc9", "xx?xx?xx?xx?xxx?x?xx") + 0x19 + 0x1;
//the call is to a relative address, so I had the call's address, the relative value and then add 4 as it's relative to the next instruction address
auto walkFunctionAddress = addr +  *((DWORD*)addr) + 0x4;

//Now I want to find the address of the TPlayerObjManager*
addr = FindPattern(moduleBase, mod.SizeOfImage, "\xa1\x00\x00\x00\x00\x8b\x70\x00\x85\xf6\x74\x00\x80\x7b", "x????xx?xxx?xx") + 1;
//This is basically a TPlayerObjManager**
auto ptrToPtrOfPlayerObjManager = *((DWORD*)addr);
auto addressOfPlayerObjManagerPtr = *((DWORD*)ptrToPtrOfPlayerObjManager);

//So to call the walk function the code will be:
short x = 107, y = 200;
DWORD position = (y << 16) | x;
__asm {
push 1
xor ecx, ecx
mov edx, position
mov eax, addressOfPlayerObjManagerPtr
call walkFunctionAddress
}

The issue with the game crashing was that instead of treating the CALL's offset as a relative address, I thought it was absolute by default.
Basically the error was that I was using this code:

Code:

//WalkFunctionPattern + 0x19 + 0x1 (1 for skipping E8 as it is the CALL's opcode)
auto addr = FindPattern(moduleBase, mod.SizeOfImage, "\x8b\x43\x00\x3b\x43\x00\x0f\x95\x00\x88\x43\x00\x84\xc0\x74\x00\x6a\x00\x33\xc9", "xx?xx?xx?xx?xxx?x?xx") + 0x19 + 0x1;
//ERROR BELOW: I should add the address of the CALL instruction and then 0x4 to point to the instruction right after
auto walkFunctionAddress = *((DWORD*)addr);

Quote:

That's because TPlayerObjManager doesn't hold any of those values, just explore to what structures does the TPlayerObjManager point to (from vtables) and I'm pretty sure something will catch your eye.

I will!

As a reply to @[Only registered and activated users can see links. Click Here To Register...] :
Thank you! You helped me by noticing I was using the CALL instruction to the relative offset instead of using an absolute address as in the error I was talking right above.

Much appreciated!
I will look forward to deepen my understanding. :handsdown:

05/29/2023 22:02 romdrak#5

Quote:

Originally Posted by ManuLeLe

Code:

//a1????????8b70??85f674??807b + 0x19
//WalkFunctionPattern + 0x19 + 0x1 (1 for skipping E8 as it is the CALL's opcode)
auto addr = FindPattern(moduleBase, mod.SizeOfImage, "\x8b\x43\x00\x3b\x43\x00\x0f\x95\x00\x88\x43\x00\x84\xc0\x74\x00\x6a\x00\x33\xc9", "xx?xx?xx?xx?xxx?x?xx") + 0x19 + 0x1;
//the call is to a relative address, so I had the call's address, the relative value and then add 4 as it's relative to the next instruction address
auto walkFunctionAddress = addr +  *((DWORD*)addr) + 0x4;

Usually it's easier to scan for the function itself, not for the caller function (there are obviously exceptions, like the function being too small for generating decent pattern or too similar to some other functions and the pattern being like 100 bytes).

05/30/2023 01:00 ManuLeLe#6

Quote:

Originally Posted by romdrak

Usually it's easier to scan for the function itself, not for the caller function (there are obviously exceptions, like the function being too small for generating decent pattern or too similar to some other functions and the pattern being like 100 bytes).

So I should directly scan for the function walk function instead by using the address of the CALL instruction?

05/30/2023 01:28 romdrak#7

Quote:

Originally Posted by ManuLeLe

So I should directly scan for the function walk function instead by using the address of the CALL instruction?

Yeah, you should scan for the beginning of the function you want to call. (at least in this use case)