乐固加固脱壳过程

今年1月份，我对Android rootnik恶意APP变种进行了深入分析并发布了此博客。此后，我继续监控这个Android恶意APP家族。6月初，FortiGuard实验室发现Android rootnik恶意APP的一个伪装成合法APP的新变种。它使用开源的Android root exploit工具在Android设备上获得root权限。事先说明，Google Play中找不到此恶意APP。恶意APP的作者从Google Play重新打包合法的APP，并将恶意代码插入其中。此APP的合法版本和重新打包版本都使用相同的包名net.gotsun.android.wifi_configuration。这种伪装甚至可以骗过细心的用户。此外，恶意APP使用高级反调试技术来防止其被逆向。在Android设备上成功获得root权限后，恶意APP可以执行恶意操作，包括应用和广告宣传，静默应用安装，推送通知，发送短信等。在本博客中我将对这个恶意APP变种进行深入分析。

快速查看恶意APP

恶意APP是一个名为Wi-Fi Auto-connect的APP的重新打包的版本，它是一个WiFi实用程序。此应用未受感染的版本仍可在Google Play上使用。


我们将恶意APP的APK文件与合法应用的APK文件反编译后的结构进行了比较，如图所示。

然后我们比较了它们的AndroidManifest.xml。


如图所示，我们可以看到，这两个应用的名称都是net.gotsun.android.wifi_configuration。我们还可以看到恶意APP的AndroidManifest.xml文件包含合法APP的AndroidManifest.xml副本。此外，它还包括大量其它支持其恶意activity的Android组件。我们在恶意APP中找不到合法应用的APK的结构，这意味着此恶意APP已打包。所以，我们需要首先脱壳获取恶意APP真正的DEX文件。

如何脱壳

以下是恶意APP的APK文件中的文件结构。

com.tencent.StubShell.TxAppEntry是恶意APP的入口。以下是该类中的attachBaseContext()函数。

在此函数中，恶意代码加载库libshel​​la-2.10.3.1.so，然后调用用于解密classes.dex中隐藏的数据的native方法以获取真正DEX文件并加载它。执行函数attachBaseContext()后执行onCreate()函数。

可以调用native方法runCreate()来运行真正的程序。接下来，我们开始分析和调试libshel​​la-2.10.3.1.so。ELF文件libshel​​la-2.10.3.1.so的section头已修改，这导致我们在使用IDA Pro静态分析时无法正确识别和解析它，需要动态调试。在libshel​​la_2.10.3.1.so的.init_array段中，有两个函数地址。在执行.init_array之前，以下是libshella_2.10.3.1.so的段。

第二个函数是sub_19C0()。以下是sub_19C0()函数中的关键代码片段。

sub_CED4()函数用于反调试。

我们在libshel​​la_2.10.3.1.so的段中偏移0x221C处设置一个断点，在该地址会调用反调试函数sub_CED4()。为了绕过反调试，我们将指令修改为00 00 A0 E1(mov r0，r0)。


此时，我们来看看libshel​​la_2.10.3.1.so的段。我们发现libshel​​la_2.10.3.1.so还有两个段。调用sub_CED4()之前的函数将libshel​​la_2.10.3.1.so中的数据从0x4000解密到0xCF68，并将解密的数据重新映射到具有RX模式的存储器段中。实际上，JNI_Onload的功能就在那段内存中。

接下来，我们在偏移0x99EC处的JNI_Onload()函数设置一个断点。它可以调用偏移0x9F44处的sub_4BDC()函数。执行sub_4BDC()函数后的Android日志如下所示。



如图所示，我们可以看到，在执行sub_4BDC()函数之后创建了一个新的代码段debug102。接下来，我们继续在libshel​​la_2.10.3.1.so偏移0xa0a8处设置断点。

在偏移0xA0C4处，它跳转到段debug102偏移0x590C处的函数。接下来，我们在段debug102偏移0x58AC处设置断点。在偏移0x58AC处，程序调用registerNatives函数来动态注册五种native方法：load，runCreate，changeEnv，reciver和txEntries。它们的偏移分别为0xcd51，0x8f5d，0x8b71，0x52b1，0x8a85。

然后，我们把重点放在native函数load上。它在段debug102中的偏移量为0xcd51。此函数用于解密隐藏在classes.dex中的数据，以获取真正DEX文件并加载它。以下是load的C代码。

在该函数中，Dalvik模式下调用sub_C1DC()函数。以下是sub_C1DC()函数的关键代码片段。

以下是关键代码段的说明。

1. 获取odex文件data@[email protected][email protected]的基址。
2. 通过DEX头中的data_size和data_off字段来获得真正DEX文件的偏移量。data_size为233944，data_off为38588。偏移量为0x43000(0x42894+0x1000)>>12)<<12。
3. 将新的DEX的DEX头数据复制到新分配的内存中。真正DEX文件的起始地址等于classes.dex的基地址加上0x43000和0x28。
4. 解密真正DEX文件的DEX头数据。

以下是解密函数sub_ F3D8()的C代码。

到目前为止，我们已经获得了DEX头的解密算法。以下是classes.dex(ODEX格式)中加密的DEX头数据。

解密后的DEX头如下所示。

真正DEX文件反编译得到的结构如下所示。

此时，我们就完成了native层的分析，并获得了恶意APP的真正DEX文件。
Package Name: net.gotsun.android.wifi_configuration
SHA256: 42e2e975edc9972c37bfc13742cd83e43eca3d708e5ea087a0a1fcaf63cbae09
原文地址：http://blog.fortinet.com/2017/07/06/unmasking-android-malware-a-deep-dive-into-a-new-rootnik-variant-part-i?noTracking