The UEFITool link should also be replaced with Github Releases, where users can look for 0.22.x versions which support re-building.
Hello,
I’ve noticed something interesting.
If I extract a module - at its top level - using “Extract as-is” - I get a 4K file (approx) (an .ffs file).
If I extract the module’s main body, by using “Extract body” on the PE32 Executable section, I get a 8K file (approx) (a .bin file).
Which is strange, b/c the .ffs file of the module seems to contain the PE32 Executable section, but yet it’s smaller…
(I’ve confirmed this: I can extract a module using “Extract as-is” to an .ffs file, then use “Replace as-is” to drop it in place of a different module, then use “Extract body” to extract he PE32 Executable body from it, and it will be the body of the module that I had originally extracted.)
Why is the.ffs file half the size of the .bin file???
I thought it might be compression, but I don’t think so, b/c I can see the GUID in the .ffs file, unencoded, right at the top, and then the GUID of the “GUID defined” section ~100 bytes down.
Thanks!
@yaronshr :
As you have already suspected, it is the compression of the complete FFS module, which may let an “as-is” extracted DXE Driver seem to be much smaller than the extracted uncompressed body of its own PE32 Image Section, but this only happens with the UEFITool.
You can easily verify it yourself, if you open the same BIOS with the related AMI Aptio UEFI MMTool and extract the same DXE driver by using the “Extract UnCompressed” option. This way you will get the uncompressed FFS module. Unfortunately the UEFITool doesn’t offer this feature.
It means that GUID-defined section has a GUID that indicates a specific compression type, so the actual body of the file is in fact decompressed data.
This is not a limitation of UEFITool, this is a design decision. A lot of people will try to extract body of GUID-defined section and then insert it as FFS file body, and this can never be done properly, unless the user is a pro. Need the compressed body - strip all headers from FFS file, because you clearly know what you are doing.
Does anyone know how, or can point me to a little info/guide on correcting this issue when modifying BIOS - warning from EUFITool - checkProtectedRanges: BG-protected ranges hash mismatch, opened image may refuse to boot
I corrected the FIT table already in this BIOS, fixing microcode locations and Bootguard key manifest and key policy locations, but am unable to figure out the above issue. Hopefully it’s possible!
Original image does not show this. I’ve seen it be OK before, but usually in those instances the bootguard key manifest and policy locations weren’t setup in FIT, at least I don’t remember having to correct those before and BIOS was OK.
I checked the ME Region, and OEM Public key hash is all zero’s, so maybe it’s not fully configured and this can be safely ignored?
BIOS In question here - https://www.supermicro.com/products/moth…0/X11DPi-NT.cfm
I updated two microcodes via GUID extraction and hex edit, then corrected it all the FIT table.
There’s no way to correct it without having vendor’s private key to ri-sign the modified firmware. If the system doesn’t have BootGuard enabled, just do nothing.
Thanks @CodeRush I thought I’ve read you say that sometime in the past, but I couldn’t find the right post. Does that mean I was correct, in thinking that is ME settings do not have OEM Public key hash value set then it’s not really enabled anyway?
The CSE setting is relevant only at the first boot after EOM when the FPF is burned into the PCH. Once the fuse is set once, it doesn’t matter what you see or set at the CSE firmware settings. So no, that setting is not indicative of what is actually set in hardware.
Thanks, I asked the user and he said he doesn’t use bootguard, but I guess that maybe still doesn’t mean this issue will be OK solely based on him not using it.
Good thing though, he has flash programmer so recovery is no problem!
@plutomaniac , while it’s not a 100% working indicator of disabled SB, it’s mostly true because no sane vendor will provide and update image that has mismatched BG configuration and will probably refuse to work because of that (depends on BG setup, actually). So, if you see a valid OEM hash in ME config, and the same hash can be found on BootGuard tab of UEFITool NE, this indicate a correct BG setup. If ME doesn’t have an OEM PK hash or has a different one, the most probable outcome is that it’s not enabled.
However to be 100% sure and get away from heuristics, MEInfo provides all the required BG-related information, so if you see BG tab populated and stuff marked in red/yellow/cyan in UEFITool NE, it’s better to ask for MEInfo output before trying to modify anything.
Thanks @CodeRush - I do see red/yellow/cyan in the modified and original BIOS. I’ll have the user get me an MEInfo report, will it be obvious from that if BG is enabled vs what we’re already discussing only partially setup?
@CodeRush : I second the fact that MEInfo must be used to know for sure what the BootGuard state at FPF actually is. I have actually seen various SPI (especially from Chinese/Taiwanese brands) which have all the BG info populated at CSME + BIOS but forget or don’t know that they need to trigger EOM to fuse them. Usually they leave the FD unlocked so the FPF stay at an uncommitted state even if their BG setup was actually proper (same hash at CSME & FIT). I’ve seen the opposite as well, meaning active BG but hash missing from CSME because it’s useless after the first EOM boot and the OEM uploaded a new image with just settings or similar. So yes, if one sees BG hashes at FIT or UEFITool, they should suspect that it’s active which can then be verified by MEInfo before trying to mod anything BIOS related.
@Lost_N_BIOS , it’s obvious from MEInfo output, as it clearly indicates Measured Boot (TPM-based BootGuard mode) and Verified Boot (ME RoT-based BootGuard mode) as enabled or disabled. If any of those is Enabled, any changes in BIOS region may lead to brick.
Thanks, I will wait for meinfo output then before giving BIOS to user to test. He has programmer to recover, but if I know it’s going to be a brick no matter what then no point in sending over a modified BIOS even if it’s done.
@CodeRush & plutomaniac (I guess that’s a good way to catch your eye? 
)
Measured Boot and Verified Boot enabled at ME level, but not at FPF side, does this indicate bootguard not active and I can edit something inside cyan region of BIOS? Thanks!
And while your looking, something I thought to ask other day, when I do find this is active on some system, editing still will fail if user has flash programmer too correct, nothing matters/can’t be edited?
Yes, the FPF are not set so the system is at an uncommitted manufacturing mode state which makes BootGuard useless. The Field Programmable Fuses (FPF) are committed once, at a hardware level, fused into the PCH. Once set, they cannot be changed without replacing the PCH. Re-flashing the SPI chip does not matter once these are set as their permanent state is stored in the PCH hardware.
Great, I thought so but haven’t seen this often enough to be sure, thanks for confirmation plutomaniac!!
And thank you for the answer on the rest as well, so only when it’s active at FPF level and ME then it’s enabled, and nothing can change that but replacement PCH or having access to the actual key to reset it after edit (Which we never have)
The CSME settings matter only for the first non-manufacturing mode boot (fpt -closemnf). Once the CSME settings are fused into the PCH, they don’t matter anymore. The CSME can have whatever settings it wants but only what is fused into the PCH matters. So you only need to see if the PFP are committed.
The hash of the Public Key (+ Exponent if I remember correctly) is fused into the PCH so yes, only with the Private Key can someone (OEM) release a working update. But once set, noone (including the OEM) can change the BootGuard settings themselves as these are permanently fused. This is why Flash Image Tool asks for confirmation by default before building an image with BootGuard enabled.