The fight against malware is never-ending for a threat researcher, and in the mobile malware arena the fight is becoming more complex at an accelerated rate as the malware authors continue to create new ways of obfuscation.
Trojan.Dropper.RealShell is a malicious APK that drops another APK onto an Android device. The way it does this is through an interesting method of obfuscation that piqued our attention.
Trojan.Dropper.RealShell uses several files stored in the Assets folder to build another APK. It accomplishes this by reading from the files found in the Assets folder and then writing them into a single file with the extension .lock.
The .lock file is an Android RandomAccessFile which means it has the ability to read lines from one file, and then write them in a random or manually assigned sequence to another file. For example, let’s say we had a file named read.txt with three lines of text in it, and another file that is empty named write.txt which is a random access file.
If the three lines in read.txt were ice cream, I, like in that order you could read those lines from read.txt and then write them into write.txt in a different order such as I, like, ice cream.
The files in the Assets folder are written to the .lock file in a manually assigned sequence. The sequence in which the files are written into the .lock file is chosen by the use of a hex key that is plugged into a complex algorithm within the code. The hex key that is used is generated by using the parent malicious apps’ package name.
Function used to generate hex key from package name
Generated hex key displayed in LogCat
Once everything is written, a new APK is built from the .lock file. This method obfuscates the malicious apps’ intentions.
There is something odd about the newly built APK, though. It doesn’t have a manifest file or other resources which are necessary for the app to run. The manifest file holds essential information about an app in order for it to run.
Resources are things like images, strings, and libraries used in the app. So how is the newly built APK able to do anything? It uses the manifest file and resources from the parent APK that built it. It does this by using an Android class known as DexClassLoader which allows code that isn’t installed to be executed in the parent application.
The parent APK morphs into a completely different app that has new code, but uses the same resources stored in the parent APK to perform another task. So what does this newly built app do? It builds yet another APK which contains code of known PUP.RiskPay.Skymobi, a shady SMS payment SDK.
More specifically, it does this by using special libraries stored in the parent APK.
A library is a container of shareable source code that can be executed by an app. By executing the code in several of these special libraries, it builds the new PUP.RiskPay.Skymobi app. If you look at the hex code of one of these libraries, it’s clear what’s going on within its strings:
There it is in plain text, skymobi being decrypted and copied into its own APK. The skymobi APK is dropped into a folder on the Android device named “RealShell”. This new APK is fully functional with its own manifest file and all other resources in order for it to run independently.
It is quite intriguing the way the new APK is built, and then uses resources from the parent APK. This method could certainly be used to build more harmful APKs other than just a PUP. Malware on PCs have been using obfuscation tactics like these for years.
Obfuscation in mobile malware is nothing new, but the tactics are becoming more complex. This just shows that there is becoming more of a focus on mobile in the malware industry.
As more people replace PCs with tablets, smartphones, and other Android devices we fully expect this trend of more complex obfuscation on mobile malware to continue.
The more complex it becomes, the more of a threat it becomes to users. Make sure to stay protected by installing a scanner, like Malwarebytes Anti-Malware Mobile, on your Android device. Stay safe out there!