{"id":6398,"date":"2017-01-26T11:58:24","date_gmt":"2017-01-26T19:58:24","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/01\/26\/news-235\/"},"modified":"2017-01-26T11:58:24","modified_gmt":"2017-01-26T19:58:24","slug":"news-235","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/01\/26\/news-235\/","title":{"rendered":"Deep Analysis of Android Rootnik Malware Using Advanced Anti-Debug and Anti-Hook, Part I: Debugging in The Scope of Native Layer"},"content":{"rendered":"
\n

Recently, we found a new Android rootnik malware which uses open-sourced Android root exploit tools and the MTK root scheme from the dashi root tool to gain root access on an Android device. The malware disguises itself as a file helper app and then uses very advanced anti-debug and anti-hook techniques to prevent it from being reverse engineered. It also uses a multidex scheme to load a secondary dex file. After successfully gaining root privileges on the device, the rootnik malware can perform several malicious behaviors, including app and ad promotion, pushing porn, creating shortcuts on the home screen, silent app installation, pushing notification, etc.  In this blog, I’ll provide a deep analysis of this malware.<\/p>\n

A Quick Look at the Malware<\/h2>\n

The malware app looks like a legitimate file helper app that manages your files and other resources stored on your Android phone.<\/p>\n

\"\"<\/p>\n

Figure 1. The malware app icon installed<\/p>\n

\"\"<\/p>\n

Figure 2. A view of the malware app<\/p>\n

We decompiled the APK file, as shown in Figure 3.<\/p>\n

\"\"<\/p>\n

Figure 3. Decompile the malware app’s apk file<\/p>\n

Its package name is com.web.sdfile. First, let’s look at its AndroidManifest.xml file.<\/p>\n

\"\"<\/p>\n

Figure 4. AndroidManifest.xml file inside the malware app’s apk file<\/p>\n

We can’t find the main activity com.sd.clip.activity.FileManagerActivity, service class, or broadcast class in Figure 4.  Obviously, the main logic of the file helper app is not located in the classes.dex.  After analysis, it was discovered that the malware app uses the multidex scheme to dynamically load a secondary dex file and execute it.<\/p>\n

How Rootnik Works<\/h2>\n

I. Workflow of Rootnik<\/h3>\n

The following is the workflow of the android rootnik malware.<\/p>\n

\"\"<\/p>\n

Figure 5. An overview of the android rootnik malware’s workflow<\/p>\n

II. Going deep into the first dex file<\/h3>\n

The following is a code snippet of the class SecAppWrapper.<\/p>\n

\"\"<\/p>\n

Figure 6. A code snippet of the class SecAppWrapper<\/p>\n

The execution flow is shown below.<\/p>\n

\n

Static code block -> attachBaseContext -> onCreate<\/p>\n<\/blockquote>\n

The static code block loads the dynamic link library libSecShell.so into the folder assets, and the program enters into the native layer, performs several anti-debug operations, decrypts the secondary dex file, and then uses a multidex scheme to load the decrypted secondary dex file, which is actually the main logic of the real application.<\/p>\n

The class DexInstall is actually the class MultiDex, and it refers to<\/p>\n

https:\/\/android.googlesource.com\/platform\/frameworks\/multidex\/+\/d79604bd38c101b54e41745f85ddc2e04d978af2\/library\/src\/android\/support\/multidex\/MultiDex.java<\/a><\/p>\n

The program then invokes the method install of DexInstall to load the secondary dex file.  The invoking of the method install of DexInstall is executed in native layer.<\/p>\n

\"\"<\/p>\n

Figure 7. Installing the secondary dex file<\/p>\n

In function attachBaseContext, the program loads the class com.sd.clip.base.MyApplication, which is the execution entry of the secondary dex. The method attach of Helper is a native method.<\/p>\n

In function onCreate, the program executes the method onCreate of the class com.sd.clip.base.MyApplication.<\/p>\n

That’s it. The first dex file is rather simple. Next, we’ll do a deep analysis of the native layer code, which is very complicated and tricky.<\/p>\n

III. The scope of the native layer code<\/h3>\n

As described above, the native layer code uses some advanced anti-debug and anti-hook techniques, and also uses several decryption algorithms to decrypt some byte arrays to get the plain text string.<\/p>\n

The following is part of the export functions in libSecShell.so.  It becomes harder to analyze due to obfuscated function names.<\/p>\n

\"\"<\/p>\n

Figure 8. Part of export functions in libSecShell.so<\/p>\n

All anti-debug native code is located in function JNI_Onload.<\/p>\n

As described in the last section, the method attach of class Helper in java scope is a native method. The program dynamically registers this method in native layer.  The following is a snippet of the ARM assembly code that registers native method in native layer.<\/p>\n

\"\"<\/p>\n

Figure 9. Dynamically register native method in native layer<\/p>\n

The function RegisterNatives is used to register a native method. Its prototype is shown below.<\/p>\n

\n

jint RegisterNatives(JNIEnv *env,jclass clazz, const JNINativeMethod* methods,jint nMethods) <\/em><\/p>\n<\/blockquote>\n

The definition of JNINativeMethod is shown below.<\/p>\n

\n

typedef struct {
const char* name;
const char* signature;
void* fnPtr;
} JNINativeMethod;<\/em><\/p>\n

The first variable name is the method name in Java. Here, it’s the string “attach”. The third variable, fnPtr, is a function pointer that points to a function in C code. <\/p>\n<\/blockquote>\n

We next need to find the location of the anti-debug code and bypass it, analyze how the secondary dex file is decrypted, and the dump the decrypted secondary dex file from memory.<\/p>\n

Let’s look at the following code in IDA:<\/p>\n

\"\"<\/p>\n

Figure 10. Code snippet around anti-debug code<\/p>\n

Based on our deep analysis, the instruction at address 0xF832 is a jump to address loc_F924.<\/p>\n

After tracing some code, we found the anti-debug code.<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

Figure 11. The location of the anti-debug code<\/p>\n

The function p7E7056598F77DFCC42AE68DF7F0151CA() performs the anti-debug operations.<\/p>\n

The following is its graphic execution flow, which is very complicated.<\/p>\n

\"\"<\/p>\n

Figure 12. The graphic execution flow of anti-debug code<\/p>\n

The following are some methods of anti-debug and anti-hook used in the malware.<\/p>\n

1. Detect some popular hook frameworks, such as Xposed, substrate, adbi, ddi, dexposed. Once found, hook it using these popular hook frameworks. It then kills the related process.\"\"<\/p>\n

Figure 13. Detection of Xposed hook framwork<\/p>\n

\"\"<\/p>\n

\"\"<\/p>\n

Figure 14. Finding the hook feature<\/p>\n

2. It then uses an kind of multi-process ptrace to implement anti-debug, which is tricky a little.  Here we don’t plan to provide a deailed analysis of the anti-debugging implementation mechanism, but only give some simple explanations.<\/p>\n

We can see that there are two processes named com.web.sdfile.<\/p>\n

\"\"<\/p>\n

Figure 15. Two processes named com.web.sdfile<\/p>\n

    The following is a snippet of multi-process anti-debug code.<\/p>\n

\"\"<\/p>\n

Figure 16. A snippet of anti-debug code<\/p>\n

3. The program also uses inotify to monitor the memory and pagemap of the main process. It causes the memory dumping to be incomplete.  The two processes use pipe to communicate with each other.<\/p>\n

In short, these anti-debug and anti-hook methods create a big obstacle for reversing engineering.  So bypassing these anti- methods is our first task. <\/p>\n

Let’s try to bypass them.<\/p>\n

As described in Figure 10, the instruction at offset 0x0000F832 jumps to loc_F924, and then the program executes these anti-debug codes. We can dynamically modify the values of some registers or some ARM instructions to change the execution flow of the program when dynamically debugging.  When the program executes the instruction “SUBS R1, R0, #0” at offset 0xF828, we modify the value of register R0 to a non-zero value, which makes the condition of the instruciotn “BNE  loc_F834” become true. This allows the program to jump to loc_F834.  <\/p>\n

\"\"<\/p>\n

Figure 17. How to bypass the anti-debug code<\/p>\n

Next, we dynamically debug it, bypass the anti-debug, and then dump the decrypted secondary dex file. The dynamic debugging is shown below.<\/p>\n

\"\"<\/p>\n

Figure 18. Modifying the value of R0 to non-zero<\/p>\n

\"\"<\/p>\n

Figure 19. Jump to local_75178834<\/p>\n

Next,  jump to local_751788D8, as follows.<\/p>\n

\"\"<\/p>\n

Figure 20. Decryption function for the secondary dex<\/p>\n

The function p34D946B85C4E13BE6E95110517F61C41 is the decryption function. The register R0 points to the memory storing the encrypted dex file, and the value of R1 is the size of file and is equal to 0x94A3E(608830). The encrypted dex file is secData0.jar in the folder assets in the apk package. The following is the file secData0.jar.<\/p>\n

\"\"<\/p>\n

Figure 21. The file secData0.jar in the folder assets in the apk package<\/p>\n

\"\"<\/p>\n

Figure 22.  The content of the decrypted secondary apk file in memory<\/p>\n

We can now dump the memory of the decrypted file to the file decrypt.dump.<\/p>\n

The decrypted file is a zip format file, and it contains the secondary dex file. After decryption, the program decompresses the decrypted secondary apk to a dex file. The function p3CBBD6F30D91F38FCD0A378BE7E54877 is used to decompress the file.<\/p>\n

Next, the function unk_75176334 invokes the java method install of class com.secshell.shellwrapper.DexInstall to load the secondary dex.<\/p>\n

\"\"<\/p>\n

Figure 23. Decompressing the decrypted secondary apk and loading the secondary dex file<\/p>\n

\"\"<\/p>\n

Figure 24. Calling the method install via Jni<\/p>\n

Here we finish the analysis of native layer and get the decrypted the secondary apk file, then will analyze the apk file in the part II <\/a>of this blog.<\/p>\n

The Decryption Function That Decrypts secData0.jar in Native Layer:<\/h2>\n