#1 楼
我发现,解析运行跟踪并不像人们希望的那样琐碎(而且我也像评论您问题的人一样假设)。造成这种情况的原因有很多:字段由可变数量的空格分隔。如果其中一个字段太长,则使用单个分号作为分隔符。但是,不能保证将数量可变的空格用作字段分隔符。
第一个字段之一是已执行指令的地址。除了十六进制地址外,这也可以是(可能是C ++解散的)符号。这些行中可以包含诸如
main std::basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >::~basic_string<unsigned short,std::char_traits<unsigned short>,std::allocator<unsigned short> >;push 0;0018EB38=0;ESP=0018EB38
之类的野兽。当然,拆装的名称也可以出现在汇编程序指令中,不仅出现在地址字段中。另外,我相信ABCDEF0既是有效的十六进制地址,又是有效的符号名称,由于跟踪仅报告已分解的名称或十六进制地址,因此无法将它们分开,
根据OllyDbg的启发式方法,在轨迹的注释字段中指出所指向的包含ASCII或Unicode数据,将显示包含的字符串。至少字符串中的换行符不会被转义,因此您必须处理分割线。调用被跟踪到(正常情况下)或被跟踪到(对于Windows DLL调用)。您可以使用试探法,例如是否显示“呼叫指令”来修改除ESP之外的其他寄存器。通过跟踪ESP,应该可以确定这一点。
转储跟踪的确切格式显然在很大程度上取决于选项,包括诸如汇编助记符是否由空格或制表符与操作数分隔之类的事情,以及是否显示的组件全为大写或小写。
以上所有内容均与OllyDbg 2.01有关;我怀疑不同版本之间肯定会有差异(我不介意该格式是否在将来的版本中更可解析)。
话虽如此,我已经写了一些(Haskell )代码以使用我的特定选项和转储的特定应用程序来解析当前适用于我的输出。这是一个与PERL兼容的正则表达式(在POSIX正则表达式上下文中不起作用),我用它来匹配行: / symbolic名称,第二组是汇编指令,第三组是包含内存内容和寄存器更改的行的“注释”部分。
我想我将继续制作Haskell程序放入过滤器中,该过滤器分析运行轨迹并以更易于机器解析的格式(例如CSV或其他格式)输出它们;如果有人感兴趣,我可以共享代码。 (对不起,使用Haskell;我只需要脚本语言无法提供的性能。我的转储大小为2 GB,而我的Haskell解析器消耗的速度约为50 Mb / s。)
#2 楼
ollydbg runtrace具有内置的分析选项,它可以对模块的runtrace进行分析,也可以全局
去运行跟踪窗口
(...)icon
右键单击并选择profile module
或global profile
一个简单的messagebox.exe(iceleions教程2)将执行从系统断点到原始入口点的
1087946
指令skipping string commands repmovsb ... movsd
中的<43,调用_LdrSnapThunk大约1000次Run trace, selected line
Back=1087946.
Thread=Main
Module=ntdll
Address=7C90120F
Command=RETN
Modified registers=ESP=0013FB24
将通过此全局配置文件调用zwCreateFile 4次
Profile of whole memory, item 30
Count=1012.
Address=7C917BF1 LdrpSnapThunk
First command=MOV EDI, EDI
xpsp3
或hop back to disassembly window
run trace window
和mark this position in run trace window
从全局配置文件到运行跟踪窗口的
jump to next marked position
的详细信息与下面相关Profile of whole memory, item 1046
Count=4.
Address=7C90D0AE ZwCreateFile
First command=MOV EAX, 25
评论
运行跟踪日志文件是具有固定宽度(或基于选项的制表符分隔)字段的简单文本文件。为什么需要特殊的库来解析它?@JasonGeffner:相反,当有人已经做过时,为什么要重新发明轮子呢? :) +1
@ 0xC0000022L:我的观点是,没有人创建用于解析OllyDbg运行跟踪字符串的库,因为解析该字符串已经很简单了。当您已经可以用单行代码解析字符串时,为什么还要创建一个库?
@JasonGeffner完全同意+1
@JasonGeffner:即使是简单的格式也可以复杂地解析,因此这个问题并非毫无根据。通常在任何地方都鼓励重用,因此有选择地在这里阻止重用吗?