[ Technical Tear Down: SIMPLELOCKER, ANDROID Ransomware ]

[ Sample used in the analysis ]
MD5: FD694CF5CA1DD4967AD6E8C67241114C
SHA1: 808DF267F38E095492EBD8AEB4B56671061B2F72

This is one of the latest Android ransomware that we got. It can be found in Mila’s website and you can take a look at the VirusTotal analysishere. The ransomware is TOR enabled and goes about encrypting files in the Android system and subsequently requesting for ransom before the key will be given to decrypt the files. Now let’s look at the technical details of the ransomware.
I’ve attached the link to the file here for anyone interested to try analysing it themselves.
The password to the attachment is “infected29A

[ Tools Used ]
Cebero Profiler is used to disassemble the apk file to analyse the smali code.
Dex2Jar and Java Decompiler are used to decompile the apk file to a jar file and subsequently to get the java code for analysis.
Android Emulator is used for the dynamic analysis portion.

[ Files ]
Below is the list of files after using Cebero Profiler to disassemble the apk file.


[ Manifest File ]

Below is the full manifest file extracted from the .apk file:


[ Permissions ]
Now let’s take a look at the AndroidManifest.xml file. When installing the application, the user is prompted with a list of permissions the application requires.


The permissions are more or less harmless in nature and doesn’t throw a redflag as in the case with other malwares. The permissions that could raise any kind of suspicion are android.permission.RECEIVED_BOOT_COMPLETED and android.permission.WAKE_LOCK. RECEIVED_BOOT_COMPLETED permission is required to allow an application to receive a broadcast that the system has finished booting up. WAKE_LOCK permission is required to keep the processor from sleeping or screen from dimming.
Both these permissions look harmless at first look but could be used to run an application upon bootup and keep it running without being pushed to suspended state by the Android operating system.

[ Source Code Analysis ]
From the manifest file, Main.class file is first launched upon starting of the app. The Main.class checks whether the MainService.class is running and if not calls it. MainService.class is linked to 5 other classes. MainService1.class, MainService2.class, MainService3.class, MainService4.class and MainService5.class. These classes are all interlinked.  What it does:

• Checks whether the TOR connection is established.
• If not try to establish a TOR connection.
• Next it gets a list of predetermined file extensions..
• Gets the filename of all files in the external storage that has any of the file extension.
• Does an AES encryption of the files.
• Displays a message presuming asking for an ransom.

Now let’s look at 2 class files that is of special interest. As it reveals more information about how the ransomware works. First is the Constants.class file. Look at the screenshot below.


The first constant ADMIN_URL which point to http://xeyocsu7fu2vjhxs.onion/ is the TOR site the ransomware connects to. This explains why it checks and tries to establish TOR connection upon starting. 2nd piece of information we can find from the “Constants” class is that it contains a variable EXTENSIONS_TO_ENCRYPT which contains the following file extensions: “jpeg”, “jpg”, “png”, “bmp”, “gif”, “pdf”, “doc”, “docx”, “txt”, “avi”, “mkv”, “3gp”, “mp4”. As the name of the variable suggest, this is the file extensions which the Ransomware would encrypt.

Another key piece on information is the CIPHER_PASSWORD, “jndlasf074hr“. Is this the key used to encrypt the files? If yes, could it also decrypts the files? For this, we take a look at the FileEncryptor.class. Look at the screenshot below of two of the functions:


As you can see from the functions, the encrypt and decrypt routine is fairly straightforward, AES using “jndlasf074hr“. Now let’s take a look at the AesCrypt class.


AesCrypt has both the encrypt and decrypt functions. Thus for example if you have installed the app by mistake and your files are now encrypted, you can re-use the functions to decrypt the files without the need to pay the ransom!!!

2 other interesting classes are “HttpSender” & “HttpSender$1”, as it send data & fetches JSON data from “http://xeyocsu7fu2vjhxs.onion/“.

[ Dynamic Analysis ]

I installed the app onto an emulator to test how it works. As it was executed on the emulator it could not perform all the ransomware “features”. But from the errors thrown, you can confirm the flow of the features. And also another reason is so that I need not turn one phone into a brick just in case it does some irreversible damage to the device.

Upon installing, it is displayed as a porn app as shown from the name of the icon.


When the app is run, it shows a message in Russian and this screen just keeps on popping up consistently even when the app is closed.


So what does actually it do in the background. Let’s check the logcat.


Obviously it is trying to establish a TOR connection which it can’t and this is repeated continuously.


There are also a lot of error messages thrown by the external libraries (which are actually *.so files needed for TOR connection) and also error that the app could not excess the External Storage which it needs to access in order to encrypt the files.

These confirms the flow of the ransomware features/actions as discussed earlier in the static analysis portion.

[ Conclusion ]

In conclusion, the ransomware is most probably marketed as an porn app and upon installing will establishes a TOR connection to the C&C and  encrypts the victim’s files and will subsequently asks for an ransom in order to decrypt back the files. However on closer observation, a technically savvy person could decrypt the files without paying the ransom as the decryption key is hardcoded within the app itself. But to be absolutely safe, don’t install porn apps 🙂

David Billa (@billa316)




Leave a Reply