Shino Channel

前言 本文主要介绍 eDBG 从 0 到 1（也许只是 0.5）的心路历程和设计过程，也许可能可以给大家一点点启发？ 碎碎念 结束了总计时长将近一年的实习，经历了两次互联网大厂的拷打，从 Android 游戏安全做到风险环境和风控，在随手搞定秋招之后，我终于回到学校开始了我的 gap year（其实就是呆在学校搞搞毕业相关的事情的比较不那么忙的一年吧），正好想着可以顺便糊弄毕业设计，就想把我之前的一些灵机一动实现一下。 由于众所周知的原因，现有的 Android 调试器全都是基于 ptrace 方案的，针对 ptrace 方案的检测非常非常多，每次调试都需要做很多麻烦的绕过（当然大部分时间都是在定位不到或者绕不过去？），用 hook 框架也总是会引入很多不友善的特征，用模拟器的“降维调试”也会直接因为没有合适的传感器数据或者特征文件被识别为风险环境——毕竟在大数据时代，一点风吹草动都会被识别为“离群值”被击毙。 在这个环境下，比较好用的方案就是我最爱用的 stackplz，这是一个使用 eBPF 来监视程序的辅助工具，由于在一般场景下，被调试的 APP 一般都不会拥有 ROOT 权限，因此针对 eBPF 技术的检测手段极少极少，因此这个工具非常好用。但是美中不足的是，作为一个记录式的辅助工具，和直接进行自由的调试相比，能提供的信息还是有上限的。 这时，比较流行的解决方案是使用 stackplz 注册 uprobe，然后发送信号挂起程序，再用调试器附加进行调试。

uprobes 特征 目前我接触过的针对 uprobes 的检测手段无非两种： 扫描 BRK 指令 检查 /proc/pid/maps中是否含有[uprobes]特征 其中第一种检测方案在实际 APP 中几乎不可行——运行时的完整性校验会带来巨大的时间开销，正常的 APP 基本无法容忍这种开销， 而对于 app 运行前的整体完整性校验，只需要稍晚附加 uprobes 便能直接绕过，因此本文不讨论这种探测方式。 主要令人担心的是第二种：在使用 uprobes 时，会在/proc/pid/maps中产生类似 7ffffff000-80000000000 --xp 00000000 00:00 0 [uprobes]的字样，如果你有针对这部分检测的魔改 ROM 或者你会使用 eBPF 对 open 和 read 系统调用进行修改，那你可以直接跳过本文内容。 但是，这种特征是怎么产生的？它在 uprobes 触发时总是会产生吗？答案是否定的。具体内容得分析一下这部分的源码。 本文在 ARM64 安卓内核版本 5.15.94 下测试，旧版本可能有所不同。 省流可以直接看后面的总结。

简介 eDBG 是一款基于 eBPF 技术实现的调试工具，为强对抗场景下的安卓 native 逆向工作打造，提供调试器应有的基本功能，在调试时不产生任何附加到目标进程的行为，不使用传统的调试方案，调试器与被调试程序相互独立，仅各自与内核产生交互行为，难以被目标进程调试或干扰。 除此之外，eDBG 和被调试程序运行状态互不干扰，断点注册不基于运行时地址，即使一方意外退出或重启，另一方也依旧能正常工作。 eDBG 的使用方式与 gdb 的使用方式几乎相同，无需学习便可直接上手使用。 项目地址：https://github.com/ShinoLeah/eDBG

碎碎念 好久没打 CTF 感觉能力退化了不少，遇到不是 Android 的题都有点不会做了，甚至卡了一题光荣成为战犯(?)。想了半天为什么 10 解的题我都不会做，后来发现原来现在还有可以直接去除的 ollvm 混淆…. 平时看到的 ollvm 混淆基本都是加强过的根本没法直接跑轮子去除就根本没往这方面想，还是有点太唐了。

前言 最近正好做到了针对安卓某 APP 内置浏览器抓包相关的东西，顺手记录一下。

碎碎念 本文也可以改名《Shino 为什么是一个啥比》，一个首波逆向题坐牢两天没做出来（还是我太菜了）