For this I call GetClassInfoA to get the window procedure of, let's say, the textbox (class name is "edit") and then modify it by writing a jump instruction at the very beginning of it's code (with WriteProcessMemory). I already did so with things like MessageBoxA and it worked perfectly. Whenever I call MessageBoxA, it calls my function instead. Fine
But now I want to 'overwrite' controls' window procedures (like 'edit' or 'static' or 'button'), which doesn't work. WriteProcessMemory fails.
Debugging a little bit I noticed that the window procedures of them are located somewhere around at 0xFFFF0000 (so says GetClassInfo) - which is kernel memory, isn't it? Isn't the entire window stuff done in usermode?
From my knowledge I thought that these controls's classes are registered when calling InitCommonControlsEx from commctrl.dll, which is located in user memory, so the window procedures are also located in usermem (so I can hook them). But my call to GetClassInfoA says something different
[/size]Edit: Huh, now I used the Unicode version GetClassInfoW, which gives me a location of the 'static' window procedure at 0x700000. lets see...
Edit2: Now I can intercept some messages like WM_CREATE and WM_PAINT, but the WM_SETTEXT one is never delivered to the hooked window procedure of the 'button' class...
Edit3: Ah, see button's text is set on WM_CREATE
Edit4: WTF I'm doing. I could also Unregister these classes and register my own replacements.... easier and much less hacky.
->Thread can be closed.