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

求道者

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

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

求道者

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

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

2011yaya2007777

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

wuwuzz

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

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

wuwuzz

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

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

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

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

wuwuzz

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

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

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

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

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

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

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

wuwuzz

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

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

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

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

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

2011yaya2007777

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

求道者

2011yaya2007777 发表于 2023-2-1 16:47
你的理解很对。问题在于这个函数执行之前，传入的eax没有保存，被这个读容量函数破坏了。以后也没有见读出 ...

BIOS源码里有BUG？
然后就K470这样了吗？

fzp070

感谢分享！
很详细，图文并茂，很用心，辛苦了!

wuwuzz

求道者 发表于 2023-2-1 23:35
BIOS源码里有BUG？
然后就K470这样了吗？

不是这样吧？

即使BIOS源码有BUG，也是在说隐藏MBR后，总扇区数忘了减相应数量，
并不影响隐藏MBR这个操作。

wuwuzz

2011yaya2007777 发表于 2023-2-1 16:47
你的理解很对。问题在于这个函数执行之前，传入的eax没有保存，被这个读容量函数破坏了。以后也没有见读出 ...

因为我不懂汇编，这里是瞎猜的：

ReadCapacity函数在开始的时候，进行了一系列栈操作(含AX寄存器)，并且：

    call    hddUFIFunnySegmentToDS
    mov    al, ds:[hddUFIHotParametersOK]

而对[hddUFIHotParametersOK]的解释，我找了一下，是：
- One if we can safely alter the media capacity and block size, else zero

是否这些代码已经事先保存了EAX里的“需减少的总扇区数值”，然后才开始
执行readcapacity命令包，破坏EAX里的值。

wuwuzz

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

我的看法:

不用搞得这么繁复吧，K470 Phoenix BIOS USB-HDD菜单下，SMI盘不用怎么调，就可以正常启动G4D，这就足够了。

fb/ventoy那样多分区，在此环境中，反而复杂化，不能正常启动。需放弃它们的时候就果断放弃。

2011yaya2007777

BIOS源码里有BUG？
然后就K470这样了吗？

我说的是隐藏扇区，eax没有保存，被这个读容量函数破坏了。以后也没有见读出的容量减每磁道扇区数。

这个因素没有大碍，最多是容量不准。

2011yaya2007777

依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议时，判断为可移动！分配驱动器号 <0x80。也就是判断为软盘。
通常U盘，也就是Flash（闪存）盘，或者叫USB海量存储器，遵循UFI协议。因此统统判断为软盘。
在这种情况下（分配盘符A:），可能会影响某些软件运行。

2. 判断为可移动时，也就是判断为软盘时，减少1磁头，隐藏第一分区之前的扇区，逻辑0扇区指向PBR。
这对于通常形态的启动模式（即读MBR，查找活动分区，然后把控制权交给PBR），没有影响。
然而对于UD形态的启动模式（即读MBR，在隐藏分区读文件，进入菜单。不交权，与PBR启动代码完全无关），实在是灾难。以为根本就没有把代码控制权交给他。

这可能是Phoenix BIOS的某一个版本，其他版本可能不一样。
K470 Phoenix BIOS 则完全一样。

wuwuzz

2011yaya2007777 发表于 2023-2-2 10:54
依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议 ...

我这里做一下订正：

软驱(盘)与可移动设备(removeable、盘号0x00、DOS下A:)是2个概念。


1.常用U盘不遵循UFI协议，而是遵循SCSI协议。通过BIOS内置算法的规则(关键标准之一就是U盘容量-总扇区数)，
可能会被设定为可移动设备。

2.当USB存储设备遵循UFI协议时，它将被Phoenix BIOS用作判断为软驱的条件之一，
即：BIOS菜单中的USB-FDC。这种遵循UFI协议的U盘，常见于有硬件仿真FDD电路的U盘。
软驱一定是可移动设备。新版AMI BIOS/UEFI源码也有这方面的设定。

3.SF8070I协议的情况比较复杂，暂时不详细讨论。遵循这种协议的USB设备不常见。
在phoenix BIOS下,这种设备也一定会被设定为可移动设备。

求道者

wuwuzz 发表于 2023-2-2 06:56
我的看法:

不用搞得这么繁复吧，K470 Phoenix BIOS USB-HDD菜单下，SMI盘不用怎么调，就可以正常启 ...

wuwuzz亲把其他牌子的BIOS源码都发给yaya吧，指不定能找到点什么鬼东西，如果还有其他源码，发给我，我放到我的nas上做个bt种子，万一有人要用这些源码也能找到，就是可惜15年泄漏的I2O源码找不到了。

wuwuzz

求道者 发表于 2023-2-2 11:30
wuwuzz亲把其他牌子的BIOS源码都发给yaya吧，指不定能找到点什么鬼东西，如果还有其他源码，发给我，我放 ...

我手上有phoenix bios的这套、然后就是AMI BIOS(BIOS技术剖析这本书光盘附带的)那套。

后来泄露出的AMI UEFI/BIOS源码，基本就是上面那套汇编代码，用C重写了一遍。


很久很久以前，我就建议过YAYA下载保留AMI BIOS那套，不知后来他做了没有。

求道者

2011yaya2007777 发表于 2023-2-2 10:54
依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议 ...

我找到了一个比较容易复现的G4D图形bug。
普通进入图形菜单。
哪怕是只设置一张图片，在1600x900 32位色深模式下，字体也会不显示。
命令行模式下可以显示字体。
图形模式 0x17F

求道者

wuwuzz 发表于 2023-2-2 11:36
我手上有phoenix bios的这套、然后就是AMI BIOS(BIOS技术剖析这本书光盘附带的)那套。

后来泄露出的AM ...

都发我吧，我到时候再找找还有没有其他源码，然后做个bt种子放网上，我自己的服务器也永久存一份，其他地方存这个迟早被删除。
然后网上下不到了。

2011yaya2007777

常用U盘不遵循UFI协议，而是遵循SCSI协议。

你说的可能比较规范。不论是协议也好，命令也罢，USB传输用到了SCSI指令，比如读扇区，读容量，查询等等，这些在我魔改的实模式USB2.0代码中，都有应用。记得与UFI是否有关，可能时间长了忘记。

我是实用主义，不求甚解。看过USB的协议，看过一些实例。能把他们驱动起来，正常使用便可。

求道者

2011yaya2007777 发表于 2023-2-2 10:54
依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议 ...

到这地步fixed模式就没救了吧？改造成本高到还不如removeable模式，操作起来就是备一个额外的小点的u盘用来做removeable模式吧，确实不算难。
如果能在pbr里嵌入usb2.0驱动，然后重载u盘，大概能够访问UD，但这实施成本太高了。
阴间BIOS确实有这种古怪的限制。

2011yaya2007777

很久很久以前，我就建议过YAYA下载保留AMI BIOS那套，不知后来他做了没有。

我下载过，也没有仔细看。电脑换了好几个，也找不到了。
我觉得现在仔细研究这些 ，没有太大的必要。

求道者

2011yaya2007777 发表于 2023-2-2 11:52
我下载过，也没有仔细看。电脑换了好几个，也找不到了。
我觉得现在仔细研究这些 ，没有太大的必要。

G4D的图形模式的bug能修吗？
QEMU估计也能复现。

wuwuzz

2011yaya2007777 发表于 2023-2-2 11:46
你说的可能比较规范。不论是协议也好，命令也罢，USB传输用到了SCSI指令，比如读扇区，读容量，查询等等 ...

喔，是这样：我不是想讲规范的事，而是因为“启动”，需要特别注意几个点：

一、UFI这个协议值是Phoenix BIOS决定软驱设备类型判定的关键，所以把它单踢出来强调。

二、命令确实可以混用，因为UFI命令集本来就是SCSI命令集的简化修改版。(继承)

三、U盘固件声称自己遵循SCSI命令集，实际上也是扯淡，SCSI太复杂无法完整实现。所以平时按简化的UFI来学习掌握没问题。

四、问题出在这：同一条命令，USB启动规范做了重新定义，而U盘固件开发者又按SCSI那一套定义来，对启动极为不利。

2011yaya2007777

到这地步fixed模式就没救了吧？

就这种主板而言，放弃吧，折腾的成本太高。U盘又不贵，多备几个不同启动方式的。

G4D的图形模式的bug能修吗？

这是内存冲突了。抽时间看看。
g4d内存使用比较乱，大部分是固定的。随机分配内存的函数有，估计是不太完善，使用不多。

wuwuzz

求道者 发表于 2023-2-2 11:51
到这地步fixed模式就没救了吧？改造成本高到还不如removeable模式，操作起来就是备一个额外的小点的u盘 ...

为什么非要fixed模式，是有特殊需求么？ 比如UD无法放弃？