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.
Thanks! The system is in manufacturing mode right now, so he will need to close that once we’re done. I’ll have to have you chime in later once we’re done testing/trying what we’re doing, so you can advise him on best thing to do before any closing.
Ok lets see i have a question to ( or more )
First off all love these kind off forums !!
Already did update my Asmedia 104x USB 3.0 firmware that went well
But now i have a question about my bios ( all my system specifications are in my signature )
I downloaded the original bios from Asus the 3602 for my motherboard and started to work with UBU + MMTools from this site
I already updated the following items to the NEW BIOS ( but did not jet install it )
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
OLD NEW
___________________________________________________
RAID : 10.5.1.1070 RAID : 12.9.0.2006
NETWORK : 1.3.72 GE NETWORK : 1.5.86 GE
JMBX36xx : 1.07.23 JMBX36xx : 1.08.01
MARVEL : 1.0.0.1029 MARVEL : 1.1.0.1002
MARVEL : 1.0.0.0022 MARVEL : 1.0.0.0034
Also all mCODES are up to date
1: it's not in it ( can't find it in the BIOS )
2: when i try to injected it in the CSMCORE ( compressed or not ) it will tell me FILE SIZE EXCEEDS THE VOLUME SIZE and/or ERROR IN INSERTING FILE
tryed it with all 3 versions off MMTools but no luck
Any idea why this won't work ?
Do i need it ?
Also i now have a raid system so when i update my bios will the original raid be lost ? ( in that case i have to make a backup off all )
Did i update the right files in my ROM
I will upload my ORIGINAL and MODDED roms with this post
So i hope somebody could help me out her
Thanks already
ORIGINAL BIOS : BIOS 3602
MODDED BIOS : BIOS MODDED
PS some info of DEV :
Intel(R) Desktop/Workstation/Server Express Chipset SATA RAID Controller : PCI\VEN_8086&DEV_2822&SUBSYS_844D1043&REV_05
@Gman2oo6 :
Welcome to the Win-RAID Forum!
1. The Intel EFI RAID BIOS module is either named “SataDriver” or "RaidDriver and can be found within the DXE Driver Volume of all AMI UEFI BIOSes, which natively support the Intel RAID option in UEFI mode.
It is neither part of the CSMCORE module nor can be inserted into it.
Since the mainboard manufacturers give the SataDriver resp. RaidDriver modules different headers (GUIDs), it is better to update just the “body” (as *.efi file) of the SataDriver resp. RaidDriver module.
No, an existing RAID array will not be touched by an updated Intel RAID OROM or SataDriver module.
Regards
Dieter (alias Fernando)
@Fernando :
So if im not mistaking now you are saying that i don’t need to inject the SataDriver90.FF i Only need to update the RAID from 10.5.1.1070 to 12.9.0.2006 ?
I was just following this:
second when i do this:
i only have this:
Noting like yours?
Well i have search everywhere but i cannot find it only thing i find with SATA in it is this
|045|SataController |BB65942B-521F-4EC3-BAF9-A92540CF60D2|0021A2D0|000E18|DRVR|
This is a complete report of the original bios:
EDIT by Fernando: Deleted, because not required at all
@Gman2oo6 :
Since you obviously have a BIOS Modding problem, which has not much to do with the topic of this thread (choice of the best suitable EFI “RaidDriver”), I have moved our discussion into >this< thread.
Now to your questions/problems:
- An Intel EFI RAID module (named SataDriver or RaidDriver) is only needed and used by the system, if
a) the Intel SATA Controller has been set to “RAID” within the BIOS,
b) the RAIDed HDD/SSD contains the boot sector and
c) the system drive boots resp. shall boot in UEFI mode. - Since the original BIOS for your mainboard doesn’t contain any Intel EFI RAID module, you cannot insert any “pure” Intel EFI RAID module (with the extension *.efi). You have to insert a complete Intel EFI RAID module (with the extension *.ffs).
- Before you are going to insert the desired Intel EFI RAID module version, you have to find out, which GUID the mainboard manufacturer (here: ASUS) uses for the Intel EFI RAID modules. AFAIK the GUID starts with the numbers 90."
Questions:
1. Have you created a RAID array or do you want to create it?
2. Do you want to boot your RAIDed system drive in UEFI mode?
Off topic:
Please shorten your signature, which needs too much space. Only 2-3 lines are needed to give us the information about
1. the mainboard manufacturer, the mainboard model and its chipset
2. the connection (SATA/PCIe/M.2) and the used data transfer protocol (AHCI/RAID/NVMe) of your system drive)
3. the in-use Operating System
1. the mainboard manufacturer, the mainboard model and its chipset
2. the connection (SATA/PCIe/M.2) and the used data transfer protocol (AHCI/RAID/NVMe) of your system drive)
3. the in-use Operating System
Ok clear
1:
a: Yes it is
b: No its not the boot sector
c: Yes it boots up in UEFI mode
2:when starting UBU to check it says in the RST has to be the file with DEV_2822 what i have but you can only put this in it
# Only IRST files should be located in this folder.
# SataOrom.bin DevID 2822/282a
# RaidDriver.efi
So a *.ffs wil not work in that folder /Intel/RST only in /Intel/RSTe you can put a *.ffs but
# Only IRSTe files should be located in this folder.
# SataOrom.bin DevID 2826
# RaidDriver.efi
# SCUOrom.bin DevID 1D6x
# SCUDriver.efi
# sSataOrom.bin DevID 2827
# sSataDriver.efi
thats not my DevID !!
I downloaded this version : Intel-RSTe_EFI-RAID_SataDriver_v12902006_without-header
but in UBU it tells me its a INTEL and not a OROM thats why i got the next rom down below
so i downloaded this one
>"Universally TRIM modified" Intel RST(e) RAID ROM v12.9.0.2006 with TRIM in RAID0 support
Note: This modded OROM is designed for DEV_2822/282a Intel RAID Controllers.
For details look look >here<. Credits go to CPL0 aka Dufus for having developed this special OROM modification.
this one he sees and also replaces it to this version 12.9.0.2006 ( from 10.5.1.1070 )
3: I cannot find any GUID starting with 90 !
1: I already have a RAID0 array installed
@Gman2oo6 :
1. As the name “UEFI BIOS Updater” already says, this tool can only update a module, which is already present within the related BIOS file. If you want to insert a natively not present BIOS module, you have to do it manually by using the AMI Aptio MMTool v4.5 or the latest UEFITool version.
2. If you want to know the first numbers of the GUID header, which ASUS is using for the Intel EFI SataDriver resp. RaidDriver modules, you can open any UEFI BIOS of an ASUS mainboard, which definitively supports Intel RAID.
Ok then i guess its save to say this one is ok for me
Universally TRIM modified" Intel RST(e) RAID ROM v12.9.0.2006 with TRIM in RAID0 support
Note: This modded OROM is designed for DEV_2822/282a Intel RAID Controllers.
Indeed when i take a bios from a newer board i will find it example
ROG MAXIMUS X FORMULA BIOS 1704
But not in my bios sadly
so i will go for the first option and see what happens