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

不点

目前的证据表明，这类工具没有犯错误。唯一可以算是毛病的是，它们没有把结果 iso 文件自动补全到 4K 对齐。这根本不能算是问题。

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

不点

至此，已经证明了 Windows 下 的内存盘遭到了破坏。

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

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

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

Plantsoot

回复 #96 不点 的帖子

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

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

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

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

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

不点

0pe 在启动过程中，有没有 map --e820cycles=... 这条命令，很关键。

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

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

Plantsoot

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

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

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

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

幸运的草

我再次建议不要用0PE进行测试，用普通的ISO就是有SETUPLDR.BIN的那种进行测试。
p大再三声明，0PE不承认其他ISO制作工具，理由就是兼容性问题。

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

Plantsoot

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

jianliulin

我也觉得幸运的草建议的好，测试环境越单纯越好

幸运的草

因为0pe与其他普通的ISO不同，他是由GRLDR引导的，里面的很多菜单程序语句及变量，还有很多内存使用，测试环境很复杂，你不可能知道到底是由于GRLDR使用引起的内存变动还是由于WINDOWS对内存的破坏。
  而普通的ISO，却是由于WINDOWS的引导模块引导，测试环境简单。
  这就是我建议用普通的ISO做测试的原因。可以排除其他情况的干扰。



还有一个有意思的现象：
　　我把楼主的ISO，用软碟通导出，将引导记录保存，然后新建一个ISO，导入原引导记录，制作时，我故意把BASIC.WIM最后导入，保存后，再打开，却发现，最后导入的BASIC.WIM的LBA值却不是最大的。相反，先前导入的背景文件的LBA值却是最大的。
　　再观察，发现新制作的ISO，其LBA值是有规律的，他是按目录层数放置的。目录层次越深，LBA值越大。但无论是否最大。却不会被破坏。奇怪？

　这个ISO和楼主的ISO字节数是一样的。
稍后，我上传到115，供各位测试研究。 对比同一个工具制作与修改后有什么变化。看新制作的ISO，是否也有4K问题。

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

Plantsoot

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

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

幸运的草

我的意思是说，新制作的ISO，所楼主的字节数是一样的，如果是4K的问题，那这个也应该存在，你们查查看，如果不存在问题，那这个WINDOWS破坏4K的问题就值得怀疑。至少可以证明是否制作工具本身存在问题。

经测试，这个新制作的ISO，启动没有问题。（但不代表无4K的问题）

http://115.com/file/e7lwv5pa#
pe.rar

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

2011bigbarry

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

答非所问

2011bigbarry

这个帖子我每一个回帖都看了一下。其实已经有人接近真相了，但是没有坚持下去。
造成加载失败的不是Winvblock，不是Grub4DOS，不是Windows……
失败的原因是UltraISO。
解决的对策也是很简单的，用UltraISO修改镜像之后，必须用“另存为”进行保存。否则会出现莫名其妙的错误！

个人感觉UltraISO的“保存”当相于增量式保存，它保存了原始数据和修改的步骤。用Grub加载容易出现错误。而它的“另存为”保存的才是最终结果。

[ 本帖最后由 2011bigbarry 于 2012-2-29 05:15 编辑 ]

网虫2008

原帖由 2011bigbarry 于 2012-2-29 05:14 发表
这个帖子我每一个回帖都看了一下。其实已经有人接近真相了，但是没有坚持下去。
造成加载失败的不是Winvblock，不是Grub4DOS，不是Windows……
失败的原因是UltraISO。
解决的对策也是很简单的，用UltraISO修 ...

也不用另存为...那么麻烦的
在UltraISO窗口，找到引导文件，重设置一下既可

blithewind

原帖由 2011bigbarry 于 2012-2-29 05:14 发表 这个帖子我每一个回帖都看了一下。其实已经有人接近真相了，但是没有坚持下去。造成加载失败的不是Winvblock，不是Grub4DOS，不是Windows……失败的原因是UltraISO。解决的对策也是很简单的，用UltraISO修 ...

这个也未必.很多人都使用mkisofs做ISO的.

幸运的草

回复 #108 网虫2008 的帖子
很多问题不是修改引导出现问题，而是修改WIM即二级内核出现挂载失败的问题。

回复 #107 2011bigbarry 的帖子
我在前面就指出是软碟通的问题，被不点否定了。　

　在＃103、＃105就是要证明这个问题。但我没能力测试。
　我一直不认为是WINDOWS及FIRADISK等驱动造成的。

经测试，另存为也不行，必须是新制作做的才行。还有一个问题。同一个文件导出再导入，就不在原位置放置了。放到最后面。是否说明它这个判断中间连续空间的方法有问题？我也一再强调这个问题，这和FBINST出现的是一样的问题。

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

zhaohj

目前的讨论结果已经很明朗了：
map --mem会自动4K对齐；
map非mem一个连续存放在本地的镜像，因为制作时如果不是4K对齐，FIRADISK或winvblk驱动会自动丢弃4K模的余部，驱动程序用固定的一组字符串填充它。这样造成包含在余部的文件无法读取。
------------------
解决办法：
1：镜像制作成4K对齐；
2：镜像用ultraiso等工具最后另加入一个大于等于4k的任意文件。

这是驱动程序的限制，目前无解。

pseudo

map非mem一个Ultraiso修改过的镜像，map成功后其内文件可能无法被grldr访问。

幸运的草

这个，可以理解，解决办法也不是一种，前面的帖子我就提出了几种解决方案，经测试都通过。
　　我主要有一个纠结的疑问：为什么同一个文件，导出再导入，LBA的值就是最大的。（文件被放到最后了）。按道理不应该。这个问题同原来的FBINST的BUG是一样的。我怀疑软碟通在这方面也可能有问题。
　　谁能证明软碟通这个工具在计算空间容量方面有BUG？

东写西读

近日下载我心如水的2012.3合盘，也是这样啦！（也许是我个案）

我自己尝试将我心如水的2012.3合盘增加一个大于4K的小文件，仍然无法加载外置

用全部装载到内存则一切正常！

不知道谁还遇到类似的问题，这个问题目前有定论了没有？

糊涂

幸运的草 发表于 2012-2-22 08:43
回复楼上各位：
　　这个问题，确实是软碟通的问题。很久前我们在调试NATIVE版的PE时，就发现了这个问题。 ...

从头看到结尾，只有这位老师说到点儿上了

一是注意WIM文件LBA值不能为最大，再就是注意此二级ISO文件碎片整理

一般注意这两点后，极速PE外置挂载问题就轻松解决！

感谢分享

糊涂

另分享一枚整理二级内核碎片的工具

整理文件碎片工具.rar (528.82 KB, 下载次数: 46)

2013-4-26 06:52 上传

点击文件名下载附件
下载积分: 无忧币 -2