All the malware analysis related articles on my blog so far have been PE malware. But malware isn’t restricted to Windows OS. There are malware for Linux, macOS, IoT-related OSes, etc. In this article, I’ll break down an Android malware called DroidDream which was infamous back in 2011. It affected Android versions before 2.3 (Gingerbread).
Android applications are written in Java. The .class bytecode (after compiling Java source code) is then converted to .dex bytecode (using the DEX compiler). The .dex bytecode is consumed by the Android RunTime (or Android Dalvik Virtual Machine for older Android versions) which sits on top of a HAL (Hardware Abstraction Layer) over Linux.
I was able to obtain DroidDream’s APK (Application Package) file sample from Hybrid-Analysis. The APK zip file contains a .dex file which we’ll convert to a .jar file for analysis. The dex-to-jar conversion is lossy, so you will find many weirdly located break or return statements and loop expressions that don’t makes sense. Also, I’ve skipped dynamic analysis for this sample because my aim is to write about source code analysis.
Let’s get it!
Basic Static Analysis
File Signature
50 4B 03 04 is the APK file signature and is located at offset 0.
Hashes
MD5: ecad34c72d2388aafec0a1352bff2dd9
SHA256: 83e813b09918219649863cc7140d715d6df6e5fc77a208f6be6be48ec5a4a475
AndroidManifest.xml
The AndroidManifest.xml file contains information about:
- Target Android SDK,
- Entry Point of application,
- Application Activities,
- Spawned services, and
- Permissions required by the application
Also, DroidDream’s code is part of the main application, which in this case is Super Guitar Solo. So, the target Android SDK version may be relevant to the main application and not the malware. However, the malware is sure to run on versions before the target SDK version. In this case, DroidDream executed successfully on Android versions prior to Android Gingerbread (2.3).
The entry point of the application is the package, com.android.root.main. In this variant, only the com.android.root.Setting service is started by the malware. It also uses multiple permissions related to the Internet and phone calls.
Advanced Static Analysis
The only important piece of code in com.android.root.main.class is the one which starts the service com.android.root.Setting. The rest of the code belongs to the main application.
The first item of interest is the decryption of a hard-coded encrypted URL using a hard-coded key. The adbRoot.crypt() function in adbRoot.class decrypts its argument using a single-key XOR operation. The decrypted URL is http://184.105.245.17:8080/GMServer/GMServlet.
It then calls a few functions to determine device information, encrypts it using the same hard-coded key and POSTs it to the above URL in XML format.
After sending the device information, DroidDream proceeds to execute the exploid exploit.
The exploid exploit is stored in a file in the assets/exploid file in the APK. The exploit is then run to escalate privileges.
If the exploit is successful, the sample goes on to change the WiFi state. The source code here is quite confusing, so I’m not sure if my reasoning is correct. According to the code, it seems that the WiFi state is toggled but I can’t understand a reason to do so. It makes sense if the WiFi is turned on if it is turned off initially.
The sample proceeds to place the su binary in /system/bin/ directory. The su binary must be called by an application to be given root access. In this case, the su binary is named profile. The ELF file, assets/profile is copied to /system/bin/profile, the SUID bit set on it and executed.
Once the su binary is successfully placed, the sample restores WiFi state to its previous state.
The sample then deletes the exploid file from the device.
Now, the sample is ready to execute another exploit, RageAgainstTheCage which will give it root access. The exploit is present in assets/rageagainstthecage file in the APK.
At this point, if the exploit was successful the malware has root access on the device; the exploitation phase ends here. Post-exploitation phase starts now.
The sample checks if a package, com.android.providers.downloadsmanager is installed. If not, it copies the file assets/sqlite.db to /system/app/DownloadProvidersManager.apk
DownloadProvidersManager.apk is installed with root privileges in the ensuing block of code which is in the form of Java bytecode. Unfortunately, it looks like the person who submitted the sample modified it and commented out the entire runRootCommand() function.
While explaining the bytecode is out of scope, the function calls to install APKs (shown in this SO article) are very similar to the invoked functions in the runRootCommand() bytecode.
After installing DownloadProvidersManager.apk, the com.android.root.Setting service exits.
Note: The analysis from this point forward is relevant to DownloadProvidersManager.apk file.
Basic Static Analysis
Hashes
MD5: a891aa9095fd2f21cedb41d882916b09
SHA256: 94ea44688feb558e2786e52fbfa46d90984e40c0980e28035fd2311d5f17f8e3
AndroidManifest.xml
DownloadProvidersManager.apk is installed (with root privileges) as a broadcast receiver. It starts a service named DownloadManageService and requires several permissions as well.
Advanced Static Analysis
The DownloadManageService service will be started when the device reboots or when the user makes a call-related action (picking up call, declining call, etc.)
A task is scheduled to run after 2 minutes and every 2 hours.
The main code of the task runs only between 23:00 and 08:00. This is also the time when most people sleep.
It queries for downloaded applications.
It decrypts the URL with the same key as before.
It builds an XML payload containing device and downloaded applications’ information.
The sample embeds the XML payload in the URL that it decrypted before.
It then connects with the C&C and sends user device information. The code responsible for this is in Java bytecode.
The sample then determines the next time to connect to the C&C server and stores this value. I’m not sure where the sample gets this value from, but I believe in its communication with the C&C server, it receives an XML payload which has an element named, NextConnectTime in it.
After storing device and downloaded applications’ information in its application database, the timed task completes.
Summary
DroidDream is an Android-based malware embedded inside another legitimate application. It uses the WiFi, multiple permissions, starts a background service and also, installs an embedded APK file. It executes two Linux local privilege exploits to escape the application sandbox and gain root access on the device. Since it achieves root, it is capable of virtually anything. However, the variant that I analyzed only periodically sent device and downloaded applications’ information to the C&C server.
Thanks for reading!
In this article, I describe my analysis for an Android malware — DroidDream. After understanding the capabilities of an Android malware, it is quite frightening to realize that mobile devices are less protected than desktops or servers but the malware can be equally destructive.
Thank you for reading! If you have any questions, leave them in the comments section below and I’ll get back to you as soon as I can!
Feature image credits: https://hackersonlineclub.com/malware-analysis/
P.S. I also write on my blog https://0x90sploiter.wordpress.com.
Originally published at http://0x90sploiter.wordpress.com on July 28, 2019.
