2

I'm having an issue when trying to patch an application. If I open the .exe application with x64dbg, it first goes through ntdll.dll and then runs the application module. It works fine as long as I don't "touch" the application module code. As soon as I apply any kind of patch, even something as simple as adding a "nop" instruction, I can no longer run the application (it terminates immediately).

When I try to debug, I notice that the execution doesn't even reach the application and stays within the ntdll.dll module. It loops 14 times between these 3 lines and the program terminates on the call to NtContinue (aka ZwContinue):

00007FFA616C2FCE | B2 01       | mov dl,1
00007FFA616C2FD0 | 48:8BCB     | mov rcx,rbx
00007FFA616C2FD3 | E8 28770200 | call <ntdll.NtContinue>

I've read that some anti-attach methods leverage the NtContinue function but in my case it's not really an attachment problem since I can debug without any issue until I patch the application. If anything it is rather an anti-patching trick...

I was wondering if this was something known already, or if you had any leads that I could try to solve this issue. I have already tried installing the "ScyllaHide" plugin and ticked the option "NtContinue" but it doesn't change the behavior. Maybe there is another anti-anti-debug plugin I could use?

0xC0000022L
  • 10,908
  • 9
  • 41
  • 79
Reverto
  • 21
  • 3
  • Thank you for your reply. I had checked this post before but I'm not 100% sure it's exactly the same because in my case the issue occurs only when I patch the file. – Reverto Jul 09 '18 at 19:23
  • Also I have to admit that I don't fully understand what is being said, as I am still in a beginner in the field (no idea what "clearing the trap flag" means...). I am first trying to understand what is causing the application process to terminate only when it is modified, then I can try to find a solution, but I'm already stuck in the understanding of the origin of the issue. For example, is there some kind of hash of the .exe file that is check when running the application? Is it a timestamp issue or anything else... – Reverto Jul 09 '18 at 19:23
  • I don't mean for you to give me all the answers, I just need a few pointers because I'm quite stuck at the moment :-)

    Thanks!

     – Reverto Jul 09 '18 at 19:24
  • I've been looking a bit on the web for hash based protections of processes and I found an interesting paper: https://www.researchgate.net/publication/221427476_Dymo_Tracking_Dynamic_Code_Identity

    Although this is about checking the run-time integrity of a process, which is not really my case since I can patch at run-time, it contains interesting part about how ntdll is involved in the "identity label" (aka "hash) check.

    Ever heard about this technique?

     – Reverto Jul 10 '18 at 07:43
  • Never mind, after a bit of digging, I realized that the application code was actually run but there is a logic that is both trying to prevent debugging and patching by killing the process when specific conditions are gathered. My guess is that the NtContinue is actually called by the application to terminate the process. So this probably has nothing to do with the topic How to bypass ZwContinue?. – Reverto Jul 10 '18 at 13:19

0 Answers0