反调试之IsDebuggerPresent()分析

哪个DLL导出了该函数？
查MSDN可知

学习一个函数最好的方式是在自己的程序里面调用该函数，并分析自己的程序，我用c写了一个简单的程序，函数不断循环打印“I am running…”,并不断检查是否程序被调试，如果程序被调试，则输出“软件正在被调试”，然后退出


我们希望知道IsDebuggerPresent()的底层实现，而不是简单的知道这个api，所以要反汇编我们写的程序，打开od附加调试

首先如何找到我们的main函数？
首先我们要知道main函数总要传递三个参数，只是我们平时可以省略不写

int main (int argc, char *argv[], char *envp[])
{
	return 0;
}

例如我们在命令行执行test.exe程序并输入几个参数

test -a -b -c

1.argc是传入参数的数量，当前argc值就是4（包括test）
2.argv[]指向了传入的参数是什么，argv[0]是带有路径的程序名，也就是c:\test.exe,argv[1]就是第一个参数“-a”,argv[2]就是第二个参数“-b”,等等
3.envp[]指向环境变量的字符串，以 “”xx=xx“”格式传入，是系统帮我们传入的
长这样

好了，我们知道main传入的参数个数之后，只需要找到有连续三个push的call，并且后面的两个push都是指针，那个call就是main函数了（ps:只有一个满足条件）

1.按回车 ，jmp到某函数

2.该函数内部只有一个call，那我们进入该call

3.现在我们遇到两个call，main函数在其中一个call里面，事实告诉我们main在第二个call里面（不信你可以在第一个call里面找一遍）

3.该函数内部有很多call，我们需要找到 call add call mov call 这种的连续三个call，就和下图一样，然后进入中间那个call

4.第四个call的前面有三个push，这就是我们要找的main函数了，进入

定位到IsDebuggerPresent()

发现它只有两行代码，并没有进入0环,我们来看它做了什么

mov eax ,dword ptr fs:[0x30]
movzx eax,byte ptr ds:[eax+0x2]

fs段寄存器指向的是当前进程的TEB,每个线程都有两个描述该线程信息的结构体，一个只给0环看，一个给3环看，TEB是给3环看的结构体，fs寄存器总指向当前线程的TEB，fs:[0x30]是TEB的0x30偏移处，存储了PEB的指针，（PEB是给3环看的描述该线程对应的进程的结构体）PEB中0x2偏移处就是BeingDebugged的值

所以第一行就是 把PEB地址给eax
第二行就是把BeingDebugged给eax
然后返回

当程序被调试时，BeingDebugged不为0，当程序没有被调试时，BeingDebugged为0

反反调试 ：将BeingDebugged恢复为0

如何获取目标进程的PEB呢？
下面列举两种方法
1.调用NtQueryInformationProcess()获取PROCESS_BASIC_INFORMATION结构体
PROCESS_BASIC_INFORMATION.PebBaseAddress存储了指向目标进程PEB的指针

涉及的结构体和函数：

__kernel_entry NTSTATUS NtQueryInformationProcess(
  HANDLE           ProcessHandle,
  PROCESSINFOCLASS ProcessInformationClass,
  PVOID            ProcessInformation,
  ULONG            ProcessInformationLength,
  PULONG           ReturnLength
);
typedef struct _PROCESS_BASIC_INFORMATION32 {
	NTSTATUS ExitStatus;
	UINT32 PebBaseAddress;
	UINT32 AffinityMask;
	UINT32 BasePriority;
	UINT32 UniqueProcessId;
	UINT32 InheritedFromUniqueProcessId;
} PROCESS_BASIC_INFORMATION32;

代码实现：

2.首先调用GetThreadContext()获取目标线程的线程上下文CONTEXT结构体；该结构体存储了在某一个快照下的所有寄存器的值，因为我们想要的是fs，它通常情况下不会改变，所以不需要挂起线程，当我们获取到fs之后，它是一个段选择子(保护模式的知识)，调用GetThreadSelectorEntry()获取该选择子指向的那个段描述符信息并封装到一个_LDT_ENTRY类型的结构体，然后根据_LDT_ENTRY将base地址给拼起来（base.high左移24位+base.mid左移16位+base.low）

涉及的结构体和函数：

BOOL GetThreadContext(HANDLE hThread, LPCONTEXT lpContext);

typedef struct _CONTEXT
{
        DWORD   ContextFlags;
        DWORD   Dr0;
        DWORD   Dr1;
        DWORD   Dr2;
        DWORD   Dr3;
        DWORD   Dr6;
        DWORD   Dr7;
        FLOATING_SAVE_AREA FloatSave;
        DWORD   SegGs;
        DWORD   SegFs;
        DWORD   SegEs;
        DWORD   SegDs;
        DWORD   Edi;
        DWORD   Esi;
        DWORD   Ebx;
        DWORD   Edx;
        DWORD   Ecx;
        DWORD   Eax;
        DWORD   Ebp;
        DWORD   Eip;
        DWORD   SegCs;
        DWORD   EFlags;
        DWORD   Esp;
        DWORD   SegSs;
} CONTEXT;

BOOL WINAPI GetThreadSelectorEntry(
  _In_  HANDLE      hThread,
  _In_  DWORD       dwSelector,
  _Out_ LPLDT_ENTRY lpSelectorEntry
);

typedef struct _LDT_ENTRY {
  WORD  LimitLow;
  WORD  BaseLow;
  union {
    struct {
      BYTE BaseMid;
      BYTE Flags1;
      BYTE Flags2;
      BYTE BaseHi;
    } Bytes;
    struct {
      DWORD BaseMid : 8;
      DWORD Type : 5;
      DWORD Dpl : 2;
      DWORD Pres : 1;
      DWORD LimitHi : 4;
      DWORD Sys : 1;
      DWORD Reserved_0 : 1;
      DWORD Default_Big : 1;
      DWORD Granularity : 1;
      DWORD BaseHi : 8;
    } Bits;
  } HighWord;
} LDT_ENTRY, *PLDT_ENTRY;

代码实现：

 CONTEXT ctx;
    LDT_ENTRY sel;
    DWORD fs;
    DWORD peb;
    SIZE_T bytesrw;
    BYTE flag;
    ctx.ContextFlags = CONTEXT_SEGMENTS;
    if (!GetThreadContext(hThread, &ctx))
        return FALSE;
    if (!GetThreadSelectorEntry(hThread, ctx.SegFs, &sel))
        return FALSE;
    fs = (sel.HighWord.Bytes.BaseHi << 24 | sel.HighWord.Bytes.BaseMid) << 16 |sel.BaseLow;    
    if (!ReadProcessMemory(hProcess, (LPCVOID)(fs + 0x30), &peb, 4, &bytesrw) ||bytesrw != 4)
        return FALSE;
    if (!ReadProcessMemory(hProcess, (LPCVOID)(peb + 0x2), &flag, 1, &bytesrw) ||bytesrw != 2)
        return FALSE;
    flag = 0;
    if (!WriteProcessMemory(hProcess, (LPCVOID)(peb + 0x2), &flag, 1, &bytesrw) ||bytesrw != 2)

扩展
BeingDebugged设为True后引发的其他问题

1. PEB中0x68偏移处的NtGlobalFlag位会被更改为0x70，而正常状态下不是
2. 当NtGlobalFlag位会被更改为0x70时，PEB中0x18偏移处ProcessHeap指向了一个HEAP结构体。该结构体成员Flags(+0xC)与Force Flags(+ox10)成员被设置成特定的值。 PEB.ProcessHeap既可以从PEB结构体中直接获得，也可以通过GetProcessHeap() API获得。当进程运行正常时Heap.Flags成员的值为0x2,Heap. ForceFlags成员的值位0x0，进程处于被调试状态时这些值也会随之改变

解放方式1：
可以看出NtGlobalFlag位被改变让我们对清除痕迹造成很大的麻烦，究其根源都是由于BeingDebugged被设为True导致的，因此如果找到一个时机，在NtGlobalFlag改变之前就设BeingDebugged为False即可绕过所有问题但是如果把BeingDebugged设为False，就不会在系统断点处触发中断了。因此还需要有技巧的设置

1. 在第一次触发LOAD_DLL_DEBUG_EVENT的时候将BeingDebugged设为False，绕过NtGlobalFlag的改变
2. 在第二次触发LOAD_DLL_DEBUG_EVENT的时候将BeingDebugged设为True，使系统中断正常触发
3. 系统中断以后再将BeingDebugged清除掉

但是在Windows7系统以及Windows7系统以后，只有如下两个位置会被改变了

0x002 UCHAR BeingDebugged;
0x068 LARGE_INTEGER NtGlobalFlag;

解放方式2：
所以我们没必要早早的在DLL加载时就更改BeingDebugged的值，而是只需要在检测函数调用之前将NtGlobalFlag和BeingDebugged清0就可以了