@SoniX
Bug Report: I have a folder inside the UBU folder called "PhoenixTool v2.59". If I run UBU 1.9.1 it tries to load that folder and afterwards renames it to bios.bin.
I have removed the numbers temporarily but shouldn’t UBU detect only files? That’s a folder, that’s why I mentioned it.
Also, after v1.9 there have been certain spelling mistakes. Didn’t note all of them but run into this just now:
I thought it said Necrocode originally! 
I have removed the numbers temporarily but shouldn’t UBU detect only files? That’s a folder, that’s why I mentioned it.
To build a list of files clause is used that command DIR, it displays an as files and folders.
Added:
Text corrected. Thank you.
UEFITool 0.20.2 | UEFIExtract 0.4.2 | UEFIPatch 0.3.2 now available !
https://github.com/LongSoft/UEFITool/releases/tag/0.20.2
@SoniX
Hi
Realtek UEFI UNDI Driver 2.033 2015/2/12
http://www.realtek.com.tw/downloads/down…3&GetDown=false
I have a quick question. In the OP it says this tool isn’t intended for laptops, I was wondering what the reasoning was. The tool seemed to accept an image of my laptops BIOS and the updating of the modules appeared successful.
Certain things work but you need to know what to update and what not. For example there are some roms that have desktop and mobile versions (Intel vBIOS). Other times, mobile roms need to be customized for each laptop whereas that’s not needed for desktop. UBU includes only the desktop versions of such firmware, that’s why it’s only intended for desktop. If you know what you are doing though, you can use it for laptops as well (ex: Microcode).
Ok, thanks for the answer. The tool shows the microcode is already the current version, but the RAID and GOP modules are older versions. I’ll hold off for now, but I may try to use the tool if I can find some laptop-specific modules to insert.
@lordkag
If you are not hard, then please explain how you define the version in the GOP ValleyView?
For these files, I see that version are in full format.
Intel ValleyView GOP 7.0.1029.efi - "7…0…1.0.2.9"
Intel ValleyView GOP 7.1.1006_x86.efi - "7…1…1.0.0.6"
Intel ValleyView GOP 7.2.1008_x86.efi - "7…2…1.0.0.8"
For these files, I do not understand the origin of the 1 or 2 for completeness version?
Intel ValleyView GOP 7.1.1003.efi - "7…1.0.0.3"
Intel ValleyView GOP 7.1.1005.efi - "7…1.0.0.5"
Intel ValleyView GOP 7.1.1006.efi - "7…1.0.0.6"
Intel ValleyView GOP 7.1.1007.efi - "7…1.0.0.7"
Intel ValleyView GOP 7.1.1008_x86.efi - "7…1.0.0.8"
Intel ValleyView GOP 7.2.1003.efi - "7…1.0.0.3"
Intel ValleyView GOP 7.2.1004.efi - "7…1.0.0.4"
Intel ValleyView GOP 7.2.1007_x86.efi - "7…1.0.0.7"
Intel ValleyView GOP 7.2.1008.efi - "7…1.0.0.8"
If you use a package “#Extractor4” from lordkag in conjunction with the new DrvVer 0.17.0, the change value ‘5’ in
1
2
3
4
2
3
4
:inlver
::Version of Intel EFI Lan UNDI
...
for /f "tokens=5" %%a in ('drvver temp\%efiffs%') do set vers=%%a
to value '6'
1
for /f "tokens=6" %%a in ('drvver temp\%efiffs%') do set vers=%%a
@SoniX
For Intel GOP ValleyView I use a bunch of guesses. This is somewhat Intel’s fault, since they dropped the clear tagging used in Haswell 5.0.x and previous generations. Here is the working method so far:
- the version usually takes 0x10 bytes, but in 7.1.1008_x86 and 7.2.1007_x86 it only has 0xC bytes.
- like you noticed, some drivers have the full version, so I just take the version as is. If the 4th byte is not 00 and the next 3 are 00, then we have a full version.
- others have only major and build, so the minor must be guessed. In 7.1.xxxx, the version is followed by 00000000FF0000000000000000000000. In 7.2.xxxx, the version is followed by 000000000000000000FFFFFFFFFFFF00 or 0000000000FFFFFFFFFFFF0000FFFFFFFFFFFF, depending on version length (0x10 or 0xC).
Sadly, this will not be enough when 7.3.xxxx appears and will not work for 7.0.xxxx versions without the minor [0] version included. Only the size of the driver is a reliable method of determining the version.
@ lordkag
For UBU, as an alternative to displaying or "7.x.10…" or only build version "10…". 
You are amazing! You pump these out faster then i drink water! THANK YOU!
@Sonix
Hi, I have used the last UBU tool version and got this hang:
With all previous versions absolutely no problem and no freeze.
Please, can you investigate ?
UBU is a fantastic tool for the standard user like me.
Best regards
100PIER
I have also this error:
@100PIER
Strangely, I have no problem.
UBU v1.10.2 BIOS Asus Z77-V Deluxe 2104
Result - scr1
Added:
You some malfunction in the BIOS file, so it should be 3 modules ("Found 3 module(s)"), and you have shown only 2 modules ("Found 2 module(s)").
@SoniX
Thanks for your comments.
I dont’t understand why UBU v 1.10.2 detects only 2 modules … on my side.
Did you mod with UBU v 1.10.2 the original ASUS BIOS 2104 or a previous modded 2104 modded with UBU tool V 1.9.1 ?
My test was done using the last BIOS 2104 i had modded with UBU V 1.9.1.
Is this the root case of the problem ?
Regards
Original.
I do not think. I just did the update modules in version 1.9.1 and then update modules in version 1.10.2. Problems have arisen. All 3 modules were in place.
I myself have been using motherboards from Asus and therefore check the results to them.
Most likely there was a failure in the normal update process modules is rare, but it happens. Just take the original and make a mod again.
Best Regards
@Sonix,
Thanks.
I have done modded tests again.
If I take the ORIGINAL ASUS 2104 BIOS (18September2013) and make a modd with UBU V 1.10.2 the 3 modules are properly detected and modded BIOS works fine. OK.
But If you take the original ASUS 2104 BIOS and make a modd with UBU V 1.9.1 and then modd again the obtained BIOS but using the UBU V 1.10.2 you should have the ‘2 modules’ only problem I reported you.
Thanks again for this very helpful UBU tool.
Best Regards