【问题标题】:int instruction from user space来自用户空间的 int 指令
【发布时间】:2012-05-14 11:56:57
【问题描述】:

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

我正在尝试从 Windows 上的用户应用程序执行 int。我知道这样做可能不对。但我想找点乐子。但是 Windows 正在杀死我的应用程序。

我认为问题是由于条件 cpl

【问题讨论】:

  • 你试图调用什么int

标签: windows assembly x86 kernel


【解决方案1】:

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

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

无论如何,细节取决于你试图调用的确切中断。例如,函数DbgBreakPoint (ntdll.dll) 和DebugBreak (kernel32.dll) 除了调用int 3(或者实际上是特定的操作码int3)之外什么都不做。

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

【讨论】:

  • 我自己使用 int2E。我不确定 kernel32.dll 是否有一些调用 int3 的驱动程序组件。但目前 int2e 使用户应用程序崩溃。你知道可能是什么原因吗?
  • 什么操作系统?查看我修改后的答案(给我几秒钟)
  • 我在 win 7 上。我正在检查是否在其他陷阱的情况下观察到类似的行为。
  • 更准确,请... Windows 7 x64 与否?作为 WOW64 进程,即 32 位,在 64 位操作系统上与否?
  • 是win 7, 64位。我试图弄清楚硬件是否在 int 上出现故障或陷阱处理程序是否引发错误。可能会发生 x86 硬件不允许根据其微码从用户空间执行 int 的情况。第二种可能性是陷阱处理程序正在启动应用程序的终止。
【解决方案2】:

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

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

Windows 中有一些非特权中断。具体来说:

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

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

【讨论】:

    【解决方案3】:

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

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

    【讨论】:

      猜你喜欢
      • 2023-04-04
      • 1970-01-01
      • 1970-01-01
      • 2011-05-23
      • 2013-02-13
      • 2018-07-06
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多