Unpacking the Packed Unpacker: Reverse Engineering an Android Anti-Analysis Native Library

The presentation discusses the current state of the art in Android anti-analysis techniques and how to overcome them.

• Malware developers are willing to sacrifice market share to avoid detection
• Anti-analysis techniques include encryption, anti-reverse engineering, and runtime environment checks
• The malware will not run if it detects an emulator or debugger
• The malware checks for specific system properties and architecture before running
• Regex can be used to get around hard-coded addresses and registers

The speaker spent several days unpacking a packed unpacker and discovered the malware's sophisticated anti-analysis techniques. The malware developers were willing to miss out on potential targets if it meant avoiding detection. The malware used encryption, anti-reverse engineering, and runtime environment checks to prevent analysis. The speaker also used regex to get around hard-coded addresses and registers.

Malware authors implement many different techniques to frustrate analysis and make reverse engineering malware more difficult. Many of these anti-analysis and anti-reverse engineering techniques attempt to send a reverse engineer down an incorrect investigation path or require them to invest large amounts of time reversing simple code. This talk analyzes one of the most robust anti-analysis native libraries we've seen in the Android ecosystem. I will discuss each of the techniques the malware author used in order to prevent reverse engineering of their Android native library including manipulating the Java Native Interface, encryption, run-time environment checks, and more. This talk discusses not only the techniques the malware author implemented to prevent analysis, but also the steps and process for a reverse engineer to proceed through the anti-analysis traps. This talk will give you the tools to expose what Android malware authors are trying to hide.