文章总结： 本文深度逆向分析了某头部大厂APP在Android10+环境下的Native层保活机制。核心采用三重技术：通过DoubleFork创建孤儿进程脱离原进程组避免连坐查杀；利用flock文件锁监控主进程存活状态；通过纯C++构造Parcel数据实现Binder穿透直接唤醒主进程。该方案具有高隐蔽性和存活率，为Android安全防护提供了重要参考。 综合评分： 85 文章分类： 移动安全,逆向分析,安全工具,恶意软件,技术标准
ANDROID 黑科技 : 保活机制深度逆向
易之生生 易之生生
看雪学苑
2026年4月24日 17:59 上海
在小说阅读器读本章
去阅读
在 Android 逆向与安全防护的博弈中，进程保活（Keep-Alive）始终是一个充满争议且技术密集的话题。随着 Android 系统的迭代，从早期的1 像素 Activity、JobScheduler，到后来的各种同步账号机制，系统对后台进程的容忍度越来越低。
本文将以某头部大厂 APP 中的保活模块（libundead_native_ability_q.so）为例，深度剖析其在 Android 10+ (API 29及以上) 环境下，如何利用 C/C++ 层的双重 Fork 逃逸、Flock 文件锁监控以及纯 Native 层的 Binder 穿透技术，实现高隐蔽性、高存活率的“不死”机制。
Java 层切入：寻根溯源
通过对 APK 的初步分析，我们定位到核心的保活入口位于包com.bytedance.platform.ka下。针对高版本 Android 系统，应用采用了分层策略，其中针对 Android 10+ 的核心类为KaAbilityQ。
查看其反编译代码：
package com.bytedance.platform.ka.ability.q.KaAbilityQ;
public class KaAbilityQ extends 09xQ implements 09xS {
// 指定加载的 SO 库名称
public void KaAbilityQ(Application p0, 09xO p1){
super(p0, p1);
this.LIZLLL = "undead_native_ability_q";
}
// 核心 JNI 方法声明
private native intdoKaOnNative(IBinder p0, long[] p1, String p2, long p3,
String p4, String p5, String p6, String p7,
String p8, boolean p9, String p10, String p11,
int p12, int p13);
// JAVA 调用接口
public final intLIZ(IBinder p0,long[] p1,String p2,long p3,String p4,String p5,String p6,String p7,String p8,boolean p9,String p10,String p11,int p12,int p13){
this.LIZIZ();
if (this.LIZJ != null) {
UnDeadLog.d("KaAbilityQ", "library load success,invoke doKaOnNative");
return this.doKaOnNative(p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10, p11, p12, p13);
}else {
UnDeadLog.e("KaAbilityQ", "library load failed,not doKA");
return -1;
}
}
}
从这里可以看出，Java 层主要负责环境准备和参数收集（如当前进程名、各种开关 Flag），真正的硬核逻辑全部通过doKaOnNative交给了libundead_native_ability_q.so处理。
在 ServiceImpl 的 LIZIZ 函数中进行了参数初始化并调用了 LIZ 函数。
ServiceImplplatform = serviceImpl.platform;
IBinderbinder = serviceImpl.o.getBinder();
ServiceImplg = serviceImpl.g;
ServiceImplmInstrConfig = serviceImpl.mInstrConfig;
mInstrConfig.getClass();
Stringstr4 = StringBuilderCache.release(StringBuilderCache.get() + mInstrConfig.LJI() + "/enable.flag");
mInstrConfig = serviceImpl.mInstrConfig;
mInstrConfig.getClass();
Stringstr5 = StringBuilderCache.release(StringBuilderCache.get() + mInstrConfig.LJI() + "/top.flag");
mInstrConfig = serviceImpl.mInstrConfig;
mInstrConfig.getClass();
StringBuilderCache.release(StringBuilderCache.get() + mInstrConfig.LJI() + "/mcomm");
if ((iKADepend = serviceImpl.mInstrConfig.LIZ()) != null) {
daemonProces = iKADepend.getDaemonProcessName();
if (!TextUtils.isEmpty(daemonProces)) {
StringpackageName = serviceImpl.mInstrConfig.LIZIZ.getPackageName();
b = serviceImpl.mIKADepend.useNativeMode();
if ((config1 = serviceImpl.mInstrConfig.LIZ.getConfig("instr")) != null && !config1.isEmpty()) {
str = config1;
}
inti1 = platform.LJ.LIZ(binder, g, str1, l2, str4, str5, p1, daemonProces, packageName, b, str, ToolUtils.LJIIIZ(platform.LIZ), startInstrum, serviceImpl.mIKADepend.transactFlags());
}
}
#
Native 层核心对抗逻辑剖析
将 SO 拖入 IDA Pro 进行分析，定位到导出函数Java_com_bytedance_platform_ka_ability_q_KaAbilityQ_doKaOnNative，内部调用了真实的实现逻辑do_ka。
该 SO 的核心保活流转经历了三个精妙的阶段：
1. 进程树逃逸：Double Fork 机制
为了防止系统在杀死主应用时，顺藤摸瓜将子进程“一锅端”，该组件在 Native 层实现了经典的 Double Fork 逃逸：
signal(17, (__sighandler_t)((char * ) & dword_0 + 1));
v27 = fork();
if (!v27) {
if (a3) {
v28 = _JNIEnv -> functions -> GetLongArrayElements(_JNIEnv, a3, 0 LL);
v29 = v28;
if (v28 && * v28 && v28[1]) {
v30 = ((__int64( * )(void)) * v28)();
((void(__fastcall * )(__int64,
constchar * )) v29[1])(v30, v46);
}
v31 = inited;
prctl(PR_SET_NAME, v46, 0 LL, 0 LL, 0 LL);
if (fork())
goto LABEL_42;
} else {
v31 = inited;
v29 = 0 LL;
if (fork())
goto LABEL_42;
}
// ...
LABEL_42:
_exit(0);
}
主进程调用fork()创建子进程 1。
子进程 1
立即再次调用fork()创建孙子进程（即未来的守护进程）。
子进程 1
随即调用_exit(0)主动退出。
孙子进程
由于生父死亡，瞬间变为孤儿进程，被系统的init进程（PID 为 1）接管，成功脱离原 APP 的进程组（Process Group）。
（注：与部分保活方案使用 Pipe 管道阻塞监控不同，这里脱离进程树是为了避免被 ActivityManagerService (AMS) 的ProcessRecord.kill()连坐查杀。）
2. 状态嗅探：Flock 文件锁无级监听
脱离进程组后，守护进程需要一种极低功耗的方式来感知主进程的生死。轮询/proc/目录显然太耗电且容易被查杀。
while (1) {
fd_2 = open(file, O_RDWR | O_CREAT, 432 LL);
if (fd_2 >= LOCK_SH) {
fd = fd_2;
if (flock(fd_2, (ENUM_LOCK) 6) < 0) {
v34 = close(fd);
if ( * (_DWORD * ) __errno(v34) == 11) {
stream_1 = fopen(filename, "rw");
if (stream_1) {
stream = stream_1;
remove(filename);
fclose(stream);
fflush(stream);
}
fd_1 = open(file, O_RDWR | O_CREAT, 432 LL);
if (fd_1 >= LOCK_SH)
flock(fd_1, LOCK_EX);
if (a5) {
if (gettimeofday( & tv, 0 LL))
v38 = 1;
else
v38 = 1000 * tv.tv_sec + tv.tv_usec / 0x3E8 uLL < a5;
} else {
v38 = 0;
}
v39 = access(name, F_OK);
v40 = access(name_1, F_OK);
if (!v38 && !v39 && v40) {
if (!a11)
return 0;
start_instr();
}
LABEL_42:
_exit(0);
}
} else {
flock(fd, LOCK_UN);
close(fd);
}
}
usleep(0x3D0900 u);
}
该组件巧妙地利用了 Linux 的flock(File Lock) 机制：
- 主应用在启动时，对一个特定的本地文件（如
.ka_monitor）进行加锁 (LOCK_EX)。 - 守护进程在其死循环中，尝试对同一个文件进行
flock。 - 由于互斥锁的存在，守护进程会被内核挂起阻塞（或者
usleep轮询），不占用 CPU 资源。 - 一旦主进程被系统 Kill (OOM 或用户划掉)，Linux 内核会强制回收主进程持有的所有文件句柄，该文件锁被瞬间释放。
- 守护进程的
flock立刻返回成功，从而精准捕获主进程的死亡事件。
3. 破土重生：纯 C++ 构造 Parcel 与 Binder 穿透
这是该方案最为硬核的部分。当守护进程发现主进程死亡后，如果通过常规的am start命令行去拉起，不仅速度慢，而且极易被高版本 Android 的后台拦截机制阻断。
逆向伪代码显示，该 SO 直接引入了 NDK 的AIBinderAPI，徒手拼接底层 IPC 数据包（Parcel）：
__int64 __fastcall init_instr_internal(__int64 kaAbility,constchar * s,constchar * s_1,constchar * s_2,int a5,int a6) {
unsignedint v12; // w22
unsignedint DataPosition; // w24
unsignedint DataPosition_1; // w23
if ((unsignedint) AIBinder_prepareTransaction(kaAbility, & ::DataPosition)) {
return 0;
} else {
v12 = 1;
AParcel_writeInt32();
strlen(s);
AParcel_writeString();
strlen(s_1);
AParcel_writeString();
AParcel_writeString();
AParcel_writeInt32();
AParcel_writeInt32();
DataPosition = AParcel_getDataPosition(::DataPosition);
AParcel_writeInt32();
AParcel_writeInt32();
AParcel_getDataPosition(::DataPosition);
AParcel_writeInt32();
__strlen_chk("instrumentation_type", 0x15 uLL);
AParcel_writeString();
AParcel_writeInt32();
__strlen_chk("instrumentation_type_ka", 0x18 uLL);
AParcel_writeString();
__strlen_chk("source_process", 0xF uLL);
AParcel_writeString();
AParcel_writeInt32();
strlen(s_2);
AParcel_writeString();
__strlen_chk("use_native_mode", 0x10 uLL);
AParcel_writeString();
AParcel_writeInt32();
AParcel_writeInt32();
DataPosition_1 = AParcel_getDataPosition(::DataPosition);
AParcel_setDataPosition(::DataPosition, DataPosition);
AParcel_writeInt32();
AParcel_setDataPosition(::DataPosition, DataPosition_1);
AParcel_writeStrongBinder(::DataPosition, 0 LL);
AParcel_writeStrongBinder(::DataPosition, 0 LL);
AParcel_writeInt32();
AParcel_writeString();
dword_410C0 = a5;
unk_410C4 = a6;::kaAbility = kaAbility;
byte_410D8 = 1;
}
return v12;
}
boolstart_instr(void){
return byte_410D8 && (unsignedint)AIBinder_transact(kaAbility, (unsignedint)dword_410C0, &DataPosition) == 0;
}
守护进程提前在内存中组装好了一通向ActivityManagerService发送startInstrumentation事务的 Parcel 包。触发时，直接调用AIBinder_transact将伪造的请求发给 AMS。
系统接收到请求后，会主动分配进程资源，拉起该 APP 注册的自定义Instrumentation。应用随之在callApplicationOnCreate中完成复苏。
调用链分析
守护进程通过AIBinder_transact向 AMS 发起startInstrumentation请求，其底层完整的调用链涉及客户端 Binder 代理与服务端实现两个关键环节。
客户端代理实现（android.app.IActivityManager的 Stub 代理）：
@Override// android.app.IActivityManager
public booleanstartInstrumentation(ComponentName componentName, String str, int i, Bundle bundle, IInstrumentationWatcher iInstrumentationWatcher, IUiAutomationConnection iUiAutomationConnection, int i2, String str2) throws RemoteException {
ParcelparcelObtain = Parcel.obtain(asBinder());
ParcelparcelObtain2 = Parcel.obtain();
try {
parcelObtain.writeInterfaceToken(Stub.DESCRIPTOR);
parcelObtain.writeTypedObject(componentName, 0);
parcelObtain.writeString(str);
parcelObtain.writeInt(i);
parcelObtain.writeTypedObject(bundle, 0);
parcelObtain.writeStrongInterface(iInstrumentationWatcher);
parcelObtain.writeStrongInterface(iUiAutomationConnection);
parcelObtain.writeInt(i2);
parcelObtain.writeString(str2);
this.mRemote.transact(51, parcelObtain, parcelObtain2, 0);
parcelObtain2.readException();
return parcelObtain2.readBoolean();
} finally {
parcelObtain2.recycle();
parcelObtain.recycle();
}
}
服务端真实处理（ActivityManagerService.java）：
public booleanstartInstrumentation(ComponentName className,
String profileFile, int flags, Bundle arguments,
IInstrumentationWatcher watcher, IUiAutomationConnection uiAutomationConnection,
int userId, String abiOverride) {
enforceNotIsolatedCaller("startInstrumentation");
final intcallingUid = Binder.getCallingUid();
final intcallingPid = Binder.getCallingPid();
userId = mUserController.handleIncomingUser(callingPid, callingUid,
userId, false, ALLOW_FULL_ONLY, "startInstrumentation", null);
// Refuse possible leaked file descriptors
if (arguments != null && arguments.hasFileDescriptors()) {
throw new IllegalArgumentException("File descriptors passed in Bundle");
}
final IPackageManagerpm = AppGlobals.getPackageManager();
synchronized(this) {
InstrumentationInfoii =null;
ApplicationInfoai =null;
booleannoRestart = (flags & INSTR_FLAG_NO_RESTART) != 0;
try {
ii = pm.getInstrumentationInfoAsUser(className, STOCK_PM_FLAGS, userId);
if (ii == null) {
reportStartInstrumentationFailureLocked(watcher, className,
"Unable to find instrumentation info for: " + className);
return false;
}
ai = pm.getApplicationInfo(ii.targetPackage, STOCK_PM_FLAGS, userId);
if (ai == null) {
reportStartInstrumentationFailureLocked(watcher, className,
"Unable to find instrumentation target package: " + ii.targetPackage);
return false;
}
} catch (RemoteException e) {
}
if (ii.targetPackage.equals("android")) {
if (!noRestart) {
reportStartInstrumentationFailureLocked(watcher, className,
"Cannot instrument system server without 'no-restart'");
return false;
}
} else if (!ai.hasCode()) {
reportStartInstrumentationFailureLocked(watcher, className,
"Instrumentation target has no code: " + ii.targetPackage);
return false;
}
intmatch = SIGNATURE_NO_MATCH;
try {
match = pm.checkSignatures(ii.targetPackage, ii.packageName, userId);
} catch (RemoteException e) {
}
if (match < 0 && match != PackageManager.SIGNATURE_FIRST_NOT_SIGNED) {
if (Build.IS_DEBUGGABLE && (callingUid == Process.ROOT_UID)
&& (flags & INSTR_FLAG_ALWAYS_CHECK_SIGNATURE) == 0) {
Slog.w(TAG, "Instrumentation test " + ii.packageName
+ " doesn't have a signature matching the target " + ii.targetPackage
+ ", which would not be allowed on the production Android builds");
} else {
Stringmsg ="Permission Denial: starting instrumentation "
+ className + " from pid="
+ Binder.getCallingPid()
+ ", uid=" + Binder.getCallingUid()
+ " not allowed because package " + ii.packageName
+ " does not have a signature matching the target "
+ ii.targetPackage;
reportStartInstrumentationFailureLocked(watcher, className, msg);
throw new SecurityException(msg);
}
}
if (!Build.IS_DEBUGGABLE && callingUid != ROOT_UID && callingUid != SHELL_UID
&& callingUid != SYSTEM_UID && !hasActiveInstrumentationLocked(callingPid)) {
// If it's not debug build and not called from root/shell/system uid, reject it.
final Stringmsg ="Permission Denial: instrumentation test "
+ className + " from pid=" + callingPid + ", uid=" + callingUid
+ ", pkgName=" + mInternal.getPackageNameByPid(callingPid)
+ " not allowed because it's not started from SHELL";
Slog.wtfQuiet(TAG, msg);
reportStartInstrumentationFailureLocked(watcher, className, msg);
throw new SecurityException(msg);
}
booleandisableHiddenApiChecks = ai.usesNonSdkApi()
|| (flags & INSTR_FLAG_DISABLE_HIDDEN_API_CHECKS) != 0;
booleandisableTestApiChecks = disableHiddenApiChecks
|| (flags & INSTR_FLAG_DISABLE_TEST_API_CHECKS) != 0;
if (disableHiddenApiChecks || disableTestApiChecks) {
enforceCallingPermission(android.Manifest.permission.DISABLE_HIDDEN_API_CHECKS,
"disable hidden API checks");
}
if ((flags & ActivityManager.INSTR_FLAG_INSTRUMENT_SDK_SANDBOX) != 0) {
return startInstrumentationOfSdkSandbox(
className,
profileFile,
arguments,
watcher,
uiAutomationConnection,
userId,
abiOverride,
ii,
ai,
noRestart,
disableHiddenApiChecks,
disableTestApiChecks,
(flags & ActivityManager.INSTR_FLAG_INSTRUMENT_SDK_IN_SANDBOX) != 0);
}
ActiveInstrumentationactiveInstr =new ActiveInstrumentation(this);
activeInstr.mClass = className;
StringdefProcess = ai.processName;;
if (ii.targetProcesses == null) {
activeInstr.mTargetProcesses = new String[]{ai.processName};
} else if (ii.targetProcesses.equals("*")) {
activeInstr.mTargetProcesses = new String[0];
} else {
activeInstr.mTargetProcesses = ii.targetProcesses.split(",");
defProcess = activeInstr.mTargetProcesses[0];
}
activeInstr.mTargetInfo = ai;
activeInstr.mProfileFile = profileFile;
activeInstr.mArguments = arguments;
activeInstr.mWatcher = watcher;
activeInstr.mUiAutomationConnection = uiAutomationConnection;
activeInstr.mResultClass = className;
activeInstr.mHasBackgroundActivityStartsPermission = checkPermission(
START_ACTIVITIES_FROM_BACKGROUND, callingPid, callingUid)
== PackageManager.PERMISSION_GRANTED;
activeInstr.mHasBackgroundForegroundServiceStartsPermission = checkPermission(
START_FOREGROUND_SERVICES_FROM_BACKGROUND, callingPid, callingUid)
== PackageManager.PERMISSION_GRANTED;
activeInstr.mNoRestart = noRestart;
final longorigId = Binder.clearCallingIdentity();
ProcessRecord app;
synchronized (mProcLock) {
if (noRestart) {
app = getProcessRecordLocked(ai.processName, ai.uid);
} else {
// Instrumentation can kill and relaunch even persistent processes
forceStopPackageLocked(ii.targetPackage, -1, true, false, true, true, false,
false, userId, "start instr");
// Inform usage stats to make the target package active
if (mUsageStatsService != null) {
mUsageStatsService.reportEvent(ii.targetPackage, userId,
UsageEvents.Event.SYSTEM_INTERACTION);
}
app = addAppLocked(ai, defProcess, false, disableHiddenApiChecks,
disableTestApiChecks, abiOverride, ZYGOTE_POLICY_FLAG_EMPTY);
app.mProfile.addHostingComponentType(HOSTING_COMPONENT_TYPE_INSTRUMENTATION);
}
app.setActiveInstrumentation(activeInstr);
activeInstr.mFinished = false;
activeInstr.mSourceUid = callingUid;
activeInstr.mRunningProcesses.add(app);
if (!mActiveInstrumentation.contains(activeInstr)) {
mActiveInstrumentation.add(activeInstr);
}
}
if ((flags & INSTR_FLAG_DISABLE_ISOLATED_STORAGE) != 0) {
// Allow OP_NO_ISOLATED_STORAGE app op for the package running instrumentation with
// --no-isolated-storage flag.
mAppOpsService.setMode(AppOpsManager.OP_NO_ISOLATED_STORAGE, ai.uid,
ii.packageName, AppOpsManager.MODE_ALLOWED);
}
Binder.restoreCallingIdentity(origId);
if (noRestart) {
instrumentWithoutRestart(activeInstr, ai);
}
}
return true;
}
以上两段代码完整展示了从客户端通过Binder事务码51发起startInstrumentation请求，到服务端ActivityManagerService进行权限校验、签名匹配、进程强制停止（或复用）以及ActiveInstrumentation注册的完整流程。
守护进程正是利用这一底层通道，在主进程死亡后伪造合法请求，触发 AMS 重新分配进程并拉起自定义Instrumentation，从而实现隐蔽唤醒。
总结
该厂的保活方案代表了目前 Android 端企服/核心业务模块在进程驻留方面的一流水平。“Double Fork 逃避进程树监控 + Flock 零功耗挂起 + Native Binder 直接穿透 AMS”的组合拳，巧妙绕过了 Java 层层层加码的系统限制。
面对未来 API 36 (Android 16) 更加严苛的Foreground Service限制和广播冻结机制，此类纯底层触发Instrumentation的方式是否还能如鱼得水？系统是否会在内核层面切断非信任进程的 Binder 节点访问权？这些都是非常值得持续跟进和逆向分析的研究方向。
#
看雪ID：易之生生
https://bbs.kanxue.com/user-home-920134.htm
*本文为看雪论坛精华文章，由 易之生生 原创，转载请注明来自看雪社区
往期推荐
安卓逆向基础知识之frida Hook
2025 强网杯和强网拟态部分题解
在逆向分析方面-unidbg真的适合 MCP 吗？
AI静态分析，内核模块隐藏 Frida 特征，绕过linker私有结构遍历崩溃链
某安全so库深度解析
球分享
球点赞
球在看
点击阅读原文查看更多
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：看雪学苑 易之生生 易之生生《ANDROID 黑科技 : 保活机制深度逆向》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论