1

I wonder how is that possible.

I found debugger detection in TLS Callback function - there is conditional jump after some check.

When I step over it with debugger and modify ZF flag to bypass detection everything works fine. But when I try to patch this jump to the opposite (jne to je) application freezes and bombards me with OutputDebugString.

I don't save patch to the file, I patch it while process is in memory.

I was interested how this patch is detected, so I set Hardware Access Breakpoints on bytes that I patched, and then run it. Breakpoints weren't hit, and yet application changed it behavior just like it always do when I patch.

Notice that difference in code flow have nothing to do with this detection since when I modify ZF flag application works fine.

So I am very baffled, how does this application detects that patch, when it doesn't apparently access memory that I patched? Or is Hardware Access Breakpoint imperfect? I am interested in general ideas, how would you go about detecting whether your code was patched or not, without hitting hardware breakpoints.

Improve this question
2
  • 1
    My first idea would be that your program uses ReadProcessMemory to access its own address space, and the hardware breakpoint is inactive while the system is in kernel mode.
    – Guntram Blohm
    Jul 28, 2016 at 15:05
  • it might acquire the context, erase the breakpoints, and then perform the scan. if you set hardware breakpoints in other places that are known to be reached, are they hit? if not, then that's what is happening.
    – peter ferrie
    Jul 29, 2016 at 16:05

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.