关于Android系统root的那些事儿

Android的内核是Linux，而root作为Linux系统中最高权限的管理员账户，在Android也一直都是兵家所必争的战略要地。

下面我们来回顾一下Android系统root的前世今生，然后分析各种root检测方案及其对抗思路或弊端。手机在root后会使许多安全措施失效，所以一般不建议个人对手机进行root。

一

root的前世今生

1、远古时代的root方式

在Android 6.0之前，市面上的root工具处于百花齐放百家争鸣的状态。当时市面上有各种“一键root”软件，其核心步骤较为相似，具体如下（上述应用还有root权限管理的作用，非本期重点关注内容不做展开）：

1）把su放到系统路径里面；

2）让这个su文件可以被执行；

3）执行su文件。

这个问题的实现上还有问题需要解决，尤其是前两步较为困难，如下：

第一步：系统路径一般是指/system/bin目录，该目录所在的system分区是只读的，想要push su到此目录，需要重新挂载system分区。然而重新挂载需要root权限。

第二步：让su文件可被执行，更确切的说，是需要让su可以被普通用户以root权限执行。万幸在Linux内核的权限管理中有一个权限标志位s（SUID，Set UID）可以让任何一个用户以文件所有者的权限运行。所以需要做的就是把su文件权限位改为rws，并将其所有者改为root用户。很可惜这两个行为也需要root权限。

我们现在就已经死锁了：获取root权限需要在系统目录里放一个具有rws权限且所有者改为root用户的su文件，但这个过程需要root权限才能完成。

不过这个问题在Android 6.0之前的时代并非无解，当时的大部分手机存在提权bug可以完成上述root过程。然而，Android 4.2时代更新使su变为了C/S架构，需要通过native service拉起su daemon之类的服务进程才能正常使用root进程；在Android 5.x时代，谷歌更新增加了SELinux访问控制策略，都让上述过程的实现越来越困难；也正是同一时期，谷歌与各大手机厂商先后修复了许多被广泛用来root的bug；于是“一键root”的时代就此落下帷幕。

2、刷recovery的root方式

“一键root”时代过去之后，黑灰产和部分发烧友对root的需求仍然旺盛。简单的root方案难以实现后，利用Android的recovery机制进行root的方式逐渐展露优势。

recovery模式是Android启动时可能会进入的三种工作模式之一（另外两种是main system和fastboot），本质上是一套精简版的系统。在recovery模式下可以刷入新的Android系统、对原有系统进行备份或升级、或者格式化数据和缓存（即恢复出厂设置）。一般手机厂商出于安全等各方面考虑，提供的recovery系统只具有基本的重置系统、升级系统功能。为了能利用recovery的高权限进行更多操作，就需要刷入具有更强大功能的第三方recovery系统。

刷recovery的root方式核心思路如下：

1）刷入三方recovery覆盖原生recovery；

2）使用三方recovery刷入带有root功能的补丁。

这个思路最大的困难在于第一步：recovery作为可以更新修改rom的高权限模块，不可能没有保护随随便便就可以刷入修改，我们要想刷入自己的定制recovery，就得让这样的保护机制失效，即解BL锁（或称解锁BootLoader）。                                          

图：高通架构Android手机的启动流程

我们以高通为例来看一下Android的启动过程（联发科启动过程类似）：其中PBL（Primary BootLoader）是写死在芯片上的，主要功能是上电自检，然后验证并加载XBL（eXtensible BootLoader）；XBL为高通新的解决方案，以前为SBL（Secondary BootLoader），主要功能是初始化一些硬件环境，然后验证并加载ABL（Android BootLoader）；ABL主要功能就是从设备验证并加载boot.img来启动Linux Kernel，进而启动操作系统。

可以看到上述的每一环节都会验证并加载下一环节的，这也是secure boot规范要求，此处的验证就是验证签名。在这个启动链条上任何一个环节（除了PBL）被修改都会导致其前一个模块验证失败，被修改的环节就不会被加载执行；而作为第一个环节的PBL的安全性是依靠硬件实现的。所以我们要想刷入自己的recovery就需要关闭这个验证体系，也就是所说的解BL锁。只有少数手机厂商仍然提供解BL锁服务，但需要向官方提出申请，大多数手机厂商已经不支持解BL锁。

假设我们现在已经搞定了BL锁，接下来我们还得定制一个与机型相匹配的recovery，市面上现有几种第三方recovery定制工具，但都更新缓慢或适配的机型不多，这也提高了手机root的难度和成本。

成功刷入定制recovery后，我们便可借助recovery刷入root工具来获取root权限。

二

root检测

一旦手机已经root，其运行环境的安全性就会大大降低，所以对于应用软件来说，检测环境是否已经root非常重要。

1、应用层root检测

1）检测系统版本

检测思路：对于可以官方解锁BootLoader的厂商，一般会发布专门的测试版本系统，而这样的测试版本系统在正式发布中是不会出现的，只能专门刷机。所以可以检测系统版本，该信息存储与/system/build.prop文件中，也可以直接在代码中查看系统属性android.os.Build.TAGS。

可能的绕过方式或者弊端：

• 攻击者可不用官方途径解锁bootloader刷机root；

• 攻击者可能使用未知漏洞等获取root权限，且在没使用或没开启dm-verity的系统中root之后修改该版本标识。

2）检测是否有root权限管理应用

检测思路：通常root之后手机并不会任由root权限被随意使用，而会使用root权限管理应用。所以可以检测手机上是否存在这种常见的root权限管理应用来作为手机是否root的标准之一。具体可以检测对应应用的包名或进程名等。

可能的绕过方式或者弊端：

• 攻击者可能不使用常见管理软件或不使用管理软件；

• 攻击者可不授予root检测应用获取本机安装应用信息的权限，使得检测应用获取不到管理软件信息。

3）检测是否存在su文件

检测思路：检测系统路径中是否存在su文件，也可以尝试执行su以获取root权限，如果存在su文件或直接可以执行以获得root权限，则说明系统有极大可能已经root。

可能的绕过方式或者弊端：

• 攻击者可将su隐藏在某个特殊目录下

• 攻击者可改名或者隐藏su使检测应用无法执行su命令  

2、系统层root检测

由于系统安全性要求，应用层权限不高，可选检测方式也相对较少。想要获得更为精确的检测结果就需要更底层的检测，也就是系统层检测。

1）校验只读分区是否被可写挂载过

检测思路：有时攻击者root之后会对常规的只读分区重新进行可写挂载，然后进行下一步行动或修改后取消root，此时我们就可以检测这些只读分区是否被可写的挂载过。

弊端：判断基于用来记录的变量的可靠性，同时攻击者可能不对原只读分区进行重新挂载而是使用增加或挂载虚拟分区等手段绕过。

2）查看关键安全机制状态

检测思路：校验secure boot及avb是否正常，校验SELinux状态。现在通常的root方式需要关闭上述机制，所以如果检测到上述机制存在已关闭的则增加了系统已经被root的概率。

弊端：有时测试者或开发者也会关闭一些安全机制，存在一定误判概率。

在Android刚刚出现之时，各种“一键root”工具充斥在市面上，人人都可以3分钟root自己的手机。大家root手机的原因也千奇百怪：卸载预装软件、UI不好看或想换字体、想用某个大神做的黑科技等等，甚至许多人还没理解什么是root就已经root了手机。然而随着手机厂商持续优化，预装软件的减少、root门槛的提高、UI界面的美化，正常用户的需求逐渐得到很好地满足，同时大家也逐渐了解到root对Android的安全性有很大损伤，现如今仍然坚持root的用户已经不多。

对于黑灰产来说，root之后获得的极高权限可以让其绕过或修改许多正常的逻辑以获得灰色收益，这导致黑灰产行业仍在不断寻找着更稳定、更隐蔽的root方式，因此我们仍需要重视对手机是否root的检测。

root检测是个不断攻防对抗的过程，本文仅是初探。希望本篇能够为大家稍解root之惑，如果大家有什么其他好的检测思路也欢迎在下方留言。

• 注：Android启动部分参考文章

  https://lineageos.org/engineering/Qualcomm-Firmware/

精彩文章推荐