# UEFI-Shell: prebuilt EDK2 shell images you can verify yourself

> pbatard/UEFI-Shell publishes prebuilt UEFI Shell binaries and bootable ISOs generated from official EDK2 stable releases, with a documented procedure for checking that a given ISO was built from public, unmodified source. It is aimed at anyone who needs a UEFI environment without building EDK2 themselves.

**pbatard/UEFI-Shell** — UEFI Shell binary images, generated from EDK2 stable

- Repository: https://github.com/pbatard/UEFI-Shell
- Stars: 699 · Forks: 74
- Language: Unknown
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/pbatard-uefi-shell

## A shell binary you would otherwise have to build

The repository holds no source of its own worth the name. It contains pre-built UEFI Shell binary images, and the README is explicit that they are generated from official EDK2 stable releases, with the EDK2 project linked as the upstream. The top level of the repository shows how little is here: a `.github/` directory, a `.gitmodules` file, a `License.txt`, the `README.md` and an `edk2` entry, which is the submodule pointing at the upstream source that the build actually consumes. That is the whole design. EDK2 is a large build with its own toolchain requirements, and this project removes that step for people who simply want the shell binary. The releases follow a naming scheme tied to half-year periods, with 26H2 published on 2026-10-05, 26H1 on 2026-02-27 and 25H2 on 2025-11-21, matching a bi-annual release schedule.

## The ISO is a convenience wrapper around the binary

The images are mostly provided in the form of a bootable ISO, and the reason given is practical: it makes them easy to use with boot media creators such as Rufus, or to be written as optical disc bootable media. The same content can also be used in two other ways, by partitioning and formatting a medium such as a USB flash drive with a FAT file system and then extracting the ISO content as is onto the FAT partition. Once that is done and the machine is set to boot from removable media, and runs a UEFI firmware using one of the architectures the release supports, it should boot into the UEFI Shell automatically. Individual UEFI Shell binaries for a specific platform can also be downloaded on their own, which is what you want when you are dropping a shell onto an existing FAT partition rather than building boot media. The topic list of the repository names the architectures involved, including x86, x86-32, x86-64, arm, arm64, aarch64 and riscv64.

## Secure Boot is the hard blocker

There is one condition that decides whether any of this works, and the README states it without softening: Secure Boot must be disabled for a UEFI Shell media to boot, because Microsoft does not allow an external UEFI Shell to be signed for Secure Boot. That is a hard platform restriction rather than a limitation of this particular build, and it means the workflow starts in the firmware setup, not in the shell. The practical consequence for a modern laptop is that you will be entering the BIOS to turn Secure Boot off, using the shell, and then turning it back on, and on a managed corporate machine you may not be allowed to do that at all. Worth noting is that the recent releases also bundle an optional extra binary, Mosby, which is invoked by typing `Mosby` at the shell prompt, and whose purpose is updating UEFI Secure Boot databases, which is exactly the situation the Secure Boot restriction creates.

## Why Mosby is bundled and what it does not change

Since release 24H2 the ISO images include Mosby as an optional binary. The reasoning given is specific rather than promotional. The expiration of the current Secure Boot database signing certificates for Microsoft Windows and UEFI third party platforms was planned to occur in 2026, and the BlackLotus revocation episode left its own mess, so the project expects more people to want a convenient way to update their UEFI Secure Boot databases. Mosby is the tool for that job. The important caveat the README repeats is that including Mosby does not change anything about the base UEFI Shell, and that it is just an extra command you can invoke if you decide to. Nothing about the shell itself is modified, and the default behaviour of the media is unchanged. If you only need the shell, the optional binary sitting on the same image is inert.

## Verifying a build from a public commit

The unusual part of this project is the validation procedure, which is described step by step because the whole point of shipping prebuilt binaries is that you are trusting them. The claim being made is that the binaries are built in a fully transparent manner so that you have assurance they contain nothing malicious, and the procedure is how you check it. The first step is to locate the build action for the ISO you downloaded under the repository's Actions tab, and the README notes the practical obstacle: GitHub's retention policy for build logs is limited to three months and the release schedule is bi-annual, so the latest build log may no longer be accessible, though there is always a three-month window in which the validation can be performed publicly. The second step is to open the `build` log, look at the `Checkout repository and submodules` task, and read the SHA-1 of the repository commit used for the build from the last line of that task.

## Following the commit into EDK2 and matching the SHA-256

The remaining steps close the loop. You append that SHA-1 to the repository's commit URL, which validates that the build was triggered by a public commit rather than a hidden one that would be deleted later, since altering a git commit to fake a specific SHA-1 is computationally infeasible. You then have to check that the EDK2 source used for the build is the public one from the tianocore repository rather than a private copy, which is done through the `Browse Files` button and the `edk2 @ #####` link in the repository tree, where the label carries the EDK2 commit. Readers familiar with the build can also read the GitHub Actions `.yml` from the commit that triggered the build, to confirm the workflow is not discarding the built executables and replacing them with pre-built ones fetched from a third-party server. The last item is the one that closes the gap left by release pages, because a repository owner can delete and replace release files. The build displays the SHA-256 for all UEFI binaries and for the ISO images, under the `Display SHA-256` or `Generate ISO images` step in the log, and you compare that against the file you downloaded.

## Where this is the wrong tool

Two limits follow directly from the design. The first is Secure Boot, already covered, and it is not something the project can work around since Microsoft does not sign external UEFI shells. The second is that a prebuilt image is a frozen artifact of a particular EDK2 stable release, so if you need a patch, a fix, or a feature that is not in that release, this repository does not provide it. Building EDK2 yourself is the route to a modified shell, and the validation procedure here is itself an argument for understanding the build rather than distrusting it. There is also a licensing point to note. The badge in the README states BSD 2-Clause, while project metadata lists the licence as a custom one that GitHub cannot classify and points to the `License.txt` file. The `License.txt` file is the authoritative statement; a badge in a README is not a licence grant, and any organisation reusing these images should read the file rather than the badge.

## Conclusion

UEFI-Shell fits a technician or developer who needs a working UEFI Shell on a machine whose firmware will not let you run one, and who would rather not spend a day building EDK2 from source. It is the wrong choice for a Secure Boot enabled machine, since the images cannot be signed for it, and it is the wrong choice if you need a production signed shell, since these are unsigned by design. Before you burn one to a USB stick, read the binary validation steps and compare the displayed SHA-256 for the image with the release file, and check that your architecture is one the release supports. The last push was on 2026-10-05 with release 26H2 published the same day, on a bi-annual release schedule, under a BSD 2-Clause licence.

## FAQ

### How do I boot a UEFI Shell from a USB drive using pbatard/UEFI-Shell?

Download the ISO, write it to a USB drive with a boot media creator such as Rufus, or partition and format a drive with a FAT file system and extract the ISO content onto it, then set the machine to boot from removable media. Secure Boot must be disabled for the media to boot, because Microsoft does not allow an external UEFI Shell to be signed for it.

### Can I verify that a UEFI-Shell ISO was built from unmodified EDK2 source?

Yes. Find the build action for your ISO in the repository's Actions tab, read the repository commit SHA-1 from the `Checkout repository and submodules` task, confirm that commit is public, then follow the `edk2 @ #####` link to confirm the EDK2 commit is public too, and finally compare the SHA-256 shown in the build log with the file you downloaded.

### What is Mosby in the UEFI-Shell images?

Since release 24H2 the images include Mosby as an optional binary that you run by typing `Mosby` at the shell prompt. It is there to help update UEFI Secure Boot databases, and the project stresses that it does not change the base UEFI Shell in any way.

### How often are new UEFI-Shell releases published?

The release schedule is bi-annual, and the repository is named after the half-year periods. The most recent tags are 26H2 on 2026-10-05, 26H1 on 2026-02-27 and 25H2 on 2025-11-21.

## Sources

- [Issues](https://github.com/pbatard/UEFI-Shell/issues)
- [pbatard/UEFI-Shell on GitHub](https://github.com/pbatard/UEFI-Shell)
- [README](https://github.com/pbatard/UEFI-Shell/blob/main/README.md)
- [Releases](https://github.com/pbatard/UEFI-Shell/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pbatard-uefi-shell