现在的 PE 是用 svbus 还是 firadisk/winvblock？

2011whp

江南一根葱 发表于 2021-11-25 19:21
其实我U启一直拒绝用打包成iso的pe，iso除了虚拟机测试方便，别的一无事处
wim不香吗，无要求直接用bootmg ...

实验室 模式，帮忙 解 惑，发表下你的 看法

2011yaya2007777

不点，你说的XP破坏了6k内存，是推测？还是亲自测试的？

sunsea

2011whp 发表于 2021-11-25 19:55
537 - 296 =241 （正好 pe.iso的体积）

想要 想通 ，是否  又得这样 理解

不对。bootmgr在启动后把boot.wim已经完全读入内存，后面操作X盘就是ramdisk.sys的纯内存操作。没看懂你这个蓝色字什么意思。

2011yaya2007777

现在的int13头部2字节，就是驻留尺寸(kb)。只是没有修改0x40e处的值。

江南一根葱

2011whp 发表于 2021-11-25 19:58
实验室 模式，帮忙 解 惑，发表下你的 看法

我不懂编程，只通无脑使用，传统bios下，不管用什么方式引导iso
都容易 花屏

2011whp

sunsea 发表于 2021-11-25 19:58
不对。bootmgr在启动后把boot.wim已经完全读入内存，后面操作X盘就是ramdisk.sys的纯内存操作。没看懂你 ...

实践基础上，个人的 假说，猜想，不一定对的


意思是：x盘 不是一次性 建好的，boot.wim缓冲后， 边启动，边释放
           假说 ：微软 记着，boot.wim 的来源，svbus的出现，发现 来源变化了，

sunsea

2011whp 发表于 2021-11-25 20:10
实践基础上，个人的 假说，猜想，不一定对的

这就不知道了。事实上以【挂载】wim这个行为的存在来看，甚至不需要释放。这也是前面WIM不支持【固实】压缩算法的WIM启动的原因吧，固实都把数据混在一起了，无法【按需取用】

不点

2011yaya2007777 发表于 2021-11-25 20:03
现在的int13头部2字节，就是驻留尺寸(kb)。只是没有修改0x40e处的值。

不必修改了。想要让 EBDA 指针指向 int13 空间，那是我糊涂了，根本不可能。BIOS 不可能答应。

0x40E 处的指针，必须指向真正的 EBDA 数据结构。这个数据结构，在 DOS 时代是可以移动到别处的。但在现今的时代，能否移动，还得由实验来检验。

2011whp

江南一根葱 发表于 2021-11-25 20:07
我不懂编程，只通无脑使用，传统bios下，不管用什么方式引导iso
都容易 花屏

我也不懂，经验，假说，也是资料嘛

不点

2011yaya2007777 发表于 2021-11-25 19:58
不点，你说的XP破坏了6k内存，是推测？还是亲自测试的？

这不是推测的，也不是亲测的。是用户报告的。是 100% 可以信赖的。而且，报告者不止一人，是有很多人。

当用户报告问题的时候，我把 int15 e820 handler 的最开头修改为一条 far jmp 指令（指令占用 5 个字节，如果我没记错的话），跳转到原始的 ROM int15 处理程序入口。用户报告说，其死机、蓝屏的代码完全相同！这说明，就连这个 far jmp 指令都被破坏了！

我又让此用户测试不挂载 int15， 也就是，中断向量表的 0x0054 处的指针指向原始 ROM int15 入口，这次不死机了！于是后来就有了 e820cycles=0 这个参数的设计。

2011yaya2007777

我在实模式修改了0x40e的值，原以为会影响鼠标键盘，结果没有事。看来EBDA与鼠键无关。以前分析过DOS，好像EBDA内部有光驱的有关信息。我不清楚，EBDA只能有一个？还是可以一个接一个？

2011yaya2007777

如果破坏了int15，那么也应当破坏了int13，也就是说map功能完全失效了。是这样的吗？

2011yaya2007777

看来并非如此，e820cycles=0不更改int15 ，使得map 成功了！那说明int13驻留的map代码仍然在发挥作用。

不点

2011yaya2007777 发表于 2021-11-25 20:36
我在实模式修改了0x40e的值，原以为会影响鼠标键盘，结果没有事。看来EBDA与鼠键无关。以前分析过DOS，好像 ...

在 DOS 时代，EBDA 服务于 DOS。鼠标等数据，在 EBDA 里面占有重要地位。当时鼠标是热门，是前沿技术。

但是，现在时代变了，DOS 时代的那些玩意，比如软盘啊，光驱啊啥的，都淘汰了，那么，它们还有必要在 BDA 和 EBDA 里面存在吗？

因此，现在的 EBDA，那应该是服务于 Windows 了。甚至原有的 EBDA 规范，都可能被偷偷修改，也就是说，可能只有微软和硬件厂家知道，而别人不一定知道。

DOS 时代，EBDA 只能有一个。它的位置由 40E 处的指针来确定。

在现今的 Windows 时代，我猜，EBDA 应该依旧是为实模式程序（例如引导程序 bootmgr 等）服务的。Windows 内核是不需要它的。不仅不需要它，甚至整个 1M 以内的（常规内存）空间，都废弃不用。

既然这样，那么 EBDA 应该也只能有一个，不会是一连串。

另外一个问题：EBDA 在通电自检之后是否位于常规内存顶部？好像是的。假如有反例的话，那也是很少很少了。

40E 处的指针，必须指向真正的 EBDA 数据。如果不是指向真正的 EBDA 数据，BIOS 就可能混乱，失败，死机。有些厂家的硬盘参数，都保存在 EBDA 里面。EBDA 的内容要是有错的话，恐怕很容易死机的。

DOS 时代 EBDA 可以移动到别的地方，但由于 40E 处的指针是个段指针，因此，也只能移动到 16 字节对齐的地方。EBDA 的长度是 KB 对齐的，因此，EBDA 的长度一定是 1K，2K，3K，.... 等等。

现在 EBDA 能否移动，不知道。但我猜，八成还可以移动。

2011yaya2007777

e820cycles好像可以等于0，1，2，3等等。一直没有搞清楚，好像在计数，调用一次减一，直到为0，然后不再使用新int15，也就是不再保护g4d的驻留内存，

不点

2011yaya2007777 发表于 2021-11-25 20:41
如果破坏了int15，那么也应当破坏了int13，也就是说map功能完全失效了。是这样的吗？

看来并非如此，e820cycles=0不更改int15 ，使得map 成功了！那说明int13驻留的map代码仍然在发挥作用。

情况与你想象的，不太一样。

我猜，整个 int13 的空间，全部都毁掉了！

为什么？因为，在 int13 还没被毁掉之前，int13 的任务完成了。当 int13 被毁掉的时候，int13 已经不再被调用了。

某个 Windows 程序开始毁掉 int13，连同里面的 int15 代码一并毁掉。

虽然 int13 被毁，但永远不调用 int13，所以没事。

然而，后来有某个程序需要调用 int15，这就完蛋了，出现蓝屏死机。

本帖内容，都是我猜测的，不是 100% 肯定的。

sunsea

不点 发表于 2021-11-25 21:33
情况与你想象的，不太一样。

我猜，整个 int13 的空间，全部都毁掉了！

ntldr也是有个16进制桩和后面名为osloader.exe的结构，使用int13部分是把可能的RAMDISK镜像（用过原版老毛桃PE的一定记得有个提示符叫Loading RAMDISK……就是它）、ntoskrnl.exe、SYSTEM、SCSI Miniport组读入内存后就转交控制权到内核，此时已经不需要int13了。

当年Intel某些集成显卡的显存就是申请一块内存，所以我怀疑加载这种buggy的集显的时候还需要e820，单独确定为集显保留的内存地址是多少，然后爆炸（尤其是搞炸的那个文件叫framebuf更加加深了这种猜测）了。当年XP的内核机制也没那么完善。（不过就算这样似乎还有个神奇的东西叫KiI386CallAbios……据说能直接呼叫BIOS的那些int，不过这东西一直没文档化不敢用，没文档化约等于极易爆炸，说明这不是正常人该碰的东西。）

不点

2011yaya2007777 发表于 2021-11-25 21:16
e820cycles好像可以等于0，1，2，3等等。一直没有搞清楚，好像在计数，调用一次减一，直到为0，然后不再使 ...

是这样的：

int15 该不该挂上？如果一直挂上，遇到那个糟糕的 XP 机器，必然蓝屏。

如果一直不挂上，又担心内存盘没有保护，出现不可预知的问题。

所以，权衡以后，就开发了 e820cycles 参数。

目的是让用户测试，究竟调用多少轮次以后让 int15 脱钩合适。

结果，有人说 e820cycles=3 时，正常。

有人说，有几个分区，这个值就设置为几。

他们的意思好像是说，设置为别的值就不行。

没有一个统一的说法。

我猜，设置为 0 应该就行。但我也不能肯定这一点。

不点

sunsea 发表于 2021-11-25 21:48
ntldr也是有个16进制桩和后面名为osloader.exe的结构，使用int13部分是把可能的RAMDISK镜像（用过原版老 ...

你这个解释，牛B极了！显示出深厚的 Windows 底蕴！

太好了！你这是说，int13 的空间早都被毁了，只是 intel 显卡去调用 int15，所以死机了。假如它不去调用，那根本就没事！

也就是说，int13 空间总是被毁掉，不管是不是 Intel 的显卡。

而且，毁掉了也不要紧，只要不再调用 int15 即可。

---

可是，现在的 win11PE，却毁掉了尾部的碎片指针，貌似 int13 的代码还能工作，这怎么解释？

sunsea

不点 发表于 2021-11-25 22:16
你这个解释，牛B极了！显示出深厚的 Windows 底蕴！

太好了！你这是说，int13 的空间早都被毁了，只是 ...

我不确定int13是不是爆炸了，只是结合现象猜测当年可能得问题所在。现在内核机制应该改了。现在的集显似乎也不那么依赖内存做显存。

wintoflash

sunsea 发表于 2021-11-25 21:48
ntldr也是有个16进制桩和后面名为osloader.exe的结构，使用int13部分是把可能的RAMDISK镜像（用过原版老 ...

ntldr也是有个16进制桩和后面名为osloader.exe的结构，使用int13部分是把可能的RAMDISK镜像（用过原版老毛桃PE的一定记得有个提示符叫Loading RAMDISK……就是它）、ntoskrnl.exe、SYSTEM、SCSI Miniport组读入内存后就转交控制权到内核，此时已经不需要int13了。

是的, NT6+的 bootmgr 和 NT5 的 ntldr 是一脉相承的，结构相似。

不过就算这样似乎还有个神奇的东西叫KiI386CallAbios……据说能直接呼叫BIOS的那些int，不过这东西一直没文档化不敢用，没文档化约等于极易爆炸，说明这不是正常人该碰的东西。

Windows 应该是只会用它调用 int10h。Win7 UEFI 启动在某些机器上黑屏就是因为 int10h 有问题。

sunsea

wintoflash 发表于 2021-11-25 22:24
是的, NT6+的 bootmgr 和 NT5 的 ntldr 是一脉相承的，结构相似。

windows自己只会叫int10。当年某些buggy集成显卡就不好说。毕竟我还真用过此类buggy的集成显卡机器……那个出毛病水平真的不好说

sunsea

不点 发表于 2021-11-25 22:16
你这个解释，牛B极了！显示出深厚的 Windows 底蕴！

太好了！你这是说，int13 的空间早都被毁了，只是 ...

我瞎猜一种可能，注意只是瞎猜:控制权到bootmgr.exe，osloader.exe以后，bootmgr.exe会打扫之前ntldr、bootmgr等的常规内存“战场”，比如说压缩的部分，腾出空间以备他用，比如说给16进制桩读盘的时候做缓存用，或者之后的内核阶段ntoskrnl.exe或者什么驱动需要调用intXX的时候做存储区用，或者清理一下高地址给回来调用intXX的时候做堆栈用。结果int13顺便挂了。运气好不需要驱动的情况下，在控制权到达内核int13读盘阶段结束之前都没有出问题。之后已经不需要int13了，所以还能工作。

问题就在这里，鬼他妈知道bootmgr.exe的缓存策略和清理策略之类的……这尼玛就是个黑箱啊。当然也有可能是ntoskrnl.exe这个阶段打扫的。


继续瞎猜:常规内存此时极有可能已经不安全了。

总结:ntoskrnl.exe等很有可能会打扫常规内存以供某些系统调用需要intXX时使用，作为堆栈、缓冲区等。到达此处时int13的历史使命已经完成，所以它有没有被毁掉已经无关紧要，也有可能从低向上清理。但是某些傻逼集显这个时候还需要int15。自然就直接爆炸了。

不点

sunsea 发表于 2021-11-25 22:45
我瞎猜一种可能，注意只是瞎猜:控制权到bootmgr.exe，osloader.exe以后，bootmgr.exe会打扫之前ntldr、 ...

好吧，其实我们现在都是在帮 yaya。继续请教，我认为也是为了帮 yaya 来向你请教。

Windows 抛弃了 0x413 的内存规范，也抛弃了 int15/e820 关于常规内存保护这一部分的规范。

那么，其目的、原因是什么？

是不是因为，常规内存紧张，无法再容纳像 grub4dos 这样的仿真代码了？但仿真代码本来也就不多呀（12K左右）？连这么少的空间占用也不能容忍吗？总之，那是抛弃 DOS 规范。应该是故意的，而不是 Windows 开发者失误造成的。以这些开发者的水平，他们不至于犯如此低级的错误，他们是吃这碗饭的，不是扫大街的。

第二个问题：

抛弃规范以后，就剩下 EBDA 这一个规范了。那么，你觉得如下做法是否可行？其可行的概率有多大？

就是，把 EBDA 向下平移，腾出 12K 左右的空间，放入 grub4dos 的仿真代码。这样的话，期望 Windows 就不再破坏 grub4dos 的数据结构了。

sunsea

不点 发表于 2021-11-25 23:11
好吧，其实我们现在都是在帮 yaya。继续请教，我认为也是为了帮 yaya 来向你请教。

Windows 抛弃了 0x ...

原因倒很好猜。毕竟对于windows自身，实模式就是个历史遗留问题、负资产，扔掉求之而不得，反正人已经基本不靠实模式吃饭。或者干脆跟UEFI一样彻底砸碎了。所以此时除了刚开机那会，其他时候一切DOS的规范都无需理会。而且既然都进bootmgr了，还想回去、退出不成？

EBDA的问题那我就真不知道了，只能通过实验得到答案了吧。不过感觉应该破坏EBDA概率不算特别大，因为里面应该会有启动用得着的东西。

不点

sunsea 发表于 2021-11-25 23:19
原因倒很好猜。毕竟对于windows自身，实模式就是个历史遗留问题、负资产，扔掉求之而不得，反正人已经 ...

谢谢。深夜了，身体要紧，休息吧。

sunsea

不点 发表于 2021-11-25 23:24
谢谢。深夜了，身体要紧，休息吧。

其实最好的办法还是启动期间和之后抓一把前1MB内存看看长啥样。有时间我试试。G4D的int13，int15驻留程序有什么指标性特征吗？除了映射插槽的

不点

sunsea 发表于 2021-11-26 08:15
其实最好的办法还是启动期间和之后抓一把前1MB内存看看长啥样。有时间我试试。G4D的int13，int15驻留程 ...

是啊， 高手们用 bochs 虚拟机就能看到所有的真相。可惜，本人不熟悉，岁数大了，也不能多学。

yaya 的 0.4.6 的 仿真代码里面，似乎能看到不少字符串，这都可以看作是 grub4dos 的特征吧。

等我有时间了，专门为您总结一下。


好的，就在这说说。


我是用十六进制编辑器查看 grldr 文件，就能看到 int13 handler 的特征。每行 16 个字节。



grub4dos 版本 0.4.6 的 int13 处理程序，含有如下一些字符串：


G4DS              <----含有此字符串的行，是 int13 handler 的第一行，标志着数据段的开始。此行的开头是 0B（即，十进制的 11），代表着 int13 handler 的总长度是 11 KBytes。版本变化时，此处的长度也可能会变。其后的数据，就是虚拟盘与真实盘的对应表格，也就是 slot （插槽）数据。共有 8 个插槽。但文件碎片不在这儿，而是在 int13 handler 的尾部。


$INT13SFGRUB4DOS    <---- 这个字符串标志着代码段的开始。这一行是 int13 handler 的第 17 行。中断向量表的 0x004C 处的指针，指向此行的开头。此行的开头，是一条 jmp 指令，指令代码 E9。


grub4dos: A20 failure  <---- 这个串位于 int13 handler 总长的大约三分之一的位置


在 int13 handler 的中部，很容易发现有一两行 00 字节，接着是这条三字节的指令:


3D 20 E8  这是比较 AX 是否 E820——好的，你明白了，这其实就是 int15 处理程序的开头。也就是说，中断向量表的 0x0054 处的指针，应该指向这条指令。



A20 Debug: XXXX trying...  done!  <---- 这个串位于 int13 handler 总长的大约三分之二的位置


FRAGMENT <---- 这个串位于 int13 handler 的尾部附近，可能是标志着碎片的开始


int13end <---- 这个串标志着 int13 handler 的结束。

2011yaya2007777

其实最好的办法还是启动期间和之后抓一把前1MB内存看看长啥样

sunsea 超级版主说到点子上了。

启动先进入G4D，执行 :
map /xxx/pe.iso  (0xff)
map --hook
read 0x413   #取2位数，比如 0x270
calc 0x270*0x400  #0x9c00
echo --mem=0x9c000=0x3000 > g4d_mem_start.bin   #驻留信息不会超过0x3000。头标2字节是以kb计的字节尺寸。 预先准备一个文件g4d_mem_start.bin，填充0x3000以上字节。
chainloader (0xff)
boot

当遇到启动失败，需要设置 e820cycles= 时(如果此时还能进入G4D，再截取一份g4d_mem_end.bin。估计不可能)，设置 e820cycles=n，顺利进入 windows，然后使用内存查看器（具体是什么软件，请提供几个），再截取0x9c000处的0x3000字节保存为g4d_mem_end.bin。

下来就是做分析了。这是最真实的证据。到底 windows 修改破坏了没有，又是如何破坏的，真相大白！

sunsea

2011yaya2007777 发表于 2021-11-26 09:59
sunsea 超级版主说到点子上了。
启动先进入G4D，执行 :
map /xxx/pe.iso  （0xff)

搜了下，似乎要用一些Native API或者写驱动进R0搞。我试试吧，看看能不能这两周倒腾个转储工具出来。