UEFI-Shell

This repository contains pre-built UEFI Shell binary images, generated from
official EDK2 stable releases.

Usage

These images are mostly provided in the form of a bootable ISO, in order to
make them easy to use with boot media creators such as Rufus.

However, these can also readily used by:

Partitioning and formatting a media, such as a USB Flash drive, using a FAT
file system.
Extracting the ISO content as is, onto the FAT partition.

Once you have done that, and provided that your machine is set to boot from
removable media (and runs a UEFI firmware that uses one of the architectures
supported by the release), it should automatically boot into the UEFI Shell.

Alternatively, you can download the individual UEFI Shell binary for your
platform.

Note that Secure Boot must be disabled for a UEFI Shell media to boot, as
Microsoft does not allow an external UEFI Shell to be signed for Secure Boot.

Inclusion of Mosby

Starting with release 24H2, these ISO images also include Mosby
as an optional binary that you can run by typing Mosby from the Shell
command prompt.

This is done because we believe that, with the planned expiration of current
Secure Boot DB signing certificates for Microsoft Windows and UEFI Third Party
that will occur in 2026, as well as the whole BlackLotus revocation mess,
more and more people are going to be looking for a convenient way to update
their UEFI Secure Boot databases, and Mosby is designed to accomplish just that.

But again, it needs to be reiterated that the inclusion of Mosby does not
change anything to the base UEFI Shell. It’s just an extra command you can
invoke, should you decide to do so.

Binary validation

These binaries are built in a fully transparent manner, in order to provide
you with complete assurance that they do not contain anything malicious.

To validate this claim, you can perform the following:

Locate the build action for the ISO you downloaded under
https://github.com/pbatard/UEFI-Shell/actions. For instance, for the 21H1
release, this would be https://github.com/pbatard/UEFI-Shell/actions/runs/1160237413.
Click on build to access the build log, and then look at the Checkout repository and submodules task. The last line for that task provides the
SHA-1 of the repository commit that was used for the build process (for 21H1
that would be 19803c2b2183849fc3a4d6f08cc3c0549232df0c).
Append that SHA-1 to https://github.com/pbatard/UEFI-Shell/commit/ to
validate that you end up with one of the public commits that were
pushed to this repository. This validates that the build was not triggered
by a “hidden” commit, that would perform something malicious, and that we
would later delete, since it is impossible for anyone without an army of
supercomputers to alter a git commit in order to “fake” a specific SHA-1.
NB: You don’t have to take our word for that last claim. Just google “SHA-1
collision” and also look into the measures that git is taking to switch to
SHA-256 so as to make the possibility of collision impossible.
At this stage, you have assurance that the commit that was used to build
the binary is a public one. However, you must also further validate that
the EDK2 source that was used for the build is also the public one that
is published from https://github.com/tianocore/edk2, and not some private
potentially malicious copy. To accomplish that, click the Browse Files
button on the page you got from the URL that was constructed above and
the click on the edk2 @ ##### link that you see in the repository tree.
For instance, for 21H1, that link will be labelled edk2 @ e1999b2.
Validate that this link takes you to a public commit from
https://github.com/tianocore/edk2. Once you have done that, then you have
validated that, not only the build cannot have been triggered by a hidden
commit but also that the EDK2 source for the UEFI Shell that is produced
by the build cannot have come from anywhere else but the public EDK2
repository.
If you are familiar enough with the build process, you should now look at
the GitHub actions .yml from the commit that was used to trigger the build
to also validate that it is not doing anything suspiscious (such as
discarding the built executables to replace them with pre-built malicious
ones downloaded from a third-party server). Again, because you have already
validated, with 100% certainty, that all the steps that are used for the
build can only have come from a public commit which everyone has access to,
it would simply be impossible for any such behaviour not to appear plainly
in the .yml.
At this stage, you should have total confidence that the build process did
produce binaries that can be trusted to have been built only from the
public unmodified EDK2 UEFI Shell source. Therefore, the one last item to
check is to validate that the binaries proposed under this project’s Release
page are the actual binaries that were produced from the build, rather
than some malicious replacements (since the owner of any GitHub project has
the ability to delete and replace release files). This last step is very
easy to accomplish however: As part of the build process, we make sure to
also display the SHA-256 for all of the UEFI binaries as well as for the
ISO images being generated.
Thus, depending on whether you extracted individual .efi files, or are
working directly with a .iso, you can find the relevant SHA-256 displayed
either under the Display SHA-256 step or the Generate ISO images step
within the build log (and you should of course have validated that the
GitHub Actions’ .yml that was used as part of the build was indeed set
to perform an actual computation of the SHA-256 from the generated files,
as opposed to mimicking the display of an SHA-256 computation in order to
trick someone looking only at the log into thinking that a malicious file
published under Releases, and that was not generated from the automated
build process, did come from the build process).
Compare the SHA-256 from the build log with the one from the .efi or
.iso you downloaded, and verify that they are the same.

If you accomplish all the steps above, then you will have established, with
absolute certainty, that the binaries that are being published on our
Releases page can be trusted not to contain malware (that is, provided you do
accept that toolchains like gcc or GitHub employees can be trusted not to
insert malware on their own, but this is outside of the scope of the kind of
assurance that we can provide here).

And the nice thing is that, because any failure of validation for the points we
describe above is very easy to detect, you can rest assured that, even if
you do not go through these steps yourself, someone else is likely to, and is
bound to say something if we ever are to do anything that looks contrary to
our claim that the UEFI Shell binaries published here are 100% trustworthy.