无忧启动论坛

标题: 非--mem形式 map iso镜像后读取文件失败的问题 [打印本页]

作者: mahuniu 时间: 2012-2-20 22:14
标题: 非--mem形式 map iso镜像后读取文件失败的问题
我自己修改的PE的iso，大小是55M，通过grub4dos加载，用map --mem则一切正常，但是不加mem就不能加载外置，不过古怪的是，在iso里面随便加些东西，该iso文件到了一定体积，又会正常。
这是配置内容：
title MYPE.iso(map)
map --mem /boot/winvblock.img.gz (fd1)
map --mem (md)0x6000+800 (fd0)
find --set-root /boot/MYPE.iso
map /boot/MYPE.iso (0xff)
map --hook
dd if=(fd1) of=(fd0) count=1
chainloader (0xff)

title MYPE1.iso(map)
map --mem /boot/winvblock.img.gz (fd1)
map --mem (md)0x6000+800 (fd0)
find --set-root /boot/MYPE1.iso
map /boot/MYPE1.iso (0xff)
map --hook
dd if=(fd1) of=(fd0) count=1
chainloader (0xff)

MYPE.iso和MYPE1.iso内容是一样的，就是容量不一样，后者随便加了个与PE没有任何关系的二十多m的文件，前者模拟出来的光驱，不是不能读ini文件就是不能读外置的wim，后者就正常加载了。如果用map --mem则是正常的。
为什么会加文件呢，那是因为我起先觉得是自己没把pe修改好，一直折腾，到最后觉得和修改前的原版pe只剩容良不一样了。

[ 本帖最后由 sratlf 于 2012-2-22 10:01 编辑 ]

作者: pseudo 时间: 2012-2-20 23:36
呵呵，不怪。
是不是iso大于64mb才行？

某个旧版grldr估计无此问题。

楼主最好提供一个能在虚拟机重现的测试例。或者定位grldr从何时起出问题，我想大约是在冬季。

[ 本帖最后由 pseudo 于 2012-2-20 23:40 编辑 ]

作者: 不点 时间: 2012-2-21 00:52
感觉 grub4dos 不太可能出现此类问题。只要你在 grub4dos 之下能够访问虚拟的光盘 (0xff) 中的所有扇区，那 grub4dos 的任务就圆满完成了。这很容易验证: 只需把 (0xff) 的最后一个扇区 cat 出来:

cat --hex (0xff)xxxxx+1

如果内容正确，就表示没问题。注意，光盘的扇区大小是 2048 字节，不要把扇区号弄错。如果按 512 字节的小扇区，计算得到的最后一个扇区号肯定比较大。而应该按照 2048 字节的大扇区计算，最后一个扇区的扇区号应该比较小。

从描述的故障现象来看，好像是 winvblock 的某个限制造成的，请进一步确认。

作者: mahuniu 时间: 2012-2-21 01:01
用firadisk效果更差，有时候在pe里看不到它模拟出来的光驱，而winvblock 怎么也看到光驱吧，不过如果加上mem，都正常的。反正加载pe内核后，访问模拟光驱上的文件是不正常的，如果用mem挂iso到内存，会有两个模拟光驱，而且好象都能正常读取

[ 本帖最后由 mahuniu 于 2012-2-21 01:10 编辑 ]

作者: mahuniu 时间: 2012-2-21 09:57
这个事情太诡异了，今天早上把那PE 的img重新做了一下并打包，竟然正常了，那iso 文件大小没有变化一个字节，邪了。
不知道什么原因，把我那个在3台电脑上不能map而只能map --mem的iso 文件上传了，如果有兴趣自己去测试一下：
http://115.com/file/c2ref4li#

作者: zhaohj 时间: 2012-2-21 10:03
“在3台电脑上不能map而只能map --mem”，想问一下，你的菜单是怎么写的？
在保证ISO文件连续存放的前提下，那就是菜单的写法有问题了。

作者: mahuniu 时间: 2012-2-21 10:08
文件是连续存放的，不然不可能加载iso吧（加载前有错误提示），菜单文件内容，顶楼已经写了呀，至于格式，ansi和其他的，好象也一样结果

作者: sratlf 时间: 2012-2-21 10:21
标题: 回复 #7 mahuniu 的帖子
有一点是错误的对winvblock驱动可以这么写进入pe后也能挂载上

对firadisk驱动还需要写入配置信息只有这几行代码进入pe后是没办法挂载的

作者: mahuniu 时间: 2012-2-21 10:40
我刚刚在Virtual PC试了，也是一样的结果，反正我这个55m的iso就是不能被map，但是map --mem或者在iso随便加二、三十m的文件进去，却又正常。55m的东西，下载也快的，如果有测试出原因的，希望能告诉我具体原因，因为这个实在太邪门了

作者: zhaohj 时间: 2012-2-21 10:52
我测试了一下很正常，你的问题属于对firadisk驱动不真正了解所致。
不多讲了，写出菜单：
title Boot MYPE.ISO With map (no mem)
map --mem /boot/FIRADISK.IMG (fd1)
map --mem (md)0x200+800 (fd0)
map --hook
dd if=(fd1) of=(fd0) count=1
set iso=/MYPE.ISO
find --set-root %iso%
map %iso% (0xff)
map --mem (md)0x200+4 (99)
map --hook
echo [FiraDisk] > (99)+1
echo StartOptions=cdrom,vmem=find:%iso%; >> (99)+1
chainloader (0xff)

Snap1.jpg (52.68 KB, 下载次数: 137)

作者: mahuniu 时间: 2012-2-21 11:04
楼上老兄，你这个是不正常的，没加载外挂。你把光驱里的文件复制一下试试

作者: zhaohj 时间: 2012-2-21 12:50
测试了一下，确实有点奇怪，往MYPE.ISO中复制一些文件后，加载了外挂。

作者: zhaohj 时间: 2012-2-21 13:11
下面是5#的mype.iso两种方式加载的情况，不点大与C大看一下，这个ISO已连续存放，为何总扇区数不一样？
(0xff)是map方式的，(hd32)是map --mem加载的。
map --mem按照8的倍数，很正常！
map不是8的倍数，难道问题在这里？

[ 本帖最后由 zhaohj 于 2012-2-21 13:17 编辑 ]

Snap1.jpg (65.1 KB, 下载次数: 119)

作者: zhaohj 时间: 2012-2-21 14:40
文件大小=0x3706800，按每扇区512字节计算=0x1b834扇区数；按每扇区2048字节=0x6e0d扇区数
cat --hex (0xff)0x6e0c+1
显示结果正常。

作者: pseudo 时间: 2012-2-21 15:07
楼主的iso是用ultraiso弄过的吧。

我曾经遇到过用ultraiso更换chenall的dpms.iso里的dpms.bat后，出现

直接map成功，但不能找到dpms.bat的现象。

所以在0pe里有这段代码：
map %~1DPMS.ISO (0xdf) && map --hook ! echo
if not exist (0xdf)/DPMS.BAT && map --unmap=0xdf && map --rehook && map --mem %~1DPMS.ISO (0xdf) && map --hook ! echo

就是说，直接map成功并不能保证iso内文件可读。

所以0pe还是用基于mkisofs的批处理生成iso靠得住。只是dpms.iso是chenall提供的，怕批处理重新生成走样，我才用ultraiso处理一下。

作者: Plantsoot 时间: 2012-2-21 15:19

原帖由 zhaohj 于 2012-2-21 14:40 发表
文件大小=0x3706800，按每扇区512字节计算=0x1b834扇区数；按每扇区2048字节=0x6e0d扇区数
cat --hex (0xff)0x6e0c+1
显示结果正常。

我这测试的结果和你的一样。
有点奇怪了，不加--mem的cat --hex (0xff)0x6e0c+1是正确的。
加了--mem的，cat最后一个扇区应该是cat --hex (0xff)0x6e0d+1，反而不正常了。

不正常的启动后反而可以加载外置?

作者: Plantsoot 时间: 2012-2-21 15:41
回复 #15 pseudo 的帖子

特意拿一个体积大小和楼主差不多的mkisofs制作的ISO再测试一下。
得到下面的结果，两种方式得到的文件大小一样了。

fbinst-2012-02-21-15-39-02.png (8.57 KB, 下载次数: 113)

作者: zhaohj 时间: 2012-2-21 15:43
加了--mem的，cat最后一个扇区应该是cat --hex (0xff)0x6e0d+1，我这里正常！

作者: mahuniu 时间: 2012-2-21 15:56
早上把那内核的img文件重新做，打包后用ultraiso修改那iso文件后，却是正常map了，所以应该不是和容量有关，但怪异的是它加进去二十多m文件进去之后却是变正常map 了，按理说，如果iso有问题，那加文件也不会改变什么呀

作者: Plantsoot 时间: 2012-2-21 16:06

原帖由 zhaohj 于 2012-2-21 15:43 发表
加了--mem的，cat最后一个扇区应该是cat --hex (0xff)0x6e0d+1，我这里正常！

看看我这个是怎么回事，我这cat --hex (0xff)0x6e0d+1得到的全是00，实际最后1个扇区不全是00。

fbinst-2012-02-21-16-04-37.png (8.58 KB, 下载次数: 109)

作者: 不点 时间: 2012-2-21 18:43
我来试着分析一下。

zhaohj 说：

文件大小=0x3706800，按每扇区512字节计算=0x1b834扇区数；按每扇区2048字节=0x6e0d扇区数
cat --hex (0xff)0x6e0c+1
显示结果正常。

文件大小不是 4K 的整数倍。注意，4K = 0x1000。因此，拷贝到内存之后，可能向上浮动，补全到 4K 对齐。因此，在内存中，大小按 0x1b838 个 512 小扇区计算，即 0x3707000 字节。

实际上最后多出了 4 个 512 字节小扇区，也就等于多出一个 2048 字节的大扇区。多出的这个扇区，当然是无效的扇区，即，不使用的扇区。它的内容全是 00 ，那是正常的，没问题。

以上各位的测试，没有发现 grub4dos 有任何错误（或者说没有发现 bug）。

那么，错误就在别的软件上了。例如，winvblock 有 bug。

猜测，当 ISO 处于硬盘不同位置时，winvblock 或者 firadisk 有 bug，导致不能正确访问 ISO 里的文件。bug 很可能随着起始扇区的数值的不同而有不同的表现。比如说，如果在硬盘上 ISO 的起始扇区号是 4 的整数倍，也就是 2048 字节对齐，则计算大扇区很容易。如果 ISO 在硬盘上的起始扇区号不是 4 的整数倍，那么软件在访问大扇区的时候，以某种方式发生了错误，即 bug。这只是一种猜测，究竟什么地方搞错了，那很难说。但我们总归可以确定，那是 winvblock 这类驱动程序的 bug。这种 bug 究竟是怎么表现的，具体的技术原因是什么，现在并不十分清楚。但 bug 属于它，却是比较清楚的，因为 grub4dos 没有问题，已经证明过了。如果从 grub4dos 内部访问 ISO 中的任何文件，都没问题，那就证明了 grub4dos 没问题。而且这是严格的证明。既然是证明，那就可以排除 grub4dos 的问题了。那么，就一定是别的问题了，例如 Windows 本身的 API 的问题，或者是 winvblock 的驱动程序的问题。如果我们相信 Windows API 不会有问题，那么就可以确定是 winvblock 的问题了。

[ 本帖最后由不点于 2012-2-21 18:49 编辑 ]

作者: Plantsoot 时间: 2012-2-21 20:33

原帖由不点于 2012-2-21 18:43 发表
如果在硬盘上 ISO 的起始扇区号是 4 的整数倍，也就是 2048 字节对齐，则计算大扇区很容易。如果 ISO 在硬盘上的起始扇区号不是 4 的整数倍，那么软件在访问大扇区的时候，以某种方式发生了错误，即 bug。...

不点这个解释很好，明天我做个这样的测试，用ud比较容易控制ISO的起始位置，之前我也遇到0PE.ISO无法正常启动的问题，再拖入一个0PE.ISO后，后拖入的文件可以正常启动。

当时我们以为可能是我的U盘有问题了，刚好第一个ISO占用了坏的部分，但是奇怪的是，我把第一个ISO导出来，和第二个ISO对比，md5是完全一致的。当时没引起重视，也许，和这个是同一个问题，我明天上午做个测试。

作者: 不点 时间: 2012-2-21 20:48
别忘了，winvblock 是开源的，原则上讲，你甚至可以把代码中的 bug 找出来。

作者: chiannet 时间: 2012-2-21 22:13
看了楼上各位老大的实验及不点老师的分析，总算大体知道了此类问题产生的原委了。这个是真实存在的问题。我补充两例：

在native Pe启动时，即便二级内核所在ISO的确已经确保无碎片且保存在UD扩展数据区内，在我们map它启动，仍有一定的概率发生native shell找不到二级内核的时候。一直找不到原因，便武断地认为是足迹老大native shell不完善，可笑！

也碰到过楼主在一楼阐述的问题，ISO被map 了，同样是winvblock 驱动，在PE资源浏览器里能看到仿真光驱内的文件及目录，但就是不能访问它们，当时也不知原委，便随意添加一个空的WIM文件后，其他的那些原本不能正确挂载的WIM便挂载成功了，对此百思不得其解，误认为是wim驱动程序的问题。

按照不点老师的阐述，此两类现象都是同一个问题所致。

[ 本帖最后由 chiannet 于 2012-2-21 22:17 编辑 ]

作者: Plantsoot 时间: 2012-2-21 22:21
标题: 回复 #24 chiannet 的帖子
嗯，呵呵，看来我们都遇到了同样的问题，只不过没引起重视，也没去追究真正的原因，用其他的方法“解决”了就没再去找原因了。

作者: pseudo 时间: 2012-2-21 22:46
我说的与winvblk关系不大。
grldr成功直接map了iso镜像，但无法找到其上文件。
是g4d找不到。

问题可能跟ultraiso有关，所以也不好说是g4d的bug。

chiannet 的iso可能也是ultraiso弄的吧。

作者: Plantsoot 时间: 2012-2-21 22:51
标题: 回复 #26 pseudo 的帖子
P大还记得我的U盘吗？我拖入grldr + 0PE.ISO，会卡住加载WIM的阶段，然后我再拖入一个同样的ISO，后者可以顺利启动。

当时我们考虑是U盘的寿命问题，但是我导出第一个ISO，md5和第二个是一样的。

还记得是哪个版本的0PE吗？反正是1.4的，我想再现一次这个问题，可惜我忘记是哪个版本了，U盘已经格式化了。

作者: 不点 时间: 2012-2-22 06:47
@pseudo

如果你能确认是 grub4dos 找不到 iso 里面的文件，那么确实如你所说，可能是 grub4dos 的 bug。这很容易证明，以上几位为何不证明一下呢？

当然，也可能是 ultraiso 的 bug。这是有可能的，我记得 ultraiso 曾经有过别的 bug，它并未锤炼得很完善。

总之，究竟是谁的 bug，这太容易确定了。如果是 ultraiso 的 bug，那么，它制作的 iso 刻录到 cdrom 上，也无法被 windows、dos、linux 识别。或者挂在 qemu 之类的虚拟机上，无法被 windows、dos、linux 识别。

作者: 幸运的草 时间: 2012-2-22 08:43
回复楼上各位：
　　这个问题，确实是软碟通的问题。很久前我们在调试NATIVE版的PE时，就发现了这个问题。一个ISO，无引导记录，只是一个或两个WIM文件，你如果用软碟通修改ISO中WIM文件，哪怕是覆盖导入，这个被修改的文件的LBA值就是最大的。这个最大LBA值的WIM文件挂载时就出错。刚开始WIM文件挂载出错，误以为是方件不连续造成的，后来发现是这样，于是就向里面添加一个无关的小文件，使这个文件的LBA值最大。这时挂载WIM文件就正常了。
　　一句话，只要用软碟通修改的文件，其LBA值是最大的。在G4D中仿真，读取这个文件就失败。　
　或者也是G4D的问题。至少是这两个共同作用的结果。

[ 本帖最后由幸运的草于 2012-2-22 08:57 编辑 ]

作者: 幸运的草 时间: 2012-2-22 08:47
补充：实际这个文件没有损坏，你导出后，与原文件无异，就是map后G4D不能正确读取。

作者: Plantsoot 时间: 2012-2-22 08:55
标题: 回复 #30 幸运的草的帖子
我那个问题很奇怪，不知道你还记得不记得我和P大当时找原因的情况。

昨天晚上和今天早上我反复测试，同样的ISO，上次宣布已经损坏的U盘，竟然又“活”了。
无法再现找不到PE.WIM的情况，太奇怪了。

作者: 不点 时间: 2012-2-22 09:07
@幸运的草

说的很含糊，没明白。什么叫做 “LBA 值是最大的”，能不能说的精确一些？文件本身没有 LBA 概念，文件可能占用很多扇区，每个扇区都有一个 LBA。所以，文件不只有一个 LBA。你说文件的 LBA 值最大，这就不能让人明白了。另外，什么叫 “ 最大 ”？这个也含糊。是最大的整数 0xFFFFFFFF 呢？还是最大达到整个 iso 的尾部？

map 有 “ 带 --mem ” 和 “ 不带 --mem ” 之分。如果带上 --mem 正常了，从 grub4dos 内部可以访问 iso 里的文件了，这说明，文件格式确实没问题。而如果此时不带 --mem 就无法用 grub4dos 来访问 iso 里面的文件，那就属于 grub4dos 的 bug。当然，需要事先排除 USB 出现故障的可能性。我们知道，USB 的 BIOS 有很多毛病。应该用普通的硬盘来试验。既然是格式问题，那与介质无关，普通的硬盘照样可以重现问题。所以应该用硬盘来试验，这样比较可靠。其实硬盘也不保证 100% 可靠。因为 BIOS 有 137G 极限，如果 iso 的位置处于超过 137G 的界限之外，那么即使在硬盘上，也照样会有问题。

希望各位逐一澄清这些问题。

[ 本帖最后由不点于 2012-2-22 09:08 编辑 ]

作者: zhaohj 时间: 2012-2-22 09:11
我们不要忘这一点：map --mem 这个ISO文件是正常的。
这就排除了ISO文件有bug的情况。也验证了firadisk或winvblk在map --mem情况下是正常的。

现在范围缩小了，map非mem下firadisk或winvblk有bug

作者: 不点 时间: 2012-2-22 09:14
标题: 回复 #31 Plantsoot 的帖子
我终于有点明白了，你们都是在 U 盘上做。

USB BIOS 出现各类故障，太常见了。如果 iso 碰巧处于 BIOS 能够访问到的区域，那么访问你 iso 里面的文件不成问题。如果 iso 碰巧跨越极限，则有一部分 iso 的扇区是可以访问的（即处于极限之内的部分），另一部分 iso 的扇区是无法访问的（即处于极限之外的部分）。

题外话：

各位尽量都把错别字改正一下，毕竟这里有外国人通过 google 翻译来阅读帖子。

楼主或者版主最好把整个线索的标题改一下。“一个非常古怪的问题”不是一个好的标题，不利于大家将来搜索这个帖子。

[ 本帖最后由不点于 2012-2-22 09:25 编辑 ]

作者: Plantsoot 时间: 2012-2-22 09:17
标题: 回复 #34 不点的帖子
我更糊涂了，因为同样的文件，同样的U盘，上次我直接拖入grldr和0PE.ISO到ud，启动过程中有无法找到PE.WIM的提示。
然后再拖入一个0PE.ISO到ud，原来的改名，就可以正常启动到PE桌面。

今天为了再现这个问题，我再次这样测试，发现两个ISO都可以正常启动，让我很不解。
难道真是BIOS的问题？上次是实机，这次是虚拟机。

我马上测试真机。

作者: 不点 时间: 2012-2-22 09:28
标题: 回复 #35 Plantsoot 的帖子
你好糊涂啊！抱歉，这不是责怪你的意思。

虚拟机的 BIOS 怎能等价于真实机的 BIOS？

作者: 幸运的草 时间: 2012-2-22 10:34
回复 #32 不点的帖子

这里所说的LBA值最大，是指在ISO中所有文件中是最大的。也就是最靠后的文件。是指修改后，而非指原创文件。原创文件没有这个问题。一修改就出现了这个问题。
　LBA值，在ISO中，好像是一个文件一个值。

注：原来测试的是hotdll发布的tangope两个版本，一个是CAB版，一个是WIM版，都出现这个问题。而没有加载FIRADISK之类驱动。只是解压后的文件不全，WIM文件挂载失败。都是在UD区，通过GRLDR引导仿真ISO。VM及实机均测试如此。

作者: 不点 时间: 2012-2-22 10:40
标题: 回复 #37 幸运的草的帖子
你的意思是说，用某软件修改 ISO 之后，不行了。

怀疑这个软件有 bug。

另外，你没有确认，带 --mem 是否也是失败的。如果带 --mem 失败，那就是 iso 格式被破坏所导致的了。也或者是 grub4dos 的 bug：它不能认识修改后的正确的格式，但这种可能性很小。而软件修改 iso 造成错误，这种可能性较大。

这里说的问题，与楼主所遇到的问题，可能属于两个不同的问题，不是同一个问题。

作者: 幸运的草 时间: 2012-2-22 10:45
同一个文件，导出再导入，LBA值就大了很多。

作者: 幸运的草 时间: 2012-2-22 10:47
标题: 回复 #38 不点的帖子
带--mem是可以的。我下载测试一下，楼主的情况。

[ 本帖最后由幸运的草于 2012-2-22 10:49 编辑 ]

作者: mahuniu 时间: 2012-2-22 11:44
这个iso文件，加进去几十k的东西，或许就能map了，而缩小体积，却还是不行，例如缩小2m，它还是不能被map，但是缩小保存后再加几十k，可能就可以map了

作者: 幸运的草 时间: 2012-2-22 11:56
楼主的ISO，用VM挂载ISO，测试可以加载驱动。用U盘测试，在VM上也能加载外置。

但实机不行。

经查看楼主的ISO，发现他加载外置工具的BASIC.WIM的LBA值是ISO文件中最大的。也就是说楼主用软碟通修改过这个文件。
　　这个问题实际和我说的是同一样问题。你可以向里面添加一个几十KB的无关的小文件，使这个小文件的LBA值大于BASIC.WIM。不用加载FIRADISK之类的驱动。完全可以加载外置工具。
　　在实机上测试通过。
　　map /mype.iso (0xff)
map --hook
chainloader (0xff)
boot
全测试没有加载这类驱动，因此完全排除是这类驱动的BUG。

　　至此，还是我的结论：是软碟通与G4D共同作用的结果，导致的问题出现。
　　

作者: Plantsoot 时间: 2012-2-22 12:01
我上次遇到的情况无法再现，先不管了。今天我做了另外一个测试。

1、win7系统、2G的U盘（fb盘，ud区的数据全部填00后再导入文件。
2、vmware7.1虚拟机，因为我实机测试了一下，效果和虚拟机一样。
3、grldr、0PE.ISO原版、0PE.ISO修改版（用ultraiso修改，把PE.WIM删除后保存，再加入PE.WIM）
4、全部测试均按map不加--mem和加--mem参数两种方式进行。
5、测试0PE.ISO修改版的时候，分几次手工修改ud文件列表中该文件的大小后进行测试。

不知道这次的测试有没点意义。

文件大小	map	map后占扇区数（512）	map后占扇区数（2048）	map后占扇区数（4096）	启动	备注
122748928		239744	59936	29968	成功	mkisofs
122748928	--mem	239744	59936	29968	成功	mkisofs
122677248		239604	59901	29950.5	失败	用ultraiso修改，把PE.WIM删除后保存，再加入PE.WIM
122677248	--mem	239608	59902	29951	失败
122679296		239608	59902	29951	成功
122679296	--mem	239608	59902	29951	失败
122681344		239612	59903	29951.5	成功
122681344	--mem	239616	59904	29952	成功
122682368		239614	59903.5	29951.75	成功
122682368	--mem	239616	59904	29952	成功
122683904		239617	59904.25	29952.125	成功
122683904	--mem	239624	59906	29953	成功
122685952		239621	59905.25	29952.625	成功
122685952	--mem	239624	59906	29953	成功
122748928		239744	59936	29968	成功
122748928	--mem	239744	59936	29968	成功

我拿楼主的有问题的MYPE.ISO做了个简单的测试。

按zhaohj说加一个4K大小的文件也行，那我就强行手工在ud内修改MYPE.ISO的大小，
增加4K大的空间，结果真的可以了。

结合我上面的测试，是不是说不管有没有用软碟通修改过，
只要map的时候，强行增大镜像体积4K以上，就可以正常启动？

MYPE.ISO文件大小	map	map后占扇区数（512）	map后占扇区数（2048）	map后占扇区数（4096）	加载外置
57698304	不加--mem	112692	28173	14086.5	失败
57702400	不加--mem	112700	28175	14087.5	成功

[ 本帖最后由 Plantsoot 于 2012-2-22 13:19 编辑 ]

作者: 幸运的草 时间: 2012-2-22 12:37
标题: 回复 #43 Plantsoot 的帖子
我测试：
　相同的文件，用软碟通导出再导入，就导致其LBA值在ISO所有文件中最大化。即表现最直接的就是WIM文件挂载失败，CAB文件不能完全解圧或失败。
0PE.WIM，中还有好几个WIM文件，这就是为什么不能用软碟通修改的原因。其实要破解也简单，向里面添加一个无用的小文件，使这个文件的LBA值在ISO中是最大的。就可以了。

还有一个办法也可，先用软碟通打开ISO，把引导记录保存为一个BIF文件，把ISO的文件及文件夹导出到硬盘；然后再重建一个新的ISO，不需要任何设置，采用默认的就行。要先添加所有的WIM文件，再添加其他的文件及文件夹。最后加载引导记录，保存。一切OK。

目前的问题，在WIM文件表现较为突出，楼主出现的问题，就是WIM文件挂载失败引起的。

[ 本帖最后由幸运的草于 2012-2-22 12:40 编辑 ]

作者: zhaohj 时间: 2012-2-22 12:37
通过多次测试，发现这样一个规律（map非mem)：
1：当文件大小是4k的整数倍时，肯定成功;
2：当文件大小不是4k的整数倍时，往ISO中加入大于等于4KB的一个文件，肯定成功。

作者: Plantsoot 时间: 2012-2-22 12:47
标题: 回复 #45 zhaohj 的帖子
看看我上面的测试，是不是有点意思，我现在拿楼主的MYPE.ISO测试下。

一会给结果。

作者: Plantsoot 时间: 2012-2-22 13:04
我拿楼主的有问题的MYPE.ISO做了个简单的测试。

按zhaohj说加一个4K大小的文件也行，那我就强行手工在ud内修改MYPE.ISO的大小，
增加4K大的空间，结果真的可以了。

结合我上面的测试，是不是说不管有没有用软碟通修改过，
只要map的时候，强行增大镜像体积4K以上，就可以正常启动？
或者换个方式，软碟通修改后的ISO用winhex再尾部补上8个512扇区的00是不是也可以解决？

title MYPE.ISO
map --mem (ud)/WINVBLK.IMG (fd1)
map --mem (md)0x6000+800 (fd0)
map (ud)/MYPE.ISO (0xff)
map --hook
dd if=(fd1) of=(fd0) count=1
chainloader (0xff)

MYPE.ISO文件大小	map	map后占扇区数（512）	map后占扇区数（2048）	map后占扇区数（4096）	加载外置
57698304	不加--mem	112692	28173	14086.5	失败
57702400	不加--mem	112700	28175	14087.5	成功

[ 本帖最后由 Plantsoot 于 2012-2-22 13:14 编辑 ]

作者: 幸运的草 时间: 2012-2-22 13:12
标题: 回复 #47 Plantsoot 的帖子
不是这样的，如果没有用软碟通修改过，不存在这个问题。也就是你用软碟通重新制作一个ISO，先添加WIM文件，后添加其他文件，再导入原ISO的引导记录。可在就不存在这个问题。
　　出现这个问题必须是用软碟通修改过且被修改的文件的LBA值最大。才导致这个问题。

　　楼主的ISO，本身就是用软碟通修改过，而且basic.wim文件的LBA值最大。
　
　　当然解决办法就是使原ISO文件增大4K体积。（不修改用软碟通新制作的不需增大4K）。

作者: Plantsoot 时间: 2012-2-22 13:16
标题: 回复 #48 幸运的草的帖子
我明白你的意思，我是说不管ISO有没用软碟通修改过，
只要map的时候都把ISO的体积扩大4K，是不能就代表着ISO都可以兼容了，
管他有没用软碟通修改过，或者采取我上面说的另外一个方法，
用软碟通修改的时候末尾加上4K的00.

作者: 幸运的草 时间: 2012-2-22 13:41
标题: 回复 #49 Plantsoot 的帖子
初步断定是软碟通的BUG。因为即使文件导出再导入，原文件的LBA值就发生了变化。按道理不应该。

　应该说加4K，只是解决办法的一种，其实，不加4K也可以。

大家可以做个测试：修改后只要保证WIM文件的LBA值不是最大，即可解决这个问题。
方法就是：修改保存前，把ISO的引导文件。即.BIN或COM。导出再导入，保存即可。该方法不增加ISO文件的体积。
　　这些文件是ISO的引导，不依靠G4D运行，所以说可“动”。
　　该方法实机测试通过。只是多了一个冗余的操作。

[ 本帖最后由幸运的草于 2012-2-22 14:10 编辑 ]

作者: 幸运的草 时间: 2012-2-22 14:08
　这个问题，估计是和FBINS出现的问题一样。也就是计算文件连续空间文件有误。其根据就是同一文件导出再导入，lba值就变化，且是所有文件最大的。也就是没有在同一个空间存放，实际放在了最后部分。这一点和原来的FBINST是一样的。
　但为什么最后的WIM会挂载失败。这个问题有能力且有兴趣的可以探讨一下。

　或者，G4D可以改进一下，在map时，人为把ISO的体积增大4K空间。这个问题就可以永久的解决了。

[ 本帖最后由幸运的草于 2012-2-22 14:13 编辑 ]

作者: zhaohj 时间: 2012-2-22 14:39
是这样的，ULTRAISO修改过的最后放进去的文件,map后都会被windows api 丢弃。
可以这样做试验：在mype.iso中先导出minipe\winpe.ini，导出后删除minipe\winpe.ini，保存ISO；再把winpe.ini拖进原位置，保存ISO。
你会发现出现蓝屏。
这个试验证明lba最大的文件，无法被windows api 识别。
而grub4dos实模式下我查看是正常的。下面的图是按上面方法修改的最后导进去的bliss.jpg文件，LBA最大。

Snap1.jpg (102.6 KB, 下载次数: 132)

作者: Plantsoot 时间: 2012-2-22 14:45
标题: 回复 #52 zhaohj 的帖子
为什么人为在文件尾部增加4k的空间后，又不抛弃了？

作者: zhaohj 时间: 2012-2-22 14:56

原帖由 Plantsoot 于 2012-2-22 14:45 发表
为什么人为在文件尾部增加4k的空间后，又不抛弃了？

感觉是windows api丢弃了4k余数部分，人为在ISO文件尾部增加4k后，所有的文件都不在这4k中，即所有文件完整的。
map --mem为何成功，因为map --mem是4k的整数倍。

作者: Plantsoot 时间: 2012-2-22 15:03
标题: 回复 #54 zhaohj 的帖子
map --mem 不一定成功，你看我做的测试。

文件大小

map

map后占扇区数（512）

map后占扇区数（2048）

map后占扇区数（4096）

启动

122679296		239608	59902	29951	成功
122679296	--mem	239608	59902	29951	失败

不加 --mem成功，加了失败，让我十分不理解！

作者: zhaohj 时间: 2012-2-22 15:11
奇怪，上面的正好是4k的整数倍，难道map --mem后丢弃了4k?
能否测试一下加个4k的文件后，map --mem能否成功？

作者: Plantsoot 时间: 2012-2-22 15:23
标题: 回复 #56 zhaohj 的帖子
全部的测试：
http://bbs.wuyou.net/forum.php?m ... p;page=5#pid2388985

结果是，增加大于4K的体积后随便加不加--mem都正常了。

作者: 不点 时间: 2012-2-22 15:36
诸位的探索，让我有这样一种印象：

grub4dos 没有问题。那个修改 ISO 的软件也没有问题。有问题的是 Windows 的 ISO 驱动程序（可能是 winvblock 之类的），它不能处理这种情况。

这还不能证明是 Windows 的 API 出了问题。要证明 Windows API 出问题，必须刻录光盘（或者把 ISO 挂在 qemu 之类的虚拟机的光驱上也是一样的）来验证 Windows 可否读出相关的文件。

当 ISO 文件长度不是 4K 的倍数的时候，可能出现这种问题。到目前为止的讨论表明，这是驱动程序的 bug。我认为 Windows API 很难出现这类问题。因此，我还是觉得这是 winvblock 的 bug。

由于 map --mem 自动把映像文件按 4K 对齐，因此，在带 --mem 的情形，bug 未表现出来。

这下子快要彻底弄清楚了。修改后的文件，可能破坏了原来的 “ 4K 对齐 ” 的文件长度，导致一系列问题的发生。

这 bug 是属于驱动程序的 bug（即，winvblock/firadisk 的 bug）或者 Windows API 的 bug（这个可能性不大），这一点再次得到验证。诱因是当某个软件修改 ISO 之后，没有把 ISO 的长度按照 4K 对齐。因此，这也就有了 workaround：制作 iso 之后，保证 iso 的长度是 4K 的倍数，这个问题也就不复存在了。

作者: 不点 时间: 2012-2-22 16:16
刚才没看到 55 楼以后的讨论。55 楼，确认没弄错吗？你把 ISO 提供给大家，让大家都测试，看看结果是否一样。

只要 grub4dos 在实模式能够访问文件，那就表明 grub4dos 没问题，同时也说明修改 ISO 的工具也没问题。

至于说其他问题，那就只能猜测了。

作者: Plantsoot 时间: 2012-2-22 16:19
以上测试是 fbinst + grldr 测试的。
我现在改用burg来map有问题的ISO，看看。

结果：

1、软碟通修改过的0PE.ISO（122677248字节，不是4K的整数倍），用burg来map，不管是否加--mem、都会有缺文件的提示。

2、人为在0PE.ISO尾部增加数据（00），变为122679296字节，4K的整数倍，
   用burg来map，不管是否加--mem、都会正常启动。
   这个情况用grldr来map，加--mem不正常，不加反而正常，非常蹊跷（特例）。

3、人为在0PE.ISO尾部增加4K的数据（00），变为122681344字节，不是4K的整数倍，
   用burg来map，不管是否加--mem、都会正常启动。
   这个情况用grldr来map，不管是否加--mem、都会正常启动。

如果不考虑那个蹊跷的特例，不知道是不是说明grub4dos应该是没问题的。应该是驱动的问题。

[ 本帖最后由 Plantsoot 于 2012-2-22 16:30 编辑 ]

作者: 不点 时间: 2012-2-22 16:23
55 楼按照 4K 对齐，此时，不带 --mem 成功。已经符合前面的结论了。

至于说带上 --mem 反而失败，这可能是另外一个完全不同性质的问题：有可能是 Windows 在某个阶段破坏了内存。它有可能不遵守 int 15 内存规范，属于 Windows 的 bug，或者某个驱动程序的 bug。内存遭到破坏，那么，内存中的 ISO 就可能正好遭到了破坏。

作者: Plantsoot 时间: 2012-2-22 16:31
回复 #61 不点的帖子

http://115.com/file/belayfll#
map加--mem失败不加成功的ISO.rar

发现只要增加4K以上的体积，不管文件大小是不是4K的倍数，加不加--mem都可以正常启动。

补充一句：启动的时候记得选择XPPE，默认是NTBOOT。
刚才我实机测试问题依旧。

[ 本帖最后由 Plantsoot 于 2012-2-22 16:46 编辑 ]

作者: 不点 时间: 2012-2-22 16:37
好的，不带 --mem 的问题，算是解决了。正如前面所说，把 iso 文件增大到 4K 对齐就 OK。

下面看看能否解决 --mem 失败的问题。这应该是属于不同性质的问题了。或许这里真的能够发现 grub4dos 的仿真代码的 bug。

先由各位下载测试之后再说。

作者: 幸运的草 时间: 2012-2-22 18:47
下载测试了百草的PE，发现这是个0PE。
先说测试结果。实机测试确如百草所说，加--mem中间停止到命令行下，是由于PE.WIM挂载失败引起的。而不加--mem反而没问题。
　查看ISO内部，发现PE.WIM的LBA值最高。
然后用软碟通把引导GRLDR导出，再导入，使这个文件LBA值为最高，这时实机测试，反过来了。--mem测试成功，而非--mem则引导失败。

个人意见。0PE本身有说明，只兼容makiso制作的ISO，不建议用软碟通修改制作。PE.WIM，里面有几个WIM文件。而其他PE的WIM文件只是一个。这是不同之处。
　挂载失败也要在0PE内部查起，由于--mem方式加载后，启动0PE的速度飞快。而以前有反映。0PE为了求快，造成启动失败的情况，所以，会不会是高速启动造成了挂载WIM文件失败呢。
　　因为他要选挂第一层，然后映射后再挂第二层。速度过快，WIM管理程序能否反映过来呢？

作者: 不点 时间: 2012-2-22 19:02
标题: 回复 #64 幸运的草的帖子
好了，我再说说自己的猜测。

百草的 0pe，PE.WIM 的 LBA 值最高，它处于内存的最高处，接近内存顶端的边界。这就使得它更有可能被 Windows 的程序破坏掉。因此，--mem 启动 PE 而失败的可能性增加了。

当在尾部续上一些无用的字节以后，Windows 所破坏的，就是无用的部分了，而不是破坏 PE.WIM 文件。此时就成功启动了。

而你把 GRLDR 弄到最末尾，这使得 PE.WIM 安全了，因此，--mem 成功。

但是不带 --mem 失败了，这可能是因为修改后的 ISO 文件并非 4K 对齐的原因了，前面已经多次提到这个问题。

大家看看这个解释满意不？

作者: Plantsoot 时间: 2012-2-22 19:18
标题: 回复 #65 不点的帖子
这样解释的话应该解释的通了，所以我在尾部增加大于4K的数据后破坏的部分是无用的部分，解释通了。

看来尾部增加一定要大于4K以上才比较保险。不同的ISO是不是都是大于4K以上才保险可能还得测试测试，

如果有时间，明天我整个300M的ISO试试看。

作者: chiannet 时间: 2012-2-22 19:48
标题: 回复 #44 幸运的草的帖子
的确总结的是这么回事！在G4D下使用Ultraiso编辑过的ISO的窍门貌似就是这样的。

[ 本帖最后由 chiannet 于 2012-2-22 19:49 编辑 ]

作者: 幸运的草 时间: 2012-2-22 20:06
标题: 回复 #65 不点的帖子
我要说的就是这样道理。问题基本明了，在G4D外的解决办法，几种方法我前面已经说了。
　　现在需要新版G4D的测试，即MAP　ISO时，把ISO体积空间增大＞4K，这样再进行测试，看是否问题消失。
　如果消失，那就彻底解决了这个问题。

＞＞CHIANNET
　在G4D外的解决办法有三，向ISO里添加无用文件是一种方法。第二种，就是把ISO的引导文件即.BIN或.com文件，导出再导入，即可，因为这两个文件是ISO的引导，不依赖于windows。不会出现上面的问题。
　第三个办法，就是将原ISO的引导记录保存，重新制作新的ISO，再导入原引导记录。制作时最好保证WIM文件最先导入。
　
　

作者: 不点 时间: 2012-2-22 21:24
标题: 回复 #68 幸运的草的帖子
原因找到了以后，你的解决方法似乎还不算合理。

既然尾部容易遭到 Windows 的破坏，那么，这是用户的事情。用户制作 ISO 时，尾部应该增加适量的无用扇区。究竟增加多少，由用户来决定。这个问题不应该由 grub4dos 来解决。只要我们在文档中把这个情况说清楚，用户比我们还要聪明。用户知道应该增加多少。

况且，不同的 Windows 环境，根据所运行的软件的多少以及软件种类的不同，它所破坏掉的内存数目也应该是不同的。我们不可能一劳永逸解决所有的问题。试想？你怎么知道 Windows 破坏多少内存？目前说不定已经破坏了许许多多的内存，只不过有些地方没有影响到启动过程，未被发现而已。那些没有用到的文件，其中很可能也有一些已经被破坏了呢！比如说，零零散散地，有些地方只破坏了几个字节，而有些地方破坏一大块内存。这种情况是有可能发生的。

这个问题既然已经证明不是 grub4dos 的 bug，而且也基本算是找到了原因，甚至也有了 workaround，那么，剩下的工作就没有了，不需要做了。

需要说明的是，在 DOS 和 Linux 的情形，不可能出问题（Linux 是开源的，出了问题容易定位）。因此，也没必要为 Windows 而浪费 grub4dos 的代码，以及浪费内存。

另外，当不带 --mem 时，由于是在磁盘上就地仿真，我们根本无法增加扇区。所以，这必须由用户自己把 ISO 增补到 4K 的整数倍。

作者: xianglang 时间: 2012-2-22 21:40
我说上想当然的想法：或者出现问题，并不是WINDOWS将内存什么的破坏了。

作者: 不点 时间: 2012-2-22 21:51
Windows 究竟破坏内存没有，这一点也是可以精确证明的。

只要在 Windows 下，用 hex 工具软件把虚拟光盘的最后几个扇区显示出来，就知道它是不是被破坏了。

作者: zw2312914 时间: 2012-2-23 01:24
to 不点大人

  if (mem == -1ULL)
  {
query_block_entries = -1; /* query block list only */
blocklist_func (to_drive, flags);
if (errnum)
      return 0;
if (query_block_entries != 1 && mem == -1ULL)
      return ! (errnum = ERR_NON_CONTIGUOUS);

start_sector = map_start_sector; /* in big 2048-byte sectors */

//sector_count = map_num_sectors;
sector_count = (filemax + 0x1ff) >> SECTOR_BITS; /* in small 512-byte sectors */
====================================
if (start_sector == part_start && part_start && sector_count == 1)
      sector_count = part_length;
  }

之后“
bytes_needed = sector_count << SECTOR_BITS;

if (bios_drive_map.to_drive == 0xFF && !(bios_drive_map.to_cylinder & 0x4000))
                  {
                  unsigned long long drvbase, drvend;
                  drvbase = (bios_drive_map.start_sector << SECTOR_BITS);
                  drvend  = (bios_drive_map.sector_count << SECTOR_BITS) + drvbase;
                                 =================================
                  drvend  = ((drvend+4095)&(-4096ULL));/* 4KB alignment, round up */
                              ============================
                  drvbase &= (-4096ULL);       /* 4KB alignment, round down */

sector_count = (filemax + 0x1ff) >> SECTOR_BITS
取整时已经多取了字节。（实际这种取整的方式也不好，filemax 如果很大，+0x1ff会越界）
之后:

(bios_drive_map.sector_count << SECTOR_BITS)
这时计算有差错不？

[ 本帖最后由 zw2312914 于 2012-2-23 03:07 编辑 ]

作者: 不点 时间: 2012-2-23 10:08
标题: 回复 #72 zw2312914 的帖子
filemax 是 long long 的，即 64 位。我们一般的文件都没有这么大，内存也没这么大，因此实际上这么大的文件根本无法装载成功。所以，越界的问题，还不怎么担忧。

sector_count 与 bios_drive_map.sector_count 是两个不同的变量，计算是没有差错的。

第一次是向上按 0x200（扇区边界）对齐，接着第二次又按照 0x1000 （4K边界）对齐。其结果也就相当于一个 4K 的边界对齐罢了。前面的扇区对齐似乎有点多余，但那是没错的。至于说去掉扇区对齐是否可以的问题，那可以进一步研究。如果发现去掉之后完全正确，那样也可以去掉。我现在很懒了，精力不济。请 chenall 和你们来研究吧。

扇区对齐是我当初写的代码。后来 karyonix 增加了 4K 对齐的代码。这是不同的人写的不同代码揉在一块了。chenall 和你们可以看看这里能否优化一下。

作者: zhaohj 时间: 2012-2-24 10:04
哇，竟然破坏了2KB，直接给出证据：
偏移0x3706000~0x37067ff的最后2kb数据破坏

[ 本帖最后由 zhaohj 于 2012-2-24 10:09 编辑 ]

Snap1.jpg (333.02 KB, 下载次数: 140)

作者: zhaohj 时间: 2012-2-24 10:33
分析一下：这个iso占用0x3706800个字节，共56346kb，除4后余2，正好2KB被破坏。
4k对齐我理解适合map --mem方式，而不适合map非mem方式。

[ 本帖最后由 zhaohj 于 2012-2-24 11:27 编辑 ]

作者: Plantsoot 时间: 2012-2-24 12:29
标题: 回复 #75 zhaohj 的帖子
有没看我那个奇怪的情况？

ISO镜像的大小是4K的倍数，map --mem启动失败，map不加--mem反而成功。

作者: 不点 时间: 2012-2-24 14:21
破坏掉的，正好是 2K。

这一点很值得疑惑。

而且破坏的数据正好是用 Unreadable .... （我猜测后面还有一个单词是 Data，在贴图中没显示出来）的可读字符填充 16 字节，不断重复同样的信息，直到把 2K 全部填满。

由于 grub4dos 会自动增加 ISO 的长度到 4K 对齐（虚拟后位于内存中的 ISO 应该是 0x3707000 字节），因此，我认为破坏掉的，不是 2K，而是 4K。请验证。

这就是说，这些内存并未真正使用，而是被某个软件 “ 初始化 ” 了，或者说，简单 “ 抹掉 ” 了。

那么这是谁干的呢？究竟是 Windows 干的呢，还是 winvblock/firadisk 干的？这需要进一步确认。猜测是 winvblock/firadisk 自己干的。

如果是 Windows 干的，即，它总是破坏顶端的 4K 内存，那么，这样也很容易验证。用一个虚拟软盘（其长度用 4K 对齐），就可以验证，是否软盘尾部正好有 4K 被破坏。此时最好不要运行 firadisk/winvblock，否则很难说清楚究竟是谁破坏了内存顶端。可以找找 Windows 下查看物理内存的 hex 工具。事先在 grub4dos 下记录映像文件的位置，然后进入 Windows 后查看内存，看看数据是否遭到破坏。

作者: zhaohj 时间: 2012-2-24 14:46
再补充两幅图（map非mem方式）：

[ 本帖最后由 zhaohj 于 2012-2-24 14:56 编辑 ]

Snap1.jpg (160.38 KB, 下载次数: 116)

Snap2.jpg (210.7 KB, 下载次数: 105)

Snap3.jpg (203.99 KB, 下载次数: 144)

Snap4.jpg (63.58 KB, 下载次数: 148)

作者: 不点 时间: 2012-2-24 15:21
标题: 回复 #78 zhaohj 的帖子
你这次贴出的是不带 --mem 的情况。上次也是的吧？

不带 --mem，就出现不能读 4K 余数部分的情况。这应该与 Windows 系统无关了。由此可以基本确定，是驱动程序自身的限制，或者算是 bug。

真实磁盘上的数据不可能被破坏，驱动程序不会轻易写入磁盘的，因为那样的话，bug 就大了。驱动程序仅仅把 4K 的余数部分，用这种方式屏蔽掉了。也就是说，当用户试图访问这些扇区时，它简单给出 unreadablesector 的内容，如此而已。

换句话说，驱动程序不支持 “ 非 4K 对齐 ” 的扇区。

你这个试验，不能证明 --mem 的情况。也就是说，内存中的 ISO 是否遭到破坏了，目前还不得而知。

作者: zhaohj 时间: 2012-2-24 15:57
我上面所有贴出的是不带 --mem 的情况。
---------------------
现在基本可以确定，驱动程序不支持“ 非4K 对齐 ”的扇区，并且驱动程序把 4K 的余数部分，用unreadablesector这种方式把4K 的余数部分填充了
刚又做了个试验，把ISO文件处理成4K 对齐，而且把wim文件的LBA搞成最大(导出导入就可)，完美实现虚拟光盘中所有扇区数据正常。

作者: 不点 时间: 2012-2-24 16:09
嗨，你这是（有点）浪费呀。本来就知道无--mem 的情况是必须 4K 对齐的，前面多次猜到了。这是已知的情况，你只不过证实了而已。当然，你证实它，也有功劳，不能抹杀。

我个人觉得最需要证实的，是 --mem 情况下遭到的破坏，究竟是怎样的？现在甚至连 “ 破坏者是谁 ” 都不能确定（是windows呢？还是winvblock/firadisk 驱动程序？）。

作者: Plantsoot 时间: 2012-2-24 16:24
我刚才做了个测试，我发现一个问题，不知道对不对。

1、
文件: G:\0PE4.ISO
大小: 122677248 字节（0x74FE800，0x3A7F4个512扇区，29950.5个4K扇区，姑且这样说）。

2、菜单

title map测试
map --mem (ud)/WINVBLK.IMG (fd1)
map --mem (md)0x6000+800 (fd0)
map --mem (ud)/MYPE.ISO (0xff)
map --mem (ud)/0PE4.ISO (0xfe)
map --hook
dd if=(fd1) of=(fd0) count=1
map --status
pause
chainloader (0xff)

3、启动过程截图：

4、原始文件的WINHEX截图

5、进入PE前后，再用winhex查看map出来的光驱

6、

map --mem后，map --status
发现map自动补齐到了4K的整数倍（122679296字节），0x3A7F8个512扇区，29951个4K扇区。

进入PE后，再次用winhex查看map出来的光驱，
大小依然为122677248 字节（0x74FE800，0x3A7F4个512扇区，29950.5个4K扇区）。

补齐的数据丢失？

[ 本帖最后由 Plantsoot 于 2012-2-24 16:42 编辑 ]

作者: 不点 时间: 2012-2-24 16:35
标题: 回复 #82 Plantsoot 的帖子
发现什么问题了？

也许你的 ISO 结尾处本来就有很多 00 字节呢？

不对比的话，根本不能说明问题。

ISO 文件长度被识别成多少，那是驱动程序的事。文件长度很可能记录在 ISO 文件开头的一些敏感数据区。驱动程序很容易知道真正的 ISO 文件系统的长度。

所以，长度问题，不用考虑。

现在我们只关心，究竟有多少内存被破坏了。

作者: zhaohj 时间: 2012-2-24 16:36
这样做了个试验：
!BAT
/srsf6/srsf6n fira
map --mem (hd0,4)/mype.iso (0xff)
map --hook
map --mem (md)0x200+4 (99)
map --hook
echo [FiraDisk] > (99)+1
echo StartOptions=cdrom,vmem=find:/mype.iso; >> (99)+1
chainloader (0xff)
boot

下面的F盘是map --mem虚拟的，G盘相当于map虚拟的
F盘内容正确，G盘有问题，破坏正好的0x800=2kb，即4kb的余数部分。

[ 本帖最后由 zhaohj 于 2012-2-24 16:41 编辑 ]

Snap1.jpg (27.64 KB, 下载次数: 117)

Snap2.jpg (131.1 KB, 下载次数: 119)

Snap3.jpg (127.43 KB, 下载次数: 118)

作者: Plantsoot 时间: 2012-2-24 16:50
标题: 回复 #83 不点的帖子
刚才漏了一个图，现在补上了。

总结一下：

map --status的时候有对它进行补齐数据，比原始的文件应该要大。
对于这个ISO，map --mem，进入PE后和原始的文件是一样的。
如果解释为“ISO 文件长度被识别成多少，那是驱动程序的事。文件长度很可能记录在 ISO 文件开头的一些敏感数据区。”
是不是就是说，map --mem的时候，根本就没必要补齐，因为补齐了进入PE后也是无效的？

但有的ISO补齐后，就可以正常使用了，我这个ISO不管补齐与否都是不能正常启动的，我又糊涂了。

作者: 不点 时间: 2012-2-24 17:15
标题: 回复 #85 Plantsoot 的帖子
所以猜测内存被破坏了呀。有这些现象的存在，才有猜测的根据呀。

猜测 + 证明，就是科学研究的方法呀。

补齐了以后，有可能在遭到内存破坏的时候，只破坏了补齐的无用部分，保护了 ISO 中有用的部分。

作者: 不点 时间: 2012-2-24 17:20
标题: 回复 #84 zhaohj 的帖子
你又一次证明了无 --mem 时，非4K对齐的失败情况。

而我们实际需要的是，在带有 --mem 的情况下，内存遭到破坏的证据。这个不容易证明了。估计要有很多困难。

作者: zhaohj 时间: 2012-2-24 17:23
有一点我不明白，map --mem会自动4K对齐，如下面的扇区总数是0x1b838=0x3707000字节，那为何在windows下查看虚拟光驱的总字节数是0x3706800?
少了0x800字节，即2KB.

Snap1.jpg (52.42 KB, 下载次数: 125)

Snap2.jpg (81.71 KB, 下载次数: 129)

作者: 不点 时间: 2012-2-24 17:38
标题: 回复 #88 zhaohj 的帖子
刚才在前面和百草霜的讨论中已经解释过了，你翻翻看。

在 83 楼。

[ 本帖最后由不点于 2012-2-24 17:40 编辑 ]

作者: 幸运的草 时间: 2012-2-24 17:39
提点建议：
还应注意另一个问题，一直不明白，但无能力证明。
　　同一个文件，为什么导出再导入，LBA值就变为最大？是不是说，它是把这个文件放到了ISO的最后位置？
这个情况和发现的FBINST的情况是一样的。
　　因此有理由怀疑，是这个工具在计算文件存放空间方面有错误呢。

[ 本帖最后由幸运的草于 2012-2-24 17:41 编辑 ]

作者: 不点 时间: 2012-2-24 17:42
标题: 回复 #90 幸运的草的帖子
目前的证据表明，这类工具没有犯错误。唯一可以算是毛病的是，它们没有把结果 iso 文件自动补全到 4K 对齐。这根本不能算是问题。

作者: Plantsoot 时间: 2012-2-24 17:47

原帖由不点于 2012-2-24 17:20 发表
你又一次证明了无 --mem 时，非4K对齐的失败情况。

而我们实际需要的是，在带有 --mem 的情况下，内存遭到破坏的证据。这个不容易证明了。估计要有很多困难。

不加--mem破坏数据的问题，刚才我也做了几次类似的测试，结果和zhaohj的一样，我就不贴图了。

奇怪的问题是我那个0PE.ISO。

加--mem启动失败，不加--mem启动成功，我用MYPE.ISO作为启动PE，
启动的过程中，分别 map 那个0PE.ISO 和 map --mem那个0PE.ISO。

启动到PE后发现map出来的两个光驱的数据完全一致，md5是一样的。

为什么一样的一个失败一个成功呢？

我想了下原因，因为启动到PE的是MYPE.ISO ，而不是0PE.ISO，所以没破坏0PE虚拟机光驱。

我尝试用0PE测试，但，0PE启动的过程中会--unmap掉另外一个虚拟机光驱，暂时没办法测试。晚上回去看看。

作者: Plantsoot 时间: 2012-2-24 17:52

原帖由 Plantsoot 于 2012-2-24 17:47 发表

为什么一样的一个失败一个成功呢？

我想了下原因，因为启动到PE的是MYPE.ISO ，而不是0PE.ISO，所以没破坏0PE虚拟机光驱。

奇怪了，我对比MYPE.ISO的时候也是用的同样的方法啊，有点晕……

作者: 不点 时间: 2012-2-24 18:30
标题: 回复 #92 Plantsoot 的帖子
这太容易解释了。

你的测试方法破坏了你的测试目的。

当你观察确定电子的位置的时候，你要用光子去碰它，结果，电子的位置确定到了一定的精度，但它的速度就完全测不准了。

你遇到的情况与此类似。

你的测试过程，干扰了测试结果，属于失败的试验。

作者: Plantsoot 时间: 2012-2-24 21:13
回复 #94 不点的帖子

嗯，确实自己干扰了自己。
刚才又做了一个测试。发现map --mem后启动到PE，竟然破坏了不少的数据，直接看图吧。

1、重新制作修改一个ISO，这里还是拿0PE.ISO，呵呵，P大不要介意。
在ISO尾部放一个文本文件，叫测试.txt，里面写一定数量的文字。
把ISO导入ud内。ISO大小为 122,681,344 字节，非4k整数倍。

win7下用winhex查看ISO：

用fbinsttool的16进制编辑器查看ISO。和上面的是一样的结果。

2、虚拟机测试，菜单如下：
title 0PE map
map --mem (ud)/0PE.ISO (0xff)
map --hook
chainloader (0xff)

进入PE后，用winhex查看虚拟出来的光盘，D盘。
发现尾部有很多数据已经不一样了。

3、对比破坏前后的测试.txt

4、用winhex把虚拟的光盘导出为一个镜像，和原始ISO对比。

[ 本帖最后由 Plantsoot 于 2012-2-24 21:32 编辑 ]

作者: 不点 时间: 2012-2-24 21:44
至此，已经证明了 Windows 下的内存盘遭到了破坏。

如果你的启动过程没有 map --e820cycles=... 的命令，那就是说，Windows （或它的某个模块）不遵守 int15 规范，破坏了由 int15 保护的内存。

这次不像是 firadisk/winvblock 的错误了，因为我们原先有大量的证据表明，Windows 会破坏内存。那时候，发现它忽略 BIOS 数据区 0x413 处的内存规范，造成了问题。现在的证据则表明，它也忽略 int15 规范，破坏内存。

如果测试过程中有某个步骤使用了 map --e820cycles=... 命令，并且其值不是 -1，那么这就是正常的了，因为我们的 iso 并未得到 int15 的保护，windows 当然可以把它当作空闲内存而写入它了。

作者: Plantsoot 时间: 2012-2-24 22:18
回复 #96 不点的帖子

刚才又用UltraISO特意修改了一个ISO, 保存后文件大小刚好为4K的整数倍。
然后做两种测试，真机测试。

1、map 不加 --mem
结果，启动后尾部 2048个字节被破坏。

2、map 加 --mem
结果，启动后尾部被破坏的数据超过了4K。

不知道是不是因为用的是0PE，对结果有一定影响。

[ 本帖最后由 Plantsoot 于 2012-2-24 22:22 编辑 ]

作者: 不点 时间: 2012-2-24 22:31
0pe 在启动过程中，有没有 map --e820cycles=... 这条命令，很关键。

既然 4K 对齐，不带 --mem 时仍旧有 2K 被破坏，这就是说，这个驱动程序很可能总是破坏 2K 数据，也即一个 2048 字节的大扇区。

而在带有 --mem 的情况，那就要看有没有执行过 map --e820cycles=... 命令了。有和没有，其性质是不一样的，前面已经阐明。

作者: Plantsoot 时间: 2012-2-24 22:53
标题: 回复 #98 不点的帖子
P大的0PE菜单比较复杂，我层层解压，发现有用到e820cycles的地方，但是按我的方式启动，这个应该是不起作用的。

具体还得等P大来解答，菜单的逻辑层层环套，我有点晕了，呵呵。

今天不折腾了，不点也要注意身体，这个问题用户解决起来也是很容易的。

[ 本帖最后由 Plantsoot 于 2012-2-24 22:54 编辑 ]

作者: 幸运的草 时间: 2012-2-25 08:51
我再次建议不要用0PE进行测试，用普通的ISO就是有SETUPLDR.BIN的那种进行测试。
p大再三声明，0PE不承认其他ISO制作工具，理由就是兼容性问题。

[ 本帖最后由幸运的草于 2012-2-25 09:32 编辑 ]

欢迎光临无忧启动论坛 (http://bbs.wuyou.net/)