tgoop.com/qianqianzhuang/17
Last Update:
最近收到一些报告，称 Shamiko 无法绕过中国农业银行等应用的检测。调查后发现，这些用户均是使用了 Magisk + ZygiskNext 的组合，且 Shamiko 等隐藏模块运行在黑名单模式。
阅读 ZygiskNext 源码[1][2]后发现，ZygiskNext 虽然支持读取 Magisk 排除列表，但实现方式仍然比较简单（简陋？），具体来说，有以下几个问题：
一是性能损耗。ZygiskNext 在判断进程是否被排除、是否具有 su 权限、是否为 Magisk 管理器等多个场景中，需要多次执行 magisk --sqlite 命令读取数据库。其中某些场景在任意 app 启动时都会触发，从而拖慢应用启动速度（虽然感知不明显）。
二是 API 行为差异。虽然 ZygiskNext 声称与原版 Zygisk API 保持行为一致，但 ZygiskNext 处理模块 flag 的最小单元是 uid，而非进程。将某个进程加入排除列表，等同于将该进程 uid 对应的所有进程都加入排除列表（一键全选）。究其原因，可能是由于 ZygiskNext 起初是为 KernelSU 专门设计的，而 KernelSU 并没有将管理的颗粒度细分到进程。这个行为差异可能会影响到模块挂载，但在实际使用中，产生问题的概率很小。
三是（暂时）无法判断隔离进程。普通应用的 uid 是固定的，而隔离进程（isolated process）的 uid 在每次创建时都是随机的，ZygiskNext 目前还无法判断隔离进程是否处于排除列表中，也无法正确执行相应的 unmount 等操作，从而影响隐藏效果。Magisk 有一系列复杂的函数处理这个问题[3]，ZygiskNext 尚未实现它们。这点在 ZygiskNext 的更新日志中也有说明，但被大多数人忽略了。若要在上述环境下使用 Shamiko，请打开白名单模式。
综上，不推荐在 Magisk 上使用 ZygiskNext。目前原版 Magisk 采用的 native bridge 加载方式搭配 Shamiko，仍能对市面上绝大多数（甚至所有） app 实现很好的隐藏。
[1] https://github.com/Dr-TSNG/ZygiskNext/blob/338d306501ce6437807f66d9e4f179dc5b0d1a8f/zygiskd/src/zygiskd.rs#L244
[2] https://github.com/Dr-TSNG/ZygiskNext/blob/338d306501ce6437807f66d9e4f179dc5b0d1a8f/zygiskd/src/root_impl/magisk.rs
[3] https://github.com/topjohnwu/Magisk/blob/b04e1394c0dadbfd1314cc999f367a9a9781cfd8/native/src/core/deny/utils.cpp
BY 钱庄
Share with your friend now:
tgoop.com/qianqianzhuang/17