Deep Analysis of Android Rootnik Malware Using Advanced Anti-Debug and Anti-Hook, Part II: Analysis of The Scope of Java

In part I of this blog we finished the analysis of the native layer and got the decrypted secondary dex file. Here in part II we will continue to analyze it. For the sake of continuity, we will maintain continuous section and figure numbers from part I of the blog.

IV. The secondary dex file

The following is the decrypted file, which is a jar format file.  It is loaded dynamically as the secondary dex via multidex scheme.

Figure 25. The decrypted secondary apk file containing the dex file

After decompressing the file “decrypt.dump,” you can now see a file named “classes.dex” located in the folder.

Next, let’s analyze the classes.dex.

Figure 27. Decompile the secondary dex file and AndroidManifest.xml file

From above figure, we can see that classes.dex is the main logic of the malware app named “file Helper”

The following is the function “onCreate” in class com.sd.clip.activity. FileManagerActivity.

Figure 28. The function onCreate in class FileManagerActivity

Figure 29. The function initadv()

Figure 30. The class Nws

The function getStart in class Nws is then used to start the service com.hg.mer.PG. The following is the definition of class PG.

Figure 31. The service class com.hg.mer.PG

After the function startService() is invoked, the function onCreate() is then invoked, followed by invoking the function onHandleIntent().  In the above figure, we marked four lines of the key code in red, and then analyzed them in order.

1. readDex()

The following is the snippet code in function readDex().

Figure 32. The function readDex()

Based on my analysis, the class Sheu is a base64 implementation class, so the result of Sheu.decode("S0suYmlu") is the string “KK.bin”.  Next, the program opens the file KK.bin in its assets folder and reads its content to extract some useful info.

The following is the file content of KK.bin:

Figure 33. The file KK.bin in folder assets

The program could extract some content from the end of the KK.bin file. There are seven strings there encoded using base64 that are stored in an array list. The function getAppid() is then used to decode these strings.

Figure 34. The function getAppid()

The result of decoding these seven strings is shown below:

Pls.Kbin: wddex.jar

Pls.OI: xdt

Pls.PL: com.svq.cvo.Rtow

Pls.Jr: getDex

Pls.Wv: sgdex

Pls.As: dos.jar

Pls.NQ: KK.bin

2 .dxfile()

The following is the code snippet of the function dxfile().

Figure 35. The function dxfile()

Figure 36. The function UnZipFolder()

The function Pls.UnZipFolder() extracts the encrypted content from KK.bin. The content starts at offset 0x20 and ends at offset 0x1CDB in the file KK.bin, and then is saved as /data/data/com.web.sdfile/files/wddex.jar. Its content is encrypted using the DES algorithm.

In the function dxfile() the program decrypts the file contents of /data/data/com.web.sdfile/files/wddex.jar to file /data/data/com.web.sdfile/app_sgdex/dos.jar.

3 .DexClassLoader()

Its constructor is shown below:

In this invocation, the value of dexPath is “/data/data/com.web.sdfile/app_sgdex/dos.jar,” and the value of optimizedDirectory is “/data/data/com.web.sdfile/app_xdt.”

This function loads classes from the .jar and .apk files containing a classes.dex entry. This function can be used to execute code not installed as part of an application. The optimized dex files are written in the file dos.dex in the folder data/data/com.web.sdfile/app_xdt.

After loading classes from /data/data/com.web.sdfile/app_sgdex/dos.jar, the program deletes this file.

4. Invoke getDex() method in class com.svq.cvo.Rtow dynamically.

Next, let’s examine dos.dex.

Figure 37. Decompile the dex file dos.dex

The following is the function getDex in class com.svq.cvo.Rtow:

Figure 38. The function getDex in class com.svq.cvo.Rtow

Figure 39. The constructor of class Dwol

In the constructor of class com.kdw.xoa.Dwol, a new file mda.ico is created in folder /data/data/com.web.sdfile/files/. It then invokes the function downloadFile to download a payload from remote server http://gt[.]rogsob[.]com/stmp/ad.png, and saves it as /data/data/com.web.sdfile/files/mda.ico. The payload is encrypted using the DES algorithm.

……

Figure 40. The function downloadFile

Figure 41. The function initData()

The following is the definition of the function silentInstall.

Figure 42. The function silentInstall

The five parts marked in red in order are explained below.

1. The function dxfile of class Dwol is used to decrypt the payload /data/data/com.web.sdfile/files/mda.ico. The decrypted payload is saved as /data/data/com.web.sdfile/app_snex/dkt.jar.
2. The function upZipFile of class Ngss is used to decompress the decrypted payload dkt.jar into the folder /data/data/com.web.sdfile/files/. It contains the following files:

Figure 43. The payload files

3. After decompressing, it deletes the files /data/data/com.web.sdfile/app_snex/dkt.jar and /data/data/com.web.sdfile/files/mda.ico, and deletes the directory /data/data/com.web.sdfile/app_snex/.
4. Renames the file classes.dex to wsh.jar in folder /data/data/com.web.sdfile/files/.
5. Dynamically loads classes from /data/data/com.web.sdfile/files/wsh.jar, and the optimized directory app_outdex stores the dex cache file as wsh.dex.
6. Invokes the function getDex in class com.rootdex.MainActivity.

Next, we will look deep into the wsh.dex, which mainly executes the root tool to root the device and install the application in the system app folder.

Figure 44. The decomple the dex file wsh.dex

The following is the definition of the function getDex of class com.rootdex.MainActivity.

Figure 45. The function getDex in class com.rootdex.MainActivity

1. The function GetActive is used to collect device information and send it to the remote server. The URL of remote server is http://grs[.]gowdsy[.]com:8092/active.do. The following is a capture of the traffic:

Figure 46. The traffic of sending collected info to remote server

2. Checks if some files exist in folder /data/data/com.web.sdfile/files/ and adds their file name into an array list it is preparing for the next step of rooting the device.
3. Executes rooting tools on the device.

Next, the function HandleRoot() is invoked in function run().

Figure 47. The function HandleRoot()

The following is a key code snippet of the function copyRootFile.

Figure 48. The function copyRootFile

In this function, there are four steps.

1. FileUtil.dxfile() is used to decrypt the file /data/data/com.web.sdfile/files/png.ico and save it as the file /data/data/com.web.sdfile/app_dex/.do.
2. FileUtil.UnZip() is used to decompress the file /data/data/com.web.sdfile/app_dex/.do into folder /data/data/com.web.sdfile/.rtt, which is a hidden system folder that contains six ELF executables, as shown below. It includes four root exploits r1,r2,r3,r4.

Figure 49. The root exploit executables

3. It deletes the decrypted root tools /data/data/com.web.sdfile/app_dex/.do and folder /data/data/com.web.sdfile/app_dex.
4. It then creates a new file, psneuter.js, in folder /data/data/com.web.sdfile/files/. Its contents are shown below.

Figure 50. The file psneuter.js

The function hanleOriMiddle is invoked in function executeRootAct. The following are four code snippets used to execute root exploits via a shell command:

Figure 51. Execute root exploits via shell command

After investigating these executable files, I found that r3 is the MTK root scheme from the dashi root tool, the exploits method in r4 comes from one exploit(CVE-2013-6282) of the open source project android-rooting-tools, and the exploit method in r2 is the CVE-2012-6422 which is a root exploit on Samsung Exynos.

The function hanleOriMiddle executes root exploits and some commands via a shell command. All executed shell commands are shown below:

Figure 52. All commands executed when rooting device

After successfully gaining root access, the script named psneuter.js is executed with super user privilege. The main purpose of this script is to install root privilege applications in folder /system/priv-app/.

Later, we will investigate these two new APK files. To avoid being caught by common users, these two apps have no icons on a victim’s device after being installed.

Additionally, the other script named rsh is then executed via a shell command.

Figure 53. Execute the script rsh via shell command

The script rsh is different, based on the Build.MANUFACTURER property. The script is shown below.

Figure 54. The script rsh(1)

Figure 55. The script rsh(2)

V. How BSetting.apk works

As shown in Figure 50, abc.apk was dropped in the folder /system/priv-app/ and renamed to BSetting.apk, and BSetting.apk was installed via pm.

BSetting.apk serves as a remote control service, and it fetches tasks from the remote server and performs them.

This app runs in the background and does not have a launcher icon on the device. The following is the app information.

Figure 55. App info of BSetting.apk

The app disguises itself as an Android sync service. The decompiled structure of the apk file is shown below:

Figure 56. Decompiled abc.apk

Figure 57.  The AndroidMainfest.xml in abc.apk

The BroadcastReceiver com.sfy.oyr.R performs the main logic of this app.

Figure 58. The class R

The program first decrypts jif.png in the folder assets. It’s a dex file, and the program uses java reflection to load class and invoke some methods.

We decompiled the decrypted dex file, as shown below:

Figure 59. Decompile classes.dex

The function launchTancTask in class ADService is used to fetch tasks from the remote server and perform them.

Figure 60. Fetching a task from the remote server

The traffic from fetching the task is shown below.  The remote server has two domains. One is the main domain grs[.]gowdsy[.]com, and the other is backup domain grs[.]rogsob[.]com. The response from the remote server is an xml file that contains the type of task, the url used to push porn, the url of the downloading apk, and the type of app to install, etc.

Figure 61. The traffic of fetching the task from the remote server

Depending on the type of task fetched, the app executes the task in a different way. The following is the key code snippet:

Figure 62. Execute the task depending on the type of task

The remote control service is capable of performing multiple malicious behaviors, including but not limited to the following:

1. Uninstall app

It uses the utility “pm uninstall” of android system to uninstall app.

Figure 63. Execute pm uninstall to uninstall app via shell command

2. Push porn

The following are some screenshots for pushed porn.

Figure 64. Porn pushed to the device by the app

3. Create a shortcut on the home screen

The shortcuts found contain porn, hot app, hot video, etc. The following is the code snippet and some screenshots of the shortcuts created.

Figure 65. The snippet of creating the shortcut on home screen

Figure 66. Shortcuts on home screen

4. App and ad promotion

In addition to gaining root privileges on the device, the rootnik malware promotes apps and ads to generate revenue for its creator. Its app and ad promotion is especially aggressive and annoying to the user.

The following are some screenshots of its app promotion:

Figure 67. App and ad promotion

5. Normal app installation and silent app installation

The malware uses different ways to install an app, depending on the type of task that has been fetched. The following is the code snippet of a normal app installation that has a user-interface view during the installation process.

Figure 68. Normal app installation

The app uses the utility “pm install -r” of the Android system to silently install non-system apps while it drops APK files into the folder /system/priv-app/ to install system apps.

Figure 69. Silent non-system app installation

In the folder /data/app/ we found that some apk files (including, but not limited to the following) had been installed.

Figure 70. Apps installed in the folder /data/app/ by the malware

Figure 71.Command to install system app

In the folder /system/priv-app/ we found that some apk files (including, but not limited to the following) had also been installed.

Figure 72. Apps installed in folder /system/priv-app/ by the malware

6. Push notification

The malware pushes a notification and induces the user to click it to open the URL in a browser.

The following is the code snippet of the pushed notification.

Figure 73. Snippet of pushed notification

Figure 74. Push notifications used by the malware

7. Download files

We found that there are many files and folders downloaded in folder /sdcard/. They include apk files, jar files, pictures, log files, etc.These files are generated by the installed apps, and some of them perform malicious behaviors.

Figure 75. The files and folders dowonloaded in folder /sdcard/

Solution

The malware sample is detected by Fortinet Antivirus signature Android/Rootnik.PAC!tr.

The traffic communicating with remote C2 server can be detected by Fortinet IPS signature Android.Rootnik.Malware.C2.

Summary

From the analysis above, we can see that the rootnik malware is very powerful and uses very advanced anti-debugging and anti-hooking techniques to prevent reversing engineering, and different types of encryption for files and strings. Additionally, it also uses a multidex scheme to dynamically load and install the secondary dex file that is the main logic of this malware.  The malware uses some open-sourced Android root exploit tools and the MTK root scheme from dashi root tool to gain root access on the Android device.  After successfully gaining root privileges on the device, the rootnik malware can perform a variety of malicious, including app and ad promotion, pushing porn, creating shortcuts on the home screen, silent app installation, and pushing notifications, etc. 

Appendix

Rootnik Malware Sample

Package Name: com.web.sdfile

SHA256: E5E22B357893BC15A50DC35B702DD5FCDFEAFC6FFEC7DAA0D313C724D72EC854

Additional APK files dropped into system partition by Rootnik malware

Package Name: com.br.srd

SHA256: E2BDCFE5796CD377D41F3DA3838865AB062EA7AF9E1E4424B1E34EB084ABEC4A

Package Name: com.oyws.pdu

SHA256: CEE6584CD2E01FAB5F075F94AF2A0CE024ED5E4F2D52E3DC39F7655C736A7232

C&C Server

gt[.]rogsob[.]com

grs[.]gowdsy[.]com:

qj[.]hoyebs[.]com

qj[.]hoyow[.]com

gt[.]yepodjr[.]com