I came across "a strange" inconsistency in terms of the function addresses in the particular application.

First, the main function is hooked successfully, the address is derived in a fashion:

baseAddress + Offset, i.e. from Ghidra baseAddress is 140000000 and the address of the main function is: 0x39EA0

So, the main function address is

(DWORD_PTR*) baseAddress + 0x39EA0 / (2 * sizeof(DWORD))

This works just fine.

But now I am trying to call

gladius::world::World* __fastcall gladius::gui::GUI::getWorld(gladius::gui::GUI* thisptr);

from within the hooked function and

which according to Ghidra supposed to be at 14003ef30.

That makes the offset equal to 0x3ef30 (plus pointer arithmetic). But at that offset from the baseAddress I get



which in the static analysis is at address 14003ecc0, 270 bytes away from the static address of getWorld.

So, what is happening? Why the stack shifted by 270 bytes? Is it the size of my hooked function?

  • Found using x64dbg that the address of the getWorld function shifted in comparison to static analysis by 60 bytes, i.e. it is 0x3EF90. Why it is the case is still not clear.
    – Irbis77
    Oct 15 at 17:32
  • 1
    what is the xxx / (2*sizeof(DWORD) ) if you have a correct base +offset they simply cannot be different in different invocations or tools base + offset should always yield the same symbol ie if main is at 0x1000 + 320 ==1320 then main can be at 2320 or 8320 or 0x4000320 but not 2860 or 8940 or 0x400199 etc offset cannot be different check the casting , division precedence , bracketing etc and also when you write your query provide the tools output rather than your interpretation of result this works fine may not be actually fine because you interpreted it wrong
    – blabb
    Oct 19 at 16:58
  • xxx/ (2*sizeof(DWORD) is a reference to pointer arithmetic. I.e. DWORD_PTR* address = <pointer address> + sizeof(DWORD_PTR). Not sure, why it is 2* in this case, but it gives the right offset for most of the functions. I will update the question with the screenshots for the place in the debug run in question. Thank you.
    – Irbis77
    Oct 20 at 12:23

OK. Found the issue after checking the screenshots again. It seems that I simply missed the correct beginning of the function while examining Ghidra output.

Verifying everything once again as @blabb has suggested has shown that I've missed the correct address for the beginning of the function.

Here are screenshots for how to it was evaluated:

Address in Ghidraenter image description here:

Addresses in VS: enter image description here

As you can see the Ghidra offset = 140000000 - 140353ed0 = 353ed0

Is the same as VS offset = createWorld - baseAddress = 0x00007ff6076d3ed0 - 0x00007ff607380000 = 353ed0

As I said - there was a mistake in checking Ghidra offset somehow...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.