来自用户空间的int指令

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

我正试图从Windows上的用户应用程序执行int。 我知道这样做可能是不对的。 但是我想有一些乐趣。 但窗户正在杀死我的应用程序。

我认为这个问题是由于条件cpl <= iopl。 有谁知道如何解决它?

Solutions Collecting From Web of "来自用户空间的int指令"

一般来说,用于调用内核服务的用户模式代码转换到内核模式的旧调度器机制是由int 2Eh (现在由int 2Eh取代)实现的。 此外int 3仍然保留到今天的断点。

基本上,内核为特定的中断设置陷阱(尽管不记得是否),并且依赖陷阱代码,它们将为用户模式调用者执行一些服务,或者如果这是不可能的,那么你的应用程序将被终止,因为它尝试一个特权的操作。

无论如何细节将取决于你试图调用的确切的中断。 例如,函数DbgBreakPointntdll.dll )和DebugBreakkernel32.dll )除了调用int 3 (或实际上是特定的操作码int3 )之外别无其他。

编辑1:在较新的Windows版本(XP SP2和更新,IIRC) int 2Eh替换int 2Eh因为我在我的答案中写道。 被终止的一个可能的原因 – 虽然你应该能够通过异常处理来捕捉这个原因,这是因为你没有在堆栈上传递它所期望的参数。 基本上,本地API的usermode部分将您调用的系统服务的参数放入堆栈,然后将服务的号码(索引放入系统服务调度程序表 – SSDT,有时是SDT)放入特定的寄存器,然后调用在较新的系统sysenter和较旧的系统int 2Eh

INT是一个“特权控制”指令。 内核必须通过这种方式来保护自己免受用户模式的侵害。 INT经历了硬件中断和处理器异常完全相同的陷阱向量,所以如果用户模式可以任意触发这些异常,中断调度代码将会变得混乱。

如果你想触发一个特定的向量,而这个向量还没有被Windows设置,你必须用调试器或者内核驱动修改这个中断向量的IDT条目。 Patchguard不会让你从x64版本的Windows上执行此操作。

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

在Windows中,大多数中断是特权指令。 这样可以防止用户模式仅仅调用双重错误处理程序来立即对操作系统进行错误检查。

在Windows中有一些非特权的中断。 特别:

  • int 1(如果在eflags中设置了EFLAGS_TF,那么CD01编码和调试中断都会在单个指令后发生)
  • int 3(编码CC和CD 03)
  • int 2E(Windows系统调用)

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