UEFITool: parsing UEFI firmware images, and where the new engine stops

What UEFITool reads that a hex editor cannot

A UEFI firmware image is not a flat blob. It is a nesting of firmware volumes, files, sections and free space, defined by the UEFI Platform Interface specifications. UEFITool parses an image into that tree, verifies its integrity, and exposes the elements through a GUI. That is the whole job, and it is a narrower job than the name suggests to people who arrive looking for a BIOS modding suite.

The audience is correspondingly narrow: firmware engineers, security researchers looking at what a vendor shipped, and advanced users who want to know what is inside a BIOS update before flashing it. If you only want to change a boot setting, this is the wrong program. The README frames the origin of the project plainly: development started in the middle of 2013 because there was a lack of cross-platform open source utilities for tinkering with UEFI images. The cross-platform part is the differentiator that survives today, and it is why the project is written in C++/Qt rather than as a Windows-only GUI.

The parser, the tree, and the two branches that matter

The engine is called ffsParser, and it is shared. UEFITool wraps it in a Qt GUI. UEFIExtract uses the same parser to dump the parsed structure recursively onto the filesystem, and UEFIFind uses it to locate image elements containing a specified pattern. Both of those are console tools built without Qt. That split is the most useful architectural fact in the repository: the parsing and the presentation are separable, and the console side is where automation lives.

The branch situation is the part to understand before you build anything. The default branch is new_engine, and it is a refactoring that began in early 2015 to handle newer UEFI features including FFSv3 volumes and fixed image elements. The README states that the editor part, meaning image reconstruction routines, and the console UI are still missing from it. Until reconstruction works, editing is only possible using an outdated and unsupported UEFITool 0.28 on the old_engine branch, along with the tools built on it, UEFIReplace and UEFIPatch. The README calls this the top priority issue, being worked on albeit slowly, and attributes the slowness to the amount of coding and testing required to do it correctly. That is an honest description of a hard problem, and it also means the headline feature in the project's name is not in the default branch.

Installing UEFITool and opening a first image

The README offers two routes: pre-built binaries from the releases page, or building from source. Releases are named with an A-series version, for example A75 (UEFITool / UEFIExtract / UEFIFind NE A75), so the binaries and the console tools ship together under one version number.

To build the Qt GUI yourself, you need a C++ compiler and an instance of Qt5 or Qt6. The README gives qmake as the generator for the project file:

qmake ./UEFITool/uefitool.pro
make release

On Windows the same step is usually nmake release instead of make release, which the README lists as an example. Qt6-based builds can also use CMake as an alternative build system. What you should end up with is a GUI binary that opens a firmware image and shows the parsed tree on the left with element details on the right.

For the console tools the build is different, because there is no Qt dependency to satisfy. You need a C++ compiler and CMake:

cmake UEFIExtract
make release

Non-Qt builds can also use Meson instead of CMake. Running the resulting UEFIExtract binary against an image dumps the parsed structure recursively to disk rather than showing it in a window, which is the form you want if you intend to diff two firmware versions or feed the output to another tool. The same parser backs UEFIFind, which takes a pattern and reports which image elements contain it.

Where UEFITool fails or is simply the wrong tool

The first limitation is the one already named: no image reconstruction in new_engine. If your task is to patch a module and flash the result, the default branch cannot finish the job, and the branch that can is described in the README as outdated and unsupported. That is not a small caveat, it is the difference between a viewer and an editor.

The second is input coverage. The README states that some vendor-specific firmware update files can be opened incorrectly or cannot be opened at all, and lists encrypted HP update files, Dell HDR and EXE files, and some InsysdeFlash FD files among them. The stated reason is that supporting them would require a large amount of reverse engineering, which the README argues is close to pointless because the updated image can be obtained from the BIOS chip where it is already decrypted and unpacked. That reasoning is sound if you have physical access to the chip. If you are analyzing a vendor download in isolation, it leaves you without a path.

Third, Intel Firmware Interface Table editing is not supported. The README explains that FIT holds pointers to components loaded before the first CPU instruction executes, including CPU microcode updates and binaries and settings used by BIOS Guard and Boot Guard. Anything that depends on rewriting FIT entries is out of scope here.

Finally, there is a platform-specific failure. Windows builds of UEFIExtract and UEFIFind can hit the 260-byte MAX_PATH limit on some input files, because the recursive dump produces deep folder paths. This is a known Windows limitation rather than a bug in the parser, but it will bite exactly the users who extract large images on Windows.

Fiano, FMMT and the Python parsers: what actually differs

The README lists several alternatives, and the differences are concrete. FMMT from TianoCore is a Python-based toolset for modifying EDK2-based firmware images. It does not support any independent BIOS vendor customizations, but it is official and lives inside the EDK2 repository. If your firmware is built from EDK2 without vendor changes, FMMT is closer to the source of truth than UEFITool is.

Fiano, by Google and Facebook, is a Go-based cross-platform toolset for modifying UEFI firmware images. The language choice matters for deployment: a Go binary drops into a container or a CI runner without a Qt or Python runtime, which is a real difference from UEFITool's Qt GUI and from the Python alternatives.

uefi-firmware-parser by Teddy Reed is a cross-platform console application in Python, described in the README as very tinker-friendly and usable in scripts to automate firmware patching. That is the opposite trade from UEFITool's C++ engine: slower and less strict, but far easier to modify when you need a nonstandard structure handled.

Chipsec takes a different angle again. It is a cross-platform, partially open source console application in Python and C, aimed at testing Intel-based platforms for security misconfigurations, and it also has an NVRAM parser and other components aimed at firmware modification. If your question is whether a platform is configured safely rather than what a specific image contains, Chipsec is the better starting point. PhoenixTool is the outlier: Windows-only freeware in C#, requiring Microsoft .NET 3.5, used mostly for SLIC-related modifications, and it supports unpacking firmware from vendor-specific formats such as encrypted HP update files and Dell installers, which is precisely where UEFITool struggles.

Maintenance, licensing and the cost of staying current

The repository is not archived, and the last push was on 2026-07-29. Releases are spaced roughly a quarter apart in the recent record: A73 in January 2026, A74 in April 2026, A75 in July 2026. That cadence is consistent with a project that is maintained but not moving quickly, which matches the README's own admission that the reconstruction work is progressing slowly.

The practical upgrade cost is low for the parser and high for anything that touches the engine. Because UEFIExtract and UEFIFind share ffsParser, a parser fix propagates to all three tools at once, and the A-series version number covers all of them together. The cost is that any change in the parsed tree shape can affect scripts that consume UEFIExtract's output, so pinning a version is worth doing if you have automation downstream.

The licence is BSD-2-Clause, which is permissive and places few conditions on redistribution or use in a larger product. It is worth noting that the licence covers the code in this repository, not the firmware images you open with it; vendor firmware carries its own terms, and nothing in the BSD-2-Clause grant changes that. This is a description of the licence text, not legal advice.

Editorial conclusion

Adopt UEFITool if you need to read a firmware image, inspect its tree, or confirm that its structure is intact, and use UEFIExtract or UEFIFind when you want that parse in a script. Do not adopt the new_engine branch expecting to write an image back: the README says the editor part, meaning image reconstruction routines, is still missing, and the console UI is missing too. Verify first which branch you are building against, since editing is only possible with the unsupported 0.28 code on old_engine, and check whether your input is a vendor update file that the parser may open incorrectly.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. LongSoft/UEFITool on GitHub
4. README
5. Releases