Oldboot.B：与Bootkit技术结合的木马隐藏手段的运用 | 少将全栈
  • 欢迎访问少将全栈，学会感恩，乐于付出，珍惜缘份，成就彼此、推荐使用最新版火狐浏览器和Chrome浏览器访问本网站。
  • 吐槽，投稿，删稿，交个朋友
  • 如果您觉得本站非常有看点，那么赶紧使用Ctrl+D 收藏少将全栈吧
> 点滴 > Oldboot.B：与Bootkit技术结合的木马隐藏手段的运用

Oldboot.B：与Bootkit技术结合的木马隐藏手段的运用

点滴 admin 11年前 (2014-05-29) 2583次浏览 已收录 扫描二维码

一个多月之前，我们在Android平台上发现了世界上第一个采用Bootkit技术的木马?Oldboot[1]（中文名：不死木马）。通过刷机等方式，Oldboot木马被植入手机ROM的BOOT分区中，在Android系统启动的早期阶段就得以运行，并进行一系列恶意行为。为此，我们在全球率先发布了Oldboot木马专杀工具，帮助用户检测和防御Oldboot木马。

近日，我们又截获了Oldboot木马家族的新变种?Oldboot.B，它与Oldboot.A一样采用Bootkit技术并静默安装APP。比较特别的是，Oldboot.B采用了一系列技术来对抗杀毒软件的查杀和病毒分析人员的分析，主要体现在代码加密、防卸载、注入系统进程、卸载或者禁用杀毒软件进程、隐写术（Steganography）等功能的加入。同时，Oldboot.B的隐蔽性得到了极大加强，采用了很多对抗技术有个别组件实现了“无进程”、“有进程无文件”等高级特性，详情请参考第二部分中的对抗与趋势分析，这些功能的具体实现请参考第一步部分中代码分析。Oldboot.B使用的这些技术，很多都是首次在Android平台上出现。无论是国内还是国外，在Android平台上的所有木马中，Oldboot木马家族使用的技术一直是领先的，Oldboot家族代表着Android平台的恶意软件的趋势。从分析结果中很容易就可以看出，Oldboot是一个组织严密、分工明确的庞大的木马家族，由专业的程序员编写，由商业公司来推动，并在不断的进化中，我们已经开发了新的专杀工具，可以有效地检测、清除和防御这个Bootkit。

一、 Oldboot.B代码分析

从目前来看，Oldboot家族木马的最显著行为是接收服务器发来的指令，未经用户许可，在后台静默下载并安装App，通过App的推广费用来盈利。当一台Android设备感染了Oldboot，用户会发现系统中经常出现一些自己没有安装过的软件和游戏。

这次发现的Oldboot家族新变种，与之前我们发现的imei_chk等文件（Oldboot.A），无论在代码上还是在功能上，都是紧密相联的。

image1

图 1 ：Oldboot.A 概貌

上图列出了Oldboot.A的相关文件，正如我们之前发布的分析报告[1]所说，imei_chk文件通过在init.rc中注册一个service实现开机自启动，它运行后马上释放另外两个木马文件GoogleKernel.apk和libgooglekernel.so，三者相互协作实现恶意行为，如果您想进一步了解他们的信息，请参考我们之前发布的分析报告[1]。

image2

图 2 : Oldboot.B概貌

上图描述了是我们近期发现的Oldboot木马的新变种，这些新变种的主要文件都是采用与Oldboot.A相同的方式实现自启动的，即：将自己写入initrd，并在init.rc中注册一个服务，然后通过刷机的方式刷入手机ROM的bootimg中。他们的功能也有相似性，比如都会持续监听socket，接收指令并执行。比较特别的是，新变种中的boot_tst文件会释放一个名为leecore.so的文件，它的一部分代码与Oldboot.A中的libgooglekernel.so文件是相同的。

这次发现的Oldboot木马的新变种，按照功能的独立性，可以粗略分为四个部分：

一、 以boot_tst为主的文件集合，远程注入Android系统的system_server进程，持续监听socket并执行发来的指令，相关的文件包括以下几个：

  1. /init.rc Android的引导配置文件，被Oldboot修改以实现自动启动
  2. /sbin/boot_tst 一个ELF格式的可执行文件
  3. /data/system/usagestats/leecore.so 一个ELF格式的动态链接库文件
  4. /data/system/usagestats/leejrc.so 一个ELF格式的动态链接库文件
  5. /data/system/usagestats/leejar.jar 一个Jar格式的模块

二、 以meta_chk文件为主的文件集合，联网更新配置文件，静默下载安装被推广的Android App，开启后门并执行远程指令，相关的文件包括以下几个：

  1. /init.rc Android的引导配置文件，被Oldboot修改以实现自动启动
  2. /sbin/meta_chk （v1 我们发现这个文件的两个版本）ELF格式的可执行文件
  3. /sbin/meta_chk （v2 我们发现这个文件的两个版本）ELF格式的可执行文件
  4. /sbin/adb_meta ELF格式的可执行文件
  5. /system/etc/.gprs.xml 具有隐藏属性的、加密的配置文件

三、 /sbin/adb_server文件，Android系统的pm文件被此文件替换，实现防卸载的功能。

四、 以agentsysline为主的文件集合，用C++编写，架构复杂，作为daemon一直在后台运行，接收指令，实现卸载杀毒软件、删除文件、启用或者禁用网络连接等功能，相关的文件包括以下几个：

  1. /init.rc Android的引导配置文件，被Oldboot修改以实现自动启动
  2. /sbin/agentsysline 一个ELF格式的可执行文件

(一) 以boot_tst为代表的部分

与Oldboot家族的其他木马类似，boot_tst的开机自启动功能是通过修改引导配置脚本init.rc来实现的，以下几行会被附加到init.rc文件的尾部：

image3

boot_tst运行后，行为逻辑大致如下图所示：

image4

图 3 ：boot_tst的执行流程示意图

如上图，整个执行流程是由boot_tst进程中的代码和注入到system_server进程中的代码这两部分来完成的，远程注入操作完成之后，两部分代码通过socket进行通信。

boot_tst进程中代码的运行流程基本如下：

    1. 释放内嵌的ELF文件为/data/system/usagestats/leecore.so，并加载，值得注意的是释放并加载SO文件之后，leecore.so会被删除，用户在文件系统里是看不到该文件的。
    2. 调用leecore.so的导出函数main
    3. 释放内嵌的ELF文件为/data/system/usagestats/leejrc.so
    4. 将/data/system/usagestats/leejrc.so注入到Android系统的system_server进程

image5

图 4 ：取得system_server的PID，并注入代码

image6

图 5 ：远程注入的代码

  1. 获取在init.rc中注册的socket?adb6?的端口号，持续监听这个端口，根据发来的指令执行相应的操作，并返回操作结果，代码实现如下图所示：

image7

图 6 ：监听socket并执行发来的指令

adb6这个socket接收的命令可以分为两大组，相关的数据结构如下图所示：

image8

图 7 ：指令分发数据结构

两组命令分别是：

  1. cmds 接收要执行的cmd命令数组，以root权限执行所有的命令。
  2. netcmd 接收system_server中leejar.jar模块发来的控制命令，实现打开、关闭网络，获取、释放wakelock等功能。

leecore.so 文件的代码是基于之前报告中Oldboot的libgooglekernel.so文件的，明显的变化是使用curl、cJSON等库来实现联网更新和配置文件的解析。

注入到system_server进程中的代码，是从leejrc.so文件的导出函数hook_thai_jrc_init开始执行的，主要流程如下：

    1. 释放内嵌的jar文件为/data/system/usagestats/leejar.jar
    2. 使用DexClassLoader将leejar.jar加载到system_server进程中
    3. 调用leejar.jar中的lee.main.main类的静态方法leeJrcInit

image9

图 8 ：使用DexClassLoader加载leejar.jar，并调用jar的方法

  1. leeJrcInit会创建一个socket server在本地监听9096端口，接收boot_tst发来的指令并执行，然后通过连接boot_tst监听的socket?adb6?返回指令的执行结果。

image10

图 9 ：leejar在system_server进程中创建一个socket server监听指令

image11

图 10 ：leejar连接boot_tst监听的socket server并写入指令

boot_tst进程通过socket向system_server中leejar创建的socket服务器发送如下指令：

  1. openNetwork
  2. closeNetwork
  3. getVerCode
  4. getCurNetworkType
  5. getAppInstallPath
  6. getSDCardAvaildSize
  7. getSystemAvaildSize
  8. isSafeMode
  9. unzip
  10. getSysInfo
  11. sendLauncherMsg
  12. acquireWakeLock
  13. releaseWakeLock

(二) 以meta_chk文件为代表的部分

meta_chk的自启动也是通过修改init.rc脚本实现的，两个版本的meta_chk的一个主要区别在于，一个在init.rc里注册一个名为adb2的socket，在代码里监听这个socket，另外一个在代码里创建一个socket服务器，监听本地的23332端口。

meta_chk的执行逻辑如下图所示：

image12

图 11 ： meta_chk的执行流程示意图

如上图，meta_chk的主要执行流程是这样的：

    1. 调用命令am startservice命令来启动UpdateNoService 服务。

image13

图 12 ：启动UpdateNoService

    1. 检测meta_chk的执行路径是否是/sbin/meta_chk，如果不是就不执行恶意功能。
    2. 删除/sbin/meta_chk文件，使得用户和杀毒软件根本没法读写这个文件，有效得避免了查杀，实现了Android上的“无文件木马”。meta_chk是位于ramdisk中的，删除这个文件并不会对木马的后续运行以及每次开机自启动造成任何影响，所以，这是增强木马隐蔽性的一个非常实用的技巧。

image14

图 13 ：检查运行时路径并删除自身文件

    1. 释放内嵌的一个ZIP文件为/system/lib/libkey.so，然后使用开源的MinZip库对这个ZIP文件进行解压，提取其中的axel文件，拷贝为/sbin/adb_meta文件，并为其增加可读可执行属性。/sbin/adb_meta(也就是axel)是类wget/curl的一个开源多线程下载工具(项目主页：http://axel.alioth.debian.org/)，被meta_chk用来从服务器下载文件。
    2. 加载配置文件/system/etc/.gprs.xml以便后续代码使用。/system/etc/.gprs.xml文件是一个加密的配置文件，目前我们发现的版本的文件大小是12508字节，其格式是自定义的，有着非常多的字段，开头以”AZD”为标志，存储的配置至少包含以下几个：a. 木马CC服务器的域名
      b. 要禁用的杀毒软件的包名
      c. 要推广的App的包名，和下载后在本地的保存路径
      d. 是否清除浏览器缓存
      e. 是否修改浏览器主页，和修改后的主页地址
      f. 要执行的命令列表
      g. 上一次恶意行为触发的时间
    3. 检测/system/etc/hosts文件内容，确定推广App时可能用的一些域名，比如zkl90.com、177.net、188.net等，是否被劫持，如果被劫持，则使用默认hosts文件的内容(127.0.0.1 localhost)覆盖掉hosts文件中的所有内容，保证后面的下载操作能够正常执行。
    4. 调用adb_meta（axel）工具下载病毒文件到/system/lib/libdowntemp.so，然后重命名为 /system/bin/chk，添加可执行属性后，运行/system/bin/chk文件。

image15

图 14 ：下载木马文件并执行

    1. 联网更新配置文件，覆盖本地保存的/system/etc/.gprs.xml文件。
    2. 下载APK文件，并静默安装。为了确保下载的App能够正常安装，meta_chk在执行静默安装操作之前，会调用pm disable关闭360手机卫士、腾讯手机管家、金山手机毒霸三款杀毒软件，安装完App之后，再调用pm enable启动他们，同时还会使用sqlite直接修改Android系统的“设置”应用的settings.db数据库文件，确保“未知来源”的应用是允许安装的。

image16

图 15：下载并安装APK

    1. 创建线程，在线程中监听socket并执行其他程序发来的指令。meta_chk可以接收的指令可以分为5种，其中opengprs和closegprs分别为打开和关闭手机的网络连接，setdb通过直接修改数据库文件来改变Android手机的“设置”应用里的各个选项，check?c=的作用是通过管道以root权限执行任意命令并返回命令的执行结果。

image17

图 16： 监听socket并执行相应的指令

有意思的是，meta_chk还会验证连接socket服务器的客户端App的RSA签名，只有当客户端App的签名文件的内容与meta_chk中硬编码的二进制数据一致时，才会执行其命令。有些杀毒软件或者专杀工具采用的是“以子之矛，攻子之盾”的方法，直接调用木马提供的功能来删除该木马，这种验证机制使其不再可行。

image18

图 17 ：meta_chk验证客户端的签名

(三) /sbin/adb_server文件

adb_sever文件替换了Android系统中的/system/bin/pm文件，主要对pm uninstall命令进行hook，如果发现卸载的App是其推广的App，不做卸载操作，并输出标志成功的字符串“Success”来欺骗用户，从而达到防卸载的效果。

adb_server也是存在于bootimg中的ramdisk中的，它没有通过init.rc来启动，而是由meta_chk拷贝并替换系统的pm文件，替换过程如下图所示：

image19

图 18 ： 使用adb_server替换系统的pm文件

当用户或者程序调用pm命令时，实际执行的文件是adb_server，adb_server启动后会进行一些必要的初始化，例如设置uid和gid为root，检查环境变量LD_LIBRARY_PATH，并检查父进程是否是shell进程。

image20

图 19 ： adb_server的初始化检查

然后，adb_server会检查子命令是否为uninstall，如果是，则取得命令参数，即要卸载的包名，与adb_server文件的内置包名列表中的包名进行一一比对，如果发现内置包名列表包含当前要卸载的包，则直接返回，并输出欺骗性的字符串“Success”。

image21

图 20 ： adb_server判断pm的子命令参数是否是uninstall，并输出欺骗性字符串“Success”

image22

图 21 ：检测要卸载的包名是否是要推广的App

(四) 以agentsysline为代表的部分

根据传入参数的不同，agentsysline可以作为一个类似于su的程序，以ROOT权限调用shell来执行各种指令，但是木马作者并没有完全实现这部分功能，不能正常使用，所以，agentsysline主要功能是，作为daemon服务在后台一直运行，接收远程服务器或者本地其他程序接收的指令，并执行。

agentsysline是使用C++语言编写的多线程应用程序，主要的功能模块都使用C++类进行封装，架构设计优良，虽然程序本身创建了多达15个线程，但是线程间同步等操作都处理的很好，从代码中就可以看出，木马作者是一个资深的Linux开发人员。

Agentsysline的主要功能封装在6个C++类中，分别是：

  1. Frame 单实例类，代表程序的运行时
  2. NetManager和TcpSession 实现网络连接功能
  3. SocketCmdManager 创建socket并收发数据，接收的指令传给CmdHandler执行
  4. CmdHandler 从SocketCmdManager接收指令，解析并创建新的线程执行这些指令
  5. Logger 单实例类，实现程序的日志功能

这几个C++类的大致关系如下图所示：

image23

图 22： agentsysline的行为逻辑示意图

agentsysline的主要运行流程是这样的：

  1. 初始化，设置resource limit和signal handler，并将自己的PID写入文件/data/system/sys.server.id。
  2. 调用SocketCmdManager创建socket server，初始化，并持续监听
  3. 调用NetManager连接网络，更新配置文件
  4. 除非singal handler接收到信号，将标志位bTerminate置1，否则一直无限循环此操作?调用SocketCmdManager接收指令并执行，支持的指令如上图所示。
  5. 如果接收到停止的信号，调用各个类的析构函数，退出。

整个运行流程的代码如下所示：

image24

图 23 ：agentsyline daemon运行流程的代码

二、 对抗与趋势

从之前发现的Oldboot样本相比，本次发现Oldboot木马家族的新变种在很多方面都发生了改变，尤其是，与杀毒软件的对抗、与病毒分析工程师的对抗、与自动化分析工具的对抗，这三个方面的变化尤为显著，主要体现在以下几个方面：

    1. Oldboot木马的隐蔽性得到极大加强。一方面，meta_chk进程在启动后，会删除自己在文件系统中的文件，只保留进程，目前流行的Android杀毒软件都不支持进程内存扫描，当然也不能发现或者删除驻留在内存中的Oldboot木马；另一方面，boot_tst文件使用远程代码注入技术，将一个so文件和一个jar文件注入到system_server进程，这种注入技术在Android平台上是比较成熟的。我们可以预期，Oldboot木马作者肯定会将这两种技术串联起来，真正实现一个“无进程、无文件”的木马，也许现在已经存在这种木马，只是我们还没有发现而已。
    2. Oldboot木马ELF文件的代码不再一目了然，而是经过了加密，运行时先解密再执行，同时，程序使用的字符串几乎都经过了加密，配置文件也被加密，这些Anti-disassembly技术的大量使用，阻碍了病毒分析工程师的分析进程，大大增加了分析所需要的时间。
    3. Oldboot木马采用一些措施，比如增加一些无意义的代码，随机触发某些行为等，来对抗动态分析。
    4. Oldboot木马在运行时会检查一些环境属性，比如meta_chk会检测执行的路径，如果不是预期的路径，就拒绝执行，同时还会检测SIM卡的信息，如果没有SIM卡，也不会执行某些行为。这些运行时检查， 会使得某些sandbox或者emulator监测不到恶意行为，从而造成误报。
    5. Oldboot木马会检测杀毒软件是否存在，进行恶意行为之前，或者卸载杀毒软件，或者先停止杀毒软件然后再启动，后一种方式更为隐蔽，使得用户毫无察觉。比较特别的是，agentsysline这个木马的作者有可能考虑到360是中国最大的安全公司、360手机卫士是中国市场占有率最大的手机安全软件，所以，在代码中只增加了卸载360手机卫士的代码，这对360的安全工程师来说是一个巨大的挑战。

image25

图 24 ：agentsysline中卸载360手机卫士并停止手机卫士的rpc server

    1. Oldboot木马使用隐写术（Steganography）等技术来隐藏自己。隐写术（Steganography）是一种强大的信息隐藏技术，曾经在美国的911恐怖袭击事件中充当联络员的角色。我们发现，meta_chk联网更新下载的文件，从外表来看，是一张图片，后来经过一番分析才发现，这张图片中隐藏了木马的配置文件，里面包含了木马会执行的命令等信息。

image26

图 25 ： 隐藏在图片中的木马配置文件

  1. Oldboot木马的架构设计比较复杂，有着很高的灵活度，很多行为都是可以配置的，都是可以从木马CC服务器控制的，有时候，这种控制可以做到非常细的粒度，能够做到的事情有很多，meta_chk的配置文件可以很明显的证明这一点，这个配置文件的大小是12508字节，几乎每个字节都有不同含义。完全分析这种远程控制类木马，本身就是一件比较困难的事情，因为木马CC服务器下发的指令不同，木马触发的行为也有区别。

三、 关联分析

meta_chk会连接的一个域名是az.o65.org（已失效），通过360搜索，对这个域名进行简单的搜索可以发现，其IP为61.160.248.67，这个IP的服务器上存在多个类似的域名，通过搜索引擎的缓存，我们发现他们的标题都是“ZKL90”，因此可以基本确定这些域名都是meta_chk的服务器。 一个单独的组件?meta_chk?拥有这么多的域名，这是需要相当多的人力和财力才能做到的，Oldboot木马背后的制作团队的规模可见一斑。

image27

图 26 ： meta_chk服务器az.o65.org的首页缓存以及域名列表

四、 解决方案

目前，我们已经独家发布了全球首个Oldboot专杀工具，下载地址是：

http://msoftdl.360.cn/mobilesafe/shouji360/360safesis/OldbootKiller_v2.apk

该专杀工具可以对Android设备进行深度地精确扫描，判断其中是否存在Oldboot及其变种。我们在其中开发了全新的查杀技术，能够有效的保护您的手机免受不死木马的侵害。

如果目前暂不支持您的设备或者专杀工具在您的手机上无法正常工作，我们的建议您：

  1. 定期检查该专杀工具的更新，我们将逐步增强专杀工具的防御能力；
  2. 在专杀工具检测到Oldboot后，将的机型信息和样本上报给我们，可以帮助我们更快更好地开发出适合您的机型的查杀代码；
  3. 加入我们的Oldboot技术支持QQ群，向我们反馈更多的信息，并获得我们应急响应工程师的技术指导；
  4. 您可以将手机重新刷写为设备厂商官方提供的系统ROM，彻底刷机后，Oldboot应该已经被清除了；
  5. 由于只有系统被经过篡改的手机设备才会感染Oldboot，如果使用我们专杀工具检测到Oldboot，您也可以直接联系手机的经销商，协商售后事宜。
  6. 安装360手机安全卫士，开启云查杀功能，抵御Oldboot带来的关联威胁。

五、 讨论

作为Android平台的第一个Bootkit，Oldboot具有标志性的意义，在杀毒软件与木马的攻防战争中，它开拓了一个新的战场，开启了一个新的时代。

智能手机之所以兴起，其中一个很大原因是高速网络的普及，Android手机作为市场占有量最大的智能手机，时刻与网络保持互联是其基本特征，Android木马作者看到这一趋势，越来越倾向于将很多信息保存在网络上，投放到用户手机上的App或者ELF文件，只提供基本的功能，比如联网更新配置，比如以ROOT权限执行任何命令等等，真正做的事情，都是由木马的CC服务器来控制的，Oldboot木马家族正是这一趋势的显著代表。

从目前的发现来看，Oldboot主要被用来静默安装并推广App，它具有高度灵活的可配置性，这一点可以从以下几个方面看出，首先，配置文件所在域名和服务器非常多，并且经常更换，以保证一直畅通，使得Oldboot木马总是可以得到最近的更新，以满足推广的需求或者应对杀毒软件的查杀；其次，配置文件极其复杂，比如下载的App的链接、下载后保存的路径和包名等等都是可以配置的；再次，Oldboot木马考虑到了多种意外情况，比如服务器地址被hosts文件劫持，比如杀毒软件的主动防御等等，比如被卸载。而且，Oldboot采用了Bootkit技术，将基础功能模块直接刷入Android手机ROM的bootimg中，在Android操作系统启动时即作为Native service启动，这种方式使得Oldboot木马在预装软件中做到了最底层。综合以上几点，可以说，在恶意推广App的这一功能上，Oldboot家族木马做到了极致。

Oldboot木马的本质特征在是世界上第一个采用Bootkit技术，并具有远程控制的功能，根据服务器的指令的不同，随时可以衍生其它行为，变身为其它类木马，比如构造虚假短信进行广告推广或者钓鱼攻击等等。在利益的驱动下，Oldboot家族木马的演进速度非常快，不停的调整自己以应对各种情况，我们将继续紧密关注其最新发展并提供安全保护方案。

六、 参考文献

  1. Oldboot: Android平台上的第一个bootkit by 肖梓航，董清，张昊，蒋旭宪
    http://blogs.360.cn/360mobile/2014/01/18/oldboot-the-first-bootkit-on-android_cn/

转http://blogs.360.cn/360mobile/2014/03/28/analysis_of_oldboot_b/

喜欢 (0)赏
[🍬谢谢你请我吃糖果🍬🍬～]
分享 (0)
关于作者：
少将，关注Web全栈开发、项目管理，持续不断的学习、努力成为一个更棒的开发，做最好的自己，让世界因你不同。
作者主页 赞助作者