反调试

首先可以看这个文章，肯定比我讲得好。

https://bbs.kanxue.com/thread-225740.htm

我下面写的东西，也是转载的啦。【方便以后自己找和看】

反调试技术，恶意代码用它识别是否被调试，或者让调试器失效。恶意代码编写者意识到分析人员经常使用调试器来观察恶意代码的操作，因此他们使用反调试技术尽可能地延长恶意代码的分析时间。为了阻止调试器的分析，当恶意代码意识到自己被调试时，它们可能改变正常的执行路径或者修改自身程序让自己崩溃，从而增加调试时间和复杂度。很多种反调试技术可以达到反调试效果。这里介绍当前常用的几种反调试技术，同时也会介绍一些逃避反调试的技巧。

反调试主要就是函数在操作【包括微软未公开的函数】

IsDebuggerPresent

IsDebuggerPresent查询进程环境块【PEB】中的IsDebugged标志。如果进程没有运行在调试器中，函数返回0；如果调试附加了进程，函数返回一个非0值。

1
2
3
4
BOOL CheckDebug()
{
return IsDebuggerPresent();
}

CheckRemoteDebuggerPresent

CheckRemoteDebuggerPresent同IsDebuggerPresent几乎一致。它不仅可以探测系统其他进程是否被调试，通过传递自身进程句柄还可以探测自身是否被调试。

1
2
3
4
5
6
BOOL CheckDebug()
{
BOOL ret;
CheckRemoteDebuggerPresent(GetCurrentProcess(), &ret);
return ret;
}

NtQueryInformationProcess

NtQueryInformationProcess

这个函数是Ntdll.dll中一个原生态API，它用来提取一个给定进程的信息。它的第一个参数是进程句柄，第二个参数告诉我们它需要提取进程信息的类型。为第二个参数指定特定值并调用该函数，相关信息就会设置到第三个参数。第二个参数是一个枚举类型，其中与反调试有关的成员有ProcessDebugPort(0x7)、ProcessDebugObjectHandle(0x1E)和ProcessDebugFlags(0x1F)。例如将该参数置为ProcessDebugPort，如果进程正在被调试，则返回调试端口，否则返回0。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
BOOL CheckDebug()
{
	int debugPort = 0;
	HMODULE hModule = LoadLibrary("Ntdll.dll");
	NtQueryInformationProcessPtr NtQueryInformationProcess =
		(NtQueryInformationProcessPtr)GetProcAddress(hModule,
			"NtQueryInformationProcess");
	NtQueryInformationProcess(GetCurrentProcess(), 0x7, &debugPort,
		sizeof(debugPort), NULL);
	return debugPort != 0;
}
BOOL CheckDebug()
{
	HANDLE hdebugObject = NULL;
	HMODULE hModule = LoadLibrary("Ntdll.dll");
	NtQueryInformationProcessPtr NtQueryInformationProcess =
		(NtQueryInformationProcessPtr)GetProcAddress(hModule,
			"NtQueryInformationProcess");
	NtQueryInformationProcess(GetCurrentProcess(), 0x1E, &hdebugObject,
		sizeof(hdebugObject), NULL);
	return hdebugObject != NULL;
}
BOOL CheckDebug()
{
	BOOL bdebugFlag = TRUE;
	HMODULE hModule = LoadLibrary("Ntdll.dll");
	NtQueryInformationProcessPtr NtQueryInformationProcess =
		(NtQueryInformationProcessPtr)GetProcAddress(hModule,
			"NtQueryInformationProcess");
	NtQueryInformationProcess(GetCurrentProcess(), 0x1E, &bdebugFlag,
		sizeof(bdebugFlag), NULL);
	return bdebugFlag != TRUE;
}

GetLastError

编写应用程序时，经常需要涉及到错误处理问题。许多函数调用只用TRUE和FALSE来表明函数的运行结果。一旦出现错误，MSDN中往往会指出请用GetLastError()函数来获得错误原因。恶意代码可以使用异常来破坏或者探测调试器。调试器捕获异常后，并不会立即将处理权返回被调试进程处理，大多数利用异常的反调试技术往往据此来检测调试器。多数调试器默认的设置是捕获异常后不将异常传递给应用程序。如果调试器不能将异常结果正确返回到被调试进程，那么这种异常失效可以被进程内部的异常处理机制探测。

对于OutputDebugString函数，它的作用是在调试器中显示一个字符串，同时它也可以用来探测调试器的存在。使用SetLastError函数，将当前的错误码设置为一个任意值。如果进程没有被调试器附加，调用OutputDebugString函数会失败，错误码会重新设置，因此GetLastError获取的错误码应该不是我们设置的任意值。但如果进程被调试器附加，调用OutputDebugString函数会成功，这时GetLastError获取的错误码应该没改变。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
BOOL CheckDebug()
{
	DWORD errorValue = 12345;
	SetLastError(errorValue);
	OutputDebugString("Test for debugger!");
	if (GetLastError() == errorValue)
	{
		return TRUE;
	}
	else
	{
		return FALSE;
	}
}

对于DeleteFiber函数，如果给它传递一个无效的参数的话会抛出ERROR_INVALID_PARAMETER异常。如果进程正在被调试的话，异常会被调试器捕获。所以，同样可以通过验证LastError值来检测调试器的存在。如代码所示，0x57就是指ERROR_INVALID_PARAMETER。

1
2
3
4
5
6
BOOL CheckDebug()
{
	char fib[1024] = { 0 };
	DeleteFiber(fib);
	return (GetLastError() != 0x57);
}

同样还可以使用CloseHandle、CloseWindow产生异常，使得错误码改变

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
BOOL CheckDebug()
{
	DWORD ret = CloseHandle((HANDLE)0x1234);
	if (ret != 0 || GetLastError() != ERROR_INVALID_HANDLE)
	{
		return TRUE;
	}
	else
	{
		return FALSE;
	}
}
BOOL CheckDebug()
{
	DWORD ret = CloseWindow((HWND)0x1234);
	if (ret != 0 || GetLastError() != ERROR_INVALID_WINDOW_HANDLE)
	{
		return TRUE;
	}
	else
	{
		return FALSE;
	}
}

ZwSetInformationThread

ZwSetInformationThread拥有两个参数，第一个参数用来接收当前线程的句柄，第二个参数表示线程信息类型，若其值设置为ThreadHideFromDebugger(0x11)，使用语句ZwSetInformationThread(GetCurrentThread(), ThreadHideFromDebugger, NULL, 0);调用该函数后，调试进程就会被分离出来。该函数不会对正常运行的程序产生任何影响，但若运行的是调试器程序，因为该函数隐藏了当前线程，调试器无法再收到该线程的调试事件，最终停止调试。还有一个函数DebugActiveProcessStop用来分离调试器和被调试进程，从而停止调试。两个API容易混淆，需要牢记它们的区别。

手动检测数据结构

虽然使用Windows API是探测调试器存在的最简单办法，但手动检查数据结构是恶意代码编写者最常使用的办法。这是因为很多时候通过Windows API实现的反调试技术无效，例如这些API函数被rootkit挂钩，并返回错误信息。因此，恶意代码编写者经常手动执行与这些API功能相同的操作。在手动检测中，PEB结构中的一些标志暴露了调试器存在的信息。这里，我们关注检测调试器存在常用的一些标志。

检测BeingDebugged属性

Windows操作系统维护着每个正在运行的进程的PEB结构，它包含与这个进程相关的所有用户态参数。这些参数包括进程环境数据，环境数据包括环境变量、加载的模块列表、内存地址，以及调试器状态。

检测ProcessHeap属性

Reserved数组中一个未公开的位置叫作ProcessHeap，它被设置为加载器为进程分配的第一个堆的位置。ProcessHeap位于PEB结构的0x18处。第一个堆头部有一个属性字段，它告诉核这个堆是否在调试器中创建。这些属性叫作ForceFlags和Flags。在Windows XP系统中，ForceFlags属性位于堆头部偏移量0x10处；在Windows 7系统中，对于32位的应用程序来说ForceFlags属性位于堆头部偏移量0x44处。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
BOOL CheckDebug()
{
	int result = 0;
	DWORD dwVersion = GetVersion();
	DWORD dwWindowsMajorVersion = (DWORD)(LOBYTE(LOWORD(dwVersion)));
	//for xp
	if (dwWindowsMajorVersion == 5)
	{
		__asm
		{
			mov eax, fs: [30h]
			mov eax, [eax + 18h]
			mov eax, [eax + 10h]
			mov result, eax
		}
	}
	else
	{
		__asm
		{
			mov eax, fs: [30h]
			mov eax, [eax + 18h]
			mov eax, [eax + 44h]
			mov result, eax
		}
	}
	return result != 0;
}

OD 有插件

当我们遇到一些常见的反调试API可以直接nop掉它，一般的话会加时钟检测，我们可以用pchunter移除程序时钟等等等。我们了解一下反调试技术就行了，现在基本很少会出现反调试，因为差不多玩不出花样，现在的难度都在程序虚拟机保护上。