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

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搞。我试试吧，看看能不能这两周倒腾个转储工具出来。

sunsea

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

我是傻逼。M$在XP以后彻底击毙了R3下访问物理内存的通道。必须写驱动进R0了。

wintoflash

sunsea 发表于 2021-11-26 10:47
我是傻逼。M$在XP以后彻底击毙了R3下访问物理内存的通道。必须写驱动进R0了。

可以用 RW-Everything 查看物理内存 http://rweverything.com/

xianglang

sunsea 发表于 2021-11-25 15:30
已证实，map --mem这部分内存会被直接不识别。（20H1的PE）
、

我也试了一下，map --mem 后的那部分内存，Windows 10 系统里面真的是不可用的，被认为是为硬件保留的内存。

图一：直接进入 Windows 10 桌面后的内存情况截图：


图二：先用 G4D 0.46a 用 map --mem USBOS3.ISO (hd) 映射一个 1.8GB 的 ISO 后进入 Windows 10 桌面后的内存情况截图：

sunsea

不点 发表于 2021-11-26 09:02
是啊， 高手们用 bochs 虚拟机就能看到所有的真相。可惜，本人不熟悉，岁数大了，也不能多学。

yaya  ...

目前的结果是，似乎是污染了，但没完全污染。

报告上载到附件了。

采用的测试代码如下，保存为C盘下的dump.cmd：

1. !BAT
   
2. debug 2
   
3. insmod /fat
   
4. map (hd0,4)/PE20H1.iso (0xff)
   
5. map --hook
   
6. read 0x413   #取2位数，比如 0x270
   
7. #calc 0x270*0x400  #0x9c00
   
8. set /a x=*0x413 & 0xffff
   
9. set /a x=%x% * 0x400
   
10. echo %x%
    
11. read %x%
    
12. set /a y=*%x% & 0xffff
    
13. set /a y=%y% * 0x400
    
14. echo %y%
    
15. map --rd-base=0
    
16. map --rd-size=0x100000000
    
17. if exist (hd0,4)/g4dmemst.bin fat del (hd0,4)/g4dmemst.bin
    
18. fat mkfile size=%y% (hd0,4)/g4dmemst.bin
    
19. dd if=(rd) of=(hd0,4)/g4dmemst.bin bs=1 count=%y% skip=%x%

复制代码

（hd0,4）是一个FAT32分区，在PE20H1.iso中制造了4个碎片。（制造方法：一个1GB的FAT32分区，然后使用fsutil file createnew D:\XXX 104857600创建一个100MB文件，共计十个，然后随机删除4个，拷贝入文件。）
%x%结果为0x9d000。%y%结果为0x2c00。
运行结果如图：


测试环境为：
1，本地硬盘的XP SP3，启动方式为上述批处理后接如下代码：

1. chainloader (hd0,0)/ntldr
   
2. root (hd0,0)
   
3. boot

复制代码

2，某坛友制作的无驱动的WIN10 20H1 PE，启动方式为上述批处理后接如下代码：

1. chainloader (0xff)
   
2. root (0xff)
   
3. boot

复制代码

测试方法：
1，g4d下执行脚本进行转录（结果为g4dmemst.bin）
2，进入系统桌面后立刻运行转储程序转储对应物理内存。（M0009D000.bin）


比较报告在附件，总结一下是确实有部分字节发生了变化，而且20H1变化的比XP的多。而且经过3次测试，变化较为稳定。

还需要更多环境进行测试，最好有e820cycles=0才能运行的buggy机器进行测试。不过似乎确实会造成污染。

有时间进行补充测试：抓前1MB进行比较。
提问：g4d下抓前1MB的合适时机是什么？是chainloader /ntldr以后还是什么时候？

2011yaya2007777

map --hook后抓

不点

sunsea 发表于 2021-11-26 15:44
目前的结果是，似乎是污染了，但没完全污染。

报告上载到附件了。

都正常，未被污染。


所改变的字节，都是运行过程中本来就可能变化的字节。


这么少的改变，不是污染。


如有几百字节的变化，那就可能是污染了。

2011yaya2007777

不加e820cycles=n就启动失败，这样的环境下测试，意义更大。

sunsea

2011yaya2007777 发表于 2021-11-26 18:48
不加e820cycles=n就启动失败，这样的环境下测试，意义更大。

对，所以需要等一个e820cycles=n的机器，到时候再做测试。到目前来说这个方面的探索可以告一段落了。

不过我还想请教咨询一下，g4d对非连续文件的碎片这部分的处理是怎样进行的？在未来比较空的时候考虑对svbus驱动打个补丁。

2011whp

用了 svbus，老老实实 map --mem  

多人结论（wintoflash  江南一根葱   yaya）

不加载内存，无解
iso转圈
img  wdf01000.sys

2011yaya2007777

sunsea：你能给svbus打补丁，那太好了。据说还有签名的问题。我先初步打个补丁，遇到不懂的地方再请教你。然后给你，你再仔细看看，错的地方修改一下，然后再编译。

sunsea

2011yaya2007777 发表于 2021-11-26 19:51
sunsea：你能给svbus打补丁，那太好了。据说还有签名的问题。我先初步打个补丁，遇到不懂的地方再请教你。 ...

这也不错，不过签名似乎x64比较无解……不过话都说回来了，都PE了，都用这玩意了，手动关签名应该都会吧？

wintoflash

sunsea 发表于 2021-11-26 19:52
这也不错，不过签名似乎x64比较无解……不过话都说回来了，都PE了，都用这玩意了，手动关签名应该都会吧 ...

安全启动开启的情况下 x64 windows 无法关闭签名验证。
另外 windows 11 已经拉黑了所有目前网上能找到的泄漏证书。

sunsea

wintoflash 发表于 2021-11-26 20:01
安全启动开启的情况下 x64 windows 无法关闭签名验证。
另外 windows 11 已经拉黑了所有目前网上能找到 ...

问题是你都用PE了……用g4e了……有用g4e还有用安全启动需求的嘛

wintoflash

sunsea 发表于 2021-11-26 20:02
问题是你都用PE了……用g4e了……有用g4e还有用安全启动需求的嘛

PE作者以 ISO 形式发布 PE 的时候肯定不希望他们的 PE 只能在关闭安全启动的情况下启动。
所以他们必然不会禁止签名验证。

2011yaya2007777

那就是说，不签名的话没有意义了。

sunsea

2011yaya2007777 发表于 2021-11-26 20:38
那就是说，不签名的话没有意义了。

问题来了，目前来说这套工具配套的是g4e，g4e本来就不是个和安全启动对接的玩意……

wintoflash

sunsea 发表于 2021-11-26 20:53
问题来了，目前来说这套工具配套的是g4e，g4e本来就不是个和安全启动对接的玩意……

装了未签名驱动，PE 必然过不了安全启动。所以 PE 发布者不会去装未签名驱动。

2011yaya2007777

windows签名与安全启动是一回事吗？那关闭安全启动，windows就不检查签名与吗？

sunsea

2011yaya2007777 发表于 2021-11-26 21:13
windows签名与安全启动是一回事吗？那关闭安全启动，windows就不检查签名与吗？

并不。安全启动是更高的要求。关了安全启动也会检查签名，不过此时可以手动关掉对签名的检查。不过还是那个问题，既然你都用g4e了，那么肯定不会开安全启动；不过PE作者可能希望自己的作品安全启动下也能用，不过这个时候就不会用g4e了。

wintoflash

2011yaya2007777 发表于 2021-11-26 21:13
windows签名与安全启动是一回事吗？那关闭安全启动，windows就不检查签名与吗？

不是一回事。
Windows驱动签名检查是在 BCD 里面配置的。
但是，如果启用了安全启动，Windows 就会强制检查驱动签名。
如果发现有未签名的驱动，Windows就会拒绝启动。
所以如果装了未签名驱动，就必须在 BCD 里面禁用签名验证，在安全启动情况下，PE 无法启动。
考虑到这一点，不可能有 PE 作者愿意集成未签名驱动。

wintoflash

sunsea 发表于 2021-11-26 21:24
并不。安全启动是更高的要求。关了安全启动也会检查签名，不过此时可以手动关掉对签名的检查。不过还是那 ...

这个问题与 g4e 没什么关系。主要是 PE 作者绝对不会愿意集成一个让 PE 过不了安全启动的驱动。
所以用户如果想用 g4e 启动ISO，必须自己修改 PE，把驱动装进去。那这 TM 还不如换个更稳妥的方法，比如自己写个挂载 ISO 的批处理。