On March 27, I gave a presentation at Black Hat Asia 2015 in Singapore. My session highlighted possible ways to create user-mode rootkits by taking advantage of Android’s new runtime, based on publicly disclosed Android OS code and not leveraging vulnerabilities.

Standard Attacks

First, let’s talk about a typical attack scenario. An attacker will first attempt to gain access to the device by exploiting a vulnerability or by tricking the user into installing malware. If successful, the attacker would have gained access with the privilege of the exploited program or of a normal app in the case of a malware install. While this is often enough to conduct some malicious operations, a higher privilege will enable the attacker to do more. The attacker would have to use another exploit to elevate his or her privileges, with gaining root privileges as the ultimate goal. However, this root access (soft root) is not persistent and will be lost when the device is rebooted. To overcome this, the final step is to make sure the attacker maintains root access even after a reboot and can hide his or her traces. This is typically achieved by installing a rootkit. It is in this stage of the attack where this research comes in.

One of the main motivations for this research is to determine whether an attacker who wants to install a rootkit can do so without having to deal with the complications brought on by some recent advancements in Android security, specifically a feature called dm-verity. First introduced in KitKat, this feature allows the kernel to verify the integrity of a partition upon a boot, thus ensuring this partition has not been tampered with. It protects the device from rootkits that add or modify binaries in the system partition to hide other malicious files and processes and maintain access.

While dm-verity is not yet a default feature, it’s always good to know early on what an attacker can do in spite of the protections in place. As a team, we needed to see whether it was possible to conduct rootkit operations without touching the system partition, thus avoiding the protection offered by dm-verity. To answer these questions, we turned to another technology that has been recently introduced in Android: the new Android Runtime (ART).

The Android Runtime

ART was first introduced in Android Kitkat 4.4 in October 2013 as an experimental alternative to the Dalvik runtime. Upon the release of Android Lollipop 5.0 in November 2014, ART became the default runtime. The main advantage of ART over Dalvik is better app performance due to ahead-of-time compilation. While Dalvik relied on interpretation and just-in-time compilation, ART precompiles app Dalvik bytecode into native code.

The command responsible for compiling an application into OAT is dex2oat, which can be found in /system/bindex2oat. This ahead-of-time compilation will result in an OAT file that is generated in the /data/dalvik-cache// directory, where arch is the name of the device’s central processing unit architecture (e.g., “arm” for ARM, “x86” for Intel x86, etc.).

All apps will be compiled every time the device’s system is upgraded or the first time it is booted up after it is purchased. During this time, ART will also compile all the code from the Android framework jars into a single OAT file named boot.oat. This boot.oat file is referenced by an app whenever the app calls a framework application programming interface (API) method. Individual apps are compiled upon installation and upon subsequent updates.

Code Modification

The approach I took was to take advantage of the mechanisms of ART to modify the framework or application code with code of our own without touching the system partition. We can use dex2oat to generate OAT files from modified versions of installed apps or system frameworks and replace the original OAT files with them. Note that we need at least a root shell access (soft root) to do this. We have the two following options:

  1. Generate a new boot.oat that contains our code modifications and replace the installed boot.oat with it. This affects all the apps calling the framework API method that we modified.
  2. Generate a new OAT file for a specific installed application that contains our code modification, and replace the installed OAT file.

There are several advantages to this approach. One is that we don’t have to deal with low-level code. All our modifications are done in Java and only run in the user mode, so there will be fewer potential problems to be encountered compared to code that deals with low-level kernel stuff. This approach is also affected less by variations in architecture and OS versions since we rely on ART itself, specifically the dex2oat tool, to generate our code. Last, with this approach, we don’t have to deal with code signing since the applications were already installed and verified. All we do is modify the app’s code that is now outside the application’s package.

Our code also runs under the context of the affected app. This means our code will have the same user ID and app permissions as the app running our code. For instance, if we use the app OAT-replacing technique and replaced the OAT for the Settings app, our code will run in the context of the system user, along with the app permissions of the Settings app.

How about persistence? As long as our modified OAT file is in use, our modification will stay in effect. The OAT files will only be replaced after an OTA update or app update. Upon the OS update, boot.art and boot.oat will have to be regenerated and all the app OAT files will have to be recompiled, as well; likewise, it must be recompiled when an app is updated. Keep in mind that our goal is not to maintain root access, since we are trying to avoid writing to /system in the first place. We do not have the option to re-exploit the device using a system-to-root exploit while our code is running as system UID.


Using these techniques, we can create user-mode rootkits that hide malicious apps and processes that we have installed on an Android app running on Lollipop. We can do this without modifying any of the files in the system partition. Again, no vulnerabilities were used, and these techniques assume the attacker already has root access. In other words, a malicious Android app cannot use this approach without elevating its privileges through a vulnerability or social engineering. If you want more details about this research, check out this white paper and the slides from the Black Hat website.

Image Source: Flickr

More from Endpoint

The Needs of a Modernized SOC for Hybrid Cloud

5 min read - Cybersecurity has made a lot of progress over the last ten years. Improved standards (e.g., MITRE), threat intelligence, processes and technology have significantly helped improve visibility, automate information gathering (SOAR) and many manual tasks. Additionally, new analytics (UEBA/SIEM) and endpoint (EDR) technologies can detect and often stop entire classes of threats. Now we are seeing the emergence of technologies such as attack surface management (ASM), which are starting to help organisations get more proactive and focus their efforts for maximum…

5 min read

X-Force Identifies Vulnerability in IoT Platform

4 min read - The last decade has seen an explosion of IoT devices across a multitude of industries. With that rise has come the need for centralized systems to perform data collection and device management, commonly called IoT Platforms. One such platform, ThingsBoard, was the recent subject of research by IBM Security X-Force. While there has been a lot of discussion around the security of IoT devices themselves, there is far less conversation around the security of the platforms these devices connect with.…

4 min read

X-Force Prevents Zero Day from Going Anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

8 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read