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.

  • 1
  • Try using a newer version of Olly or x64dbg. – 0xec Aug 26 '14 at 3:11
  • As your executable is 32 Bit you can use the freeware version of IDA Pro. x64dbg is another good tool but still a work in progress and the disassembly is not even at Olly's standards. If you have a Mac or Linux machine you could also try Hopper disassembler; very user friendly and powerful. By the way, have you tried setting a hardware rather than software BP? – JamalS Aug 26 '14 at 5:30
  • The executable is heavily protected, only ollydbg has the plugins I need to run it correctly. – farmdve Aug 26 '14 at 16:08
  • Try using some anti-debug plugins for Olly. -> ScyllaHide – 0xec Aug 27 '14 at 3:08
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().

  • 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. – ŹV - Sep 4 '14 at 3: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 5 '14 at 18:12
  • break on, not break – ŹV - Sep 8 '14 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.