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

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 的批处理。

不点

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

报告上载到附件了。

不需要 1M。抓那么多，太累，分析它们，更累。

在有问题的机器上，可以抓 0～640K 的常规内存。没必要抓 640K～1M 之间的数据。

kuer 大师的 win11PE，在我的电脑上运行，int13 空间肯定被污染了。

因为有碎片与无碎片，表现不同。

您也可以试试 kuer 的 PE，不需要抓很多扇区，只要抓 11K 的 int13 handler 即可。

补充：说错了，应该多抓点，抓 640K 的常规内存吧。注意下面的细节说明：

不同的机器，int13 handler 的位置不一样。

在执行 boot 之前，先把 0x80000 ～ int13 handler 这部分空间用某个特殊字节填充，比如，用 0xCC 填充。注意不要破坏了 int13 handler 的任何部分。

boot 以后，进入 PE，再抓一次 640K 的常规内存。

除了观察 int13 handler 是否被污染以外，再看看那些 0xCC 字节是否被改动。

sunsea

不点 发表于 2021-11-26 21:54
不需要 1M。抓那么多，太累，分析它们，更累。

在有问题的机器上，可以抓 0～640K 的常规内存。没必要 ...

我也在等个能有问题的机器。抓到有问题的机器就搞。

不点

sunsea 发表于 2021-11-26 22:05
我也在等个能有问题的机器。抓到有问题的机器就搞。

不，不。

用你的机器就能试验，不需要问题机。

我修改了帖子，您重新看看。

kuer 的 PE，肯定会污染的，如果我没猜错的话。


更新:


我用 wintoflash 的那个 rw 工具查看了, 竟然没发现任何问题.


现在是在这个 PE 下打字.


我用 --mem 启动, 因为碎块有 158 个.


但这并不影响查看 int13 handler 是否被破坏.


int13 handler 的头部还是尾部, 都干净得很. 没有污染的痕迹.



FRAGMENT 前后有很多行的 00 字节, 这些 00 字节都很完整, 没有被污染.


int13end 前后也有很多 00 字节, 也全都没有污染.


FRAGMENT 和 int13end 之间, 全是 00, 没有污染的痕迹.


FRAGMENT 和 int13end 两个字符串本身, 完整显示,没有污染的痕迹.


请 yaya 留意这个情况.



感觉很奇怪. 因为在有碎片的情况下, 它是失败啊! 不能进入桌面.



现在猜测, 有两种可能性:


可能性 1:  仿真代码在碎片处理的时候, 含有 bug.


可能性 2:  wintoflash 所说的 Windows 初始化程序对于 int13 handler 的污染, 这一假设是错的, 不成立. 至少对 kuer 大师的这个 Win11PE 是不成立的.

2011whp

论意义的话，不太大，主要是 自由想象，

倒是，g4e 适应硬件，看到 这几天，10代以上的主板，有些变化，
可能随着win11 ，12代u 要有些 变革

还有是 github云编译主机，在升级，
g4e好像，修一修，能用 新gcc

据  wintoflash 说，grldr 是不能 用新 gcc的

2011whp

有个不  转圈的 情况：img pe


1. img  内部为 fat32
2. img 内容，为光盘内的 复制
3.  img 镜像，放在 实体盘的 fat32分区
4.  map /img.img  (hd)   这个情况，不转圈

5.  而且 可以回写 文件

——————————————————
怀疑  有  镜像 内外 不同的 分区驱动 造成转圈，而加载内存 可以 忽略 此问题

2011yaya2007777

2011whp：你那个svbus.iso里面记得是boot.wim吧。wim不苛求非的是ntfs分区吧。

2011whp

不管，wim内部，是说  img（或vhd）内部

wim 没解开

不点

前面说了，今天我用 rw 工具检查的结果是 int13 handler 完全没有被污染。

任何人，在任何机器上，都可以检查。方便得很！细说如下：

map --mem (...)/PE.iso (255) 假定是 kuer 大师的 PE，别人的 Win11PE 应该也一样。
map --hook
chainloader (255)
boot

进入桌面后，找到硬盘上的 RW 工具，运行它即可！

检查的结果，应该跟我的一样：没有污染！

怎么知道它没污染呢？

int13 handler 的头部正常，尾部该有的 00 都保持 00， 该有的字符串，都保持原样。因此，很容易判定：无污染。

yaya 可以试试。这个 RW 是 wintoflash 在前面曾经提供的工具，真好用！

不点

无污染！那可是个大麻烦！

我们得重新下结论！

前面的结论可能都不可靠了！