[Guide] Manual AMI UEFI BIOS Modding

@ eroder:
Have you already tried to flash a modded BIOS into the BIOS chip of your Gigabyte GZ-Z170X-Gaming5? Maybe the header of the BIOS contains a protection against each modification.
Owners of ASUS UEFI BIOS mainboards have to use the "USB Flashback" method, users of an ASRock mainboard have to remove the BIOS header, when they want to flash a modded BIOS.

This is only valid, when you replace just the "body" of the module. In this case you have to insert a "pure" .efi module and not an .ffs one having the additional header and some other codes.

I also tried the efi module from UBU. Get the same error. Actually first time I try to flash new mobo with modded bios.

I recommend to post your problem into >this< thread and to ask CodeRush for a solution.

Hi fernando,
following your guide i was able to insert the 3 nvme modules in my Asus MAXIMUS VI HERO (Z87 Chipset) motherboard,
Here the result MAXIMUS-VI-HERO-ASUS-1603-NVME-MODDED
when trying to help a friend with his board a Gigabyte GA-Z87X-OC (Z87) using these 2 bios
GA-Z87X-OC F9c Bios & GA-Z97X-SOC F6 Bios
I was able to extract modules from z97 bios but got and error trying to insert them in the z87
"file size exceeds the volume size"


Any idea how i can resolve it?

So I always used UBU to mod my Gigabyte BIOS, but for Z170 I now have an Asus M8 Hero. I tried to use UBU for the Asus BIOS but it did not work, so I suppose I must use MMTool?
I’m not really sure I want to attempt it if it could be likely I screw it up and brick my board.

Does the MMTool work for the microcode as well? Or does that need a different tool? I would like to update all modules/microcode except I think I leave Intel RST at 14.5 for now.

Thanks for any help.

@ mandrix:

Welcome at Win-RAID Forum!
I suspect, that your Intel Z170 Chipset mainboard uses an AMI Aptio V UEFI BIOS. Neither the currently available UBU tool version nor the AMI Aptio V MMTool are able to do all demanded BIOS modding procedures.
The only tool, which is currently able to modify all Option ROM and EFI modules of an AMI Aptio V UEFI BIOS, is Code Rush’s UEFITool.
Please have a look into the start post of this thread.

Regards
Dieter (alias Fernando)

Thank you, I’ll have a look.




Check out my guide: http://www.overclock.net/t/1577530/guide-how-to-update-the-cpu-microcode-on-the-x99-ami-bios




Check out my guide: http://www.overclock.net/t/1577530/guide-how-to-update-the-cpu-microcode-on-the-x99-ami-bios



Great! I will do that. So far looks a little daunting so I need all the help I can get.

I have some comments regarding this microcode updating guide:
- using tools such as AIDA64 is not reliable anymore for displaying the version of microcode, as there is a feature to subtract 1 from the version in specific conditions (x is displayed as x - 1). Currently this is restricted to Skylake, but it is something to keep in mind for future. Instead, use UBU or any other method on the file itself, as it displays the proper version.
- it is faster to display the microcodes directly through MMTool, but running UBU is a bonus to get other modules updated.
- one issue in replacing microcodes through UBU is that OEMs have added a useless attribute and MMTool can’t work with it at all. Read one, two and three.
- AptioV supports FIT table and loading of microcodes from FIT (CodeRush mentioned this more than once). If one microcode size changes, all following microcodes will not be properly linked to FIT table anymore. The FIT table can be checked with an alpha version of UEFITool 0.30.0.
- some OEMs (Asus for instance) insert more than one ffs containing microcodes. Even though some of them are in recovery volumes and aren’t normally used, you might need to replace those too, if the microcode is not updating.
- some OEMs (Gigabyte is one, if I remember correctly) need to have the microcodes in a specific order. To be safe, use the same order as in original file.
- others insert padding between microcodes files to have them loaded from a specific address. This is not something you will see often and it is rather specific to laptops, but keep an eye for any padding you might see between microcodes.
- it is better to use a tool for the offset and sizes of microcodes. I use my Extractor for such tasks (as it supports both Intel and AMD), but it is not a public tool. You can however search for intelmicrocodelist, it will display what you need, but no extraction. In Linux world you will find iucode-tool, but I have not used it so far, don’t know if and how it works.
- Lastly, all your work will seem wasted, if you try to use an older microcode. Windows has mcupdate_GenuineIntel.dll and mcupdate_AuthenticAMD.dll for loading microcodes. If you plan on using a microcode older than what’s on that list, you will need to follow this advice.
- the content of mcupdate_GenuineIntel is attached. The list is for KB3064209 on Win7 and 10.0.10240.16384 dll on Win10.

MS_Microcodes.rar (2.76 KB)

Well that is all very interesting but in my case Ubutool failed to update the codes on my MSI Godlike X99A motherboard. Thats why I wrote that guide plus I have to admit I am an intermediate modder, and I believe you learn from doing and taking action and it helps the greater good in the community. I appreciate your critique. It was very interesting. Thanks.

It wasn’t a critique per se, but rather suggestions to improve it or avoid mistakes. For your particular case, item nr. 3 was the problem. To have UBU support, you just have to remove FFS_ATTRIB_FIXED (useless on Volume Top Files), in other words, change file attribute from 0C to 08. You could do this with UEFITool, by extracting 1BA0062E-C779-4582-8566-336AE8F78F09 and in that file change offset 0x13 from value 0C to 08, save the file, then replace it. The problem is that UEFITool will also remove the trampoline for recovery (CodeRush can offer more details). To avoid this, open your E7883IMS.110 file in hex editor and change offset FFE0C8 from 95 to 99, then change offset FFE0CB from 0C to 08. You can double check the result with UEFITool. After this change, your file will work in UBU for microcode update. See the picture bellow, you need to change only the two values, but keep the top red line unchanged.

MSI_X99.png



What part doesn’t work, I’ve got the same board and have had no issues updating any modules including microcode.

For Gigabyte Z170, everything working except OROM Sata legacy (EFI is OK).

Ok, so the BIOS modding restrictions of Z170 chipset mainboards seem to be very limited.
By the way: I don’t see any reason for owners of an Intel-100 Series Chipset system to use LEGACY Option ROM modules.

Well for whatever reason UBU just will not update the M8 Hero BIOS 902 for me…not sure why it works for someone else but not for me.
But there is no way I’m going to use any complicated methods I don’t fully understand…I’ve always used UBU because it was quite simple to use and effective.
I will continue to use it for my Z97 Gigabyte however.


Did you update the microcode, too?

Well Asus M8 Hero 902 would not update with UBU, but 1001 would!
But 1001 has an Adaptive Vcore bug…I may use it in offset mode, though.
Interesting!


Did you update the microcode, too?



Yes, Intel microcode update is OK.


I still using legacy…less trouble.

Found out something interesting. There are apparently two versions of the Asus M8 Hero BIOS…one UBU would not update, the other one UBU updated every module and microcode just fine!
So, apparently UBU is not having problems with Asus BIOS, at least not for the Z170 Hero.

Thanks everyone.