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
50 4B 03 04 is the APK file signature and is located at offset
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
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 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.
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
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
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
com.android.root.Setting service exits.
Note: The analysis from this point forward is relevant to
Basic Static Analysis
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
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.
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/