非--mem形式 map iso镜像后读取文件失败的问题

Plantsoot

原帖由 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

回复 #15 pseudo 的帖子

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

Plantsoot

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

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

Plantsoot

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

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

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

Plantsoot

嗯，呵呵，看来我们都遇到了同样的问题，只不过没引起重视，也没去追究真正的原因，用其他的方法“解决”了就没再去找原因了。

Plantsoot

P大还记得我的U盘吗？我拖入grldr + 0PE.ISO，会卡住加载WIM的阶段，然后我再拖入一个同样的ISO，后者可以顺利启动。

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

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

Plantsoot

我那个问题很奇怪，不知道你还记得不记得我和P大当时找原因的情况。

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

Plantsoot

我更糊涂了，因为同样的文件，同样的U盘，上次我直接拖入grldr和0PE.ISO到ud，启动过程中有无法找到PE.WIM的提示。
然后再拖入一个0PE.ISO到ud，原来的改名，就可以正常启动到PE桌面。

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

我马上测试真机。

Plantsoot

我上次遇到的情况无法再现，先不管了。今天我做了另外一个测试。

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
	--mem	239744	59936	29968	成功
122677248		239604	59901	29950.5	失败	用ultraiso修改，把PE.WIM删除后保存，再加入PE.WIM
	--mem	239608	59902	29951	失败
122679296		239608	59902	29951	成功
	--mem	239608	59902	29951	失败
122681344		239612	59903	29951.5	成功
	--mem	239616	59904	29952	成功
122682368		239614	59903.5	29951.75	成功
	--mem	239616	59904	29952	成功
122683904		239617	59904.25	29952.125	成功
	--mem	239624	59906	29953	成功
122685952		239621	59905.25	29952.625	成功
	--mem	239624	59906	29953	成功
122748928		239744	59936	29968	成功
	--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 编辑 ]

Plantsoot

看看我上面的测试，是不是有点意思，我现在拿楼主的MYPE.ISO测试下。

一会给结果。

Plantsoot

我拿楼主的有问题的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 编辑 ]

Plantsoot

我明白你的意思，我是说不管ISO有没用软碟通修改过，
只要map的时候都把ISO的体积扩大4K，是不能就代表着ISO都可以兼容了，
管他有没用软碟通修改过，或者采取我上面说的另外一个方法，
用软碟通修改的时候末尾加上4K的00.

Plantsoot

为什么人为在文件尾部增加4k的空间后，又不抛弃了？

Plantsoot

map --mem 不一定成功，你看我做的测试。

文件大小

map

map后占扇区数（512）

map后占扇区数（2048）

map后占扇区数（4096）

启动

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

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

Plantsoot

全部的测试：
http://bbs.wuyou.net/forum.php?m ... p;page=5#pid2388985

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

Plantsoot

以上测试是 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 编辑 ]

Plantsoot

回复 #61 不点 的帖子

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

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

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

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

Plantsoot

这样解释的话应该解释的通了，所以我在尾部增加大于4K的数据后破坏的部分是无用的部分，解释通了。

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

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

Plantsoot

有没看我那个奇怪的情况？

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

Plantsoot

我刚才做了个测试，我发现一个问题，不知道对不对。

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 编辑 ]

Plantsoot

刚才漏了一个图，现在补上了。

总结一下：

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

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

Plantsoot

原帖由 不点 于 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

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


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

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

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

Plantsoot

回复 #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 编辑 ]

Plantsoot

回复 #96 不点 的帖子

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

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

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

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

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

Plantsoot

P大的0PE菜单比较复杂，我层层解压，发现有用到e820cycles的地方，但是按我的方式启动，这个应该是不起作用的。

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

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

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

Plantsoot

就是为了找到具体问题出在哪里，为什么不兼容，呵呵。

Plantsoot

嗯，还是用楼主的ISO测试比较好，呵呵，也许我这两天做的测试大部分是失败的，只证明了不点说的
“既然 4K 对齐，不带 --mem 时仍旧有 2K 被破坏，这就是说，这个驱动程序很可能总是破坏 2K 数据，也即一个 2048 字节的大扇区。”

想办法把楼主的ISO弄成4K的整数倍，再验证下不带--mem的情况是否破坏2K的数据。