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

幸运的草

这个工具是要绕过windows登录密码直接启动系统。不知他采取什么技术。
我试过，7.14版前，确实能不要WINDOWS　XP的登录密码，在点用户名后就可以不要密码直接进系统。

不点

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 编辑 ]

zjzaog

不点大师，这是我的konboot启动画面，卡在这里。7月14日前后的版本都是这样显示的，但是7月14日前的版本能顺利进去。而之后的版本就卡死在这里

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

幸运的草

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

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

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

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

zjzaog

谢谢您，我试试看，不知道能不能加条什么命令就可以让grldr不对常规内存进行了控制

chenall

可以试试加以下参数
--int15nolow=1
--e820cycles=3
可以试试看

zjzaog

试了试这两个参数，还是不行，卡死了……，
我只能通过FBINST调用7.14版的GRLDR，这样子也就多用248kb的空间，弄成功了，总之谢谢各位的帮助。谢谢不点、chenall 、幸运的草等诸位大侠

不点

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

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 编辑 ]

幸运的草

KONBOOT原版是商业软件，是带加密狗的。由ISO和IMG版的。目前网络上流行的6KB的是破解并经修改过的。
这里有介绍：
http://hi.baidu.com/sprite_guo/b ... c2c6b3a50f52e9.html
所以，很难判断是原版就有的问题，还是修改版的问题。
知道了问题所在。解决办法（非GRLDR内部）已经不是问题了。

[ 本帖最后由 幸运的草 于 2012-3-26 16:54 编辑 ]

chenall

有没有人试一下用MEMDISK能不能启动

kernel /memdisk
initrd /konboot.img

chenall

有免费版的,我就是用免费版的,在我的电脑上可以正常使用.

http://www.piotrbania.com/all/kon-boot/index2.html#free

zhs509

确实有免费的。。。
好像免费版不支持win7，还没测试，昨天翻墙才下载下来。。。

[ 本帖最后由 zhs509 于 2012-3-26 17:16 编辑 ]

zhs509

vmware虚拟机测试没问题。。。

通过ZXW的RUN模块启动kon-boot绕过winxp 32位系统的密码

幸运的草

回复 #71 chenall 的帖子
回复 #72 zhs509 的帖子
刚下载测试了＃72的附件两个版本。ISO及IMG。

新版GRLDR，还是出现内存冲突的提示。看来是原版都与新版的GRLDR有内存冲突。

回复 #73 zhs509 的帖子
这个是早就证实的事。在VM中没有问题。

幸运的草

怎么把这个给忘了。多谢提醒。
刚测试通过。
菜单：
map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd1)
kernel /boot/imgs/memdisk
initrd /boot/imgs/konboot.img

[ 本帖最后由 幸运的草 于 2012-3-27 08:08 编辑 ]

zjzaog

请问哪个版本的memdisk最稳定？能给个下载的连接那？听说新版的不怎么好

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

幸运的草

我在百度找的，好像是最新版的，测试没问题。KON正常通过。

官方免费的KONBOOT是1.0版的。1.1版改成了商业软件，据说能绕过64位系统的密码。谁有条件测试一下6KB的1.1版的KON。看破解的版本能否绕过64位系统密码且不蓝屏，我这没有条件测试。
　　楼主附件的就是。

　　测试注意，如果是HDD的U盘，要保证启用硬盘为(hd0)，否则可能出问题。

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

adef

1.1的能绕过64位win7，巴基斯坦人发的那个。

zjzaog

我用的一直是1.1的kon，嘿嘿
我的常用的菜单式这样写的，所以不管U盘被认为zip或者hdd都能通用，

map --mem (ud)/TOOLS/KON.lzma (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 --hook
rootnoverify (fd0)

谢谢你的memdisk

=============
刚刚用memdisk测试，使用0.4.5c的grldr也能顺利进入系统！没有卡死
使用的菜单如下

title [8] >>>>> KON <<<<< \n 传奇的绕过系统密码进入电脑的工具
kernel (ud)/TOOLS/memdisk
initrd (ud)/TOOLS/KON.IMG
find --set-root --ignore-floppies --ignore-cd /ntldr || find --set-root --ignore-floppies --ignore-cd /bootmgr
map () (hd0)
map (hd0) ()
map --rehook

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

adef

77楼发的memdisk是4.04的，附件是memdisk4.05和4.06-pre2。

zjzaog

原帖由 adef 于 2012-3-27 10:24 发表
77楼发的memdisk是4.04的，附件是memdisk4.05和4.06-pre2。

memdisk的测试结果：
4.04 通过，顺利进入系统，使用的是0.4.5c的grldr
4.05 通过，顺利进入系统，同上
4.06-pre2 通过，顺利进入系统，同上

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

zjzaog

7.14以前的grldr和memdisk似乎比现在的grldr，对于这类软件的map的兼容性(或者容错能力)更强一点，这点的发展似乎背离了grldr的初衷。——仅仅我一个菜鸟的感觉而已，
========================
但是grldr的新功能的开发的发展，比如vbe等，非常棒，加油，这个只是过渡时期的小问题，深信grub4dos的开发团队。

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

不点

说说我的不同看法吧。

世界上没有完美的东西，没有万能的东西。

grub4dos 的发展、变化，一定有原因。今天由于变化而导致对某个软件造成影响，这并不奇怪。有可能世界本身就是不兼容的，就是不可兼得的。如果你很看重某个不被支持的软件，你可以舍弃新版，而继续使用旧版。你也可以使用其他间接方式（例如memdisk），达到你的目的。你甚至也可以放弃 grub4dos，而选择更适合你具体需要的、更方便的软件，这，都是应该鼓励的。

如果只有一个软件受到影响，这不足以说明问题。也不容易判断究竟错误在哪一方。

如果有很多软件都受到影响了，那么，我们获得的信息就多了，也就容易定位究竟是什么问题了。

我想，我试图谈论的，是 “ 大哲学 ”。但不知道我所谈的，究竟是对还是错，是好还是坏，以及能否被别人认可。

开发人员都很尽力，也很累。所以，如果有人牢骚，那没有用。如果有人故意给开发人员施加压力，那也是不受欢迎的。

为什么呢？因为这很浅薄。不等你来施加压力，开发人员往往自己就给自己施加了大得多的压力，因此你的压力，可能很浅薄，构不成压力，因而一般也就被无视了，像小儿科问题一样，被无视。我个人认为，真正聪明的办法，是设法给开发人员以帮助。假如你百思不得其解，很动了一番脑筋，仍然不知道如何才能给以帮助，那就说明这个问题你是帮不了的，或者，对你来说，这个问题是很困难的。在这样的困难面前，你选择那条路？对了，有 n 条路，其中之一，便是牢骚和埋怨。但正如我所解释的，这不是一个聪明的做法。你要是帮的了，相信你一定也会帮忙的，这是我们大多数人的想法。但是，帮不了的时候，却也往往容易陷入埋怨、指责的陷阱。对的，这确实是陷阱。当你看到刘翔或者某个乒乓球国手失败的时候，你也会埋怨。为什么呢？因为你很着急，而又没有能力帮他，所以，只剩下埋怨这一条路了。但是，埋怨本身，没有什么好处，不能对于解决技术问题有任何的帮助。

开发者需要的是有人伸出帮助之手，而不是前来索取的双手。

如果大家全都是索取者，那就没有 grub4dos，也没有 memdisk，等等，这些软件了。

以上就是个人的不同看法。当然，我的看法也只是一家之言，与其他任何人的看法一样，都是平等的，没有正确与错误、优与劣、好与坏之分。大家都是正确的，都是有道理的。

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

zjzaog

谢谢不点大师的指正，
看到时空上的帖子里开发人员确实很辛苦，令人敬佩。我深信这个问题在这样无私付出的团队里，肯定最终能被胜过！
我确实是略过了本质去看现象！所以只是从使用者的角度谈感受，因此肯定会有失偏颇。还望海涵。

如果不是从索取者的角度，而是从普通测试者的角度看我的所谓”感受“，也许会自然一些。呵呵，”7.14以前的grldr和memdisk似乎比现在的grldr，对于这类软件的map的兼容性(或者容错能力)更强一点，这点的发展似乎背离了grldr的初衷。——仅仅我一个菜鸟的感觉而已，“

我这样的说话方式如果太重了，那确实是我的错。

[ 本帖最后由 zjzaog 于 2012-3-27 12:59 编辑 ]

不点

你没错。即使你不说，别人也会说。你只是谈论了一种可能的思想而已。那不是你一个人的思想，而是代表着具有相同认识的一大批人的思想。任何思想，都是正确的。

我的谈论，也代表另一种思想。那也不是我一个人的思想，而可能是许多人的思想。

我前面用乒乓球国手来比喻，我觉得挺恰当。足球也一样。

zjzaog

今天再一次更详细的拍图，希望有所帮助，我用的是0.4.5c的grldr，我用fb方式启动，kon.img放在ud区，我的U盘识被别为我(hd0)，主机硬盘被识别为(hd1)，因此我在没有交换hd0和hd1的情况下，运行完kon.img会回到u盘，这样有一个好处，我可以在每一个阶段都memcheck一下并拍图下来，利于分析每一个步骤中内存的变化！！请不点大师、c大、各位版主等无忧的朋友仔细看看，或许有点帮助。
注意：有两处（1和6）是U盘的启动画面的图我忘了拍，不重要，就一个图片，所有我用虚拟机里截图代替一下，其他的图都是实机上的实拍，

1、首先是启动到这个界面，在实机模式下忘了拍图，不过不重要，所以我在虚拟里截图一下代替看一看


2、（接下来的都是实机上拍的图！）然后按c进入命令行模式，先运行memcheck看看，并且read两处重要的地方


3、在手动输入
map --mem (ud)/tools/kon.img (fd0)
map --int15nolow=1
map --hook
然后再一次memcheck看看，并且read两处重要的地方！


4、然后手动输入chainloader (fd0)+1，然后再memcheck一下，


5、再接再厉，精彩的在后面，还望看官坚持下去，^o^,
再手动输入rootnoverify (fd0),然后再一个memcheck看看，


6、再手动输入boot，出现kon.img的经典换面，然后发现回到了U盘的启动界面（这个图在实机理我没有拍，跟第一张是一样的，我在补一下图，不重要，）


7、这时kon.img应该已经起作用，按c命令行，然后memcheck，关键变化！！

8、按Esc退出，然后选择第一项，菜单内容如下
title [0] >>>>> LWS <<<<< \n 搜索并加载本地电脑上的Windows系统
find --set-root --ignore-floppies --ignore-cd /ntldr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr || chainloader /bootmgr

9、然后就死机了，请看图


当然如果我先交换了（hd0）和（hd1），就不会回到U盘启动界面而是直接从硬盘启动，但是也会死机，而且画面与9是一样的。我之所以不先交换而是让他回到U盘界面，是为了还可以memcheck一次，发现单单map --hook之后就memcheck，和boot之后memcheck是不同的，说明了kon.img起作用后，本身似乎对内存进行了修改！！但是，似乎单单map --hook前后memcheck的结果就有不同，所以……结果比较复杂。大家可以检查每两幅相邻的图里数据的变化，我觉得至少有两处，map --hook前后变化，boot前后变化

[ 本帖最后由 zjzaog 于 2012-3-27 18:03 编辑 ]

幸运的草

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

不点

拍照很辛苦。

看到没有 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 的新版本。

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

zjzaog

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

adef

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