Post Thanks / Like - 4 Thanks
You wrong, i have same problem on different game, but when i restore ring3 hook, maybe GetCommandLineA for veh error
after i restore ring3 hook, i can debug with veh debugger, use PC Hunter, use PC Hunter
Oh my fucking god? Rake made a youtube video.
Will.make a few more this month methinks
Originally Posted by HexMurder
Post Thanks / Like - 2 Thanks
CoD WW2 Anti Debug
Hey im working at the moment on finding out how the anti debug of CoD ww2 works. But im pretty much stuck. The game closes after some time when i attach any of my debuggers or use wpm.
Things i know at the moment:
These functions get overwritten to disable the possibility of attaching using a debugger all using jmps to ExitProcess:
Patching all of those makes it possible to attach a debugger.
If i use x64dbg it most of the time doesnt realize the prozess ends or has ended, which i think is pretty strange. Also im not sure if it is random when the process ends or not.
I would love to know if somebody has any idea how to approach this problem. Not being able to use a debugger makes it pretty hard to guess what is actually going on.
Guess you have to stop them shits from getting patched or unpatch them by writing the original bytes
Hey thanks for your answer. Im doing that already and that is the problem. After removing all of those it is goes this way.:
I attach a dbg .
Game crashes/Ends (after some time. I have most of the time enough time to get into a local game and jump around for a minute or two).
Debugger just sits there.
Here is my sloppy source in cs https://github.com/Nexusphobiker/CoD...ble/Program.cs
The code seems to work fine. At that point im relatively sure that the game checks those functions if they are still patched and closes the game if not. I also read somewhere about a THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER flag which hides threads from the debugger. It would make sense to me if those threads would be the root of the problem because setting breakpoints seems to be inconsistent. The only issue with that is that starting the game with a debugger attached creates mem access errors. I think you also mentioned that in your cod ww2 dbvm video if i remember correctly.
Edit: Can you check something if it shows up like that for you too? When using x64dbg and ScyllaHide and you Suspend the process before the hooks are written: set an access breakpoint on CopyFileExW. It should trigger after some time and give as source around here "s2_mp64_ship.exe"+1E8C3. If it does please let me know. Also this seems to patch the functions "s2_mp64_ship.exe"+1E6ABC
Last edited by SpieleHacksInfo; 11-07-2017 at 07:32 AM.
I don't have the game, I only tried the beta. Sounds like you have lots of reversing to do
Just in case anyone finds this thread. Trying to do the same i did:
Multiple problems arise.
1. Detection of your tools. If you use tools which are pretty much know like IDA,WinDBG,Cheat Engine,x64dbg the process scans for those and closes in response if those are running.
2. Detection of local memory patches. If you patch out the Anti Debug measure like i did the process will behave the same and close after x minutes/seconds.
3. Usage of dynamic jmps. You will probably see pretty fast that if the program doesnt expect to get back to its original address it will simply clear the stack and jmp to i.e. TerminateProcess This makes debugging pretty time consuming. So looking at the stack wont help you much here.
Im giving up at this point because it is too time consuming. In case you just want to wpm/rpm you can just write your own application to scan the process because those are not getting detected in general.
Ouch! no thank you
Originally Posted by SpieleHacksInfo