RESEARCH
/2019/Bare-metal android malware behavior analysis framework
A scalable dynamic malware analysis framework focused on capturing unified behavior profiles of Android applications by analyzing them on physical devices in real-time.
PUBLISHED:ICACT 2019
KEYWORDS:
+8
Android malware analysis is an arms race. As #android #malware detection and analysis systems improve, malware authors fold the same advances back into their evasion playbook. A modern sample can fingerprint a virtualized environment or notice that its own functions have been instrumented, and once it does, it simply withholds the behavior we are trying to observe. Analysis that leans on emulators and user-level hooks never gets to see what the sample actually does.
This paper covers TRAPDROID, the framework I built as the primary published output of my master's thesis. TRAPDROID is a scalable #dynamic-analysis system that runs a target application in real time on physical, #bare-metal devices instead of an emulator. It watches the sample through system calls, #binder communications, hardware performance counters (#PMU), and process statistics, then folds those raw kernel-level interactions into a single, compact behavior profile.
The Framework
TRAPDROID moves analysis out of an easily detected user-level sandbox and onto real hardware. It has three parts that hand work down a pipeline: the driver, the agent, and the server.
- •Driver (kernel level): A loadable kernel module (#LKM) intercepts 29 important system calls and filters
ioctlcalls on/dev/binderto capture 14 binder transactions. It also collects PMU events and task structures. - •Agent (user level): The driver pushes raw events into a circular queue. The agent pulls them from a custom character device (
/dev/trapdroid), pre-processes them to cut down on traffic, and ships them to a remote server. - •Backend Server: The server feeds the events into the analysis engine, where logs are mapped into a unified behavior profile (for example,
openandopenatcollapse into a singleOpenFilebehavior) and scored with #machine-learning to judge malicious intent.
Here is the event flow of the protocol:
Loading diagram...
To give every sample a clean slate, the framework keeps a "vault" partition with a pristine system state and reflashes partitions over ADB during the restoration phase between runs.
Feasibility and Performance
I deployed TRAPDROID on a physical Sony Xperia Z3 Compact running Android 5.1.1 and ran it against real-world malware.
- •Accuracy: Encoding the unified profiles as TF-IDF vectors and classifying them with an SVM, the system reached 93.4% accuracy on a dataset of 281 malware and 355 benign applications.
- •Bare-metal advantage: I ran 5 evasive samples (from the Ztorg, OBAD, and Hehe families) on both an emulator and TRAPDROID. On the emulator, 4 of the 5 detected the environment and terminated or crashed on launch. On bare metal, all 5 ran to completion and exposed their full malicious activity.
- •Advanced threats: To stress the system, I wrote two proof-of-concept threats and checked whether TRAPDROID could follow them. The framework caught both by the traces they left behind: irregular CPU time (
stimeversusutime) and thread activity firing while the screen was off.- •ArmageddonApp ran cache-based side-channel attacks against device libraries.
- •Zpware exfiltrated sensitive user data through a covert channel (browser Intents), without ever requesting the internet permission.
- •
The takeaway is straightforward. Against samples built to detect and dodge instrumentation, running them on real hardware is the only reliable way to observe what they actually do. TRAPDROID closes the gap between low-level kernel events and high-level behavior, and it does so without ever tipping off the malware that it is being watched.