up

无穷循环？

大概是一个虚拟机引擎。

虚拟机分析难度不小，还不如从引导扇区入手，总共才几百个字节，全部反汇编也没多少条指令。

和别的虚拟机不大一样，代码也不是很扭曲啊。

如果从引导扇区入手，也是很麻烦，要了解fat12,fat16,fat32格式

谢谢斑竹的解答

up.........

外层是UPX，从入口点开始便是VMP了。

等能够还原VMP的人来处理吧。

我还是先看看引导扇区，也许会有发现。

呆班主是最热心的斑竹。支持下。

把根目录下fbwtload.bin文件，偏移0x35-0x39共5个字节，全部改成0x90，即nop，应该就跳过了它对引导扇区的改写。

当然，前提是刚用软件生成可引导U盘，还没有用它进行过引导，所以引导扇区中的内容还是正确的。如果你用生成的U盘引导了一次系统，那么引导扇区里的内容就已经被修改了。

谢谢斑竹热心答复，这个我之前已经试过了。nop掉fbwtload.bin没有效果，因为
fbwtload.bin根本不会去调用dos的command.com

而作者又将fbwtload.bin放在一个十分令人郁闷的位置，使得用command.com的内容覆盖
fbwtload.bin也行不通。

如果从这方面入手，只有一个办法，就是自己写dbr，然后dos的启动文件一一放进合适的扇区(视不同的文件系统而定)。

再次谢谢斑竹的热心答复，不知道为什么我的peid没有显示出它里面又加了vmp，不然我就不用瞎弄几天了。

1.bootsect将自己从0000:7c00搬移到1feo:7c00，即物理地址27a00，然后跳到这1fe0这个段来执行。代码的功能是查找根目录下的fbwtload.bin，并将其载入到内存0060:0000处，即物理地址600处。

2.fbwtload.bin的功能是给27a0:jmp offset处写入字节0xfa,0xf4，即cli\hlt两条指令，然后27a0:0000处的一个扇区写回到磁盘。最后，它再将fbwtload.bin偏移0x548处开始的512个字节读入0000:7c00，并跳到那里执行。

而27a0:0000正是原来的bootsect，因FAT分区的第一扇区存放相关参数，所以有一条Jmp指令，而跳到jmp offset处开始执行。而fbwtload.bin的偏移0x548处开始的512字节是一个完整的bootsect，而且是原来OS的标准bootsect。

使用flashboot的向导配置的各种不同引导类型，就是将不同的引导扇区数据附加到fbwtload.bin的0x548处，实际向磁盘首扇区写入的只是前述的加载fbwtload.bin的代码。

3.我所说的偏移0x35-0x39一个字节，正是一条mov指令，即给原来的bootsect添加cli/hlt指令。将其nop掉，则它会将原来的bootsect写回，下次仍然可以引导。

也可以nop掉0x48-0x48三个字节，这三个字节是一条near call指令，调用写磁盘的函数。将其nop掉，则不将修改后的bootsect写回磁盘，也可达到“爆破”的目的。

4.你用command.com覆盖fbwtload.bin当然行不通，就算你用DOS的IO.SYS去覆盖也不行。因为fbwtload.bin的加载地址0060:0000既不是默认bootloader的加载地址，也不是command.com的加载地址，况且command.com加载之前的初始化都没有进行。

5.可引导U盘，原本就很简单，如果主板支持USB-FLP，就把FAT12/16的引导扇区写入即可。如果支持USB-HDD，则可以用FAT32。使用这个flashboot的软件没有太大意义。直接WinImage甚至WinHex就可以了。

十分感谢书呆彭斑竹的热心讲解。

我再去看一下资料。
flashboot还是挺不错的，因为其他的软件如usboot将大容量的U盘格成zip或hdd格式之后，在有些主板上无法引导成功，检查之后，发现是第一扇区被写成了mbr(带分区表)。而flashboot的却能引导成功(不带分区表)。

而fbwtload.bin的偏移0x548处开始的512字节确实是一个完整的bootsect，但是将其写入第一扇区依然无法成功引导——具体原因还要再看看 。

我在网上下载了个dos7.1的完整安装版，精简之后用winhex克隆进U盘，确实可以引导成功，但是U盘的容量却只有1.44M了。 。将这个dbr的bpb用flashboot的bpb覆盖，容量又回来了，但是又无法引导了——具体原因还要再看看 。

今天在电驴上找到了一个license
发上来。估计有用的着的人
license.rar

上传的附件：

• license.rar （1.34kb，15次下载）