So,
OROM VBIOS Haswell is excluded from UBU now?
(latest has been 2177)
So,
OROM VBIOS Haswell is excluded from UBU now?
(latest has been 2177)
Yes.
Latesr version OROM VBIOS Haswell - 2179. If you find a BSF file for 2179 it will be great. Can be customized using the program BMP. Look here…
@Sonix
Are you saying you flashed a BIOS just to check the version of an EFI module? I have searched a better way and since you have access to a larger database, could you confirm my findings?
For Intel Lan EFI just check for 20 0C 9A 66 and look a few lines bellow. It is located alone on that line and just above a white line.
For Intel RAID, GOP, SCU just check for 49 00 6E 00 74 00 65 00 6C 00 (hex for I.n.t.e.l.) and look bellow. If you want to be more precise, for coding a finder (if you haven’t already):
For Intel RAID RST check for 52 00 53 00 54 00 (hex for R.S.T.) and the version is next to it.
For Intel RAID RSTe check for 52 00 53 00 54 00 65 00 (hex for R.S.T.e.) and the version is next.
For Intel RAID SCU check for 52 00 53 00 54 00 65 00 (hex for R.S.T.e.) or 53 00 43 00 55 00 20 00 44 00 72 00 69 00 76 00 65 00 72 00 (hex for S.C.U. .D.r.i.v.e.r.) and the version is next.
For Intel GOP check for 47 00 4F 00 50 00 20 00 44 00 72 00 69 00 76 00 65 00 72 (hex for G.O.P. .D.r.i.v.e.r.) and the version is somewhere bellow.
For Broadcom Lan EFI check for string UNDI_VER and the version is 3 lines above E4 14 45 16 E4 14 and also directly above a white line.
For Realtek UNDI EFI I couldn’t find any pattern, but it doesn’t matter, since they are posted in Realtek download section.
The number of digits seems to follow the power of 2, for both groups and overall (e.g. 1.5.48, 2.024, 2.0.6.6, 15.4.7, 12.7.0.1936, 1.0.0.1038).
All the above search was done in uncompressed modules. If you have some that don’t follow the rule, maybe you could share them.
@lordkag
Correctly. 
Add a little.
Version EFI Realtek UNDI almost as Intel UNDI version. In all versions in one place.
And unfortunately not yet sorted out the modules Qualcomm-Atheros/Bigfoot. Therefore it is necessary to use the EFI Shell to determine the exact version before looking in Hex-editor.
If there is interest in finding versions QCA, then attach the archive known and not known versions.
qca.rar (36.1 KB)
@Sonix
Thanks for the samples and for the Realtek tip. I haven’t found anything yet for Atheros and I’m afraid it could require some disassembly. If you search for 25 64 2E 25 64 2E 25 64 2E 25 64 you will find the version in blank, that it is probably filled by a call to some instructions.
This is how it looks for qca_1.1.0.3.efi. Maybe someone fluent in this language can spot something in there.
I have found a more precise way for Intel Lan EFI.
Now something that might not be related to UBU. In the BIOS posted here by greg.chalk there is a problem with Marvell controllers. UBU sees the first 9192, but fails to see the second 9230 (because it is invalid).
This is how the first looks, which UBU wrongly reports as being inserted twice.
This is the second, which can’t be detected or replaced.
This is how I solved it: replace the yellow section with valid input (in this case 20 00 4B 1B 30 92), correct the checksums in CSMCORE (I only had to replace something in a padding zone until the module’s checksum-8 became F8), save and reinsert CSMCORE, then use UBU or MMTOOL for replacing that OROM with a new one. The only problem was that UBU still reported the first one twice (alongside the newly detected 9230), which is a bug in UBU, I think.
How can the checksums recalculation in CSMCORE be automated after hex editing? Is there a tool for this? How many checks there are, besides checksum-8 for module (=F8?) and hex length in header? Is 10h and 11h involved like in Insyde headers?
@lordkag
Why are you trying to upgrade OROM 9230? Does the motherboard have this chip? I would delete this OROM, since it “garbage”.
If believe the specification of this motherboard there only Controller Marvell 88SE9172. What is also strange because OROM 9192.
Yes, plenty of them:
1. UEFITool, the "Rebuild" action on CSMCORE will do it.
2. PhoenixTool, by using "Allow modification of other modules" and "No SLIC" mode and replacing CSMCORE manually.
3. GenFFS from EDK2 toolset, by generating new FFS header with correct checksums using modified CSMCORE with removed header.
There are 2 checksums in the FFS header (and CSMCORE is a normal FFS file with type RAW): header checksum and data checksum.
Header checksum must be recalculated only if file size was modified, data checksum must be recalculated after any data modification, but the whole data checksum thing can be disabled by clearing FFS_ATTRIB_CHECKSUM attribute in respective FFS header filed. Files with cleared attribute have standard 0x5A (old) or 0xAA (new) values in data checksum field.
0xF8 on the end of FFS header is not a checksum, it’s a state of the file. For volumes with ERASE_POLARITY=1 (all volumes in all modern UEFI BIOSes) 0xF8 means (HEADER_CONSTRUCTED and HEADER_VALID and DATA_VALID), indicating a valid FFS file. The field must not be altered.
No.
@ CodeRush:
Welcome at Win-RAID Forum!
Your presence within this Forum is much appreciated, because there are not many people with your knowledge regarding BIOS modding.
Enjoy the Forum!
Kind regards
Fernando
Will do. 
I used your newest version and added the new VBIOS OROM for sandy bridge and it bricked my board i had to use bios recovery, board is MSI H61 E33/W8 can you check this out for me, i like your tool i just don’t want this tool to brick any of my new boards i get. I could of had a bad flash but it completed 100% but i don’t know. Just check and confirm it works on your board. also do you think this utility will work on asrock z77 Extreme 3?, thats the board i ordered.
@ GlitchyJoey:
Welcome at Win-RAID Forum!
I am sorry about your problem and hope, that SoniX can help you.
Regards
Fernando
Thanks, Reason i ask about the asrock board is because i don’t think they have bios recovery and if i mess up once i am screwed.
I sincerely apologize to all for derailing the topic.
@CodeRush
I start by stating that this was not for my board, nor will I need it in any way. Just for training purpose. I now have started reading the EFI specs, for not guessing anymore how it works based on one case.
I had already used the first 2 tools, but not properly. With UEFITool I saw that “Replace” is not yet activated, but it didn’t crossed my mind about using “Insert before/after”. With PhoenixTool 2.14 I forgot to remove the header, triggering an error, which it seems I failed to read since it was about a malformed header. It seems that version 2.50b2 is removing even more than the previous one. I have just used GenFFS, but if I set the type value to the one from CSMCORE (_DRIVER or 07), it asks for PE section, if I set to _RAW or 01 it works, but then I have to manually correct, which makes GenFFS useless from this point of view. I now know that it is the 11h byte (file checksum) that I must correct, leaving 10h and 14h-16h unaltered until size changes.
When I was referring to F8, it was the file checksum that I had in mind, not knowing that it must be 00 (without state value) and that the state value rounds it to F8 (or else). What still bugs me is that after MMTOOL replaces an OROM, it also alters the value in offset 0000D64D when the size changes.
Anyway, your tool does the job in the least amount of time and if it fails, I now know how to properly correct it. Love your work and I appreciate how you go the extra mile just to help a lost fellow.
@ GlitchyJoey
I do not have time to check out the new VBIOS 2170.
Do you have a problem with VBIOS 2170? More than it is expressed in?
Which video ports are you using?
Your motherboard works with VBIOS 2143/2158 and if no updates VBIOS?
Zitat von Gast im Beitrag #220
I used your newest version and added the new VBIOS OROM for sandy bridge and it bricked my board i had to use bios recovery, board is MSI H61 E33/W8 can you check this out for me, i like your tool i just don't want this tool to brick any of my new boards i get. I could of had a bad flash but it completed 100% but i don't know. Just check and confirm it works on your board. also do you think this utility will work on asrock z77 Extreme 3?, thats the board i ordered.
I doubt it bricked your board. Try inserting a spare video card and see if you get anything to show up on your monitor. I've inserted the incorrect vBIOS for my Biostar board before and was able to recover by added in a discrete card to reflash the BIOS.
@SoniX , I was able to test out VBIOS 2170 on my ASUS Maxmius V Gene and got the rear video ports to work.
Also,
for Z77 GB boards VBIOS OROM 2170, working well:
http://forums.tweaktown.com/gigabyte/480…d-bios-288.html
@lordkag
I will go extra light year to assist and help people, that are capable to read documentation, lurk into disassembly and share their findings with others. Because they are that rare nowadays.
“Replace” action was once a combination of “Remove” and “Insert after”, but then I decided to disable it, because “Replace” will be like “Extract” when it will be implemented: “As is” and “without header”.
Header must sum to zero, not counting state byte, because it can be changed by volume management code any second of file’s life. Read more in chapter “Creating, Replacing and Deleting a File” in Volume 3 of UEFI PI specs.
If you have found a bug in UEFITool, please report it here. For a month of having UEFITool in public I’ve receeived only one useful bugreport from english-speaking community, which I find acceptable, but a bit too few.
I use a GTX 650 dedicated gpu. all i know is when i added the new 2170 bios my board bricked. all it owuld do is turn on and turn off. it was looking for a usb drive with a bios file on it to recover and it said bios is corrupt. so could the new 2170 VBIOS of bricked my board from booting if i don’t use intel HD graphics?
EDIT 1:
I was already using a dedicated gpu never use intel graphics. So i guess i had a bad flash then?
EDIT 2:
The other things i did besides adding the new VBIOS is i opened up AMIBCP4.53 and edited some names of strings (which i always do and it works) then i used AMI change Logo program to change my logo which i always do on my boards if i mod bios, and i know all that stuff has worked for me before and the only thing different was the new VBIOS so i assumed it was that, but i’m guessing it was just a bad flash would you say? Cause i flashed it within windows 7 using the AMI bios flasher from AMI.com and it has always worked for me before, but i should never flash in windows?
EDIT by Fernando: To save space I have put the 3 posts together.
Until I found one difference between 2158 and 2170.
2158
2170
Edit:
The second remark. In 2158 setting is on SandyBridge, and in 2170 - IvyBridge.
@ GlitchyJoey
Ok. Try not to update VBIOS, refresh only EFI SataDriver. What will happen?
Edit:
Generally BIOS MSI H61 E33 very interesting. It is necessary to make some adjustments to UBU 1.1.4, since it does not appear EFI GOP and EFI LAN.