Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- // READ MORE HERE: http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
- ### ------------------------------------------------------------------------------------------------ ###
- A look into what goes into the area of preventing reverse engineering, and gives developers some functions and ideas about preventing reversing engineering of their programs.
- ### ------------------------------------------------------------------------------------------------ ###
- [Table of Contents]
- ___________________
- Breakpoints
- Int 3
- Memory
- Hardware
- Timing Attacks
- RDTSC
- Win32 Timing APIs
- Windows Internals
- ProcessDebugFlags
- Debug Object Handle
- Thread Hiding
- BlockInput
- OutputDebugString
- Process Exploitation
- Open Process
- Parent Processes
- Self-Debugging
- UnhandledExceptionFilter
- NtQueryObject
- Anti-Dumping
- Nanomites
- Stolen Code (Stolen Bytes)
- SizeOfImage
- Virtual Machines
- Guard Pages
- Removing the PE Header
- IA-32 Instruction Exploits
- Interrupt 2D
- Stack Segment
- Instruction Prefixes
- OllyDBG Specific
- FindWindow
- OutputDebugString Exploit
- WinDBG Specific
- FindWindow
- Other Techniques
- Junk Code
- Native Code Permutations
- ### ------------------------------------------------------------------------------------------------ ###
- Introduction
- 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. 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. 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. Every time the protectors release a new technique, the engineers find a way around that specific method. This is the driving force behind the cracking "scene" and anti-reverse engineering fields. 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. 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.
- ### ------------------------------------------------------------------------------------------------ ###
- Background
- Anyone 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:
- ### ------------------------------------------------------------------------------------------------ ###
- Introduction to Assembly Language
- IA-32 Instruction Reference
- Iczelion's Win32 Assembly Homepage
- ### ------------------------------------------------------------------------------------------------ ###
- Inline Functions
- 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. While this can cause bloat inside an executable, it is important in anti-reverse engineering. If there are very detailed function entries and sections, then the job for the reverse engineer just got much easier. Now, he or she knows exactly what is happening when that function is called. When in-lining, this doesn't happen, and the engineer is left guessing as to what is actually happening.
- ### ------------------------------------------------------------------------------------------------ ###
- Breakpoints
- There are three types of breakpoints available to a reverse engineer: hardware, memory, and INT 3h breakpoints. Breakpoints are essential to a reverse engineer, and without them, live analysis of a module does him or her little good. Breakpoints allow for the stopping of execution of a program at any point where one is placed. 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. In fact, this is probably the most utilized technique in cracking, the only competition would be a referenced text string search. 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. The first example will cover the most common type of breakpoint which utilizes the INT 3h instruction.
- ### ------------------------------------------------------------------------------------------------ ###
- INT 3
- INT 3h breakpoints are represented in in the IA-32 instruction set with the opcode CC (0xCC). 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. Detecting this type of breakpoint is relatively simple, and some source would look like the following sample. However, we should be careful because using this method of scanning can lead to false positives.
- READ MORE HERE: http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
