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系统有所帮助。在安全行业的道路上，希望大家共勉。