app开启一条防护线程，这条防护线程魔改的ollvm+18层arm vmp,与业务线程维持通信，一旦检测到系统库被篡改，则业务线程会不正常；也与服务器通信，服务器发觉不正常，同样会导致业务不正常。
以libc.so为例，检测系统库是否被篡改采取的办法是，读取maps文件，把so整个内存加密之后发给服务器，比如手机是小米8，则服务器也会找一台小米8去运行app，然后从内存中提取出so，服务器进行分析比对。
绕过方案一，硬件断点，去分析检测线程逻辑，由于高强度，故此方案pass
绕过方案二，篡改maps文件，把未篡改过的libc重新mmap到其他地方去，maps文件各个库映射有一定规律，比如libc映射内存下方是某个so，上方是某个so，这就可以检测出来，同时，也会造成dlopen dlsym获取到的符号与读取maps文件得到基址算出来的符号不一致，一个符号，两个地址，这难道不是对android系统的背叛吗
请问有什么方案可绕过这种检测方案，另外请问实际工作中，这种方案是否能够实行，因为那么多个手机，那么多个版本，收集工作量有点多；在一个就是app业务有时候自己就会去hook系统；再一个就是系统so如此繁多，不太可能全量去检测
[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！
最后于 2023-6-7 18:34
被KerryS编辑
，原因：
