1. I haz you and pwn your
maal
(Taking control of an Android phone
and its installed malware)
By Harsimran Walia
Research Scientist, McAfee Labs
2012

2. Abstract
The paper covers the evolution of malware that attacks the Android operating system and discusses the
different types of malware infections. I shall look at the lab setup the tools required, and the steps for
reverse-engineering the Android application package (APK) files to do the malware analysis. I’ll unpack
the APK and decompile the Dalvik (Android OS) executable to Java code. I’ll cover the basic reversing of
the Java code and patching and modifying it, examine how I can compile the code, and pack it back into
an APK. I’ll also discuss how Android malware analysis is different from Windows malware analysis.
The presentation includes a live demo of a malware. Now to tie this talk to its title: While reversing the
malware, I learned to which premium phone number the infected phone sends an SMS—thus I “have
you” (your number). And by reversing the malware and changing the SMS number to my own number, I
“own” the malware.
About the Author
Harsimran Walia is a research scientist at McAfee Labs. He graduated as with a degree in mechanical
engineering from the Indian Institute of Technology, in Delhi. Walia presented his research
at NullCon2011 on the topic "Reversing Microsoft patches to reveal vulnerable code." He is the author
of various technical blogs and research papers.

3. Introduction
The increasing use of smartphones, tablets, and other mobile devices means that we no longer need to
stay in one place to access data from our computers or the Internet. We can get lots of information on
the go. However, these relatively new technologies create a larger attack vector. Our current mobility is
a treasure trove for attackers because mobile security is not as mature as desktop and network
protection.
The ease of attack and vast amount of information on smartphones makes them hot targets for
attackers and data thieves. The most reliable way of attacking any system is via malware, which can
penetrate a host, extract information, stay hidden, and send data to the attacker. Using the same
method, attackers have created smartphone malware, which are delivered in the form of smartphone
applications.
Although there are many smartphone platforms—including Apple’s iOS, Android, Symbian, and
Blackberry—Android is by far the most popular with attackers. Why? Let’s start with Android’s leading
market share.
Figure 1: Market share of Android OS smartphones, through February 2012.

4. Figure 2: Market share of Android OS smartphone sales over a period of 1 year.
As we can see, more than 50 percent of smartphone customers use Android OS–based phones. Also, 61
percent of smartphone sales in the first quarter of 2012 were Android OS based, which has been the top
seller for the past year. Looking at these stats, attackers have no trouble choosing Android as the target
for their malware.
Market share is one big factor. Now let’s look at another: the development procedure for Android and
iOS.
iOS Android
Macintosh computer/laptop required Any development platform will do (Windows, Linux, Mac
,etc.)
Sign in to developer program Android is open source; anyone can download the SDK
Wait for verification No validation required to put an app on the market
The differences in development have led to headlines such as these:
• Android OS the “worst platform for malware”— TG Daily, August 2011
• Android threats leapt 76% during Q2-2011—McAfee
• Most attacked mobile OS overtaking Symbian OS
• The most popular target for mobile malware developers
• Increasing target for cybercriminals

5. Android Malware
Android Malware Analysis
For the same reason as the malware developers, I chose the Android platform for my mobile malware
analysis. Just like for Windows malware, we have two types of analyses for Android.
• Static. Reverse-engineer the application/malware using tools and techniques to recreate the
actual code and algorithm
• Dynamic. Check the behavior of the application/malware as it is executed on the system. Look
for the network and the system logs as the malware runs.
I will cover the following important procedures of Android malware analysis:
• Lab setup including a virtual machine with an Android SDK installation
• Tools required for the analysis
• Static analysis. Extracting and decompiling the malware to understand the code
• Dynamic analysis. Understanding the behavior of the malware and the network activity
• Patching the malware to own it and repacking it to a full-blown android app (.apk)
Types of Android Malware
During any analysis phase we figure out the behavior of the malware and identify its type. Let’s see the
different effects of the malwares vs. the count of malwares of these types.
Figure 3: Malware count and their effects.

6. Based on the different behaviors exhibited by malware samples we have analyzed, Android malware
can be classified into the following types:
• Mobile Device Data Stealers. The most common type of malware found in the wild. The sole aim is
to acquire information from the infected device, including:
– OS version
– Product ID
– International Mobile Equipment Identity (IMEI) number
– International Mobile Subscriber Identity (IMSI) number
This stolen device data may or may not be encrypted and sent via HTTP POST to the attacker. This
information can be used for future attacks against the victim or against others with the attacker
impersonating the victim.
• Rooting Capable. This type of malware gains root privileges, which enables the attacker to do
lots of interesting stuff that a normal user cannot do. Rooting provides remote access to files
and the device’s flash memory.
• With rooting, malware can drop copies of itself onto flash memory without being detected or
consequently deleted by antimalware products. The variety of things that attacker can do is
similar to the operations that can be performed by root on a Linux system.
• Premium Service Abusers. This malware takes advantage of the SMS manager in Android. Most
carry one or more hardcoded premium phone numbers in their code. The malware uses the
SMS manager to send messages to these premium numbers, which charge the victims for SMS
services without their knowledge.
• Mobile Device Spies. These stay hidden and secretly monitor and steal information stored on
the device. Some of this information includes:
– GPS location
– Text and email messages
– Like data stealers, sends stolen data to specific URLs via HTTP POST
– Focuses on gathering personal data
The information may be used for targeted attacks or just for spying. The focus of this type of
malware is to steal personal data.

7. One-Click Billing Fraud
This technique delivers a specific type of malware. The operation of the technique on a computer is
depicted by Figure 4.
Figure 4: The flow of one-click billing fraud.
This type of fraud is mostly active on porn and gamer video sites. An Android user would typically see a
pop-up window on the screen as the user tries to view a video. The pop-up asks the user to download a
(malicious) app to view the video. Upon installation, the malware gets the Android user’s account
information and sends it to the cybercriminals. Using the stolen information to build credibility and to
convince the victim to pay the amount, the malware displays a message such as “We haven’t received
your payment. Therefore, based on our policy, we will have to charge you if you have not paid yet.”
The pop-up appears every few minutes. As the victim keeps accepting, the malware eats his or her
money.

8. Need
• Malware analysis is an important part of daily activities in antimalware companies and in others.
Mobile malware analysis has become equally important for these companies.
• Effective analysis can be used by law enforcement agencies to catch malware authors and attackers
• For fun, when you can pwn someone else’s malware and control it. You get yourself full-blown
malware without writing it.
Practical Analysis Phase
Tools of the Trade
Here are several tools for both static and dynamic analysis.
Tools for static analysis
• Mobile Sandbox: Provides static analysis of malware images with an easily accessible web
interface for submission. http://www.mobile-sandbox.com (still in beta)
• IDA pro: The most common tool among reverse engineers for disassembly and debugging
supports Android byte code from the professional Versions 6.1 and later. http://www.hex-
rays.com/products/ida/6.1/index.shtml
• APKInspector: A powerful GUI tool for analyzing Android applications.
http://code.google.com/p/apkinspector/
• Dex2jar: For converting Android’s .dex format to Java’s .class format.
http://code.google.com/p/dex2jar/
• JD-GUI: A standalone graphical utility that displays Java source code of .class files. You can
browse the reconstructed source code with the JD-GUI for instant access to methods and fields.
http://java.decompiler.free.fr/?q=jdgui
• Androguard: Reverse engineering and malware analysis of Android applications.
http://code.google.com/p/androguard/
• JAD: Java Decompiler. http://www.varaneckas.com/jad
• Dexdump: Java .dex file format decompiler. http://code.google.com/p/dex-decomplier/
• Smali: Smali/baksmali is an assembler/disassembler for the dex format used by Dalvik,
Android’s Java VM implementation. The syntax is loosely based on Jasmin’s/dedexer’s syntax,
and supports the functions of the dex format (annotations, debug info, line info, etc.).
http://code.google.com/p/smali/

9. Tools for dynamic analysis
• Droidbox: An Android application sandbox for dynamic analysis that uses “static precheck,
dynamic taint analysis and API monitoring. Data leaks can be detected by tainting sensitive data
and placing taint sinks throughout the API. Additionally, by logging relevant API function
parameters and return values, a potential malware can be discovered and reported for further
analysis.” http://www.honeynet.org/gsoc/slot5, http://code.google.com/p/droidbox/
• The Android SDK: “A software development kit that enables developers to create applications
for the Android platform. The Android SDK includes sample projects with source code,
development tools, an emulator, and required libraries to build Android applications.
Applications are written using the Java programming language and run on Dalvik, a custom
virtual machine designed for embedded use which runs on top of a Linux kernel.”
http://www.webopedia.com/TERM/A/Android_SDK.html
Using the Android SDK we can create a virtual Android device almost identical in functionality
and capabilities to an Android phone and use that virtual device as secure environment in which
we can execute malware and observe its behavior.
Code: http://developer.android.com/sdk/index.html
• androidAuditTools: Dynamic Android analysis tools.
https://github.com/wuntee/androidAuditTools
Lab Setup
The traditional setup for malware analysis includes a virtual machine; we need one as well. We also
need to install the Android SDK in the machine. You can find details here:
http://developer.android.com/sdk/installing.html.
During the installation you will see a screen similar to this:

10. Figure 4: Choosing the version of the Android SDK API.
At this screen (Figure 4) you must select at least one version of the API. Different API versions are
required to develop applications for different Android versions (for ICS, Gingerbread, etc). We also need
a separate SDK for different malwares targeted for a particular Android version. For my demo I will use
the Version 2.3 (Gingerbread) SDK.
Analysis
Let’s start by getting our hands on an Android malware. We can analyze it to study its behavior. At
Contagio Mini (http://contagiominidump.blogspot.in/) you can get lots of mobile malware. It is
community driven: Anyone can submit a sample, and it is made available to others.
I have Voodoo SimpleCarrierIQDetector, a malicious Android application that is supposed to detect the
presence of the Carrier IQ mobile diagnostic software on the system. We are going to dig deep inside to
analyze the application and try to find the malicious code. My choice of malware depends on the ease
of understanding, but we also see very complex malware that sends an SMS based on country of the
victim.
Static Analysis
Once we have the APK malware, we start by using an online sandbox analysis to get a brief idea about
this threat.
Mobile-sandbox.com: Submitting the APK file on mobile-sandbox.com for analysis generates the
following report, which we can view at http://mobilesandbox.org/xml_report_static/?q=176.

11. Sample SHA256: 79a3bc6da45243355a920082dc67da0febf19379c25c721c43fd6b3f83ff4ef4
Sample MD5: 69b9691a8274a17cdc22e9681b3e1c74
Start of Analysis: Feb. 12, 2012, 11:34 p.m.
End of Analysis: Feb. 12, 2012, 11:34 p.m.
apk Name: 69b9691a8274a17cdc22e9681b3e1c74.apk
Package Name: Détecteur de Carrier IQ
SDK Version: 7
Files inside the APK-package:
android.hardware.telephony
Used Features:
android.hardware.touchscreen
Requested Permissions from Android android.permission.READ_LOGS
Manifest: android.permission.SEND_SMS
Used Permissions:
Responsible API calls for used Permissions:
android.intent.action.MAIN
Used Intents:
android.intent.category.LAUNCHER
Used Activities:
sendSMS
Potentially dangerous Calls: Execution of native code
getPackageInfo
Used Services and Receiver:
Used Providers:
Used Networks:
URLs:
From the report we are interested mainly in reading the two fields that are marked as red. The malware
asks permissions to read the logs and send SMS. The call made by the application that are potentially
dangerous, according to the report, is sendSMS.

12. Extraction: With this brief idea about the behavior and type of malware, we can start our manual
analysis. As a start, we need to extract the APK to get its contents. We can use WinRAR or WinZip on
this zipped file.
On extraction we see the following files. The file of interest is classes.dex.
Figure 5: Files extracted from the malicious APK.
dex2jar: The next step is to use dex2jar at the command prompt with the following commands. It will
convert our classes.dex file to a jar file.
C:> dex2jar.bat classes.dex
Output: classes.dex classes_dex2jar.jar
JD-GUI: From the jar file, we want to be able to reach the code to proceed with our analysis. After
opening the jar file with JD-GUI, it looks like this.
Figure 6: Jar file opened with JD-GUI.

13. We see four .class files. Let’s analyze them one by one.
• Detect.class: Based on some checks, we see that the code is trying to make out if the CarrierIQ
software is installed on the system
• R.class: Every Android application contains this class file. Here it is used to declare a few
variables
• Utils.class: Contains a few utility method definitions such as findFiles. getCommandOutput, etc.
• Main.class: This is the most interesting class because it contains the malicious code. The code
looks like this:
Figure 7: Malicious code highlighted by red boxes.
Code Analysis: The four highlighted lines of code are the same commands to send an SMS to the
number 81168 with four different SMS texts:
• AT37
• MC49
• SP99
• SP93
A Google search on that number tells it is a premium-rate number that costs almost €9 per message.
This is how criminals make money with mobile malware. Some malware listens to incoming messages
and deletes them before victims can read them when the messages are from service providers
informing users about their balance or billing charges.
While searching on Google I found a related Facebook scam. The victim gets messages from friends on
Facebook asking him to vote for a friend on some “Miss and Mister” contest. Following the malicious
link hacks the Facebook account, rendering it unusable. The attacker then calls the victim and says the

14. account has been blocked for some reason. The victim must send an SMS to number 81168, with any of
the four texts, to receive a code, which has to be given to the caller (the attacker) to unlock the account.
I haz you
I “haz” you now because I know the premium-rate phone number and the text messages being sent. To
catch the crooks, this is the time to get the police involved. Find the country and the operator to whom
the number belongs and persuade that company to disclose information on the malware author.
Sometimes Google helps a lot; you can often find substantial public information.
Pwnification
Now it’s time for some fun by owning the malware and making it dance to our tune. The following
technique will explain the process to own the malware, and you can generalize for other malware.
Baksmali: We use this program to disassemble the dex files. Using the following command to
disassemble classes.dex, we get .smali files, as shown in Figure 7.
C:> baksmali-0.93.jar –o smali-out classes.dex
Figure 7: Disassembling classes.dex presents us with several .smali files.
The.smali files, which can be opened in any text editor, have names similar to the .class files. Our file
with the malicious code is main$1.smali, which we figured out in the analysis phase. Opening the file in
a text editor shows us the malicious code:

15. Figure 8: Disassembled malicious code from main$1.smali.
Let’s change the destination number of the SMS. We find this in the first argument of the
sendTextMessage function call. Set this to your mobile number or any premium number that you own
to get yourself a malware. (But think of the consequence before using it for malicious intent. We
certainly don’t advise that you really do this.) I will change it to the port number of my Android
emulator, which I’ll use later for testing. Save the file.
Smali: Now we compile the .smali files into a .dex file. After making the desired changes to the smali
file and saving it, we compile all the .smali files together to classes.dex using the following command.
C:> smali-0.93.jar smali-out –o classes.dex
Packing: With the modified classes.dex, we pack the files back to a .zip file using any packer utility.
After packing, we rename it to .apk and voila: We are done with the modification process and we own
some malware.
Signing: Google has made it mandatory for an application (apk) to be signed by the owner/author’s
private key. The system will not install an application on an emulator or a device if it is not signed. We
can use self-signed certificates to sign your applications. No certificate authority is needed.
In order to sign the application you need
• Keytool – Comes as a part of jdk installation. Used to create your private key for signing.
Following command generates private keystore by the name of my-personal-key with the key
C:> keytool -genkey -v -keystore my-personal-key.keystore

16. -alias alias_name -keyalg RSA -keysize 2048 -validity 10000
Upon executing the above command it prompts you to provide passwords for the keystore and
key, and to provide the Distinguished Name fields.
• Jarsigner – Also comes as a part of jdk installation. Used to sign the apk with created keystore
Following command signs the modified apk with the private keystore
C:> jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore my-
release-key.keystore carrieriq.apk alias_name
Running the above command above, Jarsigner prompts you to provide passwords for the keystore
and key. It then modifies the APK in-place, creating the META_INF folder with the signing details
meaning the APK is now signed.
To verify if the apk is signed use
C:> jarsigner –verify -verbose my_ carrieriq.apk alias_name
If signed properly, it outputs “JAR verified”
That’s it and voila you are done with the whole modification process and you got your own malware.
Playing
Dynamic Analysis
Let’s have a little bit of fun by installing our new Android (malware) application on the Android SDK and
check if it really performs the functions that we intended. We open two instances of the Android
emulator and install the new malware on one of them while noting the SMS number should be the port
number of the emulator, rather than the number originally with the malware installation.
Upon installation and running the app, as soon as the uninstall button is clicked the SMS gets sent to the
other emulator. As seen in the figure we get all the four sms in the other emulator as expected from our
analysis.

17. I pwn your maal
I have modified your malware, customized it to my needs, and now I pwn you maal. From now on it’s
going to serve me.
Conclusion
This paper is an overview of how the Android smartphone OS has, in a short time, become the most
popular target for cybercriminals. The article describes the different types of malware created for the
Android platform. By analyzing Android malware, the paper attempts to explain the lab setup, tools
required, and static and dynamic malware analysis by practically analyzing a real premium-rate SMS-
sending malware. Our analysis shows us the origin of the malware and how can we own it. In short, “I
haz you and pwn your maal.”

18. References
1. http://www.droid-life.com/2012/05/07/androids-market-share-balloons-to-61-in-the-u-s-
during-q1-ios-drops-to-29/
2. http://community.trendmicro.com/t5/Malware-Discussions/Mobile-Malware-4-Types-of-
Android-Malware/td-p/44005
3. http://blog.trendmicro.com/one-click-billing-fraud-scheme-through-android-app-found/
4. TrendLabs: Quarterly security roundup
5. TrendLabs: 5 simple steps to secure your Android based smartphones
6. http://contagiominidump.blogspot.in