测试版，仍有风险，注意备份

最后测试版，如果没问题就定稿了，后续就不再处理这个问题了。

我看现在好多人说kernelpatch 是用ai写的，其实不完全正确，当你真正用ai的时候会发现，接近用户态的代码会很轻松搞定，但是一旦涉及到寄存器内核态转换，ai 就会完全抓瞎，在已经发布的版本中我已经尽力让ai不要往那个方向尝试，写到最后ai自己偷偷改回来了，给出codex.md是想让更多的人自己来调试自己的内核。这种项目开发维护难免有考虑不周导致设备不开机的情况，遇到这种情况只能麻烦有设备的人进行调试了。目前处于有能力的开发者没时间或者因为无收益而不继续的，维护这种项目希望大家有更多的包容，感谢各位

KernelPatch内部解析器已由kallsyms_lookup_name_by_suffix 实现，越来越多的设备使用LTO优化内核，导致符号要么内联导致hook无效，要么有一些奇怪的后缀，kpm可以直接调用这个方法无需再次实现解析器。原始方法仍然保留为导出函数。

警告，Fake Location在程序中隐藏了一个内置可接受的命令执行后门。这作为一个root应用来说显然是不能接受的。请使用这款应用的用户注意安全。超级用户日志在之前我还觉得不是那么重要，现在后门日益增多，越来越觉得这个功能还是比较重要了。后续可能会加入提权了哪些应用以及命令加入环形日志区。

最近社区公开了我们两年前的检测，虽然在Apatch next中已经修复，但是官方的kernelpatch没有做出任何动作，因为superkey这个要求众多开发者觉得方便，所以一直没有移除，使用官方仓库不使用密钥其实是没有问题的，两年前的文章大家可以看看。
继我们在 6 月公开了一个针对 APatch 的侧信道攻击方法后，今天再公开一个 page access 检测。

在 Peekaboo 1.5.5 发布后，我们注意到一些用户反馈 DBS Paylah! 银行无法打开。由于 DBS 银行我们在 8 月份就做过对抗，（没想到国内居然也能看到 DBS），对于 zDefend 具有一定的经验，在 c malloc 内存中定位到 internalName，dump 后发现是触发了 kernel_hooking 组中的检测，继续追下去发现这个组包含 apatch_page_access_check 和 apatch_cpu_cycle_check。由于涉及到内存相关，猜测不可能是单纯的读取 self 下的信息，肯定要经过系统调用，于是拿出系统调用 dump 神器 stackplz 开抓。因为银行应用本身就需要加载很多数据到内存中，打开应用的一瞬间日志即可达到 70 MB，经过我们的分析找到了关键的检测线程，在几十万次的侧信道检测后执行了一个奇怪的调用： execveat(dirfd=-100, pathname=0x7a3e778718(/system/bin/truncate), argv=0x7e2b417ff8[], envp=0xffffffffffffffff[], flags=4352)
紧接着就会通过 read 调用读取自身的 smaps。和团队成员交流后，我们一致认为是这个调用出于某种原因导致了安装 KernelPatch 的设备触发了缺页机制，于是开始重新阅读 KernelPatch 的源码，直接定位到 execve 相关的有效 hook，直接定位到 truncate 判断的调用中[1]。二分法测试后得知 handle_supercmd 函数被调用后就会无法进入 DBS。观察上文所述的奇怪的调用中，envp 有符号正好是 -1，但 argv 的地址却不在 data 段中，而是自己 mmap 的一块内存。根据 argv 的地址找到 mmap 的过程：
mmap(addr=0x0, length=12288, prot=0x3(PROT_READ|PROT_WRITE), flags=0x21(MAP_SHARED|MAP_ANONYMOUS), fd=-1, offset=0, ret=0x7e2b417000)
观察这个 mmap，长度是 12288，眼尖的读者可能会一眼认出这是 4096 * 3，由于目前安卓没有强制 16k PageSize，mmap 的长度正好是 3 个页，同时设置为可读写的共享匿名内存。根据常识，当软件试图访问已映射在虚拟地址空间中但并未被加载在物理内存中的一个分页时，会触发缺页异常。而这段内存被 mmap 之后截止到目前为止，并没有人去读写，因此在 smaps 这段内存的 Rss 应该等于 0。回到奇怪的调用，pathname 是 truncate，argv 指向的是这段内存的地址，flags 是 4352 换算为十六进制是 0x1100。查看 execveat 系统调用的代码[2]，getname_uflags(filename, flags) 会先被执行，追下去发现 flags 是 AT_EMPTY_PATH + AT_SYMLINK_NOFOLLOW 组合，而这个组合反而会让 LOOKUP_EMPTY 判断成立，使 getname_uflags 返回一个空指针。当空指针作为 struct *filename 被传递下去后，do_execveat_common 会立刻 return 来防止空指针导致设备 panic，这也就是说正常情况下这段代码中的 argv 永远不会被拷贝，不会触发缺页。然而搭载了 KP 的设备执行这段调用后由于不加判断地拷贝 argv，触发了缺页机制，进而导致了 Rss 变化，证明设备包含了 KP。

再次感叹 zDefend 的安全研究人员是真的技术到位和基础知识的牢固，在此给各位读者留下两个思考： 1. KernelSU 同样也有类似的代码，为什么没有触发缺页中断？KP 又该如何修复？ 2. mmap 的为什么是三个页大小，而 argv 的地址却是第二个页前后？

[1] https://github.com/bmax121/KernelPatch/blob/dev/kernel/patch/common/sucompat.c#L250 [2] https://elixir.bootlin.com/linux/v5.15.166/source/fs/exec.c#L2108

KernelPatch最终的systemcall引用了KernelHook中更底层的hook,直接hook在所有路径都会经过更底层的el0_svc_common，失败则回退。这几乎可以把所有时延检测都降低在无法观测的数值内。这是相较于KernelSu方案提出不同的解法，欢迎讨论pr并完善方案。