Real Nullptr

P.S. 原生库里藏了个彩蛋，看谁先找到

ZygiskOnKernelSU 一直以来都存在着一个奇怪的 bug ，至今已经收到无数起汇报（可能最早的一例）。这些汇报的共同特征是：都来自 oplus 或者 coloros 系统；都出现了 zygiskd32 崩溃的现象；崩溃的堆栈基本上都来自 malloc ；都只有 release 构建出现问题。 早期的分析发现，崩溃的线程是处理 daemon socket 启动的线程，其中一个命令是根据不同 root 实现去查询某 uid 是否具有 root 权限，而问题似乎来自这里，因为每次执行完这个命令后，就会发生崩溃。当时一个看似可行的修复方法是将相关代码禁止内联。 而近期 root profile 推出后，zygisksu 也做出了相应修改，在这个提交中，never inline 被去掉，于是又出现了上述问题的汇报。 经过讨论 [1] ，怀疑是内核的 bool size 和 rust 中的 bool size 不一致的问题，rust 的 bool size 是 1，如果内核的 bool size 是 4，可能导致内存被破坏。而利用 prctl 查询 root 权限，需要传入一个 bool 指针，由内核改写返回值，问题可能就在这里。因此随后的一个 CI 进行了修改，并且有人汇报此 CI 的 release 版本正常 [2] 。 于是主线也做了类似的修正，不过没有用到上述 CI 的提交。但这个修正的 CI 的 release 仍有人汇报仍然出现崩溃。 实际上上述猜测是有问题的，因为随后的实验又发现，内核的 bool size 为 1 ，看起来和 rust 是一致的。后来又有人提出 copy_to_user 在长度小于 16 的时候可能出现覆盖现象。总之，问题看上去就是某种意外的内存覆写导致的。 然而想要解释问题的具体原因难度很大，因为 release 构建缺少调试信息，而且崩溃的堆栈回溯大部分帧都来自 libc ，难以从 zygiskd 自身的代码发现问题。不论如何，我还是发了一个带有 debug info 的 release 版本，等待有问题的用户参与调查。 就在最近有 ColorOS 用户积极参与了问题调查，真相似乎终于揭开。 为了验证 bool size 的问题，我给那个用户发了一个程序，检测 prctl 是否会覆写，结论是没有错误覆写 [3]。 虽然 bool 没有问题，但是种种迹象表明，应该就是这个 prctl 调用出现的问题，而且一定产生了意外的内存覆写。于是我看了看 kernelsu 的源码，发现了蹊跷之处。 在执行 CMD_UID_GRANTED_ROOT 的时候，kernelsu 会将 prctl 的 arg5 当作一个用户指针，尝试写入一个 reply_ok 返回值。这个返回值区别于 arg4 ，arg4 是命令的 bool 返回值（即 uid 是否具有 root）。 而 zygisksu 中忽略了 arg5 ，且调用 prctl 仅仅传了 4 个参数，因此可以在 dmesg 看到大量的 reply err ，因为 arg5 的地址非法。 不过调用的时候不写 arg5 ，不代表它就没有值了，32 位 arm 的调用约定是 r0~r3 作为前四个参数，之后的参数由调用者放到栈上。现在调用者没有把 arg5 放到栈上，因此取到的值就不是我们能控制的了，这种随机性也和问题报告中，崩溃点各不相同的现象相对应。 将 prctl 的参数列表补全后，release 版本终于恢复正常。 虽然没有让参与调查者在自己的设备上跟踪有问题版本 zygiskd 的系统调用，不过我在自己的设备上测试，发现 32 位的 prctl 调用的第五个参数确实是一个合法地址，甚至是 libc malloc 内存区域的地址。当 zygiskd32 调用了 uid_granted_root 后，KernelSU 也没有打出 reply err 的日志，说明这个地址确实被覆写了，至于为什么没有崩溃，也只能说是玄学了。总之，zygisksu 到这个问题发现为止一直依靠 bug 运行。另外，arm64 的系统调用跟踪发现，arg5 是 0 ，也许是因为 64 位上这个参数来自寄存器。

最近发现某个奇怪的检测，经排查发现问题发生在 USNF 模块的 cat /sys/fs/selinux/enforce 上：busybox 的 cat 会修改文件的 access time，而这个检测利用了这一点。 修复也非常简单，USNF 中那个 if 块本来就是没用的，注释了完事。

目前一个相对容易的（在 companion 中）判断 Zygisk 模块运行环境的办法：读取 /proc/self/exe，判断路径是否包含 magisk / zygisksu

由于 ollvm 需要更新，shamiko 延期发布 😚

公布一个原版 Zygisk 的检测方法：众所周知 sanitize_environ 没 sanitize 干净，但是即使将那个大声密谋“我不是个正常程序”的值抹掉换回正常的，整体偏移仍然是坏的，而恰好 libc 有个函数可以直接拿这个地址。