深度分析使用高级反调试和反hook的Android Rootnik Malware，Part II：分析JAVA层 Secer's Blog

接上篇：深度分析使用高级反调试和反hook的Android Rootnik Malware，Part I：在Native层调试

原作者：Kai Lu

译者：BlackTrace

原文链接

在Part I中，我们分析了native层和获得了解密后的第二个dex文件，在PartⅡ中我们将继续分析它。为了保持文章的连续性，我们将继续保持从part I中的章节序号。

IV. 第二个dex文件

下图是解密后的文件，它是jar文件格式。这个就是通过multidex方案动态加载的第二个dex文件

图25. 解密后的第二个apk文件包含dex文件

解压"decrypt.dump",你会看见名为"classes.dex"的文件在这个文件夹里。

图26. 名为classes.dex

接下来，我们分析这个classes.dex

图27. 反编译第二个dex文件和AndroidManifest.xml文件

从上图，我们可以看出classes.dex是名为“file Helper”的恶意app的主要逻辑。

下图是com.sd.clip.activity. FileManagerActivity类里的"OnCreate"方法

图28. FileManagerActivity类里的OnCreate方法

图29. initadv()方法

图30. Nws类

在Nws类中的getStart方法是用来开启com.hg.mer.PG服务。下图是类PG的定义

图31. service com.hg.mer.PG类

在startService()方法被调用后，OnCreate方法被调用，紧接着是调用OnHandleIntent()方法。在上图中，我们用红色标记了4行关键代码，我们接下来依次分析这4行关键代码。

1. readDex()

下图是readDex()方法的代码片段

图32. readDex()方法

基于我的分析，类Sheu是base64的实现类，因此Sheu.decode("S0suYmlu")的结果是字符串“KK.bin”。接着，程序打开在程序的assets文件夹里的KK.bin，并且读取它的内容，提取一些有用的信息。

下面是KK.bin的文件内容

图33. assets文件夹里的KK.bin文件

这个程序从KK.bin文件的结尾提取了一下信息。有7个使用base64编码的字符串存储在数组列表中。这里的getAppid()方法就是用来解码这些字符串的。

图34. 解码字符串

这7个字符串解码后的结果如下

Pls.Kbin: wddex.jar

Pls.OI: xdt

Pls.PL: com.svq.cvo.Rtow

Pls.Jr: getDex

Pls.Wv: sgdex

Pls.As: dos.jar

Pls.NQ: KK.bin

2.dxfile()

下面是dxfile()方法的代码片段

图35. dxfile()方法

图36. UnZipFolder()方法

方法 Pls.UnZipFolder()提取来自KK.bin的加密内容。这部分加密内容开始于KK.bin文件偏移0x20到偏移0x1CDB，这部分内容被保存到/data/data/com.web.sdfile/files/wddex.jar。这部分内容是使用DES算法加密的。

这个程序在dxfile()解密/data/data/com.web.sdfile/files/wddex.jar文件的内容到/data/data/com.web.sdfile/app_sgdex/dos.jar文件。

3.DexClassLoader()

这个方法的构造如下

在这个方法的调用，形参dexPath的值是“/data/data/com.web.sdfile/app_sgdex/dos.jar”，形参optimizedDirectory 的值是“/data/data/com.web.sdfile/app_xdt”。

这个方法是用来从.jar和.apk类型的文件内部加载classes.dex文件。通过这种方式可以用来执行非安装的程序代码，作为程序的一部分进行运行。优化后的dex文件写入文件夹 data/data/com.web.sdfile/app_xdt中的dos.dex。

在从/data/data/com.web.sdfile/app_sgdex/dos.jar加载完之后，这个程序将删除这个文件。

4.动态调用类com.svq.cvo.Rtow的getDex()方法

接下来，让我们检查一下dos.dex

图37. 反编译dos.dex

下图是类class com.svq.cvo.Rtow的getDex方法：

图38. 类class com.svq.cvo.Rtow的getDex方法

图39. 类Dwol的结构

在类com.kdw.xoa.Dwol的结构中，有一个新文件mda.ico被创建到/data/data/com.web.sdfile/files/文件夹中。这里，它是调用downloadFile方法去远程服务器[http://gt[.]rogsob[.]com/stmp/ad.png]()下载payload，并把payload保存到/data/data/com.web.sdfile/files/mda.ico。这个payload使用的是DES算法加密。

图40. downloadFile方法

图41. initData()方法

下面是silentInstall方法的定义。

图42. silentInstall方法

上图中的5处红色的标记解释依次如下。

a. 类Dwol的方法dxfile是被用来解密/data/data/com.web.sdfile/files/mda.ico这个payload的。这个解密后的payload保存到了/data/data/com.web.sdfile/app_snex/dkt.jar。

b. 类Ngss的upZipFile方法是被用来解压解密后的payload dkt.jar到 /data/data/com.web.sdfile/files/ 文件夹中。它包含以下文件：

图43.payload的文件

c. 解压完后，它会删除 /data/data/com.web.sdfile/app_snex/dkt.jar 和 /data/data/com.web.sdfile/files/mda.ico 这两个文件和 /data/data/com.web.sdfile/app_snex/ 这个目录。

d. 重命名 /data/data/com.web.sdfile/files/ 文件夹里的 classes.dex 为wsh.jar。

e. 动态加载/data/data/com.web.sdfile/files/wsh.jar里的classes，并且优化app_outdex 目录，存储这个dex缓存文件到wsh.dex。

f. 调用类 com.rootdex.MainActivity 类的getDex方法。

接下来，我们深入的看看这个wsh.dex，它主要运行root工具去root设备并且安装应用到系统app文件夹里。

图44. 反编译wsh.dex

下面是类com.rootdex.MainActivity的getDex方法的定义。

图45. 类com.rootdex.MainActivity的getDex方法

a. 方法GetActivie是用来收集设备信息并把这些信息发送到远程服务器上。远程服务器的URL是[http://grs[.]gowdsy[.]com:8092/active.do]()。下面是这个操作的捕获的包：

图46. 发送收集的信息到远程服务器

b. 检查一下文件是否存在于 /data/data/com.web.sdfile/files/ 文件夹里，并把他们的文件名字加到数组列表中，用来准备下一步的ruut设备。

c. 在这个设备上运行root工具。

接下来，在run()方法里的HandleRoot()方法被调用。图47. HandleRoot()方法。

下面是copyRootFile方法的关键代码片段。

图48. copyRootFile方法

在这个方法里，有4个步骤。

FileUtil.dxfile() 用来解密 /data/data/com.web.sdfile/files/png.ico 文件并保存它到/data/data/com.web.sdfile/app_dex/.do。
FileUtil.UnZip() 是用来解压 /data/data/com.web.sdfile/app_dex/.do 这个文件到 /data/data/com.web.sdfile/.rtt 文件夹，这个文件夹是系统隐藏文件夹，解压到里面的文件包含6个ELF运行文件，详细如下图。它包含了r1,r2,r3,r4,4个root exploit。
它删除解密后的root工具 /data/data/com.web.sdfile/app_dex/.do 和 /data/data/com.web.sdfile/app_dex/ 文件夹。
它会在/data/data/com.web.sdfile/files/ 文件夹里创建一个名为psneuter.js的新文件。它的内容如下。

图50. psneuter.js文件

在executeRootAct方法里handOrimiddle被调用。下面是4个通过命令行运行root exploits的4个代码片段：

图51. 通过shell命令行运行root exploits

研究这些可执行文件后，我发现r3是来自dashi root工具中的MTK root方案，r4是来自开源项目android-rooting-tools中的一个exploit(CVE-2013-6282),r2是CVE-2012-6422，这个exploit是Samsung Exynos上的root exploit。

handleOriMiddles方法是通过shell命令行运行root exploit和一些命令。所有的shell命令如下： .png)

图52. root设备时执行的所有命令

成功得到root权限后，这个名为psneuter.js的脚本在超级用户权限下运行。这个脚本的主要目的是在/system/priv-app/ 文件夹下安装root权限的应用。

之后我们将研究两个新的apk文件。为了避免被普通用户捕获，这个两个app在受害者的设备上安装后是没有图标的。

此外，还有其他的一个名为 rsh的脚本通过shell命令行运行

图53. 通过shell命令行运行rsh脚本

这个rsh脚本是不同的，它是基于Build.MANUFACTURER属性的。这个脚本内容如下：

图 54. rsh(1)脚本

图55. rsh(2)脚本

BSetting.apk 是如何工作的。

如图50所示，abc.apk是放在 /system/priv-app/ 并重命名为 BSetting.apk 并且 BSetting.apk 是通过pm安装的。

BSetting.apk服务是远程控制服务，它从远程服务器获取任务并运行任务。

这个app是运行在后台的并且在设备上没有图片，下面是这个app的信息

图55 BSetting.apk的信息

这个app伪装它自己为Android sync service。反编译这个apk的文件结构如下图：

图56. 反编译abc.apk

图57. abc.apk里面的AndroidMainfest.xml

BroadcastReceiver com.sfy.oyr.R 执行这个app的主要逻辑。

图58 类R

这个程序首先解密assets文件夹里的jif.png。这个文件是一个dex文件。然后这个程序使用java的反射机制加载类并运行一些方法。

我们反编译这个解密后的dex文件，如下图所示：

图59 反编译classes.dex

类ADService的launchTancTask 方法是用来从远程服务器上获取任务和执行任务。

图60. 从远程服务器上获取任务

下图是从远程服务器获取任务的包，这个远程服务器又两个域名，一个是主域名 grs[.]gowdsy[.]com，还有一个备用域名 grs[.]rogsob[.]com。从远程服务器上返回的响应信息是xml文件，这个文件的任务类型包含了用来推送色情信息的url，用来下载apk的url和app安装类型等。

图61. 从远程服务器获取任务的包

根据不同的任务类型，app在不同的方式下运行任务，下面是关键代码片段：

图62 根据不同的任务类型运行任务

远程控制服务能够执行多个恶意行为，包括但不只是下面的行为： 1. Uninstall app 它使用android系统的“pm uninstall”卸载app

图63 通过shell命令行运行pm unintall来卸载app

推送色情（Push porn）下面是以是一些推送色情的截图.

图64 app推送色情到设备上

在主屏幕上创建快捷方式

创建的快捷方式包括色情，hot app，hot video等。下面是一些创建快捷方式的关键代码和一些屏幕截图。

图65 创建主屏幕上的代码片段

图65 主屏幕的快捷方式

App和广告的推广

除了获取设备的root权限外，这个app通过推广app和广告为这个app的创建者产生收入。推广的app和广告是特别让用户厌烦的。

下面是一些app推广屏幕截图：

图67. App和广告的推广

正常安装app和静默安装app

这个恶意app根据获取的任务类型来使用不同的方式安装app。下面是正常通安装app的代码片段，这种方式在安装时，是有安装视图的。图68. 正常安装app

这个app使用android系统的"pm install -r"功能来静默安装非系统app到/system/priv-app/ 成为系统app。

图69 静默安装非系统app

在/data/app/文件夹里我们找到了一些安装完成了的apk文件(包括，但不只是以下这些)。图70 在文件夹/data/app/里的被恶意安装的apps

图71. 命令安装系统app

在/system/priv-app/ 文件夹里，我们也找到了安装完成了的一些apk文件(包括，但不只是一下这些)

图72 在文件夹/system/priv-app/ 里的被恶意安装的apps

推送通知

这个恶意app会推送通知并诱导用户在点击它在浏览器里打开这个URL。

下面是推送通知的代码片段。

图73. 推送通知的代码片段

图74.被恶意app推送的通知

下载文件我们找到了被下载到/sdcard/文件夹下的很多文件和文件夹。这些文件有apk文件、jar文件、图片、日志文件等。这些文件是安装app生成的，其中的一些是执行恶意行为。

图75.下载到/sdcard/文件夹下的文件和文件夹

解决方案

恶意样本被Fortinet Antivirus检测签名为Android/Rootnik.PAC!tr。

通信交流的远程C2服务被Fortinet IPS检测并签名为 Android.Rootnik.Malware.C2.

总结

通过前面的分析，我们能看出，这个rootnik恶意app是非常强的并使用非常高级的反调试和反hook技术来防止被逆向工程，不同类型的文件和字符串加密。除此之外，它还使用了multidex 方案来动态加载和安装第二个拥有恶意的主逻辑的dex文件。这个恶意app使用一些开源的android root exploit工具和dashi root工具里的MTK root方案在Android设备上获取root权限。在设备上成功获取root权限后，rootnik malware 能执行多样的恶意操作，这些操作包括app和广告的推送、推送色情（pushing porn）、在主屏幕上创建快捷方式、静默安装app和推送通知等。

附录

## Rootnik Malware样本
# Package Name: com.web.sdfile
SHA256: E5E22B357893BC15A50DC35B702DD5FCDFEAFC6FFEC7DAA0D313C724D72EC854

Additional APK files dropped into system partition by Rootnik malware
# Package Name: com.br.srd
SHA256: E2BDCFE5796CD377D41F3DA3838865AB062EA7AF9E1E4424B1E34EB084ABEC4A
# Package Name: com.oyws.pdu
SHA256: CEE6584CD2E01FAB5F075F94AF2A0CE024ED5E4F2D52E3DC39F7655C736A7232

# C&C Server
gt[.]rogsob[.]com

grs[.]gowdsy[.]com:

qj[.]hoyebs[.]com

qj[.]hoyow[.]com

gt[.]yepodjr[.]com

翻译，难免会有错误，还请指正。万分感谢.我的bolg地址：www.kejidi.net --BlackTrace