能力值：
( LV2，RANK：10 )
|
-
-
26 楼
6
|
能力值：
( LV2，RANK：10 )
|
-
-
27 楼
666
|
能力值：
( LV13，RANK：409 )
|
-
-
28 楼
1
|
能力值：
( LV3，RANK：20 )
|
-
-
29 楼
我能想到有2个防御点，一起讨论看看：1、 challenge 用时间戳，中间人转发 KA 请求，到 root 未解锁设备生成KA结果，再转发回来，这里耗时估计会比较高，后端服务器计算KA结果到服务器的时间，减去 challenge的时间，对比同型号其他设备的平时间差；
2、攻击者需要以我们app的身份在root未解锁的设备发起KA请求，那肯定要注入代码，这里就需要做好app被注入攻击的检测（lsposed、frida等等）。
最后于 2026-6-11 10:11
被dreameriii编辑
，原因：
|
能力值：
( LV5，RANK：70 )
|
-
-
30 楼
1
|
能力值：
( LV1，RANK：0 )
|
-
-
31 楼
感谢分享
|
能力值：
( LV2，RANK：10 )
|
-
-
32 楼
dreameriii
我能想到有2个防御点，一起讨论看看：1、 challenge 用时间戳，中间人转发 KA 请求，到 root& ...
1.抛去网络延时，我知道有实现已经可以在10ms内完成双向传输，而且计算ka到服务器的时间受网络环境影响太大了； 2.可以注入keystore2 binder服务而不是app 我觉得本质上这个是没办法防御的，除非将密钥认证证书与设备硬件信息进行绑定，并且传送给谷歌，类比腾讯soter的实现。
|
能力值：
( LV2，RANK：10 )
|
-
-
33 楼
此外就是做好安全补丁版本验证，对安全补丁斑斑太低的设备提高不信任值。
|
能力值：
( LV4，RANK：50 )
|
-
-
34 楼
mark
|
能力值：
( LV3，RANK：20 )
|
-
-
35 楼
 确实，注入 keystore2 那就没办法了。
|
能力值：
( LV1，RANK：0 )
|
-
-
36 楼
666
|
能力值：
( LV4，RANK：50 )
|
-
-
37 楼
666
|
能力值：
( LV1，RANK：0 )
|
-
-
38 楼
6666
|
能力值：
( LV2，RANK：10 )
|
-
-
39 楼
tql
|
能力值：
( LV4，RANK：40 )
|
-
-
40 楼
666
|
能力值：
( LV1，RANK：0 )
|
-
-
41 楼
love
|
能力值：
( LV2，RANK：10 )
|
-
-
42 楼
66666
|
能力值：
( LV1，RANK：0 )
|
-
-
43 楼
学习一下
|
能力值：
( LV1，RANK：0 )
|
-
-
44 楼
学习一下
|
能力值：
( LV1，RANK：0 )
|
-
-
45 楼
666
|
能力值：
( LV2，RANK：10 )
|
-
-
46 楼
666
|
能力值：
( LV1，RANK：0 )
|
-
-
47 楼
666
|
能力值：
( LV2，RANK：10 )
|
-
-
48 楼
see
|
能力值：
( LV2，RANK：10 )
|
-
-
49 楼
555
|
能力值：
( LV2，RANK：10 )
|
-
-
50 楼
学习
|
|
|
|
