关于KonBoot加载的疑问，感谢不点大大提示，我想了个办法，求鉴定！

captain_g

我的意思是：
1、U盘启动后root肯定是ud（未用过find --set-root等）；
2、konboot.img在ud区（无需用find --set-root等）；
3、在确定u盘是hd0的情况下（启动时按c后用find查看的）；
4、执行if "%@root%"=="(ud)" && calc *0x82a0=*0x82b9&0xff后；
5、实际上查看到的是"%@root:~1,1%"=="u"，并不是=="h"；
6、也即：if "%@root:~1,1%"=="h" && map (hd0) (hd1) && map (hd1) (hd0)这句应该不会执行，(hd0) (hd1)并没有交换；
7、问题来了：为什么最终进的是硬盘而不是U盘？

是我理解不透或错了？还是手工输入与在菜单中使用那两行有可能会出现不同结果？还是那两行有潜在问题，成功有偶然因素？

本人小白，没用过这样复杂且深的方法，尝试一下，想了解透一点而已。

G4D的帮助文档中说这一句：if "%@root%"=="(ud)" && calc *0x82a0=*0x82b9&0xff 的作用是：如果当前ROOT是(ud),设置当前磁盘为(ud)所在磁盘，比如(fd0)或(hd0)，

也就是说在ud启动的情况下，这时，"%@root:~1,1%"应是"h" 或 "f"

zyphio

captain_g 发表于 2015-3-10 15:05
我的意思是：
1、U盘启动后root肯定是ud（未用过find --set-root等）；
2、konboot.img在ud区（无需用fin ...

我也小白啊，确实你的思路没错，确实存在这个有趣的问题。

不过发现我自己的理解居然与G4D帮助文档里对第一个if句的解释是一样的（哈，我之前没看过这帮助哩）。

但有一点，root设备和boot设备不是一回事！不点大大前面提到改进就是想确保boot设备可被用户容易且准确识别好管理。

我都是把konboot.img外置到U盘常规分区上的，再find这img后root不会是u类，可能会是h\f\c等类型，实际上查看到的是"%@root:~1,1%"确实为"h"类，map交换有生效；。

谢谢哦，晚上再研究研究。

captain_g

chiannet 发表于 2015-3-9 20:29
捣鼓成这样可否？

我捣鼓成下面这样，测试均成功（UD启动后U盘被识别为hd0或fd0）！

title  KonBoot2.4绕过登录密码
map --mem ()/boot/konboot.img (fd0)
if "%@root%"=="(ud)" && set /a xyz=*0x82b9&0xff
if %xyz%==128 && map (hd0) (hd1) && map (hd1) (hd0)
map --rehook
chainloader (fd0)+1
rootnoverify (fd0)

或者

title  KonBoot2.4绕过登录密码
map --mem ()/boot/konboot.img (fd0)
if "%@root%"=="(ud)" && set /a xyz=*0x82b8&0xff00
if %xyz%==32768 && map (hd0) (hd1) && map (hd1) (hd0)
map --rehook
chainloader (fd0)+1
rootnoverify (fd0)

你的也是成功的，改动的出发点见#29、31。

zyphio

captain_g 发表于 2015-3-11 12:42
我捣鼓成下面这样，测试均成功（UD启动后U盘被识别为hd0或fd0）！

title  KonBoot2.4绕过登录密码

发现之前一直在绕弯路，总把问题复杂化：

本意——

只要确认是从这个设备上启动Konboot，要被Konboot引导的Win/linux/MAC OS在另一个硬盘上，而这个启动设备占用了(hd0)，就交换(hd0)和(hd1)。

那么——

1.不用管启动盘是什么硬件设备，无论U盘、USB/eSATA移动硬盘、光盘、ZIP驱等。
2.不用管启动后或者find后，root是什么，是ud也好，是fd0也行，是常规的分区也罢。
3.直接检查启动Konboot的设备所在的驱动器是不是被BIOS认为(hd0)，一行命令去确认就行了，是的话，就交换(hd0)和(hd1)后听天由命去：

title KonBoot
        find --set-root /konboot.img
        map --mem /konboot.img (fd0)
        checkrange 0x80 calc *0x82b9&0xff && map (hd0) (hd1) && map (hd1) (hd0)
        map --hook
        chainloader (fd0)+1
        rootnoverify (fd0)

这样少事也好理解，求高手鉴定。

不点

zyphio 发表于 2015-3-11 15:05
发现之前一直在绕弯路，总把问题复杂化：

本意——

你好像掉进漩涡了——开个玩笑。

82b9 处是 fb_status 的一个字节。假如不是从 ud 启动，这里的字节都是 00，无意义。

因此，假如不是从 ud 启动，你就不该访问这里的字节。

captain_g

zyphio 发表于 2015-3-11 15:05
发现之前一直在绕弯路，总把问题复杂化：

本意——

checkrange 0x80 calc *0x82b9&0xff && map (hd0) (hd1) && map (hd1) (hd0)

这一句在UD优盘启动的情况下，可能没问题，*0x82b9与0xff按位与运算后得到可能是0x80或0x0;

如果是普通U启的情况，0x82b9的右两位，很可能不是80，即*0x82b9与0xff按位与运算后可能经常得不到0x80！而这时0x8280和0x82a0却是80！

在这种情况下，可能应该使用 checkrange 0x80 read 0x8280 && ...

或者

checkrange 0x80 read 0x82a0 && ...

zyphio

captain_g 发表于 2015-3-11 15:34
checkrange 0x80 calc *0x82b9&0xff && map (hd0) (hd1) && map (hd1) (hd0)

这一句在UD优盘启动的情 ...

哦，原来这样，那就再加这句在后面：
checkrange 0x80 calc *0x8280&0xff && map (hd0) (hd1) && map (hd1) (hd0)

有可能*0x82b9与*x8280或*0x82b0后来两位同时是80的情况么？即不点大大#21楼提到的，用户不容易准确得BIOS层面的启动盘盘号。

captain_g

我在真机上试了，如果是普通U启（无UD、未量产、未分区），在命令环境下：
read 0x8280 或 read 0x82a0，它们的value都是0x80(当然也可能是0x0吧)，
我不知道这个有没有普遍性，道理只能由 不点 来解释了。
也就是说没必要再做*0x8280&0xff运算了，不如直接：
checkrange 0x80 read 0x8280 && map (hd0) (hd1) && map (hd1) (hd0)（没试过，初学不知语法对不对）

zyphio

不点 发表于 2015-3-11 15:23
你好像掉进漩涡了——开个玩笑。

82b9 处是 fb_status 的一个字节。假如不是从 ud 启动，这里的字节都 ...

谢谢老大，我只是一直在思考你24#说的，写法能不能好理解一些，好像还是不行，还是得像您#21楼说的那样，等用户可以方便通过某个命令得知BIOS真实启动设备再说了。

zyphio

captain_g 发表于 2015-3-11 16:06
我在真机上试了，如果是普通U启（无UD、未量产、未分区），在命令环境下：
read 0x8280 或 read 0x82a0， ...

试过直接检测0x8280，但宿主为hd0的ud启动后，这个的值是0x23，即还是ud，所以这个判断不会交换(hd0)(hd1)，达不到效果。

zyphio

captain_g 发表于 2015-3-11 12:42
我捣鼓成下面这样，测试均成功（UD启动后U盘被识别为hd0或fd0）！

title  KonBoot2.4绕过登录密码

刚虚拟机下试了，才突然发现，这样有一个问题，从U盘常规分区下启动，U被识别为(hd0)了，但第一个if句没生效，xyz变量没赋值，第二个if也无法生效，这样根本没交换(hd0)和(hd1)。

结合chreckrange命令，我改成这样：

title KonBoot
        find --set-root /konboot.img
        map --mem /konboot.img (fd0)
        if "%@root%"=="(ud)" && calc *0x82A0=*0x82b9&0xff
        checkrange 0x80 read 0x82a0 && map (hd0) (hd1) && map (hd1) (hd0)
        map --hook
        chainloader (fd0)+1
        rootnoverify (fd0

这样，konboot.img在U盘上——
若是ud启动，则if句把root设备定义为ud的宿主设备，检测root设备是否是(hd0)；
如果不是ud启动，if句没生效，直接检测root设备是否是(hd0)。

至少比前面直接检测root设备是否是h类更细颗粒化一些。

captain_g

刚刚我又手工重试了一下#23楼chiannet的菜单，没有再现我在#29和#31楼提到现象，原因可能是我昨天手动输入有误。

那几句与grldr本身内置的菜单命令相仿，内置的菜单命令已经过无数人这么久的使用，应该是没有问题的。

总结：UD U启的菜单命令 与 普通U盘 U起的菜单，是很难做到一单通用的，应该根据不同的情况分别拟写，以确保正确、成功。

还有，我在#33楼提供的菜单示例，只能用于UD U启方式。如果要用在普通U盘 U起的情况下使用，应做修改（可参见#36、#38楼）。

zyphio

zyphio 发表于 2015-3-11 16:30
刚虚拟机下试了，才突然发现，这样有一个问题，从U盘常规分区下启动，U被识别为(hd0)了，但第一个if句 ...

另外，改成0x8280更符合逻辑一些，因为万一konboot.img在别的盘呢。

我们知道从U盘（可能是常规分区、UD分区）启动，0x8280才是boot device，即是U盘，可能被BIOS识别为ud、fd、hd、cd等。

假如，是从U盘常规分区启动后，我从内置硬盘(hd1)的任意分区找到konboot.img，载入，0x82A0处root device已经变了，成了内置硬盘(hd0)，如果用082a0的值去检测，就无map交换了！

所以，上面我再修改为：

title KonBoot
        find --set-root /konboot.img
        map --mem /konboot.img (fd0)
        if "%@root%"=="(ud)" && calc *0x8280=*0x82b9&0xff
        checkrange 0x80 read 0x8280 && map (hd0) (hd1) && map (hd1) (hd0)
        map --hook
        chainloader (fd0)+1
        rootnoverify (fd0)

zyphio

captain_g 发表于 2015-3-11 17:02
刚刚我又手工重试了一下#23楼chiannet的菜单，没有再现我在#29和#31楼提到现象，原因可能是我昨天手动输入 ...

我曾经也认为可能是你录入手误，但想想也有万一，看来我们都得仔细点，请帮我鉴定一下43#的想法，可以么？

captain_g

zyphio 发表于 2015-3-11 17:06
我曾经也认为可能是你录入手误，但想想也有万一，看来我们都得仔细点，请帮我鉴定一下43#的想法，可以 ...

注意啊！
G4D帮助文档中说：
使用 boot 或 configfile 命令会改变启动设备（即0x8280的值）。

zyphio

captain_g 发表于 2015-3-11 17:07
注意啊！
G4D帮助文档中说：
使用 boot 或 configfile 命令会改变启动设备（即0x8280的值）。

所以，这适用于开机后没执行过boot，还有配置文件在U盘上的情况。

小白滴偶，能否把你说的G4D帮助文档给个链接我看看？

zyphio

captain_g 发表于 2015-3-11 17:07
注意啊！
G4D帮助文档中说：
使用 boot 或 configfile 命令会改变启动设备（即0x8280的值）。

其实仔细想想，无法回避一切可能，即使是使用0x80A0的值，也容易遇到find、root等命令的修改啊

结合chreckrange命令，我最新改成这样，一来至少比之前直接检测root设备是否是h类更细颗粒化一些，二来适应从U盘UD分区或常规分区启动，三来支持从其他设备载入konboot.img（只要相对路径正确）。

使用0x8280位置的前提启动后没有执行过针对其他驱动器的boot或configfile命令。

title KonBoot
        if "%@root%"=="(ud)" && calc *0x8280=*0x82b9&0xff
        checkrange 0x80 read 0x8280 && map (hd0) (hd1) && map (hd1) (hd0)
        find --set-root /konboot.img
        map --mem /konboot.img (fd0)
        map --hook
        chainloader (fd0)+1
        rootnoverify (fd0)

不点

如果不是 ud 启动，那当然比较容易做了。此处我就不想再重复说了。

关键就是 ud 启动时，用户不能方便地获得原始的 bios 启动盘盘号（00h 或 80h），所以，才有这样一些问题的出现。虽然说用一条菜单语句可以完成这个检测，但是，这个方法不容易被初次接触的人理解和掌握。所以，我觉得这有改进的余地。改进的目的是让 grub4dos 的用户更容易理解和掌握。

对于开发者来说，可以仔细研究这个问题能否改进以及如何改进。

对于用户来讲，假如开发者由于某种原因（或者某种权衡）没能采取任何改进措施，那么用户应该学习有关 ud 的一些知识，理解那些变量的意义，写好自己的菜单。

另外，有些用户其实是可以避免使用 ud 的。zyphio 曾经谈到，他自己使用 ud，只在 ud 区放置一个 grldr 文件，其他文件都在可见区。一句话，zyphio 不需要 ud 的隐藏功能。既然如此，我觉得 zyphio 可以用我去年开发的 multimbr 来代替 ud，这样就不会出现上述所讨论的那些与 ud 有关的问题了。

zyphio

不点 发表于 2015-3-11 17:49
如果不是 ud 启动，那当然比较容易做了。此处我就不想再重复说了。

关键就是 ud 启动时，用户不能方便地 ...

谢谢不点大大，我确实太小白了，菜鸟一个，纯纠结啊。。哈。。。

我觉得启动盘首要因素是兼容性，其次才是安全、功能、效率等，那multimbr？！是不是类似fbinst引导扇区的功能？搜索了一圈没找到，望大大能提供个下载链接与帮助文档，我想好好学习一下。

zyphio

不点 发表于 2015-3-11 17:49
如果不是 ud 启动，那当然比较容易做了。此处我就不想再重复说了。

关键就是 ud 启动时，用户不能方便地 ...

找不到啊，求multimbr，thanx

不点

zyphio 发表于 2015-3-11 18:56
谢谢不点大大，我确实太小白了，菜鸟一个，纯纠结啊。。哈。。。

我觉得启动盘首要因素是兼容性，其次 ...

http://bbs.wuyou.net/forum.php?mod=viewthread&tid=320244

captain_g

zyphio 发表于 2015-3-11 17:13
所以，这适用于开机后没执行过boot，还有配置文件在U盘上的情况。

小白滴偶，能否把你说的G4D帮助文档 ...

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

captain_g

zyphio 发表于 2015-3-11 17:33
其实仔细想想，无法回避一切可能，即使是使用0x80A0的值，也容易遇到find、root等命令的修改啊

结合ch ...

如果是【UD U启】，还是建议你按#23、#28楼的示例来拟制菜单。
菜单内置到UD中的GRLDR中或放置中UD中。
强力建议你将konboot.img放在UD区中，lzma压缩后也就 几K 到 十几K，可以避免搜索。
这个比较可靠，因为 0x82b9、0x82b8 的值好像不随 root, find --set-root, boot, configfile 操作而改变。

当然了，在实际使用中，如果你需要使用 konboot.img 去绕过登录密码，估计也不会跑一大圈才来。

我以前使用简单笨拙的方法，写了两个菜单选项，一个针对U盘为 hd0 的情形，另一个针对为 fd0 的情形。在前一个中用fallback指向后一个，如果失败则自动切换到后一个。如果不怕死循环，就在后一个中再用fallback指向前一个，操作时随便按那一个！

zyphio

captain_g 发表于 2015-3-11 21:06
如果是【UD U启】，还是建议你按#23、#28楼的示例来拟制菜单。
菜单内置到UD中的GRLDR中或放置中UD中。
...

好的，谢谢你哈，我也研究研究。

zyphio

captain_g 发表于 2015-3-11 20:30
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=185938&extra=page%3D1

呃，好久前就有下载了，没仔细去学习，我X。。

zyphio

不点 发表于 2015-3-11 20:08
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=320244

谢谢不点大大，喜欢算扇区，我去研究研究

zyphio

今天重新看了一下不点大大21#楼的想法，结合C大大前几天回答我关于find命令应用的疑问，我突然有了新的点子，重新写了此菜单，虽无什么复杂技术，但精妙之处有二，一是尽量完美的解决Konboot加载交换hd的的问题，二来保证只从grldr所在“设备”（即使是不同分区）上读取外置菜单和Konboot镜像等文件，同时兼容UD！

grldr内置菜单：

1. errorcheck off
   
2. set /A firstbd=*0x82a0
   
3. configfile /boot/menu.lst
   
4. if "%firstbd%"=="0x23" && set /A firstbd=*0x82b9&0xff
   
5. find --set-root /boot/menu.lst checkrange %firstbd% read 0x82a0 && configfile /boot/menu.lst
   
6. echo Can't find the configuration file form the first boot device.
   
7. pause Press any key to continue...
   
8. errorcheck on

复制代码

menu.lst外置菜单：

1. title KonBoot
   
2.         map --unmap=0:255
   
3.         map --rehook
   
4.         find --set-root /boot/konboot.img checkrange %firstbd% read 0x82a0
   
5.         map --mem /boot/konboot.img (fd0)
   
6.         map --hook
   
7.         if "%firstbd%"=="0x23" && set /A firstbd=*0x82b9&0xff
   
8.         if "%firstbd%"=="0x80" && map (hd0) (hd1) && map (hd1) (hd0) && map --rehook
   
9.         chainloader (fd0)+1
   
10.         rootnoverify (fd0)
    
11. 
    
12. title Windows Version 5 PE (32bit)
    
13.         map --unmap=0:255
    
14.         map --rehook
    
15.         find --set-root /boot/win5pe32.iso checkrange %firstbd% read 0x82a0
    
16.         map --mem /boot/win5pe32.iso (0xff)
    
17.         map --hook
    
18.         chainloader (0xff)
    
19.         rootnoverify (0xff)
    
20. 
    
21. title DiskGenius (DOS)
    
22.         map --unmap=0:255
    
23.         map --rehook
    
24.         find --set-root /boot/dgdos.img checkrange %firstbd% read 0x82a0
    
25.         map --mem /boot/dgdos.img (fd0)
    
26.         map --hook
    
27.         chainloader (fd0)+1
    
28.         rootnoverify (fd0)

复制代码