不知道这个是不是GRLDR的BUG，之前好像讨论过

红毛樱木

无法读取U盘的(hd0,1)分区，用一段时间就这样，但是其他分区软件能读取，也没有报错，不知道怎么处理，还需要提供哪些信息？

不点

红毛樱木 发表于 2018-1-25 16:00
是啊，这个问题好久了，一直没有条件反馈，正好今天有用户反馈，就让用户保留这个U盘别动，来反馈了。分 ...

不是 grub4dos 检查 FAT 格式的条件苛刻，而是攻击者有针对性的定点爆破。

grub4dos 是按规范来的。攻击者让 FAT 的某个地方 “不规范”，从而达到攻击 grub4dos 的目的。

攻击者也许能让别的软件不受影响，也许别的某个软件也会 “躺枪” 也说不定。

它的攻击做得 “好” 的话，只让 grub4dos 失效；做得 “差” 的话，让别的 “无辜” 软件也失效。

当我们通过分析，找到它的 “机关” 的时候，我们也就能适应它的 “不规范” 了。

tools241

请参考:
[分享]Grub4Dos - 直接启动Win10,...,Win7, 第1个XP, XP.VHD, ISO, WIM, PE ==>
    http://bbs.wuyou.net/forum.php?mod=viewthread&tid=380990

不点

你是不是弄错盘号了？从你的贴图来看，并不能看出你是否弄错盘号了。

试试

ls (hd0,1)/
ls (hd1,1)/
ls (hd2,1)/

ls (fd0,1)/
ls (fd1,1)/

还有

geometry (fd0)
geometry (fd1)
geometry (hd0)
geometry (hd1)
geometry (hd2)

如果你确实没弄错盘号的话，你可以给出 cat 的结果：

cat   --hex   (hd0)+1

看看分区表对不对。

红毛樱木

不点 发表于 2018-1-25 15:16
你是不是弄错盘号了？从你的贴图来看，并不能看出你是否弄错盘号了。

试试

来啦，我对grldr的命令不熟。。

红毛樱木

不点 发表于 2018-1-25 15:16
你是不是弄错盘号了？从你的贴图来看，并不能看出你是否弄错盘号了。

试试

好像发现问题了，您看这个正常的U盘，能识别到(hd0,1)是fat32分区，而不正常的识别不到。这种有没有办法用grldr自动修复？

不点

怀疑病毒破坏了 U 盘的某些数据（比如 FAT32 的 BPB 表上的某些标志位），导致 grub4dos 无法识别此分区。

很久以前我解决过类似问题。那时候，攻击的目标是 GNU GRUB legacy，而 grub4dos 只是躺枪罢了。那时候，病毒修改了 FAT 表开头的介质类型位，导致 grub legacy 无法挂上 FAT 分区。我通过忽略检查某些位，轻易化解了攻击。其实不是什么病毒干的，而是 gnu grub 的敌人干的。

你让 yaya 来排解问题吧，我猜一定可以找到它的 “机关”。

红毛樱木

不点 发表于 2018-1-25 15:57
怀疑病毒破坏了 U 盘的某些数据（比如 FAT32 的 BPB 表上的某些标志位），导致 grub4dos 无法识别此分区。
...

是啊，这个问题好久了，一直没有条件反馈，正好今天有用户反馈，就让用户保留这个U盘别动，来反馈了。分区其实还在的，可能就是GRUB4DOS判断这个FAT32分区类型条件太苛刻太多了才导致这种问题。等yaya上线再提供进一步信息了。

红毛樱木

不点 发表于 2018-1-25 16:10
不是 grub4dos 检查 FAT 格式的条件苛刻，而是攻击者有针对性的定点爆破。

grub4dos 是按规范来的。攻 ...

这个和攻击无关，平常使用用着用着grub4dos就读取不到这个分区了。
快来个补丁吧yaya

不点

红毛樱木 发表于 2018-1-25 16:27
这个和攻击无关，平常使用用着用着grub4dos就读取不到这个分区了。
快来个补丁吧yaya

换个说法：有软件偷偷写入 U 盘，或者破坏 grub4dos 的代码，或者破坏了 U 盘上的某些数据，导致 grub4dos 出问题。至于说这算不算攻击，自个决定。


“和攻击无关”——有这样的把握？这么肯定？攻击者也不可能敲锣打鼓说是他干的呀（世事也有例外，比如某某组织就声称对某个炸弹攻击事件负责；不过那是有目的的，他们想要形成 “震慑效应”，扩大影响力，而不需要偷偷摸摸的）。你的 U 盘如果从来不插到 Windows 下，也不插到别的电脑上，你或许还可以说 “没攻击”。你只要跟外界交流，不可避免地就可能伤风感冒。世上哪有那么干净的事情、一尘不染？不排除你确实能证明那纯粹是 grub4dos 自己毁了自己——假如你确实不曾有过任何染毒的机会的话（这意味着你十分确定，从不让这个 U 盘与外界有交流、外界没有任何写盘的机会，这是很苛刻的了，一般是很难做到的）。

“快来补丁，yaya？”——你不提供攻击细节，怎可能有补丁？难道你是说 grub4dos 自己在攻击自己？纯粹是 grub4dos 的 bug？别开玩笑了，grub4dos 都是读盘，不会随便写盘的，怎可能破坏盘上的数据？除非你自己使用了错误的命令，写盘了。再说了，要是漫无目的随机写盘，那它毁坏的恐怕就不是小范围，也很难是这么精准——只让 grub4dos 无法挂上分区，其他软件不受影响。

我扯这么多，真不知有用没用。

红毛樱木

不点 发表于 2018-1-25 16:33
换个说法：有软件偷偷写入 U 盘，或者破坏 grub4dos 的代码，或者破坏了 U 盘上的某些数据，导致 grub4 ...

您记得读取分区格式的代码在源码中的哪个文件吗？

不点

红毛樱木 发表于 2018-1-25 18:27
您记得读取分区格式的代码在源码中的哪个文件吗？

对了，你也可以调试的。只要在源代码中加入 printf 打印一些信息，就能定位出错的位置，一点也不难，我每次都是用这个笨办法调试的。

FAT 文件系统处理代码好像在 fsys_fat.c 里面。

是的，不需要开发者，你自己也可以搞定。我就是这么折腾的，从一个完全的外行，变成了开发者。

你是高手，肯定能搞定。

红毛樱木

不点 发表于 2018-1-25 18:52
对了，你也可以调试的。只要在源代码中加入 printf 打印一些信息，就能定位出错的位置，一点也不难，我每 ...

fsys_fat.7z (5.83 KB, 下载次数: 0)

2018-1-25 22:29 上传

点击文件名下载附件

这个是我用的版本的fsys_fat.c
看不懂。。。  不点能看看改一下要显示什么信息出来给你们看？

不点

红毛樱木 发表于 2018-1-25 22:33
这个是我用的版本的fsys_fat.c
看不懂。。。  不点能看看改一下要显示什么信息出来给你们看？

很不好意思，我现在不能投入开发 grub4dos 了。你要么自己弄，要么等着开发者替你弄。

我的精力是有限的，有很多事情都占用我的时间。我安排自己在 grub4dos 上的投入，不多也不少，就是目前这么多。只做自己愿意做并且力所能及的工作。就是说，既能给别人提供有限的建议或帮助，也不让自己受累。

我现在连上网都不容易了，小字看不见，要用大字了。

2011yaya2007777

把分区表 0x1d2 处的分区标记 0xef ，修改为 0x0c 试一试。
如果还不行，那就是分区起始太大，0x06915d14 扇区，52.4Gb。

我一般是使用手机浏览本网站。这几天不知为何，手机不能访问本网站。

chiannet

红毛樱木 发表于 2018-1-25 16:00
是啊，这个问题好久了，一直没有条件反馈，正好今天有用户反馈，就让用户保留这个U盘别动，来反馈了。分 ...

是的，此问题发现很久了。从MAXSKYPE、 USBZL到USBOS早期版本都有人提到过。数量不多，但挺烦人。

据反馈说都是用着用着，忽然某一天就这样了：GRLDR 读取UD区内的文件没有问题，而UD区之外，不论高端分区，低端分区都有报告说GRLDR读取不了。通常用fbinstool工具修复一下MBR就没问题了。

从2015年起，USBOS启动文件，加入了应对机制：就是制作完毕，调用BOOTICE备份U盘设备的mbr文件，存放到UD区，一旦gldr读取不到UD分区之外的其它文件时，就由GRLDR自动把UD区内备份的mbr文件还原到U盘。这样做之后，就没有人再报告此类问题了。

但是这样做弊端也明显，就是怕备份了mbr文件之后，人为更改分区状态而没有及时重新替换mbr备份文件。当再次发生此故障时，用过时的MBR恢复到U盘。

2011yaya2007777

把 (hd0,1) 的引导扇区贴上来。即BPB表。
是不是被破坏了。

gy0715

2011yaya2007777 发表于 2018-1-26 09:04
把 (hd0,1) 的引导扇区贴上来。即BPB表。
是不是被破坏了。

。。。

2011yaya2007777

分区起始 0x06915d14 扇区。
使用 DiskGenius 打开磁盘，选中磁盘，点“扇区编辑”卡，点下面“偏移量”，选“起始”，“扇区”，“十六进制”，输入“6915d14”，点“确定”。
出来PBR。使用鼠标拖曳选中1扇区，点右键，复制选快->另存为新文件

2011yaya2007777

Re gy0715
是楼主反映的坏U盘的数据吗？我只要楼主反映的坏U盘的数据。

2011yaya2007777

分区表 0x1d2 处的分区标记 0xef，实测不影响。
有可能是BPB表被破坏了。

不点

2011yaya2007777 发表于 2018-1-26 08:31
把分区表 0x1d2 处的分区标记 0xef ，修改为 0x0c 试一试。
如果还不行，那就是分区起始太大，0x06915d14  ...

grub4dos 忽略 ID 字节。所以，应该与 EF 字节无关。

另外，搜到 EE 和 EF 的解释（见下文），它们是用于 EFI 的专用分区类型。我估计用户不可以把它当成普通的分区类型来使用。我猜，操作系统有可能会按照 EFI 规范来写入此分区！

果真如此的话，那就不需要做任何事了（不是 grub4dos 该管的事），只要避免使用 EF 字节即可。

“分区起始扇区号太大”，这也不像是造成问题的原因。因为原先能访问该分区，好好的（分区位置没变化），突然有一天不行了。

https://www.win.tue.nl/~aeb/partitions/partition_types-1.html

ee Indication that this legacy MBR is followed by an EFI header
ef Partition that contains an EFI file system

    Bob Griswold (rogris@Exchange.Microsoft.com) writes: MS plans on using EE and EF in the future for support of non-legacy BIOS booting. Mark Doran (mark.doran@intel.com) adds: these types are used to support the Extensible Firmware Interface specification (EFI); go to developer.intel.com and search for EFI. (For the types ee and ef, see Tables 16-6 and 16-7 of the EFI specification, EFISpec_091.pdf.)

不点

恕我直言，可启动 U 盘不应该使用多分区。因为有些 BIOS 不支持多分区，会在启动时卡死。楼主使用多分区 U 盘，不具有通用性。如果只是自己用，那也没啥，只要自己的 BIOS 支持多分区启动便可。但如果要推广到大众，则不可取。

可启动 U 盘采用多分区就已经 “不正确” 了，而采用 EF 这种专用分区 ID，那就更是 “找事” 了。请原谅，我是 “就事说事”，是 “幽默”；决不是批评、指责、教训、数落人。我们的目的是共同研究、讨论和解决问题。我只是谈谈见解、想法而已，也不一定说得对。

gy0715

2011yaya2007777 发表于 2018-1-26 10:36
Re gy0715
是楼主反映的坏U盘的数据吗？我只要楼主反映的坏U盘的数据。

。。。

不点

好的，假如当事人明知 EF 字节不可以用，但（由于某种原因）偏偏想用，并且 yaya 也愿意对此问题进行定位和调试的话，我认为最快捷方便的调试手段就是在 fsys_fat.c 里面插入 printf 打印信息，逐步定位。看看为何此分区未能成功识别为 FAT。

红毛樱木

不点 发表于 2018-1-26 11:23
好的，假如当事人明知 EF 字节不可以用，但（由于某种原因）偏偏想用，并且 yaya 也愿意对此问题进行定位和 ...

和ef无关，以前用0B或0C也是一样问题。你的这个猜测要忽略

红毛樱木

2011yaya2007777 发表于 2018-1-26 10:36
Re gy0715
是楼主反映的坏U盘的数据吗？我只要楼主反映的坏U盘的数据。

他的优盘就是我反馈的优盘

红毛樱木

不点 发表于 2018-1-26 11:23
好的，假如当事人明知 EF 字节不可以用，但（由于某种原因）偏偏想用，并且 yaya 也愿意对此问题进行定位和 ...

关键是我真不会C
或者改好那个C文件给我，我有编译环境，编译了把输出信息给你们看。

不点

红毛樱木 发表于 2018-1-26 11:31
和ef无关，以前用0B或0C也是一样问题。你的这个猜测要忽略

既然如此，那你们就配合 yaya 来调试吧。

不点

红毛樱木 发表于 2018-1-26 11:34
关键是我真不会C
或者改好那个C文件给我，我有编译环境，编译了把输出信息给你们看。

还是看 yaya 有什么调试计划吧。我只是谈了自己的调试方法和习惯，不一定适合 yaya。