我正在反转一个使用串行接口（COM1 端口）的应用程序，并使用 API Monitor 来跟踪 API 调用。
我找到了对CreateFileA("\\.\Commsb96", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL). 我相信这是打开串口。
不久之后，代码运行DeviceIoControl，dwIoControlCode（第二个参数）设置为0x0022002b。
API Monitor 将其识别为 IOCTL_INTERNAL_USB_RECORD_FAILURE。鉴于这不是 USB 设备，我怀疑这是标签错误。如果是这样，我如何确定是什么0x0022002b？
如果不是，那么 IOCTL_INTERNAL_USB_RECORD_FAILURE 到底是什么。调用 DLL 是 VcomSB96.dll。
谢谢！
正如 Nirlzr 所说，这不是COM1设备。它是一个虚拟设备，充当实际 COM1 接口的中介。我调试了 .sys 文件，该文件仅使用了 IOCTL_INTERNAL_USB_RECORD_FAILURE，但仅使用了该 IOCTL 命令。
任何一个设备 I/O 控制代码的含义都受某些约定的约束。微软在位域中定义了代码，其中最引人注目的是作为设备类型的高位字。Microsoft 为许多类型的设备定义了许多 I/O 控制代码。如果驱动程序正在执行以处理该类型的设备，它应该期望接收那些相应的 I/O 控制代码并按照 Microsoft 定义的方式解释它们。从这个意义上说，这些 I/O 控制代码是明确定义的，因此如果您或诊断工具看到一个，通过已知的符号值识别它是合理的。
但是，驱动程序可以创建与硬件无关的设备对象。这样的设备不会成为任何设备 I/O 控制的目标，以帮助管理系统知道或关心的任何类型的设备，因此驱动程序可以编写它想要的任何 I/O 控制代码。这是驱动程序与协作应用程序通信的长期建立的机制。
通常，为此目的而发明的 I/O 控制代码倾向于将 0x0022，即 FILE_DEVICE_UNKNOWN 作为设备类型。对您进行逆向工程的实际后果是，具有 0x0022 作为高位字的相同设备 I/O 控制代码可能意味着与不同设备完全无关的事情，即使在同一驱动程序中实现也是如此。
现在，Microsoft 通过将 FILE_DEVICE_UNKNOWN 用于 I/O 控制代码，这些代码可以发送到物理设备的驱动程序，从而使水变得浑浊。但是，除非您或您的诊断工具知道您正在查看可以接收这些 I/O 控制代码的驱动程序，否则该工具将 0x0022XXXX 数字解析为的任何符号很可能是您最好忽略的幻想。