Finding memory breakpoints from debugged executable

Question

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?

Answer 1

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).

Answer 2

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.

Answer 3

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)

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.