基于eBPF实现一个简单的隐蔽脱壳工具-eBPFDexDumper

Nterp是ART为优化字节码解释执行而引入的一种改进型解释器，在Android 11分支上就被引入了，只不过仅实现了x86_64架构，而在Android S上实现了arm和arm64架构。Nterp采用了和Native方法一样的栈帧结构，并且译码和翻译执行全程都由汇编代码实现，进一步拉进解释器和compiled code的性能差距。如果采用这种方法，执行路径直接到 interpreter::ExecuteNterpImpl

如果不支持Nterp，则一个方法的执行路径从art_quick_to_interpreter_bridge 到 artQuickToInterpreterBridge再到EnterInterpreterFromEntryPoint 再进入interpreter::Execute最终走到interpreter::ExecuteSwitch

利用eBPF对这两条路径进行追踪，除此之外，加入对art::verifier::ClassVerifier::VerifyClass 的追踪，防止漏掉一些动态加载的DexFile（经过测试其实还是走这两条路径，但是可能出于其他原因没办法追踪到），能Dump的更全。

下面的结构为Android 13.0.0 的ArtMethod的结构，其中entry_point_from_quick_compiled_code_ 保存了这个方法的执行地址。

当要执行某个方法时，运行时必须首先检查该方法所属的类是否已加载。如果未加载，则Runtime将加载并链接该类。在这个过程中ART会调用 UpdateClassAfterVerification更新已经验证过的类中所有方法的入口点。如果能够使用 nterp，则将原先使用switch interpreter的方法切换到 nterp。

具体做法是遍历该类的所有方法，检查它们当前的入口点是否为QuickToInterpreterBridge，如果是，则调用 Instrumentation::InitializeMethodsCode 来更新入口点。这样，完成验证的类就可以切换到更高效的 nterp 解释器执行

2. 设计与实现

因此在设计上，通过eBPF的Uprobe去动态追踪libart.so的三个关键函数，并从参数中提取ArtMethod指针，进一步从中获取DexFile的指针并且获取DexFile的起始地址和size，即可实现被动式脱壳，即当方法被执行时即可获取到其所在DexFile。

具体而言，在内核层通过eBPF追踪三个关键函数，提取到DexFile 的起始地址和size信息，然后将其传回用户态go程序。

go程序读取到事件缓存区中的数据后，立即通过远程进程内存访问获取到dex文件并进行Dump。Linux远程进程内存访问可通过 process_vm_readv和 process_vm_writev来进行。但是调用这两个 syscall 来实现远程进程访问会被目标检测到。原理是通过是否内存缺页(例如通过mincore)来判断特定内存是否被访问过。但是在脱壳场景中是没有任何问题的。

💡

踩坑：前面在没有想到通过process_vm_readv 读取内存时，试图在eBPF程序内直接读取用户内存，并且将其分片带出到用户态（缓存区有大小限制），但是这个过程中会有大量的数据传输，极易丢失数据，从而使dump出的dex可用性较差。