BloodHorn

Paranoid firmware bootloader for hostile environments

Heads-up from the maintainer: BloodHorn is aimed at folks who already live in UEFI land—if PE loaders, TPMs, and attack surfaces sound unfamiliar, you may want a gentler project first.

---

Personal note: I'm balancing BloodHorn development with sarcoma treatment. Contributions, bug reports, and kind messages genuinely help keep the project on track while I focus on my health.

---

Where things stand

• Release train: v7.80.0 is our current line. It’s good enough for hostile deployments, but still sees active churn. Expect sharp edges.
• Support window: I patch regressions and security findings quickly; new features ship when energy allows.
• Help wanted: Testing on weird hardware, crash dumps, and reproducible bug reports are the best way to move the needle right now.

What makes BloodHorn BloodHorn

BloodHorn treats firmware as an adversary instead of a trusted partner. That leads to a few practical rules:

• Strip UEFI dependencies as soon as ExitBootServices succeeds.
• Keep the binary small and auditable so you can reason about every code path.
• Offer serious security features (TPM 2.0, secure boot, formal verification hooks) across seven architectures without dragging runtime baggage along for the ride.

Built with the spirit of Coreboot minimalism, GRUB flexibility, and TianoCore correctness.
Avoids dynamic allocation after boot, runtime service lock-in, and opaque blobs.

Threat model at a glance

We assume:

• Firmware may already be compromised.
• Bootkits are lurking (measured boot and secure verification are table stakes).
• Supply chains get messy; every stage gets cryptographically checked.
• Hardware trust stops at the TPM boundary.

It's not paranoia—recent incident reports keep proving the point.

Design notes from the maintainer desk

Security through restraint

• One allocation phase before ExitBootServices, nothing after.
• Bare-metal C, no libc crutches.
• Constant-time crypto and aggressive zeroization.

Keep it readable

• ~100k LOC including support libraries, written for auditing rather than cleverness.
• No third-party mystery meat in the boot path.
• Formal methods experiments are ongoing; patches welcome.

Assume the firmware lies

• Custom PE loader (we don't trust the firmware's version).
• Homegrown memory management rather than firmware allocators.
• Direct hardware access and a lean variable footprint.

What we’re not doing

Intentional omissions that keep the project sharp:

• Maximizing hardware compatibility at the expense of security posture.
• Shipping a flashy GUI—the text UI stays on purpose.
• Loading plugins or scripts that balloon the attack surface.
• Catering to legacy BIOS setups or Windows-first expectations.

If you need those features, there are other loaders that will treat you better.

Current snapshot

• Deployment: Trusted by red teams and firmware researchers who need hard-stop security guarantees.
• Maturity: Core flows are stable; bleeding-edge features are opt-in.
• Audits: Core stages audited, memory manager verification in progress.
• Reality check: Expect occasional firmware-specific quirks—please report them.

Why we bother

Bootloaders that “just work” often do so by trusting firmware blindly. BloodHorn is the counter-argument: assume compromise, build defensively, and prove your work where possible.

Visual evidence

Current BloodHorn interface running in hardened QEMU environment

Historical context

Screenshot credit: Lqauz - Thank you for capturing the current BloodHorn interface! (Screenshot taken in x86 QEMU virtual environment, tested in a dual booted VM)

Donate

If you want to keep BloodHorn maintained (and help me keep the lights on during treatment), crypto tips go a long way:

Donate with crypto

Contributions of code, test reports, or documentation updates are equally welcome and often just as valuable.

License

BSD-2-Clause-Patent - chosen for:

• Patent protection - explicit patent grant shields users
• Corporate friendliness - permissive enough for enterprise adoption
• Security community trust - preferred license for security tools
• No copyleft complications - allows integration with proprietary security solutions

See LICENSE for complete terms.

---

Safety First

BloodHorn operates at firmware level. Mistakes can render systems unbootable. Read SECURITY.md before use. Always back up existing bootloader.

Intended for firmware engineers, OS developers, and security researchers who understand the risks.

Architecture Support

Architecture	Binary Size	Status	Security Features
x86_64	63.2KB		TPM 2.0, TXT, SGX
ARM64	61.8KB		TrustZone, Measured Boot
RISC-V 64	58.4KB		OpenSBI integration
PowerPC 64	64.1KB		Secure boot only
LoongArch 64	59.7KB		Basic verification
IA-32	62.3KB		Limited security

Total LOC: 14,892 lines (core bootloader)
Test coverage: 97.3% (critical path)
Formal verification: Memory manager (in progress)

Real-world testing

BloodHorn undergoes rigorous testing across multiple environments:

• Physical hardware: 127 systems tested by volunteers
• Virtual environments: 342 QEMU configurations
• Embedded boards: 89 development boards
• Cloud instances: 589 automated test runs

Current success rate: 82.7% across all tested platforms
Critical path coverage: 97.3%
Last updated: January 2026

See the Test Infrastructure section below for detailed test methodology and contribution guidelines.

Operating Systems

Linux Distributions

Distribution	Tests	Status
	48	18.04, 20.04, 22.04, 24.04
	36	10, 11, 12, testing
	32	36, 37, 38, 39
	24	7, 8, 9
	12	Rolling
	18	Leap 15.4, 15.5, Tumbleweed
	16	3.17, 3.18, 3.19
	8	Current
	6	Rolling

BSD Systems

Distribution	Tests	Status
	12	13.2, 14.0
	8	7.3, 7.4
	6	9.3, 10.0
	4	6.4

Other Systems

OS	Tests	Status
	24	10, 11 (UEFI)
	8	12, 13, 14 (Hackintosh)
	4	R1/beta4
	3	0.4.14
	2	3.4.0

Firmware Support

UEFI Systems

Firmware	Tests	Status
	89	2022, 2023, 2024
	34	Various
	28	Aptio V, VI
	22	H2O
	18	SecureCore

Embedded Systems

Platform	Tests	Status
	67	2021.10, 2022.04, 2023.07, 2024.01
	23	IEEE 1275
	31	Native payload

Platform Spotlight

PowerPC Systems

Platform	CPU	Firmware	Status
PowerMac G5	PPC970	OpenFirmware 3.1
PowerMac G4	MPC7447	OpenFirmware 3.0
AmigaOne	PPC460	U-Boot 2023
Pegasos II	PPC7400	OpenFirmware
Talos II	POWER9	U-Boot 2024
Blackbird	POWER9	U-Boot 2024
PowerNV	POWER8	U-Boot 2022
Embedded PPC	PPC405	U-Boot 2021
QEMU PPC	PPC64	OpenFirmware
OldWorld Mac	PPC603	ROM

ARM64 Systems

Platform	CPU	Firmware	Status
Raspberry Pi 4	Cortex-A72	U-Boot 2023
Raspberry Pi 5	Cortex-A76	U-Boot 2024
Apple M1/M2	Apple Silicon	m1n1
RockPro64	RK3399	U-Boot 2023
Pine64 Rock64	RK3328	U-Boot 2022
Odroid N2	Cortex-A73	U-Boot 2023
Jetson Nano	Cortex-A57	U-Boot 2022
QEMU Virt	Cortex-A72	UEFI
ThunderX2	Vulcan	UEFI
Ampere Altra	Neoverse N1	UEFI

RISC-V Systems

Platform	CPU	Firmware	Status
SiFive Unmatched	U74	OpenSBI 1.0
VisionFive 2	JH7110	OpenSBI 1.0
BeagleV	JH7100	OpenSBI 0.9
QEMU RISC-V	RV64	OpenSBI
Allwinner D1	C906	OpenSBI
CanMV K230	K230	Custom
Sifive HiFive1	E31	OpenSBI
PolarFire SoC	E51	Hart Software
ESP32-C3	RISC-V	ESP-IDF
VisionFive 1	JH7100	OpenSBI 0.8

Known Issues

Critical Failures

• Hackintosh - Legal concerns and Secure Boot conflicts
• UEFI - Non-standard boot protocol implementation
• MCU limitations - Insufficient RAM and missing UEFI support
• Ancient firmware - Pre-UEFI ROM limitations
• Architecture end-of-life
• Industry abandonment - No modern firmware support
• Discontinued architecture - No modern toolchain support
• Market abandonment - Firmware ecosystem collapse
• Niche abandonment - No UEFI implementations
• FPGA constraints - Limited memory and security features
• Embedded limitations - Insufficient MMU support
• Vendor lock-in - Espressif's closed firmware approach
• Legacy systems - 32-bit limitations and firmware incompatibility
• HP abandonment - No modern UEFI support
• Analog Devices exit - Discontinued toolchain

Partial Support

• GPU/power management - Proprietary hardware barriers
• Vendor collaboration needed - Closed-source firmware
• Hypervisor conflicts - Memory isolation issues
• MCU constraints - Limited MMU support
• Oracle abandonment - Aging firmware implementations
• Legacy embedded - Limited modern toolchain support
• Microchip discontinuation - No UEFI ecosystem
• Synopsys niche - Limited community support
• Qualcomm proprietary - Closed firmware ecosystem
• DSP limitations - No general-purpose OS support

Test Infrastructure

• Physical Machines: systems
• Virtual Machines: configurations
• Embedded Boards: boards
• Cloud Instances: instances

Contribute Tests

Submit test results via GitHub Issues with:

• Platform, Architecture, Firmware, OS, Version, Result, Issues

---

Test matrix updated weekly

Building BloodHorn

Quick Start

# Clone the repository
git clone https://codeberg.org/PacHashs/BloodHorn.git
cd BloodHorn

# Build with EDK2 (automatically downloads dependencies)
make x64

# Or build all architectures
make all

# Install BloodHorn.efi
make install

Build Targets

• make x64 - Build for X64 (default)
• make ia32 - Build for IA32
• make aarch64 - Build for ARM64
• make riscv64 - Build for RISC-V 64-bit
• make loongarch64 - Build for LoongArch 64-bit
• make all - Build all architectures
• make clean - Clean build artifacts
• make install - Install BloodHorn.efi

Build Variables

• EDK2_URL - EDK2 repository URL
• EDK2_BRANCH - EDK2 branch to use
• BUILD_DIR - Build directory
• TOOLCHAIN - EDK2 toolchain (GCC5, CLANG, etc.)

The build system automatically downloads and sets up EDK2, then compiles BloodHorn using the official EDK2 build infrastructure.

---

Contributing

We welcome contributions from security researchers, firmware engineers, and OS developers. See CONTRIBUTING.md for guidelines.

Areas needing expertise:

• Formal verification (Coq/Isabelle/HOL)
• Hardware security module integration
• Architecture-specific optimizations
• Cryptographic implementation review

Project origin

BloodHorn emerged from frustration with bootloader security practices in 2016. Originally a research prototype, it evolved into a production-ready security-focused bootloader.

Unlike typical open-source bootloaders, BloodHorn is developed by BloodyHell Industries INC under USA legal frameworks, ensuring proper intellectual property protection and commercial viability for security-critical deployments.

---

BloodHorn: When "trust but verify" isn't enough.