Windbg入门实战讲解
聚锋实验室:gongmo
windbg作为windows调试的神器。是查看内核某些结构体,挖掘漏洞,调试系统内核,调试驱动等必不可少的工具。但是由于windbg命令众多,界面友好程度较差,从而造成新人上手不易,望而却步。本文抛砖引玉,从基础入手,讲解windbg。希望同作为新人的我们一起进步!
注意:本文省略部分为:1.如何加载系统符号。2.如何开启双机调试。因为这部分的内容,网络上太多了。读者可自行百度。但是请注意:这两部分也是很重要的。
0×1 程序代码
为了整体掌握windbg的调试流程。本文实例采用自己编写。好处是可以更为主动的熟悉windbg的调试命令,更加直观的查看windbg的显示结果。
0×2 windbg调试入口
打开windbg,点击:File->Open Executable,选中编译好的exe文件。Windbg会自动给程序下一个断点。但是我们不知道这个断点是否属于我们程序的区域。所以,我们先要看下,断点是断在了什么地方。我们在windbg命令中输入!address 断点地址。如下图所示:
图中不仅仅显示了断点所在的“领空区域”,还显示了一些文件的其他属性。由于此时的断点不再我们需要的领空,所以下面要使用上文提过的伪寄存器了。我们在windbg中输入:bp $exentry。也可以输入bp @$exentry。@的作用是让windbg不再去寻找系统符号,从而加快了执行速度。Bp呢,我们依旧可以看下windbg的帮助文档。从中,我们可以知道,bp就是给地址下一个断点。好让程序中断下来。那$exentry又是什么呢?我们可以在Help->Content点击索引,输入:pseudo查看。$exentry就是我们的程序入口点啦。
之后我们输入bl命令;可以查看我们下的断点。
输入g命令;g就是运行程序的意思。运行程序,程序就会停在我们的程序入口点了,也就是oep。
但这依然不是我们想要的。这下系统符号表的作用就体现出来了。虽然本程序加载的系统符号表是vs2015debug时候自动生成的,但是这个系统符号表与从微软下载的系统符号表的作用是一样的。
我们在windbg中输入:bp main;就这么简单。注意:这个符号表是利用的本地符号表。输入g命令;windbg会自动给我们断在main函数中。
G命令结束后,这里我们需要注意一下:点击windbg工具条的Source mode off。当Souce mode on的时候,debug的单步命令会直接按照函数的步骤执行,而不是从真正单步汇编命令,这点上大家可以尝试切换不同的开关。具体执行如下图所示:
0×3重点命令
1) 栈内容查看
这里很重要的一点是:本程序是为了体会windbg的流程和指令。所以,不会回避源代码的显示问题。我们单步到程序的第一个call函数中,可以用F8或者F11步入其中。输入命令:kv。或者点击View->Call Stack查看。此时,我们可以看到栈中的信息是一样的。从中,我们也可以看出kv就是显示堆栈详细信息的命令啦。k命令在windows漏洞挖掘,了解windows执行过程中是非常有用的命令之一。
从下图中,我们也可以看到kv命令后,001218a7正是第一个call函数的返回地址。00000001和00000002正是传递给f_add的参数。在CVE漏洞号码验证的程序中,经常看到大神门查看栈信息就是如此。而ChildEBP信息是什么呢?如下图所示,通过图所示看到:ChildEBP原来就是子函数栈基址的指针地址啦。RetAddr 就是返回的函数地址,Args to Child 就是显示的参数啦。
2)字符串的查看
继续F10,运行完第一个call函数后,windbg显示了一个‘string’的字符。那么想要知道这个字符是什么呢?怎么查看呢?我们这里使用了db命令,就是以byte的形式显示内存数据。Dd命令就没有后面的字符串啦,比较单调,读者可以自己尝试。
我们运行到四个参数的f_add函数中去,kb查看栈的信息,此时,发现Args to child只能显示3个参数,如果有多个参数怎么办呢?可以使用kp或者kP命令,他们的结果是一样的,知识换行与否。结果如下图所示:
3)结构查看
假如我们不知道st_m的结构,想要产看一下st_m的结构是什么,可以使用 dt st_m;可以看到如下结果。3个int类型,每个占用4字节。
有了这些知识,我们就可以简单的进行一些windows的调试;不信,看下面的例子。
0×4 Windows双机调试(实战)
此次利用的漏洞来源: www.exploit-db.com 属于SEH Buffer Overflow类型。
执行前:
执行后:
1)寻找指定进程和附加
打开wavtomp3这个软件。我们通过.process 0 0命令,查看XP中运行的进程。然后找到指定进程后,通过.process /i 进程地址。切换到实际需要的进程中去。切换后;记得‘g’运行下。
2)寻找适合的断点
合适的断点在许多的调试中很重要,断点需要经验的积累和技术的积累。没有一招吃遍天下的断点。本文因为是SHE的缓冲区溢出。并且在用户层触发异常,所以这里我们直接可以下断:bp RtlpExecuteHandlerForException。也可以求稳一点;给ReadFile函数下断点: bp ReadFile 。但是请注意:一定要.reload /f下函数的符号表。否则断点不一定成功。下断后如下图所示:
3)分析代码
运行程序后;可以断在RtlDisPatchException部分函数内。通过r命令,查看寄存器,通过db查看内存字节。例如想查看esp寄存器的值,只需要:dd esp即可。如下图所示:
图中dex的数值是shellcode文本的长度。Eip已经已经指向了异常部分。Esp指向的是栈顶。通过db esp-100 L200查看了从esp这个地址从上往下的
0×200单位的字节。
单步执行下去(F10)。遇到第一个call;图中跟入如下图:
上图中,executehandler2()函数传递了5个参数。而shellcode执行就在executehandler2()中的call ecx。我们利用命令观看:dd 0104fb24地址中的第一个参数就是我们要的执行函数的地址。也是_EXCEPTION_REGISTRATION_RECORD结构的Handler回调函数地址 。
见下图: 图中通过!exchain查看了异常的地址。通过!slist $teb _EXCEPTION_REGISTRATION_RECORD查看了当前异常链的内容。从下图也能证明,异常链的Handler是回调函数。
继续单步跟入(F8),我们发现这里其实要弹出一个Messagebox的异常对话框的。内容如下:
继续单步,就会jmp到shellcode的内容了。或者我们可以用通过一种结构来观察。此时在windbg中,输入!teb;可以看到目前的teb结构目前的值。Dt _NT_TIB又可以观察到nt_tib内部结构。
通过上下图对比,可以看到图中我们的shellcode:0x909006eb和0x004043a4就是覆盖了fs:[0],分别指向了下一个异常块和本次的回调函数。所以上文有一个call ecx,其实是call 0x004043a4。已经指向了我们想要的东西。
下面这个图;已经是我们想要执行的指令的代码了。三个部分的代码都是一样的。
4)结束语
本文主要强调对windbg的调试操作命令做说明。对日后如何调试windows系统有所帮助。在安全行业的道路上,希望大家共勉。