@konstantiniyyr
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.

Zitat von SoniX im Beitrag #60

---

@KedarWolf
I'm sorry for the delay. I uploaded a new version of mCodeFIT v0.6.7, which now fixes the _FIT_ offset to the correct one.

---

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.

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.