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

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以后还是什么时候？

sunsea

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

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

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

sunsea

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

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

sunsea

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

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

sunsea

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

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

sunsea

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

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

sunsea

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

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

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

sunsea

2011yaya2007777 发表于 2021-12-3 14:21
sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。

粗看了下，代码除了没加分号之类的问题以外没大问题，感谢！

编译和调试我在搞，尼玛狗屎烂蛋的M$ Win10不准装Win7的DDK，W10的ddk似乎没法给低版本编译，我想想办法（哪位会VS2019+W10的DDK编译给为xp的驱动的我在此也请教下，毕竟VS2019也能算宇宙最强IDE了，我还希望能再VS里搞定联机调试呢），另外最近比较忙，可能要等一会了。

sunsea

wintoflash 发表于 2021-12-4 21:08
https://blog.csdn.net/sanqiuai/article/details/119413564
我没弄过，不知道行不行。

似乎能用，不过莫名其妙编译出来的启动不了……我去坛子上找个极限精简版Win10装个调试机吧，尼玛XP还不给用来做调试端……M$真的绝了。我以前调试这玩意一直用XP，Win10体积太大了

sunsea

2011yaya2007777 发表于 2021-12-3 14:21
sunsea : svbus 的补丁我已经打上了，你再看看有什么问题。下一步编译就看你了。

喵的，上调试器整死机了，正常启动没认盘，我就用最土最笨的办法好了：插调试信息。不过这就比较费事了，最近比较忙，等段时间吧。

sunsea

2011yaya2007777 发表于 2021-12-5 19:48
现在的调试环境和以前不一样了吗？还挺费事的。

不清楚M$在搞什么。我这下断点后跑起来直接死机了。也可能是我操作问题。

sunsea

2011yaya2007777 发表于 2021-12-6 08:28
这个 svbus 编译出 svbusx64.sys 和 svbusx86.sys。
关于变量长度有个疑问：
ULONGLONG 在 32/64 位环境 ...

ULONG固定32位，ULONGLONG固定64位，int长度会变。需要32位整数可以固定使用ULONG。

sunsea

2011yaya2007777 发表于 2021-12-6 10:49
明白了。结构定义没有错误。

搜了下，int长度是确定的，32位。M$下long的长度也是32位，但是GCC下（包括给uefi编译的时候）就说不准，可能跟的是Linux的规定（见图），不知道g4d按什么编译的。可能要上stdint.h固定长度。

sunsea

2011yaya2007777 发表于 2021-12-6 10:49
明白了。结构定义没有错误。

初步调试笔记：

↑这个用途不明，但是会让调试的时候出现问题直接跑飞，下一步应该注释掉



此处对碎片的判断似乎出现了问题，没有抓到碎片。下次调试时应该抓常规内存进来确定碎片表在哪，确定是否是对地址的运算有问题。

（最近较忙，估计过段时间才能继续搞了，不过肯定会搞完，以及是否应该单开一个主题？）

sunsea

2011yaya2007777 发表于 2021-12-22 16:42
同意另开一贴。第一幅画，好像是原程序的内容吧，似乎应该把"!"去掉。有关第二幅图，应当使用最新版本的g4e ...

这样的话碎片处理补丁对于 grub4dos-for_UEFI-2021-12-15 在Win10 x64上测试通过了。不过从刚刚第二幅图来看，g4d和g4e碎片表放置位置有差异？（测试楼上第二幅图的环境是grub4dos-0.4.6a-2021-11-19）

这几天的话我把整理过的源代码发出并编译（然后另开一主题帖），然后大家一起在各种环境上广泛测试，争取经受最广泛地考验、不出bug。