5

I am currently battling this protection on an 32-bit executable.

At some point during it's runtime, the protection gets the address of DbgUiRemoteBreakin and writes a JMP to ExitProcess as an anti-attach technique. I decided to place a memory breakpoint on write(I also tried access) on that location figuring at the very least I'd find out what piece of code alters the code. Upon setting the breakpoint I hit F9 only for my memory bp to never be triggered, I tried multiple times. The code was altered, but my memory bp was not triggered. This is the first time that a memory breakpoint was not triggered for me. I am puzzled as to why this has happened. My only guess is that DbgUiRemoteBreakin is located in ntdll.dll and that is why guard pages don't work there. There were also instances where I had a crash when I set a memory bp on that function.

However I am hoping somebody has encountered this and can explain more in depth. My ollydbg version is 1.10.

0xec
  • 6,090
  • 3
  • 23
  • 33
farmdve
  • 181
  • 1
  • 7

1 Answers1

2

The most likely reason why your breakpoint didn't get hit is because the protected file removed it.

Edit: If the breakpoint was hardware-based, then the protected file can use GetThreadContext(), erase the DR entries, SetThreadContext(). If the breakpoint was page-protection-based, then the protected file can use VirtualProtect().

perror
  • 19,083
  • 29
  • 87
  • 150
peter ferrie
  • 4,709
  • 4
  • 19
  • 33
  • 1
    I am sorry, but you are incorrect. Memory breakpoints are not Hardware breakpoints. Only hardware breakpoints can be removed/changed via Set/GetThreadContext. – farmdve Aug 27 '14 at 22:19
  • @farmdve, if Olly used VirtualProtect() to guard the page, then the protected file simply used VirtualProtect() to make it writable, removing the guard protection as a side-effect. Try using the hardware break-on-write instead. If that doesn't work, then it's because the protected file removed it. – peter ferrie Aug 28 '14 at 17:22
  • The only problem with this theory is that subsequent VirtualProtect calls would break. In any case, testing this theory is much easier with the simple Ctrl-G for VirtualProtect / VirtualAlloc approach. – zetavolt Sep 04 '14 at 03:49
  • @zv_, why would subsequent VirtualProtect calls break? Anyway, I just confirmed my theory with a crafted file. It calls VirtualProtect() which removes OllyDbg's memory breakpoint. It behaves exactly like what farmdve is seeing. – peter ferrie Sep 05 '14 at 18:12
  • break on, not break – zetavolt Sep 08 '14 at 08:15
  • zv_, still not making any sense to me. OllyDbg calls VirtualProtect() to guard the page, and then resumes execution. The malware uses VirtualProtect() to make the page writable. The guard is removed by this action, so the exception never occurs on the write. The malware could even restore the guard afterwards if it wanted to. The breakpoint should be placed on the call to VirtualProtect() instead. Then the action would be obvious. – peter ferrie Sep 15 '14 at 04:24