在C / C ++中了解Windows / MSVC的一些Antidebug内联asm

Question

我试图了解https://github.com/nemesisqp/al-khaser/blob/0f74c40dde8ba060807e031271f81457a187fa08/DebuggerDetection.cpp#L603中的一些反调试器函数

---

将

__asm {
    mov eax, fs:[30h]
    mov al, [eax + 2h]
    mov IsDbg, al
}

功能相同

__asm mov IsDbg, [fs:[0x30] + 0x2]

如果没有，为什么不呢？

另外，如何将其转换为纯C / C ++？我如何获得线程信息（特别是fs：[30h]）？

---

愿意

BOOL Int2DCheck()
{
    // The Int2DCheck function will check to see if a debugger
    // is attached to the current process. It does this by setting up
    // SEH and using the Int 2D instruction which will only cause an
    // exception if there is no debugger. Also when used in OllyDBG
    // it will skip a byte in the disassembly and will create

    __try
    {
        __asm
        {
            int 2dh
            xor eax, eax
            add eax, 2
        }
    }
    __except(EXCEPTION_EXECUTE_HANDLER)
    {
        return false;
    }

    return true;
}

是一样的

__try
{
    __asm
    {
        xor eax, eax
        int 0x2d
        inc eax
    }
}
__except(EXCEPTION_EXECUTE_HANDLER)
{
    return false;
}

如果没有，为什么不呢？

Answer 1

这两种技术都比较陈旧。我认为它们在21世纪初使用，如果不是90年代后期。

---

第一个使用Thread-Information Block (TIB)驻留在fs:[0]进行Windows进程的事实（至少晚到WinXP ......从那以后我没有看过）。

进入TIB的偏移量0x30是指向Process Environment Block (PEB)的指针。从该链接，我们看到PEB中的偏移量0x2是“被调试”标志。这是API调用IsDebuggerPresent读取的值。

---

第二个例子演示了两种检测机制：

This answer详细介绍了int 0x2d在windows上的功能。目前，我们只是注意到它是Windows内置调试支持的一部分。

更简单的机制是：Windows中的结构化异常处理会捕获基于语言的异常无法处理的事情，因为它被挂钩到操作系统的异常处理框架，而不是语言运行时框架。

所以int 0x2d会产生一个错误;任何存在的调试器都会处理错误，并且由于此中断用于调试，调试器将像往常一样返回到控制流。因此，不会调用结构化异常处理机制......因此永远不会达到'catch'，因此函数的返回值也会改变。通过告诉调试器将异常传递给程序，这个方法很容易被后来的SEH感知调试器所击败，在这种情况下SEH会触发。

另一个机制是基于窗口处理int 0x2d的方式的详细信息，显然OllyDbg（一个曾经失效并且回来时充满恶意软件的非凡的调试器）完全没有模仿。我个人并不熟悉这种方法，所以我会引导你找到相关的答案。

仅就上下文而言，反调试技术的早期阶段是对特别流行的调试工具的研究。无论你从哪种文档中挖掘这些技术，你都会看到专门用于检测NuMega Softice的文件 - 可能是Windows的第一个内核调试器（大约NT 4.0）。从我的句柄派生的指令序列被用作检测该调试器的方法。

谢谢你的记忆之旅;）