最近一直在研究国企，更多的是银行相关的应用，发现几乎所有的应用都引入了ROOT检测机制，通过数次逆向分析ROOT检测的实现和尝试绕过检测机制，也发现了不少的乐趣。除此之外呢，由于疫情昨日接到防疫办的电话，通知居家隔离14天，也正因为这一突发情况让我暂时无法静下心来工作。今天也趁着时间比较富裕，分享一篇小文来打发下时间。

关于安卓手机的ROOT，相信大部分人都不会陌生。在手机没有ROOT之前，我们只能作为一个使用者来用这个手机，需要在系统的约束下进行程序的安装和部分功能的使用。而ROOT之后的设备，对于我们来说有大有可为了，相当于我们可以获取最高的用户权限，从而卸载系统应用、定制化UI等各种骚操作便有了实现的可能。当然，ROOT之后的手机对于应用和用户来说都是极其危险的。

在前面提到了，ROOT之后的手机对于应用和用户来说都非常危险。那么ROOT检测的意义便是保护应用和用户，以免因为手机被ROOT而受到危害。我们可以猜测一下ROOT手机的原因，总的来说可以分为三类：个性化、安全研究、攻击行为。设想一下，为了追求个性化而去ROOT手机万一操作不慎删除一些关键文件或者卸载了一些必要的应用，很可能会导致系统不可用，造成不可挽回的损失。而对于安全研究来说，由于该需求的特殊性暂不考虑其危害性，毕竟研究的目的就是为了保障安全嘛。至于攻击行为，这一类别的名字已经告诉了我们有多么的危险。由于ROOT之后的手机允许获取最高用户权限，那么攻击者可以将目标应用运行在ROOT之后的手机上，从而可以越权访问应用的私有数据；除此之外，目前主流的Hook框架如frida、xposed等在ROOT手机上更是如鱼得水。ROOT检测存在的意义便是及时的发现应用所运行的环境是一个被ROOT后的手机、是一个不安全的运行环境，为了保障应用的安全运行，保护数据不被窃取、篡改，从而采取一系列的防护措施。

通过对部分应用的ROOT检测机制进行逆向分析，以及查阅相关资料发现一些事情。各应用ROOT检测机制没有相对统一的标准，具体表现在检查内容、处置方式等方面，下面是我整理的一些常用的检测方法：
1、检查常用目录是否存在su
2、使用which命令查看是否存在su
3、主动申请root权限
4、执行busybox
5、访问私有目录，如/data目录，查看读写权限
6、读取build.prop中关键属性，如ro.build.tags和ro.build.type
7、检查市面主流的模拟器
8、检测frida、xposed等Hook框架的特征
上面便是我整理的各种应用主流的检测方法，目前看来绝大多数的应用都是对上面几个检测方法组合使用，甚至有很多只会实现其中的一项或者两项。另外，上面的方法也没有囊括所有的可能，比如有些应用还会检测“面具”或者Superuser.apk等是否存在来进行ROOT检测。总结来说，目前主流的ROOT检测就是对ROOT之后的手机独有的一些特征进行验证，如特征文件是否存在、是否存在越权、关键属性是否被修改等等。

检测到手机被ROOT之后如何处置也是一个重要的问题，目前看来主要有两种处置手段：其一是发现即摧毁，顾名思义就是检测到ROOT设备之后不允许应用正常运行；另外一种则是允许应用运行，但是切换与后台服务器的交互。接下来，咱们对这两种处置手段进行简单的比较：
1、第一种处置，检测到ROOT设备之后如何停止应用的运行？根据工信部的监管要求还不能直接让应用直接退出，因此现在一般的做法就是通过弹窗、Toast等以文字描述提示用户当前手机被root了存在风险，由用户决定是否退出或者延时几秒后退出。我们可以看出这种处置是将用户体验放在了一个相对重要的位置，但是这同时也给攻击者带来了诸多便利。友好的文案提示方面攻击者确认是触发了环境检测机制，从而专心绕过。不立即停止应用的运行，留给攻击者足够的时间去进行分析和注入，从而绕过应用的ROOT检测机制。
2、对第二种处置，对于攻击者来说无法直接定位到业务失败的原因，可能需要通过抓包分析，甚至自己猜测来定位，在一定程度上提高了攻击者的攻击成本和难度。但是这种处置也可能会误杀一部分为了个性化而将手机ROOT的正常用户，为了减少误杀率，现在的应用也会进行一些特殊的处置。

前面扯了一堆，后面的内容算是开始步入正题。无论我们是从事安全研究还是作为攻击者，也无论应用对检测到的ROOT设备是如何处置的，ROOT检测机制的存在都会对我们造成一些阻碍。因此，绕过应用的ROOT检测是一个必要的事情，也是我们工作中经常要遇到的。那么，如何绕过ROOT检测机制呢？这里提供两个思路，其一是对应用下手，干预应用的ROOT检测行为；另外一个思路则是对系统下手，隐藏系统自身ROOT相关的特征。我们可以借助jadx等逆向工具对应用源码进行分析，Hook相关的实现函数绕过；也可以获取AOSP源码，通过定制ROM来隐藏ROOT的特征。

目前主流的Hook框架有frida和xposed，本人比较倾向于前者，我们也可以用frida的可见框架RMS进行注入。相对来说，通过Hook的方式来绕过ROOT检测机制操作比较简单、方便，但Hook本身会受到很多的约束。一方面，受限于应用自身的加固手段，可能难以定位ROOT检测的实现函数；另一方面，Hook框架自身也会具备一些易于被检测到的特征，可能会受到这些特征的约束而难以完成工作。

定制ROM的手段有很多种，可以通过对官方包进行解包、修改后重打包。我推荐的方式是获取AOSP源码，自己编译后制作ROM包。这样可以实现更高程度的定制化，与基于现有包修改的方式相比该方式的操作空间更大，但是同样的它会带来更好的编译成本、修改难度也更大。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！