Skip to content

Latest commit

 

History

History
45 lines (40 loc) · 5.1 KB

File metadata and controls

45 lines (40 loc) · 5.1 KB

<- .anti-analysis ->

Reversing Is Easy?

  • Aside from that a compiler will bloat up the size of the compiled code, reverse engineering for the purpose of understanding how a program works is really not a hard task. Even though x86 instruction set is enormous and source to assembly is a one-to-many relationship, a compiler will usually prefer only a subset of the x86 instruction set to translate the source code to. It might take longer to understand the disassembly, but after reversing for a while, you will start to notice the same assembly patterns and idioms over and over again. Getting used to those idioms and common assembly constructs for high-level languages (e.g. for loop, if statement, function call) help you decipher the purpose of a group of instructions quicker. Eventually, you will be able to understand on a high level what portion of the disassembly is doing what. Once you reach this state, the program is yours.

Not So Fast...

  • Obviously there are people that don't want their programs to be analyzed. When that is the case, they will use various techniques to hinder reversing of their software. The well-known anti-analysis techniques can be seen below but there are also many more undocumented or less-known ones. The good news is: no matter how hard one tried to obfuscate a program, there is no guarantee that it cannot be de-obfuscated. It is only a matter of time before a protected program is taken apart. Furthermore, unless the program is a crackme or a reversing challenge, one can't simply try to make the program as hard to reverse as possible since program performance also needs to be taken into consideration. Depending on the anti-analysis techniques and on what portion of the code is hardened, the performance difference could be fairly noticeably.

section overview



further readings


.file-formats <- RERM -> .encodings