安全路透社
当前位置:安全路透社 > 安全客 > 正文

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

http://p2.qhimg.com/t01e67807d701f7ab0c.png

翻译:shinpachi8

预估稿费:180RMB

,或登陆网页版

前言


最近,我们发现了一个新的Android rootnik恶意软件,它使用开源的Android root 利用工具和来自dashi root工具的MTK root方案来在Android设备上获得root权限。这个恶意软件伪装成一个文件助手,还使用了非常先进的反调试和反HOOK技术,用于防止其被逆向 。它还使用了multidex方案加载辅助的dex文件。 在成功获得设备上的root权限后,rootnik恶意软件可能会执行以下几种恶意行为,包括应用和广告宣传,推送色情内容,在主屏幕上创建快捷方式,静默安装应用程序,推送通知等。在这篇博客中, 我会提供对此恶意软件的深入分析。


恶意软件简介


恶意应用程序看起来像是一个正常合法的文件助手程序,来管理你保存的文件和手机上的其他资源。

http://p5.qhimg.com/t01fe705cd7bf07b157.png

图4 AndroidManifest.xml

我们在图4中找不到主Activity, com.sd.clip.activity.FileManagerActivity,服务类或广播类。显然,这个文件助手的主要逻辑不在classes.dex中。在分析之后,我们发现恶意软件应用程序使用multidex方案动态加载辅助dex文件并执行。


Rootnik是如何工作的


1.Rootnik的工作流程

以下是android rootnik恶意软件的工作流程。 

http://p3.qhimg.com/t010532419f8d74f35d.png

图5 Android rootnik恶意软件工作流的概述

2.继续深入第一个dex文件

以下是SecAppWrapper类的代码段。

http://p9.qhimg.com/t01bee29b49777c3e82.png

图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层中执行的。

http://p3.qhimg.com/t011846f5ca71ff5661.png

图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中的导出函数的一部分。由于混淆的函数名称,分析变得相当困难。

http://p5.qhimg.com/t01f6970f5154b240be.png

图8 libSecShell.so中部分导出函数

所有的反调试代码都位于JNI_Onload函数中。

如上一节所述,Java层中Helper类的attach方法是一个Native方法。 程序在Native层动态注册此方法。 以下是在Native层中注册Native方法的ARM汇编代码片段。

http://p5.qhimg.com/t01e223543f038befdb.png

图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中的以下代码:

http://p5.qhimg.com/t01e223543f038befdb.png

图10 反调试代码片段

根据我们的深入分析,地址0xF832处的指令是跳转到地址loc_F924。 跟踪一些代码后,我们发现了反调试代码。

http://p5.qhimg.com/t01e223543f038befdb.png

http://p1.qhimg.com/t0114ed3a513b040734.png

图11  反调试代码的位置

函数p7E7056598F77DFCC42AE68DF7F0151CA()执行的是反调试的功能。

以下是它的图形执行流程,这是非常复杂的。

http://p3.qhimg.com/t0179cc96d6bce14a34.png

图12 反调试代码的图形执行流程

以下是一些在恶意软件中使用到的反调试和反HOOK的方法。

检测一些常用的HOOK框架,如Xposed,substrate,adbi,ddi,dexposed。一旦发现了使用这些流行的HOOK框架, 它会杀死相关的进程。

http://p7.qhimg.com/t013f6683f9e23f5be6.png

图13 检测XPOSED框架

http://p5.qhimg.com/t01211fecea34360800.png

http://p3.qhimg.com/t01dd938b96da0e4623.png

图14 发现HOOK特性

然后使用一种多进程ptrace来实现反调试,这就比较棘手了。在这里我们不打算提供一个对反调试实现机制的详细的分析,只是给一些简单的解释。

我们可以看到有两个进程名为com.web.sdfile。

http://p8.qhimg.com/t01f092c9c9fdfd13a8.png

图15 命令为com.web.sdfile的两个进程

以下是多进程反调试代码的代码段。

http://p7.qhimg.com/t01a0b275e2e66d45db.png

图16 反调试代码片段

该程序还使用inotify来监视主进程的内存和主进程的映射。它导致内存的DUMP不完整。这两个进程使用管道相互通信。

总之,这些反调试和反HOOK方法为逆向创造了一个巨大的障碍。所以绕过他们是我们的第一个任务。

那么来吧, 让我们试着绕过他们。

如图10所示,偏移位置为0x0000F832处的指令跳转到loc_F924,然后程序开始执行这些反调试代码。我们可以动态修改某些寄存器或某些ARM指令的值,以便在动态调试时改变程序的运行流程。 当程序在偏移位置0xF828处执行指令“SUBS R1,R0,#0”时,我们将寄存器R0的值修改为非零值,这将使“BNE loc_F834”的条件为真,使程序跳转至loc_F834。

http://p4.qhimg.com/t01932b57ca8f8d0a27.png

图17 如何绕过反调试

接下来,我们就需要动态调试来绕过反调试,然后dump出解密的辅助dex文件。动态调试如下所示。

http://p7.qhimg.com/t016a0657c035c7f4f5.png

图18 将寄存器R0的值修改为非0

http://p1.qhimg.com/t0142d4bc32cb0959f2.png

图19 跳到local_75178834

接下来,跳转到local_751788D8,如下所示。

http://p6.qhimg.com/t012f3ed624c374ee5a.png

图20 辅助dex的解密

函数p34D946B85C4E13BE6E95110517F61C41是解密函数。寄存器R0指向存储加密的dex文件的存储器,R1的值是dex文件的大小,即:0x94A3E(608830)。加密的dex文件是apk包中的文件夹中的secData0.jar。以下是文件secData0.jar。

http://p9.qhimg.com/t0150142a91ce9383a9.png

图21 apk包文件夹assets中的 secData0.jar文件

http://p8.qhimg.com/t01c718bbde4396292b.png

图22 解密后的DEX文件在内存中的内容

我们现在可以将解密文件的内存dump到文件decrypt.dump中。

解密的文件是zip格式的文件,它包含辅助dex文件。解密后,程序将解密的辅助apk解压缩为dex文件。函数p3CBBD6F30D91F38FCD0A378BE7E54877用来解压缩文件。

接下来,函数unk_75176334调用类com.secshell.shellwrapper.DexInstall的java方法来加载解压缩出来的dex文件。

http://p9.qhimg.com/t01b9df2e0063e2690c.png

图23 解压apk文件并加载dex文件

http://p4.qhimg.com/t01e903f8815fdc32d8.png

图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;
}


原文链接: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

未经允许不得转载:安全路透社 » 【木马分析】使用高级反调试与反HOOK的安卓恶意ROOT软件的深度分析(一):NATIVE层的调试

赞 (0)
分享到:更多 ()

评论 0

评论前必须登录!

登陆 注册