@SoniX
Welcome back to the Win-Raid Forum!
It is wonderful, that you are still working on the UBU tool!
>Here< is the download link (as *.rar archive).
Changelog (as far as I could recognize it):
Good luck!
Dieter
Changes:
EFI GOP Driver TigerLake (v17) CHANGED TO EFI GOP Driver Xe
Updated:
Updated EFI Realtek UNDI Driver 2.065
Report:
We still have an “Unknown Intel LAN version” for the Intel I225/226 (2.5Gb) on Intel 600/700 bios releases.
@SoniX It’s great to see you are back!
BTW the file UBU_v1_79.19d is missing the .rar extension.
That is why I have renamed and uploaded the file as *.rar archive to my MEGA account.
Thanx ALL.
I didn’t leave. There was also a period in life that needs to be lived through.
There will be updates, but not as fast as before
The good old link
@SoniX
That is indeed very good news for this Forum and its users. Thank you very much! 
Will you be able to post the changelog and comments into >this< already existing thread?
That would be really great!
@SoniX I’ve always wondered why you’re using precisely the version 0.25.0 of UEFITool and UEFIReplace and not the latest version 0.28.0. I’m just genuinely interested if there is any particular reason for it. I am not trying to be rude or anything. Thank you for your support of BIOS modding. UBU is really awesome tool.
I forgot to add it to the archiving list.
But all versions of UEFITool/UEFIReplace, unfortunately, create unpleasant problems for modding.
I do not know if the old utilities will be changed or not. I need to consult with CodeRush.
Welcome back, its been a while! 
I forgot to tell you.to say
Updating microcodes is more reliable, since MMTool is used and the problems mentioned above do not arise.
OK, I’ve come a full circle, and now I see your point a bit more clearly 
First of all, the BIOS boots fine with the inserted NVME & ReBar modules, so there are no issues there if things are added to the empty area in the back:
Now, to the MC replacement story.
I tried to run UBU tool, and then in MMTool_a4.exe tool I extracted the MC block from the original BIOS, extracted the same block from the UBU MC modded BIOS where the MC block shrunk, then padded the modded MC block back to the original size with FF, and did a replacement in MMTool_a4.exe for that particular GUID. Unfortunately, it’s a no go and it then could not find any microcode for the cpu that happened not to be listed first. Also, MMTool_a4.exe seems to have changed some bytes before 0x580060 where the microcode is supposed to start.
UBU tool thought the MC modded bios was OK, but I guess that did not help much.
Do you then recommend that I take the orig BIOS, pull each MC code I want from the library, pad it first with FF to the prior size, then paste these MC file contents on top of the BIOS at the right address? So everything would have dead space at the end since microcodes shrink. For example, I have dead space with FF between 2nd and 3rd microcodes in the original BIOS that UBU tool simply removed (see the 2 images below) and that’s probably a bad thing.
I wish UBU tool tried to honor the pre-existing sizes a bit more strictly if that’s possible to achieve …
P.S. Here is an extreme BIOS for this computer that had tons of microcodes. It seems they all get padded to either X000 or X800 sizes, so non-round microcodes get extra FF.
P.S.
SoniX - how simple would it be to have the UBU tool try to place the new microcodes at the pre-existing boundaries? Basically, if the new size is smaller or the same as before, keep the next MC start address as it was. A padded bios file is attached for reference, same as the picture above, J318.
J61_0318.zip (6.0 MB)
I tried your UBU_v1_80_a5 alpha on a AM5 Gigabyte B650E Aorus Master F30 bios F30 bios
As someone already noted, would be really great if UBU recognizes I225/226 NICs.
But nevertheless I would like to mention one error notice on scanning ucodes (5) which states an error
I used Python python-3.12.4-amd64 and MCE DB r298. Also compiled myself a mce.exe with same error outcome.
Really appreciate all your effort on UBU!
error
Because you replaced the bundled MCE.py
Newer MCE.py versions do not support the -ubu command line switch
Alright, the manual editing process ended up being very idiosyncratic. Kept the microcode area the same in size, padded excess at the back with FF when microcodes shrunk. Also tried to pad each microcode instead to keep the same addresses - created issues! The original BIOS already had 8KB of padding at the end of the microcodes, so I ended up increasing that area by a bit when microcodes shrunk. Offsets had to be either 0x060 or 0x860 at the end, since all official bios versions did that. Original:
Original:
Copied the same stuff from another working bios, J391, padded the end:
Increased the 1st microcode in the previous one, so had to shift things down by a bit:
I am looking for some help to update the BIOS of an NZXT N5 Z690 board with the latest Ubutool from Sonix (1_80_A5).
In which directory am I supposed to put the latest Intel VMD EFI file which is named VmdDriver.efi? Neither >Files>intel>RSTe_VROC nor >Files>intel>RST work. At least the tool doesn’t recognize that file. Also creating a new folder named VMD under >Files>intel doesn’t seem to work either.
I’ve managed to update the latest LAN components of the BIOS, but the modded BIOS file doesn’t get past the safety check of the instant flash utility of the motherboard. Does anyone know a save method to circumvent this check without bricking the board? Asrock is the manufacturer but couldn’t find a solution yet.
I think it’s all 100GbE (4.0.25, 4.0.48, 4.1.23, 4.2.34, 4.2.65), no?
(~329 KB - 359 KB)
EFI_Intel_100GbE_UNDI_4.2.68.rar (115.2 KB)
Nothing to do with any motherboard. This is a completely manual list, I added the files. The only issue is the correctness of the naming. I think they are all 100GbE files (not PRO1000), but you know better, that’s why I ask.
Intel (R) PRO/1000 for E810/E82x/E83x series.
Add:
ICS - APPS\EFI\x64 Intel(R) 800 Series Ethernet Driver - ExxxxX8
Thanks for re-naming the directory with the latest 1_80_A7, SoniX. I’ve also forgotten to re-name the Intel VMD file to the one stated in the readme. Now the VMD file gets recognized correctly. I still need to find a good method to circumvent the safety check though.
