水1

最近社区公开了两年前的检测，虽然在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