[20190106]慧荣主控”免量产“自由划分多个驱动器（最多7个）

2011yaya2007777

你的理解很对。问题在于这个函数执行之前，传入的eax没有保存，被这个读容量函数破坏了。以后也没有见读出的容量减每磁道扇区数。

wuwuzz

2011yaya2007777 发表于 2023-2-1 14:58
请你再核实一下，#367的汇编代码中间有没有删减。如果没有，那就是源代码有缺陷。

代码没有删减。我的理解：

367# addEAXToTotalSectors: 之前的代码，应是中间过程，EAX存储的是“需要减少的扇区数”

ReadCapacity命令包执行后,得到U盘固有的总扇区数，

随后应该就有：固有的总扇区数-需要减少的扇区数    代码。

2011yaya2007777

返回数据格式，16G盘为：01 dd ff ff  00 00 02 00

请你再核实一下，#367的汇编代码中间有没有删减。如果没有，那就是源代码有缺陷。

wuwuzz

2011yaya2007777 发表于 2023-2-1 11:39
请教几个问题：
1. 隐藏或者显示MBR操作，传递的每磁头扇区数，似乎没有起作用。
2. 没有看出怎样增减 ...

YA大客气了，请教不敢当。

1、hide/unhide指令源于ZIP驱动器，是专用指令，绝大部分U盘主控固件不支持，
这些指令不会执行成功。比较例外的情况是群联主控固件U盘，它返回码正确，但不知
是真支持还是假支持，返回数据是否正确(我未找到ZIP指令返回数据格式和说明，所以
未知)

2、hddufiReadCapacity函数，
一是该函数以汇编形式实现SCSI读容量指令readcapacity包发送。
二是该函数也涉及CHS计算方面的内容。

3.ReadCapacity读容量指令的格式为：




例子：
返回数据格式，16G盘为：01 dd ff ff  00 00 02 00

4、汇编编程我就不太懂了。只是对IT有爱好。
hddreadcap.txt (7.26 KB, 下载次数: 11)

2023-2-1 13:28 上传

点击文件名下载附件
下载积分: 无忧币 -2

2011yaya2007777

最后，限制一下USB-ZIP的语意：

请教几个问题：
1. 隐藏或者显示MBR操作，传递的每磁头扇区数，似乎没有起作用。
2. 没有看出怎样增减的总扇区数。
3. 可否把hddUFIReadCapacity函数发给我。

test        ah, MBR_HIDDEN
jnz        done        ;        已经隐藏

movzx        eax, ch                 ; EAX = Sectors per head                  每磁头扇区数
neg        eax                                ; EAX = -(Sectors per head)        负值，减少总扇区数

addEAXToTotalSectors:        ; 增减总扇区数
; 传入的每磁头扇区数eax，似乎没有起作用
call        hddUFIReadCapacity        ; Get EAX, BX, CX, DI  读容量
jc        done                        ; If error, leave settings unchanged  如果出现错误，请保持设置不变

wuwuzz

另外，不点开发WEE的时候（他的想法是只用
LBA，规避CHS的影响）

我曾经表达这样一个观点：只要BIOS还在，
CHS就如影形随，回避不了。

即使你不用CHS，BIOS也要计算CHS。
这个时间点就在U盘枚举阶段，还没进入
启动时。

wuwuzz

bean在时空论坛开发fb时，我曾经见证。

我的理解是：
同一U盘，在不同BIOS下，算法不同，
对HS设定不同，fb为了应对这个问题而来。

前8M空间每个扇区都有引导代码，但剩余
扇区空间不利用起来就浪费了。为了有效
利用这个空间，出现fb文件系统。这个
文件系统客观上有隐藏效果，是副产品。

当然，后来我得到bios源码，接触到算法，
同时发现SMI盘固件特性，存在有效锁定
HS值可能，就不需再用fb的技术了。
这也是为什么后来我做简单的DOS启动盘，
不再使用FB的原因。

wuwuzz

求道者 发表于 2023-1-31 14:45
神舟主要从蓝天那里拿货吧，他主要是贴牌。
他估计也不会改BIOS。

BIOS估计不是这样。
因为出来的Phoenix bios源码来源就是神舟。
它应该是花钱买了。

2011yaya2007777

说得对，创建UD的初衷，是为了BIOS采用CHS模式读U盘的兼容性。之后随着CHS读取模式逐渐退出历史舞台，这个作用就被淡化了。绝大多数帖子里提到的都是他的隐藏功能。像不会被误格式化，放点私活呀什么的。

求道者

2011yaya2007777 发表于 2023-1-30 09:57
现在分析一下神舟K470 phoenix BIOS启动U盘的情况：
经过BIOS自己的判断，认为U盘是可移动介质，因此 ...

UD的主要目的不是为了隐藏吧，是为了把最容易被BIOS读取的那段空间给引导程序用，然后顺便做了隐藏，包括前64扇区的引导记录也是为了兼容，我记得是这样。

求道者

wuwuzz 发表于 2023-1-31 13:18
这个我与层主意见不同。我能理解K470 USB-HDD出现的这种“异常”，也能理解YAYA的分析。
这不一定是技术 ...

神舟一般从蓝天那里拿货吧，他主要是贴牌。
他估计也不会改BIOS。

wuwuzz

求道者 发表于 2023-1-31 09:10
BIOS会做这么无聊的事情吗？
无聊到了一定的地步。
这么说在启动的这一阶段除了第一分区之外的扇区都被 ...

这个我与层主意见不同。我能理解K470 USB-HDD出现的这种“异常”，也能理解YAYA的分析。
这不一定是技术上的整活搞无聊事情，而更像是固定模式用错了地方。

一、很显然Phoenix有完整的USB-HDD启动模块（如联想F31A机上的，这个后面再详谈）。
但OEM给神舟K470机的显然功能不完整，这有2种可能：

1.神舟出于压缩成本考虑，没有购买配置完整模块。（这不稀奇，phoenix最早出售USB启动
功能时，连以USB2.0速度启动都要单独收费，乞丐版只能以USB1.1速度启动。联想F31A机
也是一样不完整，配了USB-HDD模块，但没有配USB-ZIP、USB-LS120启动模块）
2.神舟购买了完整源码，但改糊了。

二、不管是什么可能，结果一样：是USB-HDD也以removeable移动盘面孔出现。这又涉及
第2个问题：Phoenix bios的移动盘算法。这个算法有hide/unhide MBR计算。这很好理解，
有点类似于G4D的map fd思路/操作。

-----------------------------
再讲完整版USB-HDD启动模块的情况。除了想象中的读MBR/PBR，通过分析仪发现：
有一点与大家想的不同，Phoenix bios  USB—HDD在读完MBR后，不是立即就跳PBR，
当中有一段重要操作：读盘尾（最大LBA），也就是说，它有防LBA超限运算。

-------------------------------
最后，限制一下USB-ZIP的语意：
1.在SMI量产工具里，它指的是移动介质盘选项。
2.在phoenix BIOS下，它指的是符合Iomega ZIP驱动器设备特征(固件参数)的设备。
3.在其他BIOS下，由其具体算法确定ZIP的具体要求。

wuwuzz

2011yaya2007777 发表于 2023-1-31 05:42
应当是在读U盘的LBA（0）到缓存后修改的，然后传送回内存。

谢谢YAYA的指点。

求道者

2011yaya2007777 发表于 2023-1-31 05:42
应当是在读U盘的LBA（0）到缓存后修改的，然后传送回内存。

BIOS会做这么无聊的事情吗？
无聊到了一定的地步。
这么说在启动的这一阶段除了第一分区之外的扇区都被隐藏了？
启动代码也无法访问这些扇区？
我当初也是觉得如果需要调整的地方太多了就放弃在此平台的USB-HDD兼容，当不能用就完事了。
现在确定整不了，那就用SM3257ENAA量产个USB-ZIP算了，3.0 U盘用HDD模式，在量产个CD-ROM。


现在看来确实如此。
只是探索BIOS到底在整什么活而已。

2011yaya2007777

应当是在读U盘的LBA（0）到缓存后修改的，然后传送回内存。

wuwuzz

2011yaya2007777 发表于 2023-1-30 09:57
现在分析一下神舟K470 phoenix BIOS启动U盘的情况：
经过BIOS自己的判断，认为U盘是可移动介质，因此 ...

感谢YAYA的解读。

这个修改应该是在内存中进行的？

sunsea

2011yaya2007777 发表于 2023-1-30 09:57
现在分析一下神舟K470 phoenix BIOS启动U盘的情况：
经过BIOS自己的判断，认为U盘是可移动介质，因此 ...

突然想起了不点的multimbr，这玩意可能好使。

第一阶段的 MBR 引导记录代码，复制到最开头的 190 个扇区上。这 190 个扇区的每个扇区都带有 BPB 和分区表。

不过multimbr方案就不要想着隐藏了……

2011yaya2007777

丫丫能混合出一张能用的Fbinst假PBR吗？

PBR。

现在分析一下神舟K470 phoenix BIOS启动U盘的情况：
经过BIOS自己的判断，认为U盘是可移动介质，因此分配盘符A，隐藏第一个分区之前的扇区，修改（确切地说是减少）总扇区数，修改第一个分区（PBR）的参数表（BPB），具体是修改偏移0x1c处的4字节隐藏分区值。以求道者的UD为例，是将0x4000修改为0。然后把控制权移交给PBR代码。此时，使用int13/ah=42读LBA(0)，由于隐藏了第一个分区之前的扇区，现在LBA(0)指向第一个分区（PBR），因而不是返回MBR代码，而是返回PBR代码。

BIOS根本就没有把控制权移交给MBR的代码，因此UD的引导代码没有起作用，隐藏分区的启动菜单及文件也没有使用。UD启动失败。

要想在这种情况下UD仍然可以成功启动，办法是：
把可见分区的启动代码修改为G4D的启动代码（使用bootice）（不要修改0x1c处的值）,根目录放置grldr，建立相关启动目录，复制相关启动菜单及文件。（几乎是把隐藏分区的文件都搬过来了）
这样修改后，UD的优点荡然无存！

求道者

2011yaya2007777 发表于 2023-1-29 17:57
在神舟K470 phoenix BIOS下，使用那个启动识别为盘符A的U盘，麻烦你测试一下（无论现在是UD分区或者通常 ...

丫丫能混合出一张能用的Fbinst假PBR吗？

zp1688

大神！

wuwuzz

2011yaya2007777 发表于 2023-1-29 17:57
在神舟K470 phoenix BIOS下，使用那个启动识别为盘符A的U盘，麻烦你测试一下（无论现在是UD分区或者通常 ...

PBR。
第1张图32G盘，DOS+GRUB.EXE。
第2张图8G盘，FB+g4d(grldr装在可见FAT32分区)

2011yaya2007777

神舟K470 phoenix BIOS下，选USB-HDD引导菜单项

在神舟K470 phoenix BIOS下，使用那个启动识别为盘符A的U盘，麻烦你测试一下（无论现在是UD分区或者通常分区）：
cat --hex (fd0)+1
看看返回值是MBR还是PBR。

wuwuzz

以前是黑箱，现在不同了。有分析仪，
黑箱被撕开了口子。

作为比较，找了同系支持USB-HDD的Phoenix BIOS（联想F31A机），测试了USB-HDD的启动过程，还是那些U盘，还是那些FB、DOS+G4D.EXE，均正常进入画面。流程比先前K470  Phoenix bios更复杂一些，内容较多，等有空再研究。

对于开源软件G4D、FB，LBA0应该不是啥问题，咋个执行法，读到的内容是啥，本坛的开发者们应该清楚。当然，我是不懂的。这个事其实就是“解析”。

——与分析仪类似，硬件抓包器抓到一堆16进制数，这些16进制数解读出来，成为易读内容，就要靠解析软件进行傻瓜化。分析仪好坏，很大一部分原因其实并不取决于硬件，而是取决于解析软件。硬件上，大家都能抓包，但解析软件，有的厂家做得不行，还要人肉二次解析，就不好用了。

求道者

rgy 发表于 2023-1-26 20:41
讨论得好热闹啊，看得我蠢蠢欲动，都想做几个启动盘，再把主贴更新下了。
你们讨论的都太高深，一看就专业 ...

到了这步，就完全是黑箱操作了，BIOS在干嘛，只有鬼知道了，贼麻烦。

rgy

讨论得好热闹啊，看得我蠢蠢欲动，都想做几个启动盘，再把主贴更新下了。
你们讨论的都太高深，一看就专业啊，我是好用而不求甚解，能启动怎么的都行。

求道者

wuwuzz 发表于 2023-1-26 12:06
没成功启动。

hdd菜单下，BIOS读了MBR---又读了改造后的PBR--(可能又根据PBR代码指示)读了其他东西--- ...

擦掉分区表呢？
能启动吗？
实在不知道运行LAB0里的代码的条件，那就算了。
毕竟是纯纯的黑箱。
整不明白也正常。

wuwuzz

求道者 发表于 2023-1-25 22:33
Fbinst的引导代码只从0060开始。
和PBR的内容不冲突。
那可以用PBR和Fbinst的0060到01B7的内容进行混 ...

没成功启动。

hdd菜单下，BIOS读了MBR---又读了改造后的PBR--(可能又根据PBR代码指示)读了其他东西---但可能地址不对，卡住了。

知道了这个BUG BIOS机HDD下的工作流程，搞好PBR(比如放G4D)就可以工作了。fb的分区太复杂，不讨论了。

求道者

wuwuzz 发表于 2023-1-25 20:38
神舟K470 phoenix BIOS下，选USB-HDD引导菜单项

MBR是无论是win的、还是G4D、wee，都会多次读，但似乎 ...

Fbinst的引导代码只从0060开始。
和PBR的内容不冲突。
那可以用PBR和Fbinst的0060到01B7的内容进行混合。
但01BE到01FD的分区表要擦除吗？
这段偏移在PBR里是BOOTSTRAP CODE的范围。
可以进行测试。
将MBR伪造成PBR。



混合了FAT32的分区信息的MBR在QEMU里可以启动。
但我现在还没有擦除分区表。
wuwuzz亲你试试不擦除分区表看不能引导Fbinst。
首先只混合FAT32的分区信息到LBA0，别擦除分区表。
也许能启动。
不然如果一定要擦掉分区表才能启动的话。
这个方案就算能启动，那也价值不大。
然后我发现偏移0000到0002的这块的jmp指令没啥用啊。
不管是EB 5E 00还是EB 58 90,似乎Fbinst都能启动。
为了防止干扰，我把1-63扇区的内容全部填0了。
但还是能启动。

求道者

wuwuzz 发表于 2023-1-25 20:38
神舟K470 phoenix BIOS下，选USB-HDD引导菜单项

MBR是无论是win的、还是G4D、wee，都会多次读，但似乎 ...

看起来就是单纯的MBR都没生效。
BIOS读取LBA0只是为了分区表和PBR。
强行要兼容的话。
可以试着特制一个Fbinst的PBR。
指向UD。
估计就能启动。
我记得你说在摧毁了分区表和MBR之后也能被引导。
估计是因为BIOS第一次读取LBA0是按照FDD的搞法。
直接找到PBR，第二次读取LBA0估计是在LBA0找不到PBR的话就去找分区表，找到第一个分区的时候就在你按下启动菜单之后执行第一个分区的PBR。

在这个逻辑下似乎存在一个特例。
FDD那种状况下的LBA0是存在PBR的。


那么他是如何判断自己找到PBR了呢？

MBR和PBR的签名不都是0x55 0xAA吗？
没区别啊。





数据结构还是差了很远。

wuwuzz

求道者 发表于 2023-1-25 19:25
那HDD模式下的 启动异常还是无法解决。
只能认为被错误识别为软盘的情况下，BIOS会额外的关注分区。
用 ...

神舟K470 phoenix BIOS下，选USB-HDD引导菜单项

MBR是无论是win的、还是G4D、wee，都会多次读，但似乎没发挥相应作用，
不会激活相应的引导软件(比如G4D的menu.lst)菜单。

起作用的是PBR。PBR放的是win的，则启动IO.SYS到dos
放的是G4D，则按menu.lst 来启动。