驱动级输入模拟技术解析

关注

原创最新推荐文章于 2026-10-11 16:05:05 发布 1.1k 阅读 AI 写同款· GEO 优化 ›

驱动级鼠标键盘模拟：深入理解与实战实现

在现代操作系统中，自动化输入早已不是简单的“调用 SendInput ”就能解决的问题。当你试图在一个锁定的登录界面自动填写密码、绕过游戏反作弊系统执行宏操作、或为残障用户构建无障碍控制平台时，标准API往往无能为力——它们被设计成安全且受限的接口，而这正是驱动级输入模拟技术存在的意义。

这类技术不走寻常路：它绕开用户态的安全围栏，直接在内核层面伪造硬件行为，让操作系统“以为”真的有物理设备发来了按键或移动信号。这其中，既有基于老旧但实用的PS/2端口操作（如WinIo），也有面向未来的虚拟HID设备仿真。两者虽层次不同，目标一致： 以最底层的方式，完成最高权限的输入注入 。

要理解为什么普通API会失败，就得先明白Windows是如何处理键盘和鼠标的。从你按下机械键盘的一个键开始，信号经过控制器、USB协议栈、HID类驱动解析，最终变成一条可被应用程序接收的输入事件。而像 SendInput 这样的函数，其实是在这个流程的“半山腰”插入数据——它依赖 win32k.sys 将模拟事件分发下去。这种机制天然容易被拦截，尤其在UAC提升界面、安全桌面或某些全屏独占程序中，UIPI（用户界面特权隔离）会直接阻止低权进程向高权窗口发送消息。

真正的突破口，在于跳过这一切，直接对接HID堆栈或者传统I/O端口。这就像是不再打电话让人开门，而是自己拿着钥匙走进去。

WinIo库就是这样一个“万能钥匙”的简化版。它由Tobias Hoffmann开发，允许32位应用程序通过一个内核驱动（WinIo.sys）访问物理I/O端口和内存地址。虽然它并非真正的“编写驱动”，但借助这个中间层，开发者可以用C++代码直接读写PS/2控制器的寄存器，从而模拟真实的键盘扫描码输入。

比如，PS/2键盘通信依赖两个关键端口：
- 0x64 ：状态寄存器，用于判断控制器是否空闲；
- 0x60 ：数据寄存器，用来发送命令或扫描码。

下面这段代码展示了如何用WinIo模拟一次“A”键的按下与释放：

#include "WinIo.h"
#include <stdio.h>

int main() {
    if (!InitializeWinIo()) {
        printf("Failed to initialize WinIo.\n");
        return -1;
    }

    BYTE dataPort = 0x60;
    BYTE statusPort = 0x64;
    BYTE scanCode = 0x1C;     // 'A'按下
    BYTE releaseCode = 0x9C;  // 'A'释放

    // 等待输入缓冲区空闲（bit 1 表示忙）
    while ((GetPortVal(statusPort) & 0x02)) {
        Sleep(1);
    }
    SetPortVal(dataPort, scanCode, 1);

    Sleep(100);  // 模拟按键持续时间

    while ((GetPortVal(statusPort) & 0x02)) {
        Sleep(1);
    }
    SetPortVal(dataPort, releaseCode, 1);

    ShutdownWinIo();
    return 0;
}

这里的关键在于对状态寄存器的轮询。如果你强行往还在忙的端口写数据，轻则无效，重则导致系统不稳定甚至蓝屏。此外，部分系统还需要通过内联汇编触发中断通知，例如使用 out 0x64, 0xD4 来指示后续数据应转发给辅助设备（即鼠标通道）。这正是PS/2协议中“命令-数据”交互的一部分。

说到鼠标，WinIo同样可以模拟相对位移。以下是一个简化的移动函数：

void SimulateMouseMove(int dx, int dy) {
    const BYTE mouseCmd = 0xD4;

    // 启用鼠标接口
    while ((GetPortVal(0x64) & 0x02)) Sleep(1);
    SetPortVal(0x64, mouseCmd, 1);
    SetPortVal(0x60, 0xA8, 1);  // enable aux port

    Sleep(10);

    // 设置采样率（必须设置才能启用运动）
    SetPortVal(0x64, mouseCmd, 1);
    SetPortVal(0x60, 0xF3, 1);
    SetPortVal(0x64, mouseCmd, 1);
    SetPortVal(0x60, 200, 1);

    // 发送三字节移动包：[状态][ΔX][ΔY]
    BYTE statusByte = 0x09;  // 左右键未按，X/Y有效
    if (dx < 0) statusByte |= 0x10;
    if (dy < 0) statusByte |= 0x20;
    dx = abs(dx); dy = abs(dy);

    SetPortVal(0x64, mouseCmd, 1);
    SetPortVal(0x60, statusByte, 1);
    SetPortVal(0x64, mouseCmd, 1);
    SetPortVal(0x60, (BYTE)dx, 1);
    SetPortVal(0x64, mouseCmd, 1);
    SetPortVal(0x60, (BYTE)dy, 1);
}

注意状态字节的构造规则：第7位恒为1，第4~5位是符号位，第1~2位表示左右键状态。这些细节决定了系统能否正确解析你的“假动作”。

不过，WinIo的局限性也很明显。它依赖PS/2控制器的存在，在纯USB架构的现代PC上可能根本不起作用；更不用说64位系统默认强制驱动签名，使得加载未签名的WinIo.sys变得异常困难。因此，真正可靠的方案是转向HID仿真驱动。

HID（Human Interface Device）是USB规范中的标准设备类，几乎所有现代键盘鼠标都遵循这一协议。操作系统通过 hidclass.sys 解析设备上报的数据报告（Report Buffer），并将其转化为输入事件。如果我们能创建一个“虚假”的HID设备，并定期提交构造好的报告，就能实现完全隐身的输入注入。

实现这一点需要WDK（Windows Driver Kit）编写一个内核驱动，通常作为Filter Driver挂载在真实设备之上，或作为Bus Enumerator注册虚拟设备。核心步骤包括：

定义HID报告描述符（HID Report Descriptor）
这是一段二进制结构，告诉系统“我是什么样的设备”。例如，下面是一个键盘设备的典型描述符片段：

static CHAR g_ReportDescriptor[] = {
    0x05, 0x01,        // USAGE_PAGE (Generic Desktop)
    0x09, 0x06,        // USAGE (Keyboard)
    0xA1, 0x01,        // COLLECTION (Application)
    0x05, 0x07,        //   USAGE_PAGE (Keyboard)
    0x19, 0xE0,        //   USAGE_MINIMUM (Left Control)
    0x29, 0xE7,        //   USAGE_MAXIMUM (Right GUI)
    0x15, 0x00,        //   LOGICAL_MINIMUM (0)
    0x25, 0x01,        //   LOGICAL_MAXIMUM (1)
    0x75, 0x01,        //   REPORT_SIZE (1)
    0x95, 0x08,        //   REPORT_COUNT (8)
    0x81, 0x02,        //   INPUT (Data,Var,Abs) ; Modifier byte
    0x95, 0x01,
    0x75, 0x08,
    0x81, 0x01,        //   INPUT (Constant) ; Reserved
    0x95, 0x06,
    0x75, 0x08,
    0x15, 0x00,
    0x25, 0x65,
    0x05, 0x07,
    0x19, 0x00,
    0x29, 0x65,
    0x81, 0x00,        //   INPUT (Data,Ary,Abs) ; Key array
    0xC0               // END_COLLECTION
};

这段描述符声明了一个支持8个修饰键（Ctrl/Shift等）、6个常规按键的键盘设备。操作系统据此分配缓冲区并准备接收数据。

提交输入报告
在驱动中启动定时器或DPC（Deferred Procedure Call），周期性地调用HID库函数提交报告：

HidLibrarySubmitIdleNotificationRequest(queue, reportBuffer, sizeof(reportBuffer));

其中 reportBuffer 的内容需严格符合描述符格式。例如，按下左Ctrl+A的操作，其报告可能是：

[0x01] [0x00] [0x04] [0x00] [0x00] [0x00] [0x00] [0x00]
 ^      ^     ^
 |      |     └── 第二个按键：A（Usage ID 0x04）
 |      └─────── 其余五个按键为空
 └────────────── Modifier: 左Ctrl（bit 0 set）

这种方式的优势在于： 完全合法、不可区分、跨会话生效 。无论是登录前、安全桌面还是远程桌面断开状态，只要内核运行，虚拟HID设备就能工作。

当然，代价也不小。你需要掌握WDK编程、熟悉WDF框架、处理IRP调度，并为驱动获取数字签名——否则在64位系统上根本无法加载。调试过程更是充满挑战，一次错误的内存访问就可能导致BSOD。

实际应用中，合理的架构往往是双模混合的：

用户程序 → IOCTL控制 → 内核驱动
                     ↘ 尝试HID注入（首选）
                       ↘ 失败则降级至WinIo（仅Legacy）

这样既保证了现代系统的兼容性，又保留了对旧设备的支持能力。

安全性方面必须格外谨慎。此类技术极易被恶意软件滥用，因此在产品设计中应加入多重防护机制：
- 使用证书验证确保只有授权程序能触发注入；
- 实施进程白名单，拒绝未知来源的请求；
- 记录操作日志，便于审计追踪。

稳定性同样不容忽视。I/O端口操作若缺乏超时控制，可能造成死循环；错误的HID报告长度或格式会导致系统拒绝接收甚至崩溃。建议所有关键操作都包裹在 try/except 块中，并设置最大重试次数。

部署时还需考虑环境差异。VMware、VirtualBox等虚拟机常屏蔽I/O端口访问，此时WinIo必然失效。可通过检测 __cpuid 指令返回的厂商字符串来判断是否运行在虚拟化环境中，提前规避风险。

回望整个技术演进路径，WinIo代表的是一个时代的过渡方案——它降低了底层开发门槛，让更多人得以窥见硬件交互的本质。然而随着Windows安全机制不断强化（如HVCI、VBS、Secured Core PC），这条路正逐渐关闭。未来属于可信执行环境下的安全输入通道，例如基于虚拟化的隔离桌面或Windows Defender System Guard支持的受保护输入流。

但对于许多现实场景而言，掌握这些“老派”但有效的技术仍然至关重要。无论是为工业控制系统编写调试工具，还是为视障人士开发语音转输入的辅助设备，亦或是进行操作系统教学实验，理解输入子系统的底层运作逻辑，始终是一名资深工程师的基本功。

归根结底，驱动级输入模拟不只是“怎么骗过系统”，更是“系统本该如何设计”的一面镜子。当我们有能力从硬件层影响行为时，才真正理解了所谓“安全边界”背后的取舍与妥协。