CISSI 2016: Reverse of Android malware

Jean-François Lalande

8th of December 2016

Exercise 1: Preparing an antidote for a ransomware


For this exercise, you should have one of the following smartphones:



In this exercise of the tutorial, we will study the SimpLocker malware which is a ransomware (SHA 256: 8a918c3aa53ccd89aaa102a235def5dcffa047e75097c1ded2dd2363bae7cf97). It encrypts the user’s files and displays a fullscreen warning asking to pay a ransom to decrypt the file. The malware is connected to the attacker via the Tor network but we do not need to let the malware connect to Tor.

The goal of this exercise is to understand how works the malware by reverse engineering its code. We will let the malware operate and encrypt your files… But then, we will write an antidote by modifying the malware to force it to decrypt the encrypted files !

Let’s go !

Step 1: connect your device

You should see your device by doing:

adb devices
List of devices attached
XXXXX	device

If you cannot see your device when you type adb devices check your adb installation and make sure Usb debugging option is enabled in Settings > Developers Options.

If you still can not see your device enable Settings > Storage > 3 vertically aligned dot (top-right) > Usb computer connection > Camera (PTP)

If you still can not see your device the last thing to do is to enable Settings > More > Tethering & portable hotspot > USB tethering

If your device is unauthorized, you should accept the fingerprint of the computer that connects to the smartphone on the smartphone screen.

Step 2: disconnect the phone from the internet

For this exercise we do not need an internet connection. Disconnect your smartphone from the internet.

Step 3: take a photo of yourself

We need to provide some personal data to the malware. Take a photo of yourself or something if you do not trust totally this tutorial…

Check in the gallery app that the photo is there.

Step 4: execute the SimpLocker malware

Install the malware (if the device asks you to share data with google, decline):

adb install SimpLocker.apk

Launch the malware by hitting the icon “Sex xonix” or “Locker” (depends of the phone language). You should see a fullscreen message.

Wait 1 minute (the malware encrypts your file). You can check the files to see if the malware produces .enc files:

adb shell ls /storage/sdcard0/DCIM/Camera

Reboot the phone.

adb reboot

Uninstall the malware:

adb uninstall org.simplelocker

Check the images of the gallery: you should not see your photo anymore. All your data is gone (encrypted) !!! Damn !!!*

Step 5: reverse a simple .apk

We propose to use BytecodeViewer which enables to open and decompile an Android application. It proposes several decompilers and basic search capabilities. Download the FATJAR version (that includes all plugins).

Test BytecodeViewer on a demo file demo1.apk that is a small application of three activities (three screens):

BytecodeViewer demo1.apk

Open the jf.andro.malcon15demo package and the MainActivity class. You should see a decompilation of the bytecode where two buttons are created in the activity.

This shows how it is simple to browse the source code of an app.

Step 6: reverse the SimpleLocker malware .apk

Reverse the malware bytecode:

BytecodeViewer SimpLocker.apk

Boom ! You obtain an exception “MALFORMED”. This is because one of the files (probably the Manifest) is malformed. This is an obvious protection of the malware developer to prevent any static analysis from classical tools (here apktool which is one of the components of BytecodeViewer). Thus, we will need to the reverse with manual operations.

Unpack the malware:

mkdir malware-source
cd malware-source
unzip ../SimpLocker.apk
cd ..

The code is located in malware-source/classes.dex. This is a jar file containing all the classes using the dex format. Open the classes.dex file that is well formed with BytecodeViewer:

BytecodeViewer malware-source/classes.dex

Now you can browse the code of SimpleLocker.

The malware developer is a well organized person. All the malicious code is located in the org.simplocker package. Have a look to:

You can use the search box (bottom left) to discover where the encrypt() function is called. Search all classes with Regex “encrypt()”. You should find that the MainService$5 class launches the encryption. Of course, the ciphering process is performed in background. We can suppose that the deciphering is also performed in a service.

Now, search the calls to decrypt(). You will discover that the call is handled in HttpSender. Of course, the malware waits for a message from the attacker’s server to decipher the files.

Modifying this part is not an easy task (but would be possible). A better idea is to modify the primary behavior of the malware when MainService$5 encrypts files. Instead of calling the encrypt() method, we will force MainService$5 to call the decrypt() method. This way, our new malware will act as an antidote !

Step 7: convert, edit the classes and repackage

The classes should be converted to the standard .class format in order to be edited. Convert the dex file to a jar file and extracted the classes: malware-source/classes.dex
mkdir malware-source-jar
cd malware-source-jar
unzip ../classes-dex2jar.jar

To change the class MainService$5.class, use the bytecode editor JBE. You have to patch the CLASSPATH to put in it the …/bin directory in order to have find the main class (use export CLASSPATH=pwd/bin).

When JBE is running, change the encrypt() to a call to decrypt():
  # Edit the file and save it


Repackage the classes in a jar file:

# In the malware-source-jar folder
jar cvf ../classes-patch.jar *

Convert the jar in the dex format:

cd .. classes-patch.jar

Backup and replace the classes.dex file:

# Backup of the original classes.dex
cp malware-source/classes.dex ./classes-backup.dex
# Replacing the classes.dex by the new one
cp classes-patch-jar2dex.dex malware-source/classes.dex

Rebuild the apk and sign it:

# Rebuilding the apk
cd malware-source
rm -rf META-INF
jar cvf ../simplocker-antidote.apk *
# Sign it with the debug key
cd ..
jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore  ~/.android/debug.keystore simplocker-antidote.apk androiddebugkey -storepass android -keypass android

We have now the antidote against SimpLocker :smile:

Step 8: deploy the antidote

Install the antidote (if the device asks you to share data with google, decline):

adb install simplocker-antidote.apk

Launch the malware by hitting the icon “Sex xonix” or “Locker”. You should see a fullscreen message.

Wait 1 minute (the antidote deciphers your file). You can check the files to see if the malware deciphers .enc files:

adb shell ls /storage/sdcard0/DCIM/Camera

Eventually reboot the phone. Uninstall adb uninstall org.simplelocker, open the gallery app. Your photos should reappear magically !


This malware is a fully functional ransomware that is able to decipher the encrypted files. The command is sent via the Tor network by the attacker, when the user has paid for recovering its files. The main drawback of the malware is the poor quality of the ciphering algorithm that uses a constant as encryption key. A more advanced version of such a malware should generate the key and store it on server side to become a more dangerous malware.

For more information, you can enjoy the Kharon webpage about this malware. The graph button gives you a view of the Tor process used to anonymize the communication with the attacker.


Exercise 2: Steal a malware


For this exercise, you should have one of the following smartphones:



In this exercise of the tutorial, we will steal the files that are created by a malware in the internal storage. Internal storage is the place where private files of applications are stored. On the contrary, external storage is the place where user’s files can be mounted via a USB cable. See Files for more details.

Let’s go !

Step 1: connect your device and explore

The first thing that you can do is exploring your device with the shell:

adb shell

At the root place /, you can list files. You will see several things:

Each application can write files in /data/data/packageid where packageid is the package name of your target application. Thus, we need to find how to get files from /data/data/packageid. If you need to find what is the package id, you can list all available installed apps:

pm list packages -f

List the processes of the system:


You will observe that the owner of the processes can be:

Step 2: Install a demo application

For testing purpose we will installa demo application that creates a file in the internal storage when you hit a button.

The next goal is to get this file, even if it is written in the internal storage.

Step 3: The Run-As method

As you can see on this webpage, two methods can be used to get files from the /data directory:

Let us use the first method. Switch of context using:


Use the command “whoami” to check your identity. Launch another shell in a second terminal and list the processes. You will see that your shell is now owned by the user associated to w.jf.andro.filewritting.

Use the pwd command to check where you are.

Use the cat command to display the content of the file your application have created.

Great !

Step 4: Let’s go on a malware

Get the MADDEN NFL 12 malware (SHA256: 213e042b3d5b489467c5a461ffdd2e38edaa0c74957f0b1a0708027e66080890). This application deploys some files in the internal storage. They could have been downloaded from the internet, but in this case they are embedded in the apk (thus of course, we can get it by uncompressing the apk but for the exercise we will suppose that they are dynamically generated by the malware, for example after a download).

Install it and try the run-as method:

shell@bullhead:/ $ run-as
run-as: Package '' is not debuggable

Of course, it does not work because this appilcation is not debuggable ! We have to use the second method: the backup method.

Step 5: The backup method

The principle of the method is to extract the app files using the backup functionality: the extracted file is an archive encrypted by AES. The difficulty is the deciphering of the archive.

Backup the files:

adb backup -noapk

If the phone does not ask for the password, you can try:

adb backup

Build the backup tool:

Unpack the backup:

./abe unpack ~/swap/ ~/swap/backup.tar azerty
tar -xvf backup.tar

You will obtain the malware files !

Step 6: Analyze the files

What are the type of these files ?

And the show continues…



Even on a non rooted device, there is some methods to get files that are generated by a malware. Of course it require to have access to the phone (a locked phone would be unusable) but then, the method is quite simple. The limitation is that a lot of malware download the payload but do not write them into files. But most of malware that gets some apk and push them for installation write files because this is the way new apps are deployed.

Exercise 3: Spying a Spyware

(in case you are very fast and needs a last exercise !)


For this exercise, you should use an Android emulator or a real smartphone (if there is some available). A kitkat version (Android 4.4) is fine, but newer version may work.



In this exercise of the tutorial, we will study the KitchenService malware which is a spyware (SHA 256: 2fbc32387f9b5c5a8678af3a76c0630ba4d04fd520b21782642a517794063f05). It leaks some user information to the internet and display web pages. What is cool is that the web pages still exist !

The goal of this exercise is to understand how works the malware by reverse engineering its code. Then we will try to capture the data when the malware leaks them.

Let’s go !

Step 1 - Reverse and study the malware

With the apktools, decode the apk. You should get the files in a directory sp_ntm.

Study the required permission in the Manifest file. You should get a better idea of the malware type by reading the asked permissions. You also see the declaration of a service KitchenTimerService.

Open the apk file with BytecodeViewer. Configure Pane 1 to open a reversed version of the code (CFR). Configure Pane 2 to open the Bytecode.

Study the class KitchenTimerService. You see the the service launches futur tasks (TimerTask) for an unavailable inner class. Search in the Bytecode
the type of the new TimerTask. When you have found this class, open it: You see that the messages are sent using an informative broadcast containing “Kitchen Timer Service”.

Open the Main class. The first place to look is the onCreate() method, which is called when the application is launched by the user. You’ll see several things:

Then, you have to inspect the KitchenTimerReceiver to see what happens when the intent is received. Yyou will see that the malware gets these informations:

And the malware makes the phone vibrate !

Then, a long loop starts a lof of other activities:

The malware takes care to reprogram a task with a call to Main.this.kitchenTimerService.schedule(120000L) ;.

Step 2 - Execute it

Execute the malware in the Android Emulator.

For launching the Android emulator:

Install the malware with:

adb install malware.apk

The malware appears with an anonymous icon.

Now, we want to spy the HTTP requests that are performed by the malware.

Step 3 - Setupt a local HTTP server

Setup a local web server that will print the HTTP requests (for example based on

Check that you get the full url in the console when your browser goes to:


Launch the ngrok tool, to create a tunnel from a regular internet url to your local web server:

./ngrok http 8080

Ngrok will create a dynamic url on the domain:

Check that you get the full url in the console when your browser goes to:

Step 4 - Change hostnames in the malware

The malware use the domain to disclose some informations. We need to force the malware to use our web server, i.e. our ngrok domain.

Use the Soot-substitute-hostname tools to replace by

java -jar ./Soot-substitute-hostname.jar  KitchenTimerReceiver 2fbc32387f9b5c5a8678af3a76c0630ba4d04fd520b21782642a517794063f05.apk

It will generate a new malware in the sootOutput folder.

Sign the malware:

jarsigner -verbose -sigalg MD5withRSA -digestalg SHA1 -keystore  ~/.android/debug.keystore simplocker-antidote.apk androiddebugkey -storepass android -keypass android

Step 5 - Launch the malware and see requests !

Connect your smartphone to the internet. Launch the malware. You should capture the leaks sent by the malware !


The capture of the HTTP traffic enables to see the parameters of the requests. It could also be used to answer these requests, for example if the malware is waiting for commands. Using ngrok enables to bypass any network configuration (but you need internet). For dangerous or unknown malware, you should not do this, because the malware have full access to the internet ! Thus, it would be more safe to implemet a controlled DNS server that will filter the requests.


About us and this tutorial


J.-F. Lalande is associate professor at INSA Centre Val de Loire. He is the only serious guy of the team. He proposes these exercises for building this tutorial as a hobby compared to the work achieved in the kharon project.

Valérie Viet Triem Tong is associate professor at CentraleSupélec and Inria. She’s the lead director of the kharon project (here is the view of the buildings). This also implies that working on malware means to fund others for working on malware !

Mourad Leslous is a PhD student from Inria and University of Rennes 1. He has more malware in his computer and phone than regular apps !

Korlan Colas is a master student at INSA Centre Val de Loire. He woke up very early (before noon) to write some parts of this tutorial or to develop graphical tools for seeing malware.

Aymeric Lambrecht is a master student at INSA Centre Val de Loire. If your smartphone is flashed correctly, then his job has been done right. He also bricked one 500€ smartphone in order to make AndroBlare still alive !