|
本帖最后由 sunsea 于 2021-11-26 16:18 编辑
目前的结果是,似乎是污染了,但没完全污染。
报告上载到附件了。
采用的测试代码如下,保存为C盘下的dump.cmd:
- !BAT
- debug 2
- insmod /fat
- map (hd0,4)/PE20H1.iso (0xff)
- map --hook
- read 0x413 #取2位数,比如 0x270
- #calc 0x270*0x400 #0x9c00
- set /a x=*0x413 & 0xffff
- set /a x=%x% * 0x400
- echo %x%
- read %x%
- set /a y=*%x% & 0xffff
- set /a y=%y% * 0x400
- echo %y%
- map --rd-base=0
- map --rd-size=0x100000000
- if exist (hd0,4)/g4dmemst.bin fat del (hd0,4)/g4dmemst.bin
- fat mkfile size=%y% (hd0,4)/g4dmemst.bin
- 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,启动方式为上述批处理后接如下代码:
- chainloader (hd0,0)/ntldr
- root (hd0,0)
- boot
复制代码
2,某坛友制作的无驱动的WIN10 20H1 PE,启动方式为上述批处理后接如下代码:
- chainloader (0xff)
- root (0xff)
- boot
复制代码
测试方法:
1,g4d下执行脚本进行转录(结果为g4dmemst.bin)
2,进入系统桌面后立刻运行转储程序转储对应物理内存。(M0009D000.bin)
比较报告在附件,总结一下是确实有部分字节发生了变化,而且20H1变化的比XP的多。而且经过3次测试,变化较为稳定。
还需要更多环境进行测试,最好有e820cycles=0才能运行的buggy机器进行测试。不过似乎确实会造成污染。
有时间进行补充测试:抓前1MB进行比较。
提问:g4d下抓前1MB的合适时机是什么?是chainloader /ntldr以后还是什么时候?
|
-
-
报告.zip
21.82 KB, 下载次数: 4, 下载积分: 无忧币 -2
|