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
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
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 time, of ARTDroid is oriented towards directly modify the virtual-methods calls are devirtualized. Devirtualiza- app’s virtual-memory tampering with ART internals tion process uses method’s index to point to the rel- representation of Java classes and methods. ART- ative element inside the vtable within receiver in- Droid consists of two components. The first compo- stance’s class. As result, compiled code 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 Java side that is a bridge for calling from memory reference. 4art/runtime/mirror/object.h Now, we discuss the native code generated for the 5art/runtime/reflection.cc method callGetDeviceId. The line 4 in Figure 3 is com- 6art/runtime/jni internal.cc
22 3 user-defined Java code to ARTDroid’s core. 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 by reading a user-supplied JSON format- ted configuration file containing the target methods list. Suppose that you want to intercept calls to a virtual-method. You have to define your own Java (a) ARTDroid not enabled method and override the target method by using ART- Droid API. All calls to the target method will be in- tercepted and then go to your Java method (we call it 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 by 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 process. Now, we 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 by writing the address of the method’s patch code. within the boot image (boot.art). This Class contains The original method’s reference is not modified by both the vtable and virtual methods arrays where ARTDroid and its address is stored inside the ART- the pointer to method getDeviceId is stored. Instead, Droid’s internal data structures. This address will be Figure 5b represent the app’s memory layout while used to 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 1), and then ARTDroid loads the go to the patch code. Then, the patch code re- user-defined patch code by DexClassLoader’s methods ceives the this object and the target method’s ar- (step 2). After this, ARTDroid uses its internal guments as its parameters. To call the original functions to retrive target methods reference. So, implementation of target method, ARTDroid ex- it can hook these methods by both vtable and ports the function callOriginalMethod to the Java virtual methods hijacking (step 3). patch code. Internally, ARTDroid’s core engine calls the original method implementation using the As discussed in 2.2, the vtable array is used by JNI CallNonVirtual
23 4 5 Evaluation can be analyzed using either traceview or dmtrace- dump. To measure the effective overhead due to ART- 5.1 Performance Test Droid, we call the methods using both Java reflection To measure the effectiveness of virtual-methods hook- and JNI in addition to the normal invocation. We ing, we firstly need a test set of sensitive methods. ran the test 10,000 times for each method, once with SuSi[RAB14] provides sensitive methods in Android ARTdroid disabled and then with ARTDroid enabled 4.2. To verify how many of these methods are declared mode. The average running time for each call to an as virtual, we firstly test them in Android emulator in hooked method is showed in the following Table 1. version 4.2. We use Java reflection to call these meth- The most of overhead in ARTDroid is caused by ods at runtime. The result 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 call to an hooked method is around 0.25 seconds. This overhead could 65.1% of these methods are declared as virtual be decreased by adding an internal cache to store • methods’ reference called by ARTDroid, instead of 6.6% are non-virtual • using JNI function FindMethodID at each call. We leave these improvements as future work. 28.3% methods not found • Unfortunately, the only methods list available from Table 1: Performances SuSi is from Android version 4.2. To overcome this limitation, we analyze the sensitive methods list of- fered by PScout[AZHL12]. The methods of PScout ARTDroid Invoke type are available from version 2.2 to version 5.1.1. Our enabled? Normal Reflection JNI another test is on Android 5.1.1 codebase and it is carried on a Nexus 6 running Android 5.1.1. After an- Yes 1.12 s 1.39 s 1.19 s alyzing them, we know that only 1.0% of methods are No 0.88 s 1.14 s 0.94 s non-virtual. overhead 0.24 s 0.25 s 0.25 s
59.2% of these methods are declared as virtual • 1.0% are non-virtual 5.2 Case Study • Now, we show a case study by hooking TelephonyMan- 39.8% methods not found • ager’s getDeviceId in ARTDroid.
However, 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 most 4 " hooks ": [ 5 { of sensitive methods are virtual from our test results. 6 "class-name": "android/telephony/ ARTDroid can cover all sensitive methods except 1.0% TelephonyManager", 7 "method-name": "getDeviceId", methods on Android 5.1.1. 8 "method-sig": "()Ljava/lang/String;", The overhead introduced by ARTDroid depends 9 "hook-cls-name": "org/sid/example/HookCls" 10 }] much on the behavior of the patch code. To measure 11 }} the overhead, we 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 card (such as the user’s the definition of methods to hook. This file is used to photos), send text message to premium numbers, ac- define the information requested by ARTDroid, which cess the user’s contact list and retrive the device’s are: method’s name and signature and the class’ name IMEI. We used the profiling facilities offered by An- where the patch code is defined in. The patch code droid calling the android.os.Debug’s startMethodTrac- called instead of method getDeviceId is showed inFig- ing/stopMethodTracing. Then, the produced traces ure 7.
24 5 1 public String getDeviceId() { app. Instead, ARTDroid is still able to analyze that 2 String key = "android/telephony/ app. Obviously, ARTDroid has its limitations and cor- TelephonyManagergetDeviceId()Ljava/lang/ String ;"; ner cases. The main limitations is due to the running 3 Object[] args = {}; of the hooking library inside the same process space of 4 return (String) callOriginalMethod(key, this, args) + " IMPS2016!!"; the target app. In a scenario where an attacker want 5 } to bypass our approach, it can directly invoke a syscall through inline assembly code to gets sensitive results Figure 7: Patch code for method getDeviceId bypassing ARTDroid. We note that the direct system 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 can 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 Java direct methods are almost not in the dictionary of hooked methods, internally man- used for both malicious and security-sensitive behav- aged by ARTDroid. Second argument represents the iors, our future work will support both interface- this object and the last argument is the array of methods and direct-methods hooking. A possible solu- method’s arguments. All future calls to method get- tion is that we can statically instrument the dex2oat DeviceId will be redirected to the patch code, inde- and replace the system original one once we get root pendently if these calls are made using Java reflection privilege. The instrumented dex2oat can intercept all mechanisms or JNI. interface-methods and direct-methods. Since ARTDroid hooking library can be injected di- 6 Discussion rectly either in Zygote or when the target app is going We note that the main goal of our 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 , it can not get the original methods, our approach can be used to enforce fine- method’s address. In fact, after ARTDroid is enabled, grained user-defined security policies either on real- the original method is no more pointed by both the world devices or emulators as well. Previous re- vtable and virtual methods arrays. search has shown that even benign apps often con- In section 5, we have 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. Research re- leaking [GZWJ12],[Jia13] and remote code execution sults indicate that there is a considerable percentage of vulnerabilities[PFB+14]. sensitive methods which are virtual. Since, ARTDroid Suppose the target app is implementing the follow- can hook 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 instance, 1. 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 analysis tech- tion, etc. . . ) niques is the code-coverage issue, 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 4. invoke of security-sensitive Java methods via JNI et al. In the following, we show some applications of ART- 5. detection/evasion of emulated environments (i.e, Droid: due to copyright issue) Collect apps behavior 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 use of 1, 2 and 4. Moreover, all existing approaches based on bytecode rewriting techniques cannot analyze Verify security policies at runtime. When users that app mainly for the use of integrity checks. Note • install an app, they can enforce some policies in that since the use of 5, in contrast to ARTDroid, all ARTDroid, so that the new app’s sensitive be- the existing approaches based on emulated environ- haviors, such as sending SMS, can be restricted ments can not properly analyze the behavior of that by ARTDroid.
25 6 Android malware analysis. Some trick malware patches for Android. This system uses the DDI[DDI] • use a lot of dynamic analysis evading techniques. framework. DDI allows to replace arbitrary methods But in ARTDroid enforced sandbox, our hooking in Dalvik code with native function call using JNI. technique cannot be bypassed by current evading In [MRK14], Mulliner et. al. shown an automated techniques. Also, we can easily 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. 7 Related Work Frida[Fri], a dynamic code instrumentation toolkit, Xposed framework [Xpo] and Cydia substrate for An- Several approaches have 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 system components suck as zygote. Currently, bytecode. AppGuard[BGH+13] 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 attach 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 system 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 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 code is not patched, While these approaches are valuable and each of but new classes and native code are added to ensure them has its own advantages as well as disadvantages, that the instrumentation code is run first. Clearly, they have different significant down sides. This ap- such approaches are not effective if the code is obfus- proach is not feasible against apps that verify their cated and protected against static analysis and disas- integrity at runtime. This kind of defense (anti- sembly. Also note that the package signature of the tampering) is also used in benign apps as well. To instrumented applications are broken when they are be able to replace API-level calls with a secure wrap- patched statically. In comparison, our approach does per, bytecode rewriters need to identify desidered API not need to repack the app, our modifications are in- call-site within the target app. As mentioned in memory only and thus we do not break code signing. [HSD13],[ZAG+15], apps that use either Java reflec- Recent works proposed novel approaches that aim tion or dynamically code loading can bypass 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 Java methods can bypass this techniques approach that aims to sandbox apps by means of as 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 by 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 same ap- modified QEMU emulator). Enck et al. proposed proach to sandbox arbitrary Android apps. The ap- TaintDroid[EGH+14], an Android modified system to proach presented in both of these recent works, repre- detect privacy leak. StayDynA[ZAG+15] a system sent one of the most promising and interesing future for analyzing security of dynamic code loading in An- work direction. droid, uses a custom system image which 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, we present ARTDroid, a framework for Android malware. These families of approaches, which hooking virtual-methods under ART runtime. ART- are based on emulators, can be bypassed by emulation Droid supports the virtual-method hooking without detection techniques [PVA+14] [VC14]. A comparison any modifications to both Android system and app’s on Android sanbox has been published by Neuren et code. ARTDroid allows to analyze apps even if al. in [NVdVL+14]. they employ 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-party securities 3034811
26 7 ther Java reflection or JNI to invoke virtual-methods. [DDI] Dalvik dynamic instrumentation Moreover, ARTDroid can be used on any real devices framework. https://github.com/ with ART runtime once getting the root privilege. The crmulliner/ddi. Accessed: 2016-02- applications of ARTDroid include dynamic analysis 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 N Sheth. ing the android permission specification. Taintdroid: an information-flow track- In Proceedings of the 2012 ACM confer- ing system 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(2):5, [BBH+15] Michael Backes, Sven Bugiel, Christian 2014. Hammer, Oliver Schranz, and Philipp [Fri] Frida.re. https://frida.re. Accessed: von Styp-Rekowsky. Boxify: Full- 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 Vi- [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 Analysis 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 third-party security [SuS] Susi. https://github.com/ patches for android devices. In Pro- secure-software-engineering/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. computer 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, computer 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 comparison. arXiv xposed.info. Accessed: 2016-02-27. preprint arXiv:1410.7749, 2014. [XSA12] Rubin Xu, Hassen Sa¨ıdi,and Ross An- [PFB+14] 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 as 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 against in the security analysis of android appli- the virtual machine: hindering dynamic cations. In Proceedings of the 5th ACM analysis of android malware. In Proceed- 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+15] Yajin Zhou, Kunal Patel, Lei Wu, Zhi Eric Bodden. A machine-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 10th ACM 2014. Symposium on Information, Computer and Communications Security, pages [RCJ13] Vaibhav Rastogi, Yan Chen, and Xux- 19–30. ACM, 2015. ian Jiang. Droidchameleon: evaluating android anti-malware against 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 look into android appli- 2012. cations. In Proceedings of the 28th An-
28 9