PayPal 闪退复盘：从一个设备号缺口追到 App Zygote 的 SELinux 错误码

PayPal 以前能正常运行。当时主要依靠 Magisk 的 Root 隐藏和隐藏应用列表，后来却变成了打开即退出。

这类问题最容易把人带进配置试错：再加一个隐藏模块，扩大一次作用域，换一个版本，重启看看。每一步都可能改变环境，却未必增加对故障的理解。这次排障的转折，是先停下修改，把问题收缩到一句可以验证的话：当前这个版本的 PayPal，到底读到了什么，又是哪一个返回值让它决定退出？

最终定位到两个独立的本地检测信号：一个来自 Magisk 早期启动对匿名文件系统设备号分配顺序的影响，另一个来自 App Zygote 请求切换 SELinux 标签时的错误码差异。两处修改合并后，PayPal 进入系统指纹认证窗口；完成验证后，可以正常进入并停留。整个修复没有新增常驻模块，没有降级 PayPal，也没有清除其数据。

这篇文章记录的不只有成功路径。中间曾因 ART 入口探针测试出现黑屏，也曾把模块间符号依赖误报成内核缺失符号。把这些失误与证据边界一起留下，才方便下一次少走弯路。

先界定问题：现在为什么失败，与以前为什么能用

本次环境是 Xiaomi 13（fuxi）、Android 16 / SDK 36、内核 5.15.207-g03e6e48a5b4e、Magisk 30.7、ZygiskNext 1.5.0，以及 PayPal 10.12.0。测试开始时还存在先前工作的 Vector、NoHello 和 iFAST 兼容组件；“以前主要使用 Magisk 和隐藏应用列表”是历史背景，不能当作当前环境只有这两个组件。

清理本任务诊断 APK 后，PayPal 仍然冷启动退出。崩溃日志中的关键异常结构是：

RootDetectionSecurityException: Security policy violation: s=root

它将排查方向指向应用的 Root 检测决策。它没有告诉我们具体命中了哪项，也不能证明所有带有相同异常的设备都需要同一种修复。

“之前可以用”则是另一类证据。缺少当时的文件系统设备号、策略和真实检测输入，就不能仅凭更新日期断言是某次 PayPal、Magisk 或内核更新引入了故障。这次建立的是当前失败的可复核因果链；历史上的首次触发因素仍未确定。

把总结果拆成可观察的检测项

运行时分析把一条路径定位到检测类 o.APMf 对 native 方法 o.endFlow.a([[Ljava/lang/String;)J 的调用。在这份 PayPal 构建中，它对应 libob98.so 的偏移 0x6e628。这些名称和偏移只用于描述当前样本，不能硬套到其他版本。

这个返回值还经过调用方的整数运算，原始数值并非直接的布尔值。按实际调用方解码后，设备上得到 1，该分支使用 0x11c 更新标记。另一个函数返回的 -1 则属于控制流状态，不能看到负数就把它当成 Root 阳性。

接下来追输入。该函数直接执行 AArch64 newfstatat，读取四个路径的 stat 数据，并使用内核 release、SDK 等输入：

路径	当时实测的 st_dev
/dev	17
/dev/pts	18
/proc	19
/sys	21

这里的数字属于文件系统的设备标识，不是磁盘分区编号，也不是 mountinfo 的 mount ID。值得怀疑的是序列中的缺口。PID 1 的挂载信息显示，0:20 对应保留在 /debug_ramdisk 上、来源为 magisk 的 tmpfs。

应用看不到那条挂载记录，并不意味着内核对其他文件系统已经分配好的设备号也随之改变。隐藏名字和改变底层分配历史是两个问题。这也解释了为什么继续编辑隐藏应用列表没有直接作用到这个输入。

第一条因果证据：只改一个字段的离线 A/B/A

“有一个可疑数字”还不足以刷启动镜像。我先在电脑上用 Unicorn 执行捕获的原始 native 函数，使用设备上采集的四份完整 stat 缓冲区，固定 SDK、内核 release 和其余字段，只修改 /sys 的 st_dev：

实验	唯一变化	检测返回解码
A	/sys st_dev = 21，原输入	1
B	/sys st_dev = 20	0
A 恢复	/sys st_dev = 21	1

这个 A/B/A 将结论推进了一步：在该函数和已捕获输入下，设备号差异足以翻转这项检测。

它仍然只是离线实验。JNI 对象管理、部分 libc 操作和系统环境使用了明确的模拟，未知调用会中止；它不等于整机 A/B/A，更不等于 PayPal 已修好。将“某项通过”和“应用恢复”写成同一个状态，会直接误导后续工作。

第一处修复：调整产生差异的启动顺序

已有证据将修改点指向 Magisk 第一阶段启动。沿准确版本的 first_stage 和 prepare_data 源码核对实际路径，再使用带临时日志的 magiskinit 记录挂载分配与交接过程。

本机的诊断结果如下。前两行描述 Magisk 第一阶段的临时环境，最后一行才是 Android 接管后的最终结果，不能把两组 /proc、/sys 混为一谈。

项目	原始顺序	修正后的顺序
早期临时 /proc、/sys	18、19	18、19
提前补齐的临时 /dev、/dev/pts	无	20、21，交接前释放
保留的 Magisk tmpfs	20	22
Android 最终 /dev、/dev/pts、/proc、/sys	17、18、19、21	17、18、19、20

修正做在现有 magiskinit 中：在 prepare_data() 分配保留的 tmpfs 之前，先创建临时 /dev 和 /dev/pts，并把它们登记到已有的逆序卸载列表。交给原始 Android init 之前，这些临时挂载被释放，Android 随后重新建立自己的文件系统。

入口变化很小：

fn first_stage(&mut self) {
    info!("First Stage Init");
    self.prepare_first_stage_devices().log_ok();
    self.prepare_data();
    // 原有后续流程
}

完整 helper 与修改见实际使用的 Magisk 补丁。它没有写死 20 或 21，没有修改 stat 返回，也没有加入 PayPal 专属逻辑；它改变了持久分配与临时分配交错的顺序。这些数字是本机构建的结果，不能当作所有 Android 设备都应满足的常量。

首次实机候选启动正常，最终设备号符合预测，真实 endFlow 检测解码也从 1 变为 0。PayPal 仍然抛出相同的 Root 检测异常。 至此可以确认修掉了一个信号，同时必须继续寻找剩余条件。

一次黑屏：观测手段也会改变系统

为确定剩余分支，排查曾尝试在 ART 反射调用入口捕获检测器的固定参数。ArtMethod::Invoke 入口没有取得目标事件，随后测试 art_quick_invoke_static_stub 的 uprobe 时，启动应用后 ADB 断开，手机黑屏或画面卡住。

事后没有得到足以解释机制的 panic 日志，恢复后的 pstore 也是空的。能确定的是异常发生在这次探针测试期间；不能据此证明 Magisk 挂载修改导致黑屏，也不能把具体的 ART、CFI 或内核机制写成已证实原因。

处置是停止探测，人工进入 Fastboot，刷回已验证的原始 init_boot，再核对启动镜像、Root 和配置，并由实际操作者确认手机恢复可用。该 ART 探针脚本随后加入运行时禁用保护，后续不再复用。

这个教训改变了观测方案：系统核心调用入口的影响面太大，不能因为探针“只读”就默认无害。后续转向范围明确的系统调用 tracepoint、独立复现 APK，并让退出机制独立于主机连接。黑屏发生后首先要恢复一个可信基线；在不确定状态上继续叠加修改，会同时丢失可用性和因果判断。

第二条证据：真正执行探测的是 App Zygote

静态分析发现另一条路径与隔离服务、SELinux 标签有关。容易犯的错误是直接把它归为 isolated_app 的行为，或者在 root shell 中试几个标签就下结论。

真实进程轨迹给出的答案更具体：三个写入发生在 App Zygote，目标是 /proc/thread-self/attr/current。采集的调用序列是打开、写入、关闭，写入字节没有尾随 NUL：

写入内容	字节数	原内核的 write 返回	对应 errno
u:r:kp:s0	9	-22	EINVAL
u:object_r:ksu_file:s0	22	-22	EINVAL
u:r:magisk:s0	13	-1	EPERM

注意记号：表中负数是内核系统调用返回；后面的 APK 测试记录正数 errno，-22 和 22 是同一失败结果在不同层的表示。

这次使用 eBPF 的 sys_enter / sys_exit tracepoint，只观察目标应用 UID 与受限的具名子进程，以及两个完整匹配路径：

/proc/thread-self/attr/current
/sys/fs/selinux/context

它按线程配对入口和出口，按进程与 fd 关联后续读写，保留输入长度和返回值。第一条目标调用后的采集窗口为 15 秒；设备上另设 35 秒清理看门狗；主控脚本用 finally 清理自己的 pin 和 map。采集只观察数据，不覆盖返回值，也不挂 ART 探针。此次基线共 39 条相关事件，导出条数与计数一致，未触及设定的截断上限。

这些限制降低了本次观测的影响面，但不是“eBPF 永远安全”的保证。未来复用时还要重新核对目标 UID、进程名、fd 生命周期、事件上限和路径；该窄范围脚本不能直接冒充通用跟踪器。

另一个路径 /sys/fs/selinux/context 在这段轨迹中用于 Android 正常上下文设置。三个检测写入命中的是 procfs 接口，因此不能把针对前一个接口的配置当成已命中问题的修复。

独立 APK：复现相同字节，也复现相同执行环境

为避免从 shell 权限推测 App 行为，构建了一个没有申请权限、没有网络访问、没有 Xposed 注入的独立 APK。它使用 zygotePreloadName，并通过 isolatedProcess=true、useAppZygote=true 的服务建立真实 App Zygote 与隔离子进程。Android 服务配置文档说明了这些进程选项的用途。

同一组输入分别在三个环境中执行，结果很有区分度：

实际环境	原内核 errno	修正内核 errno
普通应用 untrusted_app	13、13、13	13、13、13
app_zygote	22、22、1	22、22、22
子进程 isolated_app	13、13、13	13、13、13

若只在普通应用或隔离子进程里测试，会漏掉真正有区分度的那一行。App Zygote 为了把子进程特化成隔离进程，拥有与最终子进程不同的权限路径。UID、SELinux 域、线程状态和启动阶段都属于实验输入。

这里也发生过一个小偏差：诊断初版多写了尾随 NUL。虽然它也得到同样的结果，复核真实调用长度后，仍修正为完全相同的字节串，重新构建和实测，并单独保留初版记录。“结果恰好相同”不能替代忠实复现。

静态判定逻辑进一步解释了差异：在相关分支中，EINVAL 不加入命中标签列表，而 EPERM 会加入；列表非空且前面的服务状态正常时，代码可以生成 0x122。这里没有直接捕获真实应用最终聚合上报的编号。证据是实际系统调用输入、独立 APK 复现、静态分支，以及后来的实机成功，不能把推导编号伪装成运行时读数。

第二处修复：保留拒绝，只统一指定路径的错误码

准确内核源码中的 selinux_setprocattr()提供了解释：初始权限检查、目标上下文解析、后续转换检查发生在不同位置。不存在的目标标签可在解析时返回 EINVAL；存在的标签可能通过解析，再在后续权限或转换条件处被拒绝。相同的“不能切换”因此暴露出不同错误。

这不等于应用成功获得了 Root 标签，而是失败路径提供了标签存在性的线索。App Zygote 的类似探测也有 DirtySepolicy 这样的独立公开实现；它是机制参考，本次 PayPal 的事实仍以实机采集为准。

配置方案没有提供已验证的解决办法：删掉 App Zygote 的 setcurrent 会损害正常隔离进程转换；只限制最终 isolated_app 又晚于实际探测。持续改 Root 域名还会增加现有组件的兼容维护。于是修改范围扩大到现有内核，并在明确允许内核评审与测试后执行。

实际补丁在 abort_change: 中调用 abort_creds(new) 之后增加 20 行。核心代码如下，完整上下文见内核补丁：

if (!strcmp(name, "current") &&
    (error == -EPERM || error == -EACCES)) {
    char *context = NULL;
    u32 context_len = 0;
    static const char prefix[] = "u:r:app_zygote:";

    if (!security_sid_to_context(&selinux_state, mysid,
                                &context, &context_len)) {
        if (context_len >= sizeof(prefix) - 1 &&
            !memcmp(context, prefix, sizeof(prefix) - 1))
            error = -EINVAL;
        kfree(context);
    }
}

它没有让被拒绝的操作成功，没有新增 allow，也没有启用 permissive。原有检查与审计继续执行，成功转换仍沿原路径返回。初始 setcurrent 检查等提前返回路径不经过这里，其他调用者、其他属性和不匹配的错误也保留原结果。

但保留权限检查不等于完全没有行为变化：这会改变所有匹配 App Zygote 调用者在指定失败路径上看到的 errno，可能影响依赖错误码的代码。补丁不匹配 PayPal 包名、UID 或某个 Root 标签；它也没有声称隐藏全部 SELinux 查询方式。这是一处有明确边界的本地兼容修改。

编译成功之后，还要跨过模块兼容性

内核只改了 20 行，启动失败的风险却可能来自完全无关的构建输入。此次采用准确源码提交、实机运行配置，并核对编译器 LLVM 源码版本：

构建输入	本次记录
内核基线	03e6e48a5b4ed606dfdd48bc782a57f9c778938b
Magisk 基线	e8a58776f1d7bdf852072ad0baa6eceb9a1e4aac
LLVM 源码版本	5e96669f06077099aa41290cdb4c5e6fa0f59349
编译器	Clang 21.0.0；源码版本相同，发行构建描述不同
内核关键选项	Full LTO、CFI 保留；CFI permissive 未启用
模块	保留原 vendor 模块及原内核 release 字符串

相同 LLVM 源码提交不等于编译器二进制逐字节相同，更不保证内核产物相同。这里仍需依靠配置差异、符号 CRC、证书与实机启动验证，不能用版本号替代兼容检查。

模块校验还有两道容易漏的关。

第一道是原模块的信任信息。 从原内核提取公开的模块验签证书，让新内核保留同一证书，并验证生成的证书逐字节一致。没有使用原私钥，也没有重新签发全部 vendor 模块。运行配置本来就不是强制拒绝所有未签名模块，修复保留了该设置，不能把这次工作描述成额外开启了签名强制校验。内核模块签名文档可用于理解公钥、签名和配置的关系。

第二道是完整的符号提供关系。 一开始只拿 vendor 模块的导入符号对比候选 vmlinux，误报了缺失。部分符号本来就由另一个 vendor 模块提供。补上原模块 ELF 的 __ksymtab_*、__crc_* 提供关系后，400 个原模块文件的 4543 项导入全部得到匹配：2984 项由内核提供，1559 项由其他原模块提供，CRC 无不匹配。

最终实际启动加载了 388 个模块，与原基线集合一致。400 是磁盘上的模块文件数，388 是这次运行加载数，二者不是矛盾。

此外，用原函数和修改后的真实函数体、配合内核 API 替身，运行了 15 项带 AddressSanitizer / UndefinedBehaviorSanitizer 的宿主测试，检查拒绝分支、允许的隔离转换、其他调用者、相似前缀、其他属性、分配失败和凭据提交／回滚。它们验证控制流，不能替代实机策略、模块 ABI 或启动测试。

实机验证分两步，避免同时移动所有变量

先用 Fastboot 临时启动候选内核，保留原 Magisk 镜像，并重新读取分区确认没有改写原 boot 和 init_boot。系统启动、Root、HMA、Enforcing 和原模块集合正常。独立 APK 得到预期的三组结果，真实 PayPal 的限时 trace 也确认三次写入返回均为 -22。

此时 PayPal 仍退出。由于原 Magisk 的挂载顺序尚未修正，这个结果不能否定内核已经消除了第二项差异。

随后才把两处已验证修改合并：安装候选内核，以及移除了临时诊断日志的 magiskinit。打包时核对 boot 头部和无关内容；本机 boot 的 ramdisk 为空，内核替换后保持镜像结构。init_boot 的 ramdisk 条目中只有 init 内容变化，其他条目的内容和元数据保持一致，vendor_boot 保持原样。

以下表格刻意区分每个阶段实际取得的证据：

阶段	设备号相关证据	SELinux 相关证据	PayPal 实际结果
原始基线	17、18、19、21；native 解码 1	真实调用 -22、-22、-1	Root 检测退出
仅 Magisk 修改	17、18、19、20；真实 native 解码 0	该阶段未单独采集此项	仍退出
仅内核修改	保留原 Magisk 镜像	APK 与真实调用均通过该项验证	仍退出
两处合并	最终读数 17、18、19、20	安装同一已验证内核；验收阶段未重挂探针	指纹验证后正常进入并停留

这不是一次把所有单元格都重新测量的完整实验矩阵，也没有完成所有历史计划中设想的整机 A/B/A 或多轮冷启动。现有证据足以支持本机构建上的修复结论，但报告应保留实际完成的范围。

最终验收：设备可用性也属于结果

组合镜像启动后，PayPal 到达系统指纹认证窗口。实际操作者完成验证，确认可以正常进入并停留。后续检查仍为同一 PayPal 进程，崩溃缓冲区为空。

同时确认了几个与“能打开”不同的结果：

• Magisk Root 与原 Zygisk 组件正常，HMA 配置哈希未变。
• SELinux 保持 Enforcing，运行策略与修复前逐字节一致。
• 原有 388 个已加载内核模块集合没有减少。
• 诊断 APK 已卸载，本任务的 BPF 程序、map、pin、探针及手机端临时文件已清理。
• iFAST 冷启动没有显示 Root／越狱提示，但仍显示已启用开发人员选项的风险提示；本轮没有继续验证该提示后的功能。

PayPal 验收覆盖认证后进入与停留，没有执行支付、转账，也没有证明硬件证明或服务端风控状态发生变化。把这些边界写在成功记录里，比留到下次故障时再猜更有用。

留给下一次的定位顺序

如果将来再次出现闪退，先从新基线开始：记录 PayPal、系统、内核、Magisk、ZygiskNext 版本，当前槽位、模块列表、策略状态，以及新的异常。不要因为症状相似就直接套用这两个补丁。

然后按下面的决策顺序推进：

1. 先确认是不是同一失败。 是否仍有 s=root 异常？是应用主动退出、native 崩溃、ANR，还是系统重启？分别保留原始证据。
2. 检查修复是否还在。 系统、内核或 Magisk 更新可能覆盖 boot 或 init_boot。对比更新后的源码、镜像记录和实际信号，不能只看 Magisk UI 版本号。
3. 检查信号所在环境。 设备号读数只能用于初筛；关键行为仍要在真实应用、App Zygote 或忠实复现中验证。shell 正常不等于目标进程正常。
4. 每次只验证一个假设。 先写下要改变的输入、预计变化的观测量，以及仍可能失败的其他条件，再实施小范围实验。
5. 所有临时观测都有退出路径。 明确目标、限时、计数和清理范围；不要重新启用本次已退役的 ART 入口探针。
6. 最终以无诊断环境验收。 单项通过后还要回到实际应用、Root、策略和已有功能，记录哪些做过、哪些没做过。

对于包含 boot / init_boot 修改的测试，回退准备要在重启前完成：从当前设备读取原镜像，计算 SHA-256，在主机保存离线恢复副本，核对设备与槽位，并确认 Fastboot 恢复路径可用。本次最终修改了两个分区，完整回退也必须恢复对应的两个原镜像；普通重启只会结束临时启动，不能撤销已经写入的修复。

升级时应基于新版本重新评审这两处修改，再做兼容验证。旧镜像包含当时系统的启动结构，不能因为设备型号相同就跨版本回刷。最有价值的保留物是补丁、准确基线、输入与验收记录，而不只是一个“当时能用”的镜像。

附件与证据说明

随文保存了附件说明、两项修改和验收的脱敏摘要、15 项宿主测试输出和附件校验清单。两份补丁与实际安装版本对应，但附件不包含可直接刷入的镜像。

公开摘要摘取本地记录中的技术字段，移除了设备标识、个人路径和账户界面；它不是完整原始日志，也不是独立第三方复验。原始镜像、原始日志和恢复材料留在本地。代码基线与证据索引另记在仓库的 docs/SOURCES.md，方便之后更新文章时逐项核对。

最终留下的修复只有现有 Magisk 和内核中的两处局部修改，维护成本依然存在。下次版本更新时，要重新问的是“这个差异还存在吗、这处改动还适用吗”，而不是无条件把旧补丁再叠一遍。