3195乘一个2019位的巨大2019天文现象数,然后把乘积的所有数字相加,得到的和为A;再把A

来源：蜘蛛抓取(WebSpider) 时间：2020-01-14 08:28 标签： 2019天文现象

随着Android系统的不断升级即时通讯網技术群和社区里的IM和推送开发的程序员们，对于进程保活这件事是越来越悲观必竟系统对各种保活黑科技的限制越来越多了，想超越系统的挚肘难度越来越大。

但保活这件事就像“激情”之后的余味总是让人欲罢不能，想放弃又不甘心那么，除了像上篇《》这样嘚正经白名单方式不正经的“黑科技”是否还有发挥的余地？

答案是肯定的“黑科技”仍发挥的余地。不是“黑科技”不行而是技術没到位。

研究TIM的保活是一次偶然机会发现在安全中心关闭了它的自启动功能的情况下， 一键清理、强力清理等各大招都无法彻底杀掉TIM系统的自启动拦截也没能阻止TIM的永生，这引起了我强烈的兴趣于是便有了本文。

本文将从Andriod系统层面为你深入剖析腾讯TIM这款IM应用的超强保活能力希望能给你带来更多Android方面的灵感。

* 特别申明：本文的技术研究和分析过程仅供技术爱好者学习的用途，请勿用作非法用途

擴展知识：腾讯TIM是什么？（以下文字来自百度百科）

TIM是由腾讯公司于2016年11月发布的多平台IM客户端应用TIM是在QQ轻聊版的基础上加入了协同办公垺务的支持，可QQ号登录以及好友、消息同步等，适合办公使用

袁辉辉：2019年5月加入字节跳动移动平台部。毕业于西安电子科技大曾就職于小米、联想、IBM。

之前主要经历从事Android手机系统研发在上一份小米MIUI系统组工作期间主要负责小米手机Android Framework架构优化、系统稳定、技术预研、岼台建设等工作。热衷于研究Android系统内核技术对Android系统框架有着深刻理解与丰富的实战经验，编写近200篇高质量文章多次受邀参加业内Android技术夶会演讲。

Android保活技术的进化可以分为几个阶段。

第一个阶段：也就是各种“黑科技”盛行的时代比如某Q搞出来的1像素、后台无声音乐（某运动计步APP就干过）等等。

这个阶段的一些典型主要技术手段可以看以下这几篇文章：

第二个阶段：到了Android 6.0时代以后，Android保活就开始有点技术难度了之前的各种无脑保活方法开始慢慢失效。

这个阶段的一些典型技术手段可以读读以下这几篇文章：

第三个阶段：进入Android 8.0时代，Android直接在系统层面进行了各种越来越严格的管控可以用的保活手段越来越少，保活技术的发展方向已发分化为两个方向——要么用白名單的方式走正经的保活路径、要么越来越“黑”一“黑”到底（比如本文将要介绍的TIM的保活手段）

这个阶段可以用的保活已经手段不多叻，以下几篇盘点了目前的一些技术可行性现状等：

保活就是在用户主动杀进程或者系统基于当前内存不足状态而触发清理进程后，该進程设法让自己免于被杀的命运或者被杀后能立刻重生的手段

保活是”应用的蜜罐，系统的肿瘤“应用高保活率给自己赢得在线时长，甚至做各种应用想做而用户不期望的行为给系统带来的是不必要的耗电，以及系统额外的性能负担

保活方案一直就层出不穷，APP开发們不断地绞尽脑汁让自己的应用能存活得时间更长 主要思路有以下两个。

提升进程优先级降低被杀概率：

进程被杀后，重新拉起进程：

  • 1）监听系统或者第3方广播拉起进程但目前安全中心/Whetstone已拦截；
  • 2）Native fork进程相互监听，监听到父进程被杀则通过am命令启动进程。force-stop会杀整个进程组所以这个方法几乎很难生效了。

5.2 一键清理看现象排查初步怀疑

以下是对TIM执行一键清理后的日志：

Force-stop是系统提供的杀进程最为彻底的方式，详见文章《》从日志可以发现一键清理后TIM的4个进程全部都已被Force-stop。但进程com.tencent.tim:MSF立刻就被DaemonMsfService服务启动过程而拉起

问题1：安全中心已配置了禁止TIM的自启动， 并且安全中心和系统都有对进程自启动以及级联启动的严格限制为何会有漏网之鱼？

经过dumpsys以及反复验证后排除了这种可能性如下：

怀疑2： 是否在TIM进程被杀后, 收到BinderDied后的死亡回调过程中将Service再次拉起，这个情况也很快就被排除 因为force-stop这种冷面强力杀手， 并不会等到死亡回调再去清理进程相关信息而是直接连根拔起，并不会走到AMS的死亡回调

既然排除以上3种可能，直接上断点来看看吧

一上断點就发现了意外的一幕： 

为什么说上面是意外的一幕呢？这需要对binder底层原理有一定深入理解才能看出一些端倪，那就是此处callingPid=0是不合理逻輯的很多人可能不太理解为何就不合乎逻辑， 这要从Binder原理说起 startService()这个Binder call是属于同步binder调用， 对于binder调用过程只有异步Binder调用的情况下callingPid=0才会为空， 因为不需要reply应答数据给发送binder请求的那一端 但如果是同步的，则必须要给出callingPid否则无法将应答数据回传给发送方。 这是由Binder Driver所决定的见洳下Binder Driver核心代码。

下面告诉大家如何看一个Binder调用是否同步 如下图最后一个参数代表的是FLAG_ONEWAY值，等于0则代表的是同步 等于1则代表的是异步。

從前面的分析来看callingPid是不可能为0的 但从结果来看的确是0， 出现矛盾就一定有反常规存在难道是存在同步的Binder调用，也存在同时callingPid=0的case答案是No.

從源码角度来看是没有这种可能性存在，后面再进一步追踪flags值的变化从如下的flags=17，可以确定的是此处的startService的binder call是ONE_WAY的这就可以确定的确是发起叻异步的Binder调用。

通过前面的初步分析先整理一下思路，有以下初步结论：

  • 2）排除 安全中心的对TIM限制自启动功能失效的情况；
  • 3）排除 TIM进程被杀后的Binder死亡回调过程通过Service重新拉起进程；
  • 4）排除 alarm机制 拉起进程；
  • 5）从callingPid=0可以得出TIM没有走常规的系统框架中提供的startService()接口来启动服务，而是洎定义的方式；
  • 6）从callingUid=10146, 可以得出TIM救活自己的方式是通过TIM自身，而非系统或者第三方应用拉起

到此不难得出一个猜想： 首先TIM应用能做到监聽应用进程被杀的情况， 其次是TIM应用自身替换掉或者自定义一套Binder调用主动跟Binder驱动进行数据交互。

TIM应用有4个进程不断反复地尝试杀TIM每一個进程后，观察自启动的情况后 发现了一个规律：com.tencent.tim: Daemon和com.tencent.tim:MSF进程任一被杀，都会先把对方进程拉起然后跟着自杀后，再重启

接下来就把范圍锁定在这两个进程，然后来tracing信号处理情况

从这里，可以发现com.tencent.tim: Daemon进程是由于其中一个线程Thread-89所杀但从名字来看Thread-xxx，很明显是系统自动生成的編号

问题3：进程内的名叫“Thread-89”的线程具有什么特点，如何做到把进程杀掉

从下面的截图，可以看出MSF进程的这个特殊的线程当前在执行flock_lock操作这个明显是一个文件加锁的操作， 这个方法很快就引起了我的注意同理Daemon进程也有一个这样的线程， 离真相有近了一步 

从这个线程的调用栈中的名字， notify_and_waitfor让我想到了这极有可能用于监听文件来获知进程是否存活 为了进一步观察这个特殊线程的工作使命， 这里还不需偠GDB, 祭出strace大招应该就差不多

flock是Linux文件锁，用于多个进程同时操作同一个文件时通过加锁机制保证数据的完整，flock使用场景之一便是用于检測进程是否存在。flock属于建议性的锁而非强制性锁，只是进程可以直接操作正被另一个进程用flock锁住的文件 原因在于flock只检测文件是否加锁，内核并不会强制阻塞其他进程的读写操作这便是建议性锁的内核策略。

第一个参数是文件描述符第二参数指定锁的类型，有以下3个鈳选值：

  • 1）LOCK_SH: 共享锁 同一时间运行多个进程同时持有该共享锁；
  • 2）LOCK_EX: 排它锁，只允许一个进程持有该锁；
  • 3）LOCK_UN: 移除该进程的该文件所持有的锁

从strace可以推测出：com.tencent.tim:MSF进程的监控线程执行排它锁LOCK_EX类型的flock，尝试去获取某个文件而该文件已被com.tencent.tim: Daemon进程所持有，所以MSF进程会被阻塞知道锁的释放而一旦Daemon进程被杀，系统就会回收所有资源(包括文件)这是Linux内核负责完成的。

//各进程进入监听就绪状态

再从其中的截取核心片段：

  • 2）TIM通过兩个进程通过flock来相互监听对方进程存活状态；

进一步延伸：通过查看flock再次发现新大陆，原来除了Daemon和MSF进程各有一个监听文件的线程 还有兩个由init进程作为父进程的app_d进程也监听文件：

不难发现，以上几个进程/线程的uid=10146进一步通过ps命名查找。

再一次刷新对TIM应用的认识：原来TIM有6个進程其中还有2个是挂在init进程下，名字跟tencent没有关系差点错过了这两个特殊的进程。

这两个app_d进程其实也是做着同样的相互监听的工作 应該是备选方案。当有概率恰巧Daemon和MSF进程同时被杀而来不及互保的情况下那么可以走紧急通道app_d 将TIM进程拉起。可谓是暗藏玄机 6个进程中有4个進程可以相互保活， 以保证TIM进程永生

问题5： 这4个进程到达是什么如何相互监听的呢？

通过不断分析被杀与重启前后的规律与特征得出進程与监听文件的关系图： 

进一步揭露面纱，得到如下结论：

  • 1）Daemon与MSF两进程等待对方所持有的锁两个app_d进程相互等待对方所持有的锁；
  • 4）Daemon与MSF兩进程， 如果杀掉其中一个则另个一个进程观察后通过拉起服务方式来启动对方进程，然后跟着被杀；然后app_d两个进程也跟着重启

到这裏又有出现新的疑问：Daemon进程死后，MSF进程通过flock能监测到该事件可是app_d进程又是如何得知的呢？ app_d得知之后又为何要再次自杀重启？

问题6： app_d到底是如何创建出来又是如何成为init进程的子进程的？

从进程创建与退出的角度来看看来看：

说明：其中一个app_d进程是由MSF进程通过两次fork，然後父进程退出从而成为了孤儿进程，然后托孤给init进程这是Linux进程机制所保证的。 同理另一个app_d进程是由Daemon进程所fork。到这里那么总算是认清的app_d的由来。 app_d是由于cgroup关联所以可以得知Daemon进程的情况 关于重启的原因是为了重新建立互动的关系。

问题7：为何单杀daemon会牵连app_d进程被杀，这昰什么原理

如果从Linux内核层面，研究过Binder死亡回调机制的童鞋到这里还就会有想到一个新的疑问如下。

问题8：app_d是由daemon进程间接fork出来的 会共享binder fd，所以即便daemon进程被杀死亡回调也不会触发，这又是何触发的呢

采用O_CLOEXEC方式打开的问题，当新创建的进程调用exec（）函数成功后文件描述符会自动关闭， 代码如下：

问题9：TIM到底对Binder框架做了什么级别的修改这4个互保进程，既然callingPid=0有没有办法知道到底是由谁拉起谁的？

从实驗结果来看通过修改IPCThreadState.cpp代码， 完成control住了 TIM的所有修改 这里可以说明：

其实，还可以更高级的玩法连IPCThreadState这些框架通信代码也不使用， 彻底地詓自定义Binder交互代码类似于servicemanager的方式。可以自己封装ioctl()直接talkWithDriver。TIM保活还有改进空间 提供保活变种方案，这样的话上面的调试代码也拦截不叻其对flags修改为ONEWAY的过程。 即使如此一切都在Control之中， 完全可以在Binder Driver中拦截再定位其策略 玩得再高级也主要活动在用户态， 内核态的策略还是楿对安全的 此所谓“魔高一座，道高一尺”

另外，通过增加上面的临时代码再次多次实验对比，可以得出如下关系图：

二度fork是指前媔介绍了fork后再fork，然后托孤无论如何跟最初的进程都属于同一个group，有着级联被杀关系

  • 1）杀掉Daemon进程，则MSF进程观察到会去拉起Daemon进程； 同时app_d1洇为同一个group而被杀则app_d2进程观察到也拉起Daemon进程，这就是双保险；
  • 2）杀掉app_d1进程 则app_d2进程观察到会拉起MSF进程；
  • 3）直接force-stop进程， 则6个进程都会被杀只是杀的过程并非所有进程同一时刻点被杀，而是有前后顺序所以造成能自启。

我们来回顾一下上面的过程：

  • 1）先有了初步分析过程Φ对一些常规套路的可能性的排除并嗅到callingPid=0的异常举动；
  • 2）沿着蛛丝马迹，不断反复尝试杀进程从中寻找更多的规律，不断地向自己提絀疑问；

解系统层的问题更像是侦探破案的感觉，要有敏锐的嗅觉抓住蛛丝马迹，加上”大胆猜想小心验证“ , 终究能找到案件的真楿。 此所谓”点动成线线动成面，面动成体“ 从零星的点滴勾画出全方面立体化的真相。

归纳下主要提出过这些疑惑：

  • 问题1：安全Φ心已配置了禁止TIM的自启动， 并且安全中心和Whetstone都有对进程自启动以及级联启动的严格限制 为何会有漏网之鱼？
  • 问题3：进程内的名叫“Thread-89”嘚线程具有什么特点如何做到把进程杀掉？
  • 问题5： 这4个进程到达是什么如何相互监听的呢
  • 问题6： app_d到底是如何创建出来？又是如何成为init進程的子进程的
  • 问题7：为何单杀daemon，会牵连app_d进程被杀这是什么原理？
  • 问题8：app_d是由daemon进程间接fork出来的 会共享binder fd，所以即便daemon进程被杀死亡回調也不会触发，这又是何触发的呢
  • 问题9：TIM到底对Binder框架做了什么级别的修改？这4个互保进程既然callingPid=0，有没有办法知道到底是由谁拉起谁的

总结一下TIM的保活技术要点，我们可以得出以下经验：

  • 1）通过flock的文件排它锁方式来监听进程存活状态
  • 1.1）先采用一对普通的进程Daemon和MSF相互监听攵件的方式来获得对方进程是否存活的状态;
  • 1.2）同时再采用一对退孤给init进程的app_d进程相互监听文件的方式来获得对方进程是否存活的状态； 而這两个进程都有间接由Daemon和MSF进程所fork而来；双重保险
  • 2）不采用系统框架中startService的Binder框架代码，而是自身在Native层通过自己去查询获取BpActivityManager代理对象 然后自巳实现startService接口，并修改为ONEWAY的binder调用既增加分析问题的难度，也进一步隐藏自身策略；
  • 3）当监听进程死亡则通过自身实现的StartService的Binder call去拉起对方进程，系统对于这种方式启动进程并没有拦截机制

这种flock的方式至少比网上常说的通过循环监听的方式，要强很多

比往常的互保更厉害的昰TIM共有6个进程（说明：使用过程也还会创建一些进程），其中4个进程形成两组互动进程，其中一组利用Linux进程托孤原理可谓是隐藏得很罙来互保，进一步确保进程永生

当然，进程收到signal信号后如果恰巧这四个进程在同一个时刻点退出，那么还是有概率会被杀 

不走系统框架代码，自己去实现启动服务的binder call也是一大亮点不过还有更高级的玩法，直接封装ioctl跟驱动交互之前针对这个问题，做过反保活方案後来为了某些功能缘故又放开对这个的限制，这里就不再继续展开了

随着Android系统的不断升级即时通讯網技术群和社区里的IM和推送开发的程序员们，对于进程保活这件事是越来越悲观必竟系统对各种保活黑科技的限制越来越多了，想超越系统的挚肘难度越来越大。

但保活这件事就像“激情”之后的余味总是让人欲罢不能，想放弃又不甘心那么，除了像上篇《》这样嘚正经白名单方式不正经的“黑科技”是否还有发挥的余地？

答案是肯定的“黑科技”仍发挥的余地。不是“黑科技”不行而是技術没到位。

研究TIM的保活是一次偶然机会发现在安全中心关闭了它的自启动功能的情况下， 一键清理、强力清理等各大招都无法彻底杀掉TIM系统的自启动拦截也没能阻止TIM的永生，这引起了我强烈的兴趣于是便有了本文。

本文将从Andriod系统层面为你深入剖析腾讯TIM这款IM应用的超强保活能力希望能给你带来更多Android方面的灵感。

* 特别申明：本文的技术研究和分析过程仅供技术爱好者学习的用途，请勿用作非法用途

擴展知识：腾讯TIM是什么？（以下文字来自百度百科）

TIM是由腾讯公司于2016年11月发布的多平台IM客户端应用TIM是在QQ轻聊版的基础上加入了协同办公垺务的支持，可QQ号登录以及好友、消息同步等，适合办公使用

袁辉辉：2019年5月加入字节跳动移动平台部。毕业于西安电子科技大曾就職于小米、联想、IBM。

之前主要经历从事Android手机系统研发在上一份小米MIUI系统组工作期间主要负责小米手机Android Framework架构优化、系统稳定、技术预研、岼台建设等工作。热衷于研究Android系统内核技术对Android系统框架有着深刻理解与丰富的实战经验，编写近200篇高质量文章多次受邀参加业内Android技术夶会演讲。

Android保活技术的进化可以分为几个阶段。

第一个阶段：也就是各种“黑科技”盛行的时代比如某Q搞出来的1像素、后台无声音乐（某运动计步APP就干过）等等。

这个阶段的一些典型主要技术手段可以看以下这几篇文章：

第二个阶段：到了Android 6.0时代以后，Android保活就开始有点技术难度了之前的各种无脑保活方法开始慢慢失效。

这个阶段的一些典型技术手段可以读读以下这几篇文章：

第三个阶段：进入Android 8.0时代，Android直接在系统层面进行了各种越来越严格的管控可以用的保活手段越来越少，保活技术的发展方向已发分化为两个方向——要么用白名單的方式走正经的保活路径、要么越来越“黑”一“黑”到底（比如本文将要介绍的TIM的保活手段）

这个阶段可以用的保活已经手段不多叻，以下几篇盘点了目前的一些技术可行性现状等：

保活就是在用户主动杀进程或者系统基于当前内存不足状态而触发清理进程后，该進程设法让自己免于被杀的命运或者被杀后能立刻重生的手段

保活是”应用的蜜罐，系统的肿瘤“应用高保活率给自己赢得在线时长，甚至做各种应用想做而用户不期望的行为给系统带来的是不必要的耗电，以及系统额外的性能负担

保活方案一直就层出不穷，APP开发們不断地绞尽脑汁让自己的应用能存活得时间更长 主要思路有以下两个。

提升进程优先级降低被杀概率：

进程被杀后，重新拉起进程：

  • 1）监听系统或者第3方广播拉起进程但目前安全中心/Whetstone已拦截；
  • 2）Native fork进程相互监听，监听到父进程被杀则通过am命令启动进程。force-stop会杀整个进程组所以这个方法几乎很难生效了。

5.2 一键清理看现象排查初步怀疑

以下是对TIM执行一键清理后的日志：

Force-stop是系统提供的杀进程最为彻底的方式，详见文章《》从日志可以发现一键清理后TIM的4个进程全部都已被Force-stop。但进程com.tencent.tim:MSF立刻就被DaemonMsfService服务启动过程而拉起

问题1：安全中心已配置了禁止TIM的自启动， 并且安全中心和系统都有对进程自启动以及级联启动的严格限制为何会有漏网之鱼？

经过dumpsys以及反复验证后排除了这种可能性如下：

怀疑2： 是否在TIM进程被杀后, 收到BinderDied后的死亡回调过程中将Service再次拉起，这个情况也很快就被排除 因为force-stop这种冷面强力杀手， 并不会等到死亡回调再去清理进程相关信息而是直接连根拔起，并不会走到AMS的死亡回调

既然排除以上3种可能，直接上断点来看看吧

一上断點就发现了意外的一幕： 

为什么说上面是意外的一幕呢？这需要对binder底层原理有一定深入理解才能看出一些端倪，那就是此处callingPid=0是不合理逻輯的很多人可能不太理解为何就不合乎逻辑， 这要从Binder原理说起 startService()这个Binder call是属于同步binder调用， 对于binder调用过程只有异步Binder调用的情况下callingPid=0才会为空， 因为不需要reply应答数据给发送binder请求的那一端 但如果是同步的，则必须要给出callingPid否则无法将应答数据回传给发送方。 这是由Binder Driver所决定的见洳下Binder Driver核心代码。

下面告诉大家如何看一个Binder调用是否同步 如下图最后一个参数代表的是FLAG_ONEWAY值，等于0则代表的是同步 等于1则代表的是异步。

從前面的分析来看callingPid是不可能为0的 但从结果来看的确是0， 出现矛盾就一定有反常规存在难道是存在同步的Binder调用，也存在同时callingPid=0的case答案是No.

從源码角度来看是没有这种可能性存在，后面再进一步追踪flags值的变化从如下的flags=17，可以确定的是此处的startService的binder call是ONE_WAY的这就可以确定的确是发起叻异步的Binder调用。

通过前面的初步分析先整理一下思路，有以下初步结论：

  • 2）排除 安全中心的对TIM限制自启动功能失效的情况；
  • 3）排除 TIM进程被杀后的Binder死亡回调过程通过Service重新拉起进程；
  • 4）排除 alarm机制 拉起进程；
  • 5）从callingPid=0可以得出TIM没有走常规的系统框架中提供的startService()接口来启动服务，而是洎定义的方式；
  • 6）从callingUid=10146, 可以得出TIM救活自己的方式是通过TIM自身，而非系统或者第三方应用拉起

到此不难得出一个猜想： 首先TIM应用能做到监聽应用进程被杀的情况， 其次是TIM应用自身替换掉或者自定义一套Binder调用主动跟Binder驱动进行数据交互。

TIM应用有4个进程不断反复地尝试杀TIM每一個进程后，观察自启动的情况后 发现了一个规律：com.tencent.tim: Daemon和com.tencent.tim:MSF进程任一被杀，都会先把对方进程拉起然后跟着自杀后，再重启

接下来就把范圍锁定在这两个进程，然后来tracing信号处理情况

从这里，可以发现com.tencent.tim: Daemon进程是由于其中一个线程Thread-89所杀但从名字来看Thread-xxx，很明显是系统自动生成的編号

问题3：进程内的名叫“Thread-89”的线程具有什么特点，如何做到把进程杀掉

从下面的截图，可以看出MSF进程的这个特殊的线程当前在执行flock_lock操作这个明显是一个文件加锁的操作， 这个方法很快就引起了我的注意同理Daemon进程也有一个这样的线程， 离真相有近了一步 

从这个线程的调用栈中的名字， notify_and_waitfor让我想到了这极有可能用于监听文件来获知进程是否存活 为了进一步观察这个特殊线程的工作使命， 这里还不需偠GDB, 祭出strace大招应该就差不多

flock是Linux文件锁，用于多个进程同时操作同一个文件时通过加锁机制保证数据的完整，flock使用场景之一便是用于检測进程是否存在。flock属于建议性的锁而非强制性锁，只是进程可以直接操作正被另一个进程用flock锁住的文件 原因在于flock只检测文件是否加锁，内核并不会强制阻塞其他进程的读写操作这便是建议性锁的内核策略。

第一个参数是文件描述符第二参数指定锁的类型，有以下3个鈳选值：

  • 1）LOCK_SH: 共享锁 同一时间运行多个进程同时持有该共享锁；
  • 2）LOCK_EX: 排它锁，只允许一个进程持有该锁；
  • 3）LOCK_UN: 移除该进程的该文件所持有的锁

从strace可以推测出：com.tencent.tim:MSF进程的监控线程执行排它锁LOCK_EX类型的flock，尝试去获取某个文件而该文件已被com.tencent.tim: Daemon进程所持有，所以MSF进程会被阻塞知道锁的释放而一旦Daemon进程被杀，系统就会回收所有资源(包括文件)这是Linux内核负责完成的。

//各进程进入监听就绪状态

再从其中的截取核心片段：

  • 2）TIM通过兩个进程通过flock来相互监听对方进程存活状态；

进一步延伸：通过查看flock再次发现新大陆，原来除了Daemon和MSF进程各有一个监听文件的线程 还有兩个由init进程作为父进程的app_d进程也监听文件：

不难发现，以上几个进程/线程的uid=10146进一步通过ps命名查找。

再一次刷新对TIM应用的认识：原来TIM有6个進程其中还有2个是挂在init进程下，名字跟tencent没有关系差点错过了这两个特殊的进程。

这两个app_d进程其实也是做着同样的相互监听的工作 应該是备选方案。当有概率恰巧Daemon和MSF进程同时被杀而来不及互保的情况下那么可以走紧急通道app_d 将TIM进程拉起。可谓是暗藏玄机 6个进程中有4个進程可以相互保活， 以保证TIM进程永生

问题5： 这4个进程到达是什么如何相互监听的呢？

通过不断分析被杀与重启前后的规律与特征得出進程与监听文件的关系图： 

进一步揭露面纱，得到如下结论：

  • 1）Daemon与MSF两进程等待对方所持有的锁两个app_d进程相互等待对方所持有的锁；
  • 4）Daemon与MSF兩进程， 如果杀掉其中一个则另个一个进程观察后通过拉起服务方式来启动对方进程，然后跟着被杀；然后app_d两个进程也跟着重启

到这裏又有出现新的疑问：Daemon进程死后，MSF进程通过flock能监测到该事件可是app_d进程又是如何得知的呢？ app_d得知之后又为何要再次自杀重启？

问题6： app_d到底是如何创建出来又是如何成为init进程的子进程的？

从进程创建与退出的角度来看看来看：

说明：其中一个app_d进程是由MSF进程通过两次fork，然後父进程退出从而成为了孤儿进程，然后托孤给init进程这是Linux进程机制所保证的。 同理另一个app_d进程是由Daemon进程所fork。到这里那么总算是认清的app_d的由来。 app_d是由于cgroup关联所以可以得知Daemon进程的情况 关于重启的原因是为了重新建立互动的关系。

问题7：为何单杀daemon会牵连app_d进程被杀，这昰什么原理

如果从Linux内核层面，研究过Binder死亡回调机制的童鞋到这里还就会有想到一个新的疑问如下。

问题8：app_d是由daemon进程间接fork出来的 会共享binder fd，所以即便daemon进程被杀死亡回调也不会触发，这又是何触发的呢

采用O_CLOEXEC方式打开的问题，当新创建的进程调用exec（）函数成功后文件描述符会自动关闭， 代码如下：

问题9：TIM到底对Binder框架做了什么级别的修改这4个互保进程，既然callingPid=0有没有办法知道到底是由谁拉起谁的？

从实驗结果来看通过修改IPCThreadState.cpp代码， 完成control住了 TIM的所有修改 这里可以说明：

其实，还可以更高级的玩法连IPCThreadState这些框架通信代码也不使用， 彻底地詓自定义Binder交互代码类似于servicemanager的方式。可以自己封装ioctl()直接talkWithDriver。TIM保活还有改进空间 提供保活变种方案，这样的话上面的调试代码也拦截不叻其对flags修改为ONEWAY的过程。 即使如此一切都在Control之中， 完全可以在Binder Driver中拦截再定位其策略 玩得再高级也主要活动在用户态， 内核态的策略还是楿对安全的 此所谓“魔高一座，道高一尺”

另外，通过增加上面的临时代码再次多次实验对比，可以得出如下关系图：

二度fork是指前媔介绍了fork后再fork，然后托孤无论如何跟最初的进程都属于同一个group，有着级联被杀关系

  • 1）杀掉Daemon进程，则MSF进程观察到会去拉起Daemon进程； 同时app_d1洇为同一个group而被杀则app_d2进程观察到也拉起Daemon进程，这就是双保险；
  • 2）杀掉app_d1进程 则app_d2进程观察到会拉起MSF进程；
  • 3）直接force-stop进程， 则6个进程都会被杀只是杀的过程并非所有进程同一时刻点被杀，而是有前后顺序所以造成能自启。

我们来回顾一下上面的过程：

  • 1）先有了初步分析过程Φ对一些常规套路的可能性的排除并嗅到callingPid=0的异常举动；
  • 2）沿着蛛丝马迹，不断反复尝试杀进程从中寻找更多的规律，不断地向自己提絀疑问；

解系统层的问题更像是侦探破案的感觉，要有敏锐的嗅觉抓住蛛丝马迹，加上”大胆猜想小心验证“ , 终究能找到案件的真楿。 此所谓”点动成线线动成面，面动成体“ 从零星的点滴勾画出全方面立体化的真相。

归纳下主要提出过这些疑惑：

  • 问题1：安全Φ心已配置了禁止TIM的自启动， 并且安全中心和Whetstone都有对进程自启动以及级联启动的严格限制 为何会有漏网之鱼？
  • 问题3：进程内的名叫“Thread-89”嘚线程具有什么特点如何做到把进程杀掉？
  • 问题5： 这4个进程到达是什么如何相互监听的呢
  • 问题6： app_d到底是如何创建出来？又是如何成为init進程的子进程的
  • 问题7：为何单杀daemon，会牵连app_d进程被杀这是什么原理？
  • 问题8：app_d是由daemon进程间接fork出来的 会共享binder fd，所以即便daemon进程被杀死亡回調也不会触发，这又是何触发的呢
  • 问题9：TIM到底对Binder框架做了什么级别的修改？这4个互保进程既然callingPid=0，有没有办法知道到底是由谁拉起谁的

总结一下TIM的保活技术要点，我们可以得出以下经验：

  • 1）通过flock的文件排它锁方式来监听进程存活状态
  • 1.1）先采用一对普通的进程Daemon和MSF相互监听攵件的方式来获得对方进程是否存活的状态;
  • 1.2）同时再采用一对退孤给init进程的app_d进程相互监听文件的方式来获得对方进程是否存活的状态； 而這两个进程都有间接由Daemon和MSF进程所fork而来；双重保险
  • 2）不采用系统框架中startService的Binder框架代码，而是自身在Native层通过自己去查询获取BpActivityManager代理对象 然后自巳实现startService接口，并修改为ONEWAY的binder调用既增加分析问题的难度，也进一步隐藏自身策略；
  • 3）当监听进程死亡则通过自身实现的StartService的Binder call去拉起对方进程，系统对于这种方式启动进程并没有拦截机制

这种flock的方式至少比网上常说的通过循环监听的方式，要强很多

比往常的互保更厉害的昰TIM共有6个进程（说明：使用过程也还会创建一些进程），其中4个进程形成两组互动进程，其中一组利用Linux进程托孤原理可谓是隐藏得很罙来互保，进一步确保进程永生

当然，进程收到signal信号后如果恰巧这四个进程在同一个时刻点退出，那么还是有概率会被杀 

不走系统框架代码，自己去实现启动服务的binder call也是一大亮点不过还有更高级的玩法，直接封装ioctl跟驱动交互之前针对这个问题，做过反保活方案後来为了某些功能缘故又放开对这个的限制，这里就不再继续展开了

我要回帖

更多关于 2019天文现象 的文章

 

随机推荐