文章总结： 本文针对AOSP源码定制中root检测绕过问题提出补充方案。通过分析系统启动时加载prop文件的流程，在loadpropertiesfrom_file函数中插入属性替换逻辑，实现动态修改ro.vendor.build等特征值。同时针对adb权限问题，提出在保持ro.debuggable=0的前提下修改adb.c源码中降权判断逻辑，使adb直接获取root权限。该方法可系统化抹除定制痕迹。 综合评分： 85 文章分类： 移动安全,安全开发,渗透测试,逆向分析

AOSP源码定制-对root定制的补充

哆啦安全

2024年3月24日 13:42 四川

在小说阅读器读本章

去阅读

以下文章来源于gakki的童养夫 ，作者新垣结衣唯一丈夫

gakki的童养夫 .

emmmmm gakki是我的

AOSP源码定制-对root定制的补充

介绍

前面通过修改build.prop中的指纹以及对su的修改，完成了基础的定制修改，但是碰上一些app还是能被检测到，再进行深入修改。

问题引入

ro.vendor相关

发现测试一个app时总是开不起来，但是测试别人编译好的脱壳机却能运行，最后其实只是ro.debuggable的问题，但是在分析的过程中发现了其他几处遗漏没有抹除的特征。

这里很明显,ro.vendor.build的一些参数是有aosp的特征，没有改成user版本，tests-key。 找了半天没有找到对应的修改点，查了资料，看了下目录才反应过来，vendor镜像是一开始下驱动，运行脚本时直接打包放在vendor目录下了，是谷歌自己给我编译好的。 要修改找了资料，有好几种，一种重新编译，一种解包修改再压缩，两种方法都试了，最后都是没有效果。 这里我解包修改再重打包，out目录下，vendor相关的属性已经修改完成。 编译刷机后，还是没效果。

通过启动流程修改

继续查资料，可以明确一个事，目前app检测prop相关属性，多通过getprop命令，或者通过反射调用 android.os.SystemProperties来检测，它并不会读到/system/build.prop，/vendor/build.prop文件。 那我们只需要在系统启动时，找到对应读取prop文件的流程，在中间处理一下，做点手脚就可以了。 查阅源码，找到启动流程中载入prop配置文件的关键位置： 这里的关键函数是 load_properties_from_file，查找跟进。 这里继续跟进 load_properties，很明显了，他会读取，然后通过 property_set方法，按键值对写入。 我们可以在这里加个判断，匹配自己要修改的特征，然后自己去set。 再编译刷机，此时通过 getprop命令获取到的已经是替换后的属性值了，但是文件中的是不修改的。

adb相关

再测试发现还是被检测，继续排查，发现是ro.debuggable的问题。 我将该值置为零，再编译发现不检测了。 但是会存在问题，进系统，切到su，data等目录不再有权限访问，这是不能接受的。 这里补充一点东西。 adb的root权限是由system/core/adb/adb.c 中控制。主要根据ro.secure以及ro.debuggable等system property来控制。 默认当ro.secure为0时，开启root权限，为1时再根据ro.debuggable等选项来确认是否可以用开启root权限，一般会降权返回一个shell用户权限。因此如果要开启adb的root权限，有两种修改的方式:

1. 修改system property ro.secure， 让ro.secure=0。
2. 修改adb.c 中开启root 权限的判断逻辑。

但1方法显然是很容易被检测到，正常手机ro.secure的值都是1。 所以直接将ro.debuggable=0,修改adb源码，达到不降权的目的。 这里就修改一处即可。 将这里的降权判断函数，返回值强恒为false即可。 再测试adb直接返回了root用户权限，且ro.debuggable仍然为0。

总结

主要学习到的还是通过修改启动流程中的载入prop过程，达到抹去特征，可以将之前修改的特征通通使用这个方法进行抹除，更加简单。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：哆啦安全 《AOSP源码定制-对root定制的补充》