【木马分析】使用高级反调试与反HOOK的安卓恶意ROOT软件的深度分析（一）：NATIVE层的调试

翻译：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;
}