-
-
[求助啊]关于OD硬件断点和异常的分派问题
-
发表于: 2011-6-18 20:10
-
声明： 个人水平比较菜，只是个人的一点学习记录，有些问题拿出来请教下，还望各位多多指点
这里主要是看下OD的F2（软断点）和F4的实现，通过一些值的变量来推断处理方式，具体过程如下：
OD加载notepad程序，在某地址下个软断点(F2) (如图一)
看下F2后的变化，通过Windbg可以看到在，OD将对应地址内容改为CC即int 3
//下硬件写断点，大小1字节，地址就是改为CC的内存地址
下面就开go，切换到虚拟机，查看代码OD下执行到断点地址，这时触发了硬件写异常，再切到windbg下 (图二)
看下触发异常时对应代码，这时还没有修改， go一次，这次触发内存写异常时发现代码已经被还原了
总结下：
OD的F2软断点，通过在要下断的地址写入CC，当指定到有int 3时触发断点异常，OD(调试器)接管异常判断并处理异常，处理方式是将int 3换原为原来指令(windbg第一次触发写异常)，修改EIP = EIP-1，并设置单步，重新执行指令，触发单步，在单步时在重新写入int3(windbg第二次写异常)
这里再顺便看下F4是的实现， 看看是不是也是通过设置int 3后执行完就还原的，windbg同上设置10073A4硬件写断点，OD中点到10073B4，按F4(图三)
没有反应，看来不是通过插入异常指令来实现的。
在10073A4windbg下读断点，go。。。。
这下可爽了，捅到马蜂窝。
(图四)
哈哈，这个至少说明异常的分发顺序真的是先给R3的调试器，R3的不处理再给R0的处理。
比如前面的int3，OD处理就没windbg的份，但是写内存时OD不处理，这才轮到windbg
这下就头大了，要是硬件断点，有什么招来证明呢？
在F4时要在设置好硬件断点后被windbg接管，早了不行，晚了不知道还有没有骨头渣剩下啊。
F4时应该是先设置好硬件断点然后就go了，我只要在半路拦下看看不就好了嘛，hook你。
Windbg 下软断点在10073AB
F4在10073B2，OD直接断在了10073AB，而且死活就不走，这是什么情况啊？？？？(图五)
kd> ba e1 10073AB
F4也断不下来，这是什么情况，这是什么情况啊。。。。。
原来OD右键可以显示调试寄存器，折腾了半天，下面是F4到10073A4的显示(图六)
疑惑：
1）windbg设置硬件执行断点时，用F4执行到windbg设置断点的后面，windbg硬件断点无效。在OD的调试寄存器中只有F4到的EIP地址，是不是OD有地方保存它自己设置的硬件断点，不是它设置的就会别清空，导致windbg没法接管？
2）在windbg下int3 或硬件执行断点时，OD非F4执行到windbg设置断点位置时，OD未处理此异常，windbg也没有接管到，OD显示”调试的程序无法处理例外”，这个是什么情况，求解？
还请碰到的各位指点迷径啊，先谢谢了！
这里主要是看下OD的F2（软断点）和F4的实现，通过一些值的变量来推断处理方式，具体过程如下：
OD加载notepad程序，在某地址下个软断点(F2) (如图一)
看下F2后的变化，通过Windbg可以看到在，OD将对应地址内容改为CC即int 3
!process 0 0
PROCESS 82646ca8 SessionId: 0 Cid: 04ec Peb: 7ffdc000 ParentCid: 06e0
DirBase: 085c02e0 ObjectTable: e1dfef68 HandleCount: 24.
Image: NOTEPAD.EXE
kd> .process /i 82646ca8
You need to continue execution (press 'g' <enter>) for the context
to be switched. When the debugger breaks in again, you will be in
the new process context.
kd> g
kd> u 100739d
0100739d 6a70 push 70h
0100739f 6898180001 push 1001898h
010073a4 cc int 3
010073a5 bf01000033 mov edi,33000001h
010073aa db538b fist dword ptr [ebx-75h]
010073ad 3dcc100001 cmp eax,10010CCh
010073b2 ffd7 call edi
010073b4 6681384d5a cmp word ptr [eax],5A4Dh
//下硬件写断点，大小1字节，地址就是改为CC的内存地址
kd> ba w1 010073a4
下面就开go，切换到虚拟机，查看代码OD下执行到断点地址，这时触发了硬件写异常，再切到windbg下 (图二)
看下触发异常时对应代码，这时还没有修改， go一次，这次触发内存写异常时发现代码已经被还原了
kd> g Breakpoint 0 hit nt!MiDoPoolCopy+0x14a: 805a90a0 834dfcff or dword ptr [ebp-4],0FFFFFFFFh kd> u 100739d 0100739d 6a70 push 70h 0100739f 6898180001 push 1001898h 010073a4 e8bf010000 call 01007568 010073a9 33db xor ebx,ebx 010073ab 53 push ebx 010073ac 8b3dcc100001 mov edi,dword ptr ds:[10010CCh] 010073b2 ffd7 call edi 010073b4 6681384d5a cmp word ptr [eax],5A4Dh再go，这次OD又把int 3插入到
kd> g Breakpoint 0 hit nt!MiDoPoolCopy+0x14a: 805a90a0 834dfcff or dword ptr [ebp-4],0FFFFFFFFh kd> u 100739d 0100739d 6a70 push 70h 0100739f 6898180001 push 1001898h 010073a4 cc int 3 010073a5 bf01000033 mov edi,33000001h 010073aa db538b fist dword ptr [ebx-75h] 010073ad 3dcc100001 cmp eax,10010CCh 010073b2 ffd7 call edi 010073b4 6681384d5a cmp word ptr [eax],5A4Dh
总结下：
OD的F2软断点，通过在要下断的地址写入CC，当指定到有int 3时触发断点异常，OD(调试器)接管异常判断并处理异常，处理方式是将int 3换原为原来指令(windbg第一次触发写异常)，修改EIP = EIP-1，并设置单步，重新执行指令，触发单步，在单步时在重新写入int3(windbg第二次写异常)
这里再顺便看下F4是的实现， 看看是不是也是通过设置int 3后执行完就还原的，windbg同上设置10073A4硬件写断点，OD中点到10073B4，按F4(图三)
没有反应，看来不是通过插入异常指令来实现的。
在10073A4windbg下读断点，go。。。。
这下可爽了，捅到马蜂窝。
kd> g Breakpoint 0 hit nt!MiDoPoolCopy+0xde: 805a9034 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]换个执行的来看看效果
kd> ba e1 10073A4
(图四)
哈哈，这个至少说明异常的分发顺序真的是先给R3的调试器，R3的不处理再给R0的处理。
比如前面的int3，OD处理就没windbg的份，但是写内存时OD不处理，这才轮到windbg
这下就头大了，要是硬件断点，有什么招来证明呢？
在F4时要在设置好硬件断点后被windbg接管，早了不行，晚了不知道还有没有骨头渣剩下啊。
F4时应该是先设置好硬件断点然后就go了，我只要在半路拦下看看不就好了嘛，hook你。
Windbg 下软断点在10073AB
F4在10073B2，OD直接断在了10073AB，而且死活就不走，这是什么情况啊？？？？(图五)
kd> ba e1 10073AB
F4也断不下来，这是什么情况，这是什么情况啊。。。。。
原来OD右键可以显示调试寄存器，折腾了半天，下面是F4到10073A4的显示(图六)
疑惑：
1）windbg设置硬件执行断点时，用F4执行到windbg设置断点的后面，windbg硬件断点无效。在OD的调试寄存器中只有F4到的EIP地址，是不是OD有地方保存它自己设置的硬件断点，不是它设置的就会别清空，导致windbg没法接管？
2）在windbg下int3 或硬件执行断点时，OD非F4执行到windbg设置断点位置时，OD未处理此异常，windbg也没有接管到，OD显示”调试的程序无法处理例外”，这个是什么情况，求解？
还请碰到的各位指点迷径啊，先谢谢了！
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
关于OD和windbg直接的关系，和OD处理F4时对调试寄存器的处理
要验证的情况，F4时OD是如何操作调试寄存器的，windbg设置调试寄存器(执行)是否影响OD Windbg 执行断点在10073B2处，go 被调试OD F4到10073B4 调试器OD断在SetThreadContext，这时设置的调试寄存器信息为Dr0：10073B4 (图一)  OD有判断回写操作，第三次Set时 (图二)  清除调试寄存后被调试OD就接管，调试OD在GetThreadContext时根本就没有windbg下的硬件执行断点 (图三)  总结 通过调试发现，OD处理F4时通过获取context信息后修改空闲的调试寄存器并设置context，重复一次操作猜测是判断是否设置成功，最后会将本次设置的调试寄存器设空 再验证下，OD的读写内存操作是否会影响windbg硬件读写断点 Windbg kd> ba w1 10073BB，go， OD F2 到10073BB (图四)  悲剧诞生了，虚拟机罢工了，丫得，重来一次，这次就一个OD了。 当双击10073BB下int 3时windbg捕获了异常。 这里只能是YY下了。哈哈 不知道到他们三者关系是否可以这么理解： 被调试程序，调试器OD，系统windbg Windbg下硬件断点后，当OD写那个地址时相当于写系统保护区了，触发了一场，这时异常分配，有调试器就给OD发了，OD不处理啊，就发给系统，也就是windbg了。哈哈，自圆其说啊。 按照上面的思路再来YY一下，windbg下int3问题。 Windbg下int3相等于直接修改被调试进程指定内存为CC，这时OD不处理，应该就发给系统了啊。莫非OD就认为这个就是程序本身的bug。 再来调调看。 kd> bp 10073ab kd> g 下面的情况就匪夷所思了。(图五)  触发异常时有调试器，就发给OD了，OD不处理又发给程序了，又异常派发，又回来了。 不忽略int 3中断时，int3 就被飘过了？(图六)  直接跳过，太牛X了，莫非OD自己++EIP了？ 声明： 都是猜测，没有具体根据，仅自娱自乐只用。 |
