@100PIER

Let me remind you again.
[UBU v1.71-1.72]
MMTool in your case is not used at all. Only UEFIReplace (based UEFITool) is used.

UBU will report if MMTool is required.

@Sonix, Thanks.
I was not sure if when MMTool is present in UBU folder it was used by prority over UEFIReplace or not. Now it is clear for me.
Does the "MMTool is required" invite criteria is only for BIOS Aptio V and when for some user specific edit such as "µCodes updates" or for any other criteria ?

By the way, did you remember the provisoire fix you indicate me few times ago into a previous UBU version to avoid Windows Explorer crash at UBU tool exit ?
I thought it was fixed definitively but I do observe a such problem again with UBU v1.72.1 as reported in post #90 (the downloadable 7zipped file offered via the link does offer the full UBU v1.72.1 folder, so you can do the in-depth analysis of the full UBU folder and check again why the problem does re-appear again).

And so, I will try to explain again how UBU works.

Grab the file and define some parameters of the BIOS image:
- Platform AMI Aptio /InsydeH2O/SCT Phoenix/Intel Insyde..
- AMD or Intel
- If Intel is the presence of _FIT_ and how many containers with microcodes

Search and extract files EFI and OROM.

UEFIFind and UEFIExteact are responsible for these actions.


Next "Main Menu" and "Sub Menu"
- UEFIFind, UEFIReplace and UEFIExttact utilities are working everywhere.
- An exception is only for OROM on Aptio 4. MMTool is required to replace them.

[mCode]
Replacing microscopes has several options.

AMD Aptio 4 Platform
- UEFIExtract -> mCodeFIT -> MMTool

AMD Aptio V Platform (Ryzen)
- only mCodeFIT, since microcodes are located in padding.

Intel
- If there are more than one container, then only MMTool is used. Since they are located mainly in PEI-volume. UEFITool cannot work correctly with such volumes.
- If the microcode container is one, then UEFIReplace is used. UBU version 1.73 will allow the use of MMTool as an alternative method. Replacement is similar to that of MSI x299.

+ mCodeFIT for offset correction.


About "Exit" and so everything is clear.


In fact, the work of UBU is in many ways similar to the user's manual actions.

@Sonix
Thanks for your clear synthesis on how UBU does work.

I have tried v1.73 and got some problems:

1) why when Windows Explorer does remain opened on UBU folder does crash at UBU exit:


2) when trying µCodes update (without MMtool presence) I got this error, my antivirus is educate to whitelist all the UBU folder. But, is there any reason to get this kind of error ? Does UBU use the default browser of the PC at any time ? If yes, I think ( a pure assumption) my antivirus (Iobit Fighter Antimalware v7.0) also has to take time to be educate to accept a 'non-standard' operation thru the web-browser. (at the second attempt after a popup menu invite acceptation the second attempt was accepted..)


3) according your Post #91 I should NOT need MMTool presence and with this version v1.73 I get a contrary invitation message to use MMTool.
If MMTool is not present I do observe the µCodes modding operation is not done.
And after installed MMTool_a4 the µCodes operation has been accepted.

@Lost_N_BIOS
I have done some BR2401B tests with new UBU V1.73.
The MMTool presence is required for this version when trying mode µCodes. I have used MMTool_a4 to get accepted µCodes Edits.
Here are 3 "bios.bin" 7zipped: BR2401B_UBU173_14apr19
One get with Multiple Edits [RST+GOP+LAN],
One get with Single Edit [µCodes] only,
One get with full Multiple Edits [RST+GOP+LAN+µCodes]
Do you need more "bios.bin" ?

@100PIER

I do not know why you have such problems.
UBU runs in a regular DOS console (cmd).
Maybe the problem is in the antivirus, maybe in the special settings of Windows.
I checked on:
- Windows 7x64 (UAC disabled) + ESET IS
- Windows 10x64 (UAC disabled) + Windows Defender
- Windows 10x64 (UAC disabled) + ESET IS
I do not observe problems.

I have already explained in which cases MMTool may be required.

Short question, is MMTool 4.50.0.23 still viable for service Aptio 4 BIOS with UBU and as standalone BIOS editor? Because in other thread recommend using it for just Aptio 4 BIOSes compare to what here prefer 5.0.0.7 as universal MMTool for both Aptio 4 and 5 with no trace of 4.50 mentioned.

@100PIER - sorry, but I don't want to download 500MB to check BIOS issues. I have no opinion on MMTool and only use it myself when forced to (very rarely), but as SoniX said multiple times it's not used anyway for your BIOS.
I only needed you to modify BIOS once, with all edits except microcodes, then I can see if microcode edit is the one breaking the BIOS as I see it, or not. If you want to include one by one as I suggested >> RST modules, GOP, LAN, ucodes, then only 4-5 BIOS files would be needed.
If we wanted to see if one of the others aside from microcode is breaking the BIOS (How I see it currently, and referring to previously posted UBU created BIOS mods before all this discussion BR2401Bmodded-via_UBU_07apr19)

Now, I downloaded your BIOS linked in post #96 -

biosRSTGOPLAN.bin (Has modified ucodes too vs stock 2013? +1 ucode count vs stock, unless you are using some other stock BIOS than 2013?) - Anyway, this BIOS OK to flash via FPT
biosµC.bin - Broken BIOS due to the same two exact issues I outlined and showed images of in post #78 - I advise you do not flash this BIOS, unless you are ready and able to recover via flash programmer. It might be OK, but I would not risk it without flash programmer in hand.
biosRSTGOPLANµC.bin - same as above

Here is updated BIOS safe to flash, I used your biosRSTGOPLAN.bin and updated microcodes manually and then fixed FIT. This was done using UEFITool 25.0, do not use 26.0 or same issues occur.
If you want UBU to be able to do this, for your particular BIOS/case, I believe putting UEFIReplace 25.0 into the UBU folder in place of current one, then it will be OK/Same as I'm doing here (Have done this in past and worked out properly)
http://s000.tinyupload.com/index.php?fil...913811624792532

@vuze4u
mmtool v5.0.0.7 for Aptio IV BIOS ,remamed as "mmtool_a4.exe"
mmtool v5.2.0.24 for Aptio V BIOS,renamed as "mmtool_a5.exe"
I have copied both two versions of MMTool to root of the UBU directory.

@Lost_N_BIOS, @Sonix

Lost_N_BIOS: Many Thanks, your provided manually modded µCodes of the biosRSTGOPPLAN.bin file is exactly what I expected.
Yes, stock 2013 is obsolete, the last stock is 2401, and yes ASUS has modified 3 µcodes for the 3 CPUIDs offered into 2013 stock and also added +1 new µcodes for a new CPUID.

Sonix: you said multiple times that I no need MMTool for this bios but UBU tool v1.73 said the contrary !



and after enter any key the original µCodes values is re-displayed:



Lost_N_BIOS:
1) Can you confirm me the manual µCodes you applied does correspond to the first displayed screenshot ?
906EA: 9A=>AE, 906EB: A4=>AE, 906EC: A0=>AE, new 906ED: B0

2) Your last recommandation is to replace the current UEFIReplace tool into UBU folder with UEFIReplace v25.00
Where can I get this exact version ? A link somewhere ?

Sonix:
The current UBU v1.73.0 does require MMTool for this bios, so UBU does seem to ignore UEFIReplace.
So, I don't see how 'to force' UBU to use UEFIReplace v25.00 instead of MMTool requirement.
Please, can you clarify ?

@100PIER - You're welcome! And sorry, I didn't notice 2013 was older BIOS this entire time I thought it was latest. All I mentioned about 2013 makes sense now

I used your ucode update BIOS as the source of microcodes, extracted via MC Extractor and then I rebuild the microcode body myself in hex.
So yes, all the same as you put, and all the latest, sorry I didn't include MC Extractor image previously after the mod/update, see below


UEFIReplace 25.0 is here - https://github.com/LongSoft/UEFITool/releases/tag/0.25.0 And all versions are here - https://github.com/LongSoft/UEFITool/releases
I don't use UBU often, but I have done this replace UEFIReplace method in the past when current versions were causing this exact same issue and UEFITool 25 worked when 26 didn't.
Replacing UEFIReplace from V25 worked as expected just like UEFITool 25. As for the current UBU issue and MMTool/UEFIReplace question and issue you are having now, yes, that would need to change before you could make it use the swapped out UEFIReplace 25

As for current versions UBU and UEFIReplace inside standard package, I cannot comment on how it would treat this BIOS, I've not tested that but assume like UEFITool 26 it will break the BIOS at the two instances I pointed out and showed images of at post #78

@Lost_N_BIOS
Thanks a lot, it is very clear and the modded BIOS Region you offered me is exactly up to date and as expected.
Thanks for the 2 links. UEFIReplace v25.0 for Windows is dated on 02 june 2018, current UEFIReplace in UBU 1.73.0 folder is dated on 07 january 2019.
Yes, I let Sonix to fix the current UBU issue about the MMTool/UEFIReplace question before to use the swapped out UEFIReplace 25.

You're welcome @100PIER - and yes, I know version 25 is older, this is the one that works in your BIOS instance, some can use current/latest versions, others for certain things you need to use older version.

You can use the BIOS I made you while you wait (and or use it and be done messing around), if you want, or yes wait on SoniX to let you know what to do about UBU 1.73 version.
You could also use 1.71 version too maybe, if it doesn't give you the MMTool/UEFIReplace issues, but replace UEFIReplace if you do use that version too in case it doesn't use MMTool.

@Lost_N_BIOS,
Thanks so much, I plan to FPT_dos flash your "hand made" BIOS asap for my basic Z390M-Plus system and let you know the result.

Hi SonicX. Decided to try out the new version of your tool after not using it in quite a while. I'm experiencing the following error when updating a few components of an Asrock z77 pro4 2.00 beta bios. It does this for both the microde and rst, maybe others if I recall.

"praseFile: invalid data checksum 5ah, should be AAh".

Can you assist? see attached image. bios is at https://www.asrock.com/mb/intel/z77%20pro4/#BIOS