在 Windows 上的用户空间中“捕获”进程自己的 sysenter 调用答案

【问题标题】："Trapping" a processes' own sysenter calls in userspace on Windows在 Windows 上的用户空间中“捕获”进程自己的 sysenter 调用
【发布时间】：2015-07-22 09:42:58
【问题描述】：

我正在 Windows 中开发一个运行时非本机二进制转换器，到目前为止，我已经能够为我尝试使用丑陋的操作系统二进制文件“捕获”中断（即 INT 0x99）使用 Windows SEH 处理无效中断的 hack；但仅仅是因为系统调用向量与 Windows 中的不同，因此我可以通过执行以下操作来捕获这些“软”异常：

static int __stdcall handler_cb(EXCEPTION_POINTERS* pes, ...)
{

    if (pes->ExceptionRecord->ExceptionCode != EXCEPTION_ACCESS_VIOLATION)
        return EXCEPTION_CONTINUE_SEARCH;

    char* instruct = (char*) pes->ContextRecord->Eip;

    if (!instruct)
        handle_invalid_instruction(instruct);   

    switch (instruct[0])
    {
        case 0xcd: // INT
        {
            if (instruct[1] != 0x99) // INT 0x99
                handle_invalid_instruction(instruct);
            handle_syscall_translation();
            ...
        }
        ...
        default:
            halt_and_catch_fire();
    }
    return EXCEPTION_SUCCESS;
}

效果相当好（但速度很慢），问题在于 Windows 首先尝试处理指令/中断，对于使用 sysenter/sysexit 而不是 int 0x99 的非本机二进制文件，一些 systenter 指令在非-native 二进制文件在执行时实际上是有效的 NT 内核调用，这意味着我的处理程序永远不会被调用，更糟糕的是； “主机”操作系统的状态也受到影响。有没有办法在 Windows 中“捕获”系统输入指令？我该怎么做呢？

【问题讨论】：

这是在 64 位长模式下运行，还是在 32 位兼容 (WOW64) 模式下运行？
它使用 32 位比较模式，因为我模拟的二进制文件是 32 位的
我想这并不重要，因为 SYSENTER 在 32 位上仍然有效。我不确定是否有任何 32 位版本的 Windows 支持 SYSENTER，但显然（根据您的实验），它们确实支持。

标签： c windows interrupt system-calls interrupt-handling

【解决方案1】：

据我所知，没有办法（从用户模式进程）“禁用”SYSENTER，因此执行它会产生异常。（我假设你的程序不会尝试SYSEXIT，因为只有 Ring 0 可以这样做）。

我认为你唯一的选择就是像 VirtualBox 那样做，扫描无效指令，用非法操作码或类似的东西替换它们，你可以捕获和模拟。见10.4. Details about software virtualization。

为了解决这些性能和安全问题，VirtualBox 包含一个代码扫描和分析管理器 (CSAM)，它可以反汇编来宾代码，以及一个补丁管理器 (PATM)，它可以在运行时替换它。

在执行 ring 0 代码之前，CSAM 会递归地扫描它以发现有问题的指令。 PATM 然后执行原位修补，即它用跳转到集成代码生成器已放置更合适实现的管理程序内存来替换指令。实际上，这是一项非常复杂的任务，因为有很多奇怪的情况需要被发现和正确处理。因此，以目前的复杂性，有人可能会说 PATM 是一种高级的原位重编译器。

【讨论】：