Infekterad BIOS

Platform: undutmaning | Category: Reversing | Type: Challenge | Difficulty: Medium | OS: Windows | Author: XESXOR | Date: 2026-03-21 | Status: Solved Techniques: known_plaintext_attack, uefi_runtime_analysis, utf16le_string_extraction, xor_key_recovery

Summary

English summary: Harriet found a submarine wreck containing a computer with a flash chip. The computer is x86-64 architecture with UEFI firmware. There appears to be a suspicious EFI file in the firmware that needs to be analyzed.

Infekterad BIOS — undutmaning

Description

Harriet har lånat dykarutrustning och ger sig ut på en liten upptäcksfärd utanför CASCADA. Ganska snart stöter hon på ett ubåtsvrak som verkar ha legat under vatten väldigt länge. I vraket hittar hon en dator med ett flash chip som ser hyffsat oskadat ut. Hon tar med sig datorn tillbaka till CASCADA. Datorn verkar vara av arkiteturen x86 (64 bitars). Harriet lyckas läsa ut innehållet på chipet och det verkar vara UEFI firmware på den. Efter ytterligare lite granskning kommer Harriet fram till att det verkar finnas en suspekt fil i firmwaret. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

English summary: Harriet found a submarine wreck containing a computer with a flash chip. The computer is x86-64 architecture with UEFI firmware. There appears to be a suspicious EFI file in the firmware that needs to be analyzed.

Files provided:

• bin.efi — UEFI EFI runtime driver (8384 bytes)

Analysis

Initial File Identification

 bash read-only • copy allowed Copy
$ file bin.efi
bin.efi: MS-DOS executable PE32+ executable (EFI runtime driver) x86-64

The binary is a UEFI runtime driver for x86-64 architecture. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

String Extraction

Standard string extraction revealed:

• Debug path: /home/user/downloads/git-repos/uefi-edk2/Build/RuntimeHookTest/RELEASE_GCC5/X64/RuntimeHookTestPkg/RuntimeHookTest/RuntimeHookTest/DEBUG/RuntimeHookTest.dll
• Standard UEFI error strings (Success, Load Error, Invalid Parameter, etc.)

UTF-16LE strings at specific offsets:

• [FRA SÄPO MUST] at offset 0x1a94 — reference to Swedish intelligence agencies
• Entry undut spoof! at offset 0x1ab6

SecureBoot Hook Analysis

The binary is a UEFI runtime hook targeting SecureBoot: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

1. String Check (0x510-0x5ab): Compares characters 's', 'e', 'c', 'u', 'r', 'e', 'b', 'o', 'o', 't'

2. XOR-encoded NT function names (XOR key 0xff):

   • ZwCreateFile at offset 0x5de
   • ZwWriteFile at offset 0x629

3. Path construction: Builds NTFS path with "undut" components using alternate data streams

Flag Encryption Algorithm

Located at offsets 0x868-0x901:

Step 1 — Key Generation (0x868-0x888):

 python read-only • copy allowed Copy
for i in range(0x100):
    key[i] = kernel_base[i % 5] ^ 0x22

The key is derived from the first 5 bytes of the kernel base address, XOR'd with 0x22. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Step 2 — Encrypted Flag Data (0x88a-0x8c9):

0xD72D145557D6161A  -> offset -0x2e1
0x2C5557D6163A4844  -> offset -0x2d9
0x102C5557D6163A48  -> offset -0x2d8 (overlapping)
0x5C47D5160A4D4ED3  -> offset -0x2d0

Step 3 — Decryption (0x8ef-0x901):

 python read-only • copy allowed Copy
for i in range(0x19):  # 25 bytes
    flag[i] = encrypted[i] ^ key[i]

Solution

Known Plaintext Attack

Since the flag format undut{...} is known, we can use the first 6 bytes as known plaintext to recover the 5-byte repeating XOR key. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 python read-only • copy allowed Copy
#!/usr/bin/env python3
"""
Infekterad BIOS - Flag Decryption via Known Plaintext Attack
"""
import struct

# Encrypted data extracted from immediate values in disassembly
val1 = 0xD72D145557D6161A
val2 = 0x2C5557D6163A4844
val3 = 0x5C47D5160A4D4ED3
val4 = 0x102C5557D6163A48

# Convert to bytes (little-endian)
b1 = struct.pack('<Q', val1)
b2 = struct.pack('<Q', val2)
b3 = struct.pack('<Q', val3)
b4 = struct.pack('<Q', val4)

# Reconstruct memory layout based on offsets
encrypted = bytearray(25)
encrypted[0:8] = b1
encrypted[8:9] = b2[0:1]
encrypted[9:17] = b4
encrypted[17:25] = b3
‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

# Known plaintext: flag starts with "undut{"
known = b"undut{"

# Derive 5-byte repeating key from known plaintext
key = bytearray(5)
for i in range(5):
    key[i] = encrypted[i] ^ known[i]

print(f"Recovered key: {key.hex()}")

# Verify key derivation: key ^ 0x22 should give PE header bytes
pe_header = bytes(k ^ 0x22 for k in key)
print(f"PE header check: {pe_header}")  # Should be b'MZ\x90\x00\x03'

# Decrypt full flag
flag = bytes(encrypted[i] ^ key[i % 5] for i in range(25))
print(f"Flag: {flag.decode()}")

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Key Insight

The key is derived from the kernel base address (first 5 bytes) XOR'd with 0x22. Since PE files always start with "MZ" (0x4D 0x5A), we can verify our recovered key:

key ^ 0x22 = b'MZ\x90\x00\x03'

This confirms the key recovery is correct.

Lessons Learned

1. UEFI Firmware Analysis — EFI drivers are PE32+ executables that can be analyzed with standard RE tools

2. XOR Encryption Weakness — When the key is derived from predictable data (like PE headers), known plaintext attacks are trivial ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

3. String Encoding Awareness — UEFI/Windows environments often use UTF-16LE; check both ASCII and wide strings

4. Immediate Value Extraction — Encrypted data stored as immediate values in assembly requires careful offset reconstruction ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍