投稿
翻译：shinpachi8
预估稿费：180RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
前言
最近，我们发现了一个新的Android rootnik恶意软件，它使用开源的Android root 利用工具和来自dashi root工具的MTK root方案来在Android设备上获得root权限。这个恶意软件伪装成一个文件助手，还使用了非常先进的反调试和反HOOK技术，用于防止其被逆向 。它还使用了multidex方案加载辅助的dex文件。 在成功获得设备上的root权限后，rootnik恶意软件可能会执行以下几种恶意行为，包括应用和广告宣传，推送色情内容，在主屏幕上创建快捷方式，静默安装应用程序，推送通知等。在这篇博客中， 我会提供对此恶意软件的深入分析。
恶意软件简介
恶意应用程序看起来像是一个正常合法的文件助手程序，来管理你保存的文件和手机上的其他资源。
图1 恶意软件安装图标
图2 恶意软件的一个界面
我们反编译APK文件，如图3所示。
图3 反编译的恶意软件
包名为com.web.sdfile。首先，我们来看看其AndroidManifest.xml文件。
图4 AndroidManifest.xml
我们在图4中找不到主Activity, com.sd.clip.activity.FileManagerActivity，服务类或广播类。显然，这个文件助手的主要逻辑不在classes.dex中。在分析之后，我们发现恶意软件应用程序使用multidex方案动态加载辅助dex文件并执行。
Rootnik是如何工作的
1.Rootnik的工作流程
以下是android rootnik恶意软件的工作流程。
图5 Android rootnik恶意软件工作流的概述
2.继续深入第一个dex文件
以下是SecAppWrapper类的代码段。
图6：类SecAppWrapper的代码段
执行流程如下所示。
Static code block -> attachBaseContext -> onCreate静态代码块将动态链接库libSecShell.so加载到文件夹资产中，然后程序进入Native层，执行几个反调试操作，解密辅助的dex文件，然后使用multidex方案加载解密的辅助 dex文件，这个DEX文件是应用的主要逻辑 。
DexInstall类实际上是MultiDex类，即：https://android.googlesource.com/platform/frameworks/multidex/+/d79604bd38c101b54e41745f85ddc2e04d978af2/library/src/android/support/multidex/MultiDex.java
然后程序调用DexInstall的安装方法来加载辅助dex文件。调用DexInstall的安装方法在Native层中执行的。
图7 安装辅助DEX文件
在attachBaseContext函数中，程序加载com.sd.clip.base.MyApplication类，它是辅助dex的执行入口。 Helper的方法attach是一个Native层方法。
在onCreate函数中，程序执行com.sd.clip.base.MyApplication 类的onCreate函数 。
这就完了。第一个dex其实相当简单。接下来，我们将对Native层代码进行深入分析，这是非常复杂和棘手的。
3. Native 代码层的范围
如上所述，Native层代码使用一些先进反调试和反HOOK技术，并且还使用若干解密算法来解密一些字节数组以获得纯文本字符串。
以下是libSecShell.so中的导出函数的一部分。由于混淆的函数名称，分析变得相当困难。
图8 libSecShell.so中部分导出函数
所有的反调试代码都位于JNI_Onload函数中。
如上一节所述，Java层中Helper类的attach方法是一个Native方法。 程序在Native层动态注册此方法。 以下是在Native层中注册Native方法的ARM汇编代码片段。
图9 在Native 层中动态注册Native函数
函数RegisterNatives用于注册Native方法。其接口如下所示。
jint RegisterNatives(JNIEnv env,jclass clazz, const JNINativeMethod methods,jint nMethods)
JNINativeMethod的定义如下所示。
typedef struct {
const char* name;
const char* signature;
void* fnPtr;
} JNINativeMethod;
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.我们接下来需要找到反调试代码的位置并绕过它，分析如何解密加密的辅助dex文件，并从内存中将dex文件DUMP出来。
让我们看看IDA中的以下代码：
图10 反调试代码片段
根据我们的深入分析，地址0xF832处的指令是跳转到地址loc_F924。 跟踪一些代码后，我们发现了反调试代码。
图11 反调试代码的位置
函数p7E7056598F77DFCC42AE68DF7F0151CA（）执行的是反调试的功能。
以下是它的图形执行流程，这是非常复杂的。
图12 反调试代码的图形执行流程
以下是一些在恶意软件中使用到的反调试和反HOOK的方法。
检测一些常用的HOOK框架，如Xposed，substrate，adbi，ddi，dexposed。一旦发现了使用这些流行的HOOK框架， 它会杀死相关的进程。
图13 检测XPOSED框架
图14 发现HOOK特性
然后使用一种多进程ptrace来实现反调试，这就比较棘手了。在这里我们不打算提供一个对反调试实现机制的详细的分析，只是给一些简单的解释。
我们可以看到有两个进程名为com.web.sdfile。
图15 命令为com.web.sdfile的两个进程
以下是多进程反调试代码的代码段。
图16 反调试代码片段
该程序还使用inotify来监视主进程的内存和主进程的映射。它导致内存的DUMP不完整。这两个进程使用管道相互通信。
总之，这些反调试和反HOOK方法为逆向创造了一个巨大的障碍。所以绕过他们是我们的第一个任务。
那么来吧， 让我们试着绕过他们。
如图10所示，偏移位置为0x0000F832处的指令跳转到loc_F924，然后程序开始执行这些反调试代码。我们可以动态修改某些寄存器或某些ARM指令的值，以便在动态调试时改变程序的运行流程。 当程序在偏移位置0xF828处执行指令“SUBS R1，R0，＃0”时，我们将寄存器R0的值修改为非零值，这将使“BNE loc_F834”的条件为真，使程序跳转至loc_F834。
图17 如何绕过反调试
接下来，我们就需要动态调试来绕过反调试，然后dump出解密的辅助dex文件。动态调试如下所示。
图18 将寄存器R0的值修改为非0
图19 跳到local_75178834
接下来，跳转到local_751788D8，如下所示。
图20 辅助dex的解密
函数p34D946B85C4E13BE6E95110517F61C41是解密函数。寄存器R0指向存储加密的dex文件的存储器，R1的值是dex文件的大小，即：0x94A3E（608830）。加密的dex文件是apk包中的文件夹中的secData0.jar。以下是文件secData0.jar。
图21 apk包文件夹assets中的 secData0.jar文件
图22 解密后的DEX文件在内存中的内容
我们现在可以将解密文件的内存dump到文件decrypt.dump中。
解密的文件是zip格式的文件，它包含辅助dex文件。解密后，程序将解密的辅助apk解压缩为dex文件。函数p3CBBD6F30D91F38FCD0A378BE7E54877用来解压缩文件。
接下来，函数unk_75176334调用类com.secshell.shellwrapper.DexInstall的java方法来加载解压缩出来的dex文件。
图23 解压apk文件并加载dex文件
图24 通过jni调用安装方法
在这里我们完成对Native层的分析，并获得解密后apk文件，我会将分析这个解密后的apk文件的内容放在这个博客的第二部分。
在Native层中解密secData0.jar的解密函数：
int __fastcall sub_7518394C(int result, _BYTE *a2, int a3)
{
int v3; // r1@1
int v4; // r3@5
unsigned int v5; // r3@7
int v6; // r6@7
int v7; // r5@7
char v8; // r2@8
int v9; // r4@9
int v10; // r3@9
int v11; // r7@11
_BYTE *v12; // r6@12
int v13; // r4@13
_BYTE *v14; // r1@15
int v15; // [sp+0h] [bp-138h]@1
int v16; // [sp+4h] [bp-134h]@1
_BYTE *v17; // [sp+8h] [bp-130h]@1
int v18; // [sp+10h] [bp-128h]@5
char v19[256]; // [sp+1Ch] [bp-11Ch]@6
int v20; // [sp+11Ch] [bp-1Ch]@1
v17 = a2;
v16 = result;
v20 = _stack_chk_guard;
v15 = a3;
v3 = 0;
if ( result <= 0x1FFFF )
{
v3 = 0x20000 - result;
if ( 0x20000 - result > a3 )
v3 = a3;
v15 = a3 - v3;
if ( v3 > 0 )
{
v18 = dword_751AF650;
v4 = 0;
do
{
v19[v4] = v4;
++v4;
}
while ( v4 != 256 );
v5 = 0;
v6 = 0;
v7 = 0;
do
{
v6 = (*(_BYTE *)(v18 + v5) + (unsigned __int8)v19[v7] + v6) & 0xFF;
v8 = v19[v7];
v5 = (v5 + 1) & -((v5 + 1 <= 0xF) + ((v5 + 1) >> 31));
v19[v7] = v19[v6];
v19[v6] = v8;
++v7;
}
while ( v7 != 256 );
v9 = 0;
result = 0;
v10 = 0;
while ( v9 != v16 )
{
v10 = (v10 + 1) & 0xFF;
v11 = (unsigned __int8)v19[v10];
++v9;
result = (v11 + result) & 0xFF;
v19[v10] = v19[result];
v19[result] = v11;
}
v12 = v17;
do
{
v10 = (v10 + 1) & 0xFF;
v13 = (unsigned __int8)v19[v10];
result = (result + v13) & 0xFF;
v19[v10] = v19[result];
v19[result] = v13;
*v12++ ^= v19[(v13 + (unsigned __int8)v19[v10]) & 0xFF];
}
while ( v12 != &v17[v3] );
}
}
if ( v15 > 0 )
{
v14 = &v17[v3];
result = (int)v14;
do
*v14++ ^= 0xACu;
while ( (signed int)&v14[-result] < v15 );
}
if ( v20 != _stack_chk_guard )
result = ((int (*)(void))unk_75173E48)();
return result;
}
