8th of December 2016
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 !
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.
For this exercise we do not need an internet connection. Disconnect your smartphone from the internet.
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.
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 IMG_20160629_115145933.jpg.enc IMG_20160629_115148191.jpg.enc ...
Reboot the phone.
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 !!!*
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):
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.
Reverse the malware bytecode:
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:
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 !
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:
d2j-dex2jar.sh 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 jbe.sh find the main class (use export CLASSPATH=
When JBE is running, change the encrypt() to a call to decrypt():
jbe.sh # Edit the file and save it
encrypt()and replace it by
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 .. d2j-jar2dex.sh 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
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 IMG_20160629_115145933.jpg.enc IMG_20160629_115145933.jpg IMG_20160629_115148191.jpg.enc IMG_20160629_115148191.jpg
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.
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.
The first thing that you can do is exploring your device with the 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:
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.
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.
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 com.android.bot run-as: Package 'com.android.bot' 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.
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 com.android.bot
If the phone does not ask for the password, you can try:
adb backup com.android.bot
Build the backup tool:
Unpack the backup:
./abe unpack ~/swap/backup-com.android.bot.ab ~/swap/backup.tar azerty tar -xvf backup.tar
You will obtain the malware 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.
(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.
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) ;.
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.
Setup a local web server that will print the HTTP requests (for example based on https://gist.github.com/huyng/814831)
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 ngrok.io domain:
Check that you get the full url in the console when your browser goes to:
The malware use the domain 14243444.com 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 14243444.com by XXXXXXXX.ngrok.io:
java -jar ./Soot-substitute-hostname.jar 14243444.com XXXXXXXX.ngrok.io 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
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.
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 !