从0开发你自己的Trace后端分析工具：（1）概述

一、概述

常规而言，在Native层进行逆向分析，有两种途径：静态分析和动态分析。静态分析，通俗来讲，就是使用反编译工具，对ELF文件进行反汇编，提取符号，更强大的工具还可以还原出伪代码，当然这种伪代码的准确性会伴随各种各样的问题，例如：IDA中的JUMPOUT(data_xxxxx)、函数范围判断错误等等。动态分析，则是通过程序断点、插桩等形式，来窥探程序运行时的状态，但是无法对整个程序进行全面的分析。

打个比方，逆向分析是拆解一件毛衣，静态分析拿到是整件毛衣，你可以翻来覆去看他是怎么编织去拆解。而动态分析是拿到了毛衣中的一根线，从这根线找到整件毛衣的线头去拆解。在实际逆向过程中，往往是动静结合的，静态分析拿到线索之后，动态分析验证思路，防御方在这个过程中设置层层阻碍打死结，让你在整件毛衣中解开死结，或者是迷失方向。

那么Trace是什么？Trace是记录整个程序的运行过程，包括指令、寄存器以及内存，记录的粒度可以是函数、也可以是线程。而我认为Trace是从本质上来说是，程序某次运行过程中的唯一路径。伪代码可能会骗人，静态反编译可能会骗人(Self InlineHook),但是Trace不会骗你。

二、采集Trace

在Android平台上，采集Trace的工具有很多，例如：

• Frida Stalker
• QDBI
• Unidbg Trace
• IDA Trace
• ...

他们都可以作为我们Trace分析的前端工具，其中会涉及到Anti、效率等问题，这些需要读者去甄别和选择不同的工具，来适配不同的场景。

只要保证一点：Trace格式一致,能被后端工具正常解析。在前辈们的项目中，tenet作为一个IDA插件，它可以来回浏览不同时刻的程序运行状态，也是仅要求了这一点。

三、难点

1. Trace效率

在前端采集过程中，使用不同工具的采集效率大为不同，IDA Trace较Frida Stalker会慢一个数量级左右，具体的原因是插桩实现方式不同导致的，感兴趣的读者可以查找相关资料。如果样本进行了OLLVM控制流混淆、指令膨胀时，大量的控制流代码会大幅增加采集的时间，甚至会导致程序崩溃。

三个解决方案可以减少Trace时长：

• 不需要的So，不Trace。
• 在Trace时，插入优化，判断循环、重复的数据，仅采集程序变化的部分。
• 换台更好的手机（钞能力）

2. 分析效率

在后端分析过程中，面对的可能是上亿条级别的Trace记录，可能会导致内存不足，分析缓慢。我将在下一篇详细说说，整个过程中的建模问题，包括：

• 函数符号建模
• 寄存器状态建模
• 内存状态建模
• 控制流图建模

四、展望功能

• 控制流优化
• 函数调用交叉索引（anti blr）
• 内存字符串
• Python插件及脚本系统（联动IDA、Binary Ninja）
• ...

参考

至此感谢@krash前辈
使用时间无关调试技术(Timeless Debugging)高效分析混淆代码

tenet trace format

TTD调试与ttd-bindings逆向工程实践