关闭

OllyDbg完全教程 分析器[Analysis]

标签: 汇编编译器代码分析exception优化include
1329人阅读 评论(0) 收藏 举报
分类:
四,分析器[Analysis]

OllyDbg 整合了一个快速而强大的代码分析器。您可以从快捷菜单,或者在CPU窗口的反汇编面板中按 Ctrl+A ,或者在可执行模块中选择“分析全部模块[Analyze all modules]”,来使用它。

分析器有很高的启发性。它能区分代码和数据,标记入口和跳转目的地址,识别转换表[switch tables],ASCII 和 UNICODE 串,定位函数过程,循环,高阶转换[
high-level switches]并且能解码标准API函数的参数(示例[example])。OllyDbg 的其他部分也广泛的使用了分析后的数据。

这是如何实现的?我将为您揭开这一神秘面纱。第一遍,OllyDbg反汇编代码段中所有可能的地址,并计算调用的每个目的地址的个数。当然,很多调用是假的,但不可能两个错误的调用都指向了相同的命令,当然如果有三个的话,就更不可能了。因此如果有三个或者更多的调用指向了相同的地址,我可以肯定的说这个地址是某个频繁使用的子程序的入口。从定位的入口出发,我继续跟踪所有的跳转和函数调用,等等。按这种方法,我可能准确定位99.9% 的命令。但是,某些字节并不在这个链条上。我再用20多种高效的启发方法(最简单的方法,比如“直接访问前64K内存是不允许的,像在MOV [0],EAX中”)来探测他们

有时,分析器在您感兴趣的地方分析错误。有两种解决方法:或者从选中的部分移除分析(快捷键退格键),这样 OllyDbg 将使用默认的解码(反汇编)方式;或者设置
解码提示[decoding hints]并重新分析。注意:在某些情况下,当分析器认为您的提示是不合适的,或者有冲突,则可能忽略您的设置。

探测程序的函数过程也很简单。在分析器眼中看来,程序只是一个连绵不断的代码,从一个入口开始,可能达到(至少从理论上)所有的命令(除了NOP以及类似的用于填充间隙的命令)。您可能指定三个识别级别。严格的函数过程要求有准确的一个入口,并且至少有一个返回。在启发级别下,分析器只要求过程有一个入口。而如果您选择模糊模式,差不多连贯的代码都会被识别为单独的过程。现代编译器进行全局代码优化,有可能把一个过程分成几个部份。在这种情况下,模糊模式非常有用。但是也会误识别的机率也就更高。

同样地,循环是一个封闭的连续的命令序列,并有一个到开始处的跳转作为一个入口,还有若干个出口。循环与高级操作命令 do, while 和 for 相对应。OllyDbg 能够识别任何复杂的嵌套循环。他们会在反汇编栏[Disassembly]中用长而粗括号标记。如果入口不是循环的第一个命令,OllyDbg会用一个小三角进行标记。

为了实现一个转换[switch], 许多编译器,读取转换变量[switch variable]到寄存器中,然后减它,像如下的代码序列:

MOV EDX,<switch variable>
SUB EDX,100
JB DEFAULTCASE
JE CASE100 ; Case 100
DEC EDX
JNE DEFAULTCASE
... ; Case 101

这个序列可能还包含一到两阶的转换表、直接比较、优化和其他元素。如果在比较或跳转的很深处,这就很难知道哪是一个分支[Case]。OllyDbg 会帮助您,它会标记所有的分支,包括默认的,甚至尝试分析每个分支的含义,如'A'、WM_PAINT 或者 EXCEPTION_ACCESS_VIOLATION。如果命令序列没有修改寄存器(也就是仅仅由比较组成),那么这可能不是转换,而很有可能是选择嵌套:

if (i==0) {...}
else if (i==5) {...}
else if (i==10) {...}

如果需要OllyDbg将选择嵌套解码成选择语句,请在分析1[Analysis1]中设置相关选项。

OllyDbg包含多达1900条常用API函数,这些都作为内部预处理资源。这个列表包含了KERNEL32, GDI32, USER32, ADVAPI32, COMDLG32, SHELL32, VERSION, SHLWAPI, COMCTL32, WINSOCK, WS2_32 和 MSVCRT。您可以添加自己的函数描述[add your own descriptions]。如果分析器遇到的调用,使用了已知的函数名(或者跳转到这样的函数),它将在调用之前立即解码PUSH命令。因此,您只需略微一看就能明白函数调用的含义。OllyDbg还包含了大约400多种的标准C函数。如果您有原始的库文件,我推荐您在分析前扫描目标文件。这样OllyDbg将能解码这些C函数的参数。

如果选项“猜测未知函数的参数个数”开启,分析器将会决定这个调用函数过程使用的长度为双字的参数个数。并且标记他们为参数1[Arg1],参数2[ Arg2],等等。注意:无论如何,寄存器参数是无法识别的,所以不会增加参数的数目。分析器使用了一种比较安全的方法。例如,它不能识别的没有参数的函数过程,或者该过程POP
命令直接做返回前的寄存器恢复,而不销毁参数。然而,识别出来的函数参数数目通常非常高,这大大加大了代码的可读性。

分析器能够跟踪整型寄存器的内容。现代优化编译器,特别是奔腾系列,频繁地使用寄存器读取常量和地址,或使用尽量少的使用内存。如果某个常量读取到寄存器中,分析器会注意它,并尝试解码函数和其参数。分析器还能完成简单的算术计算,甚至可以跟踪压栈和出栈。

分析器不能区分不同类的名称[different kinds of names]. 。如果您将某些函数指定为已知的名称,OllyDbg将会解码所有到该地址的调用。这是几个预定义的特殊名称
WinMain, DllEntryPoint and WinProc。您可能使用这些标签标记主程序、DLL的的入口以及窗口过程(注意:OllyDbg不检查用户自定义的标签是否唯一)。另外,假定预定义参数assume predefined arguments是一种更好的方法

不幸的是,没有一般规则能够做到100%的准确分析。在某些情况下,例如当模块包含了P-Code或代码段中包换了大量的数据,分析器可能将一些数据解释成代码。如果统计分析显示代码部分很可能是压缩包或者经过加密了,分析器会发出警告。如果您想使用Hit跟踪[Hit trace],我建议您不要使用模糊分析[fuzzy analysis],因为设置断点的地方可能正是数据部分。

自解压文件[Self-extractable files] 通常有一个自提取器,在“正式”代码段之外。如果您选择自解压选项[SFX option]中的“扩展代码段,包含提取器[Extend code section to include self-extractor]”,OllyDbg将会扩展代码段,形式上允许分析它,并可以使用Hit跟踪[Hit] trace和Run跟踪[Run trace]。



0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:107105次
    • 积分:1265
    • 等级:
    • 排名:千里之外
    • 原创:12篇
    • 转载:33篇
    • 译文:0篇
    • 评论:6条
    最新评论