Artdroid a Virtualmethod Hooking Framework on Android Art Runtime

Artdroid: a Virtual-Method Hooking Framework on Android Art Runtime

Artdroid: a Virtual-Method Hooking Framework on Android ART Runtime

ARTDroid: A Virtual-Method Hooking Framework on Android Fine art Runtime

Valerio Costamagna Cong Zheng Universit`adegli studi di Torino Palo Alto Networks valerio.costamagna@di.unito.information technology Georgia Institute of Technology cozheng@paloaltonetworks.com

techniques can dynamically launch specific behaviors, which can be only monitored in dynamic assay en- Abstract vironment instead of static analysis. Too, in obfus- cated apps, static analysis tin 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 observe and analyze iors, such as the URL in network connections and the Android malware. Some advanced Android phone number of sending SMS beliefs. malware can use Java reflection and JNI mech- Without above limitations of static analysis, the dy- anisms to muffle their malicious behaviors namic analysis approach is ordinarily 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 tin can exist divided into two pass all recent Android sandboxes. In this chief types: 1) hooking Android framework APIs by paper, nosotros 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 flim-flam samples. The first claw- 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 take chances for mali- ARTDroid hooking framework can be used to cious apps, which uses the device fingerprint and anti- build an efficient sandbox on existent devices and emulator technique to evade the dynamic detection. monitor sensitive methods called in both Java Fifty-fifty though the 2d hooking technique does not reflection and JNI ways. have this drawback, but information technology becomes useless when apps apply anti-repacking techniques. Apps can bank check the 1 Introduction integrity of themselves in runtime and enter the frozen The analysis of Android apps becomes more than and more manner to preclude 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 equally 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. Coffee reflection and dynamic lawmaking loading assay, we blueprint ARTDroid, an framework for hooking virtual-method calls under the latest Android Copyright c by the newspaper'due south 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, Fifty. Cavallaro, K. 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, Britain, 06-Apr-2016, patch, i.e., the runtime selection of a target process published at http://ceur-ws.org given a method reference and the receiver type, is a

twenty 1 fundamental 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 Coffee classes used in runtime, an image file tive APIs are virtual methods, we tin 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 post-obit con- image, OAT files tin call methods in Android frame- tributions. piece of work or admission 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 half-dozen.0.ane r10. • virtual-method calls without whatever modifications to 1 // C++ mirror of java.lang.Grade both the Android system and the app's code. 2 course MANAGED Grade Last : public Object { three We discuss how ARTDroid is fabricated fully compat- iv [...] • 5 HeapReference iftable_; ible with whatever real devices running the Art run- 6 HeapReference name_; fourth dimension with root privilege. 7 HeapReference super_class_; 8 HeapReference 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_; chosen 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 Grade blazon Nosotros released ARTDroid as an open up-source project The ART runtime uses specific C++ classes to mir- • 1. ror Java classes and methods. Coffee classes are inter- 2 The rest of this newspaper is organized as follows. Sec- nally mirrored by using Class . In Effigy ane, 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. five, and discussion and applications are class is copied, and the virtual methods from that course 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 assortment (line 2 Groundwork 10) and the iftable assortment (line five) contains pointers to the interface methods. Nosotros get out interface-methods Android apps are usually written in Java and com- hooking for future piece of work. The Figure 2 shows the defi- piled to Dalvik bytecode (DEX). To develop an An- nition of ArtMethod class3. The primary functionality droid app, developers typically use a prepare of tools via of ArtMethod class is to represent a Coffee method. Android Software Development Kit (SDK). With An- ane class ArtMethod Last { droid's Native Evolution Kit (NDK), developers 2 [...] can write native lawmaking and embed them into apps. The iii GcRoot declaring_class_; four uint32_t access_flags_; mutual fashion of invoking native lawmaking 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 Fine 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-Fourth dimension (AoT) 12 } compilation to convert Dalvik bytecode to native code. At the installation time, Art compiles apps using Figure 2: ART ArtMethod blazon 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'southward odex method's index value is stored in the method alphabetize file. Fifty-fifty Android framework JARs are compiled by 2art/runtime/mirror/class.h 1https://vaioco.github.io 3art/runtime/fine art method.h

21 2 field (line 5). This value is the method'due south index piled in lines xi-18 in Effigy 4. The TelephonyMan- in the concrete method dispatch table stored within ager instance (an Object4 type) is stored in the register method'south class. The access flags field (line four) r2. Then, the instance'due south class is retrived from accost stores the method's modifiers (i.due east., 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 inside this struct are every bit- from accost stored in r0. Finally, the getMethodId'due south signed by the ART compiler driver at the compilation entrypoint is chosen using the ARM branch didactics time. blx (line xviii). The entrypoint'due south address is besides retrived by using a static memory offset from the ArtMethod two.2 Virtual-methods Invocation in Art reference (line 17). In this paragraph we describe how ART runtime In Java, information technology 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'south form (line 4). Figure 4 shows dumped returns a arrow to the searched method past looking compiled codes for arm architecture by oatdump tool. in the vtable assortment of receiver's class. A Java method can too be invoked by na- 1 package org.sid.example; tive code using the CallMethod family unit 2 public form MyClass { three public String callGetDeviceId(TelephonyManager tm){ functions, exposed past JNI. For case, function CallObjectMethod(JNIEnv* env, jobject obj, 4 Cord imei = tm.getDeviceId(); six 5 return imei; jmethodID mid, ...) is used to phone call a virtual- half-dozen } method which returns an Object type. When a Java 7 } method is invoked from native code using a function from CallMethod family unit, the ART runtime Figure 3: Telephone call to method getDeviceId volition go through the vtable array to find a matched method matching. 1 Code: (code_offset=0x002d93b5 size_offset=0x002d93b0 In that location are two different means to go a Java virtual- size=60)... method'south reference. One is through the reflection two 0x002d93b4: f5bd5c00 subs r12, sp, #8192 iii 0x002d93b8: f8dcc000 ldr.w r12, [r12, #0] APIs exposed by coffee.lang.Course. For instance, 4 suspend bespeak dex PC: 0x0000 the method getMethod returns a reference which rep- 5 GC map objects: v1 ([sp + #36]), v2 (r6) half dozen 0x002d93bc: e92d40e0 button {r5, r6, r7, lr} resents the public method with a matched method 7 0x002d93c0: b084 sub sp, sp, #xvi signature. All java.lang.Class' methods, which per- eight 0x002d93c2: 1c07 mov r7, r0 9 0x002d93c4: 9000 str r0, [sp, #0] mits to get a virtual-method reference, can use the 10 0x002d93c6: 9109 str r1, [sp, #36] virtual methods array to lookup the requested 11 0x002d93c8: 1c16 mov r6, r2 12 0x002d93ca: 1c31 mov r1, r6 method. The other way is offered by the JNI func- thirteen 0x002d93cc: 6808 ldr r0, [r1, #0] tion FindMethodID. It searches for a method matching xiv append bespeak dex PC: 0x0000 15 GC map objects: v1 ([sp + #36]), v2 (r6) both the requested name and signature by looking in 16 0x002d93ce: f8d00234 ldr.w r0, [r0, #564] the virtual methods array within the class refer- 17 0x002d93d2: f8d0e02c ldr.w lr, [r0, #44] eighteen 0x002d93d6: 47f0 blx lr ence passed as argument.

Figure 4: Compiled native code of callGetDeviceId 3 Framework Design Before discussions on native code, in Fig. 4, we The goal of ARTDroid is to avoid both app's and briefly introduce the devirtualization. To speedup run- Android system code modifications. So, the design time execution, during the on-device compilation fourth dimension, of ARTDroid is oriented towards directly change the virtual-methods calls are devirtualized. Devirtualiza- app's virtual-memory tampering with Art internals tion process uses method's alphabetize to point to the rel- representation of Java classes and methods. ART- ative element inside the vtable inside receiver in- Droid consists of two components. The first compo- stance's grade. As result, compiled lawmaking contains static nent is the core engine written in C and the other memory offset used to get the called ArtMethod's one is the Coffee side that is a bridge for calling from retention reference. 4art/runtime/mirror/object.h Now, we talk over the native code generated for the 5art/runtime/reflection.cc method callGetDeviceId. The line 4 in Effigy three is com- 6art/runtime/jni internal.cc

22 three user-defined Java code to ARTDroid'southward cadre. The core engine aims to: find target methods' reference in vir- tual memory, load user-supplied DEX files, hijack the vtable and set native hooks. Moreover, it registers the native methods callable from the Java side. ARTDroid is configured past reading a user-supplied JSON format- ted configuration file containing the target methods listing. Suppose that you desire to intercept calls to a virtual-method. You lot have to define your own Java (a) ARTDroid not enabled method and override the target method by using Fine art- Droid API. All calls to the target method will be in- tercepted and so go to your Coffee method (we call information technology patch code). ARTDroid further supports loading patch code from DEX file. This allows the patch code to be written in Java and thus simplifies interacting with the target app and the Android framework (Con- text, etc). ARTDroid is based on library injection and uses An- droid Dynamic Binary Instrumentation toolkit[ADB] released past Samsung. The ABDI tool is used by ART- Droid to insert trace points dynamically into the pro- cess address space. ARTDroid requires the root privilege in order to (b) ARTDroid enabled inject the hooking library in the app's virtual memory, and the hooking library can be injected either in a Figure 5: App virtual memory layout running app or in the Zygote[LLW+14] master procedure. At present, nosotros explain the framework design in figures. ARTDroid overwrites the target method's entry Figure 5a shows the app's memory layout without within both the vtable and virtual methods ar- ARTDroid. The class TelephonyManager is loaded ray past writing the address of the method's patch code. within the boot image (boot.fine art). This Course contains The original method'southward reference is not modified by both the vtable and virtual methods arrays where ARTDroid and its address is stored inside the ART- the arrow to method getDeviceId is stored. Instead, Droid'south internal information structures. This accost will be Effigy 5b represent the app's memory layout while used to telephone call the original method implementation. ARTDroid hooking library is enabled. First, the When ARTDroid hooks a target method, all calls hooking library is loaded inside the app's virtual to that method will be intercepted and they will memory (step i), and then ARTDroid loads the go to the patch code. Then, the patch code re- user-defined patch code by DexClassLoader'southward methods ceives the this object and the target method'southward ar- (step 2). Later this, ARTDroid uses its internal guments as its parameters. To telephone call the original functions to retrive target methods reference. So, implementation of target method, ARTDroid ex- it can hook these methods past both vtable and ports the function callOriginalMethod to the Java virtual methods hijacking (step 3). patch code. Internally, ARTDroid'southward core engine calls the original method implementation using the Every bit discussed in 2.two, the vtable array is used by JNI CallNonVirtualMethod family of routines. the Art runtime to invoke a virtual-method. Instead, These functions can invoke a Coffee example method the virtual methods array is accessed to return a (non-static) on a Coffee object, co-ordinate to specified virtual-methods reference from retention. ARTDroid class and methodID. The original method implemen- exploits these mechanisms to hooking virtual-methods tation is invoked by ARTDroid using its address inter- by both vtable and virtual methods hijacking nally stored before the hooking stage. To guarantee ways. a reliable hooking, ARTDroid uses ADBI features to hook the functions of CallNonVirtualMethod four Implementation family unit. By doing this, all calls to these functions are checked by ARTDroid to block calls to an hooked To get the target method'south reference, ARTDroid uses virtual-method only if these calls exercise non come up from the JNI office FindMethodID. ARTDroid's core engine.

23 4 five Evaluation tin be analyzed using either traceview or dmtrace- dump. To measure the effective overhead due to ART- 5.one Performance Examination Droid, nosotros telephone call the methods using both Java reflection To measure the effectiveness of virtual-methods hook- and JNI in addition to the normal invocation. Nosotros ing, nosotros firstly need a test set of sensitive methods. ran the exam 10,000 times for each method, one time with SuSi[RAB14] provides sensitive methods in Android ARTdroid disabled and so with ARTDroid enabled 4.2. To verify how many of these methods are declared mode. The average running time for each call to an every bit virtual, we firstly test them in Android emulator in hooked method is showed in the following Table one. version 4.2. We use Coffee reflection to telephone call these meth- The about of overhead in ARTDroid is acquired by ods at runtime. The upshot of our experiment shows the JNI call, which is internally used to invoke the that a remarkable number of virtual-methods could be original method implementation. We registered a used to threaten user privacy. The following list de- worst case overhead of 25% for each hooked method. scribes our experiment results: Therefore, the total overhead of a phone call to an hooked method is around 0.25 seconds. This overhead could 65.one% of these methods are declared as virtual be decreased by adding an internal enshroud to store • methods' reference called by ARTDroid, instead of half dozen.6% are not-virtual • using JNI function FindMethodID at each call. Nosotros get out these improvements as hereafter piece of work. 28.three% methods not found • Unfortunately, the but methods list bachelor from Table 1: Performances SuSi is from Android version four.2. To overcome this limitation, nosotros analyze the sensitive methods list of- fered by PScout[AZHL12]. The methods of PScout ARTDroid Invoke type are available from version 2.ii to version 5.1.1. Our enabled? Normal Reflection JNI another test is on Android 5.one.1 codebase and information technology is carried on a Nexus 6 running Android 5.i.1. After an- Yes 1.12 due south 1.39 s i.xix s alyzing them, nosotros know that only i.0% of methods are No 0.88 s ane.14 southward 0.94 s non-virtual. overhead 0.24 s 0.25 south 0.25 south

59.two% of these methods are declared as virtual • one.0% are not-virtual five.2 Case Written report • Now, nosotros show a case study by hooking TelephonyMan- 39.8% methods non plant • ager'south getDeviceId in ARTDroid.

Still, some methods cannot be found via Java 1 {"config": { reflection because corresponding classes or methods 2 " debug ": 1, 3 "dex": [{"path": "/data/local/tmp/dex/target.dex are not visible to normal apps. They belong to the "}] Android system apps. So, we can conclude that near 4 " hooks ": [ v { of sensitive methods are virtual from our test results. half-dozen "class-proper name": "android/telephony/ ARTDroid can cover all sensitive methods except ane.0% TelephonyManager", 7 "method-name": "getDeviceId", methods on Android 5.1.1. 8 "method-sig": "()Ljava/lang/Cord;", The overhead introduced by ARTDroid depends 9 "hook-cls-proper noun": "org/sid/case/HookCls" x }] much on the behavior of the patch code. To measure eleven }} the overhead, nosotros developed a test app, which repeat- edly calls sensitive methods or APIs. In particular, Figure 6: ARTDroid configuration file this applciation attempts to perform the following op- erations by calling Android APIs (both via Java reflec- tion and JNI) : initiate several network connections, Figure 6 shows the configuration file which contains access sensitive files on the SD menu (such as the user's the definition of methods to claw. This file is used to photos), send text message to premium numbers, ac- define the information requested past ARTDroid, which cess the user'south contact list and retrive the device'southward are: method's proper name and signature and the grade' proper noun IMEI. We used the profiling facilities offered past An- where the patch code is defined in. The patch code droid calling the android.os.Debug's startMethodTrac- chosen instead of method getDeviceId is showed inFig- ing/stopMethodTracing. And so, the produced traces ure 7.

24 5 i public String getDeviceId() { app. Instead, ARTDroid is even so able to analyze that 2 String primal = "android/telephony/ app. Obviously, ARTDroid has its limitations and cor- TelephonyManagergetDeviceId()Ljava/lang/ Cord ;"; ner cases. The master limitations is due to the running 3 Object[] args = {}; of the hooking library inside the aforementioned process space of iv return (String) callOriginalMethod(central, this, args) + " IMPS2016!!"; the target app. In a scenario where an assailant want v } to featherbed our arroyo, it can direct invoke a syscall through inline assembly code to gets sensitive results Effigy 7: Patch code for method getDeviceId bypassing ARTDroid. Nosotros annotation that the direct organization call is not a common technique used by current daily Android malware. Nevertheless, we envise that ART- To restore the original call-flow, ARTDroid ex- Droid tin be used in conjunction with existing works poses to Java patch-code the native function like [TKFC15],[ZAG+15], [XSA12] to provide an addi- callOriginalMethod. This function receivers as first tional layer of analysis. argument the string key to identify the target method Even though Coffee directly methods are nearly not in the lexicon of hooked methods, internally homo- used for both malicious and security-sensitive behav- aged by ARTDroid. Second argument represents the iors, our future piece of work will back up both interface- this object and the terminal argument is the array of methods and direct-methods hooking. A possible solu- method'south arguments. All future calls to method become- tion is that we can statically musical instrument the dex2oat DeviceId will exist redirected to the patch code, inde- and replace the arrangement original one once nosotros become root pendently if these calls are fabricated using Java reflection privilege. The instrumented dex2oat tin intercept all mechanisms or JNI. interface-methods and straight-methods. Since ARTDroid hooking library can be injected di- 6 Give-and-take rectly either in Zygote or when the target app is going Nosotros notation that the principal goal of our piece of work is to to be spawned. Even if the app under testing can propose a novel technique to hook Java virtual- tamper with the vtable , information technology tin can not get the original methods, our approach can exist used to enforce fine- method'south address. In fact, after ARTDroid is enabled, grained user-defined security policies either on existent- the original method is no more pointed by both the world devices or emulators too. Previous re- vtable and virtual methods arrays. search has shown that fifty-fifty benign apps frequently con- In department v, we accept presented an evaluation about tain vulnerable components that expose the users to the effectiveness of virtual-methods hooking in the An- a variety of threaths: common examples are com- droid system by analyzing results obtained from both ponent hijacking vulnerabilities[LLW+12], permission SuSi[SuS] and PScout[AZHL12] projects. Inquiry re- leaking [GZWJ12],[Jia13] and remote lawmaking execution sults point that there is a considerable percentage of vulnerabilities[PFB+fourteen]. sensitive methods which are virtual. Since, ARTDroid Suppose the target app is implementing the follow- can claw virtual-methods and tamper with their ar- ing features: guments, it could be used to define security policies to verifiy apps' behaviors at runtime. For example, one. dynamic code loading ARTDroid can be used to automatically identify apps which are sending SMS to premium numbers. 2. code obfuscation (Java reflection, code encryp- Since the main downside of dynamic assay tech- tion, etc. . . ) niques is the lawmaking-coverage consequence, we envise that Art- 3. integrity checks (i.e, due to copyright issue) Droid can be integrated with automatic exploration system like Smartdroid[ZZD+12], proposed by Cong iv. invoke of security-sensitive Coffee methods via JNI et al. In the following, we testify some applications of ART- v. detection/evasion of emulated environments (i.e, Droid: due to copyright consequence) Collect apps beliefs at runtime. Analysis of An- An approach based only on static analysis cannot • droid API function calls permits the extraction of properly extract security relevant information due to information about the behavior of apps. the employ of one, 2 and 4. Moreover, all existing approaches based on bytecode rewriting techniques cannot clarify Verify security policies at runtime. When users that app mainly for the utilize of integrity checks. Notation • install an app, they tin enforce some policies in that since the use of v, in contrast to ARTDroid, all ARTDroid, so that the new app's sensitive exist- the existing approaches based on emulated environ- haviors, such equally sending SMS, can exist restricted ments can not properly analyze the beliefs of that by ARTDroid.

25 half-dozen Android malware analysis. Some trick malware patches for Android. This system uses the DDI[DDI] • use a lot of dynamic assay evading techniques. framework. DDI allows to supplant capricious methods But in ARTDroid enforced sandbox, our hooking in Dalvik lawmaking with native function phone call using JNI. technique cannot exist bypassed by current evading In [MRK14], Mulliner et. al. shown an automated techniques. Also, we can hands build our ART- attack against in-app billing using the DDI capabilities Droid sandbox either on Android emulator or on to control the in-app billing purchase flow. Note that real devices. the methods used to achieve in-app billing are defined as virtual. seven Related Work Frida[Friday], a dynamic code instrumentation toolkit, Xposed framework [Xpo] and Cydia substrate for An- Several approaches take been proposed to provide droid [Cyd] share similarity with the DDI intrumenta- methods hooking on Android. A family of approaches tion approach. These projects were created for device is based on bytecode rewriting technique. The app modding and, in contrast with DDI, require replac- can be instrumented offline by modifying the app ing of arrangement components suck equally zygote. Currently, bytecode. AppGuard[BGH+thirteen] proposed by Baches Xposed compatibility with Art runtime is actually in et ak, uses this approach to automatically repack- beta stage7 and the framework installation condition is age target apps to adhere user-level sandboxing and to flash the device by a custom recovery image. While policy enforcement code. Zhou et al. proposed these approaches are very suitable under the Dalvik AppCage[ZPW+15], a arrangement to confine the runtime VM, they are totally limited for using under the Art behavior of the thid-party Android apps. Davis et runtime. In fact, both DDI, Frida and Cydia substrate al. proposed Retroskeleton[DC13], an Android app are not able to piece of work under the Art runtime. rewriting framework for customizing apps, which is Aurasium [XSA12] builds a reference monitor into based on their previous work, I-ARM-Droid[DSKC12]. application binaries. The Dalvik lawmaking is not patched, While these approaches are valuable and each of just new classes and native lawmaking are added to ensure them has its own advantages too as disadvantages, that the instrumentation code is run first. Clearly, they have different significant downward sides. This ap- such approaches are non effective if the code is obfus- proach is non feasible against apps that verify their cated and protected against static assay and disas- integrity at runtime. This kind of defense (anti- sembly. Besides note that the packet signature of the tampering) is also used in beneficial apps as well. To instrumented applications are broken when they are be able to supercede API-level calls with a secure wrap- patched statically. In comparing, our approach does per, bytecode rewriters need to identify desidered API not demand to repack the app, our modifications are in- telephone call-site within the target app. Equally mentioned in retentivity only and thus we do not break code signing. [HSD13],[ZAG+xv], apps that use either Java reflec- Recent works proposed novel approaches that aim tion or dynamically lawmaking loading can featherbed the app to sandbox unmodified apps in non-rooted devices run- rewriting technique. Moreover, apps which are using ning stock Android. Boxify[BBH+15] presented an JNI to call Coffee methods can featherbed this techniques arroyo that aims to sandbox apps by means of every bit well. syscall interposition (using the ptrace mechanism) and A different approach to implement methods trac- it works by loading and executing the code of the orig- ing can be achieved past using a custom Android sys- inal app within the context of another, monitoring, tem or by using an emulated environment (e.g., a app. A similar work, [BFKV15] uses the aforementioned ap- modified QEMU emulator). Enck et al. proposed proach to sandbox arbitrary Android apps. The ap- TaintDroid[EGH+fourteen], an Android modified system to proach presented in both of these recent works, repre- observe privacy leak. StayDynA[ZAG+xv] a system sent one of the nigh promising and interesing future for analyzing security of dynamic code loading in An- work direction. droid, uses a custom arrangement image which tin can be used only on Nexus like devices. Tam et al. presented 8 Conclusion CopperDroid[TKFC15], a framework built on top of QEMU to automatically perform dynamic analysis of In this paper, nosotros nowadays ARTDroid, a framework for Android malware. These families of approaches, which hooking virtual-methods under Art runtime. ART- are based on emulators, can exist bypassed by emulation Droid supports the virtual-method hooking without detection techniques [PVA+14] [VC14]. A comparison any modifications to both Android organisation and app'southward on Android sanbox has been published past Neuren et lawmaking. ARTDroid allows to analyze apps even if al. in [NVdVL+fourteen]. they utilise anti-tampering techniques or they use ei- Mulliner et al. proposed PatchDroid[MORK13], a 7http://forum.xda-developers.com/showthread.php?t= system to distribute and apply third-political party securities 3034811

26 7 ther Java reflection or JNI to invoke virtual-methods. [DDI] Dalvik dynamic instrumentation Moreover, ARTDroid can be used on whatsoever existent devices framework. https://github.com/ with Art runtime in one case getting the root privilege. The crmulliner/ddi. Accessed: 2016-02- applications of ARTDroid include dynamic assay of 27. Android malware on real devices or security policies enforcement. [DSKC12] Benjamin Davis, Ben Sanders, Armen Khodaverdian, and Hao Chen. I-arm- droid: A rewriting framework for in- References app reference monitors for android ap- [ADB] Android dynamic binary instrumenta- plications. Mobile Security Technolo- tion. https://github.com/Samsung/ gies, 2012, 2012. ADBI. Accessed: 2016-02-27. [EGH+14] William Enck, Peter Gilbert, Seungyeop Han, Vasant Tendulkar, Byung-Gon [AZHL12] Kathy Wain Yee Au, Yi Fan Zhou, Zhen Chun, Landon P Cox, Jaeyeon Jung, Huang, and David Lie. Pscout: analyz- Patrick McDaniel, and Anmol Northward Sheth. ing the android permission specification. Taintdroid: an data-flow track- In Proceedings of the 2012 ACM confer- ing organisation for realtime privacy monitor- ence on Computer and communications ing on smartphones. ACM Transactions security, pages 217–228. ACM, 2012. on Computer Systems (TOCS), 32(two):five, [BBH+fifteen] Michael Backes, Sven Bugiel, Christian 2014. Hammer, Oliver Schranz, and Philipp [Fri] Frida.re. https://frida.re. Accessed: von Styp-Rekowsky. Boxify: Total- 2016-02-27. fledged app sandboxing for stock an- droid. In 24th USENIX Security Sympo- [GZWJ12] Michael C Grace, Yajin Zhou, Zhi sium (USENIX Security 15), pages 691– Wang, and Xuxian Jiang. Systematic 706, 2015. detection of capability leaks in stock an- droid smartphones. In NDSS, 2012. [BFKV15] Antonio Bianchi, Yanick Fratantonio, Christopher Kruegel, and Giovanni Half-dozen- [HSD13] Hao Hao, Vicky Singh, and Wenliang gna. Njas: Sandboxing unmodified ap- Du. On the effectiveness of api-level plications in non-rooted devices running access control using bytecode rewriting stock android. In Proceedings of the in android. In Proceedings of the 8th 5th Annual ACM CCS Workshop on ACM SIGSAC symposium on Informa- Security and Privacy in Smartphones tion, computer and communications se- and Mobile Devices, pages 27–38. ACM, curity, pages 25–36. ACM, 2013. 2015. [Jia13] Yajin Zhou Xuxian Jiang. Detecting passive content leaks and pollution in [BGH+13] Michael Backes, Sebastian Gerling, android applications. In Proceedings of Christian Hammer, Matteo Maffei, and the 20th Network and Distributed Sys- Philipp von Styp-Rekowsky. Appguard– tem Security Symposium (NDSS), 2013. enforcing user requirements on android apps. In Tools and Algorithms for the [LLW+12] Long Lu, Zhichun Li, Zhenyu Wu, Construction and Assay of Systems, Wenke Lee, and Guofei Jiang. Chex: pages 543–548. Springer, 2013. statically vetting android apps for com- ponent hijacking vulnerabilities. In Pro- [Cyd] Cydia substrate for android. http: ceedings of the 2012 ACM conference on //www.cydiasubstrate.com. Accessed: Computer and communications security, 2016-02-27. pages 229–240. ACM, 2012. [DC13] Benjamin Davis and Hao Chen. Ret- [LLW+14] Byoungyoung Lee, Long Lu, Tielei roskeleton: retrofitting android apps. In Wang, Taesoo Kim, and Wenke Lee. Proceeding of the 11th annual interna- From zygote to morula: Fortifying tional conference on Mobile systems, ap- weakened aslr on android. In Security plications, and services, pages 181–192. and Privacy (SP), 2014 IEEE Sympo- ACM, 2013. sium on, pages 424–439. IEEE, 2014.

27 8 [MORK13] Collin Mulliner, Jon Oberheide, William nual ACM Symposium on Applied Com- Robertson, and Engin Kirda. Patch- puting, pages 1808–1815. ACM, 2013. droid: scalable 3rd-party security [SuS] Susi. https://github.com/ patches for android devices. In Pro- secure-software-technology/SuSi. ceedings of the 29th Annual Computer Accessed: 2016-02-27. Security Applications Conference, pages 259–268. ACM, 2013. [TKFC15] Kimberly Tam, Salahuddin J Khan, Aristide Fattori, and Lorenzo Cavallaro. [MRK14] Collin Mulliner, William Robertson, Copperdroid: Automatic reconstruction and Engin Kirda. Virtualswindle: An of android malware behaviors. In NDSS, automated attack against in-app billing 2015. on android. In Proceedings of the 9th ACM symposium on Information, [VC14] Timothy Vidas and Nicolas Christin. figurer and communications security, Evading android runtime analysis via pages 459–470. ACM, 2014. sandbox detection. In Proceedings of the 9th ACM symposium on Informa- + [NVdVL 14] Sebastian Neuner, Victor Van der tion, calculator and communications se- Veen, Martina Lindorfer, Markus Hu- curity, pages 447–458. ACM, 2014. ber, Georg Merzdovnik, Martin Mulaz- zani, and Edgar Weippl. Enter sandbox: [Xpo] Xposed framework. https://repo. Android sandbox comparing. arXiv xposed.info. Accessed: 2016-02-27. preprint arXiv:1410.7749, 2014. [XSA12] Rubin Xu, Hassen Sa¨ıdi,and Ross An- [PFB+xiv] Sebastian Poeplau, Yanick Fratantonio, derson. Aurasium: Practical policy en- Antonio Bianchi, Christopher Kruegel, forcement for android applications. In and Giovanni Vigna. Execute this! an- Presented equally part of the 21st USENIX alyzing unsafe and malicious dynamic Security Symposium (USENIX Security code loading in android applications. In 12), pages 539–552, 2012. NDSS, volume 14, pages 23–26, 2014. [ZAG+15] Yury Zhauniarovich, Maqsood Ahmad, Olga Gadyatskaya, Bruno Crispo, and [PVA+14] Thanasis Petsas, Giannis Voyatzis, Elias Fabio Massacci. Stadyna: addressing Athanasopoulos, Michalis Polychron- the problem of dynamic code updates akis, and Sotiris Ioannidis. Rage confronting in the security analysis of android appli- the virtual car: hindering dynamic cations. In Proceedings of the 5th ACM assay of android malware. In Keep- Conference on Data and Application Se- ings of the Seventh European Workshop curity and Privacy, pages 37–48. ACM, on System Security, page 5. ACM, 2014. 2015. [RAB14] Siegfried Rasthofer, Steven Arzt, and [ZPW+xv] Yajin Zhou, Kunal Patel, Lei Wu, Zhi Eric Bodden. A automobile-learning ap- Wang, and Xuxian Jiang. Hybrid user- proach for classifying and categorizing level sandboxing of third-party android android sources and sinks. In NDSS, apps. In Proceedings of the tenth ACM 2014. Symposium on Information, Estimator and Communications Security, pages [RCJ13] Vaibhav Rastogi, Yan Chen, and Xux- 19–30. ACM, 2015. ian Jiang. Droidchameleon: evaluating android anti-malware confronting transfor- [ZZD+12] Cong Zheng, Shixiong Zhu, Shuaifu Dai, mation attacks. In Proceedings of the Guofei Gu, Xiaorui Gong, Xinhui Han, 8th ACM SIGSAC symposium on Infor- and Wei Zou. Smartdroid: An au- mation, computer and communications tomatic system for revealing ui-based security, pages 329–334. ACM, 2013. trigger conditions in android applica-

+ tions. In Proceedings of the Second [SFE 13] Michael Spreitzenbarth, Felix Freiling, ACM Workshop on Security and Pri- Florian Echtler, Thomas Schreck, and vacy in Smartphones and Mobile De- Johannes Hoffmann. Mobile-sandbox: vices, SPSM '12, pages 93–104. ACM, having a deeper await into android appli- 2012. cations. In Proceedings of the 28th An-

28 9

wyatthowing.blogspot.com

Source: https://docslib.org/doc/1750724/artdroid-a-virtual-method-hooking-framework-on-android-art-runtime

0 Response to "Artdroid a Virtualmethod Hooking Framework on Android Art Runtime"

Post a Comment

Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel