Small footprint inspection techniques for Android presented at Chaos Communication Congress 29

by Damien Cauquil, Pierre Jaury,

Summary : The lecture would address topics related to reverse engineering for mobile platforms, especially from the Android point of view. The main aspects of the presentation is a new approach to reverse engineering side effects problem: some low footprint inspection techniques that grant analysts with the ability to access the program memory without altering its behavior. One technique is presented in particular - Android service injection - and is demonstrated.
REVERSE ENGINEERING AND MOTIVATIONS
With mobile devices getting more complex everyday, users tend to store huge amounts of data and access so many services on potentially insecure networks and systems that mobile security is one of the main concerns faced by development companies and IT security experts nowadays.
Meanwhile, both for security reasons and intellectual property protection, developers are provided with a panel of optimization and obfuscation tools that is getting powerful and fairly easy to include in any release process. Reverse engineering binary packages has become a full time job for security consultants, who are lacking some tools when dealing with very specific issues.
In order to completely understand motivations for small footprint inspection techniques, one first has to compare reverse engineering with physics. Reverse engineering *is* the physics of computers: experts are collecting facts and observing behaviors to establish laws and analyze system internals that could no be observed directly. Those same experts are facing numerous experimental issues, especially when studying programs specifically designed against reverse engineering techniques. One of them is very common to physics and computers: experimental and measure uncertainty.
When performing any run-time dynamic analysis, reverse engineers modify the application behavior by altering its environment: debugging meta-data, run-time breakpoints, virtual machine overlay, physical device emulator and even network traffic interception may end up in a complete different response from the target application. Studying the program necessarily involves a bias; developers and specific anti-debugging tools exploit this bias to slow down reverse engineers or lead them to wrong conclusions.
Current tools available for the Android mobile platform usually have many side effects: their footprint is so big that dynamic analysis of mobile applications is sometimes impossible. This observation motivated various research projects for dynamic analysis mostly inspection techniques involving a minimal footprint.
SMALL FOOTPRINT INSPECTION
ANDROID INSPECTION STATE OF THE ART
Many tools are available for memory and execution path inspection of Android applications. The most common one is DDMS (Dalvik Debug Monitor Server), it is perfectly integrated with development environments like Eclipse and allows developers and auditors to place breakpoints, inspect both local and global variables. Yet the application has to be launched in debug mode (if not built with the debug flag).
One of the latest tools released is APKIL. It provides auditors with a complete Dalvik byte-code patching system that is able to inject monitoring instructions into application packages. Its main purpose is the inspection of Android API calls, which as any system call are usually perfectly relevant for analyzing internal mechanisms. It is still easily beaten by loading remote code at run-time or by spoofing usual API calls.
SERVICE INJECTION
The techniques we used to circumvent annoying side effects and anti-debugging protections are based on a very simple principle that malware developer already have widely explored: Android applications are built upon a modular architecture, declaring possibly unrelated activities, services, etc. Thus, injecting code into an application package does not necessarily mean altering the existing Dalvik byte-code.
We tried and exploited many injection vectors, from supposed static resources to fully equipped services, and ended up dropping a service that remains completely silent until it is enabled and queried by a client application.
The injected piece of code communicates using standard service calls as a covert channel in order to grant users the ability to inspect the application memory from the inside and execute any Dalvik instruction in the same process and virtual machine as the target application. It is also able to load dynamic classes at run-time in a very similar fashion as Meterpreter in order to extend its functionality while keeping a minimal space footprint.
INTROSPECTION API AND EXAMPLES
The tool we eventually developed exposes a simple service API that may be proxified over the network and integrated in the same fashion as DDMS plugins.
It is able to perform complete activities and running services introspection, variables modification and remote method invocation as well as downloading and invoking user-defined Java/Dalvik macros at run-time.
It will be released together with example client applications.