VC调试器高级应用-高级断点篇(补全).doc

VC调试器高级应用-高级断点篇CND8学院VC教程发布日期：2008年12月15日VC调试器高级应用-高级断点篇一. 高级断点语法 高级断点语法由两部分组成:1.上下文部分.2.位置,表达式,变量或Windows消息条件. 用函数,源文件和二进制模块来指定上下文,上下文的表示方法: 函数,源文件,二进制模块 必须指定唯一的,足够的上下文信息才能获取断点位置.如在TEST.CPP的20行设一位置断点,语法为:,TEST.CPP,.20,如A.DLL或B.DLL都使用了该行,又只想在B.DLL的调用中触发,则必须使用:,TEST.CPP,B.DLL.20. VC调试器中可直接输入上下文语法:Breakpoints对话框的Location选项卡BreakAt编辑框中.更容易的方法是使用BreatAt框右的箭头打开菜单,选择Advanced项,然后在Context框中输入断点的相应信息. 如想在一个绝对地址上中断,直接在BreakAt框中输入地址就行. 二.任何函数上快速中断 将函数名输入BreadAt框中.如果是C+代码,同时还需要类限定符.支持重载了的函数,调试器会列出所有满足条件的函数供选择,如输入时提供足够的信息,完全可略过选择过程.如输入:CString:operator=(const char *)可唯一确定要中断的函数.三.在系统或DLL输出的函数中设置断点 在程序中从DLL输入的函数中设置一个断点可能是毫无作用的,调试器需要知道在何处可以找到该函数上下文信息,同时,函数名取决于是否加载了DLL的符号.只有在W2K以上版本中才能在系统DLL中设置断点-原因在于其它系统没有提供边写入边复制保护的功能,若一定要启用这种方法,必须要有COFF(Common Object File Format),并在调试器中输出启动的装载-在Options对话框的Debug页,将Load COFF & Exports选中. VC调试器用分级的符号信息法,完整的符号的级别高于不太完整的.PDB(Program Database)文件具有所有可能的源码行,函数,变量和类型信息,优先级便高于COFF/DBG文件,后者只有公用函数符号,而COFF/DBG文件高于输出名称,输入的名称是一种伪符号. 调试时,如DEBUG窗口输出:装载DLL的符号,则说明符号已被装入;否则说明没有装载DLL的符号. 没有装入符号时,使用的位置字符串是DLL输出的名称,可能用DUMPBIN程序查看这个名称:DUMPBIN /EXPORTS DLLname.例:在LoadLibraryA中设置中断:,Kernel32.dllLoadLibraryA. 如装入了符号,则要根据输出函数和调用协议来计算函数名.如上例,LoadLibraryA使用_stdcall调用协议,据该协议,函数名以下划线为前缀,所跟有进栈的字节数为后缀的号.一般说来,参数个数*4,就是参数占用栈空间的总字节数,LoadLibary的名称便是:_LoadLibraryA4,故最后的语法是:或,Kernel32.dll_LoadLibraryA4 附:常用的调用协议 1、_stdcall调用约定相当于16位动态库中经常使用的PASCAL调用约定。在32位的VC+5.0中PASCAL调用约定不再被支持（实际上它已被定义为_stdcall。除了_pascal外，_fortran和_syscall也不被支持），取而代之的是_stdcall调用约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。 _stdcall是Pascal程序的缺省调用方式，通常用于Win32 Api中，函数采用从右到左的压栈方式，自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀，在函数名后加上和参数的字节数。 2、C调用约定（即用_cdecl关键字说明）按从右至左的顺序压参数入栈，由调用者把参数弹出栈。对于传送参数的内存栈是由调用者来维护的（正因为如此，实现可变参数的函数只能使用该调用约定）。另外，在函数名修饰约定方面也有所不同。 _cdecl是C和C程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。VC将函数编译后会在函数名前面加上下划线前缀。是MFC缺省调用约定。3、_fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。 _fastcall方式的函数采用寄存器传递参数，VC将函数编译后会在函数名前面加上前缀，在函数名后加上和参数的字节数。 4、thiscall仅仅应用于“C+”成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。 5、naked call采用1-4的调用约定时，如果必要的话，进入函数时编译器会产生代码来保存ESI，EDI，EBX，EBP寄存器，退出函数时则产生代码恢复这些寄存器的内容。naked call不产生这样的代码。naked call不是类型修饰符，故必须和_declspec共同使用。 关键字 _stdcall、_cdecl和_fastcall可以直接加在要输出的函数前，也可以在编译环境的Setting.C/C+ Code Generation项选择。当加在输出函数前的关键字与编译环境中的选择不同时，直接加在输出函数前的关键字有效。它们对应的命令行参数分别为/Gz、/Gd和/Gr。缺省状态为/Gd，即_cdecl。 要完全模仿PASCAL调用约定首先必须使用_stdcall调用约定，至于函数名修饰约定，可以通过其它方法模仿。还有一个值得一提的是WINAPI宏，Windows.h支持该宏，它可以将出函数翻译成适当的调用约定，在WIN32中，它被定义为_stdcall。使用WINAPI宏可以创建自己的APIs。 四.位置断点修饰符 1.跳跃计数. 功能是执行断点但不在断点处停止,直到执行完了一个特定的次数为止. 使用中首先设置一个标准的位置断点,打开BreadPoint对话框,选中该断点,单击Condition,然后在弹出的对话框最下面的编辑控件中输入次数. 只有当程序全速运行时,未执行的循环次数才有用.单步执行跨过断点时不会更新跳跃计数. 例:已知循环可能崩溃,但不清楚在哪次循环时,输入远远大于总循环次数的跳跃计数修饰符,则在崩溃时可打开Breakpoint框,其中将列出还未执行的循环次数,与总次数相减就可得已执行的次数. 2.条件表达式. 只有表达式为真时触发.Breakpoint框Condition按钮,选第一个编辑框,输入表达式即可.规则: .只可使用C类型比较运算符. .表达式中不能调用任何函数. .表达式中不能包含任何宏值. 表达式为TIB=Thread Infomation Block Linear Address,则程序只在该特定线程中才会中断.例:线程TIB地址值为0E000,则输入TIB=0xE000,则在切换到该线程时中断.对W98,可用FS=thread specific value. 如在某特定错误后中断,则可用ERR,如ERR=2表示在最后错误为ERROR_FILE_NOT_FOUND.除CLK外,所有可在WATCH窗口中使用的伪寄存器均可用于条件表达式. 条件表达式可与跳跃断点组合使用. 3.变量更改 在变量更改时中断程序.只有当位置断点执行时才能检查变量.常用用调用栈高层的函数中发现出错,需要深入调用栈,压缩范围找出根源时. 添加时在Breakpoint框第一个编辑框中输入变量名(可以是指针指向听对象:*p),在第二个编辑框中输入要查看的项目数量. 五.全局表达式和条件断点.调试器可监控某一地址和该地址上的1,2或4字节的内容.如可用硬件调试寄存器,则不影响速度;否则程序将单步执行ASM指令并在每一步中检查条件,这将严重影响程序运行速度. 总共有4个调试寄存器.硬件调试寄存器不能处理超过1个双字长的引用.确保利用硬件调试寄存器的最好方法是使用表达式和数据更改位置的实际地址值.例如:g_szGlobal是全局数组指针,地址为0x5000,则在Breakpoint对话框中DATA选项卡中将表达式断点设为*(char*)0x5000=G,但如果写为WO(0x5000)=G,则用不到硬件调试寄存器,会单步执行每条指令. 与全局表达式断点类似,使用变量的16进制地址给定长指针计算地址,并将要查看的单元数设为1,则全局变量断点可发挥最付佳功效.如上例要在变量改动时中断,则输入:*(long*)0x5000. 六.WINDOWS消息断点. Breakpoint框的Message页.需要指定一个窗口过程,注意:MFC世界中AfxWndProc是多数窗口的一个窗口过程.WinDbg:(它和VS里的调试器有什么区别呢?难道只是因为它不要钱?)WinDbg是微软开发的免费源码级调试工具。Windbg可以用于Kernel模式调试和用户模式调试，还可以调试Dump文件。由于大部分程序员不需要做Kernel模式调试， 我在这篇文章中不会介绍Kernel模式调试。Kernel模式调试对学习Windows核心极有帮助。如果你对此感兴趣，可以阅读Inside Windows 2000和Windbg所带的帮助文件。在同一个进程中可能有多个线程。命令可以用来显示和切换线程(批:似乎这是我唯一感兴趣的.看完之后,我只想说一局,OH,MY GOD,我想我一般不会去使用它)。Visual C+的调试功能是从早期的调试工具CodeBase发展而成，这个名叫CodeBase调试工具研究成为一种工业标准。(批:呵,新鲜,第一次听到)首先我们看一下使用异常处理的几种情况：A 用来处理非致命的错误B 对API函数的参数合法性的检验（假设参数都是合法的，只有遇到异常的时候进行合法性检验）C 处理致命错误（退出时最好的选择，但是有的时候可以用异常处理函数在程序退出前释放资源，删除临时文件等，甚至可以详细记录产生异常的指令位置和环境）D 处理“计划内”的异常（我们可能更关心这种情况） 接着我们看看Windows下异常处理的两种方式：1使用筛选器2 SEH异常处理一、 使用筛选器(批:这个就稍微看一下吧.)因为这里我要重点关注的是SEH的处理方式，所以还是简单的提一下筛选器处理方式。筛选器异常处理是通过异常回调函数来指定程序处理异常。这种方式的回调函数必须是唯一的，设置新的回调函数后以前的将失效。适用于进程范围。看一下这个函数的定义Invoke SetUnhandledExecpionFilter,offset_HandlerMov lpPrevHandler,eax回调函数的格式：_Handlerproc pExecptionInfo看看pExecptionInfo这个指针参数指向的一个数据结构EXCEPTION_POINTERS STRUCT (批:好象这里作者写错了,有时间可以去查查) pExceptionRecord DWORD ? ContextRecord DWORD ? EXCEPTION_POINTERS ENDS下面介绍 EXCEPTION_RECORD和CONTEXT结构的定义: ;/= 以下是两个成员的详细结构= EXCEPTION_RECORD STRUCT ExceptionCode DWORD ? ;/异常码 ExceptionFlags DWORD ? ;/异常标志 pExceptionRecord DWORD ? ;/指向另外一个EXCEPTION_RECORD的指针 ExceptionAddress DWORD ? ;/异常发生的地址 NumberParameters DWORD ? ;/下面ExceptionInformation所含有的dword数目 ExceptionInformation DWORD EXCEPTION_MAXIMUM_PARAMETERS dup(?) EXCEPTION_RECORDENDS ;/EXCEPTION_MAXIMUM_PARAMETERS =15 ;/=具体解释=ExceptionCode 异常类型,SDK里面有很多类型,你可以在windows.inc里查找STATUS_来找到更多的异常类型,下面只给出hex值,具体标识定义请查阅windows.inc,你最可能遇到的几种类型如下: C0000005h-读写内存冲突 C0000094h-非法除0 C00000FDh-堆栈溢出或者说越界 80000001h-由Virtual Alloc建立起来的属性页冲突 C0000025h-不可持续异常,程序无法恢复执行,异常处理例程不应处理这个异 常 C0000026h-在异常处理过程中系统使用的代码,如果系统从某个例程莫名奇妙的返回,则出现此代码, 如果RtlUnwind时没有Exception Record参数也同样会填入这个代码 80000003h-调试时因代码中int3中断 80000004h-处于被单步调试状态 注:也可以自己定义异常代码,遵循如下规则: _ 位: 3130 2928 2716 150 _ 含义: 严重程度 29位 功能代码 异常代码 0=成功 0=Mcrosoft MICROSOFT定义 用户定义 1=通知 1=客户 2=警告 28位 3=错误 被保留必须为0 ExceptionFlags 异常标志 0-可修复异常 1-不可修复异常 2-正在展开,不要试图修复什么,需要的话,释放必要的资源 pExceptionRecord 如果程序本身导致异常,指向那个异常结构 ExceptionAddress 发生异常的eip地址 ExceptionInformation 附加消息,在调用RaiseException可指定或者在异常号为C0000005h即内存异常时含义如下 第一个dword 0=读冲突 1=写冲突 第二个dword 读写冲突地址 ;/=解释结束= off. CONTEXT STRUCT ; _ ContextFlags DWORD ? ; | +0 iDr0 DWORD ? ; | +4 iDr1 DWORD ? ; | +8 iDr2 DWORD ? ; 调试寄存器 +C iDr3 DWORD ? ; | +10 iDr6 DWORD ? ; | +14 iDr7 DWORD ? ; _| +18 FloatSave FLOATING_SAVE_AREA ;浮点寄存器区 +1C88h regGs DWORD ? ;-| +8C regFs DWORD ? ; |段寄存器 +90 regEs DWORD ? ; |/ +94 regDs DWORD ? ;-| +98 regEdi DWORD ? ;_ +9C regEsi DWORD ? ; | 通用 +A0 regEbx DWORD ? ; | 寄 +A4 regEdx DWORD ? ; | 存 +A8 regEcx DWORD ? ; | 器 +AC regEax DWORD ? ;_|_组_ +B0 regEbp DWORD ? ;+ +B4 regEip DWORD ? ; |控制 +B8 regCs DWORD ? ; |寄存 +BC regFlag DWORD ? ; |器组 +C0 regEsp DWORD ? ; | +C4 regSs DWORD ? ;+ +C8 ExtendedRegisters db MAXIMUM_SUPPORTED_EXTENSION dup(?) CONTEXT ENDS ;/=以上是两个成员的详细结构= 程序使用筛选器异常处理时可以通过查看上面结构中的regEip来找到产生异常的地址！调试的时候可以改变EIP的值以达到越过异常程序，转到“安全”的地方。最后看一下筛选器异常处理回调函数的返回值EXECPTION_EXECUTE_HANDLER 1；进程被终止，终止前不会出现提示错误的对话框EXECPTION_CONTINUE_SEARCH 0；同样终止程序，显示错误对话框EXECPTION_CONTINUE_EXECUTION -1；系统将CONTECT设置回去，继续执行程序使用筛选器程序是最简单的处理异常方法，不足：1 不便于封装。2 处理是全局性的也就是无法对每个线程或子程序设置一个私有的异常处理程序进行异常处理。 进入正题：SEH异常处理首先解释一下什么是SEH异常处理：SEH(Structured Exception Handling,即结构化异常处理.是操作系统提供给程序设计者的强有力的处理程序错误或异常的武器。下面结合冷雨飘心的一个SEH异常处理程序来说明具体的用法：;(批:注释)/=;/ ex. 2,by Hume,2001 线程相关的异常处理 ;/=.386(批:好象汇编程序都要写个头的,没怎么研究过汇编) .model flat, stdcall option casemap :none ; case sensitive include hd.h ;/相关的头文件，你自己维护一个吧 ;/= .data(批:可能是说以下是数据区吧,我也不太懂) szCap db By HumeAfO,2001.,0 szMsgOK db Its now in the Per_Thread handler!,0 szMsgERR1 db It would never Get here!,0 buff db 200 dup(0) .code(批:可能是说代码区) _start: (批:函数的开始,这些应该都是给汇编编译器处理的吧,估计不涉及生成机器代码);/=prog begin= ASSUME FS:NOTHING push offset perThread_Handler push fs:0 mov fs:0,esp ;/建立SEH的基本ERR结构,如果不明白,就仔细研究一下吧 xor ecx,ecx mov eax,200 cdq ；/双字扩展到四个字节，因为是除法 div ecx ;/以下永远不会被执行 invoke MessageBox,NULL,addr szMsgERR1,addr szCap,MB_OK+MB_ICONINFORMATION pop fs:0 add esp,4 invoke ExitProcess,NULL ;/= perThread_Handler: (批:函数名?)invoke MessageBox,NULL,addr szMsgOK,addr szCap,MB_OK+MB_ICONINFORMATION mov eax,1 ;/ExceptionContinueSearch,不处理,由其他例程或系统处理 ;mov eax,0 ;/ExceptionContinueExecution,表示已经修复CONTEXT,可从异常发生处继续执行 ret ;/这里如果返回0,你会陷入死循环,不断跳出对话框. ;/=Prog Ends= end _start程序本身很简单，注释也很详细。我们来看看是如何注册回调函数的push offset perThread_Handler (批:回调函数的写法和普通函数有区别吗?) push fs:0 mov fs:0,esp 仅仅三个语句就解决了那么为什么要用fs这个段寄存器呢？这里又涉及一个重要的内容：TIB（Thread Information Block线程信息块）。我们来看看这个重要的数据结构（引用了罗聪浅谈利用SEB实现反跟踪的部分内容）TEB(Thread Environment Block) 在 Windows 9x 系列中被称为 TIB(Thread Information Block)，它记录了线程的重要信息，而且每一个线程都会对应一个 TEB 结构。 Matt Pietrek 大牛已经给我们列出了它的结构，我就不多说啦，见下：（摘自 Matt Pietrek 的 Under The Hood - MSJ 1996） /= / file: TIB.H / Author: Matt Pietrek / From: Microsoft Systems Journal Under the Hood, May 1996 /= #pragma pack(1) typedef struct _EXCEPTION_REGISTRATION_RECORD struct _EXCEPTION_REGISTRATION_RECORD * pNext; FARPROC pfnHandler; EXCEPTION_REGISTRATION_RECORD, *PEXCEPTION_REGISTRATION_RECORD; typedef struct _TIB PEXCEPTION_REGISTRATION_RECORD pvExcept; / 00h Head of exception record list PVOID pvStackUserTop; / 04h Top of user stack PVOID pvStackUserBase; / 08h Base of user stack union / 0Ch (NT/Win95 differences) struct / Win95 fields WORD pvTDB; / 0Ch TDB WORD pvThunkSS; / 0Eh SS selector used for thunking to 16 bits DWORD unknown1; / 10h WIN95; struct / WinNT fields PVOID SubSystemTib; / 0Ch ULONG FiberData; / 10h WINNT; TIB_UNION1; PVOID pvArbitrary; / 14h Available for application use struct _tib *ptibSelf; / 18h Linear address of TIB structure union / 1Ch (NT/Win95 differences) struct / Win95 fields WORD TIBFlags; / 1Ch WORD Win16MutexCount; / 1Eh DWORD DebugContext; / 20h DWORD pCurrentPriority; / 24h DWORD pvQueue; / 28h Message Queue selector WIN95; struct / WinNT fields DWORD unknown1; / 1Ch DWORD processID; / 20h DWORD threadID; / 24h DWORD unknown2; / 28h WINNT; TIB_UNION2; PVOID* pvTLSArray; / 2Ch Thread Local Storage array union / 30h (NT/Win95 differences) struct / Win95 fields PVOID* pProcess; / 30h Pointer to owning process database WIN95; TIB_UNION3; TIB, *PTIB; #pragma pack()让我们抬头看看上面的 Matt Pietrek 的代码，其中有这么一行： PEXCEPTION_REGISTRATION_RECORD pvExcept; / 00h Head of exception record list 注意到 PEXCEPTION_REGISTRATION_RECORD 这个定义，它表示 pvExcept 这个变量正是 exception record list 的入口，这个入口位于整个结构的 0 偏移处。同时，在 M 的 Intel i386 Windows NT/2K/XP 内核中，每当创建一个线程，OS 均会为每个线程分配 TEB ，而且 TEB 永远放在 fs 段选择器指定的数据段的 0 偏移处。 这样一来，你就明白了 SEH 注册的偏移为什么是在 fs:0 了吧？ 事实上 Windows 系统都是通过这种方法来为应用程序提供信息的，比如有这样的例子： struct _tib *ptibSelf; / 18h Linear address of TIB structure (批:程序的例子里怎么都是说TIB,好象是TEB才对.)DWORD threadID; / 24h Windows 提供了一个 API ：GetCurrentThreadID()，它的内部工作原理其实是这样的：（利用了上面的这两个地址） mov eax, fs:18h ;因为 18h 偏移处是 TIB 结构的线性偏移地址(批:取TIB结构?) mov eax, eax + 24h ;因为 24h 偏移处是 threadID 的地址(批:取threadID 的地址?) ret ;把 eax 中储存的 threadID 地址返回注：为什么要声明assume fs:nothing?因为masm编译器默认将fs段寄存器定义为error，所以程序在使用fs前必须将它启动！接下来看看SEH的回调函数_Handler proc _lpExecptionRecord, _lpSEH,lp_context,lp_DispatcherContext_lpExecptionRecord指向一个EXECPTION_RECORD结构。lp_context 指向一个CONTEXT结构。_lpSEH 指向注册回调函数时使用的EXXCEPTION_REGISTRATION结构的地址。返回值有四种取值：ExecptionContinueExecution ( 0 ：系统将线程环境设置为_lpContext指向的CONTEXT结构并继续执行。ExceptionContinueSearch（1）：回调函数拒绝处理这个异常，系统通过EXECPTION_REGISTRATION结构的prev字段得到前一个回调函数的地址并调用它。ExecptionNestedExecption （2）：发生异常嵌套。ExecptionCollidedUnwind （3）：异常展开操作。这一个部分不做多讲，有兴趣的可以看看罗云彬的书，其实是很重要的一部分。如果一个程序既有筛选器异常处理又有SEH异常处理，而且系统还有默认的异常处理机制，那么他们被调用的先后次序是怎么样的呢？发生异常时系统的处理顺序(by Jeremy Gordon): 1.系统首先判断异常是否应发送给目标程序的异常处理例程,如果决定应该发送,并且目标程序正在被调试,则系统挂起程序并向调试器发送EXCEPTION_DEBUG_EVENT消息.呵呵,这不是正好可以用来探测调试器的存在吗? 2.如果你的程序没有被调试或者调试器未能处理异常,系统就会继续查找你是否安装了线程相关的异常处理例程,如果你安装了线程相关的异常处理例程,系统就把异常发送给你的程序seh处理例程,交由其处理. 3.每个线程相关的异常处理例程可以处理或者不处理这个异常,如果他不处理并且安装了多个线程相关的异常处理例程,可交由链起来的其他例程处理. 4.如果这些例程均选择不处理异常,如果程序处于被调试状态,操作系统仍会再次挂起程序通知debugger. 5.如果程序未处于被调试状态或者debugger没有能够处理,并且你调用SetUnhandledExceptionFilter安装了最后异 常处理例程的话,系统转向对它的调用. 6.如果你没有安装最后异常处理例程或者他没有处理这个异常,系统会调用默认的系统处理程序,通常显示一个对话框, 你可以选择关闭或者最后将其附加到调试器上的调试按钮.如果没有调试器能被附加于其上或者调试器也处理不了,系统就调用ExitProcess终结程序. 7.不过在终结之前,系统仍然对发生异常的线程异常处理句柄来一次展开,这是线程异常处理例程最后清理的机会.说了这么多你也许会问SEH异常处理到底有什么用处呢？呵呵，且听小生慢慢道来第一道菜：病毒程序巧用SEH这里简单的说一下如何利用SEH异常处理程序来躲避下毒软件的反病毒引擎。一个反病毒引擎在一个程序运行的时候会模拟程序的代码，当发现程序代码的疑点比较多的时候会报告成病毒。看看下面这段程序：start:call Set_SEH;这句其实就是 push offset CONTINUE; JMP Set_SEHCONTINUE:mov esp, esp+8; ESP+8存储的是旧的堆栈地址。push offset Start_Virus ;-_ 把Start_Virus 的地址压栈，当作返回地址ret;-跳到Start_Virus去，是不是很magic? Set_SEH:sub edx, edx ;Edx =0 Assume fs:nothing push dword ptr fs:edx;把指去 _EXCEPTIONAL_REGISTRATION_RECORD 结构的指针入栈mov fs:edx, esp;安装一个sehmov edx,edx;引起一个内存读写冲突，发生异常因为edx=0 ;如果反病毒引擎不处理异常，不进入seh 处理程序(即 CONTINUE: ，继续模 ;拟下个指令，也就是jmp start，那么就进入一个死循环，可能会引起死机。 jmp start Start_Virus: .是不是很简单呢？就是让反病毒引擎不处理这个人为的异常时进入死循环！第二道菜：TEB反跟踪初探如果你的记性够好的话一定记得上面介绍过的TEB（TIB）线程信息块结构中有这么一句：(批:TEB与TIB相同?)PVOID* pProcess; / 30h Pointer to owning process database 这个偏移地址处的内容非常有用，它指向本线程的拥有者的 PDB(Process Database) 的线性地址。当你用动态调试器，例如 OllyDbg 的时候，调试器是把调试的对象作为一个子线程进行跟踪的，在这种情况下，被调试的对象的“拥有者”就是调试器本身，也就是说，它的 TEB 的 30h 处的偏移指向的内容肯定不为 0 ，这样，我们就可以利用这一点，判断 30h 偏移指向的内容，来判断是否有调试器跟踪。 最后给出一个 Anti-Debug 的例子程序，用 MASM 编译完成后，请用 OllyDbg 来加载调试一下，看看与正常的运行结果有什么不同。 ;* ;程序名称：演示利用 TEB 结构进行 Anti-Debug ; 请用 OllyDbg 进行调试 ;适用OS：Windows NT/2K/XP ;作者：罗聪 ;日期：2003-2-9 ;出处：http:/www.LuoC（老罗的缤纷天地） ;注意事项：如欲转载，请保持本程序的完整，并注明： ;转载自“老罗的缤纷天地”（http:/www.LuoC） ;* .386 .model flat, stdcall option casemap:none include masm32includewindows.inc include masm32includekernel32.inc include masm32includeuser32.inc includelib masm32libkernel32.lib includelib masm32libuser32.lib .data szCaption db Anti-Debug Demo by LC, 2003-2-9, 0 szDebugged db Hah, let me guess. U r dEBUGGINg me! , 0 szFine db Good boy, no dEBUGGEr detected!, 0 .code main: assume fs:nothing mov eax, fs:30h ;指向 PDB(Process Database) movzx eax, byte ptr eax + 2h；无符号数带