文件头里面有一个文件值属性IMAGE_FILE_HEADER.Characteristics
EXE:010F(H)
DLL:210(H)
exe和dll的加载基址不一样,NT头偏移0x34位置的4字节数据，记录着程序的默认加载基址
exe的默认加载基址：0x00400000
DLL的默认加载基址：0x10000000
NT头的扩展头(IMAGE_OPTIONAL_HEADER )的magic：WORD Magic;
32位是0x010B，64位是0x020B，0x0170代表ROM镜像。
调用CreateProcess启动，生产内核对象，分配4GB进程空间，系统加载器加载dll文件以及完成重定位,IAT,接着创建进程的主线程，
之后主线程为每个DLL调用_DLLMainCRTStartup函数，然后主线程根据EXE是GUI（图形化）程序还是CUI（控制台）程序执行MainCRTStartup
最后一步执行WinMain(或者main函数)
ReadFile读取文件头信息，判断是否是PE文件
获取映像总大小，申请可读可写可执行的内存全部填为0
获取区段信息，循环读取每一个区段内容，将ReadFile读取的数据映射到内存中
修复重定位
修复IAT
创建线程，线程回调指向OEP
cdecl：是C和C++程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码，所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式。注意：对于可变参数的成员函数，始终使用 cdecl的转换方式。C语言默认的函数调用方法:所有参数从右到左依次入栈,这些参数由调用者清除,称为手动清栈。平衡堆栈是从由调用者平衡堆栈（函数外部平衡堆栈），例如 printf 函数stdcall：函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，通常用于Win32 API中。平衡堆栈是在函数内部平衡堆栈，例如：windows的函messageboxfastcall：它是通过寄存器来传送参数的（实际上，它用ECX和EDX传送前两个双字（DWORD）或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回 前清理传送参数的内存栈）。thiscall：仅仅应用于"C++"成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。只不过前两个参数右寄存器ecx和edx传参（就是rcx,rdx,r8,r9传参）16位cpu通用寄存器共有 8 个：AX,BX,CX,DX,BP,SP,SI,DI.
32位cpu通用寄存器共有 8 个：EAX,EBX,ECX,EDX,EBP,ESP,ESI,EDI功能和上面差不多
通过API：GetProcAddress，根据函数名获取函数地址。
通过名称找地址 : 遍历名称表,得到序号表中保存的地址表下标,然后从地址表中索引出地址
INT n/INTO/INT 3—Call to Interrupt Procedure
Opcode Instruction Description
CC INT 3 A Valid Valid Interrupt 3 — trap to debugger.
CD ib INT imm8 Interrupt vector number specified by immediate byte.
【CC】
The INT 3 instruction generates a special one byte opcode (CC) that is intended for
calling the debug exception handler. (This one byte form is valuable because it can be
used to replace the first byte of any instruction with a breakpoint, including other one
byte instructions, without over-writing other code).
【CD 03】
Note that the “normal” 2-byte opcode for INT 3 (CD03) does not have these special
features. Intel and Microsoft assemblers will not generate the CD03 opcode from any
mnemonic, but this opcode can be created by direct numeric code definition or by
self-modifying code.
ReadProcessMemory，读取断点内存地址的字节。WriteProcessMemory，将指定的内存地址指令写为0xCC。CC指令，会从IDT表中查03号段描述符，其会定向到Trap03函数。
加壳
花指令
时间检查
API：IsDebuggerPresent和CheckRemoteDebuggerPresent
PEB的调试标记位：BeingDebugged //一个char类型.为1表示调试状态.为0表示没有调试.可以用于反调试. API也是从这里获取的标志
TLS Callback，利用TLS回调函数：在TLS回调函数中加入反调试代码的方法来进行的反调试手段
检测是否有OD，x64dbg，windbg等调试器进程
恶意代码会使用多种技术探测调试器调试它的痕迹，其中包括使用Windows API、手动检测调试器人工痕迹的内存结构和查询调试器遗留在系统中的痕迹等。调试器探测是恶意代码最常用的反调试技术。
1.1 IsDebuggerPresent
IsDebuggerPresent查询进程环境块(PEB)中的IsDebugged标志。如果进程没有运行在调试器环境中，函数返回0；如果调试附加了进程，函数返回一个非零值。
1.2 CheckRemoteDebuggerPresent
CheckRemoteDebuggerPresent同IsDebuggerPresent几乎一致。它不仅可以探测系统其他进程是否被调试，通过传递自身进程句柄还可以探测自身是否被调试。
1.3 NtQueryInformationProcess
这个函数是Ntdll.dll中一个API，它用来提取一个给定进程的信息。它的第一个参数是进程句柄，第二个参数告诉我们它需要提取进程信息的类型。为第二个参数指定特定值并调用该函数，相关信息就会设置到第三个参数。第二个参数是一个枚举类型，其中与反调试有关的成员有ProcessDebugPort(0x7)、ProcessDebugObjectHandle(0x1E)和ProcessDebugFlags(0x1F)。例如将该参数置为ProcessDebugPort，如果进程正在被调试，则返回调试端口，否则返回0。
1.4 GetLastError
编写应用程序时，经常需要涉及到错误处理问题。许多函数调用只用TRUE和FALSE来表明函数的运行结果。一旦出现错误，MSDN中往往会指出请用GetLastError()函数来获得错误原因。恶意代码可以使用异常来破坏或者探测调试器。调试器捕获异常后，并不会立即将处理权返回被调试进程处理，大多数利用异常的反调试技术往往据此来检测调试器。多数调试器默认的设置是捕获异常后不将异常传递给应用程序。如果调试器不能将异常结果正确返回到被调试进程，那么这种异常失效可以被进程内部的异常处理机制探测。
对于OutputDebugString函数，它的作用是在调试器中显示一个字符串，同时它也可以用来探测调试器的存在。使用SetLastError函数，将当前的错误码设置为一个任意值。如果进程没有被调试器附加，调用OutputDebugString函数会失败，错误码会重新设置，因此GetLastError获取的错误码应该不是我们设置的任意值。但如果进程被调试器附加，调用OutputDebugString函数会成功，这时GetLastError获取的错误码应该没改变。
1.5 ZwSetInformationThread
ZwSetInformationThread拥有两个参数，第一个参数用来接收当前线程的句柄，第二个参数表示线程信息类型，若其值设置为ThreadHideFromDebugger(0x11)，使用语句ZwSetInformationThread(GetCurrentThread(), ThreadHideFromDebugger, NULL, 0);调用该函数后，调试进程就会被分离出来。该函数不会对正常运行的程序产生任何影响，但若运行的是调试器程序，因为该函数隐藏了当前线程，调试器无法再收到该线程的调试事件，最终停止调试。还有一个函数DebugActiveProcessStop用来分离调试器和被调试进程，从而停止调试。两个API容易混淆，需要牢记它们的区别。
2.1 检测BeingDebugged属性
Windows操作系统维护着每个正在运行的进程的PEB结构，它包含与这个进程相关的所有用户态参数。这些参数包括进程环境数据，环境数据包括环境变量、加载的模块列表、内存地址，以及调试器状态。
进程运行时，位置fs:[30h]指向PEB的基地址。为了实现反调试技术，恶意代码通过这个位置检查BeingDebugged标志，这个标志标识进程是否正在被调试。
2.2 检测ProcessHeap属性
Reserved数组中一个未公开的位置叫作ProcessHeap，它被设置为加载器为进程分配的第一个堆的位置。ProcessHeap位于PEB结构的0x18处。第一个堆头部有一个属性字段，它告诉内核这个堆是否在调试器中创建。这些属性叫作ForceFlags和Flags。在Windows XP系统中，ForceFlags属性位于堆头部偏移量0x10处；在Windows 7系统中，对于32位的应用程序来说ForceFlags属性位于堆头部偏移量0x44处。
2.3 检测NTGlobalFlag
由于调试器中启动进程与正常模式下启动进程有些不同，所以它们创建内存堆的方式也不同。系统使用PEB结构偏移量0x68处的一个未公开位置，来决定如何创建堆结构。如果这个位置的值为0x70，我们就知道进程正运行在调试器中。
通常，我们使用调试工具来分析恶意代码，但这些工具会在系统中驻留一些痕迹。恶意代码通过搜索这种系统痕迹，来确定你是否试图分析它。
3.1 查找调试器引用的注册表项
下面是调试器在注册表中的一个常用位置。
SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug(32位系统)
SOFTWARE\Wow6432Node\Microsoft\WindowsNT\CurrentVersion\AeDebug(64位系统)
该注册表项指定当应用程序发生错误时，触发哪一个调试器。默认情况下，它被设置为Dr.Watson。如果该这册表的键值被修改为OllyDbg，则恶意代码就可能确定它正在被调试。
3.2 查找窗体信息
FindWindow函数检索处理顶级窗口的类名和窗口名称匹配指定的字符串。
3.3 查找进程信息
如：OllyDBG.EXE，OllyICE.exe，x64_dbg.exe，windbg.exe，ImmunityDebugger.exe
在逆向工程中，为了帮助恶意代码分析人员进行分析，可以使用调试器设置一个断点，或是单步执行一个进程。然而，在调试器中执行这些操作时，它们会修改进程中的代码。因此，恶意代码常使用几种反调试技术探测软件/硬件断点、完整性校验、时钟检测等几种类型的调试器行为。直接运行恶意代码与在调试器中运行恶意代码也会在一些细节上不同，如父进程信息、STARTUPINFO信息、SeDebugPrivilege权限等。
调试器设置断点的基本机制是用软件中断指令INT 3临时替换运行程序中的一条指令，然后当程序运行到这条指令时，调用调试异常处理例程。INT 3指令的机器码是0xCC，因此无论何时，使用调试器设置一个断点，它都会插入一个0xCC来修改代码。恶意代码常用的一种反调试技术是在它的代码中查找机器码0xCC，来扫描调试器对它代码的INT 3修改。repne scasb指令用于在一段数据缓冲区中搜索一个字节。EDI需指向缓冲区地址，AL则包含要找的字节，ECX设为缓冲区的长度。当ECX=0或找到该字节时，比较停止。
在OllyDbg的寄存器窗口按下右键，点击View debug registers可以看到DR0、DR1、DR2、DR3、DR6和DR7这几个寄存器。DR0、Dr1、Dr2、Dr3用于设置硬件断点，由于只有4个硬件断点寄存器，所以同时最多只能设置4个硬件断点。DR4、DR5由系统保留。 DR6、DR7用于记录Dr0-Dr3中断点的相关属性。如果没有硬件断点，那么DR0、DR1、DR2、DR3这4个寄存器的值都为0。
恶意代码可以计算代码段的校验并实现与扫描中断相同的目的。与扫描0xCC不同，这种检查仅执行恶意代码中机器码CRC或者MD5校验和检查。
被调试时，进程的运行速度大大降低，例如，单步调试大幅降低恶意代码的运行速度，所以时钟检测是恶意代码探测调试器存在的最常用方式之一。有如下两种用时钟检测来探测调试器存在的方法。
记录一段操作前后的时间戳，然后比较这两个时间戳，如果存在滞后，则可以认为存在调试器。
记录触发一个异常前后的时间戳。如果不调试进程，可以很快处理完异常，因为调试器处理异常的速度非常慢。默认情况下，调试器处理异常时需要人为干预，这导致大量延迟。虽然很多调试器允许我们忽略异常，将异常直接返回程序，但这样操作仍然存在不小的延迟。
4.1 使用rdtsc指令
较常用的时钟检测方法是利用rdtsc指令(操作码0x0F31)，它返回至系统重新启动以来的时钟数，并且将其作为一个64位的值存入EDX:EAX中。恶意代码运行两次rdtsc指令，然后比较两次读取之间的差值。
4.2 使用QueryPerformanceCounter和GetTickCount
同rdtsc指令一样，这两个Windows API函数也被用来执行一个反调试的时钟检测。使用这种方法的前提是处理器有高分辨率能力的计数器-寄存器，它能存储处理器活跃的时钟数。为了获取比较的时间差，调用两次QueryPerformanceCounter函数查询这个计数器。若两次调用之间花费的时间过于长，则可以认为正在使用调试器。GetTickCount函数返回最近系统重启时间与当前时间的相差毫秒数(由于时钟计数器的大小原因，计数器每49.7天就被重置一次)。
一般双击运行的进程的父进程都是explorer.exe，但是如果进程被调试父进程则是调试器进程。也就是说如果父进程不是explorer.exe则可以认为程序正在被调试。
explorer.exe创建进程的时候会把STARTUPINFO结构中的值设为0，而非explorer.exe创建进程的时候会忽略这个结构中的值，也就是结构中的值不为0。所以可以利用STARTUPINFO来判断程序是否在被调试。
默认情况下进程是没有SeDebugPrivilege权限的，但是当进程通过调试器启动时，由于调试器本身启动了SeDebugPrivilege权限，当调试进程被加载时SeDebugPrivilege也就被继承了。所以我们可以检测进程的SeDebugPrivilege权限来间接判断是否存在调试器，而对SeDebugPrivilege权限的判断可以用能否打开csrss.exe进程来判断。
恶意代码可以用一些技术来干扰调试器的正常运行。例如线程本地存储(TLS)回调、插入中断、异常等。这些技术当且仅当程序处于调试器控制之下时才试图扰乱程序的运行。
Thread Local Storage(TLS)，即线程本地存储，是Windows为解决一个进程中多个线程同时访问全局变量而提供的机制。TLS可以简单地由操作系统代为完成整个互斥过程，也可以由用户自己编写控制信号量的函数。当进程中的线程访问预先制定的内存空间时，操作系统会调用系统默认的或用户自定义的信号量函数，保证数据的完整性与正确性。下面是一个简单的TLS回调的例子，TLS_CALLBACK1函数在main函数执行前调用IsDebuggerPresent函数检查它是否正在被调试。
因为调试器使用INT 3来设置软件断点，所以一种反调试技术就是在合法代码段中插入0xCC(INT 3)欺骗调试器，使其认为这些0xCC机器码是自己设置的断点。
除了使用_try和_except以外还可以直接使用汇编代码安装SEH。在下面的代码中如果进程没有处于调试中，则正常终止；如果进程处于调试中，则跳转到非法地址0xFFFFFFFF处，无法继续调试。
双字节操作码0xCD03也可以产生INT 3中断，这是恶意代码干扰WinDbg调试器的有效方法。在调试器外，0xCD03指令产生一个STATUS_BREAKPOINT异常。然而在WinDbg调试器内，由于断点通常是单字节机器码0xCC，因此WinDbg会捕获这个断点然后将EIP加1字节。这可能导致程序在被正常运行的WinDbg调试时，执行不同的指令集(OllyDbg可以避免双字节INT 3的攻击)。
INT 2D原为内核模式中用来触发断点异常的指令，也可以在用户模式下触发异常。但程序调试运行时不会触发异常，只是忽略。INT 2D指令在ollydbg中有两个有趣的特性。在调试模式中执行INT 2D指令，下一条指令的第一个字节将被忽略。使用StepInto(F7)或者StepOver(F8)命令跟踪INT 2D指令，程序不会停在下一条指令开始的地方，而是一直运行，就像RUN(F9)一样。在下面的代码中，程序调试运行时，执行INT 2D之后不会运行SEH，而是跳过NOP，把bDebugging标志设置为1，跳转到normal_code；程序正常运行时，执行INT 2D之后触发SEH，在异常处理器中设置EIP并把bDebugging标志设置为0。
片内仿真器(ICE)断点指令ICEBP(操作码0xF1)是Intel未公开的指令之一。由于使用ICE难以在任意位置设置断点，因此ICEBP指令被设计用来降低使用ICE设置断点的难度。运行ICEBP指令将会产生一个单步异常，如果通过单步调试跟踪程序，调试器会认为这是单步调试产生的异常，从而不执行先前设置的异常处理例程。利用这一点，恶意代码使用异常处理例程作为它的正常执行流程。为了防止这种反调试技术，执行ICEBP指令时不要使用单步。
EFLAGS寄存器的第八个比特位是陷阱标志位。如果设置了，就会产生一个单步异常。
前面已经讨论了各种使用异常机制的反调试手段。
4.1 RaiseException
RaiseException函数产生的若干不同类型的异常可以被调试器捕获。
4.2 SetUnhandledExceptionFilter
进程中发生异常时若SEH未处理或注册的SEH不存在，会调用UnhandledExceptionFilter，它会运行系统最后的异常处理器。UnhandledExceptionFilter内部调用了前面提到过的NtQueryInformationProcess以判断是否正在调试进程。若进程正常运行，则运行最后的异常处理器；若进程处于调试，则将异常派送给调试器。SetUnhandledExceptionFilter函数可以修改系统最后的异常处理器。下面的代码先触发异常，然后在新注册的最后的异常处理器内部判断进程正常运行还是调试运行。进程正常运行时pExcept->ContextRecord->Eip+=4;将发生异常的代码地址加4使得其能够继续运行；进程调试运行时产生无效的内存访问异常，从而无法继续调试。
在OllyDbg中，选择Options->Debugging Options->Exceptions来设置把异常传递给应用程序。
与所有软件一样，调试器也存在漏洞，有时恶意代码编写者为了防止被调试，会攻击这些漏洞。这里我们展示几种OllyDbg调试器处理PE格式文件时的常见漏洞。
OllyDbg非常严格地遵循了微软对PE文件头部的规定。在PE文件的头部，通常存在一个叫作IMAGE_OPTIONAL_HEADER的结构。
需要特别注意这个结构中的最后几个元素。NumberOfRvaAndSizes属性标识后面DataDirectory数组中的元素个数。DataDirectory数组表示在这个可执行文件中的什么地方可找到其他导入可执行模块的位置，它位于可选头部结构的末尾，是一个比IMAGE_DATA_DIRECTORY略大一些的数组。数组中每个结构目录都指明了目录的相对虚拟地址和大小。DataDirectory数组的大小被设置为IMAGE_NUMBEROF_DIRECTORY_ENTRIES，它等于0x10。因为DataDirectory数组不足以容纳超过0x10个目录项，所以当NumberOfRvaAndSizes大于0x10时，Windows加载器将会忽略NumberOfRvaAndSizes。OllyDbg遵循了这个标准，并且无论NumberOfRvaAndSizes是什么值，OllyDbg都使用它。因此，设置NumberOfRvaAndSizes为一个超过0x10的值，会导致在程序退出前，OllyDbg对用户弹出一个窗口。如图所示，使用LordPE打开可执行文件，修改RVA数及大小并保存，再用OllyDbg打开，会提示错误Bad or unknown format of 32-bit executable file。
另一种PE头的欺骗与节头部有关。文件内容中包含的节包括代码节、数据节、资源节，以及一些其他信息节。每个节都拥有一个IMAGE_SECTION_HEADER结构的头部。
VirtualSize和SizeOfRawData是其中两个比较重要的属性。根据微软对PE的规定，VirtualSize应该包含载入到内存的节大小，SizeOfRawData应该包含节在硬盘中的大小。Windows加载器使用VirtualSize和SizeOfRawData中的最小值将节数据映射到内存。如果SizeOfRawData大于VirtualSize，则仅将VirtualSize大小的数据复制入内存，忽略其余数据。因为OllyDbg仅使用SizeOfRawData，所以设置SizeOfRawData为一个类似0x77777777的大数值时，会导致OllyDbg崩溃。如图所示，使用LordPE打开可执行文件，点击区段，在区段表上右击，点击编辑区段，修改物理大小并保存，再用OllyDbg打开，会提示同样的错误。
对抗这种反调试技术的最简单方法是用类似的编辑器手动修改PE头部。OllyDbg2.0和WinDbg不存在这种漏洞。
恶意代码常尝试利用OllyDbg1.1的格式化字符串漏洞，为OutputDebugString函数提供一个%s字符串的参数，让OllyDbg崩溃。因此，需要注意程序中可疑的OutputDebugString调用，例如OutputDebugString("%s%s%s%s%s%s%s%s%s")。如果执行了这个调用，OllyDbg将会崩溃。
钩子(Hook)，是Windows消息处理机制的一个平台，应用程序可以在上面设置子程以监视指定窗口的某种消息，而且所监视的窗口可以是其他进程所创建的。当消息到达后，在目标窗口处理函数之前处理它。钩子机制允许应用程序截获处理window消息或特定事件。
钩子实际上是一个处理消息的程序段，通过系统调用，把它挂入系统。每当特定的消息发出，在没有到达目的窗口前，钩子程序就先捕获该消息，亦即钩子函数先得到控制权。这时钩子函数即可以加工处理（改变）该消息，也可以不作处理而继续传递该消息，还可以强制结束消息的传递。
每一个Hook都有一个与之相关联的指针列表，称之为钩子链表，由系统来维护。这个列表的指针指向指定的，应用程序定义的，被Hook子程调用的回调函数，也就是该钩子的各个处理子程序。当与指定的Hook类型关联的消息发生时，系统就把这个消息传递到Hook子程。一些Hook子程可以只监视消息，或者修改消息，或者停止消息的前进，避免这些消息传递到下一个Hook子程或者目的窗口。最近安装的钩子放在链的开始，而最早安装的钩子放在最后，也就是后加入的先获得控制权。
微软官方提供的方法Ring3
SetWindowsHookEx
UnhookWindowsHookEx
CallNextHookEx
非官方方法 Ring0/Ring3
使用汇编代码编替换函数开始的汇编代码，使其跳转到我们的Hook函数中，非官方叫法：Inline hook
使用Hook函数地址替换调用函数地址（IAT hook/SSDT hook……）
API Hook - Inline Hook、SEH Hook、IAT Hook、SSDT Hook (Ring0)
应用层
消息Hook：SetWindowsHookEx
注入Hook：Inline HOOK、IAT HOOK、HotFix Hook
调试Hook：DebugActiveProcess
驱动层
SSDT HOOK、IDT HOOK、object HOOK、sysenter HOOK
HOOK技术主要分为两大类，一是内核层HOOK,一是用户层HOOK。
用户层HOOK也就是在ring3环境下hook kenerl32.dll、
User3.dll、Gui32.dll、Advapi.dll等导出的函数。
内核层HOOK就是HOOK只有ring0级别环境下才能操作写入改变的内核
对象，例如SSDT系统服务描述符表等。综合而言，主要有以下9种HOOK技术。
在注入技术中，DLL注入是最常见最有效的技术。作者通常把代码编写成一个动态链接库，然后把这个动态链接库加载到正常进程中去，因为任何一个进程在加载动态链接库时都要执行DLL文件里入口函数DllMain中的代码，这样代码才得以执行。
修改 HKEY_LOCAL_MACHINE/Software/Microsoft/WindowsNT/CurrentVersion/Windows/AppInit_DLLs 的键值，改为待注入DLL的路径，这样一来，程序运行后只要加载了user32.dll，都会加载我们写入的DLL。
Windows应用程序是基于消息驱动的，任何线程只要注册窗口类都会有一个消息队列用于接收用户输入的消息和系统消息。为了拦截消息，Windows提出了钩子的概念。钩子（Hook）是Windows消息处理机制中的一个监视点，钩子提供一个回调函数。当在某个程序中安装钩子后，它将监视该程序的消息，在指定消息还没到达窗口之前钩子程序先捕获这个消息。这样就有机会对此消息进行过滤，或者对Windows消息实现监控。 消息钩子分为局部钩子和全局钩子。局部钩子是指仅拦截某一个进程的消息，全局钩子将拦截系统中所有进程的消息。
该技术需要我们写一个简单的加载该DLL的程序，使其调用DLL的钩子函数，该函数会下一个全局消息钩子，强迫所有发生该消息的进程加载该DLL，这样就实现了DLL注入。
该方法需要我们熟悉PE结构，找到导入表位置在其后面添加一个新节，写入待注入的DLL，并将该DLL的导出函数的一些信息写到正确的位置，若导出函数过多将花费很多时间在手工修改上，并且可能出现空间不足写入的情况。
通过利用2000/XP等系统所有进程加载Kernel32.dll的模块基址一致的特点，先使用OpenProcess函数打开远程进程的句柄，再用VirtualAllocEx和WriteProcessMemory将待注入DLL路径写入目标进程，找到LoadLibraryW的地址，最后用CreateRemoteThread使目标进程调用LoadLibraryW加载DLL，参数为写入的DLL路径。
1. 获取指定进程句柄
OpenProcess
2. 在进程中申请一段内存
VirtualAllocEx
3. 把dll路径写入到进程内存中
WriteProcessMemory
4. 创建远程线程
CreateRemoteThread
5. 等待线程，释放空间
WaitForSingleObject
APC注入的原理是利用当线程被唤醒时APC中的注册函数会被执行的机制，并以此去执行我们的DLL加载代码，进而完成DLL注入的目的。利用QueueUserAPC()可以向APC队列投入Loadlibrary函数指针完成注入，其实这种方法配合CreateProcess使用注入最为简单，先挂起打开线程，再QueueUserAPC()，再恢复线程，完成注入。
自己实现应用程序的某个DLL，完成其导出函数，并将其放于应用程序目录下，当程序打开并加载DLL时会优先加载该目录下的DLL，原来的DLL若在该目录下降其移走即可。
利用输入法在工作时需要向进程中加载Ime文件（其实就是个Dll）,我们构造自己的Ime文件，在Ime文件注入对方进程的时候加载我们自己的DLL完成注入
对于病毒来讲，虽然远程注入DLL相对隐蔽，但是因为在被注入进程中多了个DLL模块，所以也没有做到完全隐蔽，而且也很容易将病毒清除。所以对于那些更高级的病毒则使用了更加隐蔽，更加难以清除的方法：远程代码注入。这是指，在远程进程中开辟足够大的内存空间，然后将要执行的代码直接写过去，最后使用远程线程的方法运行注入代码。这样做可以使其他进程执行病毒代码，而又不会在对方进程中产生新的模块，从而使病毒能够更隐蔽地运行。
使用二进制编辑工具打开目标程序，找到合适的地方写入二进制代码，将程序执行起始地址(AddressOfEntryPoint)改为注入代码处，在执行完后跳到源地址。
OpenThread–>SuspendThread–>申请内存–>写入代码–>GetThreadContext–>获取EIP–>修改EIP–>SetThreadContext–>ResumeThread。
CreateProcess注入方法之一，CREATE_SUSPENDED以挂起的方式打开进程，后面方法与挂起线程注入相似。
CreateProcess注入方法之二，DEBUG_ONLY_THIS_PROCESS以调试的方法打开进程，利用CREATE_PROCESS_DEBUG_EVENT，向目标程序中写入我们的ShellCode完成相应功能，并且我们的ShellCode中写入以CC断点，代码执行指令时触发EXCEPTION_DEBUG_EVENT事件，在EXCEPTION_DEBUG_EVENT的处理函数中回到原来的执行流程。
参考书籍：《计算机病毒揭秘与对抗》
参考网址：https://bbs.pediy.com/thread-217722.htm
转载于:https://www.cnblogs.com/RNGorgeous/p/8762001.html
留自启动后门方法很多,大多数时候都采用的是添加到服务，加注册表，加启动项
这部分由于我看了很多文章归类很乱，作为了解看下面的总结就行了，如果需要了解原理和实际运用，建议大家详细点击链接了解
系统工具替换后门、后门账号、明文账号记录、文件隐藏、计划任务、开机启动项、服务、waitfor.exe、bitsadmin后门、WMI后门、COM劫持、meterpreter权限维持、Empire persistence模块、进程注入、BDF后门、IIS模块后门、域环境后门
替换系统文件类：shift后门，放大镜后门
修改注册表类：自启动项、屏幕保护程序注册表、用户登陆初始化、登录脚本、映像劫持、影子账户、AppCertDlls注册表项、AppInit_DLLs注册表项、文件关联、用户登陆初始化、xx.Netsh Helper DLL
文件类：自启动文件夹、office Word StartUp劫持
计划任务：schtasks 、WMI、bitsadmin
SC命令、预加载型动态链接库后门、strace后门、SSH 后门、SUID后门、inetd服务后门、协议后门、vim后门、PAM后门、进程注入、Rootkit、端口复用、MSF权限维持：Persistence模块、Metsvc模块、Powershell权限维持、CS权限维持
详细利用请戳链接
Window下常见的权限维持方式（作者Bypass007）
主要为：预加载型动态链接库后门（利用LD_PRELOAD、利用/etc/ld.so.preload）、strace后门、SSH后门、SUID后门、inetd服务后门、协议后门、vim后门、PAM后门、进程注入、Rootkit
根据权限和原理不同，有不同的分类
上图来源于《[总结]Linux权限维持》（作者：肖洋肖恩）
上图来源于《linux权限维持-后门》（作者：Phyb0x’s）