DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Viewsfor Dynamic Android Malware Analysis

Lok Kwong Yan†‡ Heng Yin†

†Syracuse University ‡Air Force Research LaboratorySyracuse, New York, USA Rome, New York, USA

{loyan, heyin}@syr.edu

AbstractThe prevalence of mobile platforms, the large marketshare of Android, plus the openness of the Android Mar-ket makes it a hot target for malware attacks. Once a mal-ware sample has been identified, it is critical to quicklyreveal its malicious intent and inner workings. In thispaper we present DroidScope, an Android analysis plat-form that continues the tradition of virtualization-basedmalware analysis. Unlike current desktop malware anal-ysis platforms, DroidScope reconstructs both the OS-level and Java-level semantics simultaneously and seam-lessly. To facilitate custom analysis, DroidScope ex-ports three tiered APIs that mirror the three levels of anAndroid device: hardware, OS and Dalvik Virtual Ma-chine. On top of DroidScope, we further developed sev-eral analysis tools to collect detailed native and Dalvikinstruction traces, profile API-level activity, and track in-formation leakage through both the Java and native com-ponents using taint analysis. These tools have proven tobe effective in analyzing real world malware samples andincur reasonably low performance overheads.

1 IntroductionAndroid is a popular mobile operating system that is in-stalled in millions of devices and accounted for morethan 50% of all smartphone sales in the third quarter of2011 [22]. The popularity of Android and the open na-ture of its application marketplace makes it a prime tar-get for attackers. Malware authors can freely upload ma-licious applications to the Android Market1 waiting forunsuspecting users to download and install them. Ad-ditionally, numerous third-party alternative marketplacesmake delivering malicious applications even easier. In-deed recent research has shown that malicious applica-tions exist in both the official and unofficial marketplaceswith a rate of 0.02% and 0.2% respectively [41].

1The Android Market has been superceded by the Android AppsStore in Google Play.

Malware analysis and exploit diagnosis on desktopsystems is well researched. It is widely accepted thatdynamic analysis is indispensable, because malware isoften heavily obfuscated to thwart static analysis. Fur-thermore, runtime information is often needed for exploitdiagnosis. In particular, much work has leveraged virtu-alization techniques, either whole-system software emu-lation or hardware virtualization, to introspect and ana-lyze illicit activities within the virtual machine [11, 15,18, 31, 33, 39, 37].

The advantages of virtualization-based analysis ap-proaches are two-fold: 1) as the analysis runs under-neath the entire virtual machine, it is able to analyze eventhe most privileged attacks in the kernel; and 2) as theanalysis is performed externally, it becomes very diffi-cult for an attack within the virtual machine to disruptthe analysis. The downside, however, is the loss of se-mantic contextual information when the analysis com-ponent is moved out of the box. To reconstruct the se-mantic knowledge, virtual machine introspection (VMI)is needed to intercept certain kernel events and parse ker-nel data structures [16, 21, 24]. Based on this idea, sev-eral analysis platforms (such as Anubis [1], Ether [15],and TEMU [35]) have been implemented.

Despite the fact that Android is based on Linux, itis not straightforward to take the same desktop analy-sis approach for Android malware. There are two lev-els of semantic information that must be rebuilt. In thelower level, Android is a Linux operating system whereeach Android application (or App in short) is encapsu-lated into a process. Within each App, a virtual machine(known as the Dalvik Virtual Machine) provides a run-time environment for the App’s Java components.

In essence, to enable the virtualization-based analysisapproach for Android malware analysis, we need to re-construct semantic knowledge at two levels: 1) OS-levelsemantics that understand the activities of the malwareprocess and its native components; and 2) Java-level se-mantics that comprehend the behaviors in the Java com-

1

ponents. Ideally, to capture the interactions between Javaand native components, we need a unified analysis plat-form that can simultaneously rebuild these two semanticviews and seamlessly bind these two views with the exe-cution context.

With this goal in mind, we designed and implementeda new analysis platform, DroidScope, for Android mal-ware analysis. DroidScope is built on top of QEMU (aCPU emulator [3]) and is able to reconstruct the OS-level and Java-level semantic views completely from theoutside. Enriched with the semantic knowledge, Droid-Scope further provides a set of APIs to help analystsimplement custom analysis plugins. To demonstrate thecapability of DroidScope, we have implemented severaltools, including native instruction tracer and Dalvik in-struction tracer to obtain detailed instruction traces, APItracer to log an App’s interactions with the Android sys-tem, and taint tracker to analyze information leakage.

We evaluated the performance impacts of these toolson 12 different benchmarks and found that the instru-mentation overhead is reasonably low and taint analysisperformance (from 11 to 34 times slowdown) is compa-rable with other taint analysis systems. We further eval-uated the capability of these tools using two real worldAndroid malware samples: DroidKungFu and Droid-Dream. They both have Java and native components aswell as payloads that try to exploit known vulnerabili-ties. We were able to analyze their behavior without anychanges to the virtual Android device, and obtain valu-able insights.

In summary, this paper makes the following contribu-tions:

• We describe two-level virtual machine introspection torebuild the Linux and Dalvik contexts of virtual An-droid devices. Dalvik introspection also includes atechnique to dynamically disable Dalvik Just-In-Timecompilation.• We present DroidScope, a new emulation based An-

droid malware analysis engine that can be used to an-alyze the Java and native components of Android Ap-plications. DroidScope exposes an event-based anal-ysis interface with three sets of APIs that correspondto the three different abstraction levels of an AndroidDevice, hardware, Linux and Dalvik.• We developed four analysis tools on DroidScope. The

native instruction tracer and Dalvik instruction tracerprovide detailed accounts of the analysis sample’s exe-cution, while the API tracer provides a high level viewof how the sample interacts with the rest of the system.The taint tracker implements dynamic taint analysison native instructions but is capable of tracking taintthrough Java Objects with the help of the Dalvik viewreconstruction. These tools were used to instrument

Linux Kernel

Zygote System Services

Dalvik VM

Java Component

Java Component

Java Libraries Java Libraries

Native Component

Java Libraries

System Libraries

System Libraries

System Libraries

JNI

Figure 1: Overview of Android System

and analyze two real-world malware samples: Droid-KungFu and DroidDream.

2 Background and MotivationIn this section, we give an overview of the Android sys-tem and existing Android malware analysis techniques tomotivate our new analysis platform.

2.1 Android System OverviewFigure 1 illustrates the architecture of the Android sys-tem from the perspective of a system programmer. Atthe lowest level, the Android system uses a customizedLinux kernel to manage various system resources andhardware devices. System services, native applicationsand Apps run as Linux processes. In particular, Zygoteis the parent process for all Android Apps. Each Appis assigned its own unique user ID (uid) at installationtime and group IDs (gids) corresponding to requestedpermissions. These uids and gids are used to controlaccess to system resources (i.e, network and file system)like on a normal Linux system.

All Apps can contain both Java and native compo-nents. Native components are simply shared librariesthat are dynamically loaded at runtime. The Dalvik vir-tual machine (DVM), a shared library named libdvm.so,is then used to provide a Java-level abstraction for theApp’s Java components. At the same time, the Java Na-tive Interface (JNI) is used to facilitate communicationsbetween the native and Java sides.

To create a Java component, an App developer firstimplements it in Java, compiles it into Java bytecode, andthen converts it into Dalvik bytecode. The result is aDalvik executable called a dex file. The developer canalso compile native code into shared libraries, .so files,with JNI support. The dex file, the shared libraries andany other resources, including the AndroidManifest.xmlfile that describes the App, are packaged together into anapk file for distribution.

For instance, DroidKungFu is a malicious puzzle

2

game found in alternative marketplaces [25]. Its Javacomponent exfiltrates sensitive information and awaitscommands from the bot master. Its native component isused as a shell to execute those commands and it also in-cludes three resource files that are encrypted exploits tar-geting known vulnerabilities, adb setuid exhaustion andudev [12], in certain versions of Android.

For security analysts, once a new Android malwareinstance has been identified, it is critical to quickly re-veal its malicious functionality and understand its inner-workings. This often involves both static and dynamicanalysis.

2.2 Android Malware AnalysisLike malware analysis on the desktop environment, An-droid malware analysis techniques can fall into two cat-egories: static and dynamic. For static analysis, the sam-ple’s dex file can be analyzed by itself or it can be disas-sembled and further decompiled into Java using tools likedex2jar and ded [13]. Standard static program analysistechniques (such as control-flow analysis and data-flowanalysis) can then be performed. As static analysis cangive a complete picture, researchers have demonstratedthis approach to be very effective in many cases [20].

However, static analysis is known to be vulnerableto code obfuscation techniques, which are common-place for desktop malware and are expected for An-droid malware. In fact, the Android SDK includes atool named Proguard [34] for obfuscating Apps. An-droid malware may also generate or decrypt native com-ponents or Dalvik bytecode at runtime. Indeed, Droid-KungFu dynamically decrypts the exploit payloads andexecutes them to root the device. Moreover, researchershave demonstrated that bytecode randomization tech-niques can be used to completely hide the internal logicof a Dalvik bytecode program [14]. Static analysis alsofalls short for exploit diagnosis, because a vulnerableruntime execution environment is needed to observe andanalyze an exploit attack and pinpoint the vulnerability.

Complementary to static analysis, dynamic analysis isimmune to code obfuscation and is able to see the mali-cious behavior on an actual execution path. Its downsideis lack of code coverage, although it can be amelioratedby exploiting multiple execution paths [6, 9, 31]. TheAndroid SDK includes a set of tools, such as adb andlogcat, to help developers debug their Apps. WithJDWP (Java Debug Wire Protocol) support, the debug-ger can even exist outside of the device. However, justlike how desktop malware detects and disables debug-gers, malicious Android Apps can also detect the pres-ence of these tools, and then either evade or disable theanalysis. The fundamental reason is that the debuggingcomponents and malware reside in the same executionenvironment with the same privileges.

Linux Kernel

Zygote System Services

Dalvik VM

Java Component

Java Component

Java Libraries Java Libraries

Native Component

Java Libraries

System Libraries

System Libraries

System Libraries

JNI

OS-level View

Java-level View

DroidScope

Instrumentation Interface

API Tracer

Native Insn. Tracer

Dalvik Insn. Tracer

Taint Tracker

Java Component

Java Component

Figure 2: DroidScope Overview

Virtualization based analysis has proven effectiveagainst evasion, because all of the analysis componentsare out of the box and are more privileged than the run-time environment being analyzed, including the mal-ware. Based on dynamic binary translation and hard-ware virtualization techniques, several analysis plat-forms [1, 15, 38] have been built for analyzing desktopmalware. These platforms are able to bridge the seman-tic gap between the hardware-level view from the virtualmachine monitor and the OS-level view within the vir-tual machine using virtual machine introspection tech-niques [16, 21, 24].

However, these tools cannot be immediately used forAndroid malware analysis. Android has two levels ofsemantic views, OS and Java, that need to be recon-structed versus the one for desktop malware. To enablevirtualization-based analysis for Android malware, weneed a unified analysis platform that reconstructs thesetwo levels of views simultaneously and seamlessly bindsthese two views such that interactions between Java com-ponents and native components can be monitored and an-alyzed.

3 ArchitectureDroidScope’s architecture is depicted in Figure 2. Theentire Android system (including the malware) runs ontop of an emulator, and the analysis is completely per-formed from the outside. By integrating the changes intothe emulator, the Android system remains unchangedand different virtual devices can be loaded. To ensure thebest compatibility with virtual Android devices, we ex-tended the QEMU [3] based Android emulator that shipswith the Android SDK. This is done in three aspects: 1)we introspect the guest Android system and reconstructOS-level and Java-level views simultaneously; 2) as akey binary analysis technique, we implement dynamictaint analysis; and 3) we provide an analysis interface tohelp analysts build custom analysis tools. Furthermore,we made similar changes to a different version of QEMU

3

to enable x86 support.To demonstrate the capabilities of DroidScope, we

have developed several analysis tools on it. The APItracer monitors the malware’s activities at the API levelto reason about how the malware interacts with the An-droid runtime environment. This tool monitors how themalware’s Java components communicate with the An-droid Java framework, how the native components inter-act with the Linux system, and how Java components andnative components communicate through the JNI inter-face.

The native instruction tracer and Dalvik instructiontracer look into how a malicious App behaves internallyby recording detailed instruction traces. The Dalvik in-struction tracer records Dalvik bytecode instructions forthe malware’s Java components and the native instruc-tion tracer records machine-level instructions for the na-tive components (if they exist).

The taint tracker observes how the malware obtainsand leaks sensitive information (e.g., GPS location, IMEIand IMSI) by leveraging the taint analysis componentin DroidScope. Dynamic taint analysis has been pro-posed as a key technique for analyzing desktop malwareparticularly with respect to information leakage behav-ior [18, 39]. It is worth noting that DroidScope performsdynamic taint analysis at the machine code level. Withsemantic knowledge at both OS and Java levels, Droid-Scope is able to detect information leakage in Java com-ponents, native components, or even collusive Java andnative components.

We have implemented DroidScope to support bothARM and x86 Android systems. Due to the fact that theARM architecture is most widely used for today’s mo-bile platforms, we focus our discussion on ARM support,which is also more extensively tested.

4 Semantic View ReconstructionWe discuss our methodology for rebuilding the two lev-els of semantic views in this section. We first discuss howinformation about processes, threads, memory mappingsand system calls are rebuilt at runtime. This constitutesthe OS-level view. Then from the memory mapping, welocate the Dalvik Virtual Machine and further rebuild theJava or Dalvik-level view.

4.1 Reconstructing the OS-level ViewThe OS-level view is essential for analyzing native com-ponents. It also serves a basis for obtaining the Java-levelview for analyzing Java components. The basic tech-niques for reconstructing the OS-level view have beenwell studied for the x86 architecture and are generallyknown as virtual machine introspection [16, 21, 24]. Weemploy similar techniques in DroidScope. We begin byfirst describing our changes to the Android emulator to

enable basic instrumentation support.

Basic Instrumentation QEMU is an efficient CPU em-ulator that uses dynamic binary translation. The normalexecution flow in QEMU is as follows: 1) a basic blockof guest instructions is disassembled and translated intoan intermediate representation called TCG (Tiny CodeGenerator); 2) the TCG code block is then compileddown to a block of host instructions and stored in acode cache; and 3) control jumps into the translated codeblock and guest execution begins. Subsequent executionof the same guest basic blocks will skip the translationphase and directly jump into the translated code block inthe cache.

To perform analysis, we need to instrument the trans-lated code blocks. More specifically, we insert extraTCG instructions during the code translation phase, suchthat this extra analysis code is executed in the execu-tion phase. For example. in order to monitor contextswitches, we insert several TCG instructions to call ahelper function whenever the translation table registers(system control co-processor c2 base0 and c2 base1 inQEMU) are written to.

With basic instrumentation support, we extract the fol-lowing OS-level semantic knowledge: system calls, run-ning processes, including threads, and the memory map.

System Calls A user-level process has to make systemcalls to access various system resources and thus obtain-ing its system call behavior is essential for understandingmalicious Apps. On the ARM architecture, the servicezero instruction svc #0 (also known as swi #0) is used tomake system calls with the system call number in registerR7. This is similar to x86 where the int 0x80 instructionis used to transition into privileged mode and the systemcall number is passed through the eax register.

To obtain the system call information, we instrumentthese special instructions, i.e. insert the additional TCGinstructions, to call a callback function that retrieves ad-ditional information from memory. For important sys-tem calls (e.g. open, close, read, write, connect, etc.), thesystem call parameters and return values are retrieved aswell. As a result, we are able to understand how a user-level process accesses the file system and the network,communicates with another process, and so on.

Processes and Threads From the operating system per-spective, Android Apps are user-level processes. There-fore, it is important to know what processes are activeand which one is currently running. In Linux kernel 2.6,the version used in Gingerbread (Android 2.3), the basicexecutable unit is the task which is represented by thetask struct structure. A list of active tasks is main-tained in a task struct list which is pointed to byinit task. To make this information readily availableto analysis tools, DroidScope maintains a shadow task

4

list with select information about each task.

To distinguish between a thread and a process, wegather a task’s process identifier pid as well as its threadgroup identifier tgid. The pgd (the page global di-rectory that specifies the memory space of a process),uid (the unique user ID associated with each App), andthe process’ name are also maintained as part of theshadow task list. Additionally, our experience has shownthat malware often escalates its privileges or spawnschild process(es) to perform additional duties. Thus,our shadow task list also contains the task’s credentials,i.e. uid, gid, euid, egid as well as the process’parent pid.

Special attention is paid to a task’s name since thecomm 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.To address this issue, we also obtain the complete appli-cation name from the command line cmdline, whichis pointed to by the mm struct structure pointed to bytask struct. Note that the command line is locatedin user-space memory, which is not shared like kernel-space memory where all the other structures and fieldsreside. To retrieve it, we must walk the task’s page tableto translate the virtual address into a physical one andthen read it based on the physical address.

According to the design of the Linux kernel, thetask struct for the current process can be easilylocated. The current thread info structure is al-ways located at the (stack pointer & 0x1FFF), andthread info has a pointer pointing to the currenttask struct. We iterate through all active tasks byfollowing the doubly linked task struct list. Wealso update our shadow list whenever the base informa-tion changes. We do this by monitoring four system callssys fork, sys execve, sys clone and sys prctl, and updat-ing the shadow task list when they return.

Memory Map The Dalvik Virtual Machine, librariesand dex files are all memory mapped and we rely on theknowledge of their memory addresses for introspection.Therefore, it is important to understand the memory mapof an App. This is especially true for the latest version ofAndroid, Ice Cream Sandwich, since address space lay-out randomization is enabled by default.

To obtain the memory map of a process, we iteratethrough the process’ list of virtual memory areas by fol-lowing the mmap pointer in the mm struct pointed toby the task struct. To ensure the freshness of thememory map information, we intercept the sys mmap2system call and update the shadow memory map when itreturns.

rIBase:dvmAsmInstructionStart

array-length

instance-of

move/from16

move

nop

ldrh r7, [r4, #2]!and ip, r7, #255add pc, r8, ip, lsl #6push{r4,r5,r6,r7,r8,r9,sl,fp,lr}sub sp, sp, #4..nopnopnop

lsr r3, r7, #12lsr r9, r7, #8ldr r0, [r5, r3, lsl #2]and r9, r9, #15cmp r0, #0..cmp r0, r1beq<dvmAsmSisterStart+0xe4>b<dvmAsmSisterStart+0xd0>

Opcode * 0x40

0x0

0x40

0x80

0x800

0x840

Figure 3: Dalvik Opcode Emulation Layout in mterp

4.2 Reconstructing the Dalvik View

With the OS-level view and knowledge of how the DVMoperates internally, we are able to reconstruct the Java orDalvik view, including Dalvik instructions, the currentmachine state, and Java objects. Some of the details arepresented in this section.

Dalvik Instructions The DVM’s main task is to exe-cute Dalvik bytecode instructions by translating theminto corresponding executable machine code. In Ginger-bread and thereafter, it does so in two ways: interpreta-tion and Just-In-Time compilation (JIT) [8].

The interpreter, named mterp, uses an offset-addressing method to map Dalvik opcodes to machinecode blocks as shown in Figure 3. Each opcode has 64bytes of memory to store the corresponding emulationcode, and any emulation code that does not fit within the64 bytes use an overflow area, dvmAsmSisterStart,(see instance-of in Figure 3). This design simpli-fies the emulation of Dalvik instructions. mterp simplycalculates the offset, opcode ∗ 64, and jumps to the cor-responding emulation block.

This design also simplifies the reverse conversion fromnative to Dalvik instructions as well: when the pro-gram counter (R15) points to any of these code re-gions, we are sure that the DVM is interpreting a byte-code instruction. Furthermore, it is trivial to determinethe opcode of the currently executing Dalvik instruc-tion. In DroidScope we first identify the virtual ad-dress of rIBase, the beginning of the emulation code re-gion, and then calculate the opcode using the formula(R15− rIBase)/64. rIBase is dynamically calculatedas the virtual address of libdvm.so (obtained from theshadow memory map in the OS-level view) plus the off-set of dvmAsmInstructionStart (a debug sym-bol). If the debug symbol is not available, we can identifyit using the signature for Dalvik opcode number 0 (nop).

5

Update Program Counter(PC)

Is Code in JIT code cache?

Execute JIT code block

Emulate Code Using mterp

Yes

No

Decrement block Counter

Is Counter 0?Request JIT

Compilation forCode block and

reset Counter

Yes

No

Figure 4: High Level Flowchart of mterp and JIT

The Just-In-Time compiler was introduced to improveperformance by compiling heavily used, or hot, Dalvikinstruction traces (consisting of multiple code blocks) di-rectly into native machine code. While each translationtrace has a single entry point, there can be multiple ex-its known as chaining cells. These chaining cells eitherchain to other translation traces or to default entry pointsof the mterp interpreter. Overall, JIT provides an excel-lent performance boost for programs that contain manyhot code regions, although it makes fine-grained instru-mentation more difficult. This is because JIT performsoptimization on one or more Dalvik code blocks and thusblurs the Dalvik instruction boundaries.

An easy solution would be to completely disable JITat build time, but it could incur a heavy performancepenalty and more importantly it require changes to thevirtual device, which we want to avoid. Consideringthat we are often only interested in a particular sectionof Dalvik bytecode (such as the main program but notthe rest of system libraries), we choose to selectively dis-able JIT at runtime. Analysis plugins can specify thecode regions for which to disable JIT and as a result onlythe Dalvik blocks being analyzed incur the performancepenalty. All other regions and Apps still benefit fromJIT.

Figure 4 shows the general flow of the DVM. Whena basic block of Dalvik bytecode needs to be emulated,the Dalvik program counter is updated to reflect the newblock’s address. That address is then checked againstthe translation cache to determine if a translated trace forthe block already exists. If it does, the trace is executed.If it does not then the profiler will decrement a counterfor that block. When this counter reaches 0, the blockis considered hot and a JIT compilation requested. Toprevent thrashing, the counter is reset to a higher valueand emulation using mterp commences. As can be seenin the flow chart, as long as the requested code is not inthe code cache, then mterp will be used to emulate the

V4 (In 2)V3 (In 1)V2 (In 0)

V1V0

R0:R1:R2:R3:R4: rPCR5: rFPR6: rGLUER7: rINSTR8: rIBASER9:R10:R11:R12:R13:R14:R15: PC+4

framework.jar@classes.dex

mterp

InterpState

InterpState{ … Jvalue retval; ... Thread* self; …}

android.app.ContextImpl.SharedPreferencesImpl.getInt:(Ljava/lang/String;I)I:

libd

vm.s

o

StringInteger

“this”

Sta

ck g

row

s

low address

Figure 5: Dalvik Virtual Machine State

code.The dvmGetCodeAddr function is used to deter-

mine whether a translated trace exists. It returns NULLif a trace does not exist and the address of the corre-sponding trace if it does. Thus, to selectively disableJIT, we instrument the DVM and set the return value ofdvmGetCodeAddr to NULL for any translated trace wewish to disable. To show that our change to the virtualmachine state does not have any ill side-effects, we makethe following arguments. First, if the original returnvalue was NULL then our change will not have any sideeffects. Second, if the return value was a valid address,then by setting it to NULL, the profile counter is decre-mented and if 0, i.e. the code region deemed hot again,another compilation request is issued for the block. Inthis case, the code will be recompiled taking up space inthe code-cache. This can be prevented by not instrument-ing the dvmGetCodeAddr call from the compiler.

In addition to preventing the translated trace from be-ing executed, setting the value to NULL also prevents itfrom being chained to other traces. This is the desiredbehavior. For the special case where a translation tracehas already been chained and thus dvmGetCodeAddris not called, we flush the JIT cache whenever the dis-abled JIT’ed code regions change. This is done by mark-ing the JIT cache as full during the next garbage collec-tion event, which leads to a cache flush. While this is nota perfect solution, we have found it to be sufficient.

In all cases, the only side effect is wasted CPU cy-cles due to compilation; the execution logic is unaffected.Therefore, the side effects are deemed inconsequential.

DVM State Figure 5 illustrates how the DVM main-tains the virtual machine state. When mterp is emulatingDalvik instructions, the ARM registers R4 through R8store the current DVM execution context. More specifi-cally, R4 is the Dalvik program counter, pointing to thecurrent Dalvik instruction. R5 is the Dalvik stack framepointer, pointing to the beginning of the current stack

6

ClassObject*

lock

ArrayObject*

hashcode

offset (0)

count (5)inst

ance

Dat

a

struct StringObject { Object obj; u4 instanceData[1];};

struct ArrayObject { Object obj; u4 length; u8 contents[1];};

ClassObject*

lock

align_pad

0x0048 'H', 0x0045 'e'

0x006c 'l', 0x006c 'l'

0x006f 'o', 0x0000

cont

ent s

V3 (In 1)

0x0000, 0x0000

java.lang.String ClassObject

struct Object { ClassObject* clazz; u4 lock;};

char[] ClassObject

Figure 6: String Object Example

frame. R6 points to the InterpState data structure,called glue. R7 contains the first two bytes of the cur-rent Dalvik instruction, including the opcode. Finally R8stores the base address of the mterp emulation code forthe current DVM instruction. In x86, edx, esi, ediand ebx are used to store the program counter, framepointer, mterp base address and the first two bytes of theinstruction respectively. The glue object can be foundon the stack at a predefined offset.

Dalvik virtual registers are 32 bits and are stored inreverse order on the stack. They are referenced relativeto the frame pointer R5. Hence, the virtual register V0is located at the top of the stack (pointed to by the ARMregister R5,) and the virtual register V1 sits on top of V0in memory, and so forth. All other Dalvik state infor-mation (such as return value and thread information) isobtained through glue pointed to by R6.

After understanding how DVM state is maintained, weare able to reconstruct the state from the native machinecode execution. That is, by examining the ARM registersand relative data structures, we can get the current DVMprogram counter, frame pointer, all virtual registers, andso on.

Java Objects Java Objects are described using two datastructures. Firstly, ClassObject describes a class type andcontains important information about that class: the classname, where it is defined in a dex file, the size of the ob-ject, the methods, and the location of the member fieldswithin the object instances. To standardize class repre-sentations, Dalvik creates a ClassObject for each definedclass type and implicit class type, e.g. arrays. For exam-ple there is a ClassObject that describes a char[]whichis used by java.lang.String. Moreover, if the Apphas a two dimensional array, e.g. String[][], thenDalvik creates a ClassObject to describe the String[]and another to describe the array of the previously de-scribed String[] class.

Secondly, as an abstract type, Object describes a run-time object instance, i.e. member fields. Each Object

has a pointer to the ClassObject that it is an instanceof plus a tail accumulator array for storing all memberfields. Dalvik defines three types of Objects, DataOb-ject, StringObject and ArrayObject that are all pointed toby generic Object*s. The correct interpretation of anyObject* fully depends on the ClassObject that it pointsto.

We use a simple String (”Hello”) to illustrate theinterpretation process. Figure 6 depicts the differentdata structures involved as well as the struct defini-tions on top. To access the String, we first follow thereference in the virtual register V3. Since Java ref-erences are simply Object*s, V3 points to an Ob-ject. To determine the type of the object, we followthe first 4 bytes to the ClassObject structure. This Clas-sObject instance describes the java.lang.Stringclass. Internally, Dalvik does not store the String datainside the StringObject and instead use a char[].Consequently, instanceData[0] is used to storethe reference to the corresponding char[] object andinstanceData[3] is used to store the number ofcharacters in the String, 5 in this case.

We then obtain the String’s data by followinginstanceData[0] to the character array. Once againwe must follow the Object* within the new object tocorrectly interpret it as an ArrayObject. Note that sinceARM EABI requires all arrays to be aligned to its ele-ment size and u8 is 8 bytes in length, we inserted an im-plicit 4 byte align pad into the ArrayObject to ensurethat the contents array is properly aligned. Given thelength of the String from the StringObject and the cor-roborating length in the ArrayObject, the ”Hello” Stringis found in the contents array encoded in UTF-16.

4.3 Symbol InformationSymbols (such as function name, class name, field name,etc.) provide valuable information for human analysts tounderstand program execution. Thus, DroidScope seeksto make the symbols readily available by maintaining asymbol database. For portability and ASLR support, weuse one database of offsets to symbols per module. Atruntime, finding a symbol by a virtual address requiresfirst identifying the containing module using the shadowmemory map, and then calculating the offset to searchthe database.

Native library symbols are retrieved statically throughobjdump and are usually limited to Android librariessince malware libraries are often stripped of all symbolinformation. On the other hand, Dalvik or Java symbolsare retrieved dynamically and static symbol informationthrough dexdump is used as a fallback. This has the ad-vantage of ensuring the best symbol coverage for opti-mized dex files and even dynamically generated Dalvikbytecode.

7

Events

instruction begin/end context switchregister read/write system call method beginmemory read/write task begin/endblock begin/end task updated

memory map updated

Query &

Set

memory read/write query symbol database query symbol databaseget current context interpret Java object

register read/write get task list get/set DVM statetaint set/check taint set/check objects

disable JIT

NativeAPI LinuxAPI DalvikAPIDalvik instruction begin

memory r/w with pgd

Table 1: Summary of DroidScope APIs

We rely on the data structures of DVM to retrieve sym-bols at runtime. For example, the Method structure con-tains two pointers of interest. insns points to the startof the method’s bytecode, the symbol address, and namepoints to the name. Conveniently, the glue structurepointed to by R6 has a field method that points to theMethod structure for the currently executing method.

There are times when this procedure fails though, e.g.if the corresponding page of the dex file has not beenloaded into memory yet. In these cases, we first try tolook up the information in a local copy of the correspond-ing dex file, and if that fails as well, use the static symbolinformation from dexdump. DroidScope uses this samebasic method of relying on the DVM’s data structures toretrive class and field names as well.

5 Interface & PluginsDroidScope exports an event based interface for instru-mentation. We describe the general layout of the APIs,present an example of how tools are implemented, andfinally describe available tools in this section.

5.1 APIsDroidScope defines a set of APIs to facilitate customanalysis tool development. The APIs provide instrumen-tation on different levels: native, OS and Dalvik, to mir-ror the context levels of a real Android device. At eachlevel, the analysis tool can register callbacks for differentevents, and also query or set various kinds of informationand controls. Table 1 summarizes these APIs.

At the native level, one can register callbacks for in-struction start and end, basic block start and end, mem-ory read and write, and register read and write. One canalso read and write memory and register content. Astaint analysis is implemented at the machine code level,one can also set and check taint in memory and regis-ters. Currently, the taint propagation engine only sup-ports copy and arithmetic operations, control flow depen-dencies are not tracked.

At the OS level, one can register callbacks for contextswitch, system call, task start, update (such as process

name), and end, and memory map update. One can alsoquery symbols, obtain the task list, and get the currentexecution context (e.g., current process and thread). Atthe Dalvik level, one can instrument at the granularityof Dalvik instructions and methods. One can query theDalvik symbols, parse and interpret Java objects, readand modify DVM state, and selectively disable JIT forcertain memory regions. Through the Dalvik-view, onecan also set and check taint in Java Objects as well.

5.2 Instrumentation OptimizationA general guideline for performance optimization in dy-namic binary translation is to shift computation from theexecution phase to the translation phase. For instance, ifwe need to instrument a function call at address x usingbasic blocks, then we should insert the instrumentationcode for the block at x when it is being translated insteadof instrumenting every basic block and look for x at exe-cution time.

We follow this guideline in DroidScope. Conse-quently, our instrumentation logic becomes more com-plex. When registering for an event callback, one canspecify a specific location (such as a function entry) or amemory range (to trace instructions or functions within aparticular module). Therefore, our instrumentation logicsupports single value comparisons and range checks forcontrolling when and where event callbacks are insertedduring the translation phase.

The instrumentation logic is also dynamic, because weoften want to register and unregister a callback at execu-tion time. For example, when the virtual device starts,only the OS-view instrumentation is enabled so the An-droid system can start quickly as usual. When we startanalyzing an App, instrumentation code is inserted toreconstruct the Dalvik view and to perform analysis asrequested by the plugin. When instrumenting a func-tion return, the return address will be captured from thelink register R14 at the function entry during execution,and a callback is registered at the return address. Af-ter the function has returned, this callback is removed.Then when the analysis has finished, other instrumenta-tion code is removed as well. To maintain consistency,DroidScope invalidates the corresponding basic blocksin the translated code cache whenever necessary so thatthe new instrumentation logic can be enforced. Hence,the instrumentation logic in DroidScope is complex anddynamic. These details are hidden from the analysis plu-gins.

5.3 Sample PluginFigure 7 presents sample code for implementing a simpleDalvik instruction tracer. The init function at L19 willbe invoked once this plugin is loaded in DroidScope. Ininit, it specifies which program to analyze by calling the

8

 1. void opcode_callback(uint32_t opcode) { 2.   printf("[%x] %s\n", GET_RPC, opcodeToStr(opcode)); 3. } 4. 5. void module_callback(int pid) { 6.   if (bInitialized || (getIBase(pid) == 0)) 7.     return; 8. 9.   gva_t startAddr = 0, endAddr = 0xFFFFFFFF;10.11.   addDisableJITRange(pid, startAddr, endAddr);12.   disableJITInit(getGetCodeAddrAddress(pid));13.   addMterpOpcodesRange(pid, startAddr, endAddr);14.   dalvikMterpInit(getIBase(pid));15.   registerDalvikInsnBeginCb(&opcode_callback);16.   bInitialized = 1;17. }18.19. void _init() {20.   setTargetByName("com.andhuhu.fengyinchuanshuo");21.   registerTargetModulesUpdatedCb(&module_callback);22. }

Figure 7: Sample code for Dalvik Instruction Tracer

setTargetByName function. It also registers a callbackmodule callback to be invoked when module informa-tion is updated. module callback will check if the DVMis loaded and if so, disable JIT for the entire memoryspace (L9 and L11.) It also registers a callback, op-code callback, for Dalvik instructions. When invoked,opcode callback prints the opcode information.

This sample code will print all Dalvik instructions forthe specified App, including the main program and allthe libraries. If we are only interested in the execu-tion of the main program, we can add a function calllike getModAddr(”example@classes.dex”, &startAddr,&endAddr) at L10. This function locates the dex file inthe shadow memory map and stores its start and end ad-dresses in the appropriate variables. The rest of the codecan be left untouched.

5.4 Analysis PluginsTo demonstrate the capability of DroidScope for analyz-ing Android malware, we have implemented four analy-sis plugins: API tracer, native instruction tracer, Dalvikinstruction tracer, and taint tracker.

API tracer monitors how an App (including Java andnative components) interacts with the rest of the sys-tem through system and library calls. We first log allof the App’s system calls by registering for system callevents. We then build a whitelist of the virtual device’sbuilt-in native and Java libraries. As modules are loadedinto memory, any library not in the whitelist is markedfor analysis. We instrument the invoke* and execute*Dalvik bytecodes to identify and log method invoca-tions, including those of the sample. The log containsthe currently executing Java thread, the calling address,the method being invoked as well as a dump of its in-put parameters. Since Java Strings are heavily used, wetry to convert all Strings into native strings before log-ging them. We then instrument the move-result* byte-code instructions to detect when system methods returnand gather the return values. We do not instrument any

of the other bytecodes to improve performance. To loglibrary calls from the App’s native components, we reg-ister for the block end event for blocks that are located inthe App’s native components. When the callback for theblock end event is invoked, we check if the next block iswithin the Apps native components or not. If not, we logthis event.

Native instruction tracer registers ARM or x86 in-struction callbacks to gather information about each in-struction including the raw instruction, its operands (reg-ister and memory) and their values.

Dalvik instruction tracer follows the basic logic ofthe above example and logs the decoded instruction toa file in the dexdump format. The operands, their valuesand all available symbol information, e.g. class, field andmethod names, are logged as well.

Taint tracker utilizes the dynamic taint analysis APIsto analyze information leakage in an Android App. Itspecifies sensitive information sources (such as IMEI,IMSI, and contact information) as tainted and keeps trackof taint propagation at the machine code level until theyreach sinks, e.g. sys write and sys send. With the OSand Dalvik views, it further creates a graphical represen-tation to visualize how sensitive information has leakedout. To construct the graph, we first identify function andmethod boundaries. Whenever taint is propagated, weadd a node to represent the currently executing functionor method and nodes for the tainted memory locations.Since methods operate on Java Objects, we further try toidentify the containing Object and create a node for it in-stead of the simple memory location. Currently, we onlydo this check against the method’s input parameters andthe current Object, e.g. ”this”. Further improvements areleft as future work.

To identify method boundaries, we look for match-ing invoke* or execute* and move-result* Dalvik instruc-tions. We do not rely on the return* instructions sincethey are executed in the invokee context, which might notbe instrumented, e.g. inside an API. Since there are mul-tiple ways for native code to call and return from func-tions plus malicious code is known to jump into the mid-dle of functions, we do not rely on native instructionsto determine function boundaries. Instead, we treat thenearest symbol that is less than or equal to the jump tar-get in the symbol database as the function.

6 EvaluationWe evaluated DroidScope with respect to efficiency andcapability. To evaluate efficiency, we used 7 benchmarkApps from the official Android Market: AnTuTu Bench-mark (ABenchMark) by AnTuTu, CaffeineMark by RaviReddy, CF-Bench by Chainfire, Mobile processor bench-mark (Multicore) by Andrei Karpushonak, Benchmarkby Softweg, and Linpack by GreeneComputing. We then

9

ABenchMark

CaffieneMark

CFBench/Native

CFBench/Java

CFBench/Overall

CPUBench (ms)

Multicore (ms)

Softweg/CPU

Softweg/Graphics

Softweg/Memory

Linpack/Singlethread

Linpack/Multithread

0% 20% 40% 60% 80% 100% 120%

0% 20% 40% 60% 80% 100% 120%

NOJIT Baseline Context Only API TracerDalvik Instruction Tracer

Taint Tracker

Percent of Baseline

Percent of Baseline

Figure 8: Benchmark Results

ran the benchmarks while using the different automaticanalysis tools described above on the benchmarks them-selves. The results are presented in Section 6.1. Toevaluate capability, we analyzed two real world Androidmalware samples: DroidKungFu and DroidDream in de-tail, which will be presented in Sections 6.2 and 6.3.These samples were obtained from the Android MalwareGenome project [40].

Experimental Setup All experiments were conductedon an Acer 4830TG with a Core i5 @ 2.40GHz and 3GBof RAM running Xubuntu 11.10. The Android guest isa Gingerbread build configured as ”user-eng” for ARMwith the Linux 2.6.29 kernel and uses the QEMU defaultmemory size of 96 MB. No changes were made to theAndroid source.

6.1 PerformanceTo measure the performance impact of instrumentation,we took the analysis tools and targeted the benchmarkApps while the Apps performed their tests. This was re-peated 5 times. As the baseline, we ran these benchmarks

on the default Android emulator without any instrumen-tation. Since DroidScope selectively disables JIT on theApps, we also obtained a NOJIT baseline with JIT com-pletely disabled at build time. The performance resultsare summarized in the bar chart in Figure 8. Each toolis associated with a set of bars that shows its benchmarkresults (y-axis) relative to the baseline as a percentage.The ARM Instruction Tracer results are excluded as theyare similar to the taint tracker results.

Please note that the benchmarks are not perfect repre-sentations of performance as evidenced by the > 100%results. For example, in CPUBenchmark the standard de-viation, σ , for Baseline, Dalvik tracer and Context Onlyis only 1%. This means that the results are consistent foreach plugin, but might not be across plugins. Further-more, we removed the Softweg filesystem benchmarkingresults due to high variability, σ > 27%.

We can see from Figure 8 that the overhead(Context Only) of reconstructing the OS-level viewis very small, up to 7% degradation. The taint trackerhas the worst performance as expected, because it reg-isters for instruction level events. The taint tracker in-curs 11x to 34x slowdown, which is comparable to othertaint analysis tools [10, 39] on the x86 architecture. Aspecial case is seen in the Dalvik instruction tracer re-sult for CaffeineMark. This result is attributed to the factthat the tracer dynamically retrieves symbol informationfrom guest memory for logging.

The benefits of dynamically disabling JIT is evidentin some Java based benchmarks such as Linpack, CF-Bench/Java and CaffeineMark. For those benchmarks,the API tracer’s performance is greater than that of theNOJIT Baseline, despite the fact that instrumentation istaking place. This difference is due to Java libraries, suchas String methods, still benefiting from JIT in the APItracer.

6.2 Analysis of DroidKongFuThe DroidKungFu malware contains three components.First, the core logic is implemented in Java and is con-tained within the com.google.ssearch package.This is the main target of our investigation. Second arethe exploit binaries which are encrypted in the apk, de-crypted by the Java component and then subsequentlyexecuted. Third is a native library that is used as a shell.It contains JNI exported functions that can run shell com-mands and is the main interface for command and con-trol. Unfortunately the command and control server wasunavailable at the time of our test and thus we did notanalyze this feature.

Discovering the Internal Logic We began our investi-gation by running the API tracer on the sample and an-alyzing the log. We first looked for system calls of in-terest and found a sys open for a file named “gjsvro”.

10

getPermission { if checkPermission() then doSearchReport(); return if !isVersion221() then if getPermission1() then return if exists("bin/su" or "xbin/su") then getPermission2(); return if !isVersion221() then getPermission3(); return}

Figure 9: getPermission Pseudocode

There was also a subsequent sys write to the file froma byte array. We later found that this array is actu-ally part of a Java ArrayObject which was populatedby the Utils.decrypt method, which is part of Droid-KungFu. Since decrypt takes a byte array as the param-eter, 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-ing execution, DroidKungFu decrypts an asset from itspackage and generates the ”gjsvro” file. We then foundthat DroidKungFu called Runtime.exec with parameters“chmod 4755” and the name of the file, making the fileexecutable and setting the setuid bit. After that, it calledRuntime.exec again for “su” which led to a sys fork. Fur-thermore, the file path for “gjsvro” was then written toa ProcessImpl OutputStream, followed immedi-ately by “exit”. Since this stream is piped to the child’sstdin, we know that the intention of “su” was to open ashell which is then used to execute “gjsvro” followed by“exit” to close the shell. This did not work though since“su” did not execute successfully.

Next we used the Dalvik instruction tracer to obtaina Dalvik instruction trace. The trace showed that thedecrypt and Runtime.exec methods were invoked froma method called getPermission2, which was called fromgetPermission following a comparison using the resultof isVersion221 and some file existence checks. To get amore complete picture of the getPermission method, weran dexdump and built the overview pseudocode shownin Figure 9 . It is evident that to explore the getPermis-sion1 and getPermission3, we must instrument the sam-ple and change the return values of the different methodinvocations.

With the Dalvik view support, we manipulated the re-turn values of isVersion221 and exist methods and wereable to explore all three methods getPermission1, get-Permission2, and getPermission3. They are essentiallydifferent ways to obtain the root privilege on differentAndroid configurations. getPermission1 and getPermis-sion2 only uses the “gjsvro” exploit. The main differenceis that getPermission1 uses Runtime.exec to execute theexploit while the other uses the “su” shell. On the otherhand, getPermission3 decrypts “ratc”, “killall” (a wrap-per for “ratc”) and “gjsvro” and executes them using itsown native library. As the API tracer monitors both

UrlEncodedFormEntity.<init>

AbstractHttpClient.execute()

sys_write(34, 0x405967d0, 397)

String @ 0x4056a448“imei=123456789012345&ostype=...”

byte[ ] @ 405967c0 / void* @ 405967d0“POST /search/sayhi.php HTTP/1.1...”

String @ 0x40524e80“123456789012345”

getDeviceId()

Figure 10: Taint Graph for DroidKungFu

Java and native components, our logs show that the li-brary then calls sys vfork and sys execve to execute thecommands. This indicates that getPermission3 was try-ing to run both “udev” exploit and “rage against the cage”(ratc) exploits.

Analyzing Root Exploits Since Gingerbread has al-ready been patched against these exploits, they never ex-ecuted correctly. To further analyze these root exploits,we first needed to remove the corresponding patchesfrom the virtual device build. Here we focus on “ratc,”since “udev” is analyzed in the same manner. Due tospace constraints we present the exploit diagnosis of“ratc” in Appendix A.

We first ran the API tracer on the ratc exploit, but didnot observe any malicious behavior in the API log. Wedid see suspicious behavior in the process log provided aspart of the OS-view reconstruction. Particularly, we ob-served that numerous ratc processes (descendants of theoriginal ratc process) were spawned, the adbd processwith uid 2000 ended, followed by more ratc processesand then by an adbd process with uid 0 or root. Thissignifies that the attack was successful. It is worth not-ing that the traditional adb based dynamic analysis wouldfail to observe the entire exploiting process because adbdis killed at the beginning.

Further analysis of the logs and descendent processesshowed that there are in fact three types of ratc processes.The first is the original ratc process that simply iteratesthrough the /proc directory looking for the pid of theadbd process. Its child then forked itself until sys fork re-turned -11 or EAGAIN. At this point it wrote some datato a pipe and resumed forking. In the grandchild processwe see a call to sys kill to kill the adbd process followedby attempts to locate the adbd process after it re-spawns.

Triggering Data leakage Reverting back to the defaultGingerbread build, we sought to observe the informa-tion leakage behavior in doSearchReport. As depicted

11

in Figure 9, this involves instrumenting checkPermissionduring execution of getPermission. The Dalvik instruc-tion trace shows that doSearchReport invokes update-Info, which obtains sensitive information about the de-vice including the device model, build version and IMEIamongst other things. We also observed outgoing HTTPrequests, which failed because the server was down. Wethen redirected these HTTP requests to our own HTTPserver by adding a new entry into /etc/hosts. To fur-ther analyze this information leakage, we used the tainttracker and built a simplified taint propagation graph,which is shown in Figure 10. Objects, both Java andnative, are represented by rectangular nodes while meth-ods are represented by oval nodes. We see that UrlEn-codedFormEntity (the constructor) propagated the orig-inal tainted IMEI number in the String @ 0x40524e80to a second String that looks like an HTTP request. Thetaint then propagated to a byte array at 0x405967c0 byAbstractHttpClient.execute. We finally see the taint ar-riving at the sink at sys write. Note that sys write useda 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 directaccess to arrays to save on the cost of memcpy.

6.3 Analysis of DroidDreamLike analyzing DroidKungFu, we first used the APItracer to get a basic understanding of DroidDream, andthen obtained instruction traces and analyzed informa-tion leakage.

From the log generated by the API tracer and theshadow task list, we found that there are two Droid-Dream processes. “com.droiddream.lovePositions,” themain process, does not exhibit any malicious behaviorexcept using Runtime.exec to execute “logcat -c” whichclears Android’s internal log. Again, this behavior indi-cates that traditional Android debugging tools fall shortfor malware analysis.

“com.droiddream.lovePositions:remote,” the otherprocess, is the malicious one. The logs show that Droid-Dream retrieves the IMSI number along with other sen-sitive information like IMEI, and encodes them into anXML String. Then we observed a failed attempt to opena network connection to 184.105.245.17:8080.In order to observe this networking behavior, we instru-ment the return values of sys connect and sys write tomake DroidDream believe these network operations aresuccessful.

Using the taint tracker, we marked these informationsources as tainted and obtained taint propagation graphs,which confirm that DroidDream did leak sensitive infor-mation from these sources to a remote HTTP server. Thegraph for leaking IMSI information is illustrated in Fig-ure 11. We simplified the graph and annotated it to in-

String @ 0x40522a10“310260000000000”

getSubscriberId()

Formatter.format()

byte[] @ 0x405232a8

String @ 0x40523288“<?xml version="1.0" ...”

getBytes()

crypt()

sys_write(33, 405261a8, 257)

API Native Memory

ByteArrayInputStream

Figure 11: Taint Graph for DroidDream

clude crypt which is the DroidDream method used toxor-encrypt the byte array. The graph shows that get-SubscriberId is used to obtain the IMSI from the systemas a String @ 0x40522a10. The IMSI String, along withother information, is then encoded into an XML formatusing format. The resulting String is then converted intoa byte[] @ 0x405232a8 for encryption by crypt. Theencrypted version is used to create a ByteArrayInput-Stream. For brevity, we use a generic “API Native Mem-ory” node to illustrate that the taint further propagatesthrough memory until the eventual sink at sys write.

We further investigated the crypt method by augment-ing the Dalvik instruction tracer to track taint propaga-tion and generate a taint-annotated Dalvik instructiontrace. Not only do we see the byte array being xor-edwith a static field name “KEYVALUE,” we also see thatthe encryption is being conducted on the byte[] in-place.A snippet of the trace log is depicted in Figure 12.

DroidDream also includes the udev and ratc ex-ploits (unencrypted), plus the native library terminal likeDroidKungFu. Since we have already analyzed them inDroidKungFu, we skipped the analysis on them in Droid-Dream.

7 DiscussionLimited Code Coverage Dynamic analysis is known tohave limited code coverage, as it only explores a singleexecution path at a time. To increase code coverage, wemay explore multiple execution paths as demonstrated inprevious work [6, 9, 31]. In the experiments, we demon-strated that we can discover different execution paths bymanipulating the return values of system calls, native

12

[43328f40] aget-byte v2(0x01), v4(0x405232a8), v0(186) Getting Tainted Memory: 40523372(2401372) Adding M@410accec(42c5cec) len = 4[43328f44] sget-object v3(0x0000005e), KEYVALUE// field@0003[43328f48] aget-byte v3(0x88), v3(0x4051e288), v1(58)[43328f4c] xor-int/2addr v2(62), v3(41) Getting Tainted Memory: 410accec(42c5cec) Adding M@410accec(42c5cec) len = 4[43328f4e] int-to-byte v2(0x17), v2(23) Getting Tainted Memory: 410accec(42c5cec) Adding M@410accec(42c5cec) len = 4[43328f50] aput-byte v2(0x17), v4(0x405232a8), v0(186) Getting Tainted Memory: 410accec(42c5cec) Adding M@40523372(2401372) len = 1

Figure 12: Excerpt of Dalvik Instruction Trace forDroidDream. A Dalvik instruction entry shows the locationof the current instruction in square brackets, the decoded in-struction plus the values of the virtual registers in parenthesis.A taint log entry is indented and shows tainted memory beingread or written to. The memory’s physical address is shown inparenthesis and the total bytes tainted is represented by ”len.”

APIs and even internal Dalvik methods of the App. Thissimple approach works fairly well in practice although amore systematic approach is desirable. One method is toperform symbolic execution to compute path constraintsand then automatically explore other feasible paths. Wehave not yet implemented symbolic execution and leaveit as future work. In particular, we seek to use tainting inconjunction with the Dalvik view to implement a sym-bolic execution engine at the Dalvik instruction level.

Detecting and Evading DroidScope In the desktop en-vironment, malware becomes increasingly keen to theexecution environment. Emulation-resistant malware de-tect if they are running within an emulated environmentand evade analysis by staying dormant or simply crash-ing themselves. Researchers have studied this problemfor desktop malware [2, 26, 36]. The same problem hasnot arisen for Android malware analysis. However, asDroidScope or similar analysis platforms become widelyadopted to analyze Android malware, we anticipate sim-ilar evasion techniques will eventually appear. As mal-ware may detect the emulated environment using emula-tion bugs in the emulator, some efforts have been made todetect bugs in the CPU emulators and thus can improveemulation accuracy [28, 29].

More troubling are the intrinsic differences betweenthe emulated environment and mobile systems. Mobiledevices contain numerous sensors, e.g. GPS, motion andaudio, with performance profiles which might be difficultto emulate. While exploring multiple execution pathsmay be used to bypass these types of tests, they mightstill not be sufficient. For example we have observedthat Android, as an interactive platform, can be sensitiveto the performance overhead due to analysis. If the anal-

ysis takes too long, certain timeout events are triggeredleading to different execution paths. The analyst mustbe aware of these new challenges. In summary, furtherinvestigation in this area is needed.

8 Related WorkVirtual Machine Introspection Virtual Machine Intro-spection is a family of techniques that rebuild a guest’scontext from the virtual machine monitor [21, 24]. Thisis achieved by understanding the important kernel datastructures (such as the task list) and extracting impor-tant information from these data structures. For closed-source operating systems, it is difficult to have completeunderstanding of the kernel data structures. To solve thisproblem, Dolan-Gavitt et al. developed a technique thatautomatically generates introspection tools by first mon-itoring the execution of a similar tool within the guestsystem and then mimicking the same execution outsideof the guest system [16]. With deep understanding of theAndroid kernel, DroidScope is able to intercept certainkernel functions and traverse proper kernel data struc-tures to reconstruct the OS level view. In comparison,DroidScope takes it one step further to reconstruct theDalvik/Java view, such that both Java and native compo-nents from an App can be analyzed simultaneously andseamlessly.

Dynamic Binary Instrumentation PIN [27], Dy-namoRIO [5], and Valgrind [32] are powerful dynamicinstrumentation tools that analyze user-level programs.They are less ideal for malware analysis, because theyshare the same memory space with user-level mal-ware and thus can be subverted. Bernat et al. useda formal model to identify observable differences dueto instrumentation of sensitive instructions and createda sensitivity-resistant instrumentation tool called SR-Dyninst [4]. Like the other tools though, it cannot beused to analyze kernel-level malware.

Anubis [1], PinOS [7], TEMU [35], and Ether [15] arebased on CPU emulators and hypervisors. They have thefull system view of the guest system and thus are bettersuited for malware analysis. These systems only sup-port the x86 architecture and Ether, in principle, cannotsupport ARM, because it relies on the hardware virtual-ization technology on x86. A new port must be devel-oped for ARM virtualization [30]. While Atom basedmobile platforms are available, ARM still dominates theAndroid market and thus ARM based analysis is impor-tant. To the best of our knowledge, DroidScope is thefirst fine-grained dynamic binary instrumentation frame-work that supports the ARM architecture and provides acomprehensive interface for Android malware analysis.We do not however support control flow tainting or dif-ferent tainting profiles like Dytan [10]. Since Dytan is

13

based on PIN, it is theoretically feasible to port the toolto PIN for ARM [23], although it will still be limited toanalyzing user-level malware.

Dalvik Analysis Tools Enck et al. used ded to convertDalvik bytecode into Java bytecode and soot to furtherconvert it into Java source code to identify data flowviolations [20]. While powerful, the authors note thatsome violations could not be identified due to code re-covery failures. DroidRanger is a static analysis tool thatoperates on Dalvik bytecode directly and was success-ful in identifying previously unknown malicious Apps inAndroid marketplaces [41]. TaintDroid and DroidBoxare two examples of dynamic analysis tools for Androidapplications [17, 19]. TaintDroid is a specially craftedDVM that supports taint analysis of Dalvik instructionsand across API calls. DroidBox is a project that usesTaintDroid to build an android application sandbox foranalysis purposes. The biggest advantage of using Taint-Droid is that it runs on actual devices. All of the hard-ware, sensors, vendor software and unpredictable intrica-cies that come with a real device are there. This can’t beachieved in an emulated environment. The major nega-tive of all these tools is that they are limited to analyzingthe Java portion of Apps. Thus, if there is a native com-ponent, like DroidKungFu has, they will not be able tofully analyze it.

9 ConclusionWe presented DroidScope, a fine grained dynamic binaryinstrumentation tool for Android that rebuilds two lev-els of semantic information: operating system and Java.This information is provided to the user in a unified in-terface to enable dynamic instrumentation of both theDalvik bytecode as well as native instructions. In thismanner, the analyst is able to reveal the behavior of amalware sample’s Java and native components as wellas interactions between them and the rest of the systemas evidenced by the successful analysis of DroidKungFuand DroidDream using DroidScope. These capabilitiesare provided to the analyst without changing the guestAndroid system and particularly with JIT intact. Our per-formance evaluation showed the benefits of dynamicallydisabling JIT for targeted analysis such as API tracing.The overall performance seems reasonable as well.

AcknowledgementsWe thank the anonymous reviewers for their insightfulcomments towards improving this paper. This work issupported in part by the US National Science Founda-tion NSF under Grants #1018217 and #1054605. Anyopinions, findings, and conclusions made in this materialare those of the authors and do not necessarily reflect theviews of the NSF or the Air Force Research Laboratory.

References[1] Anubis: Analyzing Unknown Binaries. http://anubis.

iseclab.org/.

[2] BALZAROTTI, D., COVA, M., KARLBERGER, C., KRUEGEL,C., KIRDA, E., AND VIGNA, G. Efficient Detection of SplitPersonalities in Malware. In Proceedings of the Network andDistributed System Security Symposium (NDSS) (San Diego, CA,February 2010).

[3] BELLARD, F. QEMU, a fast and portable dynamic translator.In USENIX Annual Technical Conference, FREENIX Track (April2005).

[4] BERNAT, A. R., ROUNDY, K., AND MILLER, B. P. Efficient,sensitivity resistant binary instrumentation. In Proceedings of the2011 International Symposium on Software Testing and Analysis(New York, NY, USA, 2011), ISSTA ’11, ACM, pp. 89–99.

[5] BRUENING, D., GARNETT, T., AND AMARASINGHE, S. An in-frastructure for adaptive dynamic optimization. In InternationalSymposium on Code Generation and Optimization (CGO’03)(March 2003).

[6] BRUMLEY, D., HARTWIG, C., KANG, M. G., LIANG, Z., NEW-SOME, J., POOSANKAM, P., AND SONG, D. BitScope: Auto-matically dissecting malicious binaries. Tech. Rep. CS-07-133,School of Computer Science, Carnegie Mellon University, Mar.2007.

[7] BUNGALE, P. P., AND LUK, C.-K. PinOS: a programmableframework for whole-system dynamic instrumentation. In Pro-ceedings of the 3rd international conference on Virtual executionenvironments (2007), VEE ’07, pp. 137–147.

[8] CHENG, B., AND BUZBEE, B. A JIT com-piler for android’s dalvik VM. http://www.google.com/events/io/2010/sessions/jit-compiler-androids-dalvik-vm.html, 2010.Google I/O.

[9] CHIPOUNOV, V., KUZNETSOV, V., AND CANDEA, G. S2E: Aplatform for in-vivo multi-path analysis of software systems. InProceedings of the 16th International Conference on ArchitecturalSupport for Programming Languages and Operating Systems (AS-PLOS) (Mar. 2011).

[10] CLAUSE, J., LI, W., AND ORSO, A. Dytan: a generic dynamictaint analysis framework. In Proceedings of the 2007 Interna-tional Symposium on Software Testing and Analysis (ISSTA’07)(2007), pp. 196–206.

[11] CRANDALL, J. R., AND CHONG, F. T. Minos: Control dataattack prevention orthogonal to memory model. In Proceedingsof the 37th International Symposium on Microarchitecture (MI-CRO’04) (December 2004).

[12] Cve-2009-1185. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1185.

[13] ded: Decompiling Android Applications. http://siis.cse.psu.edu/ded/index.html.

[14] Dynamic, metamorphic (and opensource) virtual machines.http://archive.hack.lu/2010/Desnos_Dynamic_Metamorphic_Virtual_Machines-slides.pdf.

[15] DINABURG, A., ROYAL, P., SHARIF, M., AND LEE, W. Ether:malware analysis via hardware virtualization extensions. In Pro-ceedings of the 15th ACM Conference on Computer and Commu-nications Security (2008), pp. 51–62.

[16] DOLAN-GAVITT, B., LEEK, T., ZHIVICH, M., GIFFIN, J., ANDLEE, W. Virtuoso: Narrowing the semantic gap in virtual ma-chine introspection. In Proceedings of the 2011 IEEE Symposiumon Security and Privacy (Washington, DC, USA, 2011), SP ’11,IEEE Computer Society, pp. 297–312.

14

[17] Droidbox: Android application sandbox. http://code.google.com/p/droidbox/.

[18] EGELE, M., KRUEGEL, C., KIRDA, E., YIN, H., AND SONG, D.Dynamic Spyware Analysis. In Proceedings of the 2007 UsenixAnnual Conference (Usenix’07) (June 2007).

[19] ENCK, W., GILBERT, P., CHUN, B.-G., COX, L. P., JUNG, J.,MCDANIEL, P., AND SHETH, A. N. Taintdroid: an information-flow tracking system for realtime privacy monitoring on smart-phones. In Proceedings of the 9th USENIX conference on Op-erating systems design and implementation (Berkeley, CA, USA,2010), OSDI’10, USENIX Association, pp. 1–6.

[20] ENCK, W., OCTEAU, D., MCDANIEL, P., AND CHAUDHURI,S. A study of android application security. In Proceedings of the20th USENIX Security Symposium (2011).

[21] GARFINKEL, T., AND ROSENBLUM, M. A virtual machine in-trospection based architecture for intrusion detection. In Pro-ceedings of Network and Distributed Systems Security Symposium(NDSS’03) (February 2003).

[22] Gartner says sales of mobile devices grew 5.6 percent in thirdquarter of 2011; smartphone sales increased 42 percent. http://gartner.com/it/page.jsp?id=1848514, 2011.

[23] HAZELWOOD, K., AND KLAUSER, A. A dynamic binary in-strumentation engine for the arm architecture. In Proceedingsof the 2006 international conference on Compilers, architectureand synthesis for embedded systems (New York, NY, USA, 2006),CASES ’06, ACM, pp. 261–270.

[24] JIANG, X., WANG, X., AND XU, D. Stealthy malware detectionthrough vmm-based ”out-of-the-box” semantic view reconstruc-tion. In Proceedings of the 14th ACM conference on Computerand Communications Security (CCS’07) (October 2007).

[25] Security alert: New sophisticated android malware droidkungfufound in alternative chinese app markets. http://www.csc.ncsu.edu/faculty/jiang/DroidKungFu.html.

[26] KANG, M. G., YIN, H., HANNA, S., MCCAMANT, S., ANDSONG, D. Emulating emulation-resistant malware. In Pro-ceedings of the 2nd Workshop on Virtual Machine Security (VM-Sec’09) (November 2009).

[27] LUK, C.-K., COHN, R., MUTH, R., PATIL, H., KLAUSER, A.,LOWNEY, G., WALLACE, S., REDDI, V. J., AND HAZELWOOD,K. Pin: Building customized program analysis tools with dynamicinstrumentation. In Proc. of 2005 Programming Language Designand Implementation (PLDI) conference (june 2005).

[28] MARTIGNONI, L., MCCAMANT, S., POOSANKAM, P., SONG,D., AND MANIATIS, P. Path-exploration lifting: Hi-fi tests forlo-fi emulators. In Proceedings of the 17th International Confer-ence on Architectural Support for Programming Languages andOperating Systems (ASPLOS) (London, UK, Mar. 2012).

[29] MARTIGNONI, L., PALEARI, R., ROGLIA, G. F., AND BR-USCHI, D. Testing cpu emulators. In Proceedings of the 18thInternational Symposium on Software Testing and Analysis (IS-STA’09) (2009), pp. 261–272.

[30] MIJAR, R., AND NIGHTINGALE, A. Virtualization is coming toa platform near you. Tech. rep., ARM Limited, 2011.

[31] MOSER, A., KRUEGEL, C., AND KIRDA, E. Exploring mul-tiple execution paths for malware analysis. In Proceedings ofthe 2007 IEEE Symposium on Security and Privacy(Oakland’07)(May 2007).

[32] NETHERCOTE, N., AND SEWARD, J. Valgrind: a framework forheavyweight dynamic binary instrumentation. In PLDI (2007),pp. 89–100.

[33] PORTOKALIDIS, G., SLOWINSKA, A., AND BOS, H. Argos:an emulator for fingerprinting zero-day attacks. In EuroSys 2006(April 2006).

[34] Proguard. http://proguard.sourceforge.net.

[35] TEMU: The BitBlaze dynamic analysis component. http://bitblaze.cs.berkeley.edu/temu.html.

[36] YAN, L.-K., JAYACHANDRA, M., ZHANG, M., AND YIN, H.V2E: Combining hardware virtualization and software emulationfor transparent and extensible malware analysis. In Proceedings ofthe Eighth Annual International Conference on Virtual ExecutionEnvironments (VEE’12) (March 2012).

[37] YIN, H., LIANG, Z., AND SONG, D. HookFinder: Identifyingand understanding malware hooking behaviors. In Proceedings ofthe 15th Annual Network and Distributed System Security Sympo-sium (NDSS’08) (February 2008).

[38] YIN, H., AND SONG, D. Temu: Binary code analysis via whole-system layered annotative execution. Tech. Rep. UCB/EECS-2010-3, EECS Department, University of California, Berkeley,Jan 2010.

[39] YIN, H., SONG, D., MANUEL, E., KRUEGEL, C., AND KIRDA,E. Panorama: Capturing system-wide information flow for mal-ware detection and analysis. In Proceedings of the 14th ACMConferences on Computer and Communication Security (CCS’07)(October 2007).

[40] ZHOU, Y., AND JIANG, X. Dissecting android malware: Char-acterization and evolution. In Proceedings of the 33rd IEEE Sym-posium on Security and Privacy (Oakland 2012) (San Francisco,CA, USA, May 2012), IEEE.

[41] ZHOU, Y., WANG, Z., ZHOU, W., AND JIANG, X. Hey, you, getoff of my market: Detecting malicious apps in official and alter-native android markets. In Proceedings of the 19th Network andDistributed System Security Symposium (San Diego, CA, Febru-ary 2012).

A Trace-Based Exploit Diagnosis of “ratc”In this section, we provide an example of exploit diagno-sis using DroidScope and the ARM instruction tracer on“ratc”. These results corroborate with publicly availableinformation on “ratc” and the setuid exhaustion vulnera-bility.

We know that adbd is supposed to downgrade its priv-ileges by setting its uid to AID SHELL (2000), and yetadbd retained its root privileges after the attack. Thus,in an effort to identify the root cause of the vulnerability,we used DroidScope to gather an ARM instruction tracethat includes both user and kernel code.

A simplified and annotated log is shown in Figure 13.In the log, the instruction’s address comes first fol-lowed by a colon, the decoded instruction and then theoperands. We have also indented the instructions to il-lustrate the relative stack depth.

The log begins when setgid returns from the ker-nel space and returns back to adb main at address0x0000c3a4. Almost immediately, the log shows setuidbeing called. After transitioning into kernel mode, wesee sys setuid being called followed by a call to set user.Later we see set user returning an error code 0xfffffff5which is (-11 in 2’s complement or -EAGAIN).

Tracing backwards in the log reveals that this errorcode was the result of the RLIMIT NPROC check inset user. This reveals why setuid failed to downgrade

15

;;;setgid returns from kernel back to adbd0000813c: pop {r4, r7}00008140: movs r0, r000008144: bxpl lr : Read Oper[0]. R14, Val = 0xc3a5;; Return back to 0xc3a4 (caller) in Thumb mode

;;;adbd_main sets up for setuid0000c3a4: movs r0, #2500000c3a6: lsls r0, r0, #3 : Write Oper[0]. R0, Val = 0x7d0

;; 250 * 8 = 0x7d0 = 2000 = AID_SHELL

...

;;;Start of setuid section;;; 213 is syscall number for sys_setuid00008be0: push {r4, r7} : Write Oper[0]. M@be910bb8, Val = 0x7d0

;; push AID_SHELL onto the stack00008be4: mov r7, #21300008be8: svc 0x00000000

;; Make sys call

;;; === TRANSITION TO KERNEL SPACE ===

;;;sys_setuid then calls set_user in kernel mode

;;;inside sys_setuid;; Has rlimit been reached?c0048944: cmp r2, r3 : Read Oper[0]. R3, Val = 300 Read Oper[1]. R2, Val = 300

;;; RLIMIT(300) is reached and !init_user so return -11c0048960: mvn r0, #10 : Write Oper[0]. R0, Val = 0xfffffff5

;; the return value is now -11 or -EAGAINc0048964: ldmib sp, {r4, r5, r6, fp, sp, pc}

;;;Return back to sys_setuid which returns back to userspace

;;; === RETURN TO USERSPACE ===

;;;setuid continues00008bec: pop {r4, r7}00008bf0: movs r0, r0 : Read Oper[0]. R0, Val = 0xfffffff5

;; -11 is still here

;;;Return back to adb_main at 0xc3ac (the return address) above;;; Immediately starts other work, does not check return code0000c3ac: ldr r7, [pc, #356] : Read Oper[0]. M@0000c514, Val = 0x19980330

Write Oper[0]. R7, Val = 0x19980330;; 0x19980330 is _LINUX_CAPABILITY_VERSION

Figure 13: Annotated adbd trace

adbd’s privileges. Further analysis of the log shows thatthe return value from setuid was not used by adbd norwas a call to getuid seen. The same applies to setgid.This indicates that adbd failed to ensure that it is nolonger running as root. Thus, our analysis shows thatthe vulnerability is due to two factors, RLIMIT NPROCand failure to check the return code by adbd.

16