gpt4 book ai didi

assembly - 如何检测卷引导记录(分区引导扇区)中的保护模式?

转载 作者:行者123 更新时间:2023-12-04 10:39:52 26 4
gpt4 key购买 nike

我正在 x86 PC 上以 MBR 模式(无 EFI)调试一个不寻常的启动安排。IPL在 MBR --> 异国情调 BootManager * --> Partiton Boot Sector --> 实验 OS我在 16 位实模式下编写了一个原始的 512 字节分区引导扇区 (PBR) x86程序集,它使用 int 10h BIOS 服务显示传递给它的 16 位寄存器。它适用于调试。
我想增强我的调试 PBR 以显示有关 CPU 模式的信息,即 BootManager 是否已经将 CPU 切换到 Protected Mode (32 位或 64 位)或其子模式,例如 Virtual 8086 mode .我需要此信息用于调试目的。
如何可靠地检测CPU mode (及其子类型)在这种情况下?

  • BootManger 位于 MBR 和第一个分区之间的扇区中,它拦截/模拟 BIOS 服务/中断 - 我已经看到它指向 int 13h在调试器中向量到自身

  • 编辑:这个问题不是关于检测在软件中模拟的 CPU 的 CPU 模式。 (又名:虚拟 CPU)
    另外, Virtual CPUVirtual 8086 mode 不一样真正的 CPU。 Virtual 8086 mode是CPU模式,是 Protected Mode的子模式并且它是在硬件中实现的,所以这个子模式的检测是这个问题的主题,以及 32 位和 64 位的检测 protected modes等...在真正的硅片上实现。

    最佳答案

    为了防范简单的 rootkit,很容易检查您是否处于 virtual8086 模式(如 ecm 的评论中所述 - 例如 smsw ax 并查看是否设置了低位)。
    这不会解决任何问题。
    问题是稍微高级的 rootkit 只会使用硬件虚拟化(例如 https://en.wikipedia.org/wiki/Blue_Pill_(software) ),因此您的简单测试将通过。
    要检测您是否处于虚拟化环境中,您需要利用仿真中的弱点(例如,检测行为略有不同的事物);但是如果您不知道可能的弱点是什么,这并不容易,任何弱点都可以在下一个版本的 rootkit 中得到纠正,直到没有弱点为止。
    换句话说;整个方法不能“保证成功”。相反,您需要一种不同的方法。
    替代方法是“测量”在启动期间执行的代码(因此您知道它是否被篡改/更改,因为您在启动后得到不同的测量结果),并首先防止未经授权的代码被执行.
    用于“测量”;它主要只是由特殊硬件(例如 TPM 芯片)完成的美化安全哈希。这有两种形式——“静态信任根”(对启动期间执行的所有内容的测量,包括固件、MBR 等)和“动态信任根”(在启动后将 CPU 重置为已知状态,然后测量来自那个已知状态的一切)。
    为了防止未经授权的代码被执行,最著名/受支持的实现是 (UEFI) SecureBoot。基本思想是使用数字签名(其中可执行文件的安全散列由发布者的私钥加密;这样可以通过使用发布者的公钥解密签名并将其与可执行文件的散列进行比较来检查签名文件)。这允许检测修改(散列错误),并允许发布者被识别和授权(如果发布者的公钥不在接受发布者的白名单中,或者在被拒绝发布者的黑名单中,则系统拒绝执行代码)。

    关于assembly - 如何检测卷引导记录(分区引导扇区)中的保护模式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59984168/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com