史上最强Android保活思路:深入剖析腾讯TIM的进程永生技术(16)
2023-04-30 来源:飞速影视
![史上最强Android保活思路:深入剖析腾讯TIM的进程永生技术](http://fs.qqfile.top/re/aHR0cHM6Ly9waWNzNS5iYWlkdS5jb20vZmVlZC9lN2NkN2I4OTllNTEwZmIzNzY3ODdlNjZmZGE5YzU5M2QwNDMwYzc5LnBuZ0BmX2F1dG8_dG9rZW49NTAzYWUzYjM5MjkzZGE2NTYyZjM0YWM5YWM4Y2I2YTQmYW1wO3M9QjI5MTMxQzgxQUY2QTQ0OTRFNzBDODBEMDAwMEYwQzM1)
从实验结果来看,通过修改IPCThreadState.cpp代码, 完成control住了 TIM的所有修改, 这里可以说明:
TIM分别在Java层和Native层,主动向ServiceManager进程查询AMS后,获取BpActivityManager代理对象,然后继续使用框架中的IPCThreadState跟Binder驱动交互,并没有替换掉libbinder.so。
其实,还可以更高级的玩法,连IPCThreadState这些框架通信代码也不使用, 彻底地去自定义Binder交互代码,类似于servicemanager的方式。可以自己封装ioctl(),直接talkWithDriver。TIM保活还有改进空间, 提供保活变种方案,这样的话,上面的调试代码也拦截不了其对flags修改为ONEWAY的过程。 即使如此,一切都在Control之中, 完全可以在Binder Driver中拦截再定位其策略, 玩得再高级也主要活动在用户态, 内核态的策略还是相对安全的, 此所谓“魔高一座,道高一尺”。
另外,通过增加上面的临时代码,再次多次实验对比,可以得出如下关系图:
![史上最强Android保活思路:深入剖析腾讯TIM的进程永生技术](/images/loading.gif)
二度fork是指前面介绍了,fork后再fork,然后托孤,无论如何跟最初的进程都属于同一个group,有着级联被杀关系。
本站仅为学习交流之用,所有视频和图片均来自互联网收集而来,版权归原创者所有,本网站只提供web页面服务,并不提供资源存储,也不参与录制、上传
若本站收录的节目无意侵犯了贵司版权,请发邮件(我们会在3个工作日内删除侵权内容,谢谢。)
www.fs94.org-飞速影视 粤ICP备74369512号