Posted: Mon Sep 13, 2021 9:43 am Post subject: Base address in CE does not match EnumProcessModules
Hey guys, I am slowly getting there I have a little bit of code that enumerates all the modules of the process I am targeting. From that list, I can see the base address is "0xABA50000" which already strikes me as an odd address. The weird thing is, this address is THE SAME every time I launch the game. Also if I just make an entry in cheat engine of "game.exe" as a pointer, it gives me the true base address, which is more consistent with the address space I am expecting. In this case it looks like this "300905A4D". I will post a screenshot of my process enumeration. The code that is printing this is taken from the microsoft docs page labeled "enumerating-all-modules-for-a-process" for win32 docs (Sorry, can't post urls yet).
I was wondering if it might have something to do with ASLR, but since the address is the same every time I don't think so. I'm sure I am just missing a step or something, any help would be appreciated!
The arrow operator -> means "points to". The value stored at the address game.exe is 300905A4D. You can also see the first two bytes are the DOS header magic number 4D 5A - "MZ".
Don't use the pointer checkbox. Just put game.exe in the address field to see what address it is, or execute this Lua code:
Code:
print(('%08X'):format(getAddress'game.exe'))
All images (exe / dll files) will be loaded at an address that is some multiple of the windows allocation granularity (0x10000) - the last 4 bytes will always be 0. The address ABA50000 is fine for an image to be loaded at, while 300905A4D is impossible. _________________
I don't know where I'm going, but I'll figure it out when I get there.
Thank you Parkour, you helped me out yesterday as well. I actually figured this one out a little while after posting. The process is 64 bit, so I needed to be retrieving 8 bytes instead of 4! I was clipping off a good portion of the address. Accounting for that and all is finally working! Appreciate your hep
Interesting note on the window allocation granularity, I'll look more into that as I'm curious now.
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum