0x01 反调试方法
软件及硬件断点
断点（breakpoint）是调试器提供的主要工具。我们可以使用断点在特定位置中断程序执行流程。断点有两种类型：
1、软件断点
2、硬件断点
如果没有断点支持，我们很难逆向分析目标软件。常用的反逆向分析技巧都会检测断点是否存在，因此我们也有对应的反调试方法。
软件断点
在IA-32架构中，有一条特殊的指令：带有0xCC操作码（opcode）的int 3h，这条指令可以用来调用调试句柄。当CPU执行这条指令时，就会产生中断，将控制权交给调试器。为了获得控制权，调试器需要将int 3h指令注入代码中。为了检测断点是否存在，我们可以计算函数的校验和。示例代码如下：
DWORD CalcFuncCrc(PUCHAR funcBegin, PUCHAR funcEnd)
{
DWORD crc = 0;
for (; funcBegin < funcEnd; ++funcBegin)
{
crc += *funcBegin;
}
return crc;
}
#pragma auto_inline(off)
VOID DebuggeeFunction()
{
int calc = 0;
calc += 2;
calc <<= 8;
calc -= 3;
}
VOID DebuggeeFunctionEnd()
{
};
#pragma auto_inline(on)
DWORD g_origCrc = 0x2bd0;
int main()
{
DWORD crc = CalcFuncCrc((PUCHAR)DebuggeeFunction, (PUCHAR)DebuggeeFunctionEnd);
if (g_origCrc != crc)
{
std::cout << "Stop debugging program!" << std::endl;
exit(-1);
}
return 0;
}
需要注意的是，以上代码只有在设置/INCREMENTAL:NO链接器选项时才能生效，否则当获取函数地址来计算校验和时，我们会得到相对跳转地址：
DebuggeeFunction:
013C16DB jmp DebuggeeFunction (013C4950h)
g_origCrc全局变量中包含CalcFuncCrc函数已计算出的crc。为了检测函数尾部，我们使用了stub函数（桩函数）技巧。由于函数代码顺序存放，DebuggeeFunction函数的尾部就是DebuggeeFunctionEnd函数的头部。我们还使用了#pragma auto_inline(off)指令来阻止编译器在中间嵌入函数。
如何绕过
绕过软件断点检测并没有通用的方法。如果想完成该任务，我们应当找到计算校验和的代码，将返回值替换为其他常量值，也要修改存储函数校验和的所有变量的值。
硬件断点
在x86架构中，开发者在检查和调试代码时会用到一些调试寄存器。这些寄存器可以让我们中断程序执行流，在读写内存时将控制权交给调试器。调试寄存器属于特权资源，程序只有在实模式（real mode）或者安全模式（safe mode）下且特权级CPL=0时才能使用这些寄存器。调试寄存器总共有8个，分别为DR0–DR7：
-
DR0–DR3：断点寄存器 -
DR4及DR5：保留 -
DR6：调试状态 -
DR7：调试控制
DR0–DR3包含断点的线性地址。系统会在物理地址转换之前比较这些地址。每个断点都在DR7寄存器中单独描述。DR6寄存器用来表示哪个断点处于激活状态。DR7通过访问模式来定义断点激活模式，分别为：读取（read）、写入（write）或者执行（execute）。基于硬件断点的检查示例如下所示：
CONTEXT ctx = {};
ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
if (GetThreadContext(GetCurrentThread(), &ctx))
{
if (ctx.Dr0 != 0 || ctx.Dr1 != 0 || ctx.Dr2 != 0 || ctx.Dr3 != 0)
{
std::cout << "Stop debugging program!" << std::endl;
exit(-1);
}
}
我们也可以通过SetThreadContext函数来重设硬件断点。重设硬件断点的代码如下所示：
CONTEXT ctx = {};
ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
SetThreadContext(GetCurrentThread(), &ctx);
这样所有DRx寄存器都会被清零。
如何绕过
如果我们观察GetThreadContext函数，可以看到其中会调用NtGetContextThread函数。
0:000> u KERNELBASE!GetThreadContext L6
KERNELBASE!GetThreadContext:
7538d580 8bff mov edi,edi
7538d582 55 push ebp
7538d583 8bec mov ebp,esp
7538d585 ff750c push dword ptr [ebp+0Ch]
7538d588 ff7508 push dword ptr [ebp+8]
7538d58b ff1504683975 call dword ptr [KERNELBASE!_imp__NtGetContextThread (75396804)]
为了让代码读取Dr0–Dr7寄存器的值为0，我们需要重设CONTEXT结构中ContextFlags字段的CONTEXT_DEBUG_REGISTERS标志，然后在NtGetContextThread函数调用后恢复该值。至于GetThreadContext函数，该函数调用的是NtSetContextThread。绕过硬件断点检查并重置相关字段的代码如下所示：
typedef NTSTATUS(NTAPI *pfnNtGetContextThread)(
_In_ HANDLE ThreadHandle,
_Out_ PCONTEXT pContext
);
typedef NTSTATUS(NTAPI *pfnNtSetContextThread)(
_In_ HANDLE ThreadHandle,
_In_ PCONTEXT pContext
);
pfnNtGetContextThread g_origNtGetContextThread = NULL;
pfnNtSetContextThread g_origNtSetContextThread = NULL;
NTSTATUS NTAPI HookNtGetContextThread(
_In_ HANDLE ThreadHandle,
_Out_ PCONTEXT pContext)
{
DWORD backupContextFlags = pContext->ContextFlags;
pContext->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS;
NTSTATUS status = g_origNtGetContextThread(ThreadHandle, pContext);
pContext->ContextFlags = backupContextFlags;
return status;
}
NTSTATUS NTAPI HookNtSetContextThread(
_In_ HANDLE ThreadHandle,
_In_ PCONTEXT pContext)
{
DWORD backupContextFlags = pContext->ContextFlags;
pContext->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS;
NTSTATUS status = g_origNtSetContextThread(ThreadHandle, pContext);
pContext->ContextFlags = backupContextFlags;
return status;
}
void HookThreadContext()
{
HMODULE hNtDll = LoadLibrary(TEXT("ntdll.dll"));
g_origNtGetContextThread = (pfnNtGetContextThread)GetProcAddress(hNtDll, "NtGetContextThread");
g_origNtSetContextThread = (pfnNtSetContextThread)GetProcAddress(hNtDll, "NtSetContextThread");
Mhook_SetHook((PVOID*)&g_origNtGetContextThread, HookNtGetContextThread);
Mhook_SetHook((PVOID*)&g_origNtSetContextThread, HookNtSetContextThread);
}
SEH
SEH（Structured Exception Handling）是操作系统向应用程序提供的一种机制，使应用程序可以接受关于异常情况的通知（如除以0、引用不存在的指针或者执行受限指令）。这种机制可以让我们在应用内部处理异常，无需操作系统介入。如果异常没有被处理，就会导致程序异常终止。开发者通常会在栈中找到指向SEH的指针，也就是SEH帧（SEH frame）。当前SEH帧地址位于FS选择器（x64系统上是GS选择器）相对地址offset 0处，该地址指向的是ntdll!_EXCEPTION_REGISTRATION_RECORD结构：
0:000> dt ntdll!_EXCEPTION_REGISTRATION_RECORD
+0x000 Next : Ptr32 _EXCEPTION_REGISTRATION_RECORD
+0x004 Handler : Ptr32 _EXCEPTION_DISPOSITION
当出现异常时，控制权将交给当前的SEH处理函数（handler）。根据所处的具体情况，这个SEH处理函数应当返回如下某个_EXCEPTION_DISPOSITION枚举值：
typedef enum _EXCEPTION_DISPOSITION {
ExceptionContinueExecution,
ExceptionContinueSearch,
ExceptionNestedException,
ExceptionCollidedUnwind
} EXCEPTION_DISPOSITION;
如果处理函数返回的是ExceptionContinueSearch，系统会从触发异常的指令处继续执行。如果处理函数不知道如何处理异常，就会返回ExceptionContinueSearch，然后系统会移到处理链中的下一个处理函数。我们可以在WinDbg调试器中使用!exchain命令浏览当前的异常处理链：
0:000> !exchain
00a5f3bc: AntiDebug!_except_handler4+0 (008b7530)
CRT scope 0, filter: AntiDebug!SehInternals+67 (00883d67)
func: AntiDebug!SehInternals+6d (00883d6d)
00a5f814: AntiDebug!__scrt_stub_for_is_c_termination_complete+164b (008bc16b)
00a5f87c: AntiDebug!_except_handler4+0 (008b7530)
CRT scope 0, filter: AntiDebug!__scrt_common_main_seh+1b0 (008b7c60)
func: AntiDebug!__scrt_common_main_seh+1cb (008b7c7b)
00a5f8e8: ntdll!_except_handler4+0 (775674a0)
CRT scope 0, filter: ntdll!__RtlUserThreadStart+54386 (7757f076)
func: ntdll!__RtlUserThreadStart+543cd (7757f0bd)
00a5f900: ntdll!FinalExceptionHandlerPad4+0 (77510213)
链中最后一个处理程序是系统分配的默默人处理程序。如果之前的所有处理程序都无法处理异常，那么系统处理程序就会访问注册表，获取如下键值：
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
根据AeDebug表项的值，应用程序会被终止，或者控制权会交给调试器。调试器路径位于Debugger表项中（REG_SZ）。
当创建新进程时，系统会将主SEH帧（primary SEH frame）加入其中。主SEH帧的处理程序同样由系统定义。主SEH帧大多数情况下位于分配给进程的内存栈的开头处。SEH处理程序函数原型如下所示：
typedef EXCEPTION_DISPOSITION (*PEXCEPTION_ROUTINE) (
__in struct _EXCEPTION_RECORD *ExceptionRecord,
__in PVOID EstablisherFrame,
__inout struct _CONTEXT *ContextRecord,
__inout PVOID DispatcherContext
);
如果应用程序正在被调试，那么在生成int 3h中断后，调试器将会拦截控制权。否则，控制权就会交给SEH处理函数。基于SEH帧的反调试代码如下所示：
BOOL g_isDebuggerPresent = TRUE;
EXCEPTION_DISPOSITION ExceptionRoutine(
PEXCEPTION_RECORD ExceptionRecord,
PVOID EstablisherFrame,
PCONTEXT ContextRecord,
PVOID DispatcherContext)
{
g_isDebuggerPresent = FALSE;
ContextRecord->Eip += 1;
return ExceptionContinueExecution;
}
int main()
{
__asm
{
// set SEH handler
push ExceptionRoutine
push dword ptr fs:[0]
mov dword ptr fs:[0], esp
// generate interrupt
int 3h
// return original SEH handler
mov eax, [esp]
mov dword ptr fs:[0], eax
add esp, 8
}
if (g_isDebuggerPresent)
{
std::cout << "Stop debugging program!" << std::endl;
exit(-1);
}
return 0
}
如上代码中设置了SEH处理函数，指向该处理函数的指针位于处理链的开头，然后生成int 3h中断。如果应用程序没有被调试，控制权会转给SEH处理程序，g_isDebuggerPresent的值会被设置为FALSE。ContextRecord->Eip += 1这一行代码会修改执行流中的下一条指令地址，这样就会执行在int 3h后的下一条指令。然后代码返回原始的SEH处理函数，清空栈，并且检查是否存在调试器。
如何绕过
虽然绕过SEH检查并没有通用的方法，但逆向分析人员还是可以使用某些技术来减轻工作量。我们来观察下关于SEH处理程序的调用栈：
0:000> kn
# ChildEBP RetAddr
00 0059f06c 775100b1 AntiDebug!ExceptionRoutine
01 0059f090 77510083 ntdll!ExecuteHandler2+0x26
02 0059f158 775107ff ntdll!ExecuteHandler+0x24
03 0059f158 003b11a5 ntdll!KiUserExceptionDispatcher+0xf
04 0059fa90 003d7f4e AntiDebug!main+0xb5
05 0059faa4 003d7d9a AntiDebug!invoke_main+0x1e
06 0059fafc 003d7c2d AntiDebug!__scrt_common_main_seh+0x15a
07 0059fb04 003d7f68 AntiDebug!__scrt_common_main+0xd
08 0059fb0c 753e7c04 AntiDebug!mainCRTStartup+0x8
09 0059fb20 7752ad1f KERNEL32!BaseThreadInitThunk+0x24
0a 0059fb68 7752acea ntdll!__RtlUserThreadStart+0x2f
0b 0059fb78 00000000 ntdll!_RtlUserThreadStart+0x1b
可以看到该调用来自于ntdll!ExecuteHandler2。这个函数是任何SEH处理函数的调用起点。我们可以在调用指令处设置断点：
0:000> u ntdll!ExecuteHandler2+24 L3
ntdll!ExecuteHandler2+0x24:
775100af ffd1 call ecx
775100b1 648b2500000000 mov esp,dword ptr fs:[0]
775100b8 648f0500000000 pop dword ptr fs:[0]
0:000> bp 775100af
设置断点后，我们应该分析被调用的每个SEH处理函数的代码。如果反调试技术涉及到对SEH处理函数的多次调用，那么逆向人员应该花精力绕过这些函数。
VEH
VEH（Vectored Exception Handler）是从Windows XP引入的一种机制，也是SEH的变种。VEH和SEH并不相互依赖，可以同时工作。当添加了新的VEH处理函数时，SEH链并不会受到影响，因为VEH处理函数存在于未导出的ntdll!LdrpVectorHandlerList变量中。VEH和SEH机制非常相似，唯一的区别在于系统使用已公开的函数来设置并删除VEH处理函数。添加并删除VEH处理函数的函数原型以及VEH处理函数本身的原型如下所示：
PVOID WINAPI AddVectoredExceptionHandler(
ULONG FirstHandler,
PVECTORED_EXCEPTION_HANDLER VectoredHandler
);
ULONG WINAPI RemoveVectoredExceptionHandler(
PVOID Handler
);
LONG CALLBACK VectoredHandler(
PEXCEPTION_POINTERS ExceptionInfo
);
The _EXCEPTION_POINTERS structure looks like this:
typedef struct _EXCEPTION_POINTERS {
PEXCEPTION_RECORD ExceptionRecord;
PCONTEXT ContextRecord;
} EXCEPTION_POINTERS, *PEXCEPTION_POINTERS;
在处理函数中收到控制权后，系统会收集当前进程上下文并通过ContextRecord参数进行传递。使用VEH的反调试代码如下所示：
LONG CALLBACK ExceptionHandler(PEXCEPTION_POINTERS ExceptionInfo)
{
PCONTEXT ctx = ExceptionInfo->ContextRecord;
if (ctx->Dr0 != 0 || ctx->Dr1 != 0 || ctx->Dr2 != 0 || ctx->Dr3 != 0)
{
std::cout << "Stop debugging program!" << std::endl;
exit(-1);
}
ctx->Eip += 2;
return EXCEPTION_CONTINUE_EXECUTION;
}
int main()
{
AddVectoredExceptionHandler(0, ExceptionHandler);
__asm int 1h;
return 0;
}
这里我们设置了一个VEH处理函数并生成中断（int 1h不是必需操作）。当产生中断时，会出现异常，控制权会转给VEH处理函数。如果设置了硬件断点，系统就会终止程序执行。如果没有硬件断点，EIP寄存器的值就会加2，以便在int 1h指令后继续执行。
如何绕过
来观察下涉及到VEH处理函数的调用栈：
0:000> kn
# ChildEBP RetAddr
00 001cf21c 774d6822 AntiDebug!ExceptionHandler
01 001cf26c 7753d151 ntdll!RtlpCallVectoredHandlers+0xba
02 001cf304 775107ff ntdll!RtlDispatchException+0x72
03 001cf304 00bf4a69 ntdll!KiUserExceptionDispatcher+0xf
04 001cfc1c 00c2680e AntiDebug!main+0x59
05 001cfc30 00c2665a AntiDebug!invoke_main+0x1e
06 001cfc88 00c264ed AntiDebug!__scrt_common_main_seh+0x15a
07 001cfc90 00c26828 AntiDebug!__scrt_common_main+0xd
08 001cfc98 753e7c04 AntiDebug!mainCRTStartup+0x8
09 001cfcac 7752ad1f KERNEL32!BaseThreadInitThunk+0x24
0a 001cfcf4 7752acea ntdll!__RtlUserThreadStart+0x2f
0b 001cfd04 00000000 ntdll!_RtlUserThreadStart+0x1b
如上所示，控制权会从main+0x59转移到ntdll!KiUserExceptionDispatcher。来看下main+0x59中负责该操作的具体指令：
0:000> u main+59 L1
AntiDebug!main+0x59
00bf4a69 cd02 int 1
生成中断的指令如上所示。KiUserExceptionDispatcher函数是系统从内核模式到用户模式的一个回调函数，函数原型如下所示：
VOID NTAPI KiUserExceptionDispatcher(
PEXCEPTION_RECORD pExcptRec,
PCONTEXT ContextFrame
);
我们可以通过KiUserExceptionDispatcher函数hook来绕过硬件断点检测，如下所示：
typedef VOID (NTAPI *pfnKiUserExceptionDispatcher)(
PEXCEPTION_RECORD pExcptRec,
PCONTEXT ContextFrame
);
pfnKiUserExceptionDispatcher g_origKiUserExceptionDispatcher = NULL;
VOID NTAPI HandleKiUserExceptionDispatcher(PEXCEPTION_RECORD pExcptRec, PCONTEXT ContextFrame)
{
if (ContextFrame && (CONTEXT_DEBUG_REGISTERS & ContextFrame->ContextFlags))
{
ContextFrame->Dr0 = 0;
ContextFrame->Dr1 = 0;
ContextFrame->Dr2 = 0;
ContextFrame->Dr3 = 0;
ContextFrame->Dr6 = 0;
ContextFrame->Dr7 = 0;
ContextFrame->ContextFlags &= ~CONTEXT_DEBUG_REGISTERS;
}
}
__declspec(naked) VOID NTAPI HookKiUserExceptionDispatcher()
// Params: PEXCEPTION_RECORD pExcptRec, PCONTEXT ContextFrame
{
__asm
{
mov eax, [esp + 4]
mov ecx, [esp]
push eax
push ecx
call HandleKiUserExceptionDispatcher
jmp g_origKiUserExceptionDispatcher
}
}
int main()
{
HMODULE hNtDll = LoadLibrary(TEXT("ntdll.dll"));
g_origKiUserExceptionDispatcher = (pfnKiUserExceptionDispatcher)GetProcAddress(hNtDll, "KiUserExceptionDispatcher");
Mhook_SetHook((PVOID*)&g_origKiUserExceptionDispatcher, HookKiUserExceptionDispatcher);
return 0;
}
在上述代码中，DRx寄存器的值会在HookKiUserExceptionDispatcher函数中重置，也就是说，会在调用VEH处理函数前重置。
NtSetInformationThread：从调试器中隐藏线程
在Windows 2000中，出现了传递给NtSetInformationThread函数的一个新的线程信息类：ThreadHideFromDebugger。这是微软在研究如何防御逆向工程时在Windows中引入的第一个反调试技术，并且这种技术也非常强大。如果某个线程设置了该标志，那么该线程就会停止发送关于调试事件的通知。这些事件包括断点信息以及关于程序完成的通知信息。该标志的值存放于_ETHREAD结构的HideFromDebugger字段中。
1: kd> dt _ETHREAD HideFromDebugger 86bfada8
ntdll!_ETHREAD
+0x248 HideFromDebugger : 0y1
设置ThreadHideFromDebugger的代码如下所示：
typedef NTSTATUS (NTAPI *pfnNtSetInformationThread)(
_In_ HANDLE ThreadHandle,
_In_ ULONG ThreadInformationClass,
_In_ PVOID ThreadInformation,
_In_ ULONG ThreadInformationLength
);
const ULONG ThreadHideFromDebugger = 0x11;
void HideFromDebugger()
{
HMODULE hNtDll = LoadLibrary(TEXT("ntdll.dll"));
pfnNtSetInformationThread NtSetInformationThread = (pfnNtSetInformationThread)
GetProcAddress(hNtDll, "NtSetInformationThread");
NTSTATUS status = NtSetInformationThread(GetCurrentThread(),
ThreadHideFromDebugger, NULL, 0);
}
如何绕过
为了阻止应用程序向调试器隐藏线程信息，我们需要hook NtSetInformationThread函数调用。hook代码如下所示：
pfnNtSetInformationThread g_origNtSetInformationThread = NULL;
NTSTATUS NTAPI HookNtSetInformationThread(
_In_ HANDLE ThreadHandle,
_In_ ULONG ThreadInformationClass,
_In_ PVOID ThreadInformation,
_In_ ULONG ThreadInformationLength
)
{
if (ThreadInformationClass == ThreadHideFromDebugger &&
ThreadInformation == 0 && ThreadInformationLength == 0)
{
return STATUS_SUCCESS;
}
return g_origNtSetInformationThread(ThreadHandle,
ThreadInformationClass, ThreadInformation, ThreadInformationLength
}
void SetHook()
{
HMODULE hNtDll = LoadLibrary(TEXT("ntdll.dll"));
if (NULL != hNtDll)
{
g_origNtSetInformationThread = (pfnNtSetInformationThread)GetProcAddress(hNtDll, "NtSetInformationThread");
if (NULL != g_origNtSetInformationThread)
{
Mhook_SetHook((PVOID*)&g_origNtSetInformationThread, HookNtSetInformationThread);
}
}
}
在被hook的函数中，如果正确调用的话就会返回STATUS_SUCCESS，并且不会将控制权交给原始的NtSetInformationThread函数。
NtCreateThreadEx
Windows从Vista开始引入了NtCreateThreadEx函数，函数原型如下所示：
NTSTATUS NTAPI NtCreateThreadEx (
_Out_ PHANDLE ThreadHandle,
_In_ ACCESS_MASK DesiredAccess,
_In_opt_ POBJECT_ATTRIBUTES ObjectAttributes,
_In_ HANDLE ProcessHandle,
_In_ PVOID StartRoutine,
_In_opt_ PVOID Argument,
_In_ ULONG CreateFlags,
_In_opt_ ULONG_PTR ZeroBits,
_In_opt_ SIZE_T StackSize,
_In_opt_ SIZE_T MaximumStackSize,
_In_opt_ PVOID AttributeList
);
其中最有趣的参数是CreateFlags，该参数可以使用如下标志：
#define THREAD_CREATE_FLAGS_CREATE_SUSPENDED 0x00000001
#define THREAD_CREATE_FLAGS_SKIP_THREAD_ATTACH 0x00000002
#define THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER 0x00000004
#define THREAD_CREATE_FLAGS_HAS_SECURITY_DESCRIPTOR 0x00000010
#define THREAD_CREATE_FLAGS_ACCESS_CHECK_IN_TARGET 0x00000020
#define THREAD_CREATE_FLAGS_INITIAL_THREAD 0x00000080
如果新线程设置了THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER标志，那么在创建时就可以向调试器隐藏该线程信息，这与NtSetInformationThread函数设置的ThreadHideFromDebugger相同。负责安全任务的代码可以在设置THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER标志的线程中执行。
如何绕过
我们可以hook NtCreateThreadEx函数来绕过这种技术，在该函数中重置THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER。
句柄跟踪
从Windows XP开始，Windows系统就具备跟踪内核对象句柄的机制。当跟踪模式启动后，与句柄所有操作都会被保存到循环缓冲区中，并且当使用不存在的句柄时（比如使用CloseHandle函数关闭该句柄），那么就会出现EXCEPTION_INVALID_HANDLE异常。如果进程没有通过调试器启动，那么CloseHandle函数会返回FALSE。基于CloseHandle的反调试技术代码如下所示：
EXCEPTION_DISPOSITION ExceptionRoutine(
PEXCEPTION_RECORD ExceptionRecord,
PVOID EstablisherFrame,
PCONTEXT ContextRecord,
PVOID DispatcherContext)
{
if (EXCEPTION_INVALID_HANDLE == ExceptionRecord->ExceptionCode)
{
std::cout << "Stop debugging program!" << std::endl;
exit(-1);
}
return ExceptionContinueExecution;
}
int main()
{
__asm
{
// set SEH handler
push ExceptionRoutine
push dword ptr fs : [0]
mov dword ptr fs : [0], esp
}
CloseHandle((HANDLE)0xBAAD);
__asm
{
// return original SEH handler
mov eax, [esp]
mov dword ptr fs : [0], eax
add esp, 8
}
return 0
}
篡改堆栈段
当修改ss堆栈段（stack segment register）寄存器时，调试器会跳过指令跟踪。在如下示例中，调试器会立即移到xor edx, edx指令，而上一条指令仍会被执行。
这里大家可以拓展阅读“How to Reverse Engineer Software (Windows) in a Right Way”这篇文章。
调试信息
从Windows 10开始，Windows修改了OutputDebugString函数的实现，改成带有特定参数的RaiseException调用。因此，现在调试输出异常必须由调试器来处理。
我们可以使用两种异常类型来检测是否存在调试器，分别为DBG_PRINTEXCEPTION_C（0x40010006）以及DBG_PRINTEXCEPTION_W（0x4001000A）。
#define DBG_PRINTEXCEPTION_WIDE_C 0x4001000A
WCHAR * outputString = L"Any text";
ULONG_PTR args[4] = {0};
args[0] = (ULONG_PTR)wcslen(outputString) + 1;
args[1] = (ULONG_PTR)outputString;
__try
{
RaiseException(DBG_PRINTEXCEPTION_WIDE_C, 0, 4, args);
printf("Debugger detected");
}
__except (EXCEPTION_EXECUTE_HANDLER)
{
printf("Debugger NOT detected");
}
因此，如果异常没有被处理，就意味着没有附加调试器。
DBG_PRINTEXCEPTION_W用于宽字符输出，DBG_PRINTEXCEPTION_C用于ansi字符。这意味着在使用DBG_PRINTEXCEPTION_C的情况下，arg[0]会保存strlen()的结果，而args[1]在指向ansi字符串（char *）。
0x02 总结
本文描述了一系列反逆向工程技术，特别是反调试方法。我们从最简单的技术开始，也介绍了相应的绕过方法。本文并没有覆盖所有技术，还有一些技术大家可以自己进一步研究，比如：
- 自调试进程
- 使用
FindWindow函数的调试器检测技术 - 基于时间计算的检测技术（参考这篇文章）
NtQueryObjectBlockInputNtSetDebugFilterState- 自修改代码
虽然我们主要关注的是反调试保护方法，还有其他一些反逆向分析方法，包括反转储（anti-dumping）以及混淆技术。
这里我们要再次强调一下，即使最优秀的反逆向分析技术也无法完全避免软件被逆向分析。反调试技术的主要任务是使逆向分析人员操作起来更为复杂，尽可能提高反逆向分析的难度。
0x03 参考资料
https://msdn.microsoft.com/library
http://www.infosecinstitute.com/
评论