Vibe Coding 从源码阅读到模块开发：基于最新版 Magisk Zygisk，移植实现一个带 WebUI、支持 Android 16 的 Zygisk 等效模块r0zygisk(一)

1. 先解决项目本身无法构建的问题。

2. 再修复生成 zip 后 SukiSU / KernelSU 无法安装的问题（缺少正确目录的 libzygisk.so ）。

3. 然后迁移 r0zygisk 的 Zygisk API，以及 Android 16 / Baklava 相关 JNI 签名。

4. 接着梳理 zygiskd 的执行链路，为后续排查 daemon / loader / companion 问题建立上下文。

5. 再重构 WebUI，并围绕真实刷入反馈连续修复 exec 、状态显示和 SukiSU 模块描述污染问题。

6. 完成第一版阶段性收敛，固化可复现的构建与刷入结果。

7. 对 Hunter 检测链路做逆向定位，明确命中点在 native 侧 checkZygisk 分支。

8. 结合迁移记录完成第二版大修：切换注入模式并统一命名为 r0z 。

目录

1. 项目背景与环境

2. 先确认最新版 Magisk Zygisk 是否已适配 Android 16

3. 借助 code-panorama + Codex 梳理 Zygisk 源码

4. 开始移植：把最新版 Zygisk 迁到 r0zygisk

5. WebUI 重构与联调记录

6. 最终状态

7. 第二版大修：通过 Hunter 的 Zygisk 检测

8. 结合 AI：使用新的注入方式完成第二版代码

9. 总结

一、项目背景与环境

• Android Gradle Plugin： 8.9.1

• Gradle Wrapper： 8.11.1

• org.gradle.java.home=/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home

1. Gradle 使用 Java 8，改为项目级固定 JDK 17。

2. Java/Gradle 访问 Google Maven TLS 失败，增加国内 Maven 镜像。

3. 中文路径导致 Gradle/JVM 编码问题，增加 UTF-8 JVM 参数。

4. 当前目录不是 Git 仓库，版本号读取失败，增加 fallback。

5. 本机缺少项目指定 NDK，改为本机已安装的 NDK 26.1.10909125 。

6. 源码包缺少 lsplt 子模块，按 .gitmodules 克隆补齐。

7. Rust 缺少 Android 交叉编译 target，用 rustup target add 安装四个目标平台。

二、先确认最新版 Magisk Zygisk 是否已适配 Android 16

三、借助 code-panorama + Codex 梳理 Zygisk 源码

3.1 分析过程

3.2 Magisk Zygisk 源码执行流程与加载过程逐段详解

1. 如果原属性为空或 "0" ，写成 libzygisk.so 。

2. 如果原本已有 native bridge，则写成 libzygisk.so 加上原值。

1. zygisk_logging() 初始化日志。

2. hook_entry() 开始 bootstrap。

3. 返回 false ，表示自己不是真正要使用的 native bridge。

1. 找到当前 JavaVM 和 JNIEnv 。

2. 用 NativeBridgeRuntimeCallbacks 枚举 com/android/internal/os/Zygote 已注册 native 方法。

3. 用 RegisterNatives 替换这些目标方法：

• nativeForkAndSpecialize

• nativeSpecializeAppProcess

• nativeForkSystemServer

1. 构造 AppSpecializeArgs_v5 或 ServerSpecializeArgs_v1 。

2. 构造栈上 ZygiskContext ，全局 g_ctx 指向它。

3. pre 阶段：

• 对 fork 型方法，Zygisk 先调用真实 fork() 。

• 子进程向 magiskd 查询当前 uid/process 的 flags。

• 如果进程不在 enforced denylist 且不是 Magisk app，则接收模块 so 的 fd。

• 使用 android_dlopen_ext(..., ANDROID_DLEXT_USE_LIBRARY_FD, ...) 从 fd 加载模块。

• 调用模块 zygisk_module_entry 、 onLoad 、 preAppSpecialize 或 preServerSpecialize 。

1. 调用原始 Zygote native specialize 函数。

2. post 阶段：

• 调用模块 postAppSpecialize 或 postServerSpecialize 。

• 根据模块选项可能 dlclose 模块。

• 恢复 Zygote JNI hook。

• 安装自卸载 hook。

1. 模块进程向 magiskd 发 ZygiskRequest::ConnectCompanion 。

2. magiskd 按 32/64 位选择或启动一个 zygiskd 。

3. zygiskd 预先加载所有模块 companion entry。

4. 每次模块请求 companion 时，magiskd 把 client fd 转交给对应 zygiskd 。

5. zygiskd 调用目标模块的 zygisk_companion_entry(client) 。

1. 清掉模块 API 表。

2. 标记 g_hook->should_unmap = true 。

3. 恢复 Zygote JNI 方法。

4. 在 libart.so 上 hook pthread_attr_destroy 。

1. 恢复早期 PLT hook。

2. 用 musttail 跳转到 dlclose(self_handle) 。

3. 避免 dlclose 返回到已经被 unmap 的 Zygisk 代码。

1. 通过 method id 获取 shorty。

2. 查询某个 class 的 native 方法数量。

3. 导出某个 class 的 native 方法表。

1. 当前 uid 必须是 root。

2. 传入 socket fd 必须有效。

1. fstat 确认是普通文件。

2. 使用 android_dlopen_ext("/jit-cache", RTLD_LAZY, &info) 从 fd 加载。

3. 查找符号 zygisk_companion_entry 。

4. 不管成功与否，都往 modules vector 放入 entry 指针，保证模块 id 与数组下标一致。

5. 关闭原 fd。

1. recv_fd(socket) 收到一个 client socket。

2. 从 client 读 module_id 。

3. 如果 id 合法且该模块有 companion entry，调用 exec_companion_entry(client, entry) 。

4. 否则关闭 client。

1. 初始化 Zygisk 日志。

2. 调用 hook_entry() 。

3. 打印加载成功。

4. 返回 false 。

1. NativeBridgeItf 被 native bridge loader 调用。

2. Zygisk 安装 PLT hook。

3. dlclose hook 捕获 native bridge 加载结束。

4. strdup("ZygoteInit") hook 捕获 JVM 即将进入 ZygoteInit 的时机。

5. Zygisk 替换 Zygote JNI native 方法。

6. specialize 后通过 pthread_attr_destroy hook 自卸载。

1. app fork 方法数组。

2. app specialize 方法数组。

3. system\_server fork 方法数组。

1. bootstrap/卸载： hook_plt 、 hook_unloader 、 restore_plt_hook 、 post_native_bridge_load 。

2. JNI 替换： hook_zygote_jni 、 restore_zygote_hook 、 hook_jni_methods 。

1. 如果 g_ctx 存在并且 g_ctx->pid >= 0 ，返回缓存 pid。

2. 否则调用原始 fork() 。

1. native bridge loader 在加载结束附近会 dlclose loader handle。

2. Zygisk 把 libnativebridge.so 的 dlclose PLT 替换成 new_dlclose 。

3. 第一次触发时 self_handle 还为空，调用 post_native_bridge_load(handle) 。

4. 返回 0，不真正关闭。

1. 后期 hook libart.so 的 pthread_attr_destroy 。

2. JVM 创建 daemon 线程时会调用它。

3. Zygisk 在主线程触发时恢复 PLT hook。

4. 如果仍允许卸载，取出 self_handle ，删除 g_hook 。

5. 使用 [[clang::musttail]] return dlclose(self_handle);，让 dlclose 直接返回给 pthread_attr_destroy 的调用者。

1. 关闭 Zygisk logd。

2. 重新初始化 Android logging。

3. 清空每个模块的 API 表，防止 post 后继续使用。

4. 设置 should_unmap = true 。

5. 恢复 Zygote JNI hook。

6. 安装 pthread_attr_destroy 卸载 hook。

1. 扫描 /proc/self/maps ，找 libart.so 的可读写段。

2. 这个 callbacks 对象位于 libart 的 writable 区域。

3. 不同 ABI 参数传递方式不同：

• arm64：查 r19-r28。

• arm32：查 r4-r10。

• x86：从 ebp 相对位置读第二参数。

• x86\_64：查 rbx/r12-r15 等 callee-saved 寄存器。

• riscv：查 callee-saved x8/x9/x18-x27。

1. 找到落在 libart writable 范围内的值，即认为是 callbacks 指针。

1. 保存 self_handle 。

2. 使用 _Unwind_Backtrace 回溯调用栈。

3. 找到帧所属库是 libnativebridge.so 的函数地址，认为它是 android::LoadNativeBridge 。

4. 在同一帧上下文中调用 find_runtime_callbacks() 。

5. 若属性 ro.dalvik.vm.native.bridge 的值长于 libzygisk.so ，说明后面拼接了真实 native bridge 名。

6. 调用真实 LoadNativeBridge(原 native bridge, callbacks) 补载它。

7. 保存 callbacks 到 runtime_callbacks 。

1. libandroid_runtime.so 的 dev/inode。

2. libnativebridge.so 的 dev/inode。

1. 查询 class 的 native 方法数量。

2. 分配数组。

3. 填充方法表。

1. 读取旧方法表。

2. 对传入的候选 methods 逐个尝试 RegisterNatives 。

3. 再读取新方法表。

4. 对每个成功替换的方法，根据 name/signature 找到旧方法指针。

5. 把旧方法指针写回 method.fnPtr 。

1. 找 JNI_GetCreatedJavaVMs 。

• 先 dlsym(RTLD_DEFAULT, ...) 。

• 找不到就扫描并 dlopen libnativehelper.so 。

1. 获取 JavaVM 。

2. 从 JavaVM 获取当前 JNIEnv 。

3. FindClass("com/android/internal/os/Zygote") 。

4. 通过 callbacks 获取 Zygote 已注册 native 方法表。

5. 遍历方法名：

• 遇到 nativeForkAndSpecialize ，用 fork_app_methods 替换。

• 遇到 nativeSpecializeAppProcess ，用 specialize_app_methods 替换。

• 遇到 nativeForkSystemServer ，用 fork_server_methods 替换。

1. 如果任何已存在目标方法替换失败，恢复已替换的方法，并清空对应数组，避免半 hook 状态。

1. AppSpecializeArgs_v2 = AppSpecializeArgs_v1 。

2. AppSpecializeArgs_v4 = AppSpecializeArgs_v3 。

3. module_abi_v2/v3/v4/v5 都等同于 v1 布局。

4. api_abi_v3 = api_abi_v2 ， api_abi_v5 = api_abi_v4 。

1. impl 指向 ZygiskModule 。

2. registerModule 用于模块注册自身 ABI。

1. onLoad() 调用模块入口。

2. pre/post App/ServerSpecialize() 调模块回调。

3. valid() 验证模块 ABI 是否完整。

4. connectCompanion() 请求 root companion。

5. getModuleDir() 从 magiskd 获取模块目录 fd。

6. setOption() 处理模块选项。

7. tryUnload() 根据选项 dlclose 模块。

1. run_modules_pre/post() ：加载和执行模块。

2. fork/app/server/nativeXXX_pre/post() ：各类 JNI 包装流程。

3. get_module_info() ：向 magiskd 查询 flags 和模块 fd。

4. sanitize_fds() ：关闭不允许保留的 fd。

5. exempt_fd() ：实现模块 fd 豁免 API。

6. plt_hook_*() ：兼容旧版 regex PLT hook API。

1. 空指针检查。

2. 读取模块声明的 api_version 。

3. 如果版本大于当前 ZYGISK_API_VERSION ，拒绝。

4. 保存模块 ABI 指针到 mod 。

5. 按版本填充 API 函数指针。

1. hookJniNativeMethods 指向全局实现。

2. 旧版 pltHookRegister/Exclude/Commit 走 g_ctx 的 regex 兼容层。

3. connectCompanion 、 setOption 转到当前 ZygiskModule 。

1. getModuleDir 。

2. getFlags 。

1. pltHookRegister(dev, inode, ...) 直接走 lsplt。

2. exemptFd 转给 g_ctx->exempt_fd 。

1. 已注册 ABI。

2. API 版本在 1-5。

3. impl 与四个 pre/post 回调指针都不为空。

1. FORCE_DENYLIST_UNMOUNT ：设置 DO_REVERT_UNMOUNT 。

2. DLCLOSE_MODULE_LIBRARY ：post 后允许 dlclose 模块库。

1. API v1/v2：构造 AppSpecializeArgs_v1 兼容对象。

2. API v3/v4/v5：直接传 AppSpecializeArgs_v5 指针。

1. regex。

2. symbol。

3. callback。

4. backup 指针。

1. 只处理 offset 为 0、private、可读的映射。

2. 对每条注册 regex 匹配路径。

3. 再检查 exclude 规则。

4. 未被排除就 lsplt::RegisterHook(map.dev, map.inode, symbol, callback, backup) 。

1. 写 uid。

2. 写进程名。

3. 写 ABI 位数。

4. 读取 info_flags 。

5. 如果 zygisk_should_load_module(info_flags) 为真，接收模块 fd 列表。

1. 如果支持 fds_to_ignore ，把模块豁免的 fd 合并到 Zygote 的忽略列表。

2. 把已有 fds_to_ignore 中的 fd 标记为 allowed。

3. 创建新 jintArray，把原 fd 与 exempted fd 合并。

4. 扫描 /proc/self/fd 。

5. 不在 allowed_fds 中且不是扫描目录 fd 的，全部关闭。

1. 如果已经 post specialize，或者当前跳过关闭 log pipe，返回 true。

2. 如果当前流程不能豁免 fd，返回 false。

3. 否则加入 exempted_fds 。

1. block SIGCHLD 。

2. 调用原始 old_fork() 。

3. 父进程直接返回。

4. 子进程扫描 /proc/self/fd ，记录当前允许保留的 fd。

5. 目录 fd 标记为不允许。

6. Zygisk logd fd 单独标记为不允许。

1. fd 必须是普通文件。

2. 使用 android_dlopen_ext 从 fd 加载模块。

3. 查找 zygisk_module_entry 。

4. 成功则构造 ZygiskModule(i, h, e) 。

5. system\_server 中 dlopen 失败会记录 warning，并把 fd 标成 -1，稍后上报失败模块。

1. 调用 onLoad(env) 。

2. 模块通过 API 表注册自身 ABI。

3. valid() 通过则保留，否则删除。

1. app 流程调用 preAppSpecialize(args.app) 。

2. system\_server 流程调用 preServerSpecialize(args.server) 。

1. app 调 postAppSpecialize 。

2. system\_server 调 postServerSpecialize 。

3. 根据模块选项 tryUnload() 。

1. 设置 APP_SPECIALIZE 。

2. 向 magiskd 查询进程 flags 和模块 fd。

3. 如果进程在 enforced denylist，设置 DO_REVERT_UNMOUNT ，不加载模块。

4. 否则加载并运行模块 pre。

1. 调模块 post。

2. 如果当前进程是 Magisk app，设置环境变量 ZYGISK_ENABLED=1 。

3. 释放 nice_name 的 UTF chars。

1. 用 uid 1000 和进程名 system_server 查询 magiskd。

2. 如果没有模块，写回 0。

3. 如果有模块，加载并运行 pre。

4. 收集加载失败的模块 id，写回 magiskd。magiskd 会在对应模块目录下创建 zygisk/unloaded 标记。

1. 从 nice_name 获取进程名。

2. 设置 SKIP_CLOSE_LOG_PIPE 。

3. 调 app pre。

1. 调 app post。

1. 设置 SERVER_FORK_AND_SPECIALIZE 。

2. 进程名固定为 system_server 。

3. 调 fork_pre() 。

4. 子进程执行 server pre。

5. 清理 fd。

1. 子进程执行 server post。

2. 父子都执行 fork_post() 解锁 SIGCHLD。

1. 从 nice_name 获取 app 进程名。

2. 设置 APP_FORK_AND_SPECIALIZE 。

3. 先真实 fork。

4. 子进程执行 app pre。

5. 清理 fd。

1. 子进程执行 app post。

2. 父子都执行 fork_post() 。

1. Android app 进程从 Zygote fork。

2. fork 后执行 specialize，把进程放入应用沙箱。

3. Zygisk 允许模块在 app/system\_server specialize 前后运行代码。

4. 模块代码运行在目标 app/system\_server 进程，不运行在长期的 Zygote daemon 中。

5. 需要 root 能力时，使用 companion handler。

1. connectCompanion() ：连接 root companion 进程。

2. getModuleDir() ：获取模块根目录 fd。

3. setOption() ：设置模块选项。

4. getFlags() ：获取当前进程状态。

5. exemptFd() ：让指定 fd 不被 Zygote 自动关闭。

6. hookJniNativeMethods() ：替换某个 Java class 已注册 native 方法。

7. pltHookRegister() ：按 dev/inode/symbol 注册 PLT hook。

8. pltHookCommit() ：提交 PLT hook。

1. 创建静态 Api 。

2. 绑定传入 table。

3. 创建静态模块对象 T module 。

4. 创建静态 ABI。

5. 调 table->registerModule 注册。

6. 成功后调用模块 onLoad(&api, env) 。

1. AOSP Android L/O/P/R/U/B 等版本变化。

2. Samsung M/N/O/P 变体。

3. Nubia U 变体。

1. name 固定为 nativeForkAndSpecialize 。

2. signature 是对应 Android/OEM 的 JNI 签名。

3. fnPtr 是一个静态 lambda。

1. 根据参数构造 AppSpecializeArgs_v5 args(...) 。

2. 对当前签名存在的可选参数，把 args.xxx = &xxx 。

3. 构造 ZygiskContext ctx(env, &args) 。

4. 调 ctx.nativeForkAndSpecialize_pre() 。

5. 通过 get_defs()->fork_app_methods[index].fnPtr 调回原始 JNI native 函数。

6. 调 ctx.nativeForkAndSpecialize_post() 。

7. 返回 ctx.pid 。

1. AOSP 标准签名。

2. Samsung Q 变体。

1. 构造 ServerSpecializeArgs_v1 。

2. 构造 ZygiskContext 。

3. ctx.nativeForkSystemServer_pre() 。

4. 调原始 nativeForkSystemServer 。

5. ctx.nativeForkSystemServer_post() 。

6. 返回 ctx.pid 。

1. primitive 数组如 jintArray 。

2. 非 primitive 数组统一为 jobjectArray 。

1. C++ 参数列表。

2. C++ 函数指针类型。

3. lambda 签名。

4. JNI signature 字符串。

1. 初始化 args。

2. 设置可选参数指针。

3. 构造 ZygiskContext 。

4. 调 pre。

5. 调原始函数。

6. 调 post。

7. 返回 ctx.pid 。

1. fas_* ：fork app。

2. spec_* ：specialize app。

3. server_* ：fork system\_server。

1. 方法名。

2. JNI 签名。

3. 包装 lambda。

1. 文件头。

2. 前置声明。

3. JniHookDefinitions struct。

4. 三组方法数组。

1. 不是 enforced denylist 命中。

2. 不是 Magisk app。

1. 清除 remote socket 的 close-on-exec，让 fd 在 exec 后仍然有效。

2. 64 位 magiskd 中，如果目标是 32 位 companion，执行 magisk32 ；否则执行 magisk 。

3. 构造执行路径： get_magisk_tmp()/magisk 或 magisk32 。

4. 执行参数：

1. 从 client 读 ABI 位数。

2. 选择 32 位或 64 位 zygiskd socket。

3. 如果已有 socket，用 poll 检查是否仍有效。

4. 有效则直接把 client fd 发给 zygiskd。

5. 无效或不存在，则创建 socket pair。

6. fork 子进程执行 exec_zygiskd 。

7. 把当前 ABI 的所有模块 fd 发送给新 zygiskd。

8. 等 zygiskd ack。

9. 把当前 client fd 发给 zygiskd。

10. 保存 local socket 供复用。

1. restore 为 true 时重置 crash 计数并恢复属性。

2. restore 为 false 时清空 companion sockets，增加 crash 计数。

3. crash 超过 3 次，认为 zygote 崩溃过多，回滚 native bridge 属性。

1. 空或 "0" ： lib_name = "libzygisk.so" 。

2. 非空： lib_name = "libzygisk.so" + 原值 。

1. GetInfo ：查询进程 flags 和模块 fd。

2. ConnectCompanion ：启动/复用 zygiskd，转发 client fd。

3. GetModDir ：发送模块目录 fd。

1. 64 位取 m.z64 。

2. 32 位取 m.z32 。

3. 无效 fd 用 STDOUT_FILENO 占位，因为通过 socket 发送 fd 时必须是有效 fd；magiskd 中 stdout 始终是 /dev/null ，zygiskd/目标进程会把它视为无效模块。

1. uid。

2. process 名。

3. ABI 位数。

1. update_deny_flags 写入 denylist/enforced 信息。

2. 如果 uid 是当前用户的 Magisk manager uid，设置 ProcessIsMagiskApp 。

3. 如果 uid 已授权 root，设置 ProcessGrantedRoot 。

1. 先写 flags 给客户端。

2. 如果允许加载模块，发送模块 fd。

3. 如果不是 system\_server，结束。

4. 如果是 system\_server，继续读取 C++ 写回的 failed module ids。

5. 对失败模块创建 zygisk/unloaded 标记文件。

1. client ：目标进程与 companion handler 通信的 socket fd。

2. companion_handler ：模块导出的 zygisk_companion_entry 。

1. 把任务提交到 ThreadPool::exec_task 。

2. 调用前用 fd_get_attr(client) 记录 fd 对应文件的 dev/inode。

3. 执行模块 companion handler。

4. handler 返回后再次检查 fd。

5. 如果 fd 仍是同一个文件，关闭它。

四、开始移植：把最新版 Zygisk 迁到 r0zygisk

1. 环境检测

4.1 Zygisk 迁移改动

• 使用 Magisk-master/native/src/core/zygisk/api.hpp 覆盖 r0zygisk 旧版公开 API 头文件。

• ZYGISK_API_VERSION 从旧版本升级为：

• 新编译的 Zygisk 模块会按 API v5 注册。

• r0zygisk loader 需要能识别并加载 API v5 模块。

• 增加 AppSpecializeArgs_v5 。

• AppSpecializeArgs_v5 继承 AppSpecializeArgs_v3 ，并单独持有：

• 增加 API v5 兼容别名：

• call_app 增加 case 5 ，让 API v5 模块按新版参数传入。

• 兼容 Magisk 最新 Zygisk API v5。

• 保留对旧 API v1-v4 模块的兼容。

• ZygiskContext 中 app 参数指针从：

• ZygiskModule::valid() 接受 API v5：

• r0zygisk 的模块加载逻辑可以接受 v5 模块。

• Zygote JNI wrapper 传入的是新版 specialize 参数对象。

• wrapper 初始化参数从 AppSpecializeArgs_v3 改为 AppSpecializeArgs_v5 。

• 增加 Magisk 最新 Zygisk 中已有的新参数：

• 增加新的 Zygote JNI 签名候选：

• 重新生成：

• nativeForkAndSpecialize_b 是 Android 16 / Baklava 相关适配的重要线索。

• 新增的 OEM / XR 签名提高了对新系统和厂商 ROM 的兼容范围。

4.2 版本与输出文件名改动

• 项目从自己的第一版开始。

• versionCode 固定为 1 。

• 不再因为目录不是 git 仓库而输出 unknown 。

• 最终文件名符合要求。

4.3 构建验证

4.4 本次修改过的主要文件

4.5 当前阶段状态

• Zygisk API v5 迁移。

• Android 16 / Baklava 相关 JNI 签名候选加入。

• r0zygisk 自有 loader / zygiskd / ptrace 架构保留。

• 输出文件名改为 r0zygisk-v1.0.0-1-release.zip 。

• 完整打包通过。

五、WebUI 重构与联调记录

5.1 第一阶段：调研官方 ZygiskNext WebUI 功能

• 状态页

• 基本信息

• 设置页

• Root 实现显示

• Zygote monitor 状态

• Zygisk module 状态

• ZN Module 状态

• KernelSU / Magisk / APatch 排除列表策略说明

• 日志写入 dmesg

• 非 root 应用作为排除列表

• 强制排除列表

• 匿名内存加载

• Zygisk Next linker

• Zygote 注入状态说明

• 模块问题提示

• 状态仪表盘

• 追踪器控制按钮

• 已发现 Zygisk 模块列表

• 每个按钮的说明

• 原始诊断输出

• ZygiskNext 参考功能地图，并标注当前 fork 是否接入

5.2 第二阶段：重做 WebUI

• module/src/webroot/index.html

• module/src/webroot/styles.css

• module/src/webroot/app.js

• 顶部标题： Zygisk 控制台

• 总状态评分： 0/3 到 3/3

• 三个状态卡片：

• Daemon

• Zygote

• Root

• 三个操作按钮：

• 启动追踪

• 停止追踪

• 退出监控

• 已发现的 Zygisk 模块列表

• 操作说明

• 原始诊断信息

5.3 第三阶段：刷入后第一次反馈

• 当前状态显示追踪为运行

• Daemon 为运行

• 进程表未发现 zygisk

• Zygote 未确认

• Root 未识别

• 无法读取 module.prop

• 三个按钮点击没有任何反应

1. 模块路径被硬编码为：

1. WebUI 的 exec 调用方式可能不兼容当前管理器。

5.4 第四阶段：删除参考块，并继续处理 exec 超时

• 不再显示 ZygiskNext 参考 这个块

• 诊断信息显示：

• 页面上显示：

• 无法连接执行接口

• Daemon、Zygote、Root 都等待刷新

• 按钮仍然没有结果

1. bridge.exec(command, "{}", callbackName)

2. bridge.exec(command, callbackName)

3. bridge.exec(command)

5.5 第五阶段：SukiSU 模块列表显示一长串 tracing 状态

• monitor: tracing ：追踪器正在运行

• zygote64: injected ：64 位 zygote 已注入

• daemon64: running ：64 位 daemon 正在运行

• Root: KernelSU ：当前 root 实现识别为 KernelSU 系

• module(3) ：发现了 3 个 Zygisk 模块

5.6 第六阶段：迁移运行状态到 status.json

• SukiSU 模块列表保持干净描述

• 运行状态不要再塞进 module.prop description

• 状态写入独立文件，如：

1. 删除 pre_section 、 post_section 的描述拼接逻辑。

2. 不再生成临时 module.prop 并 bind mount 回模块目录。

3. 新增：

1. prepare_environment() 改为：

1. updateStatus() 写 JSON：

1. 状态文本里的表情也移除，改成纯文本：

• 优先解析 status.json

• 如果旧版本还在运行，没有 status.json ，则回退解析 module.prop description

5.7 第七阶段：WebUI Zygote 红点，状态只有 2/3

• SukiSU 模块描述已经干净

• 但 WebUI 中 ZYGOTE 红点

• 显示“未确认”

• 上方状态只有 2/3

• 正常应该是 3/3

六、最终状态

WebUI

• 显示总评分 0/3 到 3/3

• 显示 monitor / daemon / zygote / root

• 从 status.json 读取结构化状态

• 回退兼容旧 description 状态

• 自动定位真实模块目录

• 显示已安装 Zygisk 模块列表

• 支持追踪器操作：

• 启动追踪

• 停止追踪

• 退出监控

• 诊断区显示：

• module.dir

• module.prop

• status.json

• processes

• modules

Native Monitor

• 不再把状态写入 module.prop description

• 不再污染 SukiSU 模块列表

• 状态写入：

模块描述

七、第二版大修：通过 Hunter 的 Zygisk 检测

7.1 先定位检测触发点：检测发生在 Java 层还是 Native 层

1. smali 层能看到 NativeEngine.checkZygisk() 的声明与调用。

2. 关键日志模板不在业务 smali 里，而在 lib/arm64-v8a/libhunter.so 。

7.2 从上层调用链定位触发入口

1. ZhenxiServerIpc 路径：最终进入 P1(6) ，再走到 NativeEngine.checkZygisk() 。

2. ZhenxiServerTwinIpc 路径：最终进入 P1(8) ，同样会调用 NativeEngine.checkZygisk() 。

7.3 检测核心：libhunter.so 的真实实现

1. 在 so 里抽到关键字符串：

• Ptrace Check Zygisk

• find zygisk detected ,zygote root pid

• /system/lib64/libzygisk_loader.so

• /system/lib64/libzygisk.so

• /sbin/.magisk/modules/zygisk_lsposed

1. 定位 JNI_OnLoad 的动态注册逻辑，确认 checkZygisk 来自 RegisterNatives ，不是静态导出。

2. 还原 JNINativeMethod 表后，锁定 checkZygisk 对应 native 函数入口： libhunter.so@0x2a93f8 。

7.4 检测逻辑拆解

1. 先构造标题 Ptrace Check Zygisk 。

2. 进行 pid/zygote 关系相关检查；命中后拼接 find zygisk detected ,zygote root pid ...。

3. 进行路径/特征串检查，涉及 libzygisk_loader.so 、 libzygisk.so 、 zygisk_lsposed 等标识。

4. 把命中结果封装成返回对象（ ListItemBean ）上报到上层。

八、结合 AI：使用新的注入方式完成第二版代码

8.1 第一部分：修改注入方式（从 ptrace 到 native bridge）

• 通过 r0z-trace32/64 常驻进程监控 zygote/app_process

• 命中后注入 libr0z.so

• 运行过程中会留下较明显的 ptrace 与进程关系特征

1. 新增并接入： libzn_loader.so 、 libpayload.so 、 libzygisk.so 。

1. entry.cpp 增加 zygisk_entry ，构建产物从 libr0z.so + libr0z_ptrace.so 切换为三段式库输出。

1. 模块脚本不再依赖 r0z-trace ，改为 system.prop 设置 ro.dalvik.vm.native.bridge=libzn_loader.so ，并在 post-fs-data.sh/service.sh 启动 daemon。

1. 库安装路径统一为 $MODPATH/system/lib 与 $MODPATH/system/lib64 。

1. daemon 状态链路改造为本地 status.json ，移除对旧 init_monitor socket 的硬依赖。

8.2 第二部分：统一名称为 r0z

九、总结