支持含有碎片的文件仿真

chenall · 发表于 2015-1-21 16:11:03

mdyblog 发表于 2015-1-21 13:44
请问 json格式的下载信息在哪儿啊？

http://bbs.wuyou.net/forum.php?m ... &extra=page%3D1

chenall · 发表于 2015-1-24 17:18:51

@yaya
2015-01-22的改动可能有问题,这里有报告启动失败.

http://grub4dos.chenall.net/down ... 015-01-22/#comments

2011yaya2007777 · 发表于 2015-1-25 10:13:02

报告说不能启动 .iso，我这里测试没有问题。2015-01-22 的改动有可能影响 usb-cdrom，但是报告者不是这样的。

mdyblog · 发表于 2015-1-28 06:07:42

本帖最后由 mdyblog 于 2015-1-28 06:10 编辑

请问C大，能否实现这样的功能：将更1另新版grub.exe 最为外部命令来用。
或者叫 grubi.exe

执行完 grubi.exe 后返回。（返回到调用者grldr或grub.exe或grubi.exe）

grubi.exe 你面可以内置脚本：批处理脚本 (!BAT开始) 或菜单脚本

chenall · 发表于 2015-1-28 08:41:52

@yaya

这个好像和exfat有关系?

https://github.com/chenall/grub4dos/issues/33

2011yaya2007777 · 发表于 2015-2-2 22:14:38

本帖最后由 2011yaya2007777 于 2015-2-25 10:27 编辑

初步定位是 get_diskinfo 函数从 exfat 分区获得：Smax=0xff，Hmax=0x100。从而使 in_situ 置 1，惹出麻烦。
get_diskinfo 函数比较复杂，没看明白是怎样造成的。

不点 · 发表于 2015-2-2 22:32:58

本帖最后由不点于 2015-2-2 22:34 编辑

Hmax 是最大磁头号，不是磁头总数，所以，Hmax 最多只能是 255，不可能是 256。

通常 Hmax 取值为 254，也就是说，保证磁头总数可以用一个 byte 来表示。

而 Smax 更是不可以超过 63。怎可能是 0xff 呢？

2011yaya2007777 · 发表于 2015-2-3 06:45:52

所以说比较奇怪。得仔细探讨一下。

不点 · 发表于 2015-2-4 09:16:07

即使 S 和 H 错误，也不应该自动设定 in-situ 的值。只要你的命令行中没有设定 in-situ，它就不该设定。

又怀疑是 gcc 的问题了。假如有人攻击了 gcc，那么大部分开源软件都要瘫痪。

2011yaya2007777 · 发表于 2015-2-4 09:42:30

我可能没有说清楚。

2011yaya2007777 · 发表于 2015-2-4 09:58:49

S返回0xff，最高位1被带入映射擦槽，表示在原处。

不点 · 发表于 2015-2-4 10:11:19

那你就跟踪一下，看看什么地方的漏洞导致 S 和 H 探测出现重大错误。

chenall · 发表于 2015-2-4 13:12:18

@yaya

有报告0.4.6a的grldr.mbr出问题的(报告说换成0.4.5c正常)

信息在截图中了.汇编的我看不出是哪里的问题,你有空的时候看下.

不点 · 发表于 2015-2-4 13:27:58

Try （hd1）就有问题，没显示分区号，不正常。因此，代码需要继续锤炼。

2011yaya2007777 · 发表于 2015-2-4 20:26:12

可否把 (hd1) 的 MBR 及 (hd1,0) 的 PBR 截图上传？

chenall · 发表于 2015-2-5 08:58:32

2011yaya2007777 发表于 2015-2-4 20:26
可否把 (hd1) 的 MBR 及 (hd1,0) 的 PBR 截图上传？

用diskgenius备份出来的分区表信息.

2011yaya2007777 · 发表于 2015-2-5 20:27:11

是想看到出错硬盘的真正的 MBR。

2011yaya2007777 · 发表于 2015-2-5 20:36:13

那你就跟踪一下，看看什么地方的漏洞导致 S 和 H 探测出现重大错误。

0.4.6a 可以探测到 exfat 有 bpb，因此从 bpb 获取 H/S 参数。但是 H/S=0/0，所以产生错误。
位于 common.c 的init_bios_info 函数。
修正已经上传。

chenall · 发表于 2015-2-5 21:53:55

2011yaya2007777 发表于 2015-2-5 20:27
是想看到出错硬盘的真正的 MBR。

1.ptf用winhex打开,第二个扇区的内容就是对应(hd1)的MBR

2011yaya2007777 · 发表于 2015-2-8 17:53:54

有报告0.4.6a的grldr.mbr出问题的

已经修正，上传管网。

chenall · 发表于 2015-2-9 10:08:39

2011yaya2007777 发表于 2015-2-8 17:53
已经修正，上传管网。

辛苦了,我让他再测试一下看看

mdyblog · 发表于 2015-2-9 17:25:55

本帖最后由 mdyblog 于 2015-2-9 21:45 编辑

反应个现象。
为什么GRUB4DOS访问盘末尾是出现 “不支持LBA64”？
盘才６４Ｇ，　32位LBA 地址就够了。

访问磁盘尾部的6M系统，如图：

----------------补充测试----------------------
当尾部系统增加到8M时问题显示有不同。

----------------补充测试----------------------
当尾部系统增加到8.065M时问题显示有不同。没有任何提示，就是菜单读不出来。

----------------补充测试----------------------
当尾部系统增加到8.125M时就没问题了。菜单显示出来了。

1：U盘分区表
磁盘:1
  磁盘信息磁盘号大小(字节)       柱面数磁头数扇数扇区媒体    签名总线
            1 63786975232          7754 255 63  512 12 55276D56  7 MBR F
  字符说明激活 __本分区起始__ 分区 __本分区结束__ _______本分区______ ______本分区_______
  激活为0x80 磁头_扇区_柱面类型磁头_扇区_柱面 _____起始扇区号____ _____扇区总数______
  主分区1: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
  主分区2: 0x00 0xFE 0xFF 0xFF 0x0F 0xFE 0xFF 0xFF 0x69 0xB4 0xE0 0x01 0x54 0xE6 0xC1 0x03
  主分区3: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
  主分区4: 0x00 0x00 0x02 0x00 0xFE 0x00 0x02 0x00 0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00
  标志 : 0x55 0xAA
  全部分区: -1  @2  -3  1 2 3
  分区  类型激活(1) 起始(字节)    长度(字节) 隐藏扇区    结尾(字节) 物理# 盘符
-1  0x00 0             0             0          0             0 1
@2  0x0F 0 16129774080 32275998720 31503465 48405772800 2
-3  0x00 0             0             0          0             0 3
   1  0xFE 0          512          512          1          1024 4
   2  0x0B 0 16129806336 16137967104       63 32267773440 5  G:
   3  0x0B 0 32267805696 16137967104       63 48405772800 6  H:

2：尾部的6M系统不在分区表中（深度隐藏的）
用
map --in-situ (hd0)XX+YY (hd0)
...
来映射的虚拟磁盘。

3：可能是QEMU虚拟机的问题。
62291968K /63s /255 = 7754.99134765017
不是整数个柱面，
最后的零碎： 62291968K - 7754. * 63s * 255 = 8154112 = 7.7763671875M （一个柱面7.84423828125M < 8M）
和上面的测试比较接近，但相差0.3486 M

-----------------后续----------------
“相差0.3486 M”可能是grldr-文的空间，将menu.lst 挤到到后面了。
只留menu.lst, 7.85M
测试i通过。如图：

这恰好对应后面那个柱面零碎。

不点 · 发表于 2015-2-9 17:43:06

mdyblog 发表于 2015-2-9 17:25
反应个现象。
为什么GRUB4DOS访问盘末尾是出现 “不支持LBA64”？
盘才６４Ｇ，　32位LBA 地址就够了。

出错信息是 qemu 的主板 BIOS 发出的，不是 grub4dos 发出的。

1、试试 0.4.5，看看是否有相同的问题，方便开发者追踪问题的根源。
2、盘上的分区表是否不正常？假如分区起始扇区号为 0xFFFFFFFF，分区长度为 0xFFFFFFFF，那么这就可能超出 32 位的范围，需要访问 64 位的扇区号了。

to 开发者：

用跟踪调试等手段检查代码，看看什么代码导致 64 位的扇区号被传入主板 BIOS int13，造成问题。

mdyblog · 发表于 2015-2-9 17:50:47

不点发表于 2015-2-9 17:43
出错信息是 qemu 的主板 BIOS 发出的，不是 grub4dos 发出的。

1、试试 0.4.5，看看是否有相同的问题 ...

1：U盘分区表
磁盘:1
  磁盘信息磁盘号大小(字节)       柱面数磁头数扇数扇区媒体    签名总线
            1 63786975232          7754 255 63  512 12 55276D56  7 MBR F
  字符说明激活 __本分区起始__ 分区 __本分区结束__ _______本分区______ ______本分区_______
  激活为0x80 磁头_扇区_柱面类型磁头_扇区_柱面 _____起始扇区号____ _____扇区总数______
  主分区1: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
  主分区2: 0x00 0xFE 0xFF 0xFF 0x0F 0xFE 0xFF 0xFF 0x69 0xB4 0xE0 0x01 0x54 0xE6 0xC1 0x03
  主分区3: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
  主分区4: 0x00 0x00 0x02 0x00 0xFE 0x00 0x02 0x00 0x01 0x00 0x00 0x00 0x01 0x00 0x00 0x00
  标志 : 0x55 0xAA
  全部分区: -1  @2  -3  1 2 3
  分区  类型激活(1) 起始(字节)    长度(字节) 隐藏扇区    结尾(字节) 物理# 盘符
-1  0x00 0             0             0          0             0 1
@2  0x0F 0 16129774080 32275998720 31503465 48405772800 2
-3  0x00 0             0             0          0             0 3
   1  0xFE 0          512          512          1          1024 4
   2  0x0B 0 16129806336 16137967104       63 32267773440 5  G:
   3  0x0B 0 32267805696 16137967104       63 48405772800 6  H:

2：尾部的6M系统不在分区表中（深度隐藏的）
用
map --in-situ (hd0)XX+YY (hd0)
...
来映射的虚拟磁盘。

不点 · 发表于 2015-2-9 20:23:23

本帖最后由不点于 2015-2-9 20:34 编辑

刚刚想到，你也是开发者，你也可以直接调试。

扩展分区里面的逻辑分区表，如果有毛病，照样有可能引起死机。比如，错误地指向了一个很大的扇区号，造成问题。

补充：确实如你所说，有可能是 qemu 自身 bios 的毛病，比如说，它在读取尾部的扇区时，自己出现了 bug。

你可以试试别的虚拟机，如果别的虚拟机没毛病，那就可以确定是 qemu 的毛病了。

freesoft00 · 发表于 2015-2-9 22:31:13

2011yaya2007777 发表于 2015-2-8 17:53
已经修正，上传管网。

Well, after many tests, it seems that the MBR/PBR from the latest 0.4.6a versions is buggy.
The MBR is having problems finding GRLDR on partitions with file system type <> NTFS and displaying error messages.
And half of the PBR's are not booting.
In the same testing conditions the MBR/PBR from 0.4.5c and the one from 0.4.6a BOOTICE version are booting ok (except for exFAT ofcourse).

In this situation there is not much I can do but wait for yaya to fix it...
英文我不怎么看的懂，他的意思，0.46a还是有问题吗？
http://reboot.pro/topic/20238-im ... ws-and-linux/page-6

chenall · 发表于 2015-2-10 08:53:32

这里又有报告0.4.6a的问题的

https://github.com/chenall/grub4dos/issues/37

freesoft00 · 发表于 2015-2-10 09:44:34

http://reboot.pro/topic/20238-im ... ws-and-linux/page-6
grubinst-gui的中文语言文件还是旧的，不适合这个修改过的新版本了。不知道谁可以更新一下那个语言文件

不点 · 发表于 2015-2-10 11:52:11

chenall 发表于 2015-2-10 08:53
这里又有报告0.4.6a的问题的

https://github.com/chenall/grub4dos/issues/37

这个报告依旧显示 try (hd0)，没有正常显示分区号。因此 0.4.6 仍然含有逻辑错误。

2011yaya2007777 · 发表于 2015-2-10 21:25:12

本帖最后由 2011yaya2007777 于 2015-2-25 10:25 编辑

这个报告依旧显示 try (hd0)，没有正常显示分区号。因此 0.4.6 仍然含有逻辑错误。

		自动登录	找回密码
密码			注册

支持含有碎片的文件仿真

点评

点评

点评

点评

点评

点评

点评