Cheat Engine

[kuroro]

What's a good way to find out which ASM code is responsible for handling key presses? My current attempts were aimed at finding a memory address that might hold a keypress value, and then just find out which ASM is accessing/writing to it. I've tried doing memory scan of changing values (trying out different keypress everytime ) and i've also tried scanning for the exact ASCII codes of the keypress but those methods weren't helpful.

How would you guys approach this prob?

[Gniarf]

Preliminaries: In cheat engine, setup a hotkey to pause the process (in the options).
There isn't a single variable that holds what key is pressed (what would it hold if I pressed W+D+space?) but an array that stores separately the state of each key.

1-Release the desired key, do an unknown initial value scan, type=byte.
2-Go ingame, hold down the desired key and pause the process.
3-In CE, filter with changed (or increased) value.
4-Go ingame, unpause process, press and release desired key, pause process again.
5-Back to CE, filter with changed value if you're careful or exact value:0 if you want a relatively safe shortcut.
6-Go ingame, unpause, do some random stuff, ensure the desired key is not pressed. Pausing now isn't required.
7-Go in CE, filter with unchanged value.
8-Go to step 2 until only few results remain.
9-Test the few results that you can't filter out.

Other tips:
-In the last unreal engine 3 I hacked, key status (for each key) was 0 when released and 1 when pressed, stored as a 4 byte int.
-In another (old) game IIRC key status was 0x80 when pressed, 0 when released, stored as a single byte per key somewhere in a directX related dll (maybe dinput-something.dll). It was a couple years back so I don't remember very well.
-There is a possibility that is a counter that holds for how long the key has been held down which may be merged with the key's state (ex: the 0x80 may start increasing every ms when holding down the key).


Or a completely different possibility would be that your game periodically calls GetAsyncKeyState or GetKeyState, in which case I'd put a breakpoint on those, see where they are called from, nop that, and see how it affects my game.
Similarly your game could be parsing the WM_KEYDOWN message sent to your program. (<-Won't say more on that last possibility unless you're familiar with programming AND reverse engineering, otherwise I'd just speak chinese)

[kuroro]

Thanks a lot Gniarf. It was really helpful. I followed your steps (1-9) and I was eventually able to find the memory address where the key codes are being written to. Checking for the exact value of 0 after the key is released is brilliant I guess it's something that I wouldn't be able to think of unless I know how key events actually work and how it maps to memory.

I put breakpoints on "GetAsyncKeyState" and "GetKeyState", but only the latter yielded some results (although it was only checking for special keys such as ctrl,shift,window key) so it wasnt really what i was looking for.

Anyway, it seems like you're right about the WM_KEYDOWN message. After I've set a memory write breakpoint on the newly found addressp, it pointed me to the right ASM code, and looking at the callstack, I can see User32.DispatchMessage. Also the current function has the virtual keycode in its 2nd argument (4 in total), so it matches the signature of window message handler

I'm actually quite new to windows programming (coming from unix background), but just learning along slowly more about win32 api, message loop etc. Interesting stuff.

[Gniarf]

Heh, seems like there is not much for me to add, just that when you can't find key state through scanning, you can locate the message handler(s) by finding what function(s) call(s) or reference(s) User32.DefWindowProc. After that, since this function is just an enormous switch-case, find case 0x100.

[theidiot]

ty found this info very interesting