Anti-disassembly

From Unprotect Project
Jump to: navigation, search

Technique Description

Malware often use anti-disassembly techniques to avoid reverse engineering. Anti-disassembly uses specially crafted code or data in a program to cause disassembly analysis tools to produce an incorrect program listing. This technique is crafted by malware authors manually, with a separate tool in the build and deployment process or interwoven into their malware’s source code.

Techniques

Below is a list of all the anti-disassembly techniques in Unprotect Project:

Anti Disassembly Techniques
Techniques Description
API obfuscation API obfuscation is a technique use by malware to avoid analysis. Once reversed, the disassembler tool has the capabilities to print the API. If API obfuscation is used a CALL without the name of the function will be printed into the disassembler tool.
Control flow graph flattening The Control Flow Graph flattening of a program consists in flattening the control flow of each function by first breaking up the nesting of loops and if-statements, and then hiding each of them in a case of a large switch statement, that is wrapped inside the body of a loop.
Inserting junk code Junk code can be inserted without modification to the original code, the junk code will not affect the program but will add instruction into it. The result will be a huge amount of junk instruction into the disassembler that will add a difficulty during analysis.
Spaghetti code Similar to junk code, the spaghetti code will draw an instruction flow that looks like to spaghetti.
Obscuring flow control Function pointer problem Pointers are a common programming idiom use by C and C++. This functionality can be an issue for the disassembler if a huge amount of pointer is used into the code. The result can be difficult without dynamic analysis.
Adding missing cross-ref A cross-reference is used to find that one function can be called several time.
Return pointer abuse A RETN instruction is normally use to return from a function call. But if the RETN instruction is used for another purpose the disassembler will prematurely terminate the function.
Misusing SEH The Structure Exception Handling (SEH) provides a method of flow control that is unable to be followed by disassemblers and will fool debuggers.
Impossible disassembly By using a data byte placed strategically after a conditional jump instruction, with the idea that disassembly starting at this byte will prevent the real instruction that follows from being disassembled because the byte that inserted is the opcode for a multibyte instruction.
Jump instruction with same target This technique is a back-to- back conditional jump instructions that both point to the same target. If a jz loc_512 is followed by jnz loc_512, the location loc_512 will always be jumped to. The combination of jz with jnz is, in effect, an unconditional jmp, but the disassembler doesn’t recognize it as such because it only disassembles one instruction at a time.
Opcode obfuscation An opcode is a machine language instruction that specifies the operation to be performed. Some of this instruction can be obfuscated by a malware in order to dissimulate the real behaviour.
Dynamically computed target address In some case the resolved target address can be uninitialised. This may happen if the snapshot is taken at a point during the execution when the resolution of the API has not taken place in the malware code.
Disassembly desynchronization This technique involves the creative use of instructions and data to prevent the disassembly from finding the correct starting address for one or more instructions.

References

https://collaborate.mitre.org/maec/index.php/Subcapability:5
https://collaborate.mitre.org/maec/index.php/Behavior:25
http://staff.ustc.edu.cn/~bjhua/courses/security/2014/readings/anti-disas.pdf