Tracing

最近感觉记忆力衰退,遂写几篇文章进行备忘。
代码分析的过程中,经常会碰到大坨难懂的逻辑(比如动态的函数指针,鬼知道它跳到哪里去了),或是难以定位关键点的问题,这个时候就需要tracing技术了,把所有的调用记录下来,再静态分析对流程进行梳理。
用tracing技术可以用来对付那些恶心的混淆(ollvm一类),或者找到程序的执行路径,但依旧免不了大量的人肉分析工作,很多时候并不会起到关键性的作用,所以我时常在想,如果我能针对trace的结果做些自动化的话,可能会有奇效,之前画眉的课程里面,他曾经说过,如果破解程序的时候可以记录全部的jcc指令,对比下用正确激活码走的流程是怎样的(虽说大部分程序有重启验证可能更复杂些),不就可以破解了?
怀着疑问我查阅了不少相关资料。

首先是intel pin tool:
经常见ctf大佬们用这东西fuzz一些简单的题目,其自动化原理也比较简单,但过于局限性,用一位dalao的话讲便是,搞定了血赚,搞不定不亏。
ctf题目一般有明确的边界性,tracing指令的时候,可以忽略细节,直接看执行的指令数,如果同一flag每次执行的指令数相同,那么至少可以通过改变输入的flag长度以及执行的指令数变化来判断flag的长度,接下来可以通过爆破的方式获得flag,简单的题目一般从输入的第一位比较,当执行指令数变化时,便可断定当前的输入的第x位是正确的,直至得到成功的输出为止。
但真实世界中,ctf题目大概率是不会存在的,假设算法是hash一类,那么我们用这种办法除了输入位数可以确定以外,不会起到更多的帮助了。
当然,如果我把pin tool说的这么不堪,肯定会被dalao喷死,这东西是可以高度定制的 https://software.intel.com/en-us/articles/pin-a-binary-instrumentation-tool-downloads
目录下面有大量的例子讲述了这东西如何使用。
恰巧,以前我发现ida有一个pin debugger的选项,查阅了ida的pdf资料以后(帮助很大,建议去看看)https://www.hex-rays.com/wp-content/uploads/2019/12/pin_tutorial.pdf
我通过源码编译了一份ida的pin debugger插件,使用细节就不说了,pdf里面讲的很详细,我比较感兴趣的是最后section里面的Differential debugging
但真实世界中,一切都是那么的骨感,我找了几个稍微大一点的程序,比如TH15.5,黑屏十几分钟都没反应(我这还是i9,20核的处理器),盛大FFXIV的登录器,直接报错找不到路径(事实上一切都是对的,因为直接运行就没这个问题),最后,在扫雷上面倒是成功了:

不过跟着pdf里面的思路,我倒是发现,如果清楚调用边界的情况下,没必要一定用pin tool完整trace,除非你有其他更高级的需要,ida里面是自带trace功能的,只是非常卡…
save trace后,按照pdf里面的操作,直接对比两份trace就可以看到执行路径的不同结果了,这里不赘述了。

如果文章这里结束了,那你们一定觉得这是篇水文。
但!我发现了一个更爆炸易用的东西,它居然藏在CE的子菜单里,那么的不显眼!

主界面 -> memory view -> Tools -> Ultimap2
这里还是要警告一下,这个功能需要加载DBVM驱动,我胡乱操作的情况下已经蓝屏3次,所以stay safe,不要作死,以及你的CPU核心数如果太少,性能太菜的话,会卡的要死,我这种一般通过的i9 7900X在跑这个功能的时候,都可以全核心100%,so, choosing wisely

除此之外,找到了一个说的过去的相似软件,叫Funtion hacker,最新版本没有release,要自己编译。
优点是有可视化的图形,但和pin tool一样,这东西是R3下的,极易crash,我也就测了个扫雷没什么大问题,其他的全挂掉了~
就写这么多吧,反正也没人看。

发表评论

电子邮件地址不会被公开。 必填项已用*标注