介绍
前面通过修改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权限，有两种修改的方式:
- 修改system property ro.secure， 让ro.secure=0。
- 修改adb.c 中开启root 权限的判断逻辑。
但1方法显然是很容易被检测到，正常手机ro.secure的值都是1。
所以直接将ro.debuggable=0,修改adb源码，达到不降权的目的。
这里就修改一处即可。
将这里的降权判断函数，返回值强恒为false即可。
再测试adb直接返回了root用户权限，且ro.debuggable仍然为0。
总结
主要学习到的还是通过修改启动流程中的载入prop过程，达到抹去特征，可以将之前修改的特征通通使用这个方法进行抹除，更加简单。