2012

I haz you and pwn your

maal (Taking control of an Android phone

and its installed malware)

By Harsimran Walia

Research Scientist, McAfee Labs

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.

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.

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

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.

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.

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.

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/

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:

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.

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:

Used Features: android.hardware.telephony

android.hardware.touchscreen

Requested Permissions from Android

Manifest:

android.permission.READ_LOGS

android.permission.SEND_SMS

Used Permissions:

Responsible API calls for used Permissions:

Used Intents: android.intent.action.MAIN

android.intent.category.LAUNCHER

Used Activities:

Potentially dangerous Calls:

sendSMS

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.

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.

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

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:

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

-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.

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.”

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