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

红毛樱木

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

不点

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

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

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

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

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

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

求道者

不点 发表于 2018-1-28 20:48
我还有一个建议，你制作一个最小的能反应问题的 U 盘镜像，放在百度云盘上，让 yaya 亲自测试，这样你就可 ...

我觉得很对
从第一个扇区开始dd
完全复制整个磁盘


感觉现在测也只能是在瞎测
虽然为版区增加了活跃度（

不点

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

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

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

不点

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

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

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

红毛樱木

不点 发表于 2018-1-28 18:59
失败？是谁失败？是 chkdsk 自己失败？还是 chkdsk 成功了，但 grldr 仍是无法访问 FAT 分区？

如果 c ...

请不要太主管的认为我的反馈无效

红毛樱木

不点 发表于 2018-1-28 19:06
也可能你的 grldr 是已经被损坏了的。

很明显我换了grldr也不行。

不点

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

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

不点

红毛樱木 发表于 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 17:20
咳咳，都是大师，我是啥编程都不懂的中老年屌丝，我觉得chkdsk一下ntfs区修复下卷位图错误，说不定啊fat区 ...

chkdsk之后失败。

江南一根葱

咳咳，都是大师，我是啥编程都不懂的中老年屌丝，我觉得chkdsk一下ntfs区修复下卷位图错误，说不定啊fat区就正常了，

红毛樱木

2011yaya2007777 发表于 2018-1-27 22:03
比如启动windows，进入菜单：
1. windows 7
2. grub4dos

本地硬盘启动grldr，结果一样，不能访问u盘的1号分区,分区为未知。
0号分区正常。
和ud引导结果一模一样

求道者

很简单嘛
假如是对现在的数据状况感兴趣
就直接dd裸备份u盘所有写了数据的扇区
压缩发网盘
如果是对谁偷偷修改了ud感兴趣的话
那就只能一点一点排查了
这很麻烦
而且很有可能根本查不出问题所在
毕竟有可能是病毒
也有可能是异常的驱动或者工具
这可以弄个驱动丢win里然后出现类似操作时就提醒你
但是要人写这种东西
如果是g4d某个0day的洞
那就差不多是大海捞针了吧
难道也写个类似的东西放到g4d里 让他后台出log？
不过说不定这也是grub legacy的洞（一起治了？）
只是治标的话更简单

买个带写保护的U盘
没事写保护
病毒 异常 什么都能避免
只要避免写操作

不点

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

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

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

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

不点

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

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

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

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


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

gy0715

2011yaya2007777 发表于 2018-1-27 22:03
比如启动windows，进入菜单：
1. windows 7
2. grub4dos

1.对grldr的版本有要求吗？
2.用其它U盘启动，不知道如何进入grub2dos命令行
请多多指导

不点

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) 能否正常访问？

2011yaya2007777

比如启动windows，进入菜单：
1. windows 7
2. grub4dos
选择2进入grub4dos环境。

或者从其他U盘启动，进入grub4dos命令行，再插入这个U盘，执行测试。

gy0715

2011yaya2007777 发表于 2018-1-27 21:51
按不点67#的方法，从硬盘的grub4dos命令行执行测试。不知是否可以做到？

看不懂不点在说什么，也不懂怎么做

2011yaya2007777

按不点67#的方法，从硬盘的grub4dos命令行执行测试。不知是否可以做到？

不点

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

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

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

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

gy0715

2011yaya2007777 发表于 2018-1-27 21:24
必须在2017-12-23 0.4.6a版本测试!!!
截图:
cat --hex (hd0)0x06915d14+1

谢谢

不点

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

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

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

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

越来越接近谜底了……

2011yaya2007777

必须在2017-12-23 0.4.6a版本测试!!!
截图:
cat --hex (hd0)0x06915d14+1
截图:
cat --hex (hd0,1)+1

gy0715

2011yaya2007777 发表于 2018-1-27 21:13
截图:
cat --hex (hd0)+1
截图:

谢谢

2011yaya2007777

截图:
cat --hex (hd0)+1
截图:
cat --hex (hd0)0x06915d14+1
截图:
cat --hex (hd0,1)+1

gy0715

2011yaya2007777 发表于 2018-1-27 20:31
1楼是2017-12-23 0.4.6a版本。请使用这个版本测试.

你再截图一张，扇区是 6915f00

谢谢

2011yaya2007777

1楼是2017-12-23 0.4.6a版本。请使用这个版本测试.

你再截图一张，扇区是 6915f00

gy0715

2011yaya2007777 发表于 2018-1-27 08:48
Re gy0715:
你使用1楼第1幅截图的环境，也就是说在grub4dos的命令行，分别执行以下命令，然后截图：
root ...

谢谢

freesoft00

做好的可以启动的U盘，把grldr备份出来，然后把分区表和fat分区的关键扇区也都备份出来。
等出现无法启动了。然后再备份出一份内容。
两次比较。应该就可以弄明白修改了哪里。

不点

红毛樱木 发表于 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 信息被破坏），那你这个处理问题的步骤和顺序也是不对的，是不符合逻辑的。

红毛樱木

不点 发表于 2018-1-27 10:49
假如 fat 分区 bpb 和 fat 确实被修改了，yaya 通过改进 grldr 就能适应。

假如是病毒攻击了 ud 区的 ...

假如 fat 分区 bpb 和 fat 确实被修改了，yaya 通过改进 grldr 就能适应。--------------------------------------------------------------此贴种种迹象表明就是这种情况

假如是病毒攻击了 ud 区的引导代码或者 ud 区的 grldr 文件本身，yaya 根本就没法下手。-----------------------------------------此贴种种迹象表明不是这种情况