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.
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.
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:
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.
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.
Figure 43. The payload files
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
Figure 46. The traffic of sending collected info to remote server
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.
Figure 49. The root exploit executables
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)
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:
It uses the utility “pm uninstall” of android system to uninstall app.
Figure 63. Execute pm uninstall to uninstall app via shell command
The following are some screenshots for pushed porn.
Figure 64. Porn pushed to the device by the app
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
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
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
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
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/
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.
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.
Package Name: com.web.sdfile
Additional APK files dropped into system partition by Rootnik malware
Package Name: com.br.srd
Package Name: com.oyws.pdu
Sign up for weekly Fortinet FortiGuard Labs Threat Intelligence Briefs and stay on top of the newest emerging threats.