原方转自 http://www.unpack.cn/thread-65647-1-1.html
【文章标题】: 挣扎的菜鸟 - 当OD不能装载也不能附加程序时
【文章作者】: justlovemm
【作者邮箱】: 无
【作者主页】: 无
【作者QQ号】: 无
【下载地址】: 自己搜索下载
【保护方式】: VMP2.07
【使用工具】: OD,LoadPE,CE,Exception Monitor
【作者声明】: 只是感兴趣，没有其他目的。只是一个菜鸟对几年前大牛们就搞定的问题的一次练习，请大牛们无视本文。
------------------------------------------------------------------------------------------------------------------------------------------
前几天拿到一个程序X，用PEiD查不到任何信息，用exeinfope说是VMP2.07。于是先用OD载入，结果OD立即直接被关闭。开始认为TLS在作怪，用LoadPE，删除掉TLS，保存。再用od 载入，还是一样。下来先直接运行程序，然后用OD附加，结果OD也是立即直接被关闭。
检查OD的选项，first pause是在system breakpoint处(其实自TMD利用那个浮点漏洞关闭OD以后，我的OD一直是启动时停在system breakpoint的)。打开StrongOD的选项，break On TLS也是打上了勾的。这时仔细一想，不对啊，现在的设置应该能截获TLS的运行，这说明不是TLS的问题。
下来考虑是否plugin有问题，于是删除了plugin目录下的所有文件，结果还是一样。
现在菜鸟有点失望了，于是开始在论坛里找关于VMP2.07的资料，无果。查找OD被关闭，基本上就2条参考意见，一个是删除plugin试试，另一个是删除掉OD目录下的dbghelp.dll文件。于是直接试第二个方法，删除掉了OD目录下修改时间为2001年11月12日的dbghelp.dll文件，测试，结果还是一样。于是又把system32目录下的修改时间为2005年5月26日的dbghelp.dll拷贝到OD目录下，其实菜鸟心里也很清楚，这和刚试过的方法没有什么不同的，不过这个时候菜鸟已经有点绝望了，所以这样明知道不会有任何作用的方法菜鸟也要去试试。结果就不说了。
也许是这个时候命不好，菜鸟竟然没有搜索到海风大牛关于dbghelp.dll文件的那个原帖，如果当时看到那个帖子，直接下载帖子里的dbghelp.dll，就不会有这些问题了。
接着菜鸟在UPK发了一个帖子求助，热心人很多，不过菜鸟太菜，没能搞定。
下来改用CE装载，OK，可以装载。然后运行，提示发现调试器。菜鸟据此判断，此anti一定是针对OD的。不过菜鸟不会用CE调试程序，至少是不会象用OD那样去用CE调试程序。
现在，菜鸟已经绝望了。以前TMD不能加载的时候，菜鸟只能等待，不过很快，大牛们就给出了解决方法，菜鸟只是照着去做就OK了。可是现在菜鸟觉得很无助，不知道去哪里寻找帮助，觉得四周一片漆黑。绝望的菜鸟只能一个人在那儿苦苦思索，过了几个小时，菜鸟突然想到一个方法，可以用OD来调试OD，然后用被调试的OD去装载程序X，这样应该就能知道OD是怎么被关闭的了。菜鸟当时心里还有点激动，心想，也许一个新的anti OD的方法就要让本菜鸟给搞定了，哈哈。
立即动手，用OllyICE加载一个OllyDbg，用OllyDbg加载程序X，OllyDbg立即被关闭，去OllyICE中查看OllyDbg退出时的栈，没有得到任何有用的线索。
再试，用OllyICE加载一个OllyDbg，然后在CreateProcessA和ResumeThread处下断，用OllyDbg加载程序X，断在CreateProcessA处，F8过去，OllyDbg正常，再Shift+F9，断到ResumeThread处，再F8过去，然后调出任务管理器，看到进程X已经有一点CPU的占用率了，这时OllyDbg还未被关闭，再Shift+F9，OllyDbg直接被关闭，查看退出的栈，还是没有任何线索。
这时候先推理到，OllyDbg当时是一被调试的进程，除了调试进程以外，其它进程是无法关闭OllyDbg的，菜鸟猜想是否给OllyDbg窗口发送了WM_QUIT或者WM_CLOSE消息。于是在OD中查找GetMessage，未发现，查找PeekMessage，找到好几个，根据传入的消息的上下限，找到了OllyDbg的窗口过程中使用的PeekMessage，在PeekMessage返回后的一个地方下条件断点，当消息ID是WM_QUIT或者WM_CLOSE时触发断点。再次载入程序X，OllyDbg同样被关掉，并未触发任何条件断点。
这样就排除了程序X发送消息给OllyDbug窗口的可能性。这时菜鸟认定OllyDbg在装入程序X的时候本身产生了什么不可捕获的异常，导致程序直接被关闭了。问题是怎么才能知道这个异常发生在什么地方呢？
此时的菜鸟又一次陷入了绝望，又觉得四周一片漆黑。
在黑暗中孤独的思索了几个小时后，菜鸟突然想起以前用过的Exception Monitor，是M$的产品，当时是为了调试服务进程而推出的东东。用这个东西能捕获最后一次异常发生时的线程信息，包括各个寄存器和栈数据。上网搜索，还是命不好，竟然找不到MS的Exception Monitor的下载地点。不过，也意外的发现还有好几个类似的产品，一个叫EMon.exe的还是开源的，于是下载了这个EMon.exe。
打开OllyDbg，用EMon.exe去attach，在进程列表里没有发现OllyDbg。呵呵，是StrongOD隐藏了OllyDbg进程，删除掉SOD，OK，用EMon.exe attach OllyDbg，再用OllyDbg载入程序X，然后看到EMon.exe的Log窗口哗哗哗的闪，计算机不停的叫"叭嗒叭嗒"，过了有2、3分钟，停了下来，OllyDbg已经不见踪影了。
EMon.exe最后的Log是这样的:
下午 04:00:09: Process terminated with exit code 3221225477 下午 04:00:09: End of Process: 4076 - OllyDBG.EXE 下午 04:00:09: End of Process: 2380 - X.exe
接着往上看，最后出错信息是这样的：
下午 04:00:09: ACCESS_VIOLATION at address 7C92EDDD
** The thread tried to read from or write to a virtual address
for which it does not have the appropriate access.
** Thread ID=00000F34
** Access violation writing address 00030FFC
** First chance
** Register Dump:
EAX=0000000C
EBX=7C920000 : 00905A4D 00000003 00000004 0000FFFF
ECX=7C930833 : 900004C2 FFFFFF90 95C5FEFF 95C6077C
EDX=000000E0
EDI=7C9237D8 : 04244C8B 060441F7 B8000000 00000001
ESI=7C920000 : 00905A4D 00000003 00000004 0000FFFF
ESP=00031000 : 7C920000 00000000 00000000 00000000
EBP=00031020 : 00031030 7C93086E 7C920000 00031400
EIP=7C92EDDD : 458B5756 E86589F8 FC458B50 FFFC45C7
** Stack Dump:
00031000: 7C920000 : 00905A4D 00000003 00000004 0000FFFF
00031004: 00000000
00031008: 00000000
0003100C: 00000000
00031010: 00031464 : 00031834 7C9237D8 0012B060 00031520
00031014: 7C92EE18 : 83EC8B55 565308EC 8BFC5557 458B0C5D
00031018: 7C9307F5 : 4D8BC033 74C98508 FFF98330 45212B74
0003101C: 7C930838 : FFFFFFFF 7C95C5FE 7C95C607 90909090
00031020: 00031030 : 0003104C 7C9579F0 7C920000 00000001
00031024: 7C93086E : 840FC085 000025BC 18488B66 0BF98166
00031028: 7C920000 : 00905A4D 00000003 00000004 0000FFFF
0003102C: 00031400 : C0000034 00000000 00000018 00E8DAA0
00031030: 0003104C : 00031080 7C95799C 7C920000 0003107C
00031034: 7C9579F0 : 840FC085 000001D8 85FC4D8B CD840FC9
00031038: 7C920000 : 00905A4D 00000003 00000004 0000FFFF
0003103C: 00000001
** Disassembly listing
7C92EDDD: 56 push esi
7C92EDDE: 57 push edi
7C92EDDF: 8B45F8 mov eax, [ebp-0x08]
7C92EDE2: 8965E8 mov [ebp-0x18], esp
7C92EDE5: 50 push eax
7C92EDE6: 8B45FC mov eax, [ebp-0x04]
7C92EDE9: C745FCFFFFFFFF mov [ebp-0x04], 0xFFFFFFFF
7C92EDF0: 8945F8 mov [ebp-0x08], eax
7C92EDF3: 8D45F0 lea eax, [ebp-0x10]
7C92EDF6: 64A300000000 mov 0x00000000, eax
** End of exception report
7C92EDDD是在ntdll中的，菜鸟不知道这个是怎么调用来的。不过在OllyICE中看了一下fs:[8],是00031000，而上面的出错信息的ESP也是这个值，这说明线程栈已经已经用光了，程序无法再运行了。
再往上看，下来的出错信息好像都一样，都是下面这个样子的：
下午 04:00:09: ACCESS_VIOLATION at address 32C21FAE
** The thread tried to read from or write to a virtual address
for which it does not have the appropriate access.
** Thread ID=00000F34
** Access violation reading address 32C21FAE
** First chance
** Register Dump:
EAX=00000000
EBX=00000000
ECX=32C21FAE
EDX=7C9237D8 : 04244C8B 060441F7 B8000000 00000001
EDI=00000000
ESI=00000000
ESP=00031450 : 7C9237BF 00031538 0012B060 00031554
EBP=00031470 : 00031520 7C92378B 00031538 0012B060
EIP=32C21FAE
** Stack Dump:
00031450: 7C9237BF : 00258B64 64000000 0000058F E58B0000
00031454: 00031538 : C0000005 00000010 00000000 32C21FAE
00031458: 0012B060 : 8525521F 32C21FAE 1D2F676B ABC87504
0003145C: 00031554 : 0001003F 00000000 00000000 00000000
00031460: 0003150C : 0012B060 00000000 00130000 00031000
00031464: 00031834 : 00031C04 7C9237D8 0012B060 000318F0
00031468: 7C9237D8 : 04244C8B 060441F7 B8000000 00000001
0003146C: 0012B060 : 8525521F 32C21FAE 1D2F676B ABC87504
00031470: 00031520 : 00031840 7C92EAFA 0012B060 00031554
00031474: 7C92378B : C25B5E5F 8B900014 909090FF 8B559090
00031478: 00031538 : C0000005 00000010 00000000 32C21FAE
0003147C: 0012B060 : 8525521F 32C21FAE 1D2F676B ABC87504
00031480: 00031554 : 0001003F 00000000 00000000 00000000
00031484: 0003150C : 0012B060 00000000 00130000 00031000
00031488: 32C21FAE
0003148C: 00000002
** End of exception report
每次出错的地址都是32C21FAE，用上面的OllyICE调试OllyDbg并断在ResumeThread之后，查看，这个地址是空的。菜鸟觉得很怪异。
继续向上看，都是32C21FAE。于是直接翻到到最上面的Log，才发现只有第一个不是32C21FAE，第一个出错的地址是68D808BF，信息如下：
下午 03:57:58: ACCESS_VIOLATION at address 68D808BF
** The thread tried to read from or write to a virtual address
for which it does not have the appropriate access.
** Thread ID=00000F34
** Access violation reading address 8C699B73
** First chance
** Register Dump:
EAX=8C699B73
EBX=023FBF58 : 00000000 00000000 00000000 0040B987
ECX=8C291638
EDX=73A90925
EDI=023F9160 : 00000000 00000000 00400000 00000000
ESI=023FA090 : 023FAA48 00000000 00400000 00000000
ESP=0012A460 : 023F9160 80000000 023FA090 023FC3E4
EBP=0012ACAC : A1A8ECCE E2B7A856 9C91972D C09558D3
EIP=68D808BF : 0C88088A C9844002 8D38F675 FFFFF7EC
** Stack Dump:
0012A460: 023F9160 : 00000000 00000000 00400000 00000000
0012A464: 80000000
0012A468: 023FA090 : 023FAA48 00000000 00400000 00000000
0012A46C: 023FC3E4 : 000A0118 00040006 00020008 001A000F
0012A470: 023FC616 : 0040791E 0040853B 0040855D 00408581
0012A474: 023FBF58 : 00000000 00000000 00000000 0040B987
0012A478: 023FBF80 : 0000158D 00001F0C 0000D640 0000D778
0012A47C: 023FBF58 : 00000000 00000000 00000000 0040B987
0012A480: 00343158 : 00580058 0070002E 00620064 00000000
0012A484: 00000124
0012A488: 02400AF8 : 00000000 00000000 00000000 00000000
0012A48C: 000000B8
0012A490: 00000001
0012A494: 00000001
0012A498: 7EA7BC00
0012A49C: F11FC1BF
** Disassembly listing
68D808BF: 8A08 mov cl, [eax]
68D808C1: 880C02 mov [edx+eax], cl
68D808C4: 40 inc eax
68D808C5: 84C9 test cl, cl
68D808C7: 75F6 jnz +0x000000F6
68D808C9: 388DECF7FFFF cmp [ebp-0x00000814]
68D808CF: 7473 jz +0x00000073
68D808D1: F6059804DF6802 test 0x68DF0498, 0x00000002
68D808D8: 8D85ECF7FFFF lea eax, [ebp-0x00000814]
68D808DE: 8D5001 lea edx, [eax+0x01]
** End of exception report
在OllyICE中查看了一下68D808BF，在DbgHelp.dll中。
OK，重新用OllyICE装载OllyDbg，在68D808BF处下断，然后装载程序X，成功断下。在数据窗口跳到eax，eax地址有效，看了一下代码，这个应该是一个字符串拷贝的循环，删除68D808BF处的断点，在循环结束后的68D808C9下断，F9正常运行到68D808C9，然后再F9，就跑飞了。
为了捕获异常不让OllyDbg跑飞，再重新来一次，在68D808BF断下后，取消断点，跳到fs:[0]，对当前SEH的handler 68D90888 下硬件断点，F9，还是跑飞了。跑飞的时候好像还提示了那个不存在的地址32C21FAE，一看log，是"32C21FAE|访问违规: 正在执行 [32C21FAE]"，很奇怪，为什么在跳到这个不存在的地址之前没有去执行SEH的hander 68D90888。
无奈，再来，再次断到68D808BF处，F9了几次，每次都又断到68D808BF，这时查看了一下后面一行代码中的edx+eax竟然等于12A498，哈哈字符串拷贝的目标地址在当前栈上，在数据窗口跳到EAX(02363102)，看一下，没有发现00，二进制搜索00，在02363D1E，原来EAX指向的字符串长达0xC1C，就是3100字节长，而根据前面的代码
68D808B7 8D95 ECF7FFFF lea edx, dword ptr [ebp-814]
edx在栈上最大的可用空间也只能是0x814，这肯定是把线程的栈数据给覆盖了。重新测试一下，当断到68D808BF处时，在数据窗口跳去fs:[0]，然后F4到68D808C9，这时数据窗口的数据已经完全改变了，就是说SEH的链和hander已经被覆盖了，而hander就是被修改为那个不存在的32C21FAE。
这时，菜鸟已经明白了，那个字符串拷贝的循环应该就是一个inline化的strcpy，由于没有限制拷贝长度，造成栈数据被覆盖掉了，而新生成的Exception Handler是无效的，结果就又触发了新的异常，进入了一个异常循环，直到栈被用光，OD就结束了，连错误提示都没有，让人以为OD是被正常关闭了。
搞清楚这个以后，菜鸟又在想，这个分明就是一个异常，为什么用OllyICE调试OllyDbg时没有捕获这个异常呢，查看了一下OD的设置，发现是忽略了非法的内存访问异常。设置成不忽略非法的内存访问，用OllyICE装载OllyDbg，然后OllyDbg装载程序X，在OllyICE中就断到了68D808BF，OK，确定了就是这个异常。
分析到这一步，本来应该再分析一下DbgHelp.dll，看看是在拷贝什么信息的时候造成的栈溢出，可是这个时候菜鸟又去搜索了一下DbgHelp.dll，找到了海风大牛的那个帖子，下载了那个DbgHelp.dll，用OD加载程序X，正常的停到了系统入口。这时菜鸟才发现自己的确成不了大牛，因为菜鸟这个时候已经不愿意再去分析DbgHelp.dll了。
最后再说一下，菜鸟因为自己在OD不能装载和附加时，经过思考发现了如何去寻找不能装载和附加的方法，菜鸟自己非常高兴，所以写了此文，为自己庆贺一下！
对DbgHelp.dll溢出时的分析在25楼，请大家指正。