Itamsoft.com

Electrical Engineering and Computer Science Evaluating Android Anti-malware against Transformation Attacks Vaibhav Rastogi, Yan Chen, and Xuxian Jiang† Northwestern University, †North Carolina State University Technical Report NU-EECS-13-01 Mobile malware threats (e.g., on Android) have recently become a real concern. Inthis paper, we evaluate the state-of-the-art commercial mobile anti-malware productsfor Android and test how resistant they are against various common obfuscationtechniques (even with known malware). Such an evaluation is important for not onlymeasuring the available defense against mobile malware threats but also proposingeffective, next-generation solutions. We developed DroidChameleon, a systematicframework with various transformation techniques, and used it for our study.
Our results on ten popular commercial anti-malware applications for Android areworrisome: none of these tools is resistant against common malware transformationtechniques. Moreover, a majority of them can be trivially defeated by applying slighttransformation over known malware with little effort for malware authors. Finally,in the light of our results, we propose possible remedies for improving the currentstate of malware detection on mobile devices.
Evaluating Android Anti-malware against Transformation Attacks Vaibhav Rastogi, Yan Chen, and Xuxian Jiang† Northwestern University, †North Carolina State University Abstract—Mobile malware threats (e.g., on Android) have existing anti-malware tools are largely not yet understood. In recently become a real concern. In this paper, we evaluate the the meantime, there are warnings that Android malware will state-of-the-art commercial mobile anti-malware products for become more sophisticated, we will soon see polymorphic Android and test how resistant they are against various common malware, and they will be able to quickly propagate from obfuscation techniques (even with known malware). Such anevaluation is important for not only measuring the available device to device using poisoned SMS messages and social defense against mobile malware threats but also proposing effec- network postings to infected links [5]. In fact, simple forms tive, next-generation solutions. We developed DroidChameleon, of polymorphic attacks have already been seen in the wild [6].
a systematic framework with various transformation techniques, It is thus imperative for mobile security systems to have good and used it for our study. Our results on ten popular commercial defenses against polymorphic strains.
anti-malware applications for Android are worrisome: none ofthese tools is resistant against common malware transformation To evaluate existing anti-malware software, we develop techniques. Moreover, a majority of them can be trivially defeated a systematic framework called DroidChameleon with sev- by applying slight transformation over known malware with little eral common transformation techniques that may be used to effort for malware authors. Finally, in the light of our results, transform Android applications automatically. Some of these we propose possible remedies for improving the current state of transformations are highly specific to the Android platform malware detection on mobile devices.
only. Based on the framework, we pass known malware sam-ples (from different families) through these transformations to generate new variants of malware, which are verified to Mobile computing devices such as smartphones and tablets possess the originals' malicious functionality. We use these are becoming increasingly popular. Unfortunately, this popu- variants to evaluate the effectiveness and robustness of popular larity attracts malware authors too. In reality, mobile malware anti-malware tools.
has already become a serious concern. It has been reported that Our results on ten popular anti-malware products, some of on Android, one of the most popular smartphone platforms [1], which even claim resistance against malware transformations, malware has constantly been on the rise and the platform show that all the anti-malware products used in our study have is seen as "clearly today's target" [2], [3]. With the growth little protection against common transformation techniques.
of malware, the platform has also seen an evolution of anti- The techniques themselves are simple. The fact that even malware tools, with a range of free and paid offerings now without much technical difficulty, we can evade anti-malware available in the official Android app market, Google Play.
tools, highlights the seriousness of the problem. Many of them In this paper, we aim to evaluate the efficacy of anti-malware succumb to even trivial transformations such as repacking or tools on Android in the face of various evasion techniques. For reassembling that do not involve any code-level transforma- example, polymorphism is a common obfuscation technique tion. This is in contrast to the general understanding, also that has been widely used by malware to evade detection substantiated by reports from the industry [7], [8], that mobile tools by transforming a malware in different forms ("morphs") anti-malware tools work quite well. Our evaluation dataset but with the same code. Metamorphism is another common includes products that these reports claim to be perfect or technique that can mutate code so that it no longer remains the nearly perfect. Our results also give insights about detection same but still has the same behavior. For ease of presentation, models used in existing anti-malware and their capabilities, we use the term polymorphism in this paper to represent thus shedding light on possible ways for their improvements.
both obfuscation techniques. In addition, we use the term We hope that our findings work as a wake-up call and ‘transformation' broadly, to refer to various polymorphic or motivation for the community to improve the current state of mobile malware detection.
Polymorphic attacks have long been a plague for traditional We emphasize that making judgment which anti-malware desktop and server systems. While there exist earlier studies product is the best is a non-goal for this paper. There are on the effectiveness of anti-malware tools on PCs [4], our other important characteristics of anti-malware, such as the domain of study is different in that we exclusively focus on completeness of the signature database and resource consump- mobile devices like smartphones that require different ways tion, that we do not evaluate. Additionally, security vendors for anti-malware design. Also, malware on mobile devices typically package malware detection with other functionalities have recently escalated their evolution but the capabilities of such as locating missing device or filtering spam SMS together in their offerings. Evaluating these functionalities remains and so on. Third party applications run unprivileged on An- beyond the scope of this paper.
droid. The rest of this section will cover some background To summarize, this paper makes the following contributions.
on the Android middleware and application fundamentals, • We systematically evaluate anti-malware products for An- application distribution, Android anti-malware, and signatures droid regarding their resistance against various transfor- for malware detection.
mation techniques in known malware. For this purpose,we developed DroidChameleon, a systematic frameworkwith various transformation techniques to facilitate anti- A. Android Fundamentals malware evaluation. Apart from general transformations,we also develop transformations that are specific to the Applications are programmed primarily in Java though the Android platform.
programmers are allowed to do native programming via JNI • We have implemented a prototype of DroidChameleon (Java native interface). Instead of running Java bytecode, and used it to evaluate ten popular anti-malware products Android runs Dalvik bytecode, which is produced by the for Android. Our findings show that all of them are application build toolchain from Java bytecode. Dalvik is a vulnerable to common evasion techniques. Moreover, we virtual machine designed to run in low-memory environments find that 90% of the signatures studied do not require and is similar to the Java Virtual Machine (JVM) with the static analysis of bytecode.
most notable difference being that it is register based (JVM is • We studied the evolution of anti-malware tools over a stack based). Most of the JVM concepts such as classes, class period of one year. Our findings show that some anti- loaders, reflection, and so on are adopted as specified by the malware tools have tried to strengthen their signatures Java Language Specification in the Dalvik virtual machine. In with a trend towards content-based signatures while pre- Dalvik, instead of having multiple .class files as in the case viously they were evaded by trivial transformations not of Java, all the classes are packed together in a single .dex involving code-level changes. The improved signatures (Dalvik Executable) file to minimize redundant strings and are however still shown to be easily evaded.
other constants. The dex file format keeps the Dalvik bytecode • Based on our evaluation results, we also explore possible and specifies the organization of the various sections and items ways to improve current anti-malware solutions. Specif- in the file. There are separate sections for keeping strings, class ically, we point out that Android eases advanced static definitions, code items, and so on.
analyses because much of the Android application code Android applications are made of four types of components, is high-level bytecodes rather than native codes. Hence, namely activities, services, broadcast receivers, and content anti-malware products could implement the already pro- providers. These application components are implemented posed semantics-based approaches for malware detection as classes in application code and are declared in the An- more easily for mobile platforms than for PCs where droidManifest (see next paragraph). The Android middleware most applications are native binaries. Furthermore, certain interacts with the application through these components. The platform support (in terms of offering higher privileges reader is referred to the official Android Documentation for to anti-malware) can be enlisted to cope with advanced detail on these.
Android application packages are jar files1 containing the In contrast with a closely related work [9], DroidChameleon application bytecode as a classes.dex file, any native code is much more comprehensive with many more transformation libraries, application resources such as images, config files and techniques and with complete evasion of anti-malware tools, so on, and a manifest, called AndroidManifest. It is a binary which is not even attempted in this work. Further details are XML file, which declares the application package name, a offered in Section VIII.
string that is supposed to be unique to an application, and The rest of this paper is organized as follows. We present in the different components in the application. It also declares Section II the necessary background and detail in Section III other things (such as application permissions) which are not so the DroidChameleon design. We then provide implementation relevant to the present work. The AndroidManifest is written details in Section IV and summarize our malware and anti- in human readable XML and is transformed to binary XML malware data sets in Section V. After that, we present our during application build.
findings in Section VI, followed by a brief discussion in Only digitally signed applications may be installed on an Section VII on how to improve current anti-malware solutions.
Android device. Application packages are signed similar to the Finally, we examine related work in Section VIII and conclude signing of a jar file. Signing is only for the purpose of enabling in Section IX.
better sharing among applications from the same developer andrecognizing packages that come from the device vendor (such packages may have more privileges) and not verifying trust Android is an operating system for mobile devices such as in the application. Signing keys are thus owned by individual smartphones and tablets. It is based on the Linux kernel and developers and not by a central authority, and there is no chain provides a middleware implementing subsystems such as tele- phony, window management, management of communicationwith and between applications, managing application lifecycle, 1Java Archive format, which is really a zip file format B. Android Anti-malware Solutions kind of signatures that these products use to detect malware With the proliferation of malware, there are now scores and how resistant these signatures are against changes in the of both free and paid anti-malware products available in the malware binaries. In this paper, we generally use the term official Android market. Many are from obscure developers transformation to denote semantics preserving changes to a while well-established, mainstream antivirus vendors offer program. We next define transformations more specifically.
Let P be the set of all programs. A transformation is a In order to get an insight on the workings of the anti- mapping τ : P → P that preserves the relevant semantics malware products, we briefly describe the necessary parts of the program. Note that we do not require all semantic of the Android security model. Android achieves application behaviors to be preserved; we instead look for preserving only sandboxing by means of Linux UIDs. Every application (with an interesting subset of behaviors of a given program. In case a few exceptions relating to how applications are signed) is of malware, this interesting subset is the malicious behavior.
given a separate UID and most of the application resources For example, when a transformation corresponds to changing remain hidden from other UIDs.
the package name of an application, the system logs about Android anti-malware products are treated as ordinary third that application may show a different package name, but this party applications and have no additional privileges over other behavior is not relevant. On the other hand, sending out a text applications. This is in contrast with the situation on tradi- message to a premium rate number without user consent is tional platforms such as Windows and Linux where antivirus a relevant behavior when studying malware. Clearly, if two applications run with administrator privileges. An important transformations preserve the relevant semantics, so will their implication of this is that these anti-malware tools are mostly incapable of behavioral monitoring and do not have access to In this work, we develop several different kinds of trans- the private files of the application. The original application formations that may be applied to malware samples while packages however remain intact and are readable by all preserving their malicious behavior. Each malware sample un- applications. (Copy protected application packages are not dergoes one or more transformations and then passes through readable by all applications but this feature is deprecated; paid the anti-malware tools. The detection results are then collected applications are reportedly kept encrypted since Android 4.1.
and used to make deductions about the detection strengths of Note that malware have not been found in paid apps.) These these anti-malware tools.
application packages may thus be used for static, signature- The transformation set in the DroidChameleon framework based malware detection. Moreover, Android provides a broad- is comprehensive in the sense that we can expect to beat cast when a new application is installed. All the anti-malware any static program analysis technique with these transforma- applications we study have the ability to scan applications tions. We also provide some Android-specific transformations automatically immediately following their installation, most (repacking and package renaming) which would give us im- likely by listening to this broadcast.
portant insights about the workings of Android anti-malware.
Android also provides a PackageManager API, which al- Moreover, some transformations such as renaming identifiers lows applications to retrieve all the installed packages. The and reflection do not apply to native code files typical to PCs.
API also allows getting the signing keys of these packages We classify our transformations as trivial (which do not require and the information stored in their AndroidManifest such as code level changes), those which result in variants that can the package name, names of the components declared, the still be detected by static analysis (DSA), and those which permissions declared and requested, and so on. Anti-malware can render malware undetectable by static analysis (NSA).
applications have the opportunity to use information from this In the rest of this section, we describe the different kinds of API as well for malware detection.
transformations that we have in the DroidChameleon frame-work. Where appropriate we give examples, using original and C. Malware Detection Signatures transformed code. Transformations for Dalvik bytecode aregiven in Smali (as in Listing 1), an intuitive assembly language While developing malware transformations, it is important for Dalvik bytecode and very similar to Jasmin assembly to consider what kind of signatures anti-malware tools may language for Java bytecode.
use against malware. Signatures have traditionally been in theform of fixed strings and regular expressions. Anti-malware const-string v10, "profile" tools may also use chunks of code, an instruction sequence or const-string v11, "mount -o remount rw system nexit n"invoke-static {v10, v11}, Lcom/android/root/Setting;-> API call sequence as signatures. Signatures that are more so- phisticated require a deeper static analysis of the given sample.
move-result-object v7 The fundamental techniques of such an analysis comprise dataand control flow analysis. Analysis may be restricted within Listing 1: A code fragment from DroidDream malware function boundaries (intra-procedural analysis) or may expandto cover multiple functions (inter-procedural analysis).
A. Trivial Transformations In this work, we focus on the evaluation of anti-malware Trivial transformations do not require code-level changes.
products for Android. Specifically, we attempt to deduce the We have the following transformations in this category.
1) Repacking: Recall that Android packages are signed jar move-result-object v7 files. These may be unzipped with the regular zip utilities Listing 2: Code in Listing 1 after identifier renaming and then repacked again with tools offered in the AndroidSDK. Once repacked, applications are signed with custom 2) Data Encoding: The dex files contain all the strings and keys (the original developer keys are not available). Detection array data that have been used in the code. These strings and signatures that match the developer keys or a checksum of arrays may be used to develop signatures against malware.
the entire application package are rendered ineffective by To beat such signatures we transform the dex file as follows.
this transformation. Note that this transformation applies to All the strings are stored in an encoded form, such as by Android applications only; there is no counterpart in general the application of a simple Caesar cipher. Any access to an for Windows applications although the malware in the latter encoded string is immediately followed by a call to a routine operating systems are known to use sophisticated packers for for decoding the string. As an illustration, Listing 3 shows the purpose of evading anti-malware tools.
code in Listing 1, transformed by string encoding.
2) Disassembling and Reassembling: The compiled Dalvik const-string v10, "qspgjmf" bytecode in classes.dex of the application package may be disassembled and then reassembled back again. The various move-result-object v10 items (classes, methods, strings, and so on) in a dex file may be arranged or represented in more than one way and thus a compiled program may be represented in different move-result-object v11invoke-static {v10, v11}, Lcom/android/root/Setting;-> forms. Signatures that match the whole classes.dex are beaten by this transformation. Signatures that depend on the move-result-object v7 order of different items in the dex file will also likely breakwith this transformation. Similar assembling/disassembling Listing 3: Code in Listing 1 after string encoding. Strings are encodedwith a Caesar cipher of shift +1.
also applies to the resources in an Android package and tothe conversion of AndroidManifest between binary and human The initialization data for arrays of primitive types is readable formats.
stored as bytes in the dex file. We encode these bytes using 3) Changing Package Name: Every application is identified simple XOR cipher. Any operation to fill arrays with data is by a package name unique to the application. This name is immediately followed by a call to a routine to decode the defined in the package's AndroidManifest. We change the newly filled array.
package name in a given malicious application to another 3) Call Indirections: This transformation can be seen as name. Package names of apps are concepts unique to An- a simple way to manipulate call graph of the application to droid and hence similar transformations do not exist in other defeat automatic matching. Given a method call, the call is converted to a call to a previously non-existing method thatthen calls the method in the original call. This can be done B. Transformation Attacks Detectable by Static Analysis for all calls, those going out into framework libraries as well as those within the application code. This transformation may The application of DSA transformations does not break all be seen as trivial function outlining (see function outlining types of static analysis. Specifically, forms of analysis that describe the semantics, such as data flows are still possible.
4) Code Reordering: Code reordering reorders the instruc- Only simpler checks such as string matching or matching API tions in the methods of a program. This transformation targets calls may be thwarted. Except for certain forms (depending detection schemes that rely on the order of the instructions, on the accuracy and detail of information needed) of data based on either the whole instructions, or part of the instruc- flow analysis and control flow analysis, we can expect other tions such as opcodes. This transformation is accomplished by forms of detection described in Section II-C to be vulnerable reordering the instructions and inserting goto instructions to to transformations described in this section.
preserve the runtime execution sequence of the instructions.
1) Identifier Renaming: Similar to Java bytecode, Dalvik We note that even though the Java language does not have bytecode stores the names of classes, methods, and fields. It is a goto statement, the JVM and the Dalvik virtual machine possible to rename most of these identifiers without changing both have the goto instruction. Since goto is not provided the semantics of the code. Constructors and methods that in the Java source language, a source level representation of override super-class methods can however not be renamed.
the transformed program may not exist. Listing 4 shows an In general, such transformations apply only to source code example reordering. Note that move-result-* must be the or bytecode (which preserve symbolic information) and not to first instruction after a call to capture the return value.
native code. We note that several free obfuscation tools such as ProGuard [10] provide identifier renaming. Listing 2 presents an example transformation for code in Listing 1.
invoke-static {v10, v11}, Lcom/android/root/Setting;-> const-string v10, "profile" const-string v11, "mount -o remount rw system nexit n" move-result-object v7 invoke-static {v10, v11}, Lcom/hxbvgH/IWNcZs/jFAbKo;-> # next instruction const-string v11, "mount -o remount rw system nexit n" broken into sufficiently small chunks, intra-procedural analysis will not be able to give any useful information. Interprocedural const-string v10, "profile"goto :i_2 analysis is still possible though.
8) Other Simple Transformations: There are a few other Listing 4: Code in Listing 1 reverse ordered transformations as well, specific to Android. Bytecode typ- 5) Junk Code Insertion: These transformations introduce ically contains a lot of debug information, such as source code sequences that are executed but do not affect rest of the file names, local and parameter variable names, and source program. Detection based on analyzing instruction (or opcode) line numbers. All this information may be stripped off. An- sequences may be defeated by junk code insertion. We propose other possible transformation is due to the nature of Android two different kinds of transformations for this purpose: nop packages, which are zip files. Files archived in these zip files insertion, and arithmetic and branch insertion.
may be renamed. Finally, Android packages contain various re- NOP insertion: This transformation simply inserts se- sources apart from the classes.dex and AndroidManifest.
quences of nop instructions in the code. It is easy to detect All these resources may be renamed or modified appropriately.
9) Composite Transformations: Any of the above trans- Arithmetic and branch insertion: This transformation in- formations may be combined with one another to generate troduces junk arithmetic and branch instructions based on sim- stronger obfuscations. While compositions are not commuta- ple templates. The branch instructions have arbitrary branch tive, anti-malware detection results should be agnostic to the offsets. The branch conditions are designed to be always false order of application of transformations in all cases discussed so that the branches are never actually taken. We assume that the value of these conditions (true or false) will be opaque toanti-malware tools being tested. Such obfuscation may create C. Transformation Attacks Non-Detectable by Static Analysis additional dependencies in control flow analysis. Listing 5 demonstrates some of the junk code that we generate. As in These transformations can break all kinds of static analysis.
code reordering, we point out that there may not be a source Some encoding or encryption is typically required so that no level equivalent which compiles to the transformed program static analysis scheme can infer parts of the code. Parts of because branches are made to arbitrary offsets whereas control the encryption keys may even be fetched remotely. In this flow in Java is based on nested blocks (save the limited use scenario, interpreting or emulating the code (i.e., dynamic of break and continue).
analysis) is still possible but static analysis becomes infeasible.
1) Reflection: Reflection is an easy way to obfuscate const/16 v1, 0x3add-int v0, v0, v1 method calls. Reflection is the ability provided by certain add-int v0, v0, v1 programming languages allowing a program to introspect itself rem-int v0, v0, v1if-lez v0, :junk_1 and change its behavior at runtime. In Java, the reflection APIallows a program, among other things, to invoke a method by Listing 5: An example of a junk code fragment using the name of the methods. In reflection transformation, 6) Encrypting Payloads and Native Exploits: In Android, we convert every method call into a call to that method via native code is usually made available as libraries accessed reflection. This makes it difficult to analyze statically which via JNI. However, some malware such as DroidDream also method is being called. A subsequent encryption of the method pack native code exploits meant to run from a command name can make it impossible for any static analysis to recover line in non-standard locations in the application package.
the call. Listing 6 illustrates code in Listing 1 after reflection All such files may be stored encrypted in the application package and be decrypted at runtime. Certain malware such as const-string v10, "profile" DroidDream also carry payload applications that are installed const-string v11, "mount -o remount rw system nexit n"const/4 v13, 0x2 once the system has been compromised. These payloads may new-array v14, v13, [Ljava/lang/Class; also be stored encrypted. We categorize payload and exploit new-array v15, v13, [Ljava/lang/Object;const/4 v13, 0x0 encryption as DSA because signature based static detection is const-class v12, Ljava/lang/String; still possible based on the main application's bytecode. These aput-object v12, v14, v13aput-object v10, v15, v13 are easily implemented and have been seen in practice as well (e.g., DroidKungFu malware uses encrypted exploit).
const-class v12, Ljava/lang/String;aput-object v12, v14, v13 7) Function Outlining and Inlining: In function outlining, aput-object v11, v15, v13 a function is broken down into several smaller functions.
const-string v13, "runRootCommand"const-class v12, Lcom/android/root/Setting; Function inlining involves replacing a function call with the invoke-virtual {v12, v13, v14}, Ljava/lang/Class;-> entire function body. It is typically used by compilers for optimizing code related to short functions. The outlining move-result-object v13 refactoring has been proposed to eliminate duplicate code in const/4 v16, 0x0invoke-virtual {v13, v12, v15}, Ljava/lang/reflect/Method programs [11]. However, outlining and inlining can be used for call graph obfuscation also. Outlining can also be used to move-result-object v7 impede all kinds of intra-procedural analyses. If a function is check-cast v7, Ljava/lang/String; form among other things. It can also assemble and repack a Listing 6: Listing 1 with method call by reflection package. Most of the code transformations are applied to thesmali assembly code, which is assembled later into dex code.
2) Bytecode Encryption: Code encryption tries to make Only method and field renaming was implemented directly the code unavailable for static analysis. The relevant piece on the dex code, yet using the underlying library for smal- of the application code is stored in an encrypted form and is i/baksmali. The assembling and disassembling transformation decrypted at runtime via a decryption routine. Code encryption is implemented simply by decoding and building with Apktool.
has long been used in polymorphic viruses; the only code This has the effect of repacking, changing the order and rep- available to signature based antivirus applications remains the resentation of items in the classes.dex file, and changing decryption routine, which is typically obfuscated in different the AndroidManifest (while preserving the semantics of it).
ways at each replication of the virus to evade detection.
All other transformations in our implementation (apart from We discuss here code encryption alone; obfuscation of the repacking) make use of Apktool to unpack/repack application decryption routine may be possible by other methods discussed packages. Our overall implementation comprises about 1,100 lines of Python and Scala code.
We accomplish bytecode encryption by moving most of the We verified that our implementation of transformations do application in a separate dex file (packed as a jar) and storing it not modify the semantics of the programs. Specifically, we in the application package in an encrypted form. When one of tested our transformations against several test cases and ver- the application components (such as an activity or a service) is ified their correctness on two malware samples, DroidDream created, it first calls a decryption routine that decrypts the dex and Fakeplayer. In general, verifying correctness on actual file and loads it via a user defined class loader. In Android, malware is challenging because some of the original samples the DexClassLoader provides the functionality to load have turned non-functional owing to, for example, the remote arbitrary dex files. Following this operation, calls can be made server not responding, and because being able to detect all the into the code in the newly loaded dex file. Alternatively, one malicious functionality requires a custom, appropriately mon- could define a custom class loader that loads classes from itored environment. Indeed, our original DroidDream sample a custom file format, possibly containing encrypted classes.
would not work because it failed to get a reply from a remote We note that classes which have been defined as components server; we removed the functionality of contacting the remote need to be available in classes.dex (one that is loaded by server to confirm that the malicious functionality works as default) so that they are available to the Android middleware in the default class loader. These classes then act as wrappersfor component classes that have been moved to other dex files.
This section describes the anti-malware products and the malware samples we used for our study. We evaluated ten anti- IV. IMPLEMENTATION malware tools, which are listed in Table I. There are dozens of Apart from function outlining and inlining, we applied free and paid anti-malware offerings for Android from various all other DroidChameleon transformations to the malware well-established anti-malware vendors as well as not-so-well- samples. We have implemented most of the transformations known developers. We selected the most popular products; in so that they may be applied automatically to the application.
addition, we included Kaspersky and Trend Micro, which were Automation implies that the malware authors can generate then not very popular but are well established vendors in the polymorphic malware at a very fast pace. Certain transfor- security industry. We had to omit a couple of products in the mations such as native code encryption are not possible to most popular list because they would fail to identify many completely automate because one needs to know how native original, unmodified malware samples we tested. One of the code files are being handled in the code.2 Transformations tools, Dr. Web, actually claims that its detection algorithms that require modification of the AndroidManifest (rename are resilient to malware modifications.
packages and renaming components) have not been completely Our malware set is summarized in Table II. We used automated because we felt it was more convenient to modify a few criteria for choosing malware samples. First, all the manually the AndroidManifest for our study. Nevertheless, it is anti-malware tools being evaluated should detect the original certainly possible to automate this as well. Finally, we did not samples. We here have a question of completeness of the automate bytecode encryption, although there are no technical signature set, which is an important evaluation metric for barriers to doing that. However, we have implemented a proof- antivirus applications. In this work however, we do not focus of-concept bytecode encryption transformation manually on on this question. Based on this criterion, we rejected Tapsnake, existing malware.
jSMSHider and a variant of Plankton. Second, the malware We utilize the Smali/Baksmali [12] and its companion tool samples should be sufficiently old so that signatures against Apktool [13] for our implementation. Apktool is able to un- them are well stabilized. All the samples in our set were pack an application package, disassemble classes.dex into discovered in or before October 2011. All the samples are smali code and convert AndroidManifest to human readable publicly available on Contagio Minidump [14].
Our malware set spans over multiple malware kinds. Droid- 2Native code stored in non standard locations is typically copied from the application package to the application directory by the application itself Dream [15] and BaseBridge [16] are malware with root ex- (possibly through an available Android API).
ploits packed into benign applications. DroidDream tries to get TABLE I: Anti-malware products evaluated.
Norton Mobile Security Lookout Mobile Security ESET Mobile Security Dr. Web anti-virus Light Kaspersky Mobile Security Mobile Security Personal Ed.
Zoner Antivirus Free Webroot Security & Antivirus TABLE II: Malware samples used for testing anti-malware tools com.droiddream. bowl- Information exfiltration; bot- like capabilities Information exfiltration; bot- like capabilities; SMS trojan packed as payload Dynamic code loading TABLE III: Key to Tables IV, V and VI. Trans-formations coded with single letters are trivial transformations. All others are DSA. We did not need NSA transformations to thwart anti-malwaretools.
If all transformations done Dissassemble & assemble go to B else continue on A No Stop after getting Encrypt native exploit or payload Rename identifiers If all transformations done go to C else continue on B Encode strings and array data Figure 1: Evaluating anti-malware All transformations contain PAll transformations except P contain A root privileges using two different root exploits, rage against the cage, and exploid exploit. BaseBridge includes only oneexploit, rage against the cage. If these exploits are successful, As has already been discussed, we transform malware both DroidDream and BaseBridge install payload applications.
samples using various techniques discussed in Section III and Geinimi [17] is a trojan packed into benign applications. It pass them through anti-malware tools we evaluate. We will communicates with remote C&C servers and exfiltrates user now briefly describe our methodology and then discuss the information. Fakeplayer [18], the first known malware on An- findings of our study.
droid, sends SMS messages to premium numbers, thus costing We describe our methodology through Figure 1 and through money to the user. Bgserv [19] is a malware injected into Tables IV and V, which depict the series of transformations Google's security tool to clean out DroidDream and distributed applied to DroidDream and Fakeplayer samples and the detec- in third party application markets. It opens a backdoor on tion results on various anti-malware tools. Empty cells in the the device and exfiltrates user information. Plankton [20] is a tables indicate positive detection while cells with ‘x' indicate malware family that loads classes from additional downloaded that the corresponding anti-malware tool failed to detect the dex files to extend its capabilities dynamically.
malware sample after the given transformations were appliedto the sample. The tables reflect a general approach of our study. We begin testing with trivial transformations and then the general detection scheme of Dr. Web is as follows. The proceed with transformations that are more complex. Each set of method calls from every method is obtained. These transformation is applied to a malware sample (of course, sets are then used as signatures and the detection phase some like exploit encryption apply only in certain cases) consists of matching these sets against sets obtained from the and the transformed sample is passed through anti-malware.
sample under test. We also tested Dr. Web against reflection If detection breaks with trivial transformations, we stop.3 transformation (not shown in the tables) and were able to evade Next, we apply all the DSA transformations. If detection it. This offers another confirmation that signatures are based still does not break, we apply combinations of DSA trans- on method calls. Furthermore, we also found (by limiting formations. In general there is no well-defined order in which our transformations) that only framework API calls matter; transformations should be applied (in some cases a heuristic calls within the application make no difference. It seems that works; for example, malware that include native exploits are the matching is somewhat fuzzy (requiring only a threshold likely to be detected based on those exploits). Fortunately, in percentage of matches) because we found on DroidDream and our study, we did not need to apply combinations of more Fakeplayer that results are positive even when a few classes are than two transformations to break detection. When applying removed from the dex file. For these two families, we could combinations of transformations, we stopped when detection create multiple minimal sets of classes that would result in pos- broke. We do not show the redundant combinations in the itive detection. As mentioned earlier, Dr. Web indeed claims tables for the sake of conciseness. The last rows do not form it has signatures that are resilient to malware modifications.
part of our methodology; we construct them manually to show It is difficult to say if the polymorphic resistance of these the set of transformations with which all anti-malware tools signatures is any stronger than other signatures depending on identifier names and string and data values. In particular, such Our results with all the malware samples are summarized signatures do not capture semantic properties of malware such in Table VI. This table gives the minimal transformations as data and control flow. Our results aptly demonstrate the low necessary to evade detection for malware-anti-malware pairs.
For example, DroidDream requires both exploit encryption and Finding 2 At least 43% signatures are not based on code- call indirection to evade Dr. Web's detection. These minimal level artifacts. That is, these are based on file names, check- transformations also give insight into what kind of detection sums (or binary sequences) or information easily obtained by signatures are being used. Our tool produces actual malware; the PackageManager API. We also found all AVG signatures we take special precaution to avoid spreading these samples to be derived from the content of AndroidManifest only (and and are careful with whom we share these samples. We next hence that of the PackageManager API). In case of AVG, describe our key findings in the light of the detection results.
the signatures are based on application component classes These findings are not meant to be statistical conclusions; yet or package names or both. Furthermore, this information is they give a general idea of the capabilities of anti-malware derived from AndroidManifest only. We confirmed this by placing a fake AndroidManifest in malware packages and Finding 1 All the studied anti-malware products are vul- assembling them with the rest of the package kept as it is.
nerable to common transformations. All the transformations This AndroidManifest did not have any of the components appearing in Table VI are easy to develop and apply, redefine or package names declared by the malware applications. The only certain syntactic properties of the malware, and are results were that detection was negative for all the malware common ways to transform malware. Transformations like identifier renaming and data encryption are easily available Finding 3 90% of signatures do not require static analysis using free and commercial tools [10], [21]. Exploit and of bytecode. Only one of ten anti-malware tools was found payload encryption is also easy to achieve. Although most to be using static analysis. Names of classes, methods, and of current Android malware uses simple techniques, without fields, and all the strings and array data are stored in the the use of sophisticated transformations, we point out that classes.dex file as they are and hence can be obtained by some of these transformations may already be seen in the content matching. The only signatures requiring static analysis wild in current malware. For example, Geinimi variants have of bytecode are those of Dr. Web because it extracts API calls encrypted strings [22]. Similarly, the DroidKungFu malware made in various methods.
uses encrypted exploit code [23]; a similar transformation to Finding 4 Anti-malware tools have evolved towards DroidDream allows easy evasion across almost all the anti- content-based signatures over the past one year. We studied malware tools we studied. Finally, there are reports of similar compare our findings that we obtained in February 2012 server-side polymorphism as well [6]. In future, it is likely that (Table VII) to our present findings obtained in February 2013 more and more malware will adopt sophisticated techniques (Table VI). Some of the anti-malware tools have changed for polymorphism. No transformations just discussed thwart considerably for the same malware samples. Last year, 45% static analysis.
of the signatures were evaded by trivial transformations, i.e., We found that only Dr. Web uses a somewhat more so- repacking and assembling/disassembling. Such signatures have phisticated algorithm for detection. Our findings indicate that virtually no resilience against polymorphism. Our presentresults show a marked decrease in this fraction to 16%.
3All DSA and NSA transformations also result in trivial transformations because of involving disassembling, assembling and repacking. Hence, there We find that in all such cases where we see changes, anti- is no use in proceeding further.
malware authors have moved to content-based matching, such TABLE IV: DroidDream transformations and anti-malware failure. Please see Table III for key. ‘x' indicates failure in detection.
TABLE V: Fakeplayer transformations and anti-malware failure. Please see Table III for key. ‘x' indicates failure in detection. EEtransformation does not apply for lack of native exploit or payload in Fakeplayer.
TABLE VI: Evaluation summary. Please see Table III for key. ‘+' indicates the composition of two transformations.
TABLE VII: Summary of results from anti-malware tools downloaded in February 2012. Please see Table III for key. ‘+' indicates thecomposition of two transformations. Results that have changed since then are depicted in bold (see Table VI for comparison).
as matching identifiers and strings.
these additionally match on some content in the rest of theapplication as well. Although the changes in the signatures Furthermore, for malware using native code exploits, many over the past one year may be seen as improvement, we anti-malware tools previously matched on the native exploits point out that the new signatures still lack resilience against and payloads alone. The situation has changed now as all of <manifest . package= "com.crazyapps.angry.birds.rio.unlocker" <manifest . package= "com.hDEWJu.oYlCvk.hFYkwc.FgDOHA.UPkmVF" Figure 2: An example evasion. Changes required in AndroidManifest of Plankton to evade AVG (original first and modified second; onlyrelevant parts are shown with differences highlighted). No other changes are required. The application will not work though until thecomponents are also renamed in the bytecode. We confirm that AVG's detection is based on the contents of AndroidManifest alone (seeFinding 2).
polymorphic malware as our results aptly demonstrate.
discussed in the context of dynamic analysis [25], [26] but itmay be possible to adapt similar techniques to static analysis VII. DEFENSE AGAINST TRANSFORMATION ATTACKS In this section, we discuss how the current state of malware Semantics-based detection is quite challenging for native detection on Android may be improved. We identify how codes; their analyses frequently encounters issues such as anti-malware tools should improve their detection techniques missing information on function boundaries, pointer aliasing, and that mobile platforms should provide special support to and so on [27], [28]. Even disassembly of native binaries can antimalware tools.
be error prone [29], [30]. Stripped binaries pose even greaterproblems, which are not fully solved yet and current solu-tions for accurate disassembly require combination of static A. Semantics-based Malware Detection and dynamic techniques [31]. Bytecodes, on the other hand, We point out that owing to the use of bytecodes, which con- preserve much of the source-level information, thus easing tain high-level structural information, analyses of Android ap- analysis. We therefore believe that anti-malware tools have plications becomes much simpler than those of native binaries.
greater incentive to implement semantic analysis techniques Hence, semantics-based detection schemes could prove espe- on Android bytecodes than they had for developing these for cially helpful in the case of Android. For example, Christodor- native code.
escu et al. [24] describe a technique for semantics baseddetection. Their algorithms are based on unifying nodes in agiven program with nodes in a signature template (nodes may B. Support from Platform be understood as abstract instructions), while preserving def- Note that the use of code encryption and reflection (NSA use paths4 described in the template. The signature template transformations) can still defeat the above scheme. Code abstracts data flows and control flows, which are semantics encryption does not leave visible code on which signatures properties of a program. Since this technique is based on data can be developed (of course, the decryption routing may still flows rather than a superficial property of the program such as be used for generating signatures). The use of reflection simply certain strings or names of methods being defined or called, hides away the edges in the call graph. A sophisticated data it is not vulnerable to any of the transformations (all of which flow analysis can still uncover those edges; however, if the are trivial or DSA) that show up in Table VI. These techniques method names used for reflective invocations are encrypted, further have a potential for a very low false positive rate as the these edges are rendered completely opaque to static analysis.
authors demonstrate in their work. Such a detection scheme Furthermore, it is possible to use function outlining to thwart is arguably slower than current detection schemes but offers any forms of intra-procedural analysis as well. Owing to these higher confidence in detection. This is just another instance of limitations, the use of dynamic monitoring is essential.
the traditional security-performance tradeoff. Christodorescu Recall that anti-malware tools in Android are unprivileged et al. had actually reported the running times to be in the third party applications. This impedes many different kinds of order of a couple of minutes on their prototype and had dynamic monitoring that may enhance malware detection. We suggested real performance is possible with an optimized believe special platform support for anti-malware applications implementation [24]. Developing signature templates itself is essential to detect malware amongst stock Android appli- may be challenging. Automatic signature generation has been cations. This can help malware detection in several ways. For 4A def-use path for a variable signifies a definition of that variable in a example, a common way to break evasion by code encryption program and all uses of that variable, reachable from that definition.
is to scan the memory at runtime. The Android runtime could provide all the classes loaded using user-defined class loaders Christodorescu and Jha [4] conducted a study similar to ours to the anti-malware application. Once the classes are loaded, on desktop anti-malware applications eight years ago. They they are already decrypted and anti-malware tools can analyze also arrived at the conclusion that these applications have low them easily.
resilience against malware obfuscation. Our study is based on We note that providing privileges for dynamic monitoring Android anti-malware, and we include several aspects in our to anti-malware applications would promote opportunities for study that are unique to Android. Furthermore, our study dates malware to trick users to grant high privileges. This is again after many research works (see below) on obfuscation resilient a trade-off. Anti-malware tools on PCs typically require high detection, and we would expect the proposed techniques to be privileges and do useful work even though there are issues of readily integrated into new commercial products.
fake antiviruses [32].
Finally, there are many works in the industry about the We note that Google recently introduced on-phone app evaluation of desktop antivirus tools on metrics such as verification [33], which checks the app checksum against signature completeness, usability and so on [37], [38].
a malware database upon installation. This however is notsufficient against polymorphic attacks each instance of a B. Obfuscation Techniques malicious app is unique. Google also performs offline app Collberg et al. [39] review different types of obfuscations analysis for malware detection using its Bouncer service [34].
and classify them based on reverse engineering by a human This is based on emulation (using virtual machines) of real and by automated tools, and the overhead added to the ap- phone environments. Such scanning by emulation however plication. They propose many different obfuscations possible has its own problems, ranging from detection of a virtualized on Java (or Dalvik) code. Collberg et al. further propose environment to the malicious activity not getting triggered in sophisticated transformations such as modifying inheritance the limited time for which the emulation runs; Bouncer is graphs and method cloning and implementation of opaque no exception to this [35], [36]. We therefore believe offline predicates (predicates whose outcome is difficult to arrive at emulation must be supplemented by strong static analysis or while reverse engineering but is known to the obfuscator) to real-time dynamic monitoring.
insert junk code [40], [41]. DroidChameleon provides only afew of the transformations proposed by them. Nonetheless, VIII. RELATED WORK the set of transformations provided in DroidChameleon is A. Evaluating Anti-malware Tools comprehensive (together with the advanced transformations) inthe sense that they can break typical static detection techniques AV-Test.org, an antivirus evaluation lab, rated anti-malware used by anti-malware. As for opaque predicates, we use such products for Android for the completeness of their detec- techniques in our transformation for inserting junk code with tion [7], [8]. Our study is orthogonal to their study in that the assumption that anti-malware tools will not be able to we evaluate how anti-malware products perform in detecting resolve conditions we use therein.
polymorphic variants of known malware. Most of the tools There are many tools that provide obfuscation for Java (9/10) we studied are rated as "very good" by them. This bytecode. Proguard [10] provides renaming of classes and provides us reason to believe that the tools we did not study class members. Other tools like Klassmaster [21] additionally will not have any better resistance to polymorphism.
provide flow obfuscation and string encryption. We provide Zheng et al. [9] also studied the robustness of anti-malware much of these functionalities. While the goal of these tools against Android malware recently using a tool called ADAM.
is to evade manual reverse engineering, we aim at thwarting ADAM implements only a few transformations, renaming analysis by automatic tools.
methods, introducing junk methods, code reordering, andstring encoding, in addition to repacking and assembling/dis-assembling. Our set of transformations is much more com- C. Obfuscated Malware Detection prehensive and includes renaming packages, classes, encoding As already discussed, to deal with malware obfuscation, array data, inserting junk statements, encrypting payloads and the detection techniques must be based on semantics rather native exploits, reflection, and bytecode encryption as well.
than the syntax of the code. These detection techniques should Finally, we also have composite transformations. Many of the therefore be based on data flow and control flow analyses of additional transformations, including the composite ones, were the samples under test. Christodorescu et al. [24] present one crucial for evading anti-malware tools. Based on the above, such technique. Their algorithm is based on matching given we point out that ADAM is not always able to evade an samples against a template by unifying nodes in samples with anti-malware tool. Rather than attempting complete evasion, it nodes in the template while preserving def-use relationships.
simply offers percentages depicting how many variants were In subsequent work, Preda et al. [42] propose a semantics- detected by the anti-malware tools (and these percentages are based framework to prove properties about malware detectors.
also very high). In contrast, our framework is comprehensive, Kruegel et al. [43] tackle the problem of disassembling bi- aimed towards complete evasion of all anti-malware tools. We naries that have been made hard to disassemble for malware believe our results make a clear statement – all anti-malware analysis. Christodorescu et al. [44] and Fredrikson et al. [25] tools can be evaded using common obfuscation techniques.
attempt to generate semantics based signatures by mining Unlike ADAM, our result is able to highlight the severity of malicious behavior automatically. Kolbitsch et al. [26] also the problem and is easily accessible.
propose similar techniques. The last three works are for behavior-based detection and use different behavior represen- tations such as data dependence graphs and information flows [1] CNET, February 2013, http://news.cnet.com/8301-1035 3-57569402- between system calls. Due to lower privileges for anti-malware tools on Android, these approaches cannot directly apply to [2] McAfee, "Mcafee threats report: Third quarter 2011," http://www.
these tools presently. Sequence alignment from bioinformatics [45], [46] has also been applied to malware detection and related problems [47], [48]. Further work is also there to com- [4] M. Christodorescu and S. Jha, "Testing malware detectors," in Proceed- pute statistical significance of scores given by these classical ings of the 2004 ACM SIGSOFT International Symposium on Software sequence alignment algorithms [49], [50]. It may be possible Testing and Analysis, ser. ISSTA '04.
to adapt such techniques to detect transformed malware with [5] Fortinet, "2012 threat predictions," http://blog.fortinet.com/2012-threat- high performance.
D. Smartphone Malware Research [7] "Test: Malware protection for Android," March 2012, http://www.av- With the growth of malware on smartphones, sev- [8] "Are free Android virus scanners any good?" http://www.av-test.org/ eral research works have been done in this direction.
fileadmin/pdf/avtest 2011-11 free android virus scanner english.pdf.
[9] M. Zheng, P. Lee, and J. Lui, "Adam: An automatic and extensible DroidRanger [51] and Riskranker [52] use (mostly) static platform to stress test Android anti-virus systems," DIMVA, July 2012.
analysis to detect unknown malware from both known and unknown malware families. They identified several new mali- [11] R. Komondoor and S. Horwitz, "Semantics-preserving procedure extrac- tion," in In POPL.
ACM Press, 2000, pp. 155–169.
cious applications in the official Android market as well as [12] "Smali: An assembler/disassembler for Android's dex format," http:// alternative application markets. Peng et al. [53] investigate probabilistic models to rank risks for Android apps. Anti- [13] "Android-apktool: A tool for reengineering Android apk files," http: malware authors may explore their approaches, which may [14] M. Parkour, "Contagio Mobile. Mobile malware mini dump," http: serve as heuristics to raise malware suspicions. Crowdroid [54] uses crowd sourcing to collect system calls from applications [15] Lookout, "Update: Security alert: DroidDream malware found in official running on mobile devices then uses clustering to identify malicious behavior. Such techniques cannot be currently used [16] "Android.Basebridge by unprivileged third-party anti-malware applications on An- droid. Felt et al. [55] present a survey of smartphone malware.
[17] "Android.Geinimi — Symantec," http://www.symantec.com/security They present taxonomy of smartphone malware and explore the incentives to develop mobile device malware. Zhou and Jiang [56] provide another, more recent survey of Android [19] "Android.Bgserv — Symantec," http://www.symantec.com/security malware. They study how well anti-malware tools detect mal- ware samples found in the wild. The tools have good detection [21] "Zelix Klassmaster," http://www.zelix.com/klassmaster/.
on some families, like Fakeplayer and Geinimi, but fail in our [22] Lookout, "Geinimi trojan technical analysis," http://blog.mylookout.
tests when the samples are transformed. Airmid [57] proposes [23] "DroidKungFu," new mobile infrastructure for malware mitigation. Apart from Android, they also explored malware on Symbian and iOS.
[24] M. Christodorescu, S. Jha, S. Seshia, D. Song, and R. Bryant, "Semantics-aware malware detection," in Security and Privacy, 2005 Bose et al. [58] and Kim et al. [59] have used logical ordering IEEE Symposium on.
IEEE, 2005, pp. 32–46.
of applications' actions and power consumption respectively to [25] M. Fredrikson, S. Jha, M. Christodorescu, R. Sailer, and X. Yan, construct behavioral detection of Symbian malware. VirusMe- "Synthesizing near-optimal malware specifications from suspicious be-haviors," in Security and Privacy (SP), 2010 IEEE Symposium on.
ter [60] also uses power consumption to catch misbehaving IEEE, 2010, pp. 45–60.
Symbian malware. It is still to be demonstrated if these [26] C. Kolbitsch, P. Comparetti, C. Kruegel, E. Kirda, X. Zhou, and techniques apply well to Android also. In a summary, none X. Wang, "Effective and efficient malware detection at the end host," inProceedings of the 18th Conference on USENIX Security Symposium.
of the above works focuses on evaluating current mobile anti- USENIX Association, 2009, pp. 351–366.
malware solutions.
[27] P. Saxena, R. Sekar, and V. Puranik, "Efficient fine-grained binary instrumentationwith applications to taint-tracking," in Proceedings of the6th annual IEEE/ACM international symposium on Code generation and ACM, 2008, pp. 74–83.
[28] L. Harris and B. Miller, "Practical analysis of stripped binary code," We evaluated ten anti-malware products on Android for ACM SIGARCH Computer Architecture News, vol. 33, no. 5, pp. 63–68, 2005.
their resilience against malware transformations. To facilitate [29] B. Schwarz, S. Debray, and G. Andrews, "Disassembly of executable this, we developed DroidChameleon, a systematic framework code revisited," in Reverse Engineering, 2002. Proceedings. Ninth Work- with various transformation techniques. Our findings show ing Conference on.
IEEE, 2002, pp. 45–54.
[30] C. Linn and S. Debray, "Obfuscation of executable code to improve that all the anti-malware products evaluated are susceptible to resistance to static disassembly," in Proceedings of the 10th ACM common evasion techniques and may succumb to even trivial conference on Computer and communications security.
transformations not involving code-level changes. Finally, we pp. 290–299.
[31] S. Nanda, W. Li, L. Lam, and T. Chiueh, "Bird: Binary interpretation explored possible ways in which the current situation may be using runtime disassembly," in Code Generation and Optimization, improved and next-generation solutions may be developed.
2006. CGO 2006. International Symposium on. IEEE, 2006, pp. 12–pp.
[32] Microsoft, "Watch out for fake virus alerts," http://www.microsoft.com/ [56] Y. Zhou and X. Jiang, "Dissecting android malware: Characterization and evolution," Security and Privacy, IEEE Symposium on, 2012.
[33] J. Raphael, "Exclusive: Inside Android 4.2's powerful new security sys- [57] Y. Nadji, J. Giffin, and P. Traynor, "Automated remote repair for tem," November 2012, http://blogs.computerworld.com/android/21259/ mobile malware," in Proceedings of the 27th Annual Computer Security ACM, 2011, pp. 413–422.
[34] H. Lockheimer, "Android and security," February 2012, http:// [58] A. Bose, X. Hu, K. G. Shin, and T. Park, "Behavioral detection of malware on mobile handsets," in Proceedings of the 6th International [35] J. Oberheide, "Dissecting android's bouncer," June 2012, https://blog.
Conference on Mobile Systems, Applications, and Services, ser. MobiSys [36] R. Whitwam, "Circumventing Google's Bouncer, Android's anti- [59] H. Kim, J. Smith, and K. G. Shin, "Detecting energy-greedy anomalies malware system," June 2012, http://www.extremetech.com/computing/ and mobile malware variants," in Proceedings of the 6th International Conference on Mobile Systems, Applications, and Services, ser. MobiSys [37] N. J. Rubenking, "PCMag. The best antivirus for 2012," http://www.
[60] L. Liu, G. Yan, X. Zhang, and S. Chen, "Virusmeter: Preventing your cellphone from spies," in Recent Advances in Intrusion Detection.
Springer, 2009, pp. 244–264.
[39] C. Collberg, C. Thomborson, and D. Low, "A taxonomy of obfuscating transformations," Department of Computer Science, The University ofAuckland, New Zealand, Tech. Rep., 1997.
[40] ——, "Breaking abstractions and unstructuring data structures," in Com- puter Languages, 1998. Proceedings. 1998 International Conference on.
IEEE, 1998, pp. 28–38.
[41] ——, "Manufacturing cheap, resilient, and stealthy opaque constructs," in Conference Record of the Acm Symposium on Principles of Program-ming Languages, vol. 25.
ACM, 1998, pp. 184–196.
[42] M. D. Preda, M. Christodorescu, S. Jha, and S. Debray, "A semantics- based approach to malware detection," in Proceedings of the ACMSIGPLAN-SIGACT Symposium on Principles of Programming Lan-guages, ser. POPL '07.
[43] C. Kruegel, W. Robertson, F. Valeur, and G. Vigna, "Static disassembly of obfuscated binaries," in Proceedings of the 13th USENIX SecuritySymposium, 2004, pp. 255–270.
[44] M. Christodorescu, S. Jha, and C. Kruegel, "Mining specifications of malicious behavior," in Proceedings of the the 6th Joint Meeting ofthe European Software Engineering Conference and the ACM SIGSOFTSymposium on The Foundations of Software Engineering, ser. ESEC-FSE'07.
[45] S. B. Needleman and C. D. Wunsch, "A general method applicable to the search for similarities in the amino acid sequence of two proteins."Journal of Molecular Biology, vol. 48, no. 3, pp. 443–453, March 1970.
[46] T. F. Smith and M. S. Waterman, "Identification of Common Molecular Subsequences." Journal of Molecular Biology, vol. 147, no. 1, pp. 195–197, 1981.
[47] X. Jiang and X. Zhu, "vEye: Behavioral footprinting for self-propagating worm detection and profiling," Knowledge and Information Systems,vol. 18, no. 2, pp. 231–262, 2009.
[48] G. Wondracek, P. M. Comparetti, C. Kruegel, E. Kirda, and S. S. S.
Anna, "Automatic network protocol analysis," in 15th Symposium onNetwork and Distributed System Security (NDSS), 2008.
[49] A. Agrawal and X. Huang, "Pairwise statistical significance of local sequence alignment using multiple parameter sets and empirical justifi-cation of parameter set change penalty," BMC Bioinformatics, vol. 10,no. Suppl 3, p. S1, 2009.
[50] ——, "Pairwise statistical significance of local sequence alignment using sequence-specific and position-specific substitution matrices,"IEEE/ACM Transactions on Computational Biology and Bioinformatics(TCBB), vol. 8, no. 1, pp. 194–205, 2011.
[51] Y. Zhou, Z. Wang, W. Zhou, and X. Jiang, "Hey, you, get off of my market: Detecting malicious apps in official and alternative Androidmarkets," in Proceedings of the 19th Network and Distributed SystemSecurity Symposium, ser. NDSS '12, 2012.
[52] M. Grace, Y. Zhou, Q. Zhang, S. Zou, and X. Jiang, "Riskranker: scal- able and accurate zero-day android malware detection," in Proceedingsof the 10th International Conference on Mobile Systems, Applications,and Services, ser. MobiSys '12.
[53] H. Peng, C. Gates, B. Sarma, N. Li, Y. Qi, R. Potharaju, C. Nita-Rotaru, and I. Molloy, "Using probabilistic generative models for ranking risksof android apps," in Proceedings of the 2012 ACM conference onComputer and communications security, 2012.
[54] I. Burguera, U. Zurutuza, and S. Nadjm-Tehrani, "Crowdroid: behavior- based malware detection system for android," in Proceedings of the 1stACM workshop on Security and privacy in smartphones and mobiledevices.
ACM, 2011, pp. 15–26.
[55] A. Felt, M. Finifter, E. Chin, S. Hanna, and D. Wagner, "A survey of mobile malware in the wild," in Proceedings of the 1st ACM workshopon Security and privacy in smartphones and mobile devices.
2011, pp. 3–14.

Source: http://www.itamsoft.com/download/30/NorthWestern-University-evaluating-Android%20Anti-malware-nu_eecs_13_01.pdf