Is it possible to find Memory Breakpoints from within the debugged executable? (as an anti debugging technique?). And no, i do not mean Hardware Breakpoints from the Dr0 - Dr7 registers NOR INT3 \ code breakpoints.. Breakpoints like in OllyDBG when you right click a memory address and put a breakpoint on access.

What ways exist to find such breakpoints? How can i avoid detection?

3 Answers 3


You could query the page level attributes of the section you're trying to verify. If the attributes contain unexpected values (e.g. PAGE_NOACCESS), chances are that someone messed with your pages (possibly a debugger setting a memory breakpoint).

  • Can u give me real life examples of how its done? Are there any alternatives to VirtualProtectEx and VirtualQueryEx?
    – 0xAK
    Commented Mar 25, 2015 at 11:45
  • The only alternative I can think of would be NtQueryVirtualMemory.
    – newgre
    Commented Mar 25, 2015 at 12:53

This is covered in-depth in this blog post: http://waleedassar.blogspot.com/2012/11/defeating-memory-breakpoints.html

... This trick can easily detect memory breakpoints. It relies on the fact that the "ReadProcessMemory" function returns false if you try to read guarded or no-access memory. To use this trick, all you have to do is call the "ReadProcessMemory" function with the "Handle" parameter set to 0xFFFFFFFF, the "lpBaseAddress" parameter set to the image base, and the "nSize" parameter set to the size of image. If it returns false, then at least one memory breakpoint is present.

As for your other question -- "How can i avoid detection?" -- that is answered here: https://reverseengineering.stackexchange.com/a/8510/1562

You can't know how to avoid getting detected if you don't know how the detection works. I'd recommend finding and reverse engineering the detection logic so that you can either disable it (patch it out) or better understand how to avoid detection.


AFAIK this is possible, just read your own memory and look for 0xCC bytes. However this poses a problem since several compilers insert 0xCC bytes between functions (as kind of a trap in case of memory overwrite, I guess)

INT3 padding between functions shown in IDA

So, you would have to do is to know how many of those "innocent" INT3 was there before and check for anomalies. Sounds like prone to failure, IMHO :)

SPOILER: IIRC, this was one of the anti-RE mechanisms in the last Flare Challenge.

  • I did not mean Code breakpoints (INT3) i meant Memory breakpoints.. Like changing the Page Protection attributes with VirtualProtect or other api.. to PAGE_GUARD etc
    – 0xAK
    Commented Mar 25, 2015 at 10:09

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.