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

不点

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

试试

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

看看分区表对不对。

不点

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

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

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

不点

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

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

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

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

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

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

不点

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

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


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

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

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

不点

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

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

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

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

你是高手，肯定能搞定。

不点

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

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

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

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

不点

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，那就更是 “找事” 了。请原谅，我是 “就事说事”，是 “幽默”；决不是批评、指责、教训、数落人。我们的目的是共同研究、讨论和解决问题。我只是谈谈见解、想法而已，也不一定说得对。

不点

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

不点

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

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

不点

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

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

不点

2011yaya2007777 发表于 2018-1-26 15:16
以前正常，后来不正常，说明与grub4dos无关。
1楼贴图反馈不能挂载所选分区，可能是：
1. MBR分区表有问 ...

可能性太多了，比如，有可能是 ud 某些数据被破坏，影响了 grldr。也或者 grldr 本身被破坏，当然也就不正常了。

先按照 “可能性大的情况” 去处理吧。哪种情况可能性大，就先处理它。

我觉得，应该先试试从硬盘启动 grldr，看看可否访问 U 盘的 FAT 分区。

如果硬盘的 grldr 没问题，那说明是 U 盘的 GRLDR 遭到了破坏造成的。

如果硬盘的 grldr 也是同样的问题，那就确定是 FAT 分区关键信息被修改造成的了。

不点

gy0715 发表于 2018-1-26 15:23
请再看看附件。

你搞错了吧？截取的是无用的扇区。

yaya 如果直接给个调试版让他测试，就不难为他了。

不点

gy0715 发表于 2018-1-26 16:00
截取错了吗？

太难了，还是不截取算了。

等着 yaya 给你一条 grub4dos 的命令，那样更容易一些吧。


我前面提的问题，你能回答吗？

就是，在硬盘启动 grldr，看看能否访问 U 盘的 FAT32 分区？这个试验你能做吗？

不点

窄口牛 发表于 2018-1-26 23:25
遇到过，莫名其妙启动不了了，必须重写mbr，第一次以为自己操作硬盘点错，把优盘搞坏；后来不能启动，用boo ...

这个情况我早发现了。恶意软件偷偷写入引导区，即磁盘开头的若干个磁道，造成破坏。楼主的报告，本质上也是这种情况，只不过表现形式不同而已。正如 yaya 所说，只要一开始没问题，那就与 grub4dos 无关。后来出的问题，都是别的软件的问题。

总共大致有以下这些可能性：

情况一：主板 bios 有 bug，它能破坏硬盘的引导区。或者是恶意的，故意破坏 grub4dos。

情况二：某（恶意、病毒）软件偷偷写入引导区，破坏了 grub4dos。

情况三：Windows 操作系统的工具软件或某个驱动程序写入了引导区，造成破坏。这种情况是可能的，因为 Windows 也使用第一磁道。当你不使用 Windows 的某些磁盘工具的时候，可能没事。一旦使用了 Windows 自带的磁盘分区操作工具，就可能触发写入第一磁道的动作。

情况四：grub4dos 的 bug，自己毁了自己（基本不可能是这种情况）。


大家应该首先确定究竟是上述哪种情况。

如果是情况一，那根本就无解，你只能忍受。
如果是情况二，大家通过大量试验逐步排查，应该能够抓住这个恶意软件。
如果是情况三，那很容易解决：当可启动 U 盘插在电脑上的时候，永远不要直接或间接使用 Windows 自带的磁盘命令。

不点

红毛樱木 发表于 2018-1-27 09:18
严重了。
这里ud的引导正常，
(hd0,0)的NTFS访问正常，

UD区看似正常，其实可能不正常。你有没有逐个字节进行对比？看看 ud 引导区是否被修改？你没有对比，就不敢拍胸脯说 ud 区没问题。

而且还有这种可能性：ud 引导区没破坏，但是 grldr 遭到了病毒的修改！假如你没有核对，你同样不敢拍胸脯。

技术是严肃的，不是想当然的。必须通过实际排查，通过艰苦劳动，才会有收获，否则都是空谈。


ud 能启动，或者甚至能启动到 grub 环境，这并不表明 ud 区未被动手术！这个概念应该不难建立吧？不要被假象迷惑了！

不是有报告说，只要重建 ud 的代码，一切都正常了。你怎么解释这个现象？

最自然的解释，首先很容易想到，是 ud 区代码被篡改了，是不是呢？

当然也不排除别的可能性。然而首先就应该核查 ud 区的代码究竟怎么被改动了，是不是？可是你们完全不做这个基础工作，本来能定位、能缩小范围的事情，却不能定位，啥都确定不了。这样的报告是很糟糕的，会让开发者无所适从，多浪费很多精力，多做很多无用功。

不点

红毛樱木 发表于 2018-1-27 09:56
不知道这个有没有用。
他用bootice备份的mbr
里面两个文件：

我不会去检查的，我只提供思路。检查病毒修改了哪些字节，是你们自己的事，这不难做到，不需要开发者介入，而且我也脱离项目的维护了。

不过我刚注意到你不是回复我，而是回复 yaya。抱歉。

不点

红毛樱木 发表于 2018-1-27 10:25
退一万步说，即使真的如你所说是病毒攻击修改。但是这个U盘的情况是可以通过修改grub4dos的代码来避开的 ...

假如 fat 分区 bpb 和 fat 确实被修改了，yaya 通过改进 grldr 就能适应。

假如是病毒攻击了 ud 区的引导代码或者 ud 区的 grldr 文件本身，yaya 根本就没法下手。

两个都是假如，看明白了吗？

您得排除其中的一个假如的情况，缩小范围，好让 yaya 去开展工作啊？是不是？


确实，我不能够说，我说它有病毒，那它就有病毒。我说的当然不算数。真理也不是掌握在我手上。

但是，ud 区被篡改了，这是你们自己暴露出来的，这能怪我吗？你们自己说的，只要重建 ud 区，一切正常。

那这算不算是病毒破坏呢？在我看来就是病毒，或者等价于病毒。

你不认为是病毒，那它遭到的破坏，总是存在的。比如说，你们使用某个工具来挂载 ud 区的文件。这个工具就有可能出现 bug，导致 ud 区被破坏。

还比如，某些 cgi 或 ghost 工具，也有可能写入引导区，破坏 ud 的代码或数据。

红毛大人记不记得？wee 当初是 63 扇区，后来为什么瘦身改成了 62 扇区？那是因为 Ghost 工具会毁掉末尾的扇区！没办法，只好让 wee 瘦身！

报告者很伟大！他确定了问题的根源，告诉了我这些细节，让我能够通过瘦身躲过了这个问题。

如果红毛大人也做个那样的报告者，那该多好啊！

不点

红毛樱木 发表于 2018-1-27 11:09
假如 fat 分区 bpb 和 fat 确实被修改了，yaya 通过改进 grldr 就能适应。----------------------------- ...

但愿如此。那就太简单了，对于一个开发者来说，很容易通过调试找到症结。

但我的感觉却与你不同。我感觉它好像复杂得多，不像是这么简单的病毒行为。

你们回忆一下，当你们重建 ud 区的时候，它正常了。你们记不记得？此时 FAT 分区有改动吗？

如果 FAT 分区没有任何改动，它居然都正常了，那说明 FAT 分区根本就没破坏，推论——> 只有 ud 区被破坏这一种可能性了。

我提议你们做的另一个试验，你们也不做。那就是，从硬盘启动一个未被修改的 grldr，看看它能否访问 U 盘上有问题的 FAT 分区。如果能访问，那就像铁一样证明了 FAT 分区并未被破坏。如果同样不能访问 U 盘 FAT 分区，那也像铁一样证明了确实是 FAT 分区信息遭到了破坏。可惜这个简单有效的试验你们拒绝去做。

你不做这些试验，就凭空 “坚信” 某一种情况是所谓的 “事实”，而那 “事实”，有可能只是 “假象” 而已。人有可能被假象欺骗。

我从你们所提供的哪些 “种种迹象” 中，看不出能够排除 “FAT 未被破坏” 的可能性，看不出 “ud 区未被破坏” 的那种 “必然性”。也许你们掌握了别的情况不愿意透露。但我从你们已经透露出来的信息当中，实在看不出有什么理由和 “迹象” 能够排除 ud 区本身被篡改的可能性。


既然我们有办法直接证明 FAT 分区是否被破坏（通过从硬盘启动 grldr 来证明），那么，首先就应该做这个验证。这是排解 bug 的顺序问题。就是，容易确定的事情，要早早地确定，事先完成。而那些确定不了的，则靠后进行。你这顺序都搞错了，一上来就去按照 FAT 已经被破坏的情况去处理。万一 FAT 没被破坏呢，这不累死开发者了吗？为什么可以避免的情况，而不去避免呢？做这个试验又不是要你们付出什么巨大代价，举手之劳啊！

在能够轻易证明 FAT 是否被破坏的情况下，为什么不去证明呢？你如果证明了的话，这样就把目标锁定了，开发者也就有目标了，何乐而不为呢？你如果证明了的话，大家也都不会再去想各种五花八门的情况了，你有说服力了，就可以避免很多没有意义的讨论，以及避免互相扯皮了。

我也退一万步说，就算你蒙对了（即，最后表明确实是 FAT 信息被破坏），那你这个处理问题的步骤和顺序也是不对的，是不符合逻辑的。

不点

gy0715 发表于 2018-1-27 20:39
扇区是 6915f00 什么意思啊？

看到没有？在 ls 试图列出 NTFS 文件时，末尾也出现错误 “不协调的文件系统结构”。我猜，很可能文件都没列完就出错了！

NTFS 分区也损坏了吗？那它毁的东西也太多了吧？

试试从硬盘启动，不从 U 盘启动，保证硬盘上的 grldr 是未被破坏的。看看结果是否一样？

越来越接近谜底了……

不点

gy0715 发表于 2018-1-27 21:35
版本是2017-12-23 0.4.6a

看到没有？qemu 虚拟机竟然不能读出大扇区号，只能读小扇区号。怎么可能呢？要知道，正常的时候它是可以读大扇区的呀！

究竟可能是哪里不正常了呢？肯定是 grldr 不正常了，而不会是 qemu 的 bios 不正常了。qemu 的 bios 又没人动它，它怎会不正常？

那么，grldr 又怎会不正常了呢？这就该怀疑到 “ud 区的 grldr 本身已经被破坏了” 吧？是时候去验证一下了吧？给 qemu 挂上虚拟硬盘，用虚拟硬盘上的 grldr 启动试试，结果不就出来了？

不点

gy0715 发表于 2018-1-27 21:54
看不懂不点在说什么，也不懂怎么做

好的，我解释一下。

你的贴图表明，grldr 本身被破坏了。换句话说，是 ud 区已经不正常了。

如果 grldr 没被破坏的话，它肯定能够成功读取扇区，而不是 disk read error。

道理就这么简单。

因此，你需要用软盘或硬盘上的 grldr 来启动测试，看看 ntfs 和 fat 分区能否正常访问。

实在不会做？

你下载个 DOS 软盘镜像，把新版的 grub.exe 拷进去，然后，把它挂到 qemu 上（作为软盘），启动到 dos 命令行，敲入 grub 回车，然后访问 U 盘（也就是你的 hd0 盘，即，含有 ud 区的那个盘），看看两个分区 (hd0,0) 和 (hd0,1) 能否正常访问？

不点

gy0715 发表于 2018-1-27 22:11
1.对grldr的版本有要求吗？
2.用其它U盘启动，不知道如何进入grub2dos命令行
请多多指导

用我刚才给你的 DOS 软盘方案，最简单快捷，不需要安装 Windows。

你当然要用新版了，因为有新版，为何不用新版？

其实任何版本都行，只要保证 grldr 或 grub.exe 文件本身未被病毒破坏即可。


不知道 grub.exe 是啥？它就是 grub for dos 啊。它就是运行在 dos 下的 grub 啊。它就相当于后来的 grldr 的功能啊。

不点

其实没必要继续测试了，无论 FAT 分区是否被损坏，都不影响下结论，即，“ud 区肯定已经被破坏了”。确定无疑。

我觉得 yaya 终于 “解放” 了，不需要再费力去排解 “bug” 了。

节约点宝贵的时间和精力，去专心排解 “求道者” 报告的那个 bug 吧。已经好几天了，也没有见到更新，我猜可能不那么容易解决吧。

保重身体，要过年了，节日期间时间多，但键盘族最容易在节日期间累着。注意身体，多喝水，多吃点心。

不点

红毛樱木 发表于 2018-1-28 17:36
chkdsk之后失败。

失败？是谁失败？是 chkdsk 自己失败？还是 chkdsk 成功了，但 grldr 仍是无法访问 FAT 分区？

如果 chkdsk 失败，那说明 FAT 分区也被破坏了，破坏得严重。

你应该贴出 cat --hex (hd0,1)+1 的输出结果，这样好知道硬盘的 grldr 是否正常。它只要不出现 disk read error，就是成功。

另外，要从硬盘启动 grldr 才对。不可以从 ud 区用 chainloader 来启动硬盘上的 grldr。这是因为 ud 区已经被破坏了，已经不可靠了。

不点

红毛樱木 发表于 2018-1-28 15:08
本地硬盘启动grldr，结果一样，不能访问u盘的1号分区,分区为未知。
0号分区正常。
和ud引导结果一模 ...

也可能你的 grldr 是已经被损坏了的。

不点

红毛樱木 发表于 2018-1-28 19:27
请不要太主管的认为我的反馈无效

先比较一下 UD 区被破坏了多少个扇区。

如果不做这个工作，我估计没人愿意再来这里折腾了。

不点

我还有一个建议，你制作一个最小的能反应问题的 U 盘镜像，放在百度云盘上，让 yaya 亲自测试，这样你就可以彻底撒手不管了，后续的调试全由 yaya 一人完成。你可以看自己方便的时候弄一个测试镜像便可。一个月，或半年能弄好都行，不必着急。

我这只是建议罢了。我不知道你是否同意，也不知道 yaya 是否同意。

最后如果真能从中找到什么有价值的东西，我们获得进步了，那么开发者会感谢你，用户们也会感谢你。