在前期对App进行漏洞挖掘的过程中发现，以纯人工的方式去逆向某些App并且发现其中的漏洞已经不太现实，主要有以下几点原因： • Android系统体系十分庞大，App代码量巨大，存在超大型App(抖音目前已经有150万个函数)，人工分析极度不现实 • 对Android静态分析精力耗费巨大，自动化静态分析完全可以简化大量重复的工作。 Appshark 是一个针对安卓的静态分析工具,它的设计目标是针对超大型App的分析(抖音目前已经有150万个函数). Appshark支持众多特性: • 基于json的自定义扫描规则,发现自己关心的安全漏洞以及隐私合规问题 • 灵活配置,可以在准确率以及扫描时间空间之间寻求平衡 • 支持自定义扩展规则,根据自己的业务需要,进行定制分析
一切都因WMCTF2023一道Android 游戏题BabyAnti-2而起，预期解为拦截**mincore**调用（**int mincore(void *start, size_t length, unsigned char *vec);**监测指定大小的页面是否处于物理内存中。一般用于内存扫描的检查，一旦扫描行为发生，有些并不在物理内存的页面被调入。vec 是一个字节数组，用于存储结果。每个字节对应 addr 和 length 指定的内存区域中的一个页面。如果相应的页面驻留在内存中，那么相应的字节的最低位会被设置为 1，否则会被设置为 0。），当时非预期了题目，即直接CheatEngine附加游戏题，扫描内存时游戏虽然会监测到并弹窗，但是游戏正常运行，直接能修改分数并且拿到flag。 由于题目中mincore 不止存在直接libc调用，而且存在svc指令的调用，这种svc指令相当于是直接的系统调用，不能被一般的钩子挂住，从而无法监视和修改调用参数返回值。而且题目设计使用申请的内存空间修改为可执行后放置svc指令，一直循环监测。除此之外，题目还是flutter写的，逆向逻辑难上加难。经过大量逆向和调试工作后，利用frida的内存搜索功能匹配svc指令，最终能够拦截并且不被检测到，但是鉴于太复杂，想着有没有什么通用办法，不需要逆程序逻辑就直接拦截svc调用的方法。 于是有了这篇文章，文章总结了各位大佬提出的三种方案（ptrace-seccomp，frida-seccomp以及sigaction-seccomp）并进行了测试。