-
Notifications
You must be signed in to change notification settings - Fork 25
Home
This project is developed under the GSoC program and with the supervision of the Honeynet project.
ARTDroid: Simple and easy to use library to intercept virtual-method calls under the Android ART runtime.
ART is the new Android application runtime. It is based on Ahead-of-time compilation instead of Just-in-Time used by Dalvik Virtual Machine. From the Android version 4.4.4 users can switch to ART runtime, from the lollipop version it is the default runtime.
Android applications running on ART are compiled into native code at the installation time. "dex2oat" binary is used to convert the DEX file into an OAT file (the new file format used by ART). The new OAT file is saved under the dalvik-cache directory and it will be loaded as a dynamic object.
This project aims to implement an old technique (vtable hijacking) against ART. ART vtable's pointers hijacking permits to divert any virtual-methods calls to our code (patch method).
ARTDroid doesn't require both Application's code and Android system's code modifications and supports both Android emulator and physical devices. It requires only the root privilege.
ARTDroid uses ADBI project by Collin Mulliner, included as git-submodule.
Ok, but why only virtual-methods? Hey, this is the first release. The best is incoming ;)
All the info you need to know to run ARTDroid are described in the getting started page.
ARTDroid is composed by two sides, the native component written in C and the patch code written in Java.
The native component, called "libarthook", is the static library which implement the hooking functionality, while the Java component is used to define the patch methods. It permits to the user to add new patch methods using the Java language.
The library provides the hooking functionality, it is compiled as a static library (libarthook.a). You need to link to it and compile your code as a shared library. The shared library must be injected inside the target process using the "hijack" tool.
Inside the "examples/arthook_demo" directory there is a demo to show how the library works.
In order to divert a virtual-method call, we need to define (address of) the alternative method to call (the patch method). The library allows to write patch methods using the Java language, it will be loaded (using a DexClassLoader) at runtime as a DEX file.
To find the vtable which contains the target virtual method to hook we use the following approach:
- use "FindClass" JNI method to find the target class memory reference
- use "GetMethodID" JNI method to find the target method memory reference (mid)
- get the pointer to the vtable using a relative offset from the address of step 1
- get the vtable length value using a relative offset from the address of step 1
- scan the vtable (using the length as bound) to find the target mid (from step 2)
- change the pointer founded at step 5 with the pointer to our patch method
All the relative offsets above are got from AOSP ART implementation.
use library page explains how to add new hooks into the native component
At the following page you can find more technical information about how the vtable is used by the ART runtime.
Users can write their own patch methods to define the code to be executed when a call to the target method is trapped.
Please refer to the patch code page.
please, first read getting started page!
The following are easy to follow step-by-step instructions for howto run the demo.
There is an example DEX file ("examples/classes.dex") included in the library, it defines three patch methods for the "getDeviceID" , "openFileOutput", "sendTextMessage" API's methods. This demo logs call's arguments to logcat and modify the "getDeviceID" method's return value adding a static String ("w00t").
There is an "one-script" to automate the demo execution. please, start adb as root and type the following commands into a terminal (on the host)
cd scripts
bash rundemo.sh
The "rundemo.sh" script compiles the project to produce the shared library, push the files to the device/emu and runs the test app injecting the hooking engine (.so) inside it.
The following are the steps executed by the above script. Obviously you can reproduce them by your hands instead of use the "one-script" :)
++ build all ++
Use "install.sh" script to automate the building of ADBI and ARTDroid. It builds the projects and push the files to the device/emu calling the script "pusher.sh"
cd scripts
bash install.sh
If you want to compile the project manually, please look at the build/clean scripts inside the root project dir.
++ push patch code ++
Use "push_patch_code.sh" script to push the patch methods to the device/emu. It takes a DEX or APK argument.
++ prepare envinronment ++
adb shell
cd /data/local/tmp
chmod 777 init.sh
sh init.sh #this must be runned only one time per device/emu
# GET PID and USER from target process
chown USER:USER dex/opt
if all the files are in the right place, the /data/local/tmp dir will look like the following:
root@serranoltexx:/data/local/tmp # ls -lR
.:
-rwxrwxrwx root root 72 2015-08-18 14:10 arm_arthook.log
-rwxrwxrwx root root 16431 2015-08-18 14:10 arthook.log
-rwxrwxrwx root root 2530532 2015-08-17 14:23 classes.dex
-rwxrwxrwx root root 83 2015-07-26 17:53 cleaner.sh
drwxrwxrwx root root 2015-08-18 13:12 dex
-rwxrwxrwx root root 21900 2015-08-18 13:54 hijack
-rwxrwxrwx root root 868 2015-08-18 13:17 init.sh
-rwxrwxrwx root root 46320 2015-08-18 14:10 libarthookdemo.so
-rwxrwxrwx root root 1436 2015-08-18 13:19 runhijack.sh
./dex:
drwxrwxrwx USER USER 2015-08-18 13:20 opt
-rwxrwxrwx root root 2530532 2015-08-18 14:10 target.dex
For injecting the shared library into the target process using hijack tool, run the following script:
sh runhijack.sh -h
All examples are distributed with full source code.
I would like to thanks @marcograss and @emd3l and Cong Zheng my GSoC project mentor