Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.



Published on

  • Be the first to comment


  1. 1. DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis Lok Kwong Yan†‡ Heng Yin† † Syracuse University ‡ Air Force Research Laboratory Syracuse, New York, USA Rome, New York, USA {loyan, heyin}@syr.eduAbstract Malware analysis and exploit diagnosis on desktop systems is well researched. It is widely accepted thatThe prevalence of mobile platforms, the large market dynamic analysis is indispensable, because malware isshare of Android, plus the openness of the Android Mar- often heavily obfuscated to thwart static analysis. Fur-ket makes it a hot target for malware attacks. Once a mal- thermore, runtime information is often needed for exploitware sample has been identified, it is critical to quickly diagnosis. In particular, much work has leveraged virtu-reveal its malicious intent and inner workings. In this alization techniques, either whole-system software emu-paper we present DroidScope, an Android analysis plat- lation or hardware virtualization, to introspect and ana-form that continues the tradition of virtualization-based lyze illicit activities within the virtual machine [11, 15,malware analysis. Unlike current desktop malware anal- 18, 31, 33, 39, 37].ysis platforms, DroidScope reconstructs both the OS-level and Java-level semantics simultaneously and seam- The advantages of virtualization-based analysis ap-lessly. To facilitate custom analysis, DroidScope ex- proaches are two-fold: 1) as the analysis runs under-ports three tiered APIs that mirror the three levels of an neath the entire virtual machine, it is able to analyze evenAndroid device: hardware, OS and Dalvik Virtual Ma- the most privileged attacks in the kernel; and 2) as thechine. On top of DroidScope, we further developed sev- analysis is performed externally, it becomes very diffi-eral analysis tools to collect detailed native and Dalvik cult for an attack within the virtual machine to disruptinstruction traces, profile API-level activity, and track in- the analysis. The downside, however, is the loss of se-formation leakage through both the Java and native com- mantic contextual information when the analysis com-ponents using taint analysis. These tools have proven to ponent is moved out of the box. To reconstruct the se-be effective in analyzing real world malware samples and mantic knowledge, virtual machine introspection (VMI)incur reasonably low performance overheads. is needed to intercept certain kernel events and parse ker- nel data structures [16, 21, 24]. Based on this idea, sev-1 Introduction eral analysis platforms (such as Anubis [1], Ether [15], and TEMU [35]) have been implemented.Android is a popular mobile operating system that is in- Despite the fact that Android is based on Linux, itstalled in millions of devices and accounted for more is not straightforward to take the same desktop analy-than 50% of all smartphone sales in the third quarter of sis approach for Android malware. There are two lev-2011 [22]. The popularity of Android and the open na- els of semantic information that must be rebuilt. In theture of its application marketplace makes it a prime tar- lower level, Android is a Linux operating system whereget for attackers. Malware authors can freely upload ma- each Android application (or App in short) is encapsu-licious applications to the Android Market1 waiting for lated into a process. Within each App, a virtual machineunsuspecting users to download and install them. Ad- (known as the Dalvik Virtual Machine) provides a run-ditionally, numerous third-party alternative marketplaces time environment for the App’s Java components.make delivering malicious applications even easier. In- In essence, to enable the virtualization-based analysisdeed recent research has shown that malicious applica- approach for Android malware analysis, we need to re-tions exist in both the official and unofficial marketplaces construct semantic knowledge at two levels: 1) OS-levelwith a rate of 0.02% and 0.2% respectively [41]. semantics that understand the activities of the malware 1 TheAndroid Market has been superceded by the Android Apps process and its native components; and 2) Java-level se-Store in Google Play. mantics that comprehend the behaviors in the Java com- 1
  2. 2. ponents. Ideally, to capture the interactions between Javaand native components, we need a unified analysis plat- Java Java Component Componentform that can simultaneously rebuild these two semanticviews and seamlessly bind these two views with the exe- Java Libraries Java Librariescution context. System Java Libraries Zygote Services With this goal in mind, we designed and implemented Dalvik VMa new analysis platform, DroidScope, for Android mal- JNI Systemware analysis. DroidScope is built on top of QEMU (a Native System System Libraries Component Libraries LibrariesCPU emulator [3]) and is able to reconstruct the OS-level and Java-level semantic views completely from theoutside. Enriched with the semantic knowledge, Droid- Linux KernelScope further provides a set of APIs to help analystsimplement custom analysis plugins. To demonstrate the Figure 1: Overview of Android Systemcapability of DroidScope, we have implemented severaltools, including native instruction tracer and Dalvik in- and analyze two real-world malware samples: Droid-struction tracer to obtain detailed instruction traces, API KungFu and DroidDream.tracer to log an App’s interactions with the Android sys-tem, and taint tracker to analyze information leakage. 2 Background and Motivation We evaluated the performance impacts of these tools In this section, we give an overview of the Android sys-on 12 different benchmarks and found that the instru- tem and existing Android malware analysis techniques tomentation overhead is reasonably low and taint analysis motivate our new analysis platform.performance (from 11 to 34 times slowdown) is compa-rable with other taint analysis systems. We further eval- 2.1 Android System Overviewuated the capability of these tools using two real worldAndroid malware samples: DroidKungFu and Droid- Figure 1 illustrates the architecture of the Android sys-Dream. They both have Java and native components as tem from the perspective of a system programmer. Atwell as payloads that try to exploit known vulnerabili- the lowest level, the Android system uses a customizedties. We were able to analyze their behavior without any Linux kernel to manage various system resources andchanges to the virtual Android device, and obtain valu- hardware devices. System services, native applicationsable insights. and Apps run as Linux processes. In particular, Zygote is the parent process for all Android Apps. Each App In summary, this paper makes the following contribu- is assigned its own unique user ID (uid) at installationtions: time and group IDs (gids) corresponding to requested• We describe two-level virtual machine introspection to permissions. These uids and gids are used to control rebuild the Linux and Dalvik contexts of virtual An- access to system resources (i.e, network and file system) droid devices. Dalvik introspection also includes a like on a normal Linux system. technique to dynamically disable Dalvik Just-In-Time All Apps can contain both Java and native compo- compilation. nents. Native components are simply shared libraries• We present DroidScope, a new emulation based An- that are dynamically loaded at runtime. The Dalvik vir- droid malware analysis engine that can be used to an- tual machine (DVM), a shared library named, alyze the Java and native components of Android Ap- is then used to provide a Java-level abstraction for the plications. DroidScope exposes an event-based anal- App’s Java components. At the same time, the Java Na- ysis interface with three sets of APIs that correspond tive Interface (JNI) is used to facilitate communications to the three different abstraction levels of an Android between the native and Java sides. Device, hardware, Linux and Dalvik. To create a Java component, an App developer first• We developed four analysis tools on DroidScope. The implements it in Java, compiles it into Java bytecode, and native instruction tracer and Dalvik instruction tracer then converts it into Dalvik bytecode. The result is a provide detailed accounts of the analysis sample’s exe- Dalvik executable called a dex file. The developer can cution, while the API tracer provides a high level view also compile native code into shared libraries, .so files, of how the sample interacts with the rest of the system. with JNI support. The dex file, the shared libraries and The taint tracker implements dynamic taint analysis any other resources, including the AndroidManifest.xml on native instructions but is capable of tracking taint file that describes the App, are packaged together into an through Java Objects with the help of the Dalvik view apk file for distribution. reconstruction. These tools were used to instrument For instance, DroidKungFu is a malicious puzzle 2
  3. 3. game found in alternative marketplaces [25]. Its Java APIcomponent exfiltrates sensitive information and awaits Java Java Tracer Component Component Instrumentation Interfacecommands from the bot master. Its native component is Java Libraries Java Librariesused as a shell to execute those commands and it also in- System Java Libraries Java-level Native Zygote Services Viewcludes three resource files that are encrypted exploits tar- Dalvik VM Insn. Tracergeting known vulnerabilities, adb setuid exhaustion and JNI System Native Systemudev [12], in certain versions of Android. Component System Libraries Libraries Dalvik Libraries Insn. Tracer For security analysts, once a new Android malware OS-levelinstance has been identified, it is critical to quickly re- Linux Kernel View Taintveal its malicious functionality and understand its inner- Trackerworkings. This often involves both static and dynamic DroidScopeanalysis. Figure 2: DroidScope Overview2.2 Android Malware AnalysisLike malware analysis on the desktop environment, An-droid malware analysis techniques can fall into two cat- Virtualization based analysis has proven effectiveegories: static and dynamic. For static analysis, the sam- against evasion, because all of the analysis components are out of the box and are more privileged than the run-ple’s dex file can be analyzed by itself or it can be disas-sembled and further decompiled into Java using tools like time environment being analyzed, including the mal-dex2jar and ded [13]. Standard static program analysis ware. Based on dynamic binary translation and hard-techniques (such as control-flow analysis and data-flow ware virtualization techniques, several analysis plat-analysis) can then be performed. As static analysis can forms [1, 15, 38] have been built for analyzing desktopgive a complete picture, researchers have demonstrated malware. These platforms are able to bridge the seman- tic gap between the hardware-level view from the virtualthis approach to be very effective in many cases [20]. machine monitor and the OS-level view within the vir- However, static analysis is known to be vulnerable tual machine using virtual machine introspection tech-to code obfuscation techniques, which are common- niques [16, 21, 24].place for desktop malware and are expected for An-droid malware. In fact, the Android SDK includes a However, these tools cannot be immediately used fortool named Proguard [34] for obfuscating Apps. An- Android malware analysis. Android has two levels ofdroid malware may also generate or decrypt native com- semantic views, OS and Java, that need to be recon-ponents or Dalvik bytecode at runtime. Indeed, Droid- structed versus the one for desktop malware. To enableKungFu dynamically decrypts the exploit payloads and virtualization-based analysis for Android malware, weexecutes them to root the device. Moreover, researchers need a unified analysis platform that reconstructs thesehave demonstrated that bytecode randomization tech- two levels of views simultaneously and seamlessly bindsniques can be used to completely hide the internal logic these two views such that interactions between Java com-of a Dalvik bytecode program [14]. Static analysis also ponents and native components can be monitored and an-falls short for exploit diagnosis, because a vulnerable alyzed.runtime execution environment is needed to observe andanalyze an exploit attack and pinpoint the vulnerability. 3 Architecture Complementary to static analysis, dynamic analysis is DroidScope’s architecture is depicted in Figure 2. Theimmune to code obfuscation and is able to see the mali- entire Android system (including the malware) runs oncious behavior on an actual execution path. Its downside top of an emulator, and the analysis is completely per-is lack of code coverage, although it can be ameliorated formed from the outside. By integrating the changes intoby exploiting multiple execution paths [6, 9, 31]. The the emulator, the Android system remains unchangedAndroid SDK includes a set of tools, such as adb and and different virtual devices can be loaded. To ensure thelogcat, to help developers debug their Apps. With best compatibility with virtual Android devices, we ex-JDWP (Java Debug Wire Protocol) support, the debug- tended the QEMU [3] based Android emulator that shipsger can even exist outside of the device. However, just with the Android SDK. This is done in three aspects: 1)like how desktop malware detects and disables debug- we introspect the guest Android system and reconstructgers, malicious Android Apps can also detect the pres- OS-level and Java-level views simultaneously; 2) as aence of these tools, and then either evade or disable the key binary analysis technique, we implement dynamicanalysis. The fundamental reason is that the debugging taint analysis; and 3) we provide an analysis interface tocomponents and malware reside in the same execution help analysts build custom analysis tools. Furthermore,environment with the same privileges. we made similar changes to a different version of QEMU 3
  4. 4. to enable x86 support. enable basic instrumentation support. To demonstrate the capabilities of DroidScope, we Basic Instrumentation QEMU is an efficient CPU em-have developed several analysis tools on it. The API ulator that uses dynamic binary translation. The normaltracer monitors the malware’s activities at the API level execution flow in QEMU is as follows: 1) a basic blockto reason about how the malware interacts with the An- of guest instructions is disassembled and translated intodroid runtime environment. This tool monitors how the an intermediate representation called TCG (Tiny Codemalware’s Java components communicate with the An- Generator); 2) the TCG code block is then compileddroid Java framework, how the native components inter- down to a block of host instructions and stored in aact with the Linux system, and how Java components and code cache; and 3) control jumps into the translated codenative components communicate through the JNI inter- block and guest execution begins. Subsequent executionface. of the same guest basic blocks will skip the translation The native instruction tracer and Dalvik instruction phase and directly jump into the translated code block intracer look into how a malicious App behaves internally the recording detailed instruction traces. The Dalvik in- To perform analysis, we need to instrument the trans-struction tracer records Dalvik bytecode instructions for lated code blocks. More specifically, we insert extrathe malware’s Java components and the native instruc- TCG instructions during the code translation phase, suchtion tracer records machine-level instructions for the na- that this extra analysis code is executed in the execu-tive components (if they exist). tion phase. For example. in order to monitor context The taint tracker observes how the malware obtains switches, we insert several TCG instructions to call aand leaks sensitive information (e.g., GPS location, IMEI helper function whenever the translation table registersand IMSI) by leveraging the taint analysis component (system control co-processor c2 base0 and c2 base1 inin DroidScope. Dynamic taint analysis has been pro- QEMU) are written to.posed as a key technique for analyzing desktop malware With basic instrumentation support, we extract the fol-particularly with respect to information leakage behav- lowing OS-level semantic knowledge: system calls, run-ior [18, 39]. It is worth noting that DroidScope performs ning processes, including threads, and the memory map.dynamic taint analysis at the machine code level. Withsemantic knowledge at both OS and Java levels, Droid- System Calls A user-level process has to make systemScope is able to detect information leakage in Java com- calls to access various system resources and thus obtain-ponents, native components, or even collusive Java and ing its system call behavior is essential for understandingnative components. malicious Apps. On the ARM architecture, the service We have implemented DroidScope to support both zero instruction svc #0 (also known as swi #0) is used toARM and x86 Android systems. Due to the fact that the make system calls with the system call number in registerARM architecture is most widely used for today’s mo- R7. This is similar to x86 where the int 0x80 instructionbile platforms, we focus our discussion on ARM support, is used to transition into privileged mode and the systemwhich is also more extensively tested. call number is passed through the eax register. To obtain the system call information, we instrument4 Semantic View Reconstruction these special instructions, i.e. insert the additional TCGWe discuss our methodology for rebuilding the two lev- instructions, to call a callback function that retrieves ad-els of semantic views in this section. We first discuss how ditional information from memory. For important sys-information about processes, threads, memory mappings tem calls (e.g. open, close, read, write, connect, etc.), theand system calls are rebuilt at runtime. This constitutes system call parameters and return values are retrieved asthe OS-level view. Then from the memory mapping, we well. As a result, we are able to understand how a user-locate the Dalvik Virtual Machine and further rebuild the level process accesses the file system and the network,Java or Dalvik-level view. communicates with another process, and so on. Processes and Threads From the operating system per-4.1 Reconstructing the OS-level View spective, Android Apps are user-level processes. There-The OS-level view is essential for analyzing native com- fore, it is important to know what processes are activeponents. It also serves a basis for obtaining the Java-level and which one is currently running. In Linux kernel 2.6,view for analyzing Java components. The basic tech- the version used in Gingerbread (Android 2.3), the basicniques for reconstructing the OS-level view have been executable unit is the task which is represented by thewell studied for the x86 architecture and are generally task struct structure. A list of active tasks is main-known as virtual machine introspection [16, 21, 24]. We tained in a task struct list which is pointed to byemploy similar techniques in DroidScope. We begin by init task. To make this information readily availablefirst describing our changes to the Android emulator to to analysis tools, DroidScope maintains a shadow task 4
  5. 5. list with select information about each task. ldrh r7, [r4, #2]! Opcode * 0x40 and ip, r7, #255 To distinguish between a thread and a process, we add pc, r8, ip, lsl #6 push{r4,r5,r6,r7,r8,r9,sl,fp,lr}gather a task’s process identifier pid as well as its thread 0x0 rIBase:dvmAsmInstructionStart sub sp, sp, #4 nop .group identifier tgid. The pgd (the page global di- 0x40 . moverectory that specifies the memory space of a process), 0x80 nop move/from16 nopuid (the unique user ID associated with each App), and nopthe process’ name are also maintained as part of the lsr r3, r7, #12 lsr r9, r7, #8shadow task list. Additionally, our experience has shown ldr r0, [r5, r3, lsl #2] and r9, r9, #15that malware often escalates its privileges or spawns 0x800 cmp r0, #0child process(es) to perform additional duties. Thus, instance-of . 0x840 . array-lengthour shadow task list also contains the task’s credentials, cmp r0, r1 beq<dvmAsmSisterStart+0xe4>i.e. uid, gid, euid, egid as well as the process’ b<dvmAsmSisterStart+0xd0>parent pid. Special attention is paid to a task’s name since the Figure 3: Dalvik Opcode Emulation Layout in mterpcomm field in task struct can only store up to 15characters. This is often insufficient to store the App’sfull name, making it difficult to pinpoint a specific App. 4.2 Reconstructing the Dalvik ViewTo address this issue, we also obtain the complete appli-cation name from the command line cmdline, which With the OS-level view and knowledge of how the DVMis pointed to by the mm struct structure pointed to by operates internally, we are able to reconstruct the Java ortask struct. Note that the command line is located Dalvik view, including Dalvik instructions, the currentin user-space memory, which is not shared like kernel- machine state, and Java objects. Some of the details arespace memory where all the other structures and fields presented in this section.reside. To retrieve it, we must walk the task’s page table Dalvik Instructions The DVM’s main task is to exe-to translate the virtual address into a physical one and cute Dalvik bytecode instructions by translating themthen read it based on the physical address. into corresponding executable machine code. In Ginger- According to the design of the Linux kernel, the bread and thereafter, it does so in two ways: interpreta-task struct for the current process can be easily tion and Just-In-Time compilation (JIT) [8].located. The current thread info structure is al- The interpreter, named mterp, uses an offset-ways located at the (stack pointer & 0x1FFF), and addressing method to map Dalvik opcodes to machinethread info has a pointer pointing to the current code blocks as shown in Figure 3. Each opcode has 64task struct. We iterate through all active tasks by bytes of memory to store the corresponding emulationfollowing the doubly linked task struct list. We code, and any emulation code that does not fit within thealso update our shadow list whenever the base informa- 64 bytes use an overflow area, dvmAsmSisterStart,tion changes. We do this by monitoring four system calls (see instance-of in Figure 3). This design simpli-sys fork, sys execve, sys clone and sys prctl, and updat- fies the emulation of Dalvik instructions. mterp simplying the shadow task list when they return. calculates the offset, opcode ∗ 64, and jumps to the cor- responding emulation block. This design also simplifies the reverse conversion fromMemory Map The Dalvik Virtual Machine, libraries native to Dalvik instructions as well: when the pro-and dex files are all memory mapped and we rely on the gram counter (R15) points to any of these code re-knowledge of their memory addresses for introspection. gions, we are sure that the DVM is interpreting a byte-Therefore, it is important to understand the memory map code instruction. Furthermore, it is trivial to determineof an App. This is especially true for the latest version of the opcode of the currently executing Dalvik instruc-Android, Ice Cream Sandwich, since address space lay- tion. In DroidScope we first identify the virtual ad-out randomization is enabled by default. dress of rIBase, the beginning of the emulation code re- To obtain the memory map of a process, we iterate gion, and then calculate the opcode using the formulathrough the process’ list of virtual memory areas by fol- (R15 − rIBase)/64. rIBase is dynamically calculatedlowing the mmap pointer in the mm struct pointed to as the virtual address of (obtained from theby the task struct. To ensure the freshness of the shadow memory map in the OS-level view) plus the off-memory map information, we intercept the sys mmap2 set of dvmAsmInstructionStart (a debug sym-system call and update the shadow memory map when it bol). If the debug symbol is not available, we can identifyreturns. it using the signature for Dalvik opcode number 0 (nop). 5
  6. 6. Update V4 (In 2) Stack grows R0: Integer Program Counter(PC) R1: V3 (In 1) String R2: V2 (In 0) “this” R3: V1 R4: rPC V0 R5: rFP R6: rGLUE Is Code in JIT Yes Execute JIT R7: rINST InterpState code cache? code block R8: rIBASE { R9: … R10: Jvalue retval; InterpState No R11: ... R12: Thread* self; Request JIT R13: … Decrement block Yes Is Counter 0? Compilation for R14: mterp } Counter Code block and R15: PC+4 reset Counter No framework.jar@ classes.dex Emulate Code Using mterp low address;I)I: Figure 4: High Level Flowchart of mterp and JIT Figure 5: Dalvik Virtual Machine State The Just-In-Time compiler was introduced to improve code.performance by compiling heavily used, or hot, Dalvik The dvmGetCodeAddr function is used to deter-instruction traces (consisting of multiple code blocks) di- mine whether a translated trace exists. It returns NULLrectly into native machine code. While each translation if a trace does not exist and the address of the corre-trace has a single entry point, there can be multiple ex- sponding trace if it does. Thus, to selectively disableits known as chaining cells. These chaining cells either JIT, we instrument the DVM and set the return value ofchain to other translation traces or to default entry points dvmGetCodeAddr to NULL for any translated trace weof the mterp interpreter. Overall, JIT provides an excel- wish to disable. To show that our change to the virtuallent performance boost for programs that contain many machine state does not have any ill side-effects, we makehot code regions, although it makes fine-grained instru- the following arguments. First, if the original returnmentation more difficult. This is because JIT performs value was NULL then our change will not have any sideoptimization on one or more Dalvik code blocks and thus effects. Second, if the return value was a valid address,blurs the Dalvik instruction boundaries. then by setting it to NULL, the profile counter is decre- An easy solution would be to completely disable JIT mented and if 0, i.e. the code region deemed hot again,at build time, but it could incur a heavy performance another compilation request is issued for the block. Inpenalty and more importantly it require changes to the this case, the code will be recompiled taking up space invirtual device, which we want to avoid. Considering the code-cache. This can be prevented by not instrument-that we are often only interested in a particular section ing the dvmGetCodeAddr call from the compiler.of Dalvik bytecode (such as the main program but not In addition to preventing the translated trace from be-the rest of system libraries), we choose to selectively dis- ing executed, setting the value to NULL also prevents itable JIT at runtime. Analysis plugins can specify the from being chained to other traces. This is the desiredcode regions for which to disable JIT and as a result only behavior. For the special case where a translation tracethe Dalvik blocks being analyzed incur the performance has already been chained and thus dvmGetCodeAddrpenalty. All other regions and Apps still benefit from is not called, we flush the JIT cache whenever the dis-JIT. abled JIT’ed code regions change. This is done by mark- ing the JIT cache as full during the next garbage collec- Figure 4 shows the general flow of the DVM. When tion event, which leads to a cache flush. While this is nota basic block of Dalvik bytecode needs to be emulated, a perfect solution, we have found it to be sufficient.the Dalvik program counter is updated to reflect the newblock’s address. That address is then checked against In all cases, the only side effect is wasted CPU cy-the translation cache to determine if a translated trace for cles due to compilation; the execution logic is unaffected.the block already exists. If it does, the trace is executed. Therefore, the side effects are deemed inconsequential.If it does not then the profiler will decrement a counter DVM State Figure 5 illustrates how the DVM main-for that block. When this counter reaches 0, the block tains the virtual machine state. When mterp is emulatingis considered hot and a JIT compilation requested. To Dalvik instructions, the ARM registers R4 through R8prevent thrashing, the counter is reset to a higher value store the current DVM execution context. More specifi-and emulation using mterp commences. As can be seen cally, R4 is the Dalvik program counter, pointing to thein the flow chart, as long as the requested code is not in current Dalvik instruction. R5 is the Dalvik stack framethe code cache, then mterp will be used to emulate the pointer, pointing to the beginning of the current stack 6
  7. 7. struct Object { struct StringObject { struct ArrayObject { ClassObject* clazz; Object obj; Object obj; has a pointer to the ClassObject that it is an instance u4 lock; u4 instanceData[1]; u4 length; }; }; u8 contents[1]; of plus a tail accumulator array for storing all member }; fields. Dalvik defines three types of Objects, DataOb- java.lang.String ClassObject ject, StringObject and ArrayObject that are all pointed to V3 (In 1) char[] ClassObject by generic Object*s. The correct interpretation of any Object* fully depends on the ClassObject that it points ClassObject* ClassObject* lock lock to. We use a simple String (”Hello”) to illustrate the instanceData ArrayObject* align_pad hashcode 0x0048 H, 0x0045 e interpretation process. Figure 6 depicts the different contents offset (0) 0x006c l, 0x006c l count (5) 0x006f o, 0x0000 data structures involved as well as the struct defini- 0x0000, 0x0000 tions on top. To access the String, we first follow the reference in the virtual register V3. Since Java ref- Figure 6: String Object Example erences are simply Object*s, V3 points to an Ob- ject. To determine the type of the object, we followframe. R6 points to the InterpState data structure, the first 4 bytes to the ClassObject structure. This Clas-called glue. R7 contains the first two bytes of the cur- sObject instance describes the java.lang.Stringrent Dalvik instruction, including the opcode. Finally R8 class. Internally, Dalvik does not store the String datastores the base address of the mterp emulation code for inside the StringObject and instead use a char[].the current DVM instruction. In x86, edx, esi, edi Consequently, instanceData[0] is used to storeand ebx are used to store the program counter, frame the reference to the corresponding char[] object andpointer, mterp base address and the first two bytes of the instanceData[3] is used to store the number ofinstruction respectively. The glue object can be found characters in the String, 5 in this case.on the stack at a predefined offset. We then obtain the String’s data by following instanceData[0] to the character array. Once again Dalvik virtual registers are 32 bits and are stored in we must follow the Object* within the new object toreverse order on the stack. They are referenced relative correctly interpret it as an ArrayObject. Note that sinceto the frame pointer R5. Hence, the virtual register V0 ARM EABI requires all arrays to be aligned to its ele-is located at the top of the stack (pointed to by the ARM ment size and u8 is 8 bytes in length, we inserted an im-register R5,) and the virtual register V1 sits on top of V0 plicit 4 byte align pad into the ArrayObject to ensurein memory, and so forth. All other Dalvik state infor- that the contents array is properly aligned. Given themation (such as return value and thread information) is length of the String from the StringObject and the cor-obtained through glue pointed to by R6. roborating length in the ArrayObject, the ”Hello” String After understanding how DVM state is maintained, we is found in the contents array encoded in UTF-16.are able to reconstruct the state from the native machinecode execution. That is, by examining the ARM registers 4.3 Symbol Informationand relative data structures, we can get the current DVMprogram counter, frame pointer, all virtual registers, and Symbols (such as function name, class name, field name,so on. etc.) provide valuable information for human analysts to understand program execution. Thus, DroidScope seeksJava Objects Java Objects are described using two data to make the symbols readily available by maintaining astructures. Firstly, ClassObject describes a class type and symbol database. For portability and ASLR support, wecontains important information about that class: the class use one database of offsets to symbols per module. Atname, where it is defined in a dex file, the size of the ob- runtime, finding a symbol by a virtual address requiresject, the methods, and the location of the member fields first identifying the containing module using the shadowwithin the object instances. To standardize class repre- memory map, and then calculating the offset to searchsentations, Dalvik creates a ClassObject for each defined the database.class type and implicit class type, e.g. arrays. For exam- Native library symbols are retrieved statically throughple there is a ClassObject that describes a char[] which objdump and are usually limited to Android librariesis used by java.lang.String. Moreover, if the App since malware libraries are often stripped of all symbolhas a two dimensional array, e.g. String[][], then information. On the other hand, Dalvik or Java symbolsDalvik creates a ClassObject to describe the String[] are retrieved dynamically and static symbol informationand another to describe the array of the previously de- through dexdump is used as a fallback. This has the ad-scribed String[] class. vantage of ensuring the best symbol coverage for opti- Secondly, as an abstract type, Object describes a run- mized dex files and even dynamically generated Dalviktime object instance, i.e. member fields. Each Object bytecode. 7
  8. 8. NativeAPI LinuxAPI DalvikAPI name), and end, and memory map update. One can also instruction begin/end context switch Dalvik instruction begin query symbols, obtain the task list, and get the current register read/write system call method begin Events memory read/write task begin/end execution context (e.g., current process and thread). At block begin/end task updated the Dalvik level, one can instrument at the granularity memory map updated of Dalvik instructions and methods. One can query the memory read/write query symbol database query symbol database Dalvik symbols, parse and interpret Java objects, read Query & Set memory r/w with pgd get current context interpret Java object register read/write get task list get/set DVM state and modify DVM state, and selectively disable JIT for taint set/check taint set/check objects certain memory regions. Through the Dalvik-view, one disable JIT can also set and check taint in Java Objects as well. 5.2 Instrumentation Optimization Table 1: Summary of DroidScope APIs A general guideline for performance optimization in dy- namic binary translation is to shift computation from the We rely on the data structures of DVM to retrieve sym- execution phase to the translation phase. For instance, ifbols at runtime. For example, the Method structure con- we need to instrument a function call at address x usingtains two pointers of interest. insns points to the start basic blocks, then we should insert the instrumentationof the method’s bytecode, the symbol address, and name code for the block at x when it is being translated insteadpoints to the name. Conveniently, the glue structure of instrumenting every basic block and look for x at exe-pointed to by R6 has a field method that points to the cution time.Method structure for the currently executing method. We follow this guideline in DroidScope. Conse- There are times when this procedure fails though, e.g. quently, our instrumentation logic becomes more com-if the corresponding page of the dex file has not been plex. When registering for an event callback, one canloaded into memory yet. In these cases, we first try to specify a specific location (such as a function entry) or alook up the information in a local copy of the correspond- memory range (to trace instructions or functions within aing dex file, and if that fails as well, use the static symbol particular module). Therefore, our instrumentation logicinformation from dexdump. DroidScope uses this same supports single value comparisons and range checks forbasic method of relying on the DVM’s data structures to controlling when and where event callbacks are insertedretrive class and field names as well. during the translation phase. The instrumentation logic is also dynamic, because we5 Interface & Plugins often want to register and unregister a callback at execu-DroidScope exports an event based interface for instru- tion time. For example, when the virtual device starts,mentation. We describe the general layout of the APIs, only the OS-view instrumentation is enabled so the An-present an example of how tools are implemented, and droid system can start quickly as usual. When we startfinally describe available tools in this section. analyzing an App, instrumentation code is inserted to reconstruct the Dalvik view and to perform analysis as5.1 APIs requested by the plugin. When instrumenting a func-DroidScope defines a set of APIs to facilitate custom tion return, the return address will be captured from theanalysis tool development. The APIs provide instrumen- link register R14 at the function entry during execution,tation on different levels: native, OS and Dalvik, to mir- and a callback is registered at the return address. Af-ror the context levels of a real Android device. At each ter the function has returned, this callback is removed.level, the analysis tool can register callbacks for different Then when the analysis has finished, other instrumenta-events, and also query or set various kinds of information tion code is removed as well. To maintain consistency,and controls. Table 1 summarizes these APIs. DroidScope invalidates the corresponding basic blocks At the native level, one can register callbacks for in- in the translated code cache whenever necessary so thatstruction start and end, basic block start and end, mem- the new instrumentation logic can be enforced. Hence,ory read and write, and register read and write. One can the instrumentation logic in DroidScope is complex andalso read and write memory and register content. As dynamic. These details are hidden from the analysis plu-taint analysis is implemented at the machine code level, can also set and check taint in memory and regis-ters. Currently, the taint propagation engine only sup- 5.3 Sample Pluginports copy and arithmetic operations, control flow depen- Figure 7 presents sample code for implementing a simpledencies are not tracked. Dalvik instruction tracer. The init function at L19 will At the OS level, one can register callbacks for context be invoked once this plugin is loaded in DroidScope. Inswitch, system call, task start, update (such as process init, it specifies which program to analyze by calling the 8
  9. 9.  1. void opcode_callback(uint32_t opcode) {  2.   printf("[%x] %sn", GET_RPC, opcodeToStr(opcode)); of the other bytecodes to improve performance. To log  3. } library calls from the App’s native components, we reg-  4.  5. void module_callback(int pid) { ister for the block end event for blocks that are located in  6.   if (bInitialized || (getIBase(pid) == 0))  7.     return; the App’s native components. When the callback for the  8.  9.   gva_t startAddr = 0, endAddr = 0xFFFFFFFF; block end event is invoked, we check if the next block is 10. within the Apps native components or not. If not, we log 11.   addDisableJITRange(pid, startAddr, endAddr); 12.   disableJITInit(getGetCodeAddrAddress(pid)); this event. 13.   addMterpOpcodesRange(pid, startAddr, endAddr); 14.   dalvikMterpInit(getIBase(pid)); Native instruction tracer registers ARM or x86 in- 15.   registerDalvikInsnBeginCb(&opcode_callback); 16.   bInitialized = 1; struction callbacks to gather information about each in- 17. } struction including the raw instruction, its operands (reg- 18. 19. void _init() { ister and memory) and their values. 20.   setTargetByName("com.andhuhu.fengyinchuanshuo"); 21.   registerTargetModulesUpdatedCb(&module_callback); Dalvik instruction tracer follows the basic logic of 22. } the above example and logs the decoded instruction to Figure 7: Sample code for Dalvik Instruction Tracer a file in the dexdump format. The operands, their values and all available symbol information, e.g. class, field andsetTargetByName function. It also registers a callback method names, are logged as well.module callback to be invoked when module informa- Taint tracker utilizes the dynamic taint analysis APIstion is updated. module callback will check if the DVM to analyze information leakage in an Android App. Itis loaded and if so, disable JIT for the entire memory specifies sensitive information sources (such as IMEI,space (L9 and L11.) It also registers a callback, op- IMSI, and contact information) as tainted and keeps trackcode callback, for Dalvik instructions. When invoked, of taint propagation at the machine code level until theyopcode callback prints the opcode information. reach sinks, e.g. sys write and sys send. With the OS This sample code will print all Dalvik instructions for and Dalvik views, it further creates a graphical represen-the specified App, including the main program and all tation to visualize how sensitive information has leakedthe libraries. If we are only interested in the execu- out. To construct the graph, we first identify function andtion of the main program, we can add a function call method boundaries. Whenever taint is propagated, welike getModAddr(”example@classes.dex”, &startAddr, add a node to represent the currently executing function&endAddr) at L10. This function locates the dex file in or method and nodes for the tainted memory locations.the shadow memory map and stores its start and end ad- Since methods operate on Java Objects, we further try todresses in the appropriate variables. The rest of the code identify the containing Object and create a node for it in-can be left untouched. stead of the simple memory location. Currently, we only do this check against the method’s input parameters and5.4 Analysis Plugins the current Object, e.g. ”this”. Further improvements areTo demonstrate the capability of DroidScope for analyz- left as future Android malware, we have implemented four analy- To identify method boundaries, we look for match-sis plugins: API tracer, native instruction tracer, Dalvik ing invoke* or execute* and move-result* Dalvik instruc-instruction tracer, and taint tracker. tions. We do not rely on the return* instructions since API tracer monitors how an App (including Java and they are executed in the invokee context, which might notnative components) interacts with the rest of the sys- be instrumented, e.g. inside an API. Since there are mul-tem through system and library calls. We first log all tiple ways for native code to call and return from func-of the App’s system calls by registering for system call tions plus malicious code is known to jump into the mid-events. We then build a whitelist of the virtual device’s dle of functions, we do not rely on native instructionsbuilt-in native and Java libraries. As modules are loaded to determine function boundaries. Instead, we treat theinto memory, any library not in the whitelist is marked nearest symbol that is less than or equal to the jump tar-for analysis. We instrument the invoke* and execute* get in the symbol database as the function.Dalvik bytecodes to identify and log method invoca-tions, including those of the sample. The log contains 6 Evaluationthe currently executing Java thread, the calling address, We evaluated DroidScope with respect to efficiency andthe method being invoked as well as a dump of its in- capability. To evaluate efficiency, we used 7 benchmarkput parameters. Since Java Strings are heavily used, we Apps from the official Android Market: AnTuTu Bench-try to convert all Strings into native strings before log- mark (ABenchMark) by AnTuTu, CaffeineMark by Raviging them. We then instrument the move-result* byte- Reddy, CF-Bench by Chainfire, Mobile processor bench-code instructions to detect when system methods return mark (Multicore) by Andrei Karpushonak, Benchmarkand gather the return values. We do not instrument any by Softweg, and Linpack by GreeneComputing. We then 9
  10. 10. Percent of Baseline on the default Android emulator without any instrumen- 0% 20% 40% 60% 80% 100% 120% tation. Since DroidScope selectively disables JIT on the Apps, we also obtained a NOJIT baseline with JIT com- Linpack/Multithread pletely disabled at build time. The performance results Linpack/Singlethread are summarized in the bar chart in Figure 8. Each tool is associated with a set of bars that shows its benchmark Softweg/Memory results (y-axis) relative to the baseline as a percentage. The ARM Instruction Tracer results are excluded as they Softweg/Graphics are similar to the taint tracker results. Please note that the benchmarks are not perfect repre- Softweg/CPU sentations of performance as evidenced by the > 100% results. For example, in CPUBenchmark the standard de- Multicore (ms) viation, σ , for Baseline, Dalvik tracer and Context Only is only 1%. This means that the results are consistent for CPUBench (ms) each plugin, but might not be across plugins. Further- more, we removed the Softweg filesystem benchmarking CFBench/Overall results due to high variability, σ > 27%. CFBench/Java We can see from Figure 8 that the overhead (Context Only) of reconstructing the OS-level view CFBench/Native is very small, up to 7% degradation. The taint tracker has the worst performance as expected, because it reg- CaffieneMark isters for instruction level events. The taint tracker in- curs 11x to 34x slowdown, which is comparable to other ABenchMark taint analysis tools [10, 39] on the x86 architecture. A 0% 20% 40% 60% 80% 100% 120% special case is seen in the Dalvik instruction tracer re- Percent of Baseline sult for CaffeineMark. This result is attributed to the fact NOJIT Baseline Context Only API Tracer that the tracer dynamically retrieves symbol information Dalvik Taint Tracker Instruction from guest memory for logging. Tracer The benefits of dynamically disabling JIT is evident in some Java based benchmarks such as Linpack, CF- Figure 8: Benchmark Results Bench/Java and CaffeineMark. For those benchmarks, the API tracer’s performance is greater than that of the NOJIT Baseline, despite the fact that instrumentation isran the benchmarks while using the different automatic taking place. This difference is due to Java libraries, suchanalysis tools described above on the benchmarks them- as String methods, still benefiting from JIT in the APIselves. The results are presented in Section 6.1. To tracer.evaluate capability, we analyzed two real world Androidmalware samples: DroidKungFu and DroidDream in de- 6.2 Analysis of DroidKongFutail, which will be presented in Sections 6.2 and 6.3. The DroidKungFu malware contains three components.These samples were obtained from the Android Malware First, the core logic is implemented in Java and is con-Genome project [40]. tained within the package.Experimental Setup All experiments were conducted This is the main target of our investigation. Second areon an Acer 4830TG with a Core i5 @ 2.40GHz and 3GB the exploit binaries which are encrypted in the apk, de-of RAM running Xubuntu 11.10. The Android guest is crypted by the Java component and then subsequentlya Gingerbread build configured as ”user-eng” for ARM executed. Third is a native library that is used as a shell.with the Linux 2.6.29 kernel and uses the QEMU default It contains JNI exported functions that can run shell com-memory size of 96 MB. No changes were made to the mands and is the main interface for command and con-Android source. trol. Unfortunately the command and control server was unavailable at the time of our test and thus we did not6.1 Performance analyze this feature.To measure the performance impact of instrumentation, Discovering the Internal Logic We began our investi-we took the analysis tools and targeted the benchmark gation by running the API tracer on the sample and an-Apps while the Apps performed their tests. This was re- alyzing the log. We first looked for system calls of in-peated 5 times. As the baseline, we ran these benchmarks terest and found a sys open for a file named “gjsvro”. 10
  11. 11. getPermission { getDeviceId() if checkPermission() then doSearchReport(); return if !isVersion221() then String @ 0x40524e80 if getPermission1() then return “123456789012345” if exists("bin/su" or "xbin/su") then getPermission2(); return UrlEncodedFormEntity.<init> if !isVersion221() then getPermission3(); return } String @ 0x4056a448 “imei=123456789012345&ostype=...” Figure 9: getPermission Pseudocode AbstractHttpClient.execute()There was also a subsequent sys write to the file from byte[ ] @ 405967c0 / void* @ 405967d0a byte array. We later found that this array is actu- “POST /search/sayhi.php HTTP/1.1...”ally part of a Java ArrayObject which was populatedby the Utils.decrypt method, which is part of Droid- sys_write(34, 0x405967d0, 397)KungFu. Since decrypt takes a byte array as the param- Figure 10: Taint Graph for DroidKungFueter, we were able to search backwards and identify thatthis particular array was read from an asset inside theApp’s package file called ”gjsvro”. It means that dur- Java and native components, our logs show that the li-ing execution, DroidKungFu decrypts an asset from its brary then calls sys vfork and sys execve to execute thepackage and generates the ”gjsvro” file. We then found commands. This indicates that getPermission3 was try-that DroidKungFu called Runtime.exec with parameters ing to run both “udev” exploit and “rage against the cage”“chmod 4755” and the name of the file, making the file (ratc) exploits.executable and setting the setuid bit. After that, it calledRuntime.exec again for “su” which led to a sys fork. Fur- Analyzing Root Exploits Since Gingerbread has al-thermore, the file path for “gjsvro” was then written to ready been patched against these exploits, they never ex-a ProcessImpl OutputStream, followed immedi- ecuted correctly. To further analyze these root exploits,ately by “exit”. Since this stream is piped to the child’s we first needed to remove the corresponding patchesstdin, we know that the intention of “su” was to open a from the virtual device build. Here we focus on “ratc,”shell which is then used to execute “gjsvro” followed by since “udev” is analyzed in the same manner. Due to“exit” to close the shell. This did not work though since space constraints we present the exploit diagnosis of“su” did not execute successfully. “ratc” in Appendix A. We first ran the API tracer on the ratc exploit, but did Next we used the Dalvik instruction tracer to obtain not observe any malicious behavior in the API log. Wea Dalvik instruction trace. The trace showed that the did see suspicious behavior in the process log provided asdecrypt and Runtime.exec methods were invoked from part of the OS-view reconstruction. Particularly, we ob-a method called getPermission2, which was called from served that numerous ratc processes (descendants of thegetPermission following a comparison using the result original ratc process) were spawned, the adbd processof isVersion221 and some file existence checks. To get a with uid 2000 ended, followed by more ratc processesmore complete picture of the getPermission method, we and then by an adbd process with uid 0 or root. Thisran dexdump and built the overview pseudocode shown signifies that the attack was successful. It is worth not-in Figure 9 . It is evident that to explore the getPermis- ing that the traditional adb based dynamic analysis wouldsion1 and getPermission3, we must instrument the sam- fail to observe the entire exploiting process because adbdple and change the return values of the different method is killed at the beginning.invocations. Further analysis of the logs and descendent processes With the Dalvik view support, we manipulated the re- showed that there are in fact three types of ratc processes.turn values of isVersion221 and exist methods and were The first is the original ratc process that simply iteratesable to explore all three methods getPermission1, get- through the /proc directory looking for the pid of thePermission2, and getPermission3. They are essentially adbd process. Its child then forked itself until sys fork re-different ways to obtain the root privilege on different turned -11 or EAGAIN. At this point it wrote some dataAndroid configurations. getPermission1 and getPermis- to a pipe and resumed forking. In the grandchild processsion2 only uses the “gjsvro” exploit. The main difference we see a call to sys kill to kill the adbd process followedis that getPermission1 uses Runtime.exec to execute the by attempts to locate the adbd process after it re-spawns.exploit while the other uses the “su” shell. On the otherhand, getPermission3 decrypts “ratc”, “killall” (a wrap- Triggering Data leakage Reverting back to the defaultper for “ratc”) and “gjsvro” and executes them using its Gingerbread build, we sought to observe the informa-own native library. As the API tracer monitors both tion leakage behavior in doSearchReport. As depicted 11
  12. 12. in Figure 9, this involves instrumenting checkPermission getSubscriberId()during execution of getPermission. The Dalvik instruc-tion trace shows that doSearchReport invokes update- String @ 0x40522a10 “310260000000000”Info, which obtains sensitive information about the de-vice including the device model, build version and IMEI Formatter.format()amongst other things. We also observed outgoing HTTP String @ 0x40523288requests, which failed because the server was down. We “<?xml version="1.0" ...”then redirected these HTTP requests to our own HTTPserver by adding a new entry into /etc/hosts. To fur- getBytes()ther analyze this information leakage, we used the tainttracker and built a simplified taint propagation graph, byte[] @ 0x405232a8which is shown in Figure 10. Objects, both Java andnative, are represented by rectangular nodes while meth- crypt()ods are represented by oval nodes. We see that UrlEn- ByteArrayInputStreamcodedFormEntity (the constructor) propagated the orig-inal tainted IMEI number in the String @ 0x40524e80 API Native Memoryto a second String that looks like an HTTP request. Thetaint then propagated to a byte array at 0x405967c0 by sys_write(33, 405261a8, 257)AbstractHttpClient.execute. We finally see the taint ar-riving at the sink at sys write. Note that sys write used Figure 11: Taint Graph for DroidDreama void* at 0x405967d0, which is the contents array ofthe byte array Object (see the StringObject example inSection 4.2). This is expected since JNI provides direct clude crypt which is the DroidDream method used toaccess to arrays to save on the cost of memcpy. xor-encrypt the byte array. The graph shows that get- SubscriberId is used to obtain the IMSI from the system6.3 Analysis of DroidDream as a String @ 0x40522a10. The IMSI String, along withLike analyzing DroidKungFu, we first used the API other information, is then encoded into an XML formattracer to get a basic understanding of DroidDream, and using format. The resulting String is then converted intothen obtained instruction traces and analyzed informa- a byte[] @ 0x405232a8 for encryption by crypt. Thetion leakage. encrypted version is used to create a ByteArrayInput- From the log generated by the API tracer and the Stream. For brevity, we use a generic “API Native Mem-shadow task list, we found that there are two Droid- ory” node to illustrate that the taint further propagatesDream processes. “com.droiddream.lovePositions,” the through memory until the eventual sink at sys write.main process, does not exhibit any malicious behavior We further investigated the crypt method by augment-except using Runtime.exec to execute “logcat -c” which ing the Dalvik instruction tracer to track taint propaga-clears Android’s internal log. Again, this behavior indi- tion and generate a taint-annotated Dalvik instructioncates that traditional Android debugging tools fall short trace. Not only do we see the byte array being xor-edfor malware analysis. with a static field name “KEYVALUE,” we also see that “com.droiddream.lovePositions:remote,” the other the encryption is being conducted on the byte[] in-place.process, is the malicious one. The logs show that Droid- A snippet of the trace log is depicted in Figure 12.Dream retrieves the IMSI number along with other sen- DroidDream also includes the udev and ratc ex-sitive information like IMEI, and encodes them into an ploits (unencrypted), plus the native library terminal likeXML String. Then we observed a failed attempt to open DroidKungFu. Since we have already analyzed them ina network connection to DroidKungFu, we skipped the analysis on them in Droid-In order to observe this networking behavior, we instru- Dream.ment the return values of sys connect and sys write tomake DroidDream believe these network operations are 7 Discussionsuccessful. Limited Code Coverage Dynamic analysis is known to Using the taint tracker, we marked these information have limited code coverage, as it only explores a singlesources as tainted and obtained taint propagation graphs, execution path at a time. To increase code coverage, wewhich confirm that DroidDream did leak sensitive infor- may explore multiple execution paths as demonstrated inmation from these sources to a remote HTTP server. The previous work [6, 9, 31]. In the experiments, we demon-graph for leaking IMSI information is illustrated in Fig- strated that we can discover different execution paths byure 11. We simplified the graph and annotated it to in- manipulating the return values of system calls, native 12
  13. 13. [43328f40] aget-byte v2(0x01), v4(0x405232a8), v0(186) ysis takes too long, certain timeout events are triggered Getting Tainted Memory: 40523372(2401372) Adding M@410accec(42c5cec) len = 4 leading to different execution paths. The analyst must[43328f44] sget-object v3(0x0000005e), KEYVALUE// field@0003 be aware of these new challenges. In summary, further[43328f48] aget-byte v3(0x88), v3(0x4051e288), v1(58) investigation in this area is needed.[43328f4c] xor-int/2addr v2(62), v3(41) Getting Tainted Memory: 410accec(42c5cec) Adding M@410accec(42c5cec) len = 4 8 Related Work[43328f4e] int-to-byte v2(0x17), v2(23) Getting Tainted Memory: 410accec(42c5cec) Virtual Machine Introspection Virtual Machine Intro- Adding M@410accec(42c5cec) len = 4[43328f50] aput-byte v2(0x17), v4(0x405232a8), v0(186) spection is a family of techniques that rebuild a guest’s Getting Tainted Memory: 410accec(42c5cec) context from the virtual machine monitor [21, 24]. This Adding M@40523372(2401372) len = 1 is achieved by understanding the important kernel data structures (such as the task list) and extracting impor- tant information from these data structures. For closed-Figure 12: Excerpt of Dalvik Instruction Trace for source operating systems, it is difficult to have completeDroidDream. A Dalvik instruction entry shows the location understanding of the kernel data structures. To solve thisof the current instruction in square brackets, the decoded in- problem, Dolan-Gavitt et al. developed a technique thatstruction plus the values of the virtual registers in parenthesis. automatically generates introspection tools by first mon-A taint log entry is indented and shows tainted memory being itoring the execution of a similar tool within the guestread or written to. The memory’s physical address is shown in system and then mimicking the same execution outsideparenthesis and the total bytes tainted is represented by ”len.” of the guest system [16]. With deep understanding of the Android kernel, DroidScope is able to intercept certainAPIs and even internal Dalvik methods of the App. This kernel functions and traverse proper kernel data struc-simple approach works fairly well in practice although a tures to reconstruct the OS level view. In comparison,more systematic approach is desirable. One method is to DroidScope takes it one step further to reconstruct theperform symbolic execution to compute path constraints Dalvik/Java view, such that both Java and native compo-and then automatically explore other feasible paths. We nents from an App can be analyzed simultaneously andhave not yet implemented symbolic execution and leave as future work. In particular, we seek to use tainting inconjunction with the Dalvik view to implement a sym- Dynamic Binary Instrumentation PIN [27], Dy-bolic execution engine at the Dalvik instruction level. namoRIO [5], and Valgrind [32] are powerful dynamic instrumentation tools that analyze user-level programs.Detecting and Evading DroidScope In the desktop en- They are less ideal for malware analysis, because theyvironment, malware becomes increasingly keen to the share the same memory space with user-level mal-execution environment. Emulation-resistant malware de- ware and thus can be subverted. Bernat et al. usedtect if they are running within an emulated environment a formal model to identify observable differences dueand evade analysis by staying dormant or simply crash- to instrumentation of sensitive instructions and createding themselves. Researchers have studied this problem a sensitivity-resistant instrumentation tool called SR-for desktop malware [2, 26, 36]. The same problem has Dyninst [4]. Like the other tools though, it cannot benot arisen for Android malware analysis. However, as used to analyze kernel-level malware.DroidScope or similar analysis platforms become widely Anubis [1], PinOS [7], TEMU [35], and Ether [15] areadopted to analyze Android malware, we anticipate sim- based on CPU emulators and hypervisors. They have theilar evasion techniques will eventually appear. As mal- full system view of the guest system and thus are betterware may detect the emulated environment using emula- suited for malware analysis. These systems only sup-tion bugs in the emulator, some efforts have been made to port the x86 architecture and Ether, in principle, cannotdetect bugs in the CPU emulators and thus can improve support ARM, because it relies on the hardware virtual-emulation accuracy [28, 29]. ization technology on x86. A new port must be devel- More troubling are the intrinsic differences between oped for ARM virtualization [30]. While Atom basedthe emulated environment and mobile systems. Mobile mobile platforms are available, ARM still dominates thedevices contain numerous sensors, e.g. GPS, motion and Android market and thus ARM based analysis is impor-audio, with performance profiles which might be difficult tant. To the best of our knowledge, DroidScope is theto emulate. While exploring multiple execution paths first fine-grained dynamic binary instrumentation frame-may be used to bypass these types of tests, they might work that supports the ARM architecture and provides astill not be sufficient. For example we have observed comprehensive interface for Android malware analysis.that Android, as an interactive platform, can be sensitive We do not however support control flow tainting or dif-to the performance overhead due to analysis. If the anal- ferent tainting profiles like Dytan [10]. Since Dytan is 13