Reverse Engineering Android Apps With CodeInspect

Siegfried Rasthofer1, Steven Arzt1, Marc Miltenberger1, and Eric Bodden2

1Fraunhofer SIT & TU Darmstadt, Darmstadt, Germany2Paderborn University & Fraunhofer IEM, Paderborn, Germany

Abstract

While the Android operating system is popu-lar among users, it has also attracted a broadvariety of miscreants and malware. New sam-ples are discovered every day. Purely auto-matic analysis is often not enough for un-derstanding current state-of-the-art Androidmalware, though. Miscreants obfuscate andencrypt their code, or hide secrets in nativecode. Precisely identifying the malware’s be-havior and finding information about its po-tential authors requires tools that assist hu-man experts in a manual investigation. In thispaper, we present CodeInspect, a novel reverseengineering tool for Android app that opti-mally supports investigators and analysts inthat task.

1 IntroductionMobile devices such as smartphones and tablets areincreasingly used in everyday life and have long sincebecome essential tools. This success is primarily dueto the availability of apps for almost every need. Whilethis abundance is helpful for users, it also attracts mis-creants. Stealing sensitive user information or directlyincurring charges on them is a profitable, albeit illegalbusiness model. As Android has the largest marketshare among mobile operating systems [8], most mal-ware is developed for Android as well. The rate withwhich new malware appears in the wild increases bythe year [12].

Many approaches for automatically detecting An-droid malware have been proposed in the academicliterature [1, 6, 5] and implemented into practical toolssuch as Drebin [1] or Chabada [6]. While automation

Copyright c© by the paper’s authors. Copying permitted forprivate and academic purposes. This volume is published andcopyrighted by its editors.In: D. Aspinall, L. Cavallaro, M. N. Seghir, M. Volkamer (eds.):Proceedings of the Workshop on Innovations in Mobile Privacyand Security IMPS at ESSoS’16, London, UK, 06-April-2016,published at http://ceur-ws.org

is crucial for mass analysis, these tools face challengesfor highly obfuscated state-of-the-art malware and isusually completely ineffective for novel or targeted at-tacks. In these cases, to understand the behavior of agiven sample the analyst must resort to manual labor.Furthermore, she usually needs to gather additionalinformation such as potential hints on the miscreantsbehind the malware. Remote URLs, telephone num-bers, e-mail addresses, or even coding patterns can givevaluable insights to defenders and prosecutors alike.Though approaches exist to extract information fromapps automatically [11, 10, 14, 7], gaining a completeunderstanding of a malware sample usually requiresmanual inspection.

With today’s numbers of new samples arriving ev-ery day, it has become of utmost importance to makemanual investigations as efficient as possible. Theanalysis tool should thus support the human expert toreduce the mechanical parts of the investigation, allow-ing the human to focus on understanding the threat.In this paper, we present CodeInspect, a novel reverse-engineering tool for Android applications. CodeIn-spect features an expressive intermediate languagewith type information for local variables, an interac-tive debugger, and various Android-specific analysessuch as data-flow tracking and permissions-usage scan-ning. We show how CodeInspect can be used to analyzea complex real-world malware sample [13] within lessthan one hour.

The remainder of this paper is structured as follows.In Section 2, we introduce the malware that will serveas a running example in this paper. Afterwards, wegive an overview over CodeInspect in Section 3. In Sec-tion 4, we show how we used CodeInspect to reverse en-gineer the malware, before we conclude in Section 5.

2 Android/BadAccent MalwareThe Android/BadAccents malware family was discov-ered in 2015 [13] and is a banking trojan that usesdifferent obfuscation techniques. Its design is modu-lar with several features such as SMS stealing, socialengineering, and uninstalling AV apps. Furthermore,

11

the malware is designed to evade automatic detectionapproaches. To completely understand the behavior ofthe malware, a manual investigation is necessary. Outof the various components, we focus on the SMS In-terception component, which intercepts incoming SMSmessages and forwards them to the attacker. Thisis done in an attempt to obtain mobile transactionnumbers (mTAN), which can then be used to conductfraudulent transaction at the user’s expense. For theinvestigator, it is important to understand where thestolen information is sent as any target address maygive clues on the identity of the miscreant running thescam. From a previous investigation, we knew that themalware sends some information via e-mail. It was,however, unclear where the e-mails were sent to, andwhether additional channels existed. Therefore, find-ing the target mail address and possible other channelswas the focus of the manual investigation at hand.

3 CodeInspect OverviewAs seen in the introduction, some situations requirebinary software to be inspected manually. Analystscan use existing command-line tools such as APKtoolto decompile the binary APK file into readable textsource. This tool, however, creates smali code. Smaliis an untyped assembly language, leaving the analystwith the challenging task as making sense to regis-ters operations and explicit reference management onthe heap. Filling data structures, for instance, is acomplex set of heap navigation instructions in smali.Furthermore, disassembly files only give a static lookon the malware. They do not easily allow for runtimeinspection.

A powerful IDE such as CodeInspect, on the otherhand, is much more convenient to use. The tool isbased on the Eclipse [4] IDE, so that developers usu-ally have an intuition on how to use it. CodeInspectconverts the APK file into a typed, higher-level in-termediate representation that is much more conve-nient to read than smali. The code editor providesthe analyst with syntax highlighting and navigationcapabilities that allow the analyst to e.g., jump to thedefinition of a symbol of interest. The CodeInspectIDE allows the analyst to work with the decompiledcode on a semantic, rather than just a textual level.If the analyst, e.g., searches for a specific method, shewill only find occurrences of that method name, notarbitrary strings that happen to have the same name.CodeInspect can import APK file either directly if theyare available on the analyst’s machine, or it can loadthem from a real tablet or phone on which the respec-tive apps are installed.

Besides reverse engineering for malware analysis,CodeInspect can also be used to analyze benign apps

in detail. Bundled third party libraries such as adver-tisement libraries are usually considered safe, althoughthey might pose a security or privacy risk to the user ofthe application. The library code is often not availableand, thus, cannot be checked by the app developers.CodeInspect, however, enables developers to validatethe behavior of the compiled application including theactions performed by the libraries. Similar challengesarise when outsourcing app development to third par-ties that only deliver the binaries of the developed app,but not the source code. In that case, the purchasingcompany also need powerful analysis tools to look intothe delivered black box. Otherwise, that black box de-velopment could contain serious security flaws or evenmalicious code that goes undetected.

3.1 Jimple Intermediate Representation

CodeInspect relies on the Soot framework for programanalysis and transformation [9]. The Soot frameworktakes an Android application as input and converts itinto a human readable type-based intermediate repre-sentation called Jimple [15]. From now on, all codeanalyses and transformations are performed on thisintermediate representation rather than the originalbytecode. Soot also offers the possibility to convertthe (potentially modified) Jimple code back into anAndroid binary. CodeInspect inherits this feature andallows the analyst to modify the app, for instance toremove emulator checks or other challenges to the anal-ysis. The human expert can also refactor the app tointegrate conclusions she has already drawn about theapp, e.g., by renaming methods to what their actualtask is instead of some obfuscated name. The analystcan also merge additional Jimple or Java code into theapp. With this feature, she can, for instance, imple-ment a decryption method for some obfuscated stringsin Java and use them during a dynamic analysis to bet-ter understand the original data processed inside theapp. CodeInspect automatically merges the originalapp code and the new additions at compile time.

Although actual Java source code might be eveneasier to understand than Jimple, it is not always pos-sible to decompile an app’s bytecode back into validJava code. The Dalvik bytecode language that An-droid uses allows for constructs that have no equiva-lent in Java, such as unconditional nested jumps (gotoinstructions). Existing obfuscators [3] allow to easilytransform an app into such a non-reversible form. Aslong as the app still contains valid bytecode (i.e., runson the device), it can, however, be represented in Jim-ple. This makes Jimple the ideal middle ground be-tween bytecode and Java source code. It also makessure that CodeInspect can re-compile every app (withpotential changes from the analyst) and inspect its be-

22

Figure 1: Jimple Search

Figure 2: Jimple Code Snippet

havior dynamically. For those cases in which a Java de-compilation is possible, CodeInspect integrates an ex-isting state-of-the-art Java decompiler in a best-effortapproach.

CodeInspect’s Jimple editor behaves similarly to anormal Eclipse code editor for Java. The user maymodify the code as she wishes. When she saves herchanges, the code is automatically recompiled. As aresult, she receives a modified application as a newAPK file, which behaves like the original application,but with the changed code.

In the same way, due to Soot’s class file feature, amain method can be written in Java, which calls theaforementioned ”decryption” method from Java code,which runs on the JVM on the computer. In case theapp loads a dex file at runtime, one can also inspectits code and debug it via the Dex file merge feature.It merges the code from an available dex file and addsit to an existing project.

The user also may search for specific fields, meth-ods, classes as well as their usages using the Jimplesearch, as shown in figure 1.

Figure 2 shows the Jimple representation of amethod taken from a real-world malware app. Thebody a Jimple method can be divided into two parts.

The first part contains the variable declarations. Thesecond part contains the actual Jimple instructions. Inthis example, we see a read access to a field (urlServer)in the first line and a method call (DownloadFile) in thesecond line. In total, this example loads a file froma server on the web and specifies the user name andpassword required to access the file.

3.2 Project Explorer

In the normal Eclipse project explorer, CodeInspectlists all parts of the decompiled Android app. Thisincludes not only the code, but also the manifest xmlfile (in human-readable form), the assets bundled withthe app, the native libraries, and the layout XML files.The user is free to inspect and modify all of thesefiles. For opening the manifest or the layout XMLfiles, CodeInspect contains the Android ADT compo-nents for Eclipse. A layout file will thus be shown ingraphical UI editor in addition to the plain XML rep-resentation. All the different editors are linked; if theuser clicks on a class name in one editor (e.g., the man-ifest file), she can directly jump to the respective codein the Jimple code editor. These links are also auto-matically updated when the code is changed. If theanalyst, for instance, renames an activity, the respec-tive manifest entry will also be adapted automatically.

3.3 Debugging

To debug the application, it is not required to rootthe phone. Debugging may be performed on an emu-lator or a real device; the only requirement is that theDeveloper mode is activated on the device. The AutoStepper view automates stepping through the appli-cation under analysis. If activated, it steps throughthe code in a predefined frequency. Of course, it isalso possible to manually set breakpoints, jump intoor over method calls, jump back from a method toits caller, or drop the execution pointer to the currentstack frame. CodeInspect’s debugger is as powerful asthe original Android debugger that app developers useon their source code.

3.4 Android-Specific Analyses

CodeInspect extends the normal Eclipse IDE with vari-ous Android-specific analyses that give a human expertmore information on the current app. These analysesare implemented as additional views. The Permis-sion Usage View (Figure 3) lists all the permissionsrequested by the app. For every permission, it also re-ports all locations in the code where the respectivepermission is required. More precisely, CodeInspectidentifies all API calls that would fail if the respec-tive permission were not present. This information

33

Figure 3: Permission Usage View

Figure 4: Type Hierarchy View

can give the analyst a first hint to potentially mali-cious behavior in the app, for instance in the case ofSMS trojans.

Furthermore, the normal Java-based code analy-ses known from Eclipse are also available in CodeIn-spect. Similar to the Java Eclipse IDE Plug-In (JDT),CodeInspect contains a type hierarchy view, which canbe used to examine inheritance and interface imple-mentation relationships. Figure 4 shows the type hier-archy of the Service class, thus showing all Services ofan application. Besides, we have implemented a callhierarchy view. Figure 5 shows all potential callers ofmethod getSDPath1. This might give clues on how therespective method is used. In case of the getSDPath1

method, the view shows that this method gets calledfrom deleteFoder1, hinting that the app is trying to deletea folder.

3.5 Plugins

As CodeInspect has been developed at an academic in-stitution, we have also compiled our research resultsinto CodeInspect plugins. FlowDroid [2] is a popu-lar static information flow tracker for Java and An-droid, which can be used to detect unwanted or po-tentially dangerous data flows. FlowDroid is tightlyintegrated into CodeInspect through CodeInspect’s ex-tensible plug-in interface. This allows the analyst toconfigure and conduct data flow analyses easily andefficiently. The results are graphically displayed insideCodeInspect as shown in Figure 6. The user can selectdifferent data flows, represented by data sources andsinks. After selecting a particular data flow, the plug-in highlights the corresponding statements that are re-

Figure 5: Call Hierarchy View

sponsible for the information flow and shows all rele-vant statements in the Calltrace View. With a click,the user can jump from the flow results directly intothe source code.

To fully understand an Android app, it is often im-portant to know certain runtime values. If the ana-lyst has found out that a malware application leaksdata via SMS, she must then find the target tele-phone number. For communication with a remotecommand&control server, she is interested in the URLof that server. Such values are, however, often notavailable in the app as plain text, but are obfuscated.Their final value only gets decrypted or computed atruntime. Manually undoing obfuscations is a cum-bersome and inefficient task. We therefore provideHarvester [11], an approach that fully automaticallyextracts such runtime values from Android applica-tions. It can also be used for e.g., deobfuscating re-flective method calls by first finding the correct tar-get method signature and then replacing the reflectivecall with a direct one. Harvester is well-integrated intoCodeInspect. The user can select a code positions (e.g.method arguments) from which she wants to extractruntime values. Harvester will then fully automati-cally extract possible runtime values for this particularset of variables. Similarly, she can select the reflectivemethod calls she wants to simplify. Harvester thenlooks for the receiver method and injects a direct call.

CodeInspect’s plugin interface is also open to otherdevelopers who want to extend the tool with additionalfunctionality. As CodeInspect is based on Eclipse, nor-mal Eclipse plugins can be used to provide new fea-tures such as support for more version control systemsor specific file type editors.

44

Figure 6: FlowDroid Plug-In4 Reverse Engineering Bad/Accents

Malware With CodeInspectIn this Section, we explain how CodeInspect can beused in a malware investigation. Such a manual re-verse engineering task is usually important if auto-mated approaches, such as a behavior analysis in asandbox [10, 14], provide no or only little evidence onquestions such as which data is stolen?, or where isthe data sent to?. In such cases, a manual inspectionis usually the only solution. We take the malware in-vestigation [13] of the Android/BadAccents malwareas an example to demonstrate the need for manual re-verse engineering. An automated pre-analysis of thismalware family hinted at a banking trojan, but it wasnot clear to the malware analyst where the stolen datafrom the SMS intercepting component of the malwarewas sent to. In the following we will explain in detailhow one could use CodeInspect during investigationssuch as the one on Android/BadAccents. The goal isto answer detailed questions such as the receivers ofstolen data on potentially obfuscated code.

4.1 APK Overview

The Android manifest provides a good starting pointin a manual malware investigation since it contains in-formation about the different components of the appalong with additional meta-information. In the con-text of the Android/BadAccents malware, one canidentify that com.shit.MainActivity is the class of the mainactivity, which gets called first when the user opens anapplication. Furthermore, the manifest also containsa broadcast receiver called com.a.a.AR which, in turn,

has an onReceive() method that gets executed wheneverthe device receives a new SMS message. Note thatthe receiver also reacts on other actions besides theSMS_RECEIVED, but these actions are less important. Themain activity and the receiver class are two interestingparts, which needs to be analyzed in more detail.

Besides the manifest, one can also use CodeInspect’ssearch function. Since we are looking for user e-mailcredentials, a simple lookup for “password” or “user”might return interesting code positions. Indeed, An-droid/BadAccents contains a few code statements thatcontain the two search words. The most interestingcode location is the one shown in the lower part ofFigure 7. It contains two api calls stringUser() andstringPassword() which are call native methods. Thesemethods take no parameters and return strings, i.e.,are simple native getters. The code section was exe-cuted in the onCreate() method of the main activity andthe api calls were directly executed without any specialtriggering.

Now, one could either reverse engineer the nativeimplementation of the two api calls or proceed with adynamic analysis. We could have extracted the nativecode into a new app and called the two methods thereto find the returned string values. Debugging the orig-inal malware app, however, required even less effort aswe explain in the next section.

55

Figure 7: Access to Email Credentials in the MainActivity

Figure 8: Runtime Values of Variables

4.2 Detailed Manual Analysis

One of the most powerful features of CodeInspect isthe interactive debugger. It allows a human analystto peform single-step debugging on the Jimple code.Whenever the execution is halted, she can examinethe current contents of all variables in scope in the livevariables view. This was very useful for extracting theconcrete username and password which are returnedfrom the two native API calls. A breakpoint in line 264in Figure 7 stops the program at that point and givesthe analyst the possibility to view the runtime valuesof the variable $String and $String2. These two valuesare temporarily stored on the file system and are laterused for sending the stolen data to the attacker’s emailaccount via the SMTP protocol. This answers the firstquestion in our investigation. We have informationabout email credentials, which were hidden in nativecode. However, we do not have a proof that thesecredentials are actually used for authentification.

A quick search for “mail” in the Jimple codeshows that the application contains a method called“MailSend” which sounds like the method which is re-ponsible for sending emails to the attacker. We use the“Open Call Hierarchy” feature of CodeInspect (see Fig-ure 9) and discover that the “MailSend” method getstriggered by the “onReceive” method which gets exe-cuted once the application receives an SMS (see Sec-tion 4.1). This shows that SMS data is indeed stolenand leaked via e-mail.

As a next step, we send an SMS message (number

Figure 9: Call Hierarchy View for the MailSendMethod

Figure 10: Sending an SMS Message to the Emulatorvia CodeInspect

“+861111” and text “Hello World!”) to the emulatoras shown in Figure 10. After single stepping throughthe Jimple code, we hit an interesting Code section(see Figure 11), which checks whether the incomingnumber starts with “+86” or “+82” which shows thatthe malware is expecting SMS messages from China orSouth Korea. This is an interesting result from the in-vestigation which shows that the malware is especiallytargeting users from China or South Korea.

Further stepping through the code leads to anotherinteresting code section as shown in Figure 12. Herewe can see that the malware expects a certain SMStext “ak40 1”. The purpose of this special commandis to activate and deactive stealing the incoming SMSmessages. After sending the “ak40 1” command to theemulator, all further incoming SMS messages are in-tercepted and sent to the attacker. Figure 13 showsthe usage of the “MailSend” method which leaks theincoming SMS message to the attacker with the cre-

Figure 11: Incoming SMS Number Check

66

Figure 12: Activation Command for Stealing IncomingSMS Messages

Figure 13: Variables View of the Debugger at theMailSend API Call

dentials that we have previously identified. This con-cludes the investigation on the malware’s e-mail inter-face. We have all information which were necessaryto proof that the Android/BadAccents steals incom-ing SMS messages and leaks them to the attacker viaemail.

5 Conclusion

In this paper, we have presented CodeInspect, a noveltool for manually reverse engineering malicious An-droid apps. The tool supports the human expertwith an expressive, typed intermediate representation,an interactive debugger, and various Android-specificanalyses. It greatly reduces the effort of the inves-tigation. As future work, we plan to integrate moreanalysis techniques and views into the tool.

References[1] Daniel Arp, Michael Spreitzenbarth, Malte Hub-

ner, Hugo Gascon, and Konrad Rieck. Drebin: Ef-fective and explainable detection of android mal-ware in your pocket. In NDSS. The Internet So-ciety, 2014.

[2] Steven Arzt, Siegfried Rasthofer, Christian Fritz,Eric Bodden, Alexandre Bartel, Jacques Klein,Yves Le Traon, Damien Octeau, and Patrick Mc-Daniel. Flowdroid: Precise context, flow, field,object-sensitive and lifecycle-aware taint analysisfor android apps. In Proceedings of the 35th ACMSIGPLAN conference on Programming languagedesign and implementation (PLDI). ACM, June2014.

[3] Michael Batchelder and Laurie J. Hendren. Ob-fuscating java: The most pain for the least gain.In Shriram Krishnamurthi and Martin Odersky,editors, CC, volume 4420 of Lecture Notes inComputer Science, pages 96–110. Springer, 2007.

[4] W. Beaton and J. d. Rivieres. Eclipse platformtechnical overview. Technical report, The EclipseFoundation, 2006.

[5] Saurabh Chakradeo, Bradley Reaves, PatrickTraynor, and William Enck. Mast: Triage formarket-scale mobile malware analysis. In Pro-ceedings of the Sixth ACM Conference on Securityand Privacy in Wireless and Mobile Networks,WiSec ’13, pages 13–24, New York, NY, USA,2013. ACM.

[6] Alessandra Gorla, Ilaria Tavecchia, Florian Gross,and Andreas Zeller. Checking app behavioragainst app descriptions. In ICSE’14: Proceedingsof the 36th International Conference on SoftwareEngineering, 2014.

[7] Johannes Hoffmann, Martin Ussath, ThorstenHolz, and Michael Spreitzenbarth. Slicing droids:Program slicing for smali code. In Proceedingsof the 28th Annual ACM Symposium on Ap-plied Computing, SAC ’13, pages 1844–1851, NewYork, NY, USA, 2013. ACM.

[8] Kantar. Android returns to growth in europe’sbig five markets. whitepaper, 2015.

[9] Patrick Lam, Eric Bodden, Ondrej Lhotak, andLaurie Hendren. The soot framework for java pro-gram analysis: a retrospective. In Cetus Usersand Compiler Infastructure Workshop (CETUS2011), Oktober 2011.

77

[10] Martina Lindorfer, Matthias Neugschwandner,Lukas Weichselbaum, Yanick Fratantonio, Vic-tor van der Veen, and Christian Platzer. An-drubis - 1,000,000 Apps Later: A View on Cur-rent Android Malware Behaviors. In Proceed-ings of the International Workshop on Build-ing Analysis Datasets and Gathering Experi-ence Returns for Security (BADGERS), Wroclaw,Poland, September 2014.

[11] Siegfried Rasthofer, Steven Arzt, Marc Mil-tenberger, and Eric Bodden. Harvesting run-time values in android applications that featureanti-analysis techniques. In 2016 Network andDistributed System Security Symposium (NDSS),2016.

[12] Pulse Secure. Mobile threat report 2015. whitepa-per, 2015.

[13] Stephan Huber Siegfried Rasthofer, Irfan Asrarand Eric Bodden. How current android malwareseeks to evade automated code analysis. In 9thInternational Conference on Information SecurityTheory and Practice (WISTP’2015), 2015.

[14] Michael Spreitzenbarth, Felix Freiling, FlorianEchtler, Thomas Schreck, and Johannes Hoff-mann. Mobile-sandbox: Having a deeper look intoandroid applications. In Proceedings of the 28thAnnual ACM Symposium on Applied Computing,SAC ’13, pages 1808–1815, New York, NY, USA,2013. ACM.

[15] Raja Vallee-Rai and Laurie J. Hendren. Jimple:Simplifying java bytecode for analyses and trans-formations, 1998.

88