grldr使得bootmgr不能识别exfat

yaojy

U盘采用exfat格式，用win8的bootmgr可以正常识别并引导PE，用grldr（改名为bootmgr）也能识别出exfat并引导PE（ISO方式）。
但如果grldr以chainloader /xxx/bootmgr方式引导win7PE时，出现0xc0000225错误，不能读取U盘中的bcd文件。
然而如果U盘采用NTFS或FAT32格式，就不会有上述问题的。
请高手指点。为何这个过程“U盘MBR”→bootmgr（由grldr改名）→xxxmgr（由win8的bootmgr改名），就会使得win8的bootmgr识别不了exfat？

不点

当初 chainloader 加载 NTLDR，是发现了 NTLDR 的一个秘密，即，必须在 0000:7C00 放置 NTLDR 所在分区的 BPB 表（放上 512 字节的 PBR 引导扇区就够了）。如果在 0000:7C00 不放置这个 PBR ，那么 NTLDR 的启动将会失败。因此，chainloader 自动加载这个 PBR 到 0000:7C00，然后再把控制传递给 NTLDR 的第一条指令，这样，就可以成功引导 NTLDR 了。

exfat 出现之后，BPB 不存在了。因此，上述启动 NTLDR 的逻辑将失败。需要 yaya 继续破解 bootmgr 的秘密。

在 yaya 破解之前，yaojy 可以试试在 chainloader 之后紧跟着执行一次 dd if=()+12 of=(md)0x3E+12 ，即手动把 PBR 处的 12 个扇区加载在 0000:7C00 之后的连续内存空间，看看这样行不行。

yaojy

在 chainloader 之后紧跟着执行一次 dd if=()+12 of=(md)0x3E+12 的结果是：立马重启

不点

抱歉，脑子已经开始糊涂了。

如果在 0000:7C00 放置 12 个扇区，必然破坏掉现有的 grub4dos 核心代码。因此，立即重启了。

看来 boot 的代码也得修改才能应用这种方法。

再想想有没有简单的办法先来测试一下这种方法？

2011yaya2007777

使用win8的bootmgr或grldr（改名为bootmgr）引导，是从exfat格式的PBR加载的，此时PBR已经在0000：7c00。其中的偏移0x40--0x77就是BPB表，只不过形式和内容与FAT12/16/32不同而已。win8的bootmgr或grldr（改名为bootmgr）运作时需要从BPB表获取参数。

不点

既然这样，那么如何解释 chainloader 加载 bootmgr 出现失败的问题？

注意，chainloader 也已经把 PBR 的一个扇区放在 0000:7C00 了。因此我怀疑，单一的扇区可能是不够的，需要包括整个 PBR 中的引导代码。

2011yaya2007777

请问：chainloader 是否加载 bootmgr 全部文件到 2000:0000 ？

不点

不。

由于 bootmgr 超过 512 字节，chainloader 只是记住它的文件名（文件的位置）。待到 boot 执行的时候，最后才真的执行一段汇编代码 HMA_ADDR ，这才把 bootmgr 的内容放置在 2000:0000 并递交控制权。

chainloader /bootmgr 执行之后，0000:7C00 处已经正确放置了 512 字节的 PBR 了。不过，我怀疑这 512 字节对于新的 exfat 来说是不够的，正如前面已经提到的。

fujianabc

直接把exfat的启动扇区保存成文件（比如chainloader /exfat.bin）来chainloader的话，哪怕启动扇区文件只有开头一个扇区也能成功

不点

你说的情况是当然成功的，与此处讨论的问题无关。

第一扇区本来就是供 BIOS 加载之用的，它当然能成功启动。这个第一扇区可以根据自己的需要自动负责加载后续的扇区。

但我们此处讨论的问题，其性质根本不同。我们这里所加载的 PBR 扇区并不接管控制权（是 bootmgr 从 grub4dos 接管控制权的），PBR 只是供 bootmgr 调用而已。PBR 里面可能会提供一些函数，而 bootmgr 有可能调用其中的某些函数。这就是为什么要把 PBR 放在 0000:7C00 的原因。

2011yaya2007777

从 PBR 跳转到 2000：0000 之前，向 7C0B 填充每扇区字节数 200，向  7C1C 填充了分区起始扇区号，向 dl 传递了驱动器号，向 7C02 填充了1，表示支持扩展读写。

不点

请诸位确认一下，这样是不是就解决了？

在 chainloader /bootmgr 之后，执行以下这些命令：

1. 
   
2. write    0x7C02    1
   
3. write    0x7C0B    0x200
   
4. write    0x7C1C    0xYYYYYYYY
   

复制代码

注意，每条 write 命令写的是 4 个字节。在写之前，可以先用 read 命令读出原有值。然后计算一下该写什么值。

YYYYYYYY 是分区的起始扇区号，chainloader 命令会显示出 hidden sectors，这就是分区起始扇区号。

fujianabc

原帖由 不点 于 2012-7-12 21:15 发表
请诸位确认一下，这样是不是就解决了？

在 chainloader /bootmgr 之后，执行以下这些命令：


write    0x7C02    1
write    0x7C0B    0x200
write    0x7C1C    0xYYYYYYYY


注意，每条 write 命 ...

写了这三条命令后成功了!

[ 本帖最后由 fujianabc 于 2012-7-13 20:29 编辑 ]

不点

感谢！

我想，下一次，chenall 或 Roy 就可以修改 chainloader 了，也用不着把整个 12 扇区全都加载了。

下次修改时，建议把 asm.S 中的两、三条 hlt 指令全都注释掉。这些 hlt 指令带来的好处不明显，但坏处太大了，遇上有 bug 的 CPU，一条 hlt 指令会造成系统死掉。以前有人说 kexec 加载 grub.exe 死机，我觉得有可能与这些 hlt 指令有关。

另外，grub4dos 的 builtins.c 中有探测分区文件系统的代码，于是就知道一个分区究竟是 FAT、NTFS 还是 Ext2。现在多了一个 exfat，那么，还应该为 probe_bpb 函数添加探测 exfat 的代码。这个工作好像应该由 yaya 来做。

2011yaya2007777

请问：（struct master_and_dos_boot_sector *BS） 取自 0x7c00 还是 0xd000 ? 这2处可能不一样。

不点

你说的是什么意思？是指 probe_bpb 参数表里面的 BS 吗？

int
probe_bpb (struct master_and_dos_boot_sector *BS)
{
}

参数里的 BS，它仅仅是虚参，由调用者填写实参啊。调用者可以填写任意的值，让 probe_bpb 函数去检查那里的 boot sector 所体现出来的文件系统类型。

这里你不用管 BS 究竟具体指向什么位置，只要知道，BS 正是用户希望检查其 BPB 的、 512 字节扇区数据的开始。用户给定一个 BS，那么 probe_bpb 的任务就是计算这个 BS 所指向的 512 字节究竟代表何种文件系统。