Hook Int 10h 导致窗口加载失败答案

【问题标题】：Hook Int 10h cause the Window load failHook Int 10h 导致窗口加载失败
【发布时间】：2017-03-07 20:29:09
【问题描述】：

我尝试编写一个非常简单的引导代码来挂钩 INT 10，如下所示：

New_int10：

Pushf
Cli
Call [CS:old_Int10]
Iret

代码在所有情况下都可以正常工作，但是当我尝试启动到 Window 时。系统挂起。我在 Bochs 中调试并注意到 OS 尝试切换 到 v8086 模式然后调用 Int10 并使用我的新 Int10 处理程序（address 0x97400）执行失败（它没有转到导致系统挂起的处理程序，似乎保护模式下的某些映射不正确）。

如果不更改INT10，我可以进入int10 handler（address 0xC0152 的原始处理程序）。

我错过了什么吗？

我已经用Int15h钩住Int15h注册新处理程序的区域e820 type = 2

更新：我做了更多调试并发现...当窗口（仅在 Windows 启动到安全模式时发生）切换到 v8086 模式时，它设置 VME（在 CR4 中）= 1 ,IPOL=3，程序跳转到 0x97400。不幸的是，页面映射当前将此地址映射到另一个物理地址 0x7dd2000 ......所以应用程序发疯了。地址 0xC0000 仍然映射到 0xC0000，这解释了为什么如果我们不更改 INT10，窗口可以启动。

我的问题：有什么方法可以通知 Window Boot Loader 不要重新映射地址 0x97400？

谢谢

【问题讨论】：

1) 为什么你的处理程序中有cli 指令（没有任何对应指令）？你确定系统没有用一些数据重写它的位置来修改你的处理程序吗？
iret 命令将从堆栈中弹出标志，因此 cli 不会影响功能...我只是放在那里，因为有些参考代码做到了。我可以确定系统没有修改代码，因为在进入 INT10 之前...我将代码转储到地址 0x97400，它没有任何变化。我怀疑窗口在设置 v8086 模式之前使用了一些其他信息，我可能会错过

标签： x86 operating-system kernel bootloader x86-emulation

【解决方案1】：

好吧，我终于解决了这个问题。

我必须将 edba 从 0x9fc00 复制到 0x97400 并将 0x40e 调整到新位置 0x97400。然后我将我的代码重新定位到 EDBA 旁边并更新 EDBA 大小。然后代码就可以运行了。

我猜 Window Boot Loader 尝试将 640K 映射到 0x7dd2000 的新位置。然后它只复制 bda（从 0 到 4ff）和 ebda（从 0x9fc00 到 0xa000）到新位置……所以重新定位 edba 并更新 edba 的大小就可以了。

【讨论】：