Weird WndProc hook : Crash when zoning/loading into game

[nippel]

I'm a bit out of options and maybe someone else has an idea.
I've hooked 2 different spots that are both using the WndProc arguments (one beeing the correct windowclass wndproc) with 2 different hooking methods and each time I go from charscreen to ingame the game crashes and their errorhandler catches it. Both wndproc hooks work completely fine in the mainmenu/charselect and ofc ingame. But the moment you zone from a big map to the next one or go from charscreen to ingame, it goes boom
I breakpointed the start of the WndProc function as well as a bit more down the func and both times I see it beeing "written" by an instruction "mov edi, [eax-4]" which is located in the .reloc seqment of the exe. The return pointer / calling functionptr was always 0.
The "mov edi, [eax-4]" instruction itself does (when the bp gets hit) start with an eax beeing the eso.exe baseaddr and then goes upwards through the memory. Sadly I have no fckn clue what it does here, maybe does a copy of it, reinitializes/recreates the whole shit or does some integrity check...no idea. All I know is that trying to find a reference in IDA lead always to some weird / not analysed / .reloc section regions.

Anyone else was playing with that and having this issue or an explanation maybe ?.

[Cypher]

I'm a bit out of options and maybe someone else has an idea.
I've hooked 2 different spots that are both using the WndProc arguments (one beeing the correct windowclass wndproc) with 2 different hooking methods and each time I go from charscreen to ingame the game crashes and their errorhandler catches it. Both wndproc hooks work completely fine in the mainmenu/charselect and ofc ingame. But the moment you zone from a big map to the next one or go from charscreen to ingame, it goes boom
I breakpointed the start of the WndProc function as well as a bit more down the func and both times I see it beeing "written" by an instruction "mov edi, [eax-4]" which is located in the .reloc seqment of the exe. The return pointer / calling functionptr was always 0.
The "mov edi, [eax-4]" instruction itself does (when the bp gets hit) start with an eax beeing the eso.exe baseaddr and then goes upwards through the memory. Sadly I have no fckn clue what it does here, maybe does a copy of it, reinitializes/recreates the whole shit or does some integrity check...no idea. All I know is that trying to find a reference in IDA lead always to some weird / not analysed / .reloc section regions.

Anyone else was playing with that and having this issue or an explanation maybe ?.

You probably can't see the code in the .reloc section because IDA is discarding it. When opening the file use the "Manual Load" checkbox.

[nippel]

You probably can't see the code in the .reloc section because IDA is discarding it. When opening the file use the "Manual Load" checkbox.

I have the "proper" unpacked exe and also manually loaded into ida, so I can see most of the code, but ofc not all .reloc secton areas are completely analysed. I can see the asm it "live" in CE, it looks the same in ida. I just never saw such behavior before and have no explaination what the game is doing in that moment.

[cute_star]

Whenever i hooked some functions or patch the original code of code section , they shows 'Zo crash reporter' .
I think they ( packer ?) detect the patching .
How can i bypass the detection ? or anyone already solved this problem ?

[IchTreffeNix]

Maybe your hook is wrong and you're pushing the args wrong or your stack is corrupt. My hooks are fine over here. Provide some code and the function you'd like to hook.

[nippel]

The hooks are fine until you load into a new zone, then their exe is doing something with larger chunks of their allocated memory of their exe which breaks the hooks.
So far I can live without them, I was just curious if anyone else experienced the same and maybe knows what exactly is happening here.

For example try to hook the mainwindow WndProc , currently at .text:004B9400 WndProc, then load into a game from charscreen and see the crash happening.

[Sirmabus]

I ran into this too.
Will be interesting to use a guarded/trapped code page (or something else) to find out when and where
code is being checked/hashed, if that's what they are doing.

Also were you able to get a debugger running? Mind you I haven't tried any anti-debugger/hide plug-ins yet, but after just allowing the single step and access violation
exceptions to pass, I hit a non-passable one.

One of these days I'd like to make a complete DLL debugger module (like old SoftIce but in R3, and per-process) that doesn't use the "debugger" API, I can load into a client and
not hit any anti-debugger stuff, nor be detected as one. Maybe someone already made such a thing?

[viperbot]

Have you tried Olly? Just need StrongOD and PhantOm. Its really nice since Olly is fully scriptable you can make some nice plugins.

[Sirmabus]

Guess it'll have to be on an XP machine then.

[nippel]

well you can always run the good old CE in VHE mode and attach the debugger, that doesnt trigger anything and works fine in ESO to breakpoint n check the access on the hooks.

[JuJuBoSc]

Had the same issue while patching their code for speed hack, I told Cypher about that on skype, they probably detect patch in their code (themida stuff?).
But for WndProc I didn't have any issue as it don't modify their code, just used SetWindowLong stuff to install my own WndProc callback.

[Cypher]

I ran into this too.
Will be interesting to use a guarded/trapped code page (or something else) to find out when and where
code is being checked/hashed, if that's what they are doing.

Also were you able to get a debugger running? Mind you I haven't tried any anti-debugger/hide plug-ins yet, but after just allowing the single step and access violation
exceptions to pass, I hit a non-passable one.

One of these days I'd like to make a complete DLL debugger module (like old SoftIce but in R3, and per-process) that doesn't use the "debugger" API, I can load into a client and
not hit any anti-debugger stuff, nor be detected as one. Maybe someone already made such a thing?

I believe CE has functionality similar to this, but I think it's quite buggy. Doing something like that is also on my long term todo list, but it's a pretty hefty task to get everything working properly.