rminateThread，系统可以劫持到本地创建的全部线程。
[0124] 其中，对这些值的维护，保护系统使用stl中的map来维护Threadld的值。
[0125] -旦有一个本地的线程建立，操作系统的ZwCreateThreadEx函数一定会被调用， 保护系统将从map中加入当前值。
[0126] -旦有一个本地线程主动退出或者被动退出，操作系统会自动调用 ZwTerminateThread这个API函数，保护系统会从map中删除这个值。
[0127] 当保护dll的DllMain入口点收到DLL_THREAD_ATTACH的通知，此时调用 GetCurrentThreadld就能检查是否是当前进程创建的线程，如果不是，那么就是远程注入 的。
[0128] 但是因为不是本地调用的，就算我们在本地是无法通过劫持这三个API达到监视 目的的。然而全局Hook不仅可能不稳定，还可能大幅度降低系统的运行速度，这个做法也是 不可取的。
[0129] 然而，在exe被远程调用CreateRemoteThread注入dl 1的时候，这个时候，在内核会 为被注入的进程创建一个线程。自然而然，所有已加载的dll会在DllMain入口点收到DLL_ THREAD_ATTACH的通知，此时调用GetCurrentThreadld的时候就能获取当前创建的线程id。 接着保护dll从ntdll处Hook ZwCreateThreadEx ZwTerminateThread，系统可以劫持到本 地创建的全部线程。
[0130] 其中，对这些值的维护，保护系统使用stl中的map来维护Threadld的值。
[0131 ] -旦有一个本地的线程建立，操作系统的ZwCreateThreadEx函数一定会被调用。
[0132] 一旦有一个本地线程主动退出或者被动退出，操作系统会自动调用 ZwTerminateThread 这个 API 函数。
[0133] map<UL0NG,UL0NG>ThreadTree；
[0134] 在这，我们可以先判断一下，整个进程是不是由Debugger启动的：
[0135] STARTUPINFOff si；
[0136] GetStartupInfoff(&si)；
[0137] 获取该应用程序的启动信息，如果其中的si .dwFillAttribute值不为0,就可以认 为该进程是由Debugger启动的，如果不是，则继续。
[0138] 获取当前进程的主线程。
[0139] 加载器不会启动本身不会启动附带的线程，别的dll线程对于加载器都是透明的， 所以保护系统使用时间比较的方式找出当前系统的主线程。
[0140] 先使用Thread32First这个API遍历当前系统中的全部API。
[0141] THREADENTRY32pe32={sizeof(pe32)}；
[0142] if(Thread32First(hThreadSnap,&pe32)){···}
[0143] 对于每个API使用GetThreadTimes获取创建时间：
[0144] GetThreadTimes(handle,&createtime,&time2,&time3,&time4)；
[0145] 最后再遍历一次全部Thread的创建时间，最小的那个就是当前进程的主线程，因 为它最早被创建。
[0146] 将这个值添加到ThreadTree中。
[0147]全部的用户线程创建都是从ZwCreateThreadEx提交到内核进行创建的，同理 ZwTerminateThread也是用于结束对用的代码。
[0148] 和公开的CreateThread不同的是，ZwCreateThreadEx可以提交进程的Handle来指 定为哪个进程创建线程。只要进程为自己创建了一个进程，就在ThreadTree中插入该线程 id，同理，调用ZwTerminateThread的时候也从查找树中删除对应的记录。
[0149] 当保护dll的DllMain入口点收到DLL_THREAD_ATTACH的通知，此时调用 GetCurrentThreadld就能检查是否是当前进程创建的线程，如果不是，那么就是远程注入 的。
[0150]考虑到有些和安全相关的进程，不得不使用线程注入来保证自己的安全性能，所 以系统主动劫持了位于ntdll中的LdrpLoadDll来检查当前注入系统的dll镜像是否是受验 证的，或者是自己希望的添加的dll动态链接库。保护系统提供了QueryLisence的函数接口 来过滤线程注入的dll。
[0151] 因为这个步骤6不能立刻获取到结果，所以做完底层劫持以后，直接执行第7步。
[0152] 7、建立保护线程
[0153] 建立一个优先度比较底的线程(THREAD_PRI0RITY_BEL0W_N0RMAL)，做死循环检 查，为了防止影响应用程序的性能，所以每一秒检查一次。检查的内容有:是否是Debugger 加载。
[0154] 直接从BYTE Ptr fs:[30]+2处获取到一个BYTE长度的数据，如果检测到Flag为1 的时候，使用SetUnhandledExceptionFilter设置一个Filter 函数，然后返回EXCEPTI0N_ EXECUTE_HANDLER，表明当前的异常已经处理，程序可以直接退出了。这样就可以做到反 Debugger的功能。
[0155] 如果Debugger能够很简单地加载被保护的应用程序的话，破解者可以直接在 Debugger中修改，最后dump内存镜像到达破解的目的。
[0156] 检查Debugger的最简单方式就是调用Kerne 132下的IsDebuggerPresent API函数 进行判断，但是这种调用API的方式不是最好的，如果破解者从别的地方恶意修改到了这个 API，那么Debugger检查也相当于形同虚设。
[0157] 当一个Debugger连接上目标进程的时候，进程中的PEB中的Debugger Flag会被置 为1，也就是BYTE Ptr fs:[30]+2处的数据会被置为1。保护器可以直接监视这个数值以达 到监视Debugger注入的功能。
[0158]
[0159] 保护器使用eax的低8位来保存这个flag。
[0160] 首先保持eax寄存器的值，然后将这个flag复制到al寄存器中，即eax寄存器的低8 位。最后把al寄存器的值保存到DebuggerFlag中并且恢复eax的原始值。
[0161] 如果检测到Flag为1的时候：
[0162] 使用SetUnhandledExceptionFilter设置一个Filter函数，函数中可以输出一些 出错信息，然后返回EXCEPTION_EXECUTE_HANDLER，表明当前的异常已经处理，程序可以直 接退出了。
[0163] SetUnhandledExceptionFi1ter(DebuggerFiIter)
[0164]这样，系统达到了反Debugger的功能。
[0165] 反 Dump:
[0166] 如果加载器使用了虚拟化之类的加密技术，那么dump出来镜像也是不可运行的。
[0167] 如果加载器没有做任何加密，问题也不大，因为本发明的加载方式可以保证受保 护的文件不能直接被dump，因为当前运行进程是加载器的进程，如果不使用Debugger进行 调试，受保护程序的代码段不能直接通过API获取到。
[0168] 采用本专利可以达到如下有益效果：
[0169] 当前保护界中，一般有三种保护手段：
[0170] 第一种是加壳，其中分为加密壳和压缩壳。
[0171] 第二种是驱动保护。
[0172]第三种是代码虚拟化技术。
[0173] 加壳保护保护能有效防止受保护对象被静态反编译或者是一定程度上防止动态 调试。但是因为保护较弱，现在一般不会单独拿出来使用。
[0174] 而具有强大保护功能的代码虚拟化技术本质上就是将本地代码转换成虚拟机代 码，然后在运行的时候又即时翻译成本地代码。这种技术能有效防止代码被静态编译或者 是代码被动态调试，因为调试器无法识别对方镜像中的代码。但是代码虚拟化技术不具有 保护API的功能。由于代码需要及时翻译才能执行，代码虚拟化后，受保护镜像的运行速度 会大幅度降低。所以这种保护方式只适用于较小的软件产品而且对执行速度要求不高。
[0175] 本发明的优点：
[0176] 1、本发明提供了一种新的方式，将代码植入加载器中。由于加载器加载镜像的时 候是随机定位的，并且受保护镜像对操作系统是透明的，所以目前的进程监视器是无法监 视到受保护镜像的。并且本专利使用了 dll劫持作为镜像保护的方法，从镜像加载前就获取 到镜像的控制权，对受保护镜像进行监视，能有效防止受保护镜像受到恶意修改。再加上受 保护镜像是完全加密的，所以调试器是完全无法加载受保护的镜像，从根本上防止了反调 试。
[0177] 2、本发明使用的保护机制都是快速的，甚至能使保护后代码执行的速度比保护前 更快。而本发明适用的范围就是软件受保护的同时，还能快速执行的场合。
【附图说明】
[0178] 图1为:加密镜像所使用的文件头。
[0179] 图2为:本发明使用的加密算法，每隔32个字节更新一次加密数组。
[0180] 图3为:PE文件头文本提及的部分。
[0181]图4为;尝试使用OllyDbg加载受保护的镜像。
[0182]图5为;已经加载的镜像模块。
[0183]图6为:查看本进程的内存区域，找不到可疑的模块。
[0184]图7为