@konstantiniyyr1
Problem in MMTool, using v5.2.0.24
Well. Unfortunately we have to use two versions of the MMTool.
UEFIReplace, to replace the microcode, will not work. Since it uses the old UEFITool engine,
MMTool 5.0.0.7 as we see, it does not always cope with new BIOSes on Aptio V.
MMTool 5.2.0.24 also has problems with some BIOS on Aptio V, and there is also no full support for Aptio 4.
Therefore, in UBU version 1.72 you will need to have 2 versions of MMTool:
- 5.0.0.7 as mmtool_a4.exe
- 5.2.0.24 as mmtool_a5.exe
This will solve these problems post above.
By default, if necessary, mmtool_a4 will be used for all versions of Aptio.In case of a problem, there will be a replacement by mmtool_a5.
Thank you. I checked in a Hex Editor, works perfectly! 
And I checked the microcodes with MCExtractor, they are the latest after using UBU Tool. 
had to rename mmtool.exe (5.0.0.7) to mmtool_A4.exe with the new 1.71.1 , it was a bit unclear at first but i got it eventually. System is up to date again. Thx again guys.
What i ment to say is that the addition of the little word "rename as" instead of just "as" in the script would be so much clearer.
Dear Fernando
I saw the UBU 1.71.1 has already updated again. Could administor consider adding mage download link again in thread [Tool Guide+News] UEFI BIOS Updater (UBU),so everyone include me could download it easyly. Though when new version publishing, update three download link looks a bit troublesomely.
thanks.
@thinking :
AFAIK the latest UBU version is still v1.71.1.
What is a mage link? Do you mean a MEGA link? If yes, it has already been done by me.
Yes…you’re right，dear fernando
, “mega link”， sorry for my poor English，I made a wrong spell.
The mega link could successfully open it at least once in thirty clicks in firewall country.
Thanks.
there’s a small typo at the start of line 1831 of ubu.bat in this latest version 1.72, there’s a “ff” instead of “if”.
Btw, it’s working great, thank you SoniX!!
@SoniX , @Lost_N_BIOS
I have tried this procedure to modd ASUS Z390M-Plus BIOS v2401.
1) Via EZ_Flash Tool I have updated to stock BIOS v2401 on a Z390M_Plus system. (PRIME-Z390M-PLUS-ASUS-2401.CAP file size 16MB). [No Flashback button].
2) Via FPT_DosFree Tool I have done from this system a Bios Region dump (file size 13MB)
3) Via UBU v1.72.1 Tool I have submitted this Bios Region dump to mod it with all possible items such as RST BIOS EFI/OROM modules, EFI LAN module for i-719 component, Intel EFI GOP driver, and Replaced the obsolete µCodes for 3 CPUIDS present.
I get no problem up to the modding completion.
4) When exit UBU Tool I selected ‘bios.bin’ option.
Question:
Does this final modded ‘bios.bin’ (file size 13MB) flashable (on this system) via FPT_DosFree Tool without any problem ?
Is this the proper way to mod a BIOS of a ASUS machine without ‘flashback’ button ?
@100PIER - Yes, if all mods done correctly then you can flash it back via FPT, if BIOS lock has been disabled by you in grub w/ setup_var
BIOS does need to be checked vs stock image, to see if all mods look correctly implemented, so you need to attach BIOS (stock BIOS or FPT BIOS region dump + Mod BIOS region) for someone to check.
* Edit @100PIER - I checked the file you sent via PM "BR2401Bmodded-via_UBU_07apr19" and no, this is bad mod, TWO critical padding file has been removed during one of the edits as I mentioned to you before, probably during microcode update for one or both.
Do all edits again, except microcodes, and then check with UEFITool NE version (51-55) if padding file is there above microcode module @ GUID 17088572-377F-44EF-8F4E-B09FFF46A070 and then compare second to last module in the last volume, it should appear the same in both stock and mod BIOS
If padding file remains, then do rest of microcode mod by hand, or using MMITool or UEFITool 25 (if this removes it too, then you can do with MMTool only)
On that second to last module, in stock BIOS this is compressed "Non-Empty Pad file / Non-UEFI Data found in pad file" In the mod BIOS, this is just plain padding file, not compressed and does not match original BIOS.
I advise you do not flash this file - as we discussed before, go ahead and do all that except the microcodes and then send to me and I can do for you.
If BIOS is being broken before this, then SoniX will need to know
I completely agree.
It is important to remember that if the backup was made with the -bios argument (FPT), then you need to back up this backup with the same argument.
Yes, I gave him proper directions to backup BIOS with FPT (FPT -bios -d biosreg.bin) and then reflash after BIOS lock disabled (FPT -bios -f modbiosreg.bin)
But, he needs to have good looking mod BIOS first 
I think UBU will do all his other mods OK without breaking BIOS, but I’m not sure since I do not have all the modules he’s using so I can’t test myself right now.
I think it’s just the ucode update possibly, certainly only that one is removing the padding above microcode, but possibly any/all other mods done inside main BIOS volume too that’s breaking the pad right before VTF… Hard to know without all files he’s using for now.
@Lost_N_BIOS
I understand what you are saying.
I already wrote about this. We have already encountered this when the offset to the FIT itself was lost. At the same time, the old versions of MMTool 5.0…0.7 and UR/UT 0.2x.x do not correct this offset.
MMTool 5.2.0.24 and mCodeFIT 0.6.8 handle this.
But, in general, you must first watch the original and backup.
There is such an example, although the file is clean original.
[Discussion] UBU Tool related Questions, Reports and Suggestions (4)
Edit:
ASUS Prime Z390M-Plus
I checked original BIOS image. Everything is as usual, nothing critical. All offsets are the same after modification.
Added:
@Lost_N_BIOS
By the way, I wanted to ask you. @john77 asks to help him update the BIOS.
https://www.gigabyte.com/us/Motherboard/…support-dl-bios
You’re doing great with GigaByte. 
@Lost_N_BIOS , @SoniX
Thanks a lot for all your last comments.
As I have no sufficient skills to understand the issue about µCodes update I do summarize my understanding:
For you Lost_N_BIOS the “bios.bin” is suspect and should not be FPT flashed ?
For you Sonix do you think the “bios.bin” should be correct and FPT flashable because no error where displayed/detected during UBU operation?
Here is a link to download BR2401_Full_modding_08apr19 a compressed file which do contain:
→ The original stock BIOS (.CAP file)
→ The full “UBU v1.72.1 folder” which do contain the entry Bios Region input file “BR2401B.bin” to be modded, and the Bios Region output file “bios.bin” after UBU operation.
→ The set of ‘step by step’ screenshots to visualize the UBU operation done without any problem report and specifically before and after µCodes updates.
So, the basic question is:
Does the output file “bios.bin” is suspect ? or is it fully OK to be FPT flashed ?
Do I have used the correct “MMTool” version for this try?
or
Do you recommend to use UBU tool for all items modding, except for µCodes modding, when the UBU input file is a Bios Region file (13MB) and not a classical Bios .CAP file (16MB) ?
Your recommandations will be very helpful to clarify me.
@100PIER
The first thing I want to say is that for such BIOS MMTool is not required at all. Everything makes UEFIReplace.
All that is contained in the archive, has no information for reflection.
As I said earlier, I see no particular problems after modifying the original BIOS image.
In the end, you yourself must decide to make and flash a modified BIOS or not. No one will ever give a 100% guarantee that everything will be Ok. Any intervention in BIOS is a tape measure.
ASUS also has CrashFree bios 3 function in board to rescue damaged bios ,but I think asus 3xx series board needs to verity intergrity and spi of bios.So it’s hard to flash bios, just wait for new bios version from offical.
https://www.asus.com/us/support/FAQ/1012219/
After UBU operation,you could save modified BIOS by chosing “1 rename to…” selection instead of "0 as is bios.bin " ,this instruction you could find in section “C. Finishing UBU:” of thread [Tool Guide+News] “UEFI BIOS Updater” (UBU)
@SoniX - on post #70, I was not referring to anything to do with FIT, FIT is OK in his mod BIOS. Here is a link to the mod so you can see the items I mentioned at post #70 - https://1drv.ms/u/s!Ai4MDoZBl1gOggsHRFiOxruTN10t
1. Padding file above microcode is removed (Sometimes this is OK, often = brick) 2. Padding module just above VTF is drastically changed vs stock (stock is compressed, mod one is not, + different contents etc & it should remain same general “Look” in UEFITool before/after mod)
Those 2 things are all I was mentioning, to my eyes this is broken mod BIOS and I would not risk flashing without programmer in hand
Sorry for any confusion, I did mention ucodes, but only in regards to that is what mod often removes the padding file and breaks the BIOS (FIT issues aside if present, this happens often with any various edit).
He also modified other things in that same volume, so any of them on rebuild could have done this, or could have also changed the structure of the padd module above VTF too. I am not sure which edit is breaking the padding files in this mod (x2)
Here is images of what I mean, in case you don’t have time to download stock BIOS and mod BIOS to compare
* Edit - Sorry, I forgot to comment on your last bit >> @john77 asks to help him update the BIOS.
https://www.gigabyte.com/us/Motherboard/…support-dl-bios
Thank you, what does he need done on this BIOS?
@100PIER - no, I mentioned this BIOS >> BR2401B_ubumodded.bin << I would not flash that due to reasons mentioned above and at post #70, it might be OK, but very risky to flash without programmer in hand (and again I do not think it’s OK, seen both of these issues and either alone = brick many times)
And yes, as SoniX mentioned above, we cannot guarantee anything, I can only point out the issues I see in a mod by looking it over and then offer my advice and thoughts.
You also cannot rely on any Asus "BIOS crash free recovery stuff etc, that is only last good hope, if BIOS is broken bad enough these kinds of recovery will not help, and with no programmer in hand no USB Flashback on this model risk goes way up when flashing even stock BIOS.
I am not correct 100% of the time either, so you don’t have to only accept what I say, but I do know what I’m talking about so freqency of me being wrong on such things is low.
@Lost_N_BIOS
Thanks very much for your very clear opinion and I do agree to not FPT flash the ‘bios.bin’ output file of the UBU tool when the input file is a “BIOS region” dump.
As, at the moment, I have a programmer CH341A near the machine, but not working under W10 interface or Live USB Linux interface for some compatibilities problems with the BIOS component MXIC model MX25L12873F , I don’t want, for sure, to take the risk to brick the BIOS and get no solution to re-alive the BIOS.
I do agree totally also the “BIOS crash free3” function is a pure ‘marketing feature’ which technically does not make sense…
(As you said when a BIOS is dead and fully bricked, the minimum vital to offer under BIOS menu the “BIOS crash free” feature is also dead and bricked, and only one external action (such as a programmer tool) can re-alive the BIOS component).
So, at the moment, the only valid way to get a ‘FPT’ sure flashable modded BIOS is to provide you the stock BIOS file, the BIOS Region Dump file obtained from the “BIOS host PC system” via your Guide Lines, the list of items to mod and with your expertise you do manually mod the BIOS Region Dump file that can be finally is ‘FPT’ flashable on the “BIOS host PC system”.
@100PIER - As mentioned, it very well might be OK, but chances are high it’s not so it’s big risk to you if you do not have flash recovery tools and know how to easily recover from bad BIOS flash.
Sometimes crashfree BIOS might recover from certain bad flashes or corrupt BIOS, but not always, same as with all brand “BIOS recovery or protection” programs, you simply can’t rely on that especially if you only have one system and no working flash recovery setup.
I have the stock BIOS, I simply need the FPT dumps from you and all the mods you wanted done, as we originally discussed in PM but then you kept getting new BIOS come out from Asus so we had delays, and I was slow to reply in PM’s too (Sorry)
UBU may be able to edit some, or nearly all of those edits you made without messing up the BIOS (As I see it), it could just be the final microcode edit that breaks it all, hard to know.
If you want to know for sure which edit, and when etc, you’d have to edit in one thing at a time and then save that BIOS into it’s own folder with the file you edited in (so I know which edit it was for each folder/BIOS) and then do that for each edit one by one and send a bunch of single edited BIOS (All in one archive eventually)
Do the edits separately and save, so one BIOS has updated this only, next BIOS has updated that only, and so on, until you have a single BIOS for each of the edits. Then, I could check them all and tell you exactly what and when the BIOS gets broken.
This would be helpful for SoniX to know too I’m sure.
And yes, I could then edit the BIOS manually and you could then flash via FPT and we’d be done