{
	"id": "a8b29401-1e97-4845-9440-a13fedf9cc92",
	"created_at": "2026-04-06T00:17:00.821122Z",
	"updated_at": "2026-04-10T03:20:51.199684Z",
	"deleted_at": null,
	"sha1_hash": "ba5184c016193f74d51d53fad09a254be8c2eb73",
	"title": "Deep Analysis of Android Rootnik Malware Using Advanced Anti-Debug and Anti-Hook, Part I: Debugging in The Scope of Native Layer",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5542583,
	"plain_text": "Deep Analysis of Android Rootnik Malware Using Advanced Anti-Debug\r\nand Anti-Hook, Part I: Debugging in The Scope of Native Layer\r\nBy Kai Lu\r\nPublished: 2017-01-26 · Archived: 2026-04-05 20:14:17 UTC\r\nRecently, we found a new Android rootnik malware which uses open-sourced Android root exploit tools and the MTK root\r\nscheme from the dashi root tool to gain root access on an Android device. The malware disguises itself as a file helper app\r\nand then uses very advanced anti-debug and anti-hook techniques to prevent it from being reverse engineered. It also uses a\r\nmultidex scheme to load a secondary dex file. After successfully gaining root privileges on the device, the rootnik malware\r\ncan perform several malicious behaviors, including app and ad promotion, pushing porn, creating shortcuts on the home\r\nscreen, silent app installation, pushing notification, etc.  In this blog, I’ll provide a deep analysis of this malware.\r\nA Quick Look at the Malware\r\nThe malware app looks like a legitimate file helper app that manages your files and other resources stored on your Android\r\nphone.\r\nFigure 1. The malware app icon installed\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 1 of 13\n\nFigure 2. A view of the malware app\r\nWe decompiled the APK file, as shown in Figure 3.\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 2 of 13\n\nFigure 3. Decompile the malware app’s apk file\r\nIts package name is com.web.sdfile. First, let’s look at its AndroidManifest.xml file.\r\nFigure 4. AndroidManifest.xml file inside the malware app’s apk file\r\nWe can’t find the main activity com.sd.clip.activity.FileManagerActivity, service class, or broadcast class in Figure 4. \r\nObviously, the main logic of the file helper app is not located in the classes.dex.  After analysis, it was discovered that the\r\nmalware app uses the multidex scheme to dynamically load a secondary dex file and execute it.\r\nHow Rootnik Works\r\nI. Workflow of Rootnik\r\nThe following is the workflow of the android rootnik malware.\r\nFigure 5. An overview of the android rootnik malware’s workflow\r\nII. Going deep into the first dex file\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 3 of 13\n\nThe following is a code snippet of the class SecAppWrapper.\r\nFigure 6. A code snippet of the class SecAppWrapper\r\nThe execution flow is shown below.\r\nStatic code block -\u003e attachBaseContext -\u003e onCreate\r\nThe static code block loads the dynamic link library libSecShell.so into the folder assets, and the program enters into the\r\nnative layer, performs several anti-debug operations, decrypts the secondary dex file, and then uses a multidex scheme to\r\nload the decrypted secondary dex file, which is actually the main logic of the real application.\r\nThe class DexInstall is actually the class MultiDex, and it refers to\r\nhttps://android.googlesource.com/platform/frameworks/multidex/+/d79604bd38c101b54e41745f85ddc2e04d978af2/library/src/android/support/mult\r\nThe program then invokes the method install of DexInstall to load the secondary dex file.  The invoking of the method\r\ninstall of DexInstall is executed in native layer.\r\nFigure 7. Installing the secondary dex file\r\nIn function attachBaseContext, the program loads the class com.sd.clip.base.MyApplication, which is the execution entry of\r\nthe secondary dex. The method attach of Helper is a native method.\r\nIn function onCreate, the program executes the method onCreate of the class com.sd.clip.base.MyApplication.\r\nThat’s it. The first dex file is rather simple. Next, we’ll do a deep analysis of the native layer code, which is very\r\ncomplicated and tricky.\r\nIII. The scope of the native layer code\r\nAs described above, the native layer code uses some advanced anti-debug and anti-hook techniques, and also uses several\r\ndecryption algorithms to decrypt some byte arrays to get the plain text string.\r\nThe following is part of the export functions in libSecShell.so.  It becomes harder to analyze due to obfuscated function\r\nnames.\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 4 of 13\n\nFigure 8. Part of export functions in libSecShell.so\r\nAll anti-debug native code is located in function JNI_Onload.\r\nAs described in the last section, the method attach of class Helper in java scope is a native method. The program\r\ndynamically registers this method in native layer.  The following is a snippet of the ARM assembly code that registers native\r\nmethod in native layer.\r\nFigure 9. Dynamically register native method in native layer\r\nThe function RegisterNatives is used to register a native method. Its prototype is shown below.\r\njint RegisterNatives(JNIEnv *env,jclass clazz, const JNINativeMethod* methods,jint nMethods)\r\nThe definition of JNINativeMethod is shown below.\r\ntypedef struct {\r\nconst char* name;\r\nconst char* signature;\r\nvoid* fnPtr;\r\n} JNINativeMethod;\r\nThe first variable name is the method name in Java. Here, it’s the string “attach”. The third variable, fnPtr, is a\r\nfunction pointer that points to a function in C code. \r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 5 of 13\n\nWe next need to find the location of the anti-debug code and bypass it, analyze how the secondary dex file is decrypted, and\r\nthe dump the decrypted secondary dex file from memory.\r\nLet’s look at the following code in IDA:\r\nFigure 10. Code snippet around anti-debug code\r\nBased on our deep analysis, the instruction at address 0xF832 is a jump to address loc_F924.\r\nAfter tracing some code, we found the anti-debug code.\r\nFigure 11. The location of the anti-debug code\r\nThe function p7E7056598F77DFCC42AE68DF7F0151CA() performs the anti-debug operations.\r\nThe following is its graphic execution flow, which is very complicated.\r\nFigure 12. The graphic execution flow of anti-debug code\r\nThe following are some methods of anti-debug and anti-hook used in the malware.\r\n1. Detect some popular hook frameworks, such as Xposed, substrate, adbi, ddi, dexposed. Once found, hook it using these\r\npopular hook frameworks. It then kills the related process.\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 6 of 13\n\nFigure 13. Detection of Xposed hook framework\r\nFigure 14. Finding the hook feature\r\n2. It then uses an kind of multi-process ptrace to implement anti-debug, which is tricky a little.  Here we don’t plan to\r\nprovide a detailed analysis of the anti-debugging implementation mechanism, but only give some simple explanations.\r\nWe can see that there are two processes named com.web.sdfile.\r\nFigure 15. Two processes named com.web.sdfile\r\n    The following is a snippet of multi-process anti-debug code.\r\nFigure 16. A snippet of anti-debug code\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 7 of 13\n\n3. The program also uses inotify to monitor the memory and pagemap of the main process. It causes the memory dumping to\r\nbe incomplete.  The two processes use pipe to communicate with each other.\r\nIn short, these anti-debug and anti-hook methods create a big obstacle for reversing engineering.  So bypassing these anti-methods is our first task. \r\nLet’s try to bypass them.\r\nAs described in Figure 10, the instruction at offset 0x0000F832 jumps to loc_F924, and then the program executes these\r\nanti-debug codes. We can dynamically modify the values of some registers or some ARM instructions to change the\r\nexecution flow of the program when dynamically debugging.  When the program executes the instruction “SUBS R1, R0,\r\n#0” at offset 0xF828, we modify the value of register R0 to a non-zero value, which makes the condition of the instruction\r\n“BNE  loc_F834” become true. This allows the program to jump to loc_F834.  \r\nFigure 17. How to bypass the anti-debug code\r\nNext, we dynamically debug it, bypass the anti-debug, and then dump the decrypted secondary dex file. The dynamic\r\ndebugging is shown below.\r\nFigure 18. Modifying the value of R0 to non-zero\r\nFigure 19. Jump to local_75178834\r\nNext,  jump to local_751788D8, as follows.\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 8 of 13\n\nFigure 20. Decryption function for the secondary dex\r\nThe function p34D946B85C4E13BE6E95110517F61C41 is the decryption function. The register R0 points to the memory\r\nstoring the encrypted dex file, and the value of R1 is the size of file and is equal to 0x94A3E(608830). The encrypted dex\r\nfile is secData0.jar in the folder assets in the apk package. The following is the file secData0.jar.\r\nFigure 21. The file secData0.jar in the folder assets in the apk package\r\nFigure 22.  The content of the decrypted secondary apk file in memory\r\nWe can now dump the memory of the decrypted file to the file decrypt.dump.\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 9 of 13\n\nThe decrypted file is a zip format file, and it contains the secondary dex file. After decryption, the program decompresses\r\nthe decrypted secondary apk to a dex file. The function p3CBBD6F30D91F38FCD0A378BE7E54877 is used to decompress\r\nthe file.\r\nNext, the function unk_75176334 invokes the java method install of class com.secshell.shellwrapper.DexInstall to load the\r\nsecondary dex.\r\nFigure 23. Decompressing the decrypted secondary apk and loading the secondary dex file\r\nFigure 24. Calling the method install via Jni\r\nHere we finish the analysis of native layer and get the decrypted the secondary apk file, then will analyze the apk file in the\r\npart II of this blog.\r\nThe Decryption Function That Decrypts secData0.jar in Native Layer:\r\nint __fastcall sub_7518394C(int result, _BYTE *a2, int a3)\r\n{\r\nint v3; // r1@1\r\nint v4; // r3@5\r\nunsigned int v5; // r3@7\r\nint v6; // r6@7\r\nint v7; // r5@7\r\nchar v8; // r2@8\r\nint v9; // r4@9\r\nint v10; // r3@9\r\nint v11; // r7@11\r\n_BYTE *v12; // r6@12\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 10 of 13\n\nint v13; // r4@13\r\n_BYTE *v14; // r1@15\r\nint v15; // [sp+0h] [bp-138h]@1\r\nint v16; // [sp+4h] [bp-134h]@1\r\n_BYTE *v17; // [sp+8h] [bp-130h]@1\r\nint v18; // [sp+10h] [bp-128h]@5\r\nchar v19[256]; // [sp+1Ch] [bp-11Ch]@6\r\nint v20; // [sp+11Ch] [bp-1Ch]@1\r\nv17 = a2;\r\nv16 = result;\r\nv20 = _stack_chk_guard;\r\nv15 = a3;\r\nv3 = 0;\r\nif ( result \u003c= 0x1FFFF )\r\n{\r\nv3 = 0x20000 - result;\r\nif ( 0x20000 - result \u003e a3 )\r\nv3 = a3;\r\nv15 = a3 - v3;\r\nif ( v3 \u003e 0 )\r\n{\r\nv18 = dword_751AF650;\r\nv4 = 0;\r\ndo\r\n{\r\nv19[v4] = v4;\r\n++v4;\r\n}\r\nwhile ( v4 != 256 );\r\nv5 = 0;\r\nv6 = 0;\r\nv7 = 0;\r\ndo\r\n{\r\nv6 = (*(_BYTE *)(v18 + v5) + (unsigned __int8)v19[v7] + v6) \u0026 0xFF;\r\nv8 = v19[v7];\r\nv5 = (v5 + 1) \u0026 -((v5 + 1 \u003c= 0xF) + ((v5 + 1) \u003e\u003e 31));\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 11 of 13\n\nv19[v7] = v19[v6];\r\nv19[v6] = v8;\r\n++v7;\r\n}\r\nwhile ( v7 != 256 );\r\nv9 = 0;\r\nresult = 0;\r\nv10 = 0;\r\nwhile ( v9 != v16 )\r\n{\r\nv10 = (v10 + 1) \u0026 0xFF;\r\nv11 = (unsigned __int8)v19[v10];\r\n++v9;\r\nresult = (v11 + result) \u0026 0xFF;\r\nv19[v10] = v19[result];\r\nv19[result] = v11;\r\n}\r\nv12 = v17;\r\ndo\r\n{\r\nv10 = (v10 + 1) \u0026 0xFF;\r\nv13 = (unsigned __int8)v19[v10];\r\nresult = (result + v13) \u0026 0xFF;\r\nv19[v10] = v19[result];\r\nv19[result] = v13;\r\n*v12++ ^= v19[(v13 + (unsigned __int8)v19[v10]) \u0026 0xFF];\r\n}\r\nwhile ( v12 != \u0026v17[v3] );\r\n}\r\n}\r\nif ( v15 \u003e 0 )\r\n{\r\nv14 = \u0026v17[v3];\r\nresult = (int)v14;\r\ndo\r\n*v14++ ^= 0xACu;\r\nwhile ( (signed int)\u0026v14[-result] \u003c v15 );\r\n}\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 12 of 13\n\nif ( v20 != _stack_chk_guard )\r\nresult = ((int (*)(void))unk_75173E48)();\r\nreturn result;\r\n}\r\nSource: https://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nhttps://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer\r\nPage 13 of 13\n\ndo {   \nv6 = (*(_BYTE *)(v18 + v5) + (unsigned __int8)v19[v7] + v6) \u0026 0xFF;\nv8 = v19[v7];   \nv5 = (v5 + 1) \u0026 -((v5 + 1 \u003c= 0xF) + ((v5 + 1) \u003e\u003e 31)); \n  Page 11 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.fortinet.com/2017/01/24/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer"
	],
	"report_names": [
		"deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer"
	],
	"threat_actors": [],
	"ts_created_at": 1775434620,
	"ts_updated_at": 1775791251,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ba5184c016193f74d51d53fad09a254be8c2eb73.pdf",
		"text": "https://archive.orkl.eu/ba5184c016193f74d51d53fad09a254be8c2eb73.txt",
		"img": "https://archive.orkl.eu/ba5184c016193f74d51d53fad09a254be8c2eb73.jpg"
	}
}