再次修改标题！！新版的grldr已经解决了在某些联想老主板上与KON存在内存冲突的问题

zjzaog

新版的grldr已经解决此问题！以下内容成为过去时了……只要升级就ok！！特别感谢勤勉的grub4dos的团队！
【新版的grldr与KON不兼容，启动的时候提示内存不足，换成老版本的却可以用！但是没有VBE的漂亮换面，纠结啊～～】
【----具体的状况请看#86楼拍的图，对比7-14和3-22的图请看#101楼】
【暂时替代方法：1、可以结合memdisk使用；2、也可以通过FBINST调用7.14版的GRLDR，再通过7.14版的GRLDR调用KONBOOT，】
【现在只要升级就可以。】

原帖由 不点 于 2012-3-25 17:06 发表
map 前，内存顶部的 EBDA 占用 1K。

map 后，由于 grub4dos 仿真代码占用 12 K，所以，常规内存顶部总共占用 13 K。

0x280 = 640
0x273 = 627

两者相差 13 K，正常。

0xA0000 - 13×1024 = 0x9CC00

这说明，map 后用户可以使用的常规内存的结尾位于 0x9CC00。

但是，konboot 却报告只有 9B400 的可用常规内存，因此，它自己占用了 6 K 的常规内存。 正是这个占用，导致了问题。它占用内存的同时，还修改了 int 15。它应该修改错了。int15 很复杂，一不小心就要出错。有理由怀疑，konboot 没弄好。

konboot 开源吗？如果开源，我们可以帮它找毛病。如果不是开源的，让其作者解决问题。

[ 本帖最后由 不点 于 2012-3-25 17:15 编辑 ]

原帖由 幸运的草 于 2012-3-25 20:21 发表
回复 #63 zjzaog 的帖子


通过不点的分析，可以判断是由于新版GRLDR对常规内存进行了控制，KONBOOT与之有内存的冲突。
知道问题所在，可采以下取变通方法加以解决。(该方法只对FB制作的U盘，对其他方式不适用)

----------------------------------------------------------------------------------------------------------------------

　下载7.14版的GRLDR，改名为KONBOOT或其他名。修改改名后的grldr内置菜单，在内置菜单中调用KONBOOT。
　　修改FBINST菜单，在FBINST菜单中调用这个改名后的GRLDR（7.14版）。

　　即通过FBINST调用7.14版的GRLDR，再通过7.14版的GRLDR调用KONBOOT。

原帖由 不点 于 2012-3-26 06:56 发表

个人发表一点揣测性意见：

konboot 有可能建立了一个 int13 的虚拟内存盘。否则，它没必要驻留在常规内存。估计它应该像 grub4dos 以及 memdisk 那样，建立了内存盘。设计者自己设计了一套内存盘，与 grub4dos 步调不一致，产生冲突。尤其是，当它的 int15 代码有漏洞时，还间接地造成死机。

我觉得，作者完全可以优化他的代码，去掉他自己的内存盘。这样，他即不需要写 int13 磁盘仿真代码，也不需要写 int15 内存处理代码，当然还永远不会与 grub4dos、memdisk 等仿真程序造成冲突。

分析如下：

在 map --mem /konboot.gz (fd0) 时，已经把 konboot 的代码加载到软盘上了。他可以修改这个软盘的内容，来达到他的目的。

当然，如果他的程序需要接管键盘输入之类的，那他还是需要另外开辟内存使用区，从而自己处理 int15。

===============

当有人发现 grub4dos 的 int15 有错误时，我们可以纠正。

但是，当任何人都不能发现错误时，那怎么可能纠正呢？

总得有错，才能纠正吧？

代码是开源的，任何人都可以检查。

特别是，konboot 的作者也一定可以检查。如果他发现了 grub4dos 的 int15 代码的毛病，相信他一定会给出报告，甚至直接给出补丁。

所以，这个问题可以先放在这里不管它了。等待 konboot 的作者给出结果。

[ 本帖最后由 不点 于 2012-3-26 14:58 编辑 ]

原帖由 不点 于 2012-3-29 05:35 发表
回复 #101 zjzaog 的帖子


这次终于找到毛病了，功夫不负有心人，很棒。

map 后，kon 还没开始运行，但 3 月 22 日的已经少掉了关于 9C800 - 9F800 这一段的描述。

要是早贴这个图多好，一下子就找到毛病了，不用浪费这么多的楼层。

原帖由 zjzaog 于 2012-3-29 20:54 发表
在时空看到不点大师上传的新版的grldr已经解决了这个问题，大家只要升级就ok，估计不久就能放出新版！完美，这贴可以关了，哈哈

3月29日的GRLDR，测试通过。没有发现与KON冲突。
测试菜单，没有使用多余的参数
map --mem /konboot.gz (fd0)
map (hd0)  (hd1)
map (hd1)  (hd0)
map --hook
chainloader ()+1
rootnoverify (fd0)
大家再通过泛的测试，(非memdisk方式)，看是否有问题。

[ 本帖最后由 幸运的草 于 2012-3-29 22:00 编辑 ]


附件
2012-3-29 21:35
  下载次数: 2
grub4dos-0.4.5c-2012-03-29.7z.zip (251.66 KB)
  

[ 本帖最后由 zjzaog 于 2012-3-30 10:11 编辑 ]

szfhx

谢谢楼主！下载试试看！

2011aaaaa0808

原帖由 <i>zjzaog</i> 于 2012-3-27 09:07 发表 <a href="http://bbs.wuyou.net/redirect.php?goto=findpost&pid=2409715&ptid=207219" target="_blank"><img src="http://bbs.wuyou.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open(this.src);}" onmousewheel="return imgzoom(this);" alt="" /></a><br />
我用的一直是1.1的kon，嘿嘿<br />
我的常用的菜单式这样写的，所以不管U盘被认为zip或者hdd都能通用，<br />
<br />
map --mem (ud)/TOOLS/KON.lzma (fd0)<br />
map --hook<br />
chainloader (fd0)+1<br />
find --set-root --ignore-flopp ...

<br />


最经典的答案，不用解释

shwk88888

谢谢了，我再试试看，麻烦你们了

幸运的草

这个要具体看情况而定，如果你的U盘是HDD格式的，且BIOS也识做HDD的。GRLDR启动后，U盘是(hd0),硬盘是(hd1)，这时，如果不交换磁盘，就会出问题。黑屏的多。这是因为他要从U盘启动，而你的U盘没有硬盘的启动文件，就黑屏了。
　如果是ZIP，或者你的BIOS将U盘识别为ZIP，则启动后你的U盘是(fd0)，硬盘是(hd0)，这时则不需要交换磁盘。
　以上几楼给出的菜单，都是从以find来定交换磁盘的，这种情况可不分zip及hdd的情况，大部分情况下看似没问题，但特殊情况下，就会出错了。
　比如，你启动时加载了plbpt加速器。find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
　这个100%出错。接下来
　map () (hd0)
　map (hd0) ()
　map --rehook还会正确吗？

   当加载加速器后，如果是zip，原来的(fd0)为成了(hd0),原来的硬盘(hd0)变成了(hd1),多出来一个硬盘。而BIOS中检测的硬盘数是1并把这个参数传给了GRLDR，实际这时硬盘数为2；
　　　　　　　　　如果是hdd，原来的(hd0)仍为(hd0),原来的硬盘(hd1)变成了(hd2),向后出来一个硬盘。中间出现了一个空的(hd1)。BIOS中向GRLDR传的硬盘数参数是2，此时实际为3，中间多出来一个空的硬盘。
　所以find失效了。找不到硬盘启动文件。

[ 本帖最后由 幸运的草 于 2012-4-11 09:59 编辑 ]

dvd008

这个"坑", 硬盘,光盘等,菜单不一样

下面3个,可以在光盘,硬盘下使用

title 81 Boot KON.IMG
find --set-root --ignore-floppies /BOOT/KON.IMG
map --mem /BOOT/KON.IMG (fd0)
map --hook
chainloader (fd0)+1
map () (hd0)
map (hd0) ()
map --hook
rootnoverify (fd0)

title 82 Boot KON.IMG
find --set-root --ignore-floppies /BOOT/KON.IMG
map --mem /BOOT/KON.IMG (fd0)
map --hook
chainloader (fd0)+1
map (hd1) (hd0)
map --hook
rootnoverify (fd0)


title 83 Boot KON.IMG
find --set-root --ignore-floppies /BOOT/KON.IMG
map --mem /BOOT/KON.IMG (fd0)
map --hook
chainloader (fd0)+1
map (hd0)  (hd1)
map (hd1)  (hd0)
map --hook
rootnoverify (fd0)

zjzaog

试一下这个菜单吧，你的kon.img要放在根目录下的/tools/文件夹里
title [7] >>>>> KON <<<<< \n 传奇的绕过系统密码进入电脑的工具
find --set-root /tools/kon.img
map --mem /TOOLS/KON.img (fd0)
map --hook
chainloader (fd0)+1
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
map () (hd0)
map (hd0) ()
map --rehook
rootnoverify (fd0)

[ 本帖最后由 zjzaog 于 2012-4-10 23:21 编辑 ]

shwk88888

能有人做个grldr和kon和菜单配套的发上来吗，我下了好多个都没成功，包括五子登科最新版直接写入优盘，进入kon后都是黑屏，就没显示了，谢谢了

shwk88888

请问konboot不适用于硬盘有多个主分区的吗？我运行后就黑屏了，什么都没有

20120301

我在单位的一个老电脑上，用3月29日的GRLDR，成功绕过winxp，
之前只要运行konboot就蓝屏。
自己的电脑3个主分区konboot不支持

zhs509

哈哈 我的电脑好像不符合测试条件。。。

装了Win XP/7 双系统，用grub4dos引导的。。。

前几天U盘UD方式启动konboot，成功绕过winxp、win7 32位系统密码进入桌面(用的是官方免费版的konboot)

幸运的草

3月29日的GRLDR，测试通过。没有发现与KON冲突。
测试菜单，没有使用多余的参数
map --mem /konboot.gz (fd0)
map (hd0)  (hd1)
map (hd1)  (hd0)
map --hook
chainloader ()+1
rootnoverify (fd0)
大家再通过泛的测试，(非memdisk方式)，看是否有问题。

[ 本帖最后由 幸运的草 于 2012-3-29 22:00 编辑 ]

zjzaog

在时空看到不点大师上传的新版的grldr已经解决了这个问题，大家只要升级就ok，估计不久就能放出新版！完美，这贴可以关了，哈哈，成功后的memcheck如下

[ 本帖最后由 zjzaog 于 2012-3-29 21:09 编辑 ]

zhaohj

功夫不负有心人，可喜可贺！
关键的0x3000（12KB）找到了。

不点

这次终于找到毛病了，功夫不负有心人，很棒。

map 后，kon 还没开始运行，但 3 月 22 日的已经少掉了关于 9C800 - 9F800 这一段的描述。

要是早贴这个图多好，一下子就找到毛病了，不用浪费这么多的楼层。

zjzaog

谢谢不点大师的解答，请多注意身体……

[ 本帖最后由 zjzaog 于 2012-3-28 22:55 编辑 ]

zjzaog

这个版本的memdisk，把img或者iso虚拟进内存的速度快的惊人！！！竟然远远快于map --mem的速度，不知是什么原理？！
谢谢adef朋友

不点

非常好。

The int13 hook is off. The drive map table is currently empty.

这已经说明，旧的 map 都失效了。比如说，map --status 也未能列出 (fd0) 这个虚拟盘。

(fd0) 本身应该还是可以访问的，只是新的 grub4dos 已经认不出它是由先前的 grub4dos 建立的了，而认为它是 BIOS 建立的，或者是由别的仿真程序（例如 memdisk 之类）建立的，总之，是外来的，不认为它是 grub4dos 内部建立的。

这证明 kon 是采用第一种情况，与我的猜测一致。kon 采用第一种方式所营造的这个环境不安全，不如第二种方式安全（当然，前提是，它必须得处理好前面提到的那些相关问题）。

你提到的警告没有什么影响，通常可以忽略这个警告。

[ 本帖最后由 不点 于 2012-3-28 13:47 编辑 ]

幸运的草

经测试，KON可以在BURG下运行。无发现异常。

[ 本帖最后由 幸运的草 于 2012-3-28 15:56 编辑 ]

zjzaog

我测试一下，您说的”第一种情况下map --status 会显示不出…………“说一我试试看：
“第一种，紧接 grub4dos 的仿真代码之下，这是 kon 最有可能采用的方法。但是，如果此后又进入 grub4dos 的环境，则新的 grub4dos 环境有可能找不到前一个 grub4dos 在内存中放置的仿真程序了，因为 int13 以及 int15 可能已经被 kon 修改了，这样 grub4dos 就可能认为自己从前不曾在常规内存中安装过仿真代码。这种情况下，map --status 将显示不出先前的 grub4dos 所建立的虚拟磁盘（或虚拟光盘）。”

所以在手动输入
map --mem (ud)/tools/kon.img (fd0)
map --int15nolow=1
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
boot
在boot完kon.img后，就回到grub启动菜单哪里，然后按c进入命令行，再map --status了一下，有没有显示“先前的 grub4dos 所建立的虚拟磁盘（或虚拟光盘）”？我看不懂，只能晒图


另外顺便问一下，在我map --mem (ud)/tools/kon.img (fd0),回车之后，出现这样的警告，不知有什么影响
fat12 bpb found with 0xeb (jmp) leading the boot sector.
warning: bpb total sectors(2880) is greater than the number of sectors in the whole disk image (12). the int13 handler will disable any read/write operations across the image boundary. that means you will not be able to read/write sectors (in absolute address, i.e., lba) 12 - 2879, though they are logically inside your file system.
probed c/h/s = 80/2/18, probed total sectors = 2880

[ 本帖最后由 zjzaog 于 2012-3-28 13:25 编辑 ]

jianliulin

kon  也不能在burg下正常运行

不点

想到另外一个问题。

kon 在 grub4dos 之后驻留内存。那么，它自己的代码究竟是位于 grub4dos 的代码之下呢，还是位于 grub4dos 的代码之上？

无论哪种情况，都不安全。分述如下：

第一种，紧接 grub4dos 的仿真代码之下，这是 kon 最有可能采用的方法。但是，如果此后又进入 grub4dos 的环境，则新的 grub4dos 环境有可能找不到前一个 grub4dos 在内存中放置的仿真程序了，因为 int13 以及 int15 可能已经被 kon 修改了，这样 grub4dos 就可能认为自己从前不曾在常规内存中安装过仿真代码。这种情况下，map --status 将显示不出先前的 grub4dos 所建立的虚拟磁盘（或虚拟光盘）。

第二种，先把 grub4dos 的代码向下移动 6K，然后把空出的 6K 作为 kon 的驻留空间，并保证中断向量表中的 int13 和 int15 都指向 grub4dos 的代码（而不是指向 kon 自己的代码）。这种情况如果设计得很完美，将不发生任何冲突。但困难在于，很难设计完美，因为移动 grub4dos 的代码之后，还得修改 grub4dos 代码中的某些区域，这些区域是安装 int13 处理程序的时候就计算好的，与 int13 处理程序的代码所处的线性地址有关。如果 int13 代码被移动，那么，这些区域必须进行相应的修补，否则 int13、int15 处理程序就要发生错误。而且，一旦 grub4dos 的仿真代码发生改变，这种办法也就要受到影响了。

究竟是哪种情况？谁了解的，可以确认一下。

幸运的草

　　也不能说是KON钻了G4D内存管理的“空子”，G4D是大环境，KON是小环境，KON要想通过G4D的引导而运行，不管G4D在内存管理方面有BUG也好，无BUG也好，他必须要与之兼容。这就是老版的G4D运行KON没有问题的原因。
　　而新版G4D调整后，KON没有及时跟进或者是没有来得及发布新版，就出现了与新版G4D的不兼容，这是不可避免的。发布日期就说明这这一点。

　　因此，出现这种问题，本身就是正常的。双方谁都没有错。只是时间给我们开了一个玩笑。
　　

[ 本帖最后由 幸运的草 于 2012-3-28 10:51 编辑 ]

不点

我身体吃不消，不能长时间看代码。zw2312914 看到这个问题之后，主动承担起责任来。他很久没有露面了，大概也很忙。这次他看到 yaya 忙于 0.4.6，chenall 忙于 0.4.5，没有人管 int15 了，于是这个任务也就压到 zw2312914 自己的身上了。的确，也只有他适合处理此类问题，他很严谨，尤其在这方面很有经验。纵使我自己身体好，也不一定能找到 int15 的毛病，因为代码是我自己写的，通常自己是很难发现毛病的。换个人之后，才容易找到毛病。早在本帖报告之前，zw2312914 就在时空论坛提到 int15 的（可能的）毛病了，当时我还不以为然。他确实有一种特殊的敏锐。现在他正在寻找 int15 的漏洞，试图捉住潜藏的任何一个 bug，让 grub4dos 的 int 15 代码是 “ 强健的 ”、“ 坚韧的 ”、“ 可以信赖的 ” 和 “ 牢不可破的 ”。这同时也说明，这个问题是在认真处理、认真对待。开发人员很重视，是毫不懈怠的。我想，关注此贴的人，应该比较放心了。

zhs509

哈哈 或者可以这样认为

之前的grub4dos对内存管理方面一个bug，而konboot刚好由于grub4dos的bug而钻了空子。。。

幸运的草

说的不错，KON这个工具就是在G4D环境下的一个密码工具。他的使用环境就是通过G4D来引导的。最新版的是在2010.3.16日发布，这就是为何与新版G4D有冲突的原因。因为自2011.7.14以后，G4D进行变改才导致新版与之冲突。

　　因此，我们既不能把责任归咎于G4D，也不要归咎于KON，G4D没有错，他要发展就会进行变更。KON也没有错，他是根据G4D来开发的，新版G4D变更后，KON没有发布新版，老版的KON与G4D发生冲突也是不为过。

　如果谁对KON的作者比较熟悉，可以向其作者反映新版G4D的变化，相信KON的作者会进行调整。

目前的解决办法，可采取一些变通的办法。（见作者一楼）

adef

下测试版memdisk的人居然要多一点？
memdisk 4.06-pre3，今天的。

zjzaog

受教了，
这句话说的真好！“我的意思是说，这是一种理解，是当您以前不曾有过这种理解的时候，您可以考虑的、新增的一种理解。”

不点

拍照很辛苦。

看到没有 kon 参与的时候，read 0x413 得到的是 0x272，这就证实了先前的推测。有 kon 加入时，再次进入 grub4dos，read 0x413 得到的是 0x26c，这证明 kon 驻留在内存中，占用了 6K 的空间。

注意，这个情况本身就是在走钢丝，已经超出 grub4dos 的安全应用范围了。出现任何异常，都是不奇怪的。

grub4dos 的开发者们，最多也只能 “ 严于律己 ”，无法要求 kon 这个软件如何如何，因为这不属于 grub4dos 的开发人员的管辖范围。

如果开发者们无法从自身找到毛病，或者甚至能够证明自身没有问题，那这个问题也就无解（或者暂时无解）。

为了帮助诸位理解这个情况，我再补充几句。

不要以为 kon 以前能够运行，它就必然没问题。这个观念是不正确的。以前能运行，有可能是因为凑巧了，或者说，其潜藏的问题问题未暴露、未引爆而已，或者说是侥幸。哲学和逻辑很重要，往往能够揭示某些容易进入的误区。严谨的思维，这就是哲学和逻辑要教会我们的。在中国，“哲” 有 “聪明” 的含义。只有思维严谨，才会少犯错误，少走弯路。也才能明辨事理。真理都是相对的。以前 kon 能运行，也能配合 memdisk 运行，那说明，kon 这个软件没问题。注意，“没问题” 也是相对的。并非 “绝对没问题”。以前没问题，只是以前的条件、环境之下的一种表现。它可能只是 “ 表现得没问题 ” 而已。这个概念有点抽象，不太容易理解。

以上这是一种理解，但我的意思绝对不是说，只有这样理解才是正确的。我的意思是说，这是一种理解，是当您以前不曾有过这种理解的时候，您可以考虑的、新增的一种理解。这是一种可能性，而不是必然性。多一种理解，就多一种选择，就多一种思维，就多一种出路。有了这种新的理解，你就更灵活了。因为你的路子宽了。

我看到进入 kon 之后，还可以重新进入 grub4dos，那么新的 grub4dos 环境，已经处于不稳定状态了，因为已经有 kon 的代码参与到系统中了。这种不稳定状态究竟会表现如何，那只能碰运气了。运气好了，一切正常。运气不好，就发生死机。

我还可以猜测，kon 这个软件（的开发者）很可能包含了对于 grub4dos 以及 memdisk 等软件的特别 “ 优惠 ”。意思是说，开发者很可能针对 grub4dos 以及 memdisk 这类 “著名的” 软件而 “优化”，就是特别地给以 “支持” 和处理，使得它自己可以被 grub4dos 以及 memdisk 加载。它是如何支持 grub4dos 的呢？可能是这样的：它假定 grub4dos 一定会怎样怎样，然后在这样的假定之下来开发 kon 这个软件。当 grub4dos 发生变化之后，kon 对 grub4dos 的支持也就可能失去基础了。grub4dos 可能 “不知不觉” 地掉进 kon 的 “不支持条件” 之中，结果导致 kon 无法运行了。对于 kon 的开发者来说，他们不能预测 grub4dos 的变化，所以，他们没有责任。对于 grub4dos 的开发者来说，他们也不知道支持 kon 需要什么条件，因为 kon 的开发人员没有告诉 grub4dos 的开发人员有关 kon 的技术细节。所以，这是两张皮，谁都不负责任的。这个问题也就只能靠它自生自灭。说不定 kon 的作者会主动解决这个问题的，假定他们很希望支持 grub4dos 的新版本。

说得太多，不知道我说明白了没有。希望这些话能够有些用处。

幸运的草

还是内存冲突。
暂时无解。
采用变通办法运行吧。！