Embed Size (px)
Citation preview
Aurasium: Practical Policy Enforcement for Android Applications
Rubin XuComputer Laboratory
University of CambridgeCambridge, UK
Hassen SaıdiComputer Science Laboratory
SRI InternationalMenlo Park, USA
Ross AndersonComputer Laboratory
University of CambridgeCambridge, UK
AbstractThe increasing popularity of Google’s mobile platformAndroid makes it the prime target of the latest surge inmobile malware. Most research on enhancing the plat-form’s security and privacy controls requires extensivemodification to the operating system, which has signif-icant usability issues and hinders efforts for widespreadadoption. We develop a novel solution called Aurasiumthat bypasses the need to modify the Android OS whileproviding much of the security and privacy that users de-sire. We automatically repackage arbitrary applicationsto attach user-level sandboxing and policy enforcementcode, which closely watches the application’s behaviorfor security and privacy violations such as attempts to re-trieve a user’s sensitive information, send SMS covertlyto premium numbers, or access malicious IP addresses.Aurasium can also detect and prevent cases of privilegeescalation attacks. Experiments show that we can applythis solution to a large sample of benign and maliciousapplications with a near 100 percent success rate, with-out significant performance and space overhead. Aura-sium has been tested on three versions of the AndroidOS, and is freely available.
1 Introduction
Google’s Android OS is undoubtedly the fastest grow-ing mobile operating system in the world. In July 2011,Nielsen placed the market share of Android in the U.S.at 38 percent of all active U.S. smartphones [9]. Weekslater, for the period ending in August, Nielsen found thatAndroid has risen to 43 percent. More important, amongthose who bought their phones in June, July, or August,Google had a formidable 56 percent market share. Thisunprecedented growth in popularity, together with theopenness of its application ecosystem, has attracted ma-licious entities to aggressively target Android. Attackson Android by malware writers have jumped by 76 per-cent over the past three months according to a report by
MacAfee [29], making it the most assaulted mobile op-erating system during that period. While much of theinitial wave of Android malware consisted of trojans thatmasquerade as legitimate applications and leak a user’spersonal information or send SMS messages to premiumnumbers, recent malware samples indicate an escalationin the capability and stealth of Android malware. In par-ticular, attempts are made to gain root access on the de-vice through escalation of privilege [37] to establish astealthy permanent presence on the device or to bypassAndroid permission checks.
Fighting malware and securing Android-powered de-vices has focused on three major directions. The firstone consists of statically [20] and dynamically [12, 36]analyzing application code to detect malicious activitiesbefore the application is loaded onto the user’s device.The second consists of modifying the Android OS to in-sert monitoring modules at key interfaces to allow theinterception of malicious activity as it occurs on the de-vice [19, 27, 17, 33, 13]. The third approach consists ofusing virtualization to implement rigorous separation ofdomains ranging from lightweight isolation of applica-tions on the device [35] to running multiple instances ofAndroid on the same device through the use of a hyper-visor [26, 30, 11].
Two fundamental and intertwined problems plaguethese approaches. The first is that the definition of ma-licious behavior in an Android application is hard to as-certain. Access to privacy- and security-relevant partsof Android’s API is controlled by an install-time appli-cation permission system. Android users are informedabout what data and resources an application will haveaccess to, and user consent is required before the appli-cation can be installed. These explicit permissions aredeclared in the application package. Install-time permis-sions provide users with control over their privacy, butare often coarse-grained. A permission granted at installtime is granted as long as the application is installed onthe device. While an application might legitimately re-
quest access to the Internet, it is not clear what connec-tions it may establish with remote servers that may bemalicious. Similarly, an application might legitimatelyrequire sending SMS messages. Once the SMS permis-sion is granted, there are no checks to prevent the appli-cation from sending SMS messages to premium numberswithout user consent. In fact, the mere request for SMSpermission by an application can be deemed maliciousaccording to a recent Android applications analysis [24],where it is suggested that 82 percent of malicious ap-plications require permissions to access SMS. A recentsurvey [18] exposes many of the problems [22, 14] as-sociated with application components interactions, dele-gation of permission, and permission escalation attacksdue to poor or missing security policy specifications bydevelopers. This prompted early work [21] on securitypolicy extension for Android.
The second problem is that any approach so far thatattempts to enhance the platform’s security and privacycontrols based on policy extensions requires extensivemodification to the operating system. This has significantusability issues and hinders any efforts for widespreadadoption. There exists numerous tablet and phone mod-els with different hardware configurations, each runninga different Android OS version with its own customiza-tions and device drivers. This phenomenon, also knownas the infamous Android version fragmentation problem[16] demonstrates that it is difficult to provide a custom-built Android for all possible devices in the wild. Andit is even more difficult to ask a normal user to applythe source patch of some security framework and com-pile the Android source tree for that user’s own device.These issues will prevent many OS-based Android secu-rity projects from being widely adopted by the normalusers. Alternatively, it is equally difficult to bring to-gether Google, the phone manufacturers, and the cellularproviders to introduce security extensions at the level ofthe consumer market, due to misaligned incentives fromdifferent parties.
Our Approach We aim at addressing these challengesby providing a novel, simple, effective, robust, and de-ployable technology called Aurasium. Conceptually, wewant Aurasium to be an application-hardening service: auser obtains arbitrary Android applications from poten-tially untrusted places, but instead of installing the ap-plication as is, pushes the application through the Aura-sium black box and gets a hardened version. The userthen installs this hardened version on the phone, assuredby Aurasium that all of the application’s interactions areclosely monitored for malicious activities, and policiesprotecting the user’s privacy and security are actively en-forced.
Aurasium does not need to modify the Android OS
at all; instead, it enforces flexible security and privacypolices to arbitrary applications by repackaging to at-tach sandboxing code to the application itself, which per-forms monitoring and policy enforcement. The repack-aged application package (APK) can be installed on auser’s phone and will enforce at runtime any definedpolicy without altering the original APK’s functionali-ties. Aurasium exploits Android’s unique application ar-chitecture of mixed Java and native code execution toachieve robust sandboxing. In particular, Aurasium in-troduces libc interposition code to the target application,wrapping around the Dalvik virtual machine (VM) underwhich the application’s Java code runs. The target appli-cation is also modified such that the interposition hooksget placed each time the application starts.
Aurasium is able to interpose almost all types of in-teractions between the application and the OS, enablingmuch more fine-grained policy enforcement than An-droid’s built-in permission system. For instance, when-ever an application attempts to access a remote site on theInternet, the IP of the remote server is checked againstan IP blacklist. Whenever an application attempts tosend an SMS message, Aurasium checks whether thenumber is a premium number. Whenever an applica-tion tries to access private information such as the In-ternational Mobile Equipment Identity (IMEI), the Inter-national Mobile Subscriber Identity (IMSI), stored SMSmessages, contact information, or services such as cam-era, voice recorder, or location, a policy check is per-formed to allow or disallow the access. Aurasium alsomonitors I/O operations such as write and read. We eval-uated Aurasium against a large number of real-world An-droid applications and achieved over 99 percent successrate. Repackaging an arbitrary application using Aura-sium is fast, requiring an average of 10 seconds.
Our main contributions are that
• We have built an automated system to repackagearbitrary APKs where arbitrary policies protectingprivacy and ensuring security can be enforced.
• We have developed a set of policies that take advan-tage of advances in malware intelligence such as IPblacklisting.
• We provide a way of protecting users from mali-cious applications without making any changes tothe underlying Android architecture. This makesAurasium a technology that can be widely de-ployed.
• Aurasium is a robust technology that was tested onthree versions of Android. It has low memory andruntime overhead and, unlike other approaches, ismore portable across the different OS versions.
2
The paper is organized as follows: Section 2 providesthe some background information on the architecture ofAndroid and then goes through details about the archi-tecture, enforceable policies and deployment methods ofAurasium. In Section 3 we evaluate Aurasium with re-spect to its robustness in repackaging applications, aswell as the overhead introduced by the repackaging pro-cess. Section 4 describes threat models against Aurasiumand mitigation techniques. Related work and conclusionsare discussed in Section 5 and Section 6, respectively.
2 Aurasium
2.1 AndroidAndroid, the open source mobile operating system de-veloped by the Open Handset Alliance led by Google,is gaining increasing popularity and market share amongsmartphones. Built on top of a Linux 2.6 kernel, Androidintroduces a unique application architecture designed toensure performance, security, and application portabil-ity. Rigorous compartmentalization of installed applica-tions is enforced through traditional Linux permissions.Additional permission labels are assigned to applicationsduring install time to control the application’s access tosecurity and privacy-sensitive functionalities of the OS,forming a mandatory access-control scheme.
Android employs an inter-process communication(IPC) mechanism called Binder [6] extensively for inter-actions between applications as well as for application-OS interfaces. Binder is established by a kernel driverand exposed as a special device node on which individ-ual applications operate. Logically, the IPC works on theprinciple of thread migration. A thread invoking an IPCcall with Binder appears as if it migrates into the targetprocess and executes the code there, hopping back whenthe result is available. All the hard work such as takingcare of argument marshalling, tracking object referencesacross processes, and recursions of IPC calls is handledby Binder itself.
Android applications are mainly implemented in Java,with the compiled class files further converted intoDalvik bytecode, running on the proprietary register-based Dalvik VM. It is similar to the JVM, but designedfor a resource-constrained environment with a highercode density and smaller footprint. Applications aretightly coupled with a large and function-rich Androidframework library (c.f. J2SE). Also, applications arefree to include compiled native code as standalone Linuxshared object (.so) files. The interaction between an ap-plication’s Java and native code is well defined by theJava Native Interface (JNI) specification and supportedby Android’s Native Development Kit (NDK). In reality,the complexity of using native code means that only a
small number of applications employ native code for themost performance-critical tasks.
2.2 System Design
Aurasium is made up of two major components: therepackaging mechanism that inserts instrumentationcode into arbitrary Android applications and the moni-toring code that intercepts an application’s interactionswith the system and enforces various security policies.The repackaging process makes use of existing opensource tools augmented with our own glue logic to re-engineer Android applications. The monitoring code em-ploys user-level sandboxing and interposition to interceptthe application’s interaction with the OS. Aurasium isalso able to reconstruct the high-level IPC communica-tion from the low-level system call data, which allows itto monitor virtually all of Android’s APIs.
2.2.1 Application-OS Interaction
Under the hood, some of Android’s OS APIs are han-dled by the kernel directly, while others are implementedat user-mode system services and are callable via inter-process communication methods. However, in almost allscenarios the application does not need to distinguish be-tween the two, as these APIs have already been fully en-capsulated in the framework library and the applicationsjust need to interact with the framework through well-documented interfaces. Figure 1 shows in detail the lay-ers of the framework library in individual applications’address space.
Application Code
Framework Code - Java
Framework Code - Native (C++)
Java Native Interface
libandroid runtime.solibdvm.so libbinder.so
libc.solibm.so libstdc++.soKernel Boundary
Process Boundary
Linux Kernel
Aurasium
Figure 1: Android Application and Framework Structure
The top level of the framework is written in Java and isthe well-documented part of the framework with whichapplications interact. This hides away the cumbersome
3
details from the application’s point of view, but in orderto realize the required operations it will hand over the re-quest to the low-level part of the framework implementedin native code. The native layer of the framework con-sists of a few shared objects that do the real work, such ascommunicating with the Dalvik VM or establishing themechanism for IPC communication. If we dive lower,we find that these shared objects are in fact also relyingon shared libraries at even lower levels. There, we findAndroid’s standard C libraries called Bionic libc. TheBionic libc will initiate appropriate system calls into thekernel that completes the required operation.
For example, if the application wants to download afile from the Internet, it has multiple ways to do so, rang-ing from fully managed HttpURLConnection class tolow-level Socket access. No matter what frameworkAPIs the application decides to use, they will all landon the connect() method in the OSNetworkSystem
Java class in order to create the underlying TCP socket.This connect() method in turn transfers control tolibnativehelper.so, one of the shared objects in thenative layer of the framework, which again delegatesthe request to the connect() method in libc.so. Thesocket is finally created by libc issuing a system call intothe Linux kernel.
No matter how complex the upper layer framework li-brary may be, it will always have to go through appropri-ate functions in the Bionic libc library in order to interactwith the OS itself. This gives a reliable choke point atwhich the application’s interactions with the OS can beexamined and modified. The next section explains howfunction calls from the framework into libc can be inter-posed neatly.
2.2.2 Efficient Interposition
Similar to the traditional Linux model, shared objectsin Android are relocatable ELF files that are mappedinto the process’s address space when loaded. To savememory and avoid code duplication, all shared objectsshipped with Android are dynamically linked against theBionic libc library. Because a shared object like libc canbe loaded into arbitrary memory address, dynamic link-ing is used to resolve the address of unknown symbols atload time. For an ELF file that is dynamically linkedto some shared object, its call sites to the shared ob-ject functions are actually jump instructions to some stubfunction in the ELF’s procedure linkage table (PLT). Thisstub function then performs a memory load on some en-try in the ELF’s global offset table (GOT) in order to re-trieve the real target address of this function call to whichit then branches. In other words, the ELF’s global offsettable contains an array of function pointers of all dynam-ically linked external functions referenced by its code.
During dynamic linking this table is filled with appropri-ate function pointers; this is controlled by the metadatastored in the ELF file, such as which GOT entry maps towhich function in which shared object.
This level of indirection introduced by dynamic link-ing can be exploited to implement the required interpo-sition mechanism neatly: it is sufficient to go throughevery loaded ELF file and overwrite its GOT entries withpointers to our monitoring functions. This is equivalentto doing the dynamic linking again but substituting func-tion pointers of interposition routines1.
Because Java code is incapable of directly modifyingprocess memory, we implemented our interposition rou-tines in C++ and compiled them to native code. All thedetour functions are also implemented in C++ and theywill preprocess the relevant function call arguments be-fore feeding them to Aurasium’s policy logic. We try tominimize the amount of native code because it is gener-ally difficult to write and test. As a result most of thepolicy logic is implemented in Java, which also means itcan take advantage of many helper functions in the stan-dard Android framework. However, in the preprocessingstep of the IPC calls we make an effort to reconstructthe inter-process communication parameters as well ashigh-level Java objects out of marshalled byte streamsin our native code. It turns out that despite the systemchanges between Android 2.2, 2.3 and 3.x, the IPC pro-tocol remains largely unaffected2 and hence our interpo-sition code is able to run on all major Android versionsreliably.
With all these facilities in place, Aurasium is capa-ble of intercepting virtually all framework APIs and en-forcing many classes of security and privacy policies onthem. It remains to be discussed what policies we cur-rently implement (Section 2.3) and how reliable Aura-sium’s sandboxing mechanism is (Section 4). But beforethat, let us explain how we repackage an Android appli-cation such that Aurasium’s sandboxing code is inserted.
2.2.3 APK Repackaging
Android applications are distributed as a single file calledan Android Application Package (APK) (Figure 2). AnAPK file is merely a Java JAR archive containing thecompiled manifest file AndroidManifest.xml, the ap-plication’s code in the form of dex bytecode, compiledXML resources such as window layout and string con-stant tables, and other resources like images, sound andnative libraries. It also includes its own signature in aform identical to the standard Java JAR file signatures.
1We did not consider other advanced dynamic linking techniquessuch as lazy linking here because they are not adopted in the currentAndroid OS. They can be dealt with similarly.
2An exception is the introduction of Strict Mode from version
4
Android Package (.apk)
classes.dex resources.arsc
uncompiled resources
AndroidManifest.xml
AurasiumNative
Library
AurasiumComponentDeclaration
Decompiledsmali files
AurasiumJava Code
Figure 2: Android Application Package
Because the Aurasium code contains both a native li-brary for low-level interposition and high-level Java codethat executes the policy logic, we need a way of in-serting both into the target APK. Adding a native li-brary is trivial as native libraries are standalone Linuxshared object (.so) files and are stored as is. AddingJava code is slightly tricky because Android requires allthe application’s compiled bytecode to reside in a sin-gle file called classes.dex. To insert Aurasium’s Javacode into an existing application, we have to take theoriginal classes.dex, disassemble it back to a col-lection of individual classes, add Aurasium’s classes,and then re-assemble everything back to create the newclasses.dex.
There exist open source projects that can perform suchtask. For example, smali [7], an assembler/disassemblerfor dex files, and android-apktool [1], which is anintegrated solution that can process not only code butalso compiled resources in APK files.3 In Aurasium weadopt apktool in our repackaging process. In the de-code phase, apktool takes in an APK file, disassemblesits dex file, and produces a directory such that each byte-code file maps to a single Java class, and its path corre-sponds to the package hierarchy, together with all otherresources in the original APK file. Aurasium’s Java codeis then merged into the directory and apktool is en-gaged again to assemble the bytecode back into a newclasses.dex file. Together with other resources, a newAPK file is finally produced.
In reality, before producing the final APK file there isone more thing to do: merely merging Aurasium codeinto the target application does not automatically implythat it will run. We need to make sure that Aurasiumcode is invoked somehow, preferably before any of theoriginal application code, so that the application does notexecute any of its code before Aurasium’s sandboxing isestablished. One option would be to modify the applica-tion’s entry point so that it points to Aurasium. This turns
2.3 Gingerbread.3apktool is actually built on top of a fork of smali.
out to be not as easy as one might expect. Android appli-cations often possess many possible entry points, in thesense that every public application component includingactivity, service, broadcast receiver, and content providercan be invoked directly and hence they all act as entrypoints.
In Aurasium we take a different approach: TheAndroid SDK allows an application to specify anApplication class in its manifest file which willbe instantiated by the runtime whenever the applica-tion is about to start. By declaring Aurasium as thisApplication class, Aurasium runs automatically be-fore any other parts of the application. There is a smallcaveat that the original application may have already de-fined such Application class. In this case, we tracethe inheritance of this class until we find the root baseclass. This class will have to be inherited directly fromApplication, and we modify its definition (which isin the decompiled bytecode form) such that it inheritsfrom Aurasium’s Application class instead. This al-lows Aurasium to be instantiated as before, and beingthe root class ensures that Aurasium gets run before theapplication’s Application class is instantiated.
Figure 2 illustrates the composition of an APK and thevarious Aurasium modules added at repackaging time.
2.2.4 Application Signing
The last thing to worry about is that when an applicationis modified and repackaged, its signature is inevitablydestroyed and there is no way to re-sign the applica-tion under its original public key. We believe this is aproblem, but manageable. Every Android applicationis indeed required to have a valid signature, but signa-tures in Android work more like a proof of authorship,in the sense that applications signed by the same certifi-cate are believed to come from the same author, hencethey are trusted by each other and enjoy certain flexibil-ities within Android’s security architecture, e.g., signa-ture permission. Application updates are also requiredto be signed with the same certificate as the original ap-plication. Other than that, signatures impose few otherrestrictions, and developers often use self-signed certifi-cates for their applications.
This observation means that Aurasium can just re-sign the repackaged application using a new self-signedcertificate. To preserve the authorship relation, Aura-sium performs the re-signing step using a parallel setof randomly generated Aurasium certificates, maintain-ing a one-to-one mapping between this set to arbitrarydeveloper certificates. In other words, whenever Aura-sium is about to re-sign an application, it first verifiesthe validity of the old signature. If it passes, then Aura-sium will proceed to sign the application with its own
5
certificate that corresponds to the application’s originalcertificate, or a newly generated one if this applicationhas not been encountered earlier. In this way, the equiv-alence classes of authorship among applications are stillmaintained by Aurasium’s re-signing procedure. Prob-lems can still arise if Aurasium re-signs only a partial setof applications in the cases of application updates or ap-plications intending to cooperate with their siblings. Weconsider these cases non-severe, with one reason beingthat Aurasium is more likely to be applied to a standaloneapplication from a non-trusted source where applicationupdates and application cooperation are not common.
Because all private keys of the generated certificatesneed to be stored4 for future queries, the re-signing pro-cess contains highly confidential information and, hence,requires careful protection. It should be (physically) sep-arated from Aurasium’s other services and perceived asan oracle with minimal interfaces to allow re-signing analready-signed application. For higher assurance, hard-ware security modules could be used.
2.2.5 Aurasium’s Security Manager
Aurasium-wrapped applications are self-contained in thesense that the policy logic and the relevant user inter-face are included in the repackaged application bundle,and so are remembered user decisions stored locally inthe application’s data directory. Alternatively, AurasiumSecurity Manager (ASM) can also be installed, enablingcentral handling of policy decisions of all repackagedapplication on the device. Depending on the enforcedpolices at repackaging time, an application queries theASM for a policy decision via IPC mechanisms with in-tents describing the sensitive operation it is about to per-form, and the ASM either prompts the user for consent,uses a remembered user decision recorded earlier, or au-tomatically makes a decision without user interaction byenforcing a predefined policy embedded at repackagingtime. The policy logic in individual applications prefersdelegating policy decisions to the ASM, and will fallback to local decisions only if a genuine ASM instanceis not detected on the device.
Using ASM for central policy decision managementhas one major advantage: policy logic can be controlledglobally, and it can also be improved by updating theASM instance on the device. For example, IP addressblacklisting and whitelisting can be managed and keptup to date by ASM. Repackaged applications are ableto take advantage of better policy logics once ASM isupdated, even after they have been repackaged and de-ployed to users’ devices. There is a tradeoff between theflexibility of ASM and the efficiency of repackaged ap-
4Alternatively, these new certificates can be generated from theoriginal certificate under a master key.
plication, though. In extreme cases, a repackaged appli-cation can proxy every IPC call to ASM, but this wouldbe vastly inefficient. In our implementation ASM is con-sulted only with high-level summaries of potential sensi-tive operations, the set of which is fixed at repackagingtime.
2.3 PoliciesNow that we have demonstrated the ability to repackagearbitrary applications with Aurasium to insert monitor-ing code, we discuss various security policies that lever-age this technique. It is important to point out that theseare just some examples that we implemented as a proofof concept so far. Aurasium itself provides a flexibleframework under which many more potent policies arepossible.
We are interested primarily in enforcing some securitypolicy that protects the device from untrusted applica-tions. This includes not only attempts by the applicationto access sensitive information, leaking to the outsideworld or modifying it, but also attempts by the applica-tion to escalate privilege and to gain root access on thedevice by running suspicious system calls and loadingnative libraries. Aurasium’s architecture and design al-low us to implement many of the already-proposed poli-cies such as dynamically constraining permissions [33],or setting up default dummy IMEI and IMSI numbers aswell as phone numbers, as in [27].
The following subsections describe a set of policiesthat are easily checkable by Aurasium. The enforcementof these policies is supported by Aurasium interceptingthe following functions:
• ioctl()
This is the main API through which all IPCs aresent. By interposing this and reconstructing thehigh-level IPC communication, Aurasium is able tomonitor most Android system APIs and enforce theprivacy and SMS policies, and modifying the IPCarguments and results on the fly. In certain casessuch as content providers, Aurasium replaces the re-turned Cursor object with a wrapper class to allowfiner control over the returned data.
• getaddrinfo() and connect()
These functions are responsible for DNS resolvingand socket connection. Intercepting them allowsAurasium to control the application’s Internet ac-cess.
• dlopen(), fork() and execvp()
The loading of native code from Java and executionof external programs are provided by these func-tions, which Aurasium monitors.
6
• read(), write()
These functions reflect access to the file system. In-tercepting them allows Aurasium to control privateand shared files accesses.
• open() and reflection APIs in libdvm.so5
These functions are intercepted to prevent maliciousapplications from circumventing Aurasium’s sand-boxing. Because Aurasium may stores policy de-cisions in the application’s local directory, it mustprevent the application from tampering with the de-cision file. open() is hooked such that whenever itis invoked on the decision file it will check the JNIcall stack and allow only Aurasium code to success-fully open the file. The various reflection APIs arealso guarded to prevent malicious applications frommodifying Aurasium’s Java-based policy logic byreflection.
2.3.1 Privacy Policy
The most obvious set of policies that can be defined re-lates to users’ privacy. These policies protect the pri-vate data of the user such as the IMEI, IMSI, phonenumber, location, stored SMS messages, phone conver-sations, and contact list. These policies can be checkedby monitoring access to the system services provided bythe Framework APIs. While many APIs are availableto access system services, they all translate to a singlecall to the ioctl() system call. By monitoring calls toioctl(), and parsing the data that is transmitted in thecall, we are able to determine which service is being ac-cessed and alert the user.
Figure 3: Enforcement of Privacy Policies: Access toPhone Number
Figure 3 illustrates how Aurasium intercepts a requestmade by an application to access the user’s phone num-ber. Aurasium displays a warning message and prompts
5Dalvik java lang reflect Method invokeNative(),Dalvik java lang reflect Field setField() andDalvik java lang reflect Field setPrimitiveField()
the user to either accept the requested access or denyit. The user can also make Aurasium store that user’sanswer to the request so that the same request neverprompts the user for approval again and the cached an-swer is used instead. Finally, the user has the option toterminate the application.
Aurasium is capable of intercepting requests for theIMEI (Figure 4) and IMSI identifiers. Both the IMEI andIMSI numbers are often abused by applications to trackusers and devices for analytics and advertisement pur-poses, but are also used by malware to identify victims.
Similar policies are also implemented for accessingdevice location and contact list. In all of the above cases,if the user denies an request for the private information,Aurasium will provide shadow data to the application in-stead, similar to the approach in [27];
Figure 4: Enforcement of Privacy Policies: Access toIMEI from repackaged Android Market Security Toolmalware.
2.3.2 Preventing SMS Abuse
Figure 5 illustrates how Aurasium intercepts SMS mes-sages sent to a premium number, which is initiated by themalicious application AndroidOS.FakePlayer [2] foundin the wild. Aurasium displays the destination number aswell as the SMS’s content, so users can make informeddecision on whether to allow the operation or not. Inthis case, the malware is most likely to attempt to sub-scribe to some premium service covertly. We also ob-served malware NickySpy [3] leaking device IMEI viaSMS in another test run. We believe automatic classifi-cation on SMS number and content is possible to furtherreduce user intervention.
2.3.3 Network Policy
Similarly to the privacy policies, we enforce a set of net-work policies that regulate how an application is allowedto interact with the network. Since the Android permis-sion scheme allows unrestricted access to the Internetwhen an application is installed, we enforce finer-grained
7
Figure 5: Enforcement of SMS Sending
policies that are expressed as a combination of the fol-lowing:
• restrict the application to only a particular web do-main or set of IP addresses
• restrict the application from connecting to a remoteIP address known to be malicious
Figure 6: Enforcement of Network Policies: Access toan IP address with an unverified level of maliciousness
We use an IP blacklisting provided by the Bothunternetwork monitoring tool [4] to harvest information aboutmalicious IP addresses. For each connection, the serviceretrieves information about the remote location, and thewarning presented to the user indicates the level of ma-liciousness of the remote location (Figure 6). We alsodisplay the geo-location of the remote IP. It would bepossible to include more threat intelligence from variousdiverse sources.
2.3.4 Privilege Escalation Policy
In addition to the privacy policy and the network policy,we implement a policy that warns the user when a suspi-cious execvp is invoked. Aurasium intervenes wheneverthe application tries to execute external ELF binaries.
Knowing the attack signatures based on suspicious ex-ecutables can prevent certain types of escalation of priv-ilege attacks. Figure 7 illustrates an interception of thesu command. The Aurasium warning indicates that theapplication is trying to gain root access on a potentiallyrooted phone by executing the su command.
In another scenario, Aurasium warns the user when theapplication is about to load a native library. Maliciousnative code can interfere with Aurasium and potentiallybreak out of its sandbox, which we discuss further in sec-tion 4.
Figure 7: Enforcement of Privilege Escalation Policy
2.3.5 Automatic Embedding of policies
Our implementation allows us to naturally compare thebehavior of an application against a policy expressed notas a single event such as a single access to private data, toa system service or a single invocation of a system call,but as a sequence of such events. We plan on automat-ically embedding into an application code an arbitraryuser-defined policy expressible in an automaton.
2.4 Deployment ModelsDriven by the need for deployable mobile security solu-tions for Android and other platforms, we support mul-tiple deployment models for Aurasium. The unrestrictedand open nature of the Android Market allows us toprovide Aurasium hardened and repackaged applicationsto users directly. Here, we discuss several deploymentmodels for Aurasium that users can directly use withoutmodifying the Android OS on their phones.
2.4.1 Web Interface
We have a web interface6 that allows users to upload ar-bitrary applications and download the Aurasium repack-aged and hardened version. Aurasium can be employedto repackage any APKs that the user possesses.
6www.aurasium.com
8
2.4.2 Cooperation with Application Markets
We are exploring collaborations with Android marketsrun by mobile service providers to deploy Aurasium.Subscribers to the mobile service who get their applica-tions from the official Android market supported by themobile provider will have all their applications packagedwith Aurasium for protection.
2.4.3 Deployment in the Cloud
Another deployment model consists of writing a customdownload application that runs on a user’s phone so thatwhenever a user browses an Android market and wishesto download an application, the application is pulled andsent to the Aurasium cloud service where the applicationis repackaged and then downloaded to the user’s phone.This may be more accessible as users no longer need tointeract with Aurasium’s web interface manually.
2.4.4 Phone Deployment
Similarly to the cloud service, we plan on porting therepackaging tool to the Android phone itself. That is, wewill be able to repackage an application on the deviceitself.
2.4.5 Corporate Environment
Many corporations have security concerns about mobiledevices in their infrastructure and Aurasium can help toestablish the desired security and privacy polices on ap-plications to be installed on these devices. These An-droid devices should be configured to allow installingonly Aurasium-protected applications (by means of APKsignatures for example), while the applications can beprovided by some methods described above, such as aninternal repackaging service or a transparent repackagingproxy between the application market and the device.
3 Evaluation
We have evaluated Aurasium on a collection of Androidapplications to ensure that the application repackagingsucceeds and that our added code does not impede theoriginal functionality of the application. We have con-ducted a broad evaluation that includes a large number ofbenign applications as well as malware collection. Ourevaluation was conducted on a Samsung Nexus S phonerunning Android 2.3.6 “Gingerbread”.
3.1 Setting Up An Evaluation FrameworkAurasium consists of scripts that implement the repack-aging process described in Figure 2. It transforms each
APK file in the corpus to the corresponding hardenedrepackaged application. We scripted to load the applica-tion onto the Nexus S phone, start the application auto-matically, and capture the logs generated by Aurasium.Android Monkey [8] is used to randomly exercise theuser interface (UI) of the application.Monkey is a program running on Android that feeds
the application with pseudo-random streams of userevents such as clicks and touches, as well as a numberof system-level events. We use Monkey to stress-test therepackaged applications in a random yet repeatable man-ner. The captured logs allow us to determine whether theapplication has started and is being executed normally orwhether it crashes due to our repackaging process. As arandom fuzzer, Monkey is fundamentally unable to ex-ercise all execution paths of an application. But in oursetup, running random testing over a large number of in-dependent applications proves useful, covering most ofAurasium’s policy logic and revealing several bugs.
3.2 Repackaging EvaluationWe first performed an evaluation to determine how manyAPK files can successfully be repackaged by Aurasium.Table 1 shows a breakdown of the Android APK files cor-pus on which we ran our evaluation. We applied Aura-sium to 3491 applications crawled from a third-partyapplication store7 and 1260 known malicious applica-tions [39]. Table 1 shows the success rate of repackagingfor each category of applications.
Type of App #of Apps Repackaging SuccessRate
App store corpus 3491 99.6%(3476)Malware corpus 1260 99.8%(1258)
Table 1: Repackaging Evaluation Results
We have a near 100% success rate in repackaging ar-bitrary applications. Our failures to repackage an appli-cation are due to bugs in apktool in disassembling andreassembling the hardened APK file. We are working onimproving apktool to achieve a 100% success rate.
3.3 Runtime RobustnessAs we pointed out earlier, Aurasium is able to run onall major Android versions (2.2, 2.3, 3.x) without anyproblem. We performed the robustness evaluation on aSamsung Nexus S phone running Android 2.3.6 (whichis among the most widely used Android distributions
7http://lisvid.com
9
2.3.3− 2.3.7 [10]). For each hardened application weuse Monkey to exercise the application’s functionalitiesby injecting 500 random UI events. These hardened ap-plications are built with a debug version of Aurasiumthat will output a log message when Aurasium success-fully intercepts an API invocation. Out of 3476 suc-cessfully repackaged application, we performed tests on3189 standalone runnable applications8 on the device.We were able to start all of the applications in the sensethat Aurasium successfully reported the interception ofthe first API invocation for all of them.
3.4 Performance Evaluation
We take two Android benchmark applications from theofficial market and apply Aurasium to them in order tocheck if Aurasium introduces significant performanceoverhead to a real-world application. In both cases, thebenchmark scores turn out to be largely unaffected byAurasium (Table 2).
Benchmark App without withAurasium Aurasium
AnTuTu Benchmark 2900 Pts 2892 PtsBenchmarkPi 1280 ms 1293 ms
Table 2: Performance on Benchmark Applications
Aurasium introduces the most overhead when the ap-plication performs API invocations, which is not themost important test factor of these benchmarks. So wesynthesized an artificial application that performs a largenumber of API invocations, in order to find Aurasium’sperformance overhead in the worst cases. Because theseAPIs all involve IPC with remote system services, theyare expected to induce the most overhead as Aurasiumneeds to fully parse the Binder communication. Resultsin Table 3 show that Aurasium introduces an overheadof 14% to 35% in three cases, which we believe is ac-ceptable as IPC-based APIs are not frequently used bynormal applications to become the performance bottle-neck. In objective testing we did not feel any laggingwhen playing with an Aurasium-hardened application.
3.5 Size Overhead
We evaluated application size after being repackagedwith Aurasium code, as shown in Figure 8. On aver-age, Aurasium increases the application size by only 52
8The rest are applications that do not have a main launchable Activ-ity, and applications that fail to install due to clashes with pre-installedversion.
200 API Without With OverheadInvocations Aurasium AurasiumGet Device Info 106 ms 143 ms 35%Get Last Location 41 ms 55 ms 34%Query Contact List 1270 ms 1340 ms 14%
Table 3: Performance on Synthesized Application
Kb, which is a very small overhead for the majority ofapplications.
Size Increase After Repackaging / Kb
No.
of A
pps
20 40 60 80 100 120 140
020
4060
80
Mean: 52.2
Figure 8: Application Size Increase After Repackaging.
3.6 Policies EnforcementWe observe the various behaviors intercepted from the3031 runnable applications that were previously repack-aged and run on the Nexus S device under Monkey. Table4 shows a breakdown of the application corpus into per-mission requested in the manifest file of the applications.It also shows which applications actually make use of thepermission to access the requested service.
Permission Requested AccessedInternet Permission 2686 1305GPS Permission 846 132Phone State Permission 1243 378
Table 4: Permission Requested and Permissions Used
Due to the random fuzzing nature of our evaluation,
10
the accessed permission is most likely to be an underes-timate. We also observed that 226 applications includednative code libraries in their application bundle.
4 Attack Surfaces
Because fundamentally Aurasium code runs in the sameprocess context as the application’s code, there is nostrong barrier between the application and Aurasium.Hence, it is non-trivial to argue that Aurasium can re-liably sandbox arbitrary Android applications. We de-scribe possible ways that a malicious application canbreak out of Aurasium’s policy enforcement mechanismand discuss possible mitigation against them.
4.1 Native CodeAurasium relies on being able to intercept calls to Bioniclibc functions by means of rewriting function pointersin a module’s global offset table. This is robust againstarbitrary Java code, but a malicious application can em-ploy native code to bypass Aurasium completely eitherby restoring the global offset table entries, by makingrelevant system calls using its own libc implementationrather than going through the monitored libc, or by tam-pering with the code or private data of Aurasium. How-ever, because Android runtime requires applications tobootstrap as Java classes, the first load of native codein even malicious applications has to go through a well-defined and fixed pathway as defined by JNI. This givesus an upper hand in dealing with potential untrusted na-tive code: because of the way our repackaging processworks, Aurasium is guaranteed to start before the appli-cation’s code and hence be able to intercept the applica-tion’s first attempt to load alien native code (invocationof dlopen() function in libc). As a result, Aurasiumis guaranteed to detect any potential circumvention at-tempts by a malicious application.
What can Aurasium do with such an attempt? Silentlydenying the load of all native code is not satisfactory be-cause it will guarantee an application crash and somelegitimate applications use native code. Even thoughAurasium has the power to switch off the unknown na-tive code, the collateral damage caused by false positiveswould be too severe.
If Aurasium is to give binary decisions on whether ornot to load some unknown native code, then it reducesto the arms race between malware and antivirus softwarethat we have seen for years. Aurasium tries to classifynative code in Android applications, while malware au-thors craft and obfuscate it to avoid being detected. It isbetter not to go down the same road; and a much neaterapproach would be letting the native code run, but notwith unlimited power.
Previous work [28, 40, 34] on securely executing un-trusted native code provides useful directions for exam-ple, by using dynamic binary translation. In our sce-nario we are required to restrict the application’s nativecode from writing to guarded memory locations (to pre-vent tampering with Aurasium and the libc interpositionmechanism), using special machine instructions (to ini-tiate system calls without going through libc), and per-forming arbitrary control flow transfer into libc. Due totime constraints we have not implemented such facilitiesin Aurasium. Currently, Aurasium prompts the user fora decision, and informs the user that if the load is al-lowed then Aurasium can be rendered ineffective fromthis point onwards. We consider this problem a high pri-ority for future work.
Unlike the filtering-based hybrid sandboxes that areprone to the ‘time of check/time of use’ race condi-tions [25, 38], Aurasium’s sandboxing mechanism is del-egation based and hence much easier to defend againstthis class of attack.
4.2 Java CodeA possible attack on Aurasium would be using Java’sreflection mechanism to interfere with the operation ofAurasium. Because currently Aurasium’s policy en-forcement logic is implemented in Java, a malicious ap-plication can use reflection to modify Aurasium’s inter-nal data structures and hence affect its correct behavior.We prevent such attacks by hooking into the reflectionAPIs in libdvm.so and preventing reflection access toAurasium’s internal classes.
Note that dynamically loaded Java code (via Dex-ClassLoader) poses no threat to Aurasium, as the code isstill executed by the same Dalvik VM instance and hencecannot escape Aurasium’s sandbox. Native Java methodsmap to a dynamically loaded binary shared object libraryand are subject to the constraints discussed in the previ-ous section, which basically means that attempts of usingthem will always be properly flagged by Aurasium.
4.3 Red PillCurrently Aurasium is not designed to be stealthy. Theexistence of obvious traces such as changed applicationsignature, the existence of Aurasium native library andJava classes allow applications to find out easily whetherit is running under Aurasium or not. A malicious ap-plication can then refuse to run under Aurasium, forcingthe user to use the more dangerous vanilla version. Alegitimate application may also verify its own integrity(via application signature) to prevent malicious repack-aging by malware writers. Due to Aurasium’s controlover the application’s execution, it is possible to clean
11
up these traces for example by spoofing signature accessto PackageManager, but fundamentally this is an armsrace and a determined adversary will win.
5 Related Work
With the growing popularity of Android and the growingmalware threat it is facing, many approaches to secur-ing Android have been proposed recently. Many of thetraditional security approaches adopted in desktops havebeen migrated to mobile phones in general and Androidin particular. Probably the most standard approach is touse signature-based malware detection, which is in its in-fancy when it comes to mobile platforms. This approachis ineffective against zero-day attacks, and there is littlereason to believe that it will be more successful in themobile setting. Program analysis and behavioral analy-sis have been more successfully applied in the context ofAndroid.
Static Analysis Static analysis of Android applica-tion package files is relatively more straightforward thanstatic analysis of malware prevalent on desktops in gen-eral. Obfuscation techniques [41] used in today’s mal-ware are primarily aimed at impeding static analysis.Without effective ways to deobfuscate native binaries,static analysis will always suffer major drawbacks. Be-cause of the prevalence of malware on x86 Windowsmachines, little effort has been focusing on reverse en-gineering ARM binaries. Static analysis of Java codeis much more attainable through decompilation of theDalvik bytecode. The DED [20] and dex2jar [5] aretwo decompilers that aim at achieving translation fromDalvik bytecode to Java bytecode.
Dynamic Analysis Despite its limitations, dynamicanalysis remains the preferred approach among re-searchers and antivirus companies to profile malware andextract its distinctive features. The lack of automatedways to explore all the state space is often a hinderingfactor. Techniques such as multipath exploration [31]can be useful. However, the ability of mobile malwareto load arbitrary libraries might limit the effectiveness ofsuch techniques. The honeynet project offers a virtualmachine for profiling Android Applications [36] simi-lar to profiling desktop malware. Stowaway [23] is atool that detects overprivilege in compiled Android ap-plications. Testing is used on the Android API in orderto build the permission map that is necessary for detect-ing overprivilege, and static analysis is used to determinewhich calls an application invokes.
Monitoring The bulk of research related to securingAndroid has been focused on security policy exten-sion and enforcement for Android starting with [21].TaintDroid [19] taints private data to detect leakage ofusers’ private information modifying both Binder and theDalvik VM, but extends only partially to native code.Quire [17] uses provenance to track permissions acrossapplication boundaries through the IPC call chain to pre-vent permission escalation of privilege attacks. Crepe[15] allows access to system services requested throughinstall-time permission only in a certain context at run-time. Similarly, Apex [33] uses user-defined runtimeconstraints to regulate applications’ access to system ser-vices. AppFence [27] blocks application access to datafrom imperious applications that demand informationthat is unnecessary to perform their advertised function-ality, and covertly substitute shadow data in place. Air-mid [32] uses cooperation between in-network sensorsand smart devices to identify the provenance of malicioustraffic.
Virtualization Recent approaches to Android securityhave focused on bringing virtualization technology toAndroid devices. The ability to run multiple version ofthe Android OS on the same physical device allows forstrong separation and isolation but comes at a higher per-formance cost. L4Android [30] is an open source projectderived from the L4Linux project. L4Android combinesboth the L4Linux and Google modifications of the Linuxkernel and thus enables running Android on top of a mi-crokernel. To address the performance issues when us-ing virtualization, Cells in [11], is a lightweight virtu-alization architecture where multiple phones run on thesame device. It is possible to run multiple versions ofAndroid on a bare metal hypervisor and ensure strongisolation where shared security-critical device drivers runin individual virtual machines, which is demonstratedby [26]. Finally, logical domain separation, where twosingle domains are considered and isolation is enforcedas a dataflow property between the logical domains with-out running each domain as a separate virtual machine,can also be employed [35].
6 Conclusion and Future Work
We have presented Aurasium, a robust and effective tech-nology that protects users of the widely used Android OSfrom malicious and untrusted applications. Unlike manyof the security solutions proposed so far, Aurasium doesnot require rooting and device reflashing.
Aurasium allows us to take full control of the execu-tion of an application. This allows us to enforce arbi-trary policies at runtime. By using the Aurasium security
12
manager (ASM), we are able to not only apply policiesat the individual application level but across multiple ap-plications simultaneously. This allows us to effectivelyorchestrate the execution of various applications on thedevice and mediate their access to critical resources anduser’s private data. This allows us to also detect attemptsby multiple applications to collaborate and implement amalicious logic. With its overall low overhead and highrepackaging success rate, it is possible to imagine Aura-sium implementing an effective isolation and separationat the application layer without the need of complex vir-tualization technology.
Even though Aurasium currently only treats applica-tions as black boxes and focuses on its external behav-ior, the idea of enforcing policy at per-application levelby repackaging applications to attach side-by-side moni-toring code is very powerful. By carefully instrumentingthe application’s Dalvik VM instance on the fly, it is evenpossible to apply more advanced dynamic analysis suchas information flow and taint analysis, and we leave thisas a possible direction of future work. We also plan onexpanding our investigation of the potential threat mod-els against Aurasium and provide practical ways to mit-igate them, especially in the case of executing untrustednative code.
7 Acknowledgments
This material is based on work supported by the ArmyResearch Office under Cyber-TA Grant No. W911NF-06-1-0316 and by the National Science Foundation GrantNo. CNS-0716612.
References[1] Android apktool: A tool for reengineering Android apk files.
code.google.com/p/android-apktool/.
[2] Android.OS/Fakeplayer. www.f-secure.com/v-
descs/trojan\_androidos\_fakeplayer\_a.shtml.
[3] Android.OS/NickiSpy. www.maikmorgenstern.de/
wordpress/?tag=androidnickispy.
[4] Bothunter community threat intelligence feed.http://www.bothunter.net.
[5] dex2jar: A tool for converting Android’s .dex format to Java’s.class format. code.google.com/p/dex2jar/.
[6] OpenBinder. www.angryredplanet.com/~hackbod/
openbinder/docs/html/.
[7] smali: An assembler/disassembler for Android’s dex format.code.google.com/p/smali/.
[8] UI/Application exerciser Monkey. developer.android.com/
guide/developing/tools/monkey.html.
[9] In U.S. market, new smartphone buyers increasingly embrac-ing Android. blog.nielsen.com/nielsenwire/online_
mobile/, sep 2011.
[10] ANDROID OPEN SOURCE PROJECT. Platform versions.developer.android.com/resources/dashboard/
platform-versions.html.
[11] ANDRUS, J., DALL, C., HOF, A. V., LAADAN, O., AND NIEH,J. Cells: a virtual mobile smartphone architecture. In Pro-ceedings of the Twenty-Third ACM Symposium on Operating Sys-tems Principles (New York, NY, USA, 2011), SOSP ’11, ACM,pp. 173–187.
[12] BLASING, T., SCHMIDT, A.-D., BATYUK, L., CAMTEPE,S. A., AND ALBAYRAK, S. An Android application sand-box system for suspicious software detection. In 5th Interna-tional Conference on Malicious and Unwanted Software (MAL-WARE’2010) (Nancy, France, France, 2010).
[13] BURGUERA, I., ZURUTUZA, U., AND NADJM-TEHRANI, S.Crowdroid: behavior-based malware detection system for An-droid. In Proceedings of the 1st ACM Workshop on Securityand Privacy in Smartphones and Mobile devices (New York, NY,USA, 2011), SPSM ’11, ACM, pp. 15–26.
[14] CHIN, E., FELT, A. P., GREENWOOD, K., AND WAGNER, D.Analyzing inter-application communication in Android. In Pro-ceedings of the 9th International Conference on Mobile Systems,Applications, and Services (New York, NY, USA, 2011), Mo-biSys ’11, ACM, pp. 239–252.
[15] CONTI, M., NGUYEN, V. T. N., AND CRISPO, B. Crepe:context-related policy enforcement for Android. In Proceed-ings of the 13th International Conference on Information Security(Berlin, Heidelberg, 2011), ISC’10, Springer-Verlag, pp. 331–345.
[16] DEGUSTA, M. Android orphans: Visualizing a sad history ofsupport. theunderstatement.com/post/11982112928/
android-orphans-visualizing-a-sad-history-of-
support.
[17] DIETZ, M., SHEKHAR, S., PISETSKY, Y., SHU, A., AND WAL-LACH, D. S. Quire: lightweight provenance for smart phoneoperating systems. In Proceedings of the 20th USENIX Confer-ence on Security (Berkeley, CA, USA, 2011), SEC’11, USENIXAssociation, pp. 23–23.
[18] ENCK, W. Defending users against smartphone apps: Techniquesand future directions. In Proceedings of the 7th InternationalConference on Information Systems Security (Kolkata, India, dec2011), ICISS.
[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 Oper-ating 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 ofthe 20th USENIX conference on Security (Berkeley, CA, USA,2011), SEC’11, USENIX Association, pp. 21–21.
[21] ENCK, W., ONGTANG, M., AND MCDANIEL, P. On lightweightmobile phone application certification. In Proceedings of the16th ACM Conference on Computer and Communications Secu-rity (New York, NY, USA, 2009), CCS ’09, ACM, pp. 235–245.
[22] ENCK, W., ONGTANG, M., AND MCDANIEL, P. UnderstandingAndroid security. IEEE Security and Privacy 7 (January 2009),50–57.
[23] FELT, A. P., CHIN, E., HANNA, S., SONG, D., AND WAG-NER, D. Android permissions demystified. In Proceedings of the18th ACM Conference on Computer and Communications Secu-rity (New York, NY, USA, 2011), CCS ’11, ACM, pp. 627–638.
13
[24] FELT, A. P., FINIFTER, M., CHIN, E., HANNA, S., AND WAG-NER, D. A survey of mobile malware in the wild. In Proceed-ings of the 1st ACM Workshop on Security and Privacy in Smart-phones and Mobile Devices (Oct. 2011), SPSM ’11, ACM, pp. 3–14.
[25] GARFINKEL, T., PFAFF, B., AND ROSENBLUM, M. Ostia: Adelegating architecture for secure system call interposition. InProceedings of the Network and Distributed Systems SecuritySymposium (February 2004).
[26] GUDETH, K., PIRRETTI, M., HOEPER, K., AND BUSKEY, R.Delivering secure applications on commercial mobile devices:the case for bare metal hypervisors. In Proceedings of the 1stACM Workshop on Security and Privacy in Smartphones andMobile devices (New York, NY, USA, 2011), SPSM ’11, ACM,pp. 33–38.
[27] HORNYACK, P., HAN, S., JUNG, J., SCHECHTER, S., ANDWETHERALL, D. These aren’t the droids you’re looking for:retrofitting Android to protect data from imperious applications.In Proceedings of the 18th ACM Conference on Computer andCommunications Security (New York, NY, USA, 2011), CCS ’11,ACM, pp. 639–652.
[28] KIRIANSKY, V., BRUENING, D., AND AMARASINGHE, S. P.Secure execution via program shepherding. In Proceedings of the11th USENIX Security Symposium (Berkeley, CA, USA, 2002),USENIX Association, pp. 191–206.
[29] LABS, M. McAfee threats report: Second quarter2011. www.mcafee.com/us/resources/reports/rp-
quarterly-threat-q2-2011.pdf, aug 2011.
[30] LANGE, M., LIEBERGELD, S., LACKORZYNSKI, A., WARG,A., AND PETER, M. L4Android: a generic operating systemframework for secure smartphones. In Proceedings of the 1stACM Workshop on Security and Privacy in Smartphones andMobile devices (New York, NY, USA, 2011), SPSM ’11, ACM,pp. 39–50.
[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 (Washington,DC, USA, 2007), SP ’07, IEEE Computer Society, pp. 231–245.
[32] NADJI, Y., GIFFIN, J., AND TRAYNOR, P. Automated remoterepair for mobile malware. In Proceedings of the 2011 AnnualComputer Security Applications Conference (Washington, DC,USA, 2011), ACSAC ’10, ACM.
[33] NAUMAN, M., KHAN, S., AND ZHANG, X. Apex: extendingAndroid permission model and enforcement with user-definedruntime constraints. In Proceedings of the 5th ACM Symposiumon Information, Computer and Communications Security (NewYork, NY, USA, 2010), ASIACCS ’10, ACM, pp. 328–332.
[34] SCOTT, K., KUMAR, N., VELUSAMY, S., CHILDERS, B.,DAVIDSON, J. W., AND SOFFA, M. L. Retargetable and re-configurable software dynamic translation. In Proceedings ofthe international symposium on Code Generation and Optimiza-tion: feedback-directed and runtime optimization (Washington,DC, USA, 2003), CGO ’03, IEEE Computer Society, pp. 36–47.
[35] SVEN, B., LUCAS, D., ALEXANDRA, D., STEPHAN, H.,AHMAD-REZA, S., AND BHARGAVA, S. Practical andlightweight domain isolation on Android. In Proceedings of the1st ACM Workshop on Security and Privacy in Smartphones andMobile devices (New York, NY, USA, 2011), SPSM ’11, ACM,pp. 51–62.
[36] THE HONEYNET PROJECT. Android reverse engineering virtualmachine. www.honeynet.org/node/783.
[37] VIDAS, T., VOTIPKA, D., AND CHRISTIN, N. All your droid arebelong to us: a survey of current Android attacks. In Proceedings
of the 5th USENIX Workshop On Offensive Technologies (Berke-ley, CA, USA, 2011), WOOT’11, USENIX Association, pp. 10–10.
[38] WATSON, R. N. M. Exploiting concurrency vulnerabilities insystem call wrappers. In Proceedings of the first USENIX Work-shop On Offensive Technologies (Berkeley, CA, USA, 2007),USENIX Association, pp. 2:1–2:8.
[39] YAJIN, Z., AND XUXIAN, J. Dissecting android malware: Char-acterization and evolution. In Proceedings of the 33rd IEEE Sym-posium on Security and Privacy (may 2012).
[40] YEE, B., SEHR, D., DARDYK, G., CHEN, J. B., MUTH, R.,ORMANDY, T., OKASAKA, S., NARULA, N., AND FULLAGAR,N. Native client: a sandbox for portable, untrusted x86 nativecode. Commun. ACM 53 (January 2010), 91–99.
[41] YOU, I., AND YIM, K. Malware obfuscation techniques: A briefsurvey. In Proceedings of the 2010 International Conference onBroadband, Wireless Computing, Communication and Applica-tions (Washington, DC, USA, 2010), BWCCA ’10, IEEE Com-puter Society, pp. 297–300.
14
