A readme and/or instructions on how to actually compile would be nice...

Would you like to replace more defines for constant values by enumerations to stress their relationships?

• FLASH_DENSITY_…
• IMAGE_FILE_MACHINE_…

Looking at some Lenovo UEFI BIOS (downloaded from Lenovo's website) I get the following:
parseVolume: unknown file system FFF12B8D-7696-4C8B-A985-2747075B4F50
parseVolume: unknown file system 00504624-8A59-4EEB-BD0F-6B36E96128E0

Digging into these I have found credible references for both of these:

1. FFF12B8D-7696-4C8B-A985-2747075B4F50 is "EFI_SYSTEM_NV_DATA_FV_GUID" according to edk: https://github.com/tianocore/edk/blob/master/Foundation/Guid/SystemNvDataGuid/SystemNvDataGuid.h#L26

2. 00504624-8A59-4EEB-BD0F-6B36E96128E0 is "ADDITIONAL_NV_STORE_GUID" according to chipsec: https://github.com/chipsec/chipsec/blob/master/source/tool/chipsec/hal/uefi_platform.py#L512

Both of these seem to be used for storing NV ram settings.

Please include these GUID translations in the next update =)

No more candies for you, mister!

• I thought this issue is solved in both branches? It looks to be solved in new_engine, based on the UEFIFind_0.10.2 you provided, but not in master branch.
• Maybe I haven't opened Gigabyte images for a long time or this issue is recent, but UEFITool (both branches) is showing an error. It fixes Gigabyte's bug/feature of BIOS region base, but it then uses the initial wrong size to check for image consistency. Take any image from Station-Drivers as an example.

This tool and applications like it are, in my opinion, vital gateways to user-owned and hack-friendly firmware. It can do no one any good, however, if it is undocumented. I would like to assist in this effort if you'll allow it, but I'll first need to understand how it works.

A simple README with build instructions is the first step, I think. I will draw one up, and possibly a POSIX shell build script if you will guide me.

Seriously, thank you for putting in the effort to create this tool.

( An example of just how wordy I can get: http://www.coreboot.org/pipermail/coreboot/2013-October/076442.html )

• Switch to dump only leaf items, will greatly simplify parsing of the .dump folder
• Finish deQtzation of the new_engine, release UEFIDump

Hi,
I try to replace a modified PE32 image, but i only have Extract body option selectable. Replace body is gray in menu. I use 0.30.0_alpha21 of tool. The same on Mac and Windows...

Can help ?

I am trying to create PKGBUILD for Arch Linux, but I cannot do this, until I solve problem of compiling.
UefiTool itself is not a problem, compiling normally.
But UefiExtract fails to compile:

qmake-qt5 uefiextract.pro
make

g++ -Wl,-O1 -Wl,-O1,--sort-common,--as-needed,-z,relro -o UEFIExtract uefiextract_main.o ffsdumper.o types.o descriptor.o ffs.o ffsparser.o peimage.o treeitem.o treemodel.o utility.o LzmaDecompress.o LzmaDec.o EfiTianoDecompress.o moc_treemodel.o -lQt5Core -lpthread ffsparser.o: In functionFfsParser::parseNvarStore(QByteArray const&, QModelIndex const&)':
ffsparser.cpp:(.text+0xfd4a): undefined reference to nvarAttributesToQString(unsigned char)' ffsparser.o: In functionFfsParser::parseVssStoreBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1c559): undefined reference to efiTimeToQString(EFI_TIME_ const&)' ffsparser.o: In functionFfsParser::parseFlashMapBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1f133): undefined reference to flashMapGuidToQString(EFI_GUID_ const&)' collect2: error: ld returned 1 exit status Makefile:340: recipe for target 'UEFIExtract' failed make: *** [UEFIExtract] Error 1

Also for UefiFind

qmake-qt5 uefifind.pro
make

g++ -Wl,-O1 -Wl,-O1,--sort-common,--as-needed,-z,relro -o UEFIFind uefifind_main.o uefifind.o types.o descriptor.o ffs.o ffsparser.o peimage.o treeitem.o treemodel.o utility.o LzmaDecompress.o LzmaDec.o EfiTianoDecompress.o moc_treemodel.o -lQt5Core -lpthread ffsparser.o: In functionFfsParser::parseNvarStore(QByteArray const&, QModelIndex const&)':
ffsparser.cpp:(.text+0xfd4a): undefined reference to nvarAttributesToQString(unsigned char)' ffsparser.o: In functionFfsParser::parseVssStoreBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1c559): undefined reference to efiTimeToQString(EFI_TIME_ const&)' ffsparser.o: In functionFfsParser::parseFlashMapBody(QModelIndex const&)':
ffsparser.cpp:(.text+0x1f133): undefined reference to flashMapGuidToQString(EFI_GUID_ const&)' collect2: error: ld returned 1 exit status Makefile:340: recipe for target 'UEFIFind' failed make: *** [UEFIFind] Error 1
The corresponding line numberrs are:

• 3132 for nvarAttributesToQString
• 4225 for efiTimeToQString
• 4643 for flashMapGuidToQString

Also, where did UefiPatch disappeared from new_engine branch?

What a better way to start the new year, than with a bug report? Get back to work, lazy human, bring me the ultimate tool for slashing UEFI!

• I've noticed a new Lenovo capsule E20BAFD3-9914-4F4F-9537-3129E090EB3C in this file. Use Universal Extractor or InnoExtractor, then BEEF or /cap or /ext to get the BIOS.cap file.
• Add Lenovo capsule GUID
• Why do I get UEFIFind error code 8, when doing a mass search on this file? It's not limited to this file alone, just a sample. The common ground seems to be when there is nothing found in any of the patterns. The weird part is that I get this error code when capturing the output with Python, thus UEFIFind displays the result, but somehow returns error code 8.
• Check the reason of returning ERR_ITEM_NOT_FOUND from UEFIFind
• In this file there is a decompression error for those "non-UEFI data found in sections area". UEFIRomExtract can decompress it.
• Improve detection of which Tiano/EFI1.1 algorithm is used for a particular compressed section
• Prevent duplication of decompressed data
• I'm getting a QString error when using UEFIExtract on Intel signed sections.
• Check the interaction between UE and signed sections
• Another Lenovo capsule 25B5FE76-8243-4A5C-A9BD-7EE3246198B5 in these files, also again UEFIFind error code 8 with CAPSULE_A.scap.
• Add another Lenovo capsule GUID
• In the same archive, for file SPSFullME.bin, is there no check for the space between regions? As you can see, that file is using one of the reserved regions to map the space between 0x1000 and 0x11000.
• Add padding between flash regions, if detected
• Not an actual bug, just rounding to magic number 7 and checking your devotion to the robot cause. Can you feel me?
• --I can feel you. --Nothing is gonna stop me now!
• Wait, I lied. When opening images like SPSFullME.bin, with no volumes or bios region, no offset is shown for rest of the regions. I don't expect the fancy fields (memory address, compression, fixed) to be present, but the offset should be known and displayed. In 0.30.0_A18 I'm not getting an offset at all, in any image. But this might be due to my building tools, as I mentioned in the PM.
• Try adding offset information even if parsing is failed

I was just testing whether I could modify a BIOS binary with UEFITool and write it back to the machine with an SPI programmer. I just randomly picked a PEIM, PchSpiPeim out of this HP BIOS. I right clicked the PE32 within it and did "Extract Body" and saved out the PE32 file. Then I opened it in CFF explorer, went to the end of the .text section, and changed some padding 0s to 0x90s. Then I went back into the file, right clicked on the PE and said "replace body" and selected the modified PE with nops at the end. But when I do this, UEFITool starts displaying 2 PE sections under that GUID. I can see it's set to rebuild the file, but when I save it out and open it again, there are still two PE sections under the same PEIM file GUID. Am I doing something incorrect? Despite the extra file, the BIOS is still bootable. It's just that I don't know if I made a meaningful change if it would actually be using the proper file.

The HP BIOS I'm modding is available here:
https://drive.google.com/file/d/0B-fqKYB_fAF-aFQ0TW1BN2pweTA/view?usp=sharing

(While I'm submitting I should also say that when I try to replace a DXE file within the compressed volume, it seems to do the replacement correctly, but the resulting BIOS is un-bootable once written back to the HP. I just don't know how I could help debug this for you... But if you have any thoughts feel free to email me at my username at gmail and we can guess and test things.)

With qt ver.4.8.5 name conflict with `struct _XRegion* Region ' occurs.
I quick-fixed addind namespace: https://github.com/6vasia/UEFITool/commit/73bbcda5002cbe88c8e1c94de904ff684da2a736

It's an issue indeed, but no one can do something about it.
I've began UEFItool's development about 10 months ago, and there are still only very few issues reported.
Hey, users, am I achieved perfection with this peace of poor C/C++ mix or you are just too shy to report anything? 😄
Please go ahead, I know there are many flaws here, but I keep forgetting about them and issue tracker will help me remember.

• Add well-known GUID database support

It would be nice if you could load a file with GUIDs and descriptions (or maybe this would be compiled in) and the UI would display the description along with the GUID.

Here's a script that will scrape GUIDs from .dec files, from e.g. TianoCore EDK2:
https://github.com/jethrogb/uefireverse/blob/master/guiddb/dec2c.rb

Hi,

UEFIExtract will not use the GUID for firmware volumes for OS X EFI images. It instead uses "AppleCRC32 AppleFSO" text field that shows ip on UEFITool.

Instead of this code in FfsEngine::recursiveDump
QString childPath = QString("%1/%2 %3").arg(path).arg(i).arg(model->text(childIndex).isEmpty() ? model->name(childIndex) : model->text(childIndex));
it probably should be
QString childPath = QString("%1/%2 %3").arg(path).arg(i).arg(model->name(childIndex));

Personally I find it more useful to have the GUID as folder name instead of that text.

Best,
fG!

i have issu in bios lenovo t460 win i make chang in module laptop npt work
i have teste all version uefitool
i have ather lenovo t450 i can mak modification withwot problem uefitool work gret
i think problem in compression of module
thinks for your help
if you want bios dump for t460 i can send it and for t450 if you want compar bitwin
sory for my english

Most files have a BSD LICENSE header, but there is no explicit LICENSE.md file of the BSD license.

Take this Intel file.

• File F5CF71AB-B04B-4B7E-988A-D8A0D498E692 is not reporting Data checksum as invalid, but it gets fixed anyway after saving the file.
• Some files have FFS_ATTRIB_TAIL_PRESENT and EFI_FFS_FILE_TAIL is present in those. UEFITool reports the wrong size (minus tail) and extracts the file with reported_size + 1 (or tail cut in half). If I try to change a byte in such a file (example 140BAF0E-8D12-478F-A0B4-17B9B7B5CEED), it fixes the tail, but tail is shifted to right by 1 byte, so it results in first byte of old tail being included in file next to new tail. This time, the size of file is accurately reported (if you ignore the fact that it added an extra byte), but it gets extracted as reported_size - 1. Volume GUID 7A9354D9-0468-444A-81CE-0BF617D890DF is revision 1, shouldn't all this be supported in UEFITool?
• File 4A538818-5AE0-4EB2-B2EB-488B23657022 is a mess, all the sizes are wrong, even after removing Intel custom data at top and bottom. File C62B4EFE-9147-4589-8DEA-ADB0173A4441 can be fixed with removing Intel extra data (obviously not recommended), but it has duplicate files. These two files will most likely be used to prepare the file for flashing, nothing you should worry about.

• UI for section/file/volume creation
• Embedded hex viewer/editor
• Plugins and/or scripting support
• Command-line interface
• Log of applied changes (both before and after rebuild)
• Undo/redo capability

Hi,

I've noticed that the info.txt files that get dumped to disk by UEFIExtract don't have a trailing new-line for the last line of the file. This creates all sorts of interesting issues for Linux tools and python which all expect POSIX compliance for all lines in a file.

I'd like to help you remedy this by sending a patch to new_engine. I'm opening this issue to discuss what your preferred option of fixing this is. From what I see there are three ways to fix this problems and I list them below. Obviously each option has its advantages and disadvantages. Options 3 seems the easiest and most future proof as it doesn't require you to change how you code but it feels like a hack :)

Anyway, please let me know which option you prefer (or if you have another option I didn't list) and I'll send a pull request to you!

Cheers,
Parth

Option 1 - correct existing code

Go through ffsengine.cp and make sure that every occurrence of info += tr or info = tr that appears just before a call to model->addItem has a \n as the final character of the text.

An example of doing this would include changing the current line 240 to have the extra \n added:
QString info = tr("Full size: %1h (%2)\n")

This is tedious but the real downside is if you append new info later then you have to remember to make sure the \n stays in the correct place.

Option 2 - add a new line of code before addItem

Go through ffsengine.cp and add info += tr("\n") just the line before every model->addItem call.

An example would be adding a new line at line 243 that will state:
info += tr("\n")

This feels like repetitive coding.

Option 3 - patch addItem directly

Modify in only the one central place by changing the addItem function in treemodel.cpp so that the first code at line 275 reads:
info += tr("\n")

One example of the problem

As you can see the shell gets wrapped wrongly:

pparth@doctor:~/bios.bin.dump/4 FFF12B8D-7696-4C8B-A985-2747075B4F50/2 Free space$ cat info.txt 
Type: Free space
Subtype: 
Offset: 5D1000h
Full size: 1F000h (126976)
Compressed: No
Fixed: Yes
Memory address: FFDD1000hpparth@doctor:~/bios.bin.dump/-2747075B4F50/2 Free space$ 

• Show subsections of the PE32/TE images

PE32 images, in uefi, can contain multiple sections. The sections of a PE32 image follow the EFI_IMAGE_SECTION_HEADER, and are contained immediately after the optional PE32 header.

UEFI drivers compiled with the "UEFI_HII_RESOURCE_SECTION = TRUE" will create a .rsrc section that containsii the Hii String, IFR packages, etc.

Being able to extract, and replace the .rsrc subsection would allow modification of setup string, etc.

The latest pecoff v8.3 specification from microsoft:
https://msdn.microsoft.com/en-us/windows/hardware/gg463119.aspx

AARCH64 (ARM64) images are already running UEFI firmware

define IMAGE_FILE_MACHINE_AARCH64 0xAA64

In the EDKII build tools, there are some references to PPC: (file BaseTools\Source\Python\CommonDataClass.py)
EBC | IA32 | X64 | IPF | ARM | PPC | AARCH64

define IMAGE_FILE_MACHINE_POWERPC 0x1f0 //Power PC little endian

define IMAGE_FILE_MACHINE_POWERPCFP 0x1f1 //Power PC with floating point support

Sometimes I just need to quickly check something in a file or an NVAR, and having to dump it to disk is a bit bothersome. Would be nice if a small window with hex dump was shown for it.

Hi!

I've just compiled UEFITool and tried to open Lenovo G505s bios file with no luck. An error message "parseBios: One of volumes inside overlaps the end of data" occurred.
What's the reason? Could you help me?
Link to BIOS file

Plutomaniac sent me an image that showed some errors in Extractor. Upon inspection, I noticed it was because of a little bug in UEFITool engine. To test it, just take any Intel SPI image and add something after BIOS region with hex editing. This is what you will get:

• That padding can't be extracted properly. It will have the right size, but it will be extracted from the end of BIOS region.
• There is no search in that padding.
• If you search something that is present in BIOS region right where UEFITool places this padding, you will get a false result, as if it was found in that padding.

I believe they are all due to the same error, the offset of the padding is wrong.

I would like to point out that identifiers like "_FLASH_DESCRIPTOR_HEADER" and "__UEFITOOL_H__" do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

• NVAR entry
• VSS store
• VSS_standard entry
• VSS_auth entry
• VSS_apple entry
• Fsys/Gaid store
• Fsys/Gaid entry
• FTW store
• _FDC store
• EVSA store
• EVSA entry
• EVSA extended data entry
• FLASH_MAP store
• FLASH_MAP entry
• Intel uCode
• CMDB store
• OA2.0 SLIC pubkey and marker

• Report generation

It would be nice to be able to generate a report about the current BIOS and save the report to a text or comma separated value file. This would be useful when trying to compare two versions of a BIOS when trying to determine the individual FFS files, ME regions, etc, that have changed between the two versions.

The report itself is here, I'm opening the issue to remember fix all the stuff I've promised.

Master branch:

• Add all data to the tree for Intel-based images starting with descriptor.
• Add 539182B9-ABB5-4391-B69A-E3A943F72FCC and 3BE07062-1D51-45D2-832B-F093257ED461 to the list of known UEFI capsule GUIDs.
• Fix a bogus "file with invalid size" warning while working with almost-full volumes (free space is less than 24 bytes).

New_engine branch:

• Add all data to the tree for Intel-based images starting with descriptor.
• Add 539182B9-ABB5-4391-B69A-E3A943F72FCC and 3BE07062-1D51-45D2-832B-F093257ED461 to the list of known UEFI capsule GUIDs.
• Add third extract action for compressed items ("extract uncompressed body").
• Add AppleFSO check.
• Add "Open in new window" action
• Port UEFIFind to new_engine and add mass search feature.

It would be nice to have a rudimentary Makefile.

Hi,

Is there a way to run this without the UI and just via command-line ? I want to embed this tool into a custom Linux distro that will have no X-server and no mouse inputs either.
It would be great if you could do this or at least inform me on how to go about it and I can give you a pull request for it.

Or can I just use the FFSEngine class to do all the work without the UEFITool class ?

--Thanks.

When trying to 'Insert after…' legacyvga to the end of my BIOS, I get a crash as below. I've emailed you the images separately.

Process: UEFITool [12490]
Path: /Network/*/UEFITool.app/Contents/MacOS/UEFITool
Identifier: com.CodeRush.UEFITool
Version: ???
Code Type: X86-64 (Native)
Parent Process: launchd [267]
Responsible: UEFITool [12490]
User ID: 1025

Date/Time: 2014-11-21 23:58:35.915 +0800
OS Version: Mac OS X 10.9.5 (13F34)
Report Version: 11

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x000000020314d9d7

VM Regions Near 0x20314d9d7:
CG shared images 00000001c871f000-00000001c8727000 [ 32K] r--/r-- SM=SHM
-->
MALLOC_NANO 0000600000000000-0000600000400000 [ 4096K] rw-/rwx SM=COW

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.CodeRush.UEFITool 0x00000001000379e6 Decode + 102
1 com.CodeRush.UEFITool 0x00000001000378d5 Decompress + 229
2 com.CodeRush.UEFITool 0x0000000100037a44 EfiDecompress + 20
3 com.CodeRush.UEFITool 0x0000000100021459 FfsEngine::decompress(QByteArray const&, unsigned char, QByteArray&, unsigned char_) + 233
4 com.CodeRush.UEFITool 0x00000001000224a8 FfsEngine::compress(QByteArray const&, unsigned char, QByteArray&) + 440
5 com.CodeRush.UEFITool 0x0000000100027101 FfsEngine::reconstructSection(QModelIndex const&, unsigned int, QByteArray&) + 881
6 com.CodeRush.UEFITool 0x00000001000268cc FfsEngine::reconstructFile(QModelIndex const&, unsigned char, unsigned char, unsigned int, QByteArray&) + 1180
7 com.CodeRush.UEFITool 0x0000000100025ad2 FfsEngine::reconstructVolume(QModelIndex const&, QByteArray&) + 2642
8 com.CodeRush.UEFITool 0x0000000100024f10 FfsEngine::reconstruct(QModelIndex const&, QByteArray&) + 480
9 com.CodeRush.UEFITool 0x00000001000245a7 FfsEngine::reconstructRegion(QModelIndex const&, QByteArray&) + 391
10 com.CodeRush.UEFITool 0x00000001000238da FfsEngine::reconstructIntelImage(QModelIndex const&, QByteArray&) + 714
11 com.CodeRush.UEFITool 0x0000000100024e71 FfsEngine::reconstruct(QModelIndex const&, QByteArray&) + 321
12 com.CodeRush.UEFITool 0x0000000100027bc2 FfsEngine::reconstructImageFile(QByteArray&) + 82
13 com.CodeRush.UEFITool 0x0000000100007fa7 UEFITool::saveImageFile() + 167
14 QtCore 0x0000000100d8cb6f QMetaObject::activate(QObject_, int, int, void**) + 1871
15 QtWidgets 0x00000001000a11d4 QAction::activate(QAction::ActionEvent) + 260
16 QtWidgets 0x00000001000a165f 0x10007c000 + 153183
17 QtCore 0x0000000100d8cb6f QMetaObject::activate(QObject*, int, int, void**) + 1871
18 libqcocoa.dylib 0x0000000104e9638f 0x104e73000 + 144271
19 com.apple.AppKit 0x00007fff8c5b2260 -[NSApplication sendAction:to:from:] + 327
20 com.apple.AppKit 0x00007fff8c5cd1c8 -[NSMenuItem corePerformAction] + 394
21 com.apple.AppKit 0x00007fff8c5ccf04 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 117
22 com.apple.AppKit 0x00007fff8c61c40d -[NSMenu internalPerformActionForItemAtIndex:] + 35
23 com.apple.AppKit 0x00007fff8c61c289 -[NSCarbonMenuImpl carbonCommandProcessEvent:handlerCallRef:] + 104
24 com.apple.AppKit 0x00007fff8c5c2ff6 NSSLMMenuEventHandler + 716
25 com.apple.HIToolbox 0x00007fff929d21d4 DispatchEventToHandlers(EventTargetRec, OpaqueEventRef, HandlerCallRec) + 892
26 com.apple.HIToolbox 0x00007fff929d1787 SendEventToEventTargetInternal(OpaqueEventRef_, OpaqueEventTargetRef_, HandlerCallRec_) + 385
27 com.apple.HIToolbox 0x00007fff929e5880 SendEventToEventTarget + 40
28 com.apple.HIToolbox 0x00007fff92a1b640 SendHICommandEvent(unsigned int, HICommand const_, unsigned int, unsigned int, unsigned char, void const_, OpaqueEventTargetRef_, OpaqueEventTargetRef_, OpaqueEventRef**) + 420
29 com.apple.HIToolbox 0x00007fff92a4e228 SendMenuCommandWithContextAndModifiers + 59
30 com.apple.HIToolbox 0x00007fff92a4e1d0 SendMenuItemSelectedEvent + 178
31 com.apple.HIToolbox 0x00007fff92a4e0af FinishMenuSelection(SelectionData_, MenuResult_, MenuResult_) + 94
32 com.apple.HIToolbox 0x00007fff92a56085 MenuSelectCore(MenuData_, Point, double, unsigned int, OpaqueMenuRef**, unsigned short*) + 718
33 com.apple.HIToolbox 0x00007fff92a55cb1 _HandleMenuSelection2 + 446
34 com.apple.AppKit 0x00007fff8c53562c _NSHandleCarbonMenuEvent + 284
35 com.apple.AppKit 0x00007fff8c39452e _DPSNextEvent + 2170
36 com.apple.AppKit 0x00007fff8c39389b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
37 com.apple.AppKit 0x00007fff8c38799c -[NSApplication run] + 553
38 libqcocoa.dylib 0x0000000104e925e4 0x104e73000 + 128484
39 QtCore 0x0000000100d559ad QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) + 381
40 QtCore 0x0000000100d58ee7 QCoreApplication::exec() + 359
41 com.CodeRush.UEFITool 0x000000010000338e main + 302
42 com.CodeRush.UEFITool 0x0000000100003254 start + 52

I seem to not be getting any interface referenced in the usage guide. A command prompt window comes up and disappears.

Hi,

I really like how the UEFITool UI in new_engine displays the FIT table but this information seems to get lost when I run UEFIExtract on the same flash image. Can you please look at exposing this within the structure so it will get extracted out to disk with UEFIExtract?

I've attached a screenshot here. As you can see in this example, the FIT table physical address show that it's within the Padding area. When I extract this out, I just get body.bin and info.txt for the Padding area volume and the details of the FIT table aren't exported out in any manner.

Cheers,
Parth

I can just use Extract facility，any else si black and can't use. what the problem

• Add the ability to parse and display the microcode versions that are contained in the UEFI firmware image.

To remind myself about small things that keep being forgotten I'm opening this issue. It will not be closed until all this small problems are resolved:

• Rewrite descriptor handling for Gigabyte BIOSes (no need to complain, just start BIOS region right after ME region) Done in 0.18.1
• Move messages creation after tree item creation to be able to point to the item, not it's parent. Done in 0.18.2
• Rework error messages to be more user-friendly ("Error: 14" is not enough). Done in 0.18.2
• Implement GUID search and pattern-based search. Done in 0.18.3
• Check for TODO commentaries and either do something there or just remove unneeded TODOs. Done in 0.18.4
• Use a path to opened image to determine default path for all file-related operations. Done in 0.18.4

• add an empty line after "nothing found" and replace "uefitool" with "uefifind" in the help message
• show correct EFI capsule image size
• search for VTF inside volume's non-UEFI data

I see you have closed my issues. They were so young and beautiful, will be endlessly missed. Now I'm going to open others, as a revenge. Take that, human!

• I've tested the new UEFIFind and it works as expected. What I can recommend is to also add an empty line after "nothing found" and replace "uefitool" with "uefifind" in the help message. On my old laptop it takes around 30-40 seconds for 80 mixed patterns on the hardest images, but after that it is a breeze for Extractor. It is even faster for most images and way faster than before. On powerful desktops it should be in a blink of an eye.
• I take it that you only show the FIT when there is a VTF? They say an apple a day keeps the doctor away, but this one will cause more pain and frustration than actually help. I believe you will need a Linux or OS X to unpack the .pkg inside, as on Windows I could only do it with AnyToISO. After that navigate to EFIPayloads and take MBP121_0167_B07_LOCKED.fd as an example. Unlike the .scap images, this one looks (almost) flash-ready. There is a FIT structure, despite UEFITool empty tab. At first I thought it is just not linked to VTF, but on closer inspection, it is in a strange way. Check in Non-UEFI_data.pad, it is made of two identical blocks of 0x20000 bytes. Each block contains 0x8000 zero padding + 0x4400 microcode + 0x4000 microcode + 0x7C00 zero padding + 0x30 FIT + 0x1FD00 zero padding + 0x6000 Volume. That volume has a VTF that links to the second FIT. Why would they do that and what are your plans? Honestly, I wouldn't want to be in your shoes when you receive such reports. On one hand, you want a nice and clean tool, with only the specs to worry about and some nice additions once in a while. On the other hand, doing so may prevent some images being fully recognized or properly assembled, therefore extra checks and checks for the checks are needed, adding more complexity to the model.
• From the same package, take any scap images, like MP61_0116_B15_LOCKED.scap. In the capsule information, the full size and image size are equal. The Intel capsule is also affected, while AMI and Toshiba ones are showing the proper values.
• Speaking of capsules, let's talk about AMI. Do you have her number, is she into robots? If not, compare the images from ASRock Z97 Extreme 6 and Asus SABERTOOTH Z97 MARK 1. I suppose any ASRock or Asus image would do. I haven't yet read about the structure and I'm not even sure there are public sources, but shouldn't AMI capsule be made as GUID + UINT32 ROM offset + UINT32 Flags + UINT32 Full size + UINT16 Header size + UINT16 Map offset + Certificate + ROM Map/Layout? The certificate appears to be the same as in Intel signed sections: UINT32 size + UINT16 revision + CertificateType (WIN_CERT_TYPE_EFI_GUID) + CertificateGUID (EFI_CERT_TYPE_RSA2048_SHA256_GUID) + CertificateData (EFI_CERT_BLOCK_RSA_2048_SHA256 = HashType (EFI_HASH_ALGORITHM_SHA256_GUID) + PublicKey[256] + Signature[256]). The map area is made of UINT64 Address + UINT32 Offset + UINT32 size + UINT32 type + UINT32 attributes, from a quick read. Because I see some contradiction on those images. The Asus one has the ROM offset pointing to 0x1C, while the ASRock to real image offset. The Asus image only covers the first hash in certificate size, while ASRock covers both hashes and padding until ROM map. There is also the fact that ASRock capsule declares the full size as 0x601000, when the image is 0x801000. Maybe they meant to target just the BIOS region, but how is that possible? The MAP area already has the hooks for signing whatever blocks you want. And how is UEFITool showing the full size as 0x801000?

An extra null pointer check is not needed in a function like "UEFITool::init".

You can't get away from me, human! One robot order coming up:

• how is the FIT table searched in a file? Do you use the pointer from VTF, plain search or something else? Take this Dell file and prepare for a journey. Extract the hdr with PhoenixTool or this script. Once you get the HDR, look into Extractor > "file dellhdr" to unpack this HDR into components. The UEFI firmware should be the one ending with .rom, also uploaded here. This is still not the final image, it is a multi-volume image similar to Intel .bio files, but at least it can be opened by UEFITool. Version 0.30.0 shows no FIT table, but there is one at offset 1C0100, present in the same GUID B52282EE-9B66-44B9-B1CF-7E5040F787C1 that seems to be used just for this purpose, as seen in other images from different OEMs. I don't expect you to bend over for every pack OEMs imagine, but I would like to know if I should report FIT related bugs for every image that can be parsed or just for normal Intel images.
• Take this file > ftp://ftp.supermicro.nl/Firmware/Switch/MBM-GEM-001/Release-1441-1/SageBios_painted_gorge.linux_payload_51.rom < (link not processed by GitHub). Again a strangely packed image. It has Intel regions, but the BIOS region is formed from LARCHIVE sections. Each this section is formed as: signature LARCHIVE + 4 bytes body size + 4 bytes unknown (type of section?) + 4 bytes reserved + 4 bytes header size + x bytes section name + y 00/FF bytes to fill the header -> all fields in big endian. Obviously, this image can't be parsed by UEFITool and no one expects it to be parsed. But it shows an interesting effect: the first _FVH signature confuses UEFITool, which in turn misses the second and valid _FVH. Is there no way to ignore false positives? For instance, I would very much doubt we will find a volume with a size to fill FvLength or to replace the reserved bytes or to have a strange revision.
• Have you noticed the new structure for Skylake descriptor? If there are no public datasheets and you have the NDA heavy breathing over your head, you can check this commit. You can also consult with Plutomaniac, he did some work on his own for MEA -> region locks in Skylake. As a side note, I see some bogus regions in both Skylake and old descriptor. Coreboot mentions 9 regions (including Descriptor), but the map has 9 regions (without descriptor); the old descriptor mentions 2-4 regions, but the map can sometimes have 6 regions. The extra regions are disabled by default, but why are they present in the first place?

UPD: moved all TODOs to the top, new_engine only:

• Add messages UI to FIT table
• Warn on FIT candidates not linked from LastVtf
• Detect and skip obviously wrong FVs using values of header fields
• Show all checksum values for a rapid visual compare between items

see: https://pmbs.links2linux.de/package/show/Extra/UEFITool

g++ -c -pipe -fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/default -I. -I/usr/include/QtCore -I/usr/include/QtGui -I/usr/include -I. -I. -o ffsengine.o ffsengine.cpp
ffsengine.cpp: In member function 'UINT8 FfsEngine::parseVolume(const QByteArray&, QModelIndex&, const QModelIndex&, UINT8)':
ffsengine.cpp:849:19: error: 'ParsingDataTypes' is not a class or namespace
     pdata->Type = ParsingDataTypes::VolumeParsingData;
                   ^
ffsengine.cpp:955:23: error: 'ParsingDataTypes' is not a class or namespace
         pdata->Type = ParsingDataTypes::FileParsingData;
                      ^
ffsengine.cpp: In member function 'UINT8 FfsEngine::reconstructVolume(const QModelIndex&, QByteArray&)':
ffsengine.cpp:3076:28: error: 'ParsingDataTypes' is not a class or namespace
         if (pdata->Type == ParsingDataTypes::VolumeParsingData && pdata->Data.Volume.HasZeroVectorCRC) {
                            ^
Makefile:351: recipe for target 'ffsengine.o' failed

Hi,

I ran:

./UEFIPatch X99-E-ASUS-0601.CAP

And got this output:

parseImageFile: Aptio capsule signature may become invalid after image modifications
parseSection: section with unknown type 52h
parseFile: non-empty pad-file contents will be destroyed after volume modifications
parseSection: section with unknown type 52h
parseFile: non-empty pad-file contents will be destroyed after volume modifications
No patches can be applied to input file

Can this be fixed?

It's not possible to open multiple bios files at the same time, at least in the OS X version.
It would be great to have an option to open a new window for working on another bios file.
Usually this is very useful for comparing changes and so on.

fG!

You have deleted fitParser.h and fitParser.cpp in 59a6f2 commit.
But you did not edit UEFIDump/uefidump.h. UEFIDump/uefidump.h includes fitParser.h.
I tryed to comment this line, but it was unable to build. Please fix.

Hi
I am trying to patch my Asus Rampage V Extreme 3301 bios
I am using Broadwell E patch.txt
Uefipatch outputs this:
parseImageFile: Aptio capsule signature may become invalid after image modifications parseSection: section with unknown type 52h parseFile: non-empty pad-file contents will be destroyed after volume modifications parseSection: section with unknown type 52h parseFile: non-empty pad-file contents will be destroyed after volume modifications patch: replaced 6 bytes at offset F69h 0FBA6C24400F -> 0FBA7424400F Image patched
Is It correct?
Hi attach original bios and patched one
Thank you
Asus RVE.zip

Hi,

I noticed the too shy post and wanted to express this, so this issue is more of a question. Last time I tried to use UEFITool it was not obvious how to extract the video card blob. If you have not already, could a option be implemented that makes this task much more straight forward?

Thanks,
Edward.

• simplified VBIOS and other BLOBs extraction (can be used to get BLOBs for building coreboot image)

First of all this project is amazing!

Would it be possible to add a dependency graph option ?
I think on something to let easier to understand what modules are dependent to each other.

Modifying Apple's EFI dumps will brick the target Macs.
The crc32 and crc16 are all ok and the modification (replacement or reinjection is also ok).

I found out that the issue is related to the last 4 bytes of the ZeroVector. As you know the first 4 of the last 8 bytes are the crc32 value of the firmware volume contents. The question is what are the last 4 bytes, since they appear to be meaningful.
They are the number of bytes occupied by all the files in each firmware volume. So they are the difference between the FVLength reported by the EFI volume header and the free space (beware of padding?). So if the volume is modified and the free space changes, those bytes at the ZeroVector must be updated with the new value, and then the header crc16 fixed for this.

This way the firmware can be reflashed without bricking the machine. The value is not used on the boot volume (still too early for those kind of checks?) but definitely on PEI/DXE phases. I didn't reverse where it is implemented since I noticed its meaning before diving into reversing it.

Thanks for the awesome work with UEFITool :-)

fG!

• Complete logging of things done during patching
• Better handling of several sections of same type
• Search and replace in the whole file (without or after parsing)
• Ability to add/replace/remove volumes/files/sections
• Direct invocation without patches.txt file