tgoop.com/CanyieChannel/188
Last Update:
公开两个检测 resetprop 的方法：
通过 setprop/getprop 等手段操作property 实际上是操作了位于 /dev/__property__ 下的文件。按 property 各自的 SELinux Context 存储，相同的 context 分为一组，存储在一个文件内。每个文件大小为固定的 128KB。需要使用的 prop_bt prop_info 等对象由一个线性内存分配器实现，每次分配内存时只是简单地 bump 地址，不支持释放内存。
更多细节可以查看 https://blog.canyie.top/2022/04/09/property-implementation-and-isolation/
Magisk 的 resetprop 在删除 property 时，会将 prop_bt 中指向 prop_info 的引用置空，然后清空整个 prop_info 的内存。问题就发生在这里，prop_info 的内存被清空但并没有被释放，这就导致对应内存位置出现一片很大的空区域。通过检测这里，应用可以检测到对应属性区域有属性被删除了，进而推断出设备已经 root（因为正常情况 property 是不支持删除的）。
什么时候会发生删除操作？通过 resetprop 重置 ro 也就是只读属性时。而保存着 bootloader 锁定状态的多个 property 和保存着 native bridge 的 ro.dalvik.vm.native.bridge 还有经常被修改的设备指纹都是只读属性。也就是说，除非避免修改这些属性，否则就会被检测到，而不修改 bootloader 状态的属性又会导致里面直接存着“已解锁”，应用一样可以读到。
在 https://github.com/topjohnwu/Magisk/commit/f41994cb52ca08856216a8da0a28ed148c833f4e 过后，作为副作用，上面的问题刚好被缓解，但还有另一个问题：
prop_info 上有一个字段叫 serial，当这个 prop_info 被更新时，serial 会自增 2。也就是说，prop 被更新的次数 = serial / 2。而对于 ro 属性，它们是只读的，正常情况根本无法被更新，因此 serial 应该始终保持为 0。也就是说，如果发现 serial 不为 0 的只读属性，就代表它被 resetprop 过。
我们调查发现已经有应用在使用这些方法检测 root，Shamiko 1.0+ 已经尽全力隐藏了相关痕迹。我知道有很多人并不愿意使用 Shamiko，而其他隐藏方案的开发者并不知道这两个检测点，也就没有办法处理它，所以我公开了。
BY 小页页的胡言乱语
Share with your friend now:
tgoop.com/CanyieChannel/188