Next, we jump to our page, and if we're under a debugger, specifically OllyDBG, then we will hit the RET instruction and return to the address we pushed onto the stack before we jumped to our page. We then mark the page as a guard page and push a potential return address onto the stack. In essence, what occurs is that we allocate a dynamic buffer and write a RET to the buffer. However, we can use the techniques a debugger uses to implement memory breakpoints to discover if our program is currently running under a debugger.
At the moment, there's no accurate way to check for memory breakpoints. In a nutshell, when a page of memory is marked as PAGE_GUARD and is accessed, a STATUS_GUARD_PAGE_VIOLATION exception is raised, which can then be handled by the current program. Memory breakpoints are implemented by a debugger using guard pages, and they act like "a one-shot alarm for memory page access" ( Creating Guard Pages). Unsigned char *pTmp = ( unsigned char*)pMemory įor ( size_t i = 0 i < SizeToCheck i++) However, we should be careful because using this method of scanning can lead to false positives.īool CheckForCCBreakpointXor55( void* pMemory, size_t SizeToCheck) Detecting this type of breakpoint is relatively simple, and some source would look like the following sample. This is the most common expression of this type of breakpoint however, it can also be expressed as the byte sequence 0xCD 0x03 which can cause some troubles. INT 3h breakpoints are represented in in the IA-32 instruction set with the opcode CC (0xCC). The first example will cover the most common type of breakpoint which utilizes the INT 3h instruction. This is why breakpoint checks are done over important APIs like MessageBox, VirtualAlloc, CreateDialog, and others that play an important role in the protecting user information process. In fact, this is probably the most utilized technique in cracking, the only competition would be a referenced text string search.
#Ida hide debugger windows#
By utilizing this, reverse engineers can put breakpoints in areas like Windows APIs, and can very easily find where a badboy message (a messagebox saying you entered a bad serial, for example) is coming from. Breakpoints allow for the stopping of execution of a program at any point where one is placed. Breakpoints are essential to a reverse engineer, and without them, live analysis of a module does him or her little good. There are three types of breakpoints available to a reverse engineer: hardware, memory, and INT 3h breakpoints. When in-lining, this doesn't happen, and the engineer is left guessing as to what is actually happening. Now, he or she knows exactly what is happening when that function is called. If there are very detailed function entries and sections, then the job for the reverse engineer just got much easier. While this can cause bloat inside an executable, it is important in anti-reverse engineering. I didn't feel this side note required its own section however, when reading this article or the attached source, one will notice the functions being marked inline. BackgroundĪnyone who is interested in the field of reverse engineering needs a strong understanding of Assembly language, so if your ASM is a little rusty or if you're just beginning to learn, here are some sites that can assist: I'm presenting these methods here to share the knowledge, and perhaps inspire others to find ways to apply these methods and utilize them in new and creative ways that challenge contemporary methodology. Most of the techniques here can easily be bypassed, and some of the others aren't as easily taken out of the picture however, all of them can in one way, shape, or form be bypassed. This is the driving force behind the cracking "scene" and anti-reverse engineering fields.
Every time the protectors release a new technique, the engineers find a way around that specific method. Some comments in my previous article noted that the techniques I presented could, and are most of the time, easily bypassed by intermediate level reversers one statement I would like to make is that there is an ongoing battle between the coders who develop programs that protect against cracking and reverse engineering and the engineers themselves. In this article, I plan to travel a bit deeper into the interesting world of reverse engineering and explore some more intermediate level techniques for annoying reverse engineers. In my previous article, I gave a short introduction into some Anti-Debugging/Debugger Detection techniques that primarily involved the use of Win32 API functions.
0 kommentar(er)
