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.

Improve this question
5
  • 1
    Memory breakpoints in Ollydbg can be bypassed
    – 0xec
    Aug 26, 2014 at 3:04
  • Try using a newer version of Olly or x64dbg.
    – 0xec
    Aug 26, 2014 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, 2014 at 5:30
  • The executable is heavily protected, only ollydbg has the plugins I need to run it correctly.
    – farmdve
    Aug 26, 2014 at 16:08
  • Try using some anti-debug plugins for Olly. -> ScyllaHide
    – 0xec
    Aug 27, 2014 at 3:08

1 Answer 1

Reset to default
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().

Improve this answer
6
  • 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, 2014 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, 2014 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 4, 2014 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, 2014 at 18:12
  • break on, not break
    – zetavolt
    Sep 8, 2014 at 8:15

Your Answer

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

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