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如此繁多,不太可能全量去检测
[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课
Lupinus 这个方案是ok的,就是还有一些优化空间,比如说libc上传内存中的so到后台去分析,还不如把磁盘中提取的so和内存中的so用类似md5或者crc的方式处理一下一起传到后台,然后后台根据一样机型和小版本 ...