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

2011yaya2007777

请看看附件是不是需要的信息

不是
点“确定“后，出现新数据，光标一般位于x000处，鼠标左键点光标所在字节，按住不放，拖曳至x200以后，放开左键，点右键，保存数据。

你使用DiskGenius再截几张图。
usm（h：） 分区参数，浏览文件
usmesi(i:)    分区参数，浏览文件

2011yaya2007777

以前正常，后来不正常，说明与grub4dos无关。
1楼贴图反馈不能挂载所选分区，可能是：
1. MBR分区表有问题，通过他找不到BPB表；
2. BPB表有问题，grub4dos挂载分区时，判断某些参数，不符合要求时，放弃挂载，退出。

至于为什么DiskGenius可以识别，有可能他不判断某些参数。

gy0715

2011yaya2007777 发表于 2018-1-26 15:02
不是
点“确定“后，出现新数据，光标一般位于x000处，鼠标左键点光标所在字节，按住不放，拖曳至x200以 ...

。。。

不点

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 15:47
你搞错了吧？截取的是无用的扇区。

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

。。。

不点

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

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

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


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

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

2011yaya2007777

截取错了吗？

把“字节”变成“扇区”就对了。不用复制保存了，直接截图。

gy0715

2011yaya2007777 发表于 2018-1-26 18:55
把“字节”变成“扇区”就对了。不用复制保存了，直接截图。

。。。

2011yaya2007777

这次对了

chenall

像网上流传的那些大白菜，老毛桃之类的PE尽量少用，我有发现了好几起由于使用此类PE启动系统之后，系统引导被（修改）导致无法启动，还有插在电脑上的U盘里面的引导也被修改了。

红毛樱木

chenall 发表于 2018-1-26 21:41
像网上流传的那些大白菜，老毛桃之类的PE尽量少用，我有发现了好几起由于使用此类PE启动系统之后，系统引导 ...

ud能引导啊，这时候

dos时代菜鸟

应该是 分区表问题，我用 grub4dos 引导ubuntu .iso 文件 对硬盘的空余空间进行划分和安装ubuntu 以后，grub4dos 也会这样，可以 find 到文件,却不能 ls 和 使用分区上的文件。
我就怀疑是 ubuntu 安装时用的分区软件 把分区表 弄乱了，虽然也能用，但是，把grub 弄糊涂了。

2012zhd

chenall 发表于 2018-1-26 21:41
像网上流传的那些大白菜，老毛桃之类的PE尽量少用，我有发现了好几起由于使用此类PE启动系统之后，系统引导 ...

技术上的事我不懂，但是的确多次遇到把u盘插到某些电脑上以BIOS（grldr为主引导）启动pe后，再启动其他的电脑就不行了，用FbinstTool打开提示要修复什么的。efi启动倒是没受影响。后来干脆量产一个u盘应急。

红毛樱木

2012zhd 发表于 2018-1-26 22:25
技术上的事我不懂，但是的确多次遇到把u盘插到某些电脑上以BIOS（grldr为主引导）启动pe后，再启动其他的 ...

这个反馈的和你的不同，混淆了。
这个ud正常

窄口牛

遇到过，莫名其妙启动不了了，必须重写mbr，第一次以为自己操作硬盘点错，把优盘搞坏；后来不能启动，用bootice检查优盘还是g4d主引导，并没有被误操作改成nt6，说明不是自己主观所为。我说的和楼主不一样，无效插嘴。

不点

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

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

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

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

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

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

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


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

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

2011yaya2007777

Re gy0715:
你使用1楼第1幅截图的环境，也就是说在grub4dos的命令行，分别执行以下命令，然后截图：
root , geometry (hd0) , find , vol , ls (hd0)/ , ls (hd0,0)/ , ls (hd0,1)/

gy0715

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

。。。

红毛樱木

不点 发表于 2018-1-27 08:41
这个情况我早发现了。恶意软件偷偷写入引导区，即磁盘开头的若干个磁道，造成破坏。楼主的报告，本质上也 ...

严重了。
这里ud的引导正常，
(hd0,0)的NTFS访问正常，
(hd0,1)的fat32访问不正常。

2011yaya2007777

2013-04-19 0.4.5c版本。1楼是2017-12-23 0.4.6a版本。是同一个U盘吗？
这次 ls (hd0,1)/ 返回 “磁盘读错误”， 1楼却返回“不能挂载所选择的分区”。

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

红毛樱木

2011yaya2007777 发表于 2018-1-27 09:26
2013-04-19 0.4.5c版本。1楼是2017-12-23 0.4.6a版本。是同一个U盘吗？
这次 ls (hd0,1)/ 返回 “磁盘读错 ...

他现在出差了。不在。UD里有不同的GRLDR，是同一个U盘。

不点

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

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

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

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


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

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

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

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

红毛樱木

2011yaya2007777 发表于 2018-1-27 09:26
2013-04-19 0.4.5c版本。1楼是2017-12-23 0.4.6a版本。是同一个U盘吗？
这次 ls (hd0,1)/ 返回 “磁盘读错 ...

mbr.zip (2.97 KB, 下载次数: 1)

2018-1-27 10:00 上传

点击文件名下载附件

不知道这个有没有用。
他用bootice备份的mbr
里面两个文件：
1是默认的(备份扇区数：1)
63是选择备份扇区数：63

不点

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

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

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

红毛樱木

不点 发表于 2018-1-27 10:02
我不会去检查的，我只提供思路。检查病毒修改了哪些字节，是你们自己的事，这不难做到，不需要开发者介 ...

退一万步说，即使真的如你所说是病毒攻击修改。但是这个U盘的情况是可以通过修改grub4dos的代码来避开的，我期望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 10:49
假如 fat 分区 bpb 和 fat 确实被修改了，yaya 通过改进 grldr 就能适应。

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

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

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

不点

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

freesoft00

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