ARTDroid: A Virtual-Method Hooking Framework on Android ART Runtime Valerio Costamagna Cong Zheng Universit`adegli studi di Torino Palo Alto Networks [email protected] Georgia Institute of Technology [email protected] techniques can dynamically launch specific behaviors, which can be only monitored in dynamic analysis en- Abstract vironment instead of static analysis. Besides, in obfus- cated apps, static analysis can only check the API-level Various static and dynamic analysis tech- behaviors of apps rather than the fine-grained behav- niques are developed to detect and analyze iors, such as the URL in network connections and the Android malware. Some advanced Android phone number of sending SMS behavior. malware can use Java reflection and JNI mech- Without above limitations of static analysis, the dy- anisms to conceal their malicious behaviors namic analysis approach is usually used for deeply an- for static analysis. Furthermore, for dynamic alyzing apps [SFE+13]. Currently, dynamic analysis analysis, emulator detection and integrity self- uses hooking techniques for monitoring behaviors of checking are used by Android malware to by- apps. The hooking techniques can be divided into two pass all recent Android sandboxes. In this main types: 1) hooking Android framework APIs by paper, we propose ARTDroid, a framework modifying Android system [ZAG+15][EGH+14], and for hooking virtual-methods calls supporting 2) hooking APIs used in the app process by static in- the latest Android runtime (ART). A virtual- strumentation [BGH+13][DC13]. Both of them have method is called by the ART runtime using a limitations to analyze trick samples. The first hook- dispatch table (vtable). ARTDroid can tam- ing technique has a drawback that it cannot be used per the vtable without any modifications to on other vendors’ devices except for Google Nexus both Android framework and app’s code. The devices or emulators. This gives a chance for mali- ARTDroid hooking framework can be used to cious apps, which uses the device fingerprint and anti- build an efficient sandbox on real devices and emulator technique to evade the dynamic detection. monitor sensitive methods called in both Java Even though the second hooking technique does not reflection and JNI ways. have this drawback, but it becomes useless when apps apply anti-repacking techniques. Apps can check the 1 Introduction integrity of themselves in runtime and enter the frozen The analysis of Android apps becomes more and more mode to prevent dynamic analysis if the integrity is difficult currently. Both benign and malicious de- broken. Moreover, if malicious apps implement ma- velopers use various protection techniques, such as licious behaviors in native codes, the second hooking Java reflection, dynamic code loading and code ob- technique still cannot detect them. fuscation [RCJ13], to prevent their apps from reverse- To build a better hooking framework for dynamic engineering. Java reflection and dynamic code loading analysis, we design ARTDroid, an framework for hooking virtual-method calls under the latest Android Copyright c by the paper’s authors. Copying permitted for runtime (ART). The idea of hooking on ART is tam- private and academic purposes. This volume is published and pering the virtual method table (vtable) for detour- copyrighted by its editors. ing virtual-methods calls. The vtable is to support In: D. Aspinall, L. Cavallaro, M. N. Seghir, M. Volkamer (eds.): the dynamic-dispatch mechanism. And, dynamic dis- Proceedings of the Workshop on Innovations in Mobile Privacy and Security IMPS at ESSoS’16, London, UK, 06-April-2016, patch, i.e., the runtime selection of a target procedure published at http://ceur-ws.org given a method reference and the receiver type, is a 20 1 central feature of object-oriented languages to pro- the dex2oat tool to the boot.oat file. To allow pre- vide polymorphism. Since almost all Android sensi- loading of Java classes used in runtime, an image file tive APIs are virtual methods, we can collect the apps called boot.art is created by dex2oat. The image file behavior by using ARTDroid to hook Android APIs contains pre-initialized classes and objects from the methods. Android framework JARs. Through linking to this To summarize, this paper makes the following con- image, OAT files can call methods in Android frame- tributions. work or access pre-initialized objects. We are going to briefly analyze the ART internals, using as codebase We propose ARTDroid, a framework for hooking the Android version 6.0.1 r10. • virtual-method calls without any modifications to 1 // C++ mirror of java.lang.Class both the Android system and the app’s code. 2 class MANAGED Class FINAL : public Object { 3 We discuss how ARTDroid is made fully compat- 4 [...] • 5 HeapReference<IfTable> iftable_; ible with any real devices running the ART run- 6 HeapReference<String> name_; time with root privilege. 7 HeapReference<Class> super_class_; 8 HeapReference<PointerArray> vtable_; 9 uint32_t access_flags_; We demostrate that the hooking technique used • 10 uint64_t direct_methods_; by ARTDroid allows to intercept virtual-methods 11 uint64_t virtual_methods_; 12 uint32_t num_virtual_methods_; called in both Java reflection and JNI ways. 13 [...] 14 } We discuss applications of ARTDroid on malware • analysis and policy enforcement in Android apps. Figure 1: ART Class type We released ARTDroid as an open-source project The ART runtime uses specific C++ classes to mir- • 1. ror Java classes and methods. Java classes are inter- 2 The rest of this paper is organized as follows. Sec- nally mirrored by using Class . In Figure 1, virtual- tion 2 introduces the background about Android and methods defined in Class are stored in an array of the new Android runtime ART. The ARTDrod frame- ArtMethod* elements, called virtual methods (line work is introduced in Sec. 3 and its implementation 11). The vtable field (line 8) is the virtual method is discussed in Sec. 4. Performance evaluation is pre- table. During the linking, the vtable from the super- sented in Sec. 5, and discussion and applications are class is copied, and the virtual methods from that class in Sec. 6. Section 7 discuss some related works, and either override or are appended inside it. Basically, the we conclude this paper in Sec. 8. vtable is an array of ArtMethod* type. Direct meth- ods are stored in the direct methods array (line 2 Background 10) and the iftable array (line 5) contains pointers to the interface methods. We leave interface-methods Android apps are usually written in Java and com- hooking for future work. The Figure 2 shows the defi- piled to Dalvik bytecode (DEX). To develop an An- nition of ArtMethod class3. The main functionality droid app, developers typically use a set of tools via of ArtMethod class is to represent a Java method. Android Software Development Kit (SDK). With An- 1 class ArtMethod FINAL { droid’s Native Development Kit (NDK), developers 2 [...] can write native code and embed them into apps. The 3 GcRoot<mirror::Class> declaring_class_; 4 uint32_t access_flags_; common way of invoking native code on Android is 5 uint32_t method_index_; through Java Native Interface (JNI). 6 [...] 7 struct PACKED(4) PtrSizedFields { 8 void* entry_point_from_interpreter_; 2.1 ART Runtime 9 void* entry_point_from_jni_; 10 void* entry_point_from_quick_compiled_code_; ART, silently introduced in October 2013 at the An- 11 } ptr_sized_fields_; droid KitKat release, applies Ahead-of-Time (AoT) 12 } compilation to convert Dalvik bytecode to native code. At the installation time, ART compiles apps using Figure 2: ART ArtMethod type the on-device dex2oat tool to keep the compatibil- By definition, a method is declared within a class, ity. The dex2oat is used to compile Dalvik bytecode pointed by the declaring class field (line 3). The and produce an OAT file, which replaces Dalvik’s odex method’s index value is stored in the method index file. Even Android framework JARs are compiled by 2art/runtime/mirror/class.h 1https://vaioco.github.io 3art/runtime/art method.h 21 2 field (line 5). This value is the method’s index piled in lines 11-18 in Figure 4. The TelephonyMan- in the concrete method dispatch table stored within ager instance (an Object4 type) is stored in the register method’s class. The access flags field (line 4) r2. Then, the instance’s class is retrived from address stores the method’s modifiers (i.e., public, private, in r2 and stored in the register r0 (line 13). The static, protected, etc. ) and the PtrSizedFields method getDeviceId (an ArtMethod type) is directly struct, (line 7), contains pointers to the ArtMethod’s retrived (line 16) from memory using a static offset entry points. Pointers stored within this struct are as- from address stored in r0. Finally, the getMethodId’s signed by the ART compiler driver at the compilation entrypoint is called using the ARM branch instruction time. blx (line 18). The entrypoint’s address is also retrived by using a static memory offset from the ArtMethod 2.2 Virtual-methods Invocation in ART reference (line 17). In this paragraph we describe how ART runtime In Java, it is allowed to invoke a method dy- invokes virtual-methods by choosing the virtual- namically specified using Java Reflection. Re- flection calls managed by ART runtime use the method android.telephony.TelephonyManager’s 5 getDeviceId as an example. Figure 3 shows that the function InvokeMethod . This function calls getDeviceId method is invoked on TelephonyManager FindVirtualMethodForVirtualOrInterface which object’s class (line 4). Figure 4 shows dumped returns a pointer to the searched method by looking compiled codes for arm architecture by oatdump tool. in the vtable array of receiver’s class. A Java method can also be invoked by na- 1 package org.sid.example; tive code using the Call<type>Method family 2 public class MyClass { 3 public String callGetDeviceId(TelephonyManager tm){ functions, exposed by JNI.