目录
1、hutrace工具系列第1篇之基本功能介绍
2、hutrace工具系列第2篇之Windows应用
3、hutrace工具系列第3篇之Linux应用
4、hutrace工具系列第4篇之衍生工具hzytrace

    上一篇主要介绍hutrace的各个看着花里胡哨的功能，这里结合一些漏洞、样本的实例进行分析，日常工作见到的一些测试用例不方便公开，很多程序来自网上搜集，演示效果还不够好，而且本文主要目的是介绍hutrace功能用于辅助分析，对于用例的漏洞成因等不再介绍，暂时也确实没足够精力深入分析这些测试样例，网上也已经有比较多的文章了。。

介绍几个简单的漏洞Exp分析示例，演示hutrace在实战中的应用，漏洞成因暂不做更为深入分析，找的漏洞的例子其实不太多，像一些有符号信息程序或者可自己编译源码的如ie系列、chrome等浏览器程序，虽然可以使用脚本对hutrace的日志中地址的符号信息进行标注，但这样操作反而有点问题搞的复杂化，最差的情况下可以把hutrace的运行日志当作参照物掌握其执行流程，不用调试回溯即可反向定位到之前执行的代码流程。

样本来源：https://github.com/unamer/CVE-2017-11882

shellcode功能为重新创建一个傀儡进程EQNEDT32.EXE进程并注入、释放并执行一个3k大小的弹框程序。win7x32+office2010测试环境，执行以下命令：

这里没有使用之前hutrace.exe直接启动Word程序，因为公式编辑器进程EQNEDT32.EXE是通过RPC方式启动，而dynamorio的追踪子进程功能只能捕捉默认的CreateProcess等方式启动的子进程，独立的EQNEDT32.EXE进程无法追踪，但是可以使用dynamorio的自动附加功能，使用dynamorio中自带的drconfig.exe为EQNEDT32.EXE进程注册启动时自动注入dynamorio插件。

下面直接在测试环境使用word打开test.rtf文件，日志目录中生成的文件中我们只需要关注下面三个：

其中前两个是Shellcode执行记录的情况，而创建的傀儡进程EQNEDT32.EXE的trace日志文件huhu.EQNEDT32.EXE.02120.0000.log文件内容（从LoadlibraryA函数开始其实进程已经执行完主题功能，后面未严格处理漏洞现场环境导致进程崩溃退出了，msappid.exe功能简单只有一个弹框）：

Shellcode功能一览无遗，也比较简单，下面主要根据日志分析漏洞执行情况，搜索API执行情况，直接从trace的日志中API调用结果的最后开始向前追溯：

很明显漏洞触发后最先执行的既是CreateProcessA函数，双击定位到相应的位置：

继续往上翻代码：

这不明显就是溢出覆盖的返回地址嘛~有的Shellcode可能会故意清除已执行代码或者栈结构，有了trace记录则不会受这种情况影响，到了这里如果结合IDA可以很容易定位溢出位置，如果继续查看该日志文件可能信息不是很大了，而且溢出位置之前的部分代码并非第一次执行，所以trace的日志里不再打印实际的汇编指令，后面继续分析，不使用IDA非要找虐的话，也可以使用hutrace的print_ins_reg功能打印所有执行指令以及指令状态信息，把上面执行的命令print_ins_info替换为print_ins_reg再次执行trace过程，这样的trace过程就比较慢了，两分钟生成了约500兆的接近全部运行状态的日志文件（注意还不是全部状态哦，只是指令引用的寄存器及内存状态信息，不过大部分情况已经足够了），虽然运行效率低点，好消息是不用像TTD等工具那样反复重放操作了，如果结合IDA的话可以在对处理流程更了解的基础上，设置只处理trace的起始地址，划分关注的代码这样trace的效率更高。

我们下面演示不用调试器、IDA分析的情况下，利用无脑全流程trace的方式分析该漏洞，通过记录的指令指令状态信息定位溢出点，首先根据溢出覆盖的返回地址信息：

日志文件中搜索0x12f1d0：

看到图中左侧框中的数据变化规律可以看出在循环处理栈中的数据，继续往上翻日志：

这不就找到溢出点位置了，后面可以再据此根据rtf文件结构、shellcode在rtf中的位置、搜索rtf数据在trace日志文件中的处理流程等等，探究漏洞成因，结合IDA的话其实基本也可以做到不用调试就能澄清漏洞细节了，这里我就不继续了。。。

继续搞个pdf的洞简单分析下，首先关闭Adobe的沙盒保护：

不会影响漏洞触发，但是开启该机制会影响hutrace的trace操作，关闭之后执行下述命令指定对漏洞模块EScript.api的追踪：

漏洞的Shellcode为一个简单的MessagexBox弹框，大概三分钟的时间形成了近20个记录的线程日志，其中最大的日志文件约1.9G，这还不包含寄存器等状态信息，首先搜索其API执行情况，从后往前查看或者直接搜索MessageBox：

查看VirtualAlloc函数附近的代码：

这不就是rop嘛，如果只关注该exp的功能的话可以往后分析其Shellcode功能，分析漏洞成因的话当然到这里还不算完，日志文件里记录的还有流程信息、内存API申请释放等的结果信息可以辅助分析成因，如果继续跟上一个漏洞一样无脑全指令状态记录的话我曾经测试过虚拟机里大概需要五六个小时，日志文件70多个G。。。虽然已经比调试器trace等快得多了，但是trace的日志太大很影响检索，也没有必要，可以考虑在一定的分析基础上再使用hutrace对trace的日志文件进行裁剪或者对漏洞成因进行一定的探究后再指定起始地址开始进行寄存器状态等的记录，也可以用Windbg的TTD、Windbg开页堆等等快速定位，手段比较多，hutrace毕竟只是一个trace工具，不是一个智能全自动化分析工具，纯粹依赖hutrace的话可能有的场景下还不如windbg的几条命令快一点，根据实际情况能辅助到分析过程即可。

看雪上随便找了一个apt28组织的样本，直接hutrace上去怼：

在得到的trace日志中可得：

恢复快照设置自动追踪rundll32.exe,并指定trace释放的cdnver.dll模块的行为：

截取部分日志结果：

该样本实际是先使用谷歌域名测试下网络联通性，后面还会根据解析出的真正C2服务器域名信息，进行交替访问，不过我虚拟机里没联网，没有记录其与真正C2服务器域名的通信行为。

常规的API Monitor工具只是记录API函数的调用行为，而hutrace则更加灵活，虽然上述例子中其实也是仅对样本的API调用情况进行了查看，实际中是可以对trace日志中更细粒度的基本块、指令、寄存器及内存情况进行分析，例如根据日志中打印的汇编指令情况可以很快澄清API函数中参数来源等，对于病毒样本类的分析使用hutrace对性能影响一般比较小，上述例子生成的trace日志加一起也只有几十兆，也完全可以使用打印寄存器和内存功能，整个分析过程可以看到完全可以不需调试器的参与，在trace日志中进行特定代码的检索也比较便捷，也可以自己做解析二次处理，在下面的插件例子中会介绍一些更个性化的应用~

一些木马样本、Shellcode如cs等提供syscall方式躲避杀软以及一部分AV/EDR的功能，给分析也带来了一定的难度，hutrace中添加了syscall记录的功能，可以使用-print_syscall选项开启，但是Windows上系统版本差异较大，测试中dynamorio的内置获取系统版本的函数可能会很奇怪的获取失败，如果获取失败的话hutrace会从hutrace.config文件中读取自定义设置的系统版本号进行对应版本syscall table的选择，syscall table列表提取自drstrace项目（支持到win10 1803），如果内置获取系统版本的函数调用失败且hutrace.config中未设置自定义的系统版本，会使用hutrace程序中默认设置的win7系统的系统调用表对目标程序运行时的syscall进行标记。

hutrace.config中不设置系统调用对应的参数类型的话，默认只打印syscall的名称，如果遇到感兴趣的syscall需要记录，可以在hutrace.config进行设置如下（以NtCreateKey为例）：

得到的日志中的syscall记录：

在Windows上界面程序一般没必要开启syscall记录，非界面程序的记录需求也比较少，默认是记录程序中所有的syscall调用，不会过滤是否为目标程序本身或者系统函数中的调用，导致trace的日志量也会比较大。

调试时经常遇到需要对特定指令或数据进行运行时修改的情况，hutrace本身提供了一个简易patch的功能，但是对于一些复杂场景显得处理能力较弱，为了实现功能更强大的自定义代码注入功能，hutrace添加了插件功能，可基本实现在程序的任意运行状态修改程序运行信息，下面以一个固定VirtualAlloc内存申请基址的小需求为例，利用提供的hutrace的插件模板很容易即可实现。首先看一个演示的注入程序：

主体功能为注入rundll32.exe弹出计算器的Shellcode（VirtualAllocEx在rundll32.exe内存空间申请0x800大小内存），为了演示，自身也加了一段申请0x1234大小的内存的代码：

下面我们来使用插件把程序本身申请0x1234大小的内存地址固定为0x18000000，进程注入的Shellcode内存地址固定为0x19000000，首先在hutrace.config配置文件中添加以下内容：

其中null代表不使用模块名方式寻址，也即是指示后续的0x77e305f4、0x77e1b42c为绝对地址，分别为KERNEL32.dll模块VirtualAlloc、VirtualAllocEx函数地址，在上面的记录日志里也有体现，在我虚拟机中设置了关闭ASLR,当然只要不重启系统有的dll地址也不会变化，以第一条内容为例，意思是在程序执行到0x77e305f4地址时加载自定义的插件myDynamorioPlugin.dll，并且分别在该地址对应的函数执行前后分别执行插件中的f_hookpre、f_hookpost导出函数（注意并非该地址指令执行前后，如果该地址对应的并非一个函数，可以设置f_hookpost为null，否则可能会导致程序崩溃）。

VirtualAllocEx函数对应的f_hookprex、f_hookpostx函数实现类似。功能为固定返回0x19000000的内存地址，不再赘述，注意参数顺序即可，可见附件中工程代码，下面看下hutrace插件模板中对应的f_hookpre、f_hookpost函数实现：

写的比较简陋，也没有严格处理内存申请失败等等情况，仅作演示用，my_fprintf（写入到trace日志中）、my_getarg（按照API调用约定获取参数的值）为模板中已经实现好的函数，在f_hookpre、f_hookpost函数中可以对任意寄存器（利用传进来的mc参数）、内存进行修改，也可以调用其它API函数。

下面把生成的插件放置到hutrace同目录下，再次trace目标进程inject.exe:

查看日志中的结果：

可以同时trace下rundll32查看其注入的shellcode（msf生成的shellcode）确认其代码地址确实已经被替换成自己指定的值0x19000000，需要使用drconfig方式哦，hutrace的follow_children参数有时无法自动trace这类注入进程：

这个需求的实现能够同时支撑hutrace的其它功能（record_start_addr的指定地址开始记录功能等），不过使用时需要注意会同时导致小问题，Hook的地址与API信息打印、简易Patch功能等功能冲突，如上例对VirtualAlloc函数HOOK之后即不会再打印其KERNEL32.dll模块里VirtualAlloc参数信息，当然KERNELBASE.dll的还是会打印。

另外hutrace.config文件中中使用hook功能时同时支持以下语法：

dynamorio 8.0及以上版本编译的hutrace程序可以在Win10上运行，然而我自己测试的Win10本机运行hutrace记录的效率还不如自己的2核2g内存的“胜七”虚拟机，不知道是什么鬼原因。。。

hutrace源码近期暂先不发布呀，其实目前功能已经比较完善了，应该用不到改源码加啥功能，没啥技术含量，水平比较弱，写的比较随意，抽空把辣眼睛的地方改改少挨点骂。

另外对于一些带调试信息的程序，可以根据记录的trace日志情况，编写IDA脚本对其符号信息等进行标注，这里不做展开说明了~自己写的不多，也比较简陋。

4.对于一些日志中记录的中文等字符串信息，如在hutrace.config中设置char*类型参数打印，需要在010edit中设置简中字符集才能正常显示。

github地址：https://github.com/huhu0706/hutrace

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课