ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

KeepAlive 攻防指南:MIUI 为何封杀它?系统级防御与反制策略全解读

2026/8/28 15:56:52 拓冰建站 浏览量
KeepAlive 攻防指南:MIUI 为何封杀它?系统级防御与反制策略全解读 KeepAlive 攻防指南MIUI 为何封杀它系统级防御与反制策略全解读【免费下载链接】KeepAliveFighting against force-stop kill process on Android with binder ioctl / Android高级保活项目地址: https://gitcode.com/gh_mirrors/ke/KeepAliveKeepAlive 是一个 Android 高级保活进程复活开源库它通过 binder ioctl 直接与系统 binder 驱动通信让被杀死的进程能被守护进程复活。本文带你彻底看懂它的攻防原理为什么 MIUI 等定制系统会封杀它、系统层该如何防御、又该如何反制。什么是 KeepAliveAndroid 保活的不死方案KeepAlive 在 Leoric通过 JNI 复活进程的基础上实现了通过ioctl 复活进程能最大程度提高复活率资源占用少用户无感知成功率高在未被封杀的环境下Android 4.4 ~ 9.0 模拟器几乎杀不死 同时是学习binder 框架的优秀案例⚠️ 作者明确提示真机上不能保证保活成功MIUI 等定制系统已封杀了这个方案不建议在 C 端产品上使用。保活原理三个进程如何互相守护一、进程结构主进程 双守护KeepAlive 把 App 拆成三个互相监听的进程配置见library/src/main/java/com/boolbird/keepalive/KeepAliveConfigs.java进程默认名称角色主进程App 包名业务逻辑负责初始化保活常驻进程:resident守护者 A监控守护者 BDaemon 助手android.process.daemon守护者 B伪装成系统进程名任一进程被杀另外两个都会通过 binder 把它拉起来形成连环守护。二、复活机制绕过 Java API 直接喊话 AMS核心实现在library/src/main/java/com/boolbird/keepalive/KeepAliveProcessImpl.java反射拿到ActivityManagerNative的远程代理mRemote即 ActivityManagerService 的 binder 对象按 AIDL 协议手工构造startService的 Parcel 数据——注意不同系统版本的 transaction code 不同Android 9 为 24、8.0 为 30、7.x 为 26、4.4 为 34这就是它只能覆盖 4.4~9.0 的原因一旦检测到目标进程死亡直接调用mRemote.transact(code, parcel, null, 1)让系统以为是正常启动服务进程原地复活。三、监听机制C 层的隐藏观察者library/src/main/cpp/keep_alive.cppJNI 声明见library/src/main/java/com/boolbird/keepalive/NativeKeepAlive.java实现了进程死亡检测双重fork派生隐藏子进程并用setArgV0把进程名伪装成app_d躲避ps排查用 indicator 标记文件 flock文件锁判断对方是否还活着进程死亡时锁自动释放观察者立刻发起 binder 复活配合AlarmManager每 60 秒定时唤醒见KeepAlive.launchAlarm和bindServicelinkToDeath死亡回调多管齐下。为防止无限重启风暴还内置了rebootThreshold(10s, 3)10 秒内连续重启超过 3 次就自动停用守护实现见KeepAlive.checkProcessContinuousBootOverTimes。为什么 MIUI 会封杀 KeepAlive这套方案的隐藏前提是杀了我之后系统还允许我启动新进程。用户点击强制停止am force-stop时标准流程是直接杀掉该应用的进程。但如果观察者进程在被打死前抢先发出一次transact进程就复活了保活成功。MIUI 等定制 ROM 正是针对这个窗口期做了两处系统级改造README「应对方法」一节给出的官方思路force-stop 期间禁止启动新进程系统为该应用打上正在强杀标记标记存续期间所有指向该应用的 startService/startActivity 请求被直接拒绝——观察者喊话也喊不出活来批量收集后统一击杀不再发现一个杀一个而是先收集好应用的全部进程必要时先发送 SIGSTOP 冻结再统一 kill杜绝任何进程在间隙中偷跑复活请求。反制策略一条命令冻结并终结观察者项目根目录的 kill_alive.sh 就是压力测试脚本循环 100 次执行am force-stop观察复活率。在未被改造的系统上单条 force-stop 往往杀不干净正确的终结姿势是README 给出ps -A | grep ps -A | grep keepalive | awk {print $1} | head -1 | awk {print $2} | xargs kill -19 am force-stop com.boolbird.keepalive拆解一下kill -19发送SIGSTOP先把观察者进程冻结让它彻底失去复活窗口随后am force-stop再整体击杀。这正是防御策略先 SIGSTOP、后统一 kill在攻击侧的直接应用——攻防双方博弈的核心都在这几百毫秒的时间窗口里。如何快速上手4 步集成 KeepAlive以 demo 模块app/为例注册保活配置在 Application 的attachBaseContext中调用KeepAlive.init(base, configs)指定常驻 Servicedemoapp/src/main/java/com/boolbird/keepalive/demo/MainApplication.java声明 Service在app/src/main/AndroidManifest.xml中给 Service 设置独立进程:residentService 需继承KeepAliveService否则在 Android 4.4 上无保活效果启动服务startService(...)即可自动唤醒保活进程可选增强configs.ignoreBatteryOptimization()忽略电池优化、configs.rebootThreshold(10*1000, 3)重启限频、configs.setOnBootReceivedListener(...)设置开机自启。适用场景与注意事项维度说明✅ 推荐自研轻量定制 Android 系统对系统应用的保活✅ 推荐作为binder 框架的学习案例⚠️ 谨慎C 端消费者产品不建议使用⚠️ 注意避免在 Application 中初始化第三方库否则所有进程都会重复初始化一句话总结KeepAlive 用三进程互守 binder 直连 AMS把复活率拉满而 MIUI 的应对就是强杀期间禁启 先冻结后集火。理解了这场攻防你也就读懂了 Android 进程保活与系统管控博弈的本质。【免费下载链接】KeepAliveFighting against force-stop kill process on Android with binder ioctl / Android高级保活项目地址: https://gitcode.com/gh_mirrors/ke/KeepAlive创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考