Can we use it as the .efi images present in UBU, or do we need to do something, like removing the header as for Intel OROMs? thank you!
@gpvecchi :
EFI BIOS modules with header are the *.ffs files, after the removal of the header they are named *.efi files.
The handling of the Legacy mode Option ROM modules (usually as *.bin files) is totally different. They can be inserted as they are (without removing any header).
cpu000506E3_plat36_ver000000B2_date01-02-2017
Many thanks, is there some tutorial on how to remove header? I assume it has to be done with hex editor…
EDIT: I removed the firts byte of the ffs file (I looked at the old .15 Intel Lan .efi in UBU modules folder and compared to the .ffs file from same version) and used old UBU to add latest Skylake microcode (no modding from the version posted).
Should I be fine?
Yes, what you need is an Hex Editor like HxD.
The procedure is very simple. All you have to do is to delete the hex code, which belongs to the header. All you must know is, that the "body" of the EFI module begins with the hex code "4D 5A".
Here is my "tutorial" about how to remove the header from any uncompressed EFI module named *.ffs:
- Open the related EFI module as uncompressed FFS file (in my example it is the Intel "RaidDriver" v15.5.0.2813) with the tool HxD.
This is what you will see:
- Mark the header as shown in the picture above (blue colored part). Make sure, that the marked hex code part ends just before the code "4D 5A".
Then hit "Edit" > "Delete" from the task bar.
Now you get the following warning:
- Click onto "OK".
This is what you see now:
- Save the modified module and name it like the source file, but with the suffix *.efi.
Now you have the "pure" EFI module (without header).
ffs is a container so there can be data like the module name at the end as well. In this case the executable has a size of 0x4BE20.
Many thanks, I’ll try to keep my bios updated till new UBU will came out. Regarding the microcode, may I just use it as it has been posted, or do I have to edit something?
@plutomaniac : Since the number in the hex dump is 0x4be24, you subtracted 4 to get 0x4be20. Where did that magic adjustment come from? I’m guessing that it’s a byte count from the first byte of the number (rather than from the start of the efi). With that extra 10 byte between the count and the efi that would make 4 bytes. Is that correct, or did you leave out the “24 00 00 15” at the end for some other reason? I’m asking because the ffs number, 0x4be88, is clearly the entire size of the file (and not a byte count from the start of that number).
@ gpvecchi:
Yes, ready for use.
@ rmongiovi:
The size mentioned at the first dword includes itself as well. The actual data starts after 4 bytes with dword_size - 0x4. That dword consists of Size [0x3] and Type [0x1]. In this case we have a size of 0x4BE24 - 0x4 = 0x4BE20 and Type 0x10 which stands for EFI_SECTION_PE32. Another example, after the PE32 image ends, you can see that the next section has a size of 0x24 - 0x4 = 0x20 and a Type of 0x15 (EFI_SECTION_USER_INTERFACE) and the last section has a size of 0xE - 0x4 = 0xA and a Type of 0x14 (EFI_SECTION_VERSION). All of these can be found at the public UEFI Specification.
thx.The answer from the developer and author of the UBU tool is within post #202.
Hello, I have a MSI GT72 6QE DOMINATOR PRO G laptop and I have tried to update the bios modified with your UBU application, and at the time of updating the BIOS on my laptop it does not detect it and it does not let me update it, it only detects the original, You can help me because I want to update the Intel IRST firmware.
Greetings.
@salva_vts :
Welcome at Win-RAID Forum!
Your problem is not caused by the UBU tool, but by the actions of your laptop manufacturer to prevent, that the user flashes a modded or a wrong BIOS.
Flashing a modded BIOS of a Mobile system is generally much more risky than doing the same with a Desktop system.
You have to rename the modded BIOS file. It must have exactly the same name and suffix as the original BIOS file.
What is the reason for the update? Do you have any special problems? Is your on-board Intel SATA Controller running in RAID mode at all?
Regards
Dieter (alias Fernando)
P.S.: I have moved your post into this "UBU Discussion" thread, because the other UBU thread has been designed just for the UBU guide and the announcements of UBU updates.
@Fernando
Nice tutorial on converting FFS to Efi but I think you forgot to mention, though i could be wrong, that the last two bytes on the end of the file need to be zero’d out such that if it says ‘FF FF’ it should say ‘00 00’ ?
Thanks
You are wrong. The last bytes on the end of an *.ffs and *.efi file from the same manufacturer and with the same version can be identical, but should be different (as plutomaniac has posted >here<).
EDIT: My statement has been corrected after having read plutomaniac’s reply.
Here is the proof (above is the Intel RaidDriver.efi, below the RaidDriver.ffs, both v15.5.0.1038:
The last 2 bytes (FD FD) are not essential for the function, but required, if you want, that the DXE module is shown within any BIOS tool with the name, which stands some bytes before (here: "RaidDriver").
At the picture above I can see that RaidDriver.efi has useless data at the end. As mentioned above, FFS is a container. So to take the PE32 .efi image out of it, the extra stuff needs to be removed from both the start and end of the container. An efi is an executable (PE32 image) so it needs to be proper. For example you can take an exe and add however many random bytes at the end and it will probably still work because the payload ends at a predefined offset before them but that doesn’t mean that these should be there.
