UEFIGame: Five Boot Time UEFI Games and the Security Tradeoffs

Alejandro Armas — known on GitHub as mycroftsnm — has released a compact collection of five boot-time UEFI games that force a simple choice every time you start a PC: win, and the machine continues to boot; lose, and it shuts down. The project, published as the UEFIGame repository, bundles a mix of quiz, pattern-memory, Simon-like and reflex tests — User Evaluation for Ineptness, Insult Sword Fighting, Fall To Boot, Age Verification and UEFI Says — and the developer states the suite took roughly ten months to build. The result is a deliberately playful, deliberately disruptive experiment that explores what firmware can do when treated like a tiny platform for games and challenges the conventions of the boot experience while raising real usability and security questions for enthusiasts and administrators alike.

Background / Overview​

UEFI (Unified Extensible Firmware Interface) is the modern firmware environment that replaced the legacy BIOS model on most PCs. Unlike the old BIOS, UEFI is modular, supports richer graphics and input at boot, and can load and run binary "applications" from the EFI System Partition or from removable media — which is precisely what makes Armas’ idea technically feasible. UEFI’s architecture gives developers the ability to render simple UIs and accept input before the OS loads, and hobbyist projects have long used that capability for tools and tiny apps that run outside an operating system.
That same firmware layer is also the place where platform integrity features live: Secure Boot enforces that only signed early-boot components run, and TPM-based measured boot makes it possible to attest to what occurred before the OS started. Because UEFI sits at that gate, code that runs here has real power — from setting boot variables to initiating system-level behavior such as power state changes, logging measured boot values, or handing control to the OS. Those capabilities are a technical enabler for boot-time games, but they are also why firmware-level code demands careful handling and a clear understanding of risk.

---

The UEFIGame collection — what’s included​

Armas’ UEFIGame repository bundles five distinct mini-games with the same high-level rule: succeed and the firmware continues the normal boot sequence; fail and the firmware triggers a shutdown. The project is intentionally small and retro in aesthetic, but mechanically each entry tests a different skill:

• User Evaluation for Ineptness — a math quiz that asks the user to add two random numbers from 0–99. An incorrect answer provokes an insulting response and a shutdown. This game is the purest "preflight test" style: quick to compute, low friction for success if you're awake.
• Insult Sword Fighting — a Monkey Island–inspired text-choice duel where the player picks a retort from options; the list of possible comebacks is extensible by editing insults.txt. The game blends humor and choice selection.
• Fall To Boot — a graphical vertical-scroller in which a star-like cursor falls through a procedurally generated tunnel; touching the walls ends the run with a shutdown. This one is the reflex test of the collection.
• Age Verification — an 80s pop-culture trivia quiz styled as a Leisure Suit Larry nod; by design it filters for players with the right pop-culture knowledge or patience.
• UEFI Says — a graphical memory/pattern test in the "Simon" family; the firmware lights up pattern sequences that the user must repeat to win.

Videos of the games in action are included in the repository’s demo section, making the experience easy to preview before running anything on a real machine. The repository also allows for simple customization — for example, expanding insult lists — which is part of the project's charm and experimental intent.
This design is intentionally provocative: a tiny, deterministic barrier to access your machine that converts a mundane boot sequence into a minute of gameplay. For hobbyists, retro-gamers and UEFI tinkerers that’s a novelty. For production systems it’s obviously inappropriate.

---

How these games actually run (technical mechanics)​

Technically, a UEFI application is an executable that the firmware can load and run before handing control to the bootloader or OS. UEFI apps can be stored on the EFI System Partition or delivered from removable media; they can open graphical or text-mode displays and capture keyboard input — capabilities Armas uses to present questions, patterns and small games. The same platform APIs that let you build a firmware-level system utility let you make a game with basic graphics and input.
Because UEFI sits before the OS, these apps run in a privileged environment relative to operating-system processes: they can change boot variables, set the next boot entry, and trigger ACPI/GPIO-based power operations such as shutdown. That is how a UEFI game can safely and reliably halt a boot sequence: the firmware invokes the shutdown path directly. That capability is powerful and also the reason why firmware-level code needs the same care you’d apply to a kernel-mode driver.
One practical complication: many modern systems enforce Secure Boot. If Secure Boot is active and the firmware is configured to only run signed UEFI binaries, the games must be either signed by a trusted key or installed in a firmware state that permits their execution. Running unsigned or self-signed UEFI apps typically requires the user to disable Secure Boot, enroll custom keys, or run on systems that permit developer-mode booting. That reduces the portability of a raw hobbyist build and raises additional safety trade-offs because disabling Secure Boot can change the system’s trust posture.

---

Strengths and creative value​

There are several notable strengths to the UEFIGame project that make it worth attention beyond the immediate meme value:

• Technical novelty: It demonstrates firmware-level interactivity beyond setup utilities or vendor diagnostics, and it shows the expressive potential of UEFI as a tiny platform for experimentation. That novelty matters to firmware hackers and hobbyist developers who enjoy pushing platform boundaries.
• Simplicity of design: The games are small, self-contained, and designed to be auditable. They’re not complex software ecosystems, which makes code review and casual modification straightforward for competent users.
• Educational value: For people learning UEFI programming, a small set of games is an approachable way to practice graphics, input handling and firmware-level control flows.
• Customizability: With text-based assets (insults.txt, trivia lists), users can expand or adapt the experience without deep changes to compiled code. This lowers the entry barrier for crafting a personalized boot-time ritual.

These aspects make the project interesting as a proof-of-concept: UEFI can be more than "just" firmware-level initialization — it can host tiny interactive experiences.

---

Risks, real-world impacts and cautionary points​

The same firmware power that makes these games possible also creates a set of safety and operational risks. Any discussion of running UEFI-level code on daily drivers must be anchored by clear warnings.

• Unintended lockout or data recovery issues: Firmware actions during pre-OS phases interact with disk encryption and BitLocker semantics. Users who tinker in firmware or change boot variables without following rescue and backup steps risk BitLocker recovery screens, encryption lockouts or more serious boot failures. Always export and securely store BitLocker recovery keys and create full disk images before experimenting with firmware-level code.
• Secure Boot and signed binaries: If UEFI Secure Boot is enabled — which is increasingly common, especially on Windows 11–capable hardware — unsigned UEFI binaries will be blocked. Disabling Secure Boot to run an unsigned game reduces platform protections and may affect update paths or anti‑cheat compatibility later. That means running these games in a way that bypasses Secure Boot is a conscious risk decision.
• Anti‑cheat and online services: Some online game ecosystems rely on early-boot attestation for anti-cheat. While Armas’ games are offline and playful, modifications to firmware behavior — or enabling/disabling platform protections to run firmware code — can affect the system posture and may lead to compatibility issues with games that perform attestation checks. For users who also play competitive online titles, these interactions are non-trivial and can lead to unexpected account or access issues.
• Physical and enterprise policy considerations: On managed devices (corporate laptops, school PCs), firmware modifications are often blocked by IT policy. Installing arbitrary UEFI software on such hardware can violate corporate rules and expose the device to support issues or administrative lockouts. For organization-owned systems, stay out of firmware experiments.
• Supply-chain and authenticity risks: Installing firmware-level code from untrusted sources is inherently riskier than installing a user-mode app. While the UEFIGame repository is a hobbyist project, community tools and projects in the UEFI space have been mimicked by malicious actors before; always verify downloads and prefer inspecting source code before running any firmware-level binary.
• Potential for user frustration: Beyond technical hazards, forcing a game on every boot may produce the exact opposite of a good user experience for most people. Those who need quick access to email, meetings or on-call tools will find it intolerable. From an accessibility and productivity perspective, the concept should be restricted to dedicated hobbyist rigs or ephemeral test machines.

Where possible, the project should be treated as an experiment for spare boxes and lab hardware, not something that belongs on a primary workstation or a production laptop.

---

How to experiment safely (recommended steps for enthusiasts)​

If you’re curious and want to try UEFIGame in a controlled way, follow these precautions:

1. Back up absolutely everything. Create a verified full disk image and export BitLocker recovery keys if the disk is encrypted.
2. Test inside a virtual machine that supports UEFI (QEMU with OVMF / SeaBIOS UEFI firmware) before touching a real device, or use an expendable spare PC. That lets you preview the experience and confirm the shutdown behavior in a low-risk environment.
3. Keep a recovery USB with official Windows or Linux install media on hand so you can boot to rescue tools if something goes wrong.
4. If Secure Boot is enabled and you want to run unsigned UEFI apps, consider the trade-off: you will need to either sign binaries with keys the firmware recognizes or temporarily disable Secure Boot — which reduces platform security. Only do that on test machines.
5. Audit the repo: read the source and make sure nothing unexpected (network calls, hidden disk writes) exists in the binaries or scripts. The project’s small scale makes a source review feasible for competent users.

Following the checklist above minimizes the chance of an unrecoverable situation and makes experimentation responsible.

---

Broader context: Why UEFI experiments attract interest​

UEFI’s capabilities and the ecosystem around firmware experimentation have grown in the last decade. Hobbyists create tiny utilities, boot managers, diagnostic tools and even retro-game demos that run pre-OS to demonstrate the flexibility of modern firmware. This playfulness is not purely aesthetic; it also exposes important engineering and governance questions about what code should be permitted to run before an OS takes over. The tradeoffs between flexibility for hobbyists and platform security are real and require deliberate thought from vendors and the community.
At the same time, the industry trend to rely on platform-level attestation and Secure Boot for anti-cheat and other protections has made firmware behavior a matter of public interest and operational consequence. Any project that invites users to change UEFI settings or temporarily disable platform protections must be clear about the risk and encourage conservative practices.

---

Critical analysis — strengths vs. potential blind spots​

• Strength: Educational and playful exploration — UEFIGame is an elegant demonstration of what firmware can do, and it’s approachable for those who want to learn UEFI development. The simplicity of the games keeps the attack surface small and makes code review feasible.
• Strength: Customizable and portable — text assets and a small codebase let hobbyists personalize the experience without recompiling the whole suite.
• Risk: Operational hazard if misused — firmware-level shutdowns, interactions with BitLocker and Secure Boot, and possible incompatibility with attestation-sensitive software make running this on a daily driver inadvisable.
• Risk: Security posture changes — users tempted to disable Secure Boot to run unsigned apps are lowering device integrity and may expose themselves to toolchains that exploit that weakened state.
• Blind spot: Assumptions about accessibility and user context — the project presumes a single-user who is happy to be gamified at boot. It doesn’t cater to multi-user, accessibility needs, or remote-admin workflows where a shutdown on failure could be catastrophic.
• Blind spot: Signature and distribution considerations — the project documentation should explicitly instruct users about Secure Boot, recommended signing approaches, and the legal/operational consequences of disabling platform protections; those instructions are the difference between a harmless toy and a risky mod.

Where claims in reporting rely on one source — for example, the statement that the collection took “approximately 10 months to create” — treat them as developer-reported facts unless independently corroborated. That timeline is plausible for a small firmware project but is a developer claim rather than a measurable platform property; label such items as attributable to the repository’s author unless multiple independent milestones back the statement.

---

Practical takeaways and a measured verdict​

• For curious tinkerers with spare hardware or a lab VM: UEFIGame is a fun, harmless technical novelty that showcases UEFI’s interactive capabilities. It’s a good learning exercise if you follow the safety checklist and avoid running it on primary devices.
• For daily drivers, corporate laptops, and multi-user machines: the concept is inappropriate. The risk of accidental shutdown, BitLocker recovery complications, and policy violations is real and not worth the entertainment value.
• For the UEFI and security community: this project is a useful reminder that firmware isn’t a black box — it’s a programmable layer that can host interactive experiences. That raises useful conversations about signing, distribution, and how vendors might support safe hobbyist experimentation without undermining platform trust.

Armas’ UEFIGame is an inventive, cheeky exploration of modern firmware’s capabilities. It stands as both a small piece of retro-inspired fun and a prompt for a more serious conversation about what we allow to run at the earliest stages of system boot. When treated as an experimental project for prepared machines, it’s perfectly in the spirit of a tinkerer’s playground; when treated as a daily-driver convenience, it becomes a risk. The sensible middle path is to enjoy the creativity, learn from the code, and keep those experiments out of environments where a single lost round should not mean a forced shutdown.

---

Quick safe-start checklist (copyable)​

1. Create a full disk image and verify it.
2. Export and store BitLocker recovery keys offline.
3. Try UEFIGame in a UEFI-capable VM (QEMU + OVMF) or on a disposable test machine first.
4. Review the repository source and confirm no network or unexpected disk writes.
5. If Secure Boot is enabled and you must run unsigned code, accept the security trade-offs and consider signing the binary with a test key rather than disabling Secure Boot.

The project is an excellent entry-point to firmware programming and an entertaining twist on "desktop rituals" — so long as it is treated like the experiment it is, not a recommended workflow for everyday computing.

---

Source: Tom's Hardware Dev creates selection of UEFI games you have to beat in order to boot your computer — 10-month project will shut down your PC if you lose