来自用户空间的int指令

Question

我的印象是x86上的“int”指令没有特权。所以，我认为我们应该能够从用户空间应用程序执行此指令。但似乎并非如此。

我正在尝试从Windows上的用户应用程序执行int。我知道这样做可能不对。但我想要玩得开心。但Windows正在杀死我的应用程序。

我认为问题是由条件cpl＆lt; = iopl引起的。有谁知道如何绕过它？

Answer 1

通常，用户模式代码转换到内核模式以调用内核服务的旧调度程序机制由int 2Eh实现（现在由sysenter替换）。此外，int 3仍为断点保留至今。

基本上，内核为某些中断设置了陷阱（不记得是否为所有中断），并且根据陷阱代码，它们将为用户模式调用者执行某些服务，或者如果不可能，您的应用程序将被杀死，因为它尝试了特权操作。

无论如何，详细信息取决于您尝试调用的确切中断。函数DbgBreakPoint（ntdll.dll）和DebugBreak（kernel32.dll）除了调用int 3（或实际上是特定的操作码int3）之外什么都不做，例如。

编辑1：在较新的Windows版本（XP SP2及更新版本，IIRC）sysenter替换int 2Eh，正如我在答案中写的那样。它终止的一个可能原因 - 尽管你应该能够通过异常处理来捕获它 - 是因为你没有传递它在堆栈上预期的参数。基本上，本机API的usermode部分将您调用的系统服务的参数放入堆栈，然后将服务的编号（系统服务调度程序表中的索引 - SSDT，有时是SDT）放入特定的寄存器中，然后调用在较新的系统sysenter和旧系统int 2Eh上。

Answer 2

给定中断向量的最小环级别（决定给定的“int”是否具有特权）是基于与中断描述符表中的向量相关联的环级描述符。

在Windows中，大多数中断都是特权指令。这可以防止用户模式仅仅调用双故障处理程序来立即检查操作系统。

Windows中存在一些非特权中断。具体做法是：

• int 1（如果在eflags中设置EFLAGS_TF，则在单条指令后发生CD 01编码和调试中断）
• int 3（编码CC和CD 03）
• int 2E（Windows系统调用）

所有其他中断都是特权，并且调用它们会导致发出“无效指令”中断。

Answer 3

INT是一种“特权控制”指令。内核必须以这种方式保护自己免受用户模式的影响。 INT经历与硬件中断和处理器异常完全相同的陷阱向量，因此如果用户模式可以任意触发这些异常，则中断调度代码将会混淆。

如果要在特定向量上触发尚未由Windows设置的中断，则必须使用调试器或内核驱动程序修改该中断向量的IDT条目。 Patchguard不允许您从x64版本的Windows上的驱动程序执行此操作。