I have been nagged a lot regarding guest posts, and almost 90% of them are related to some news, social media bullshit and half baked security crescendo. Until recently, I was contacted by amiable folks at
Infosec Institute with a good article on
Anti Debugging. This is an article by
Dejan Lukan, a security researcher at
Infosec Institute, in which
he discusses the
Anti Debugging techniques in an objective and direct manner. I loved the implementation part, reminded me of my rev days (you can learn about
how to reverse Winrar or just have a look at
a real noobs guide to reverse some more stuff) , and more importantly Dejan explains how to stop (read : slow down) people from reversing your code. Hope you will enjoy it.
Before we begin, we must mention that it's impossible to completely prevent reversing. What is possible is that we can place as many obstacles on the way as we want to make the process slow enough that reverse engineers will give up. Actually there are hardware implementations where you can buy a black box that attaches to your computer which can do the encryption/decryption for you, but this is far from being used in everyday life. Techniques to Harden Reverse Engineering
The most basic approaches to harden the reverse engineering of programs are the following [1]:
- Eliminating Symbolic Information
- Obfuscating the Program
- Embedding Antidebugger Code
When eliminating symbolic information, we're taking the textual information from the program, which means we're striping all symbolic information from the program executable. In bytecode programs, the executable often contains large amounts of internal symbolic information such as class names, class member names, the names of instantiated global objects. By removing every symbol from the executable or by renaming every symbol, the reverser is faced with a bigger problem than usual because symbol names alone can often be used to gather enough information about what the function does, which simplifies the reverse engineering part. This can easily be done in C/C++ programs where we only have to append a few compiler flags to the command line that actually compiles the program into the executable. It's much harder with programming languages like Java and .NET, where those symbols are used internally to reference variables, functions, etc. This is also the reason why Java and .NET programs can easily be converted into a pretty good source code of the original program. We can still strip the symbols from such programs by renaming all the symbols from their meaningful names into meaningless representations, which effectively does the job.
Besides stripping the executable symbols, we can also obfuscate the program. When obfuscating a program, we're basically changing the code of the program without actually changing the logic behind it, so the program does the same as before but its code is far less readable. Here we have two techniques that can achieve that:
- Encoding: With encoding, we must add the decoding instructions that decode the whole program before it's being run. This can be done by appending the decoding instruction at the end of the program and changing the entry point to point to the decoding instructions. When the program is run, the decoding instructions are executed first, which decodes the whole program into its original form. After that, we must jump to the start of the program and actually run the original instructions as if the encoding didn't even happen.
- Packing: When packing the executable, we're basically reducing the size of the executable as well as encrypting it. When such a program is run, it must first be decoded in memory and then run.
- By obfuscating the program with nonstandard encoders/packers, we can greatly complicate the task of reverse engineering the executable, but at the end, a persistent reverse engineer will nevertheless be able to bypass that and get the non-obfuscated version of the executable, which can easily be reversed.
More Recent Articles
0 comments:
Post a Comment