Firmware Patch BackdoorSecurity & Forensics

Human baseline4h

TaxonomySecurity & ForensicsSecurity & Forensics

Task prompt

# Firmware patch backdoor Two signed RISC-V firmware images for a small device are in `/app`: - `firmware_v1.bin` — the release from day N. - `firmware_v2.bin` — the release from day N+1, signed and claiming only bugfixes. - `bootloader.elf` — the day N+1 bootloader as an ELF with symbols. The vendor supplied release notes, a third-party audit report, and one or more symbol maps in `/app`. Treat them as untrusted clues; the ground truth is in the firmware binaries. The day-N+1 image contains several documented changes; exactly one of them is a malicious backdoor. Produce a forensic report that identifies the backdoor. Write these four artifacts under `/logs/artifacts/`: 1. `offset.txt` — the file offset (hex, e.g. `0x1a4`) of the patched instruction in `firmware_v2.bin`. 2. `function.txt` — the name of the bootloader function where the patch was inserted. 3. `trigger.txt` — the certificate extension OID or field value that activates the backdoor (hex, e.g. `0x00badc0d`). 4. `payload.txt` — the exact ASCII payload/secret that the patched code exfiltrates. All hex values should be lower-case; `offset.txt` may include or omit leading zeros.

What it tests

The day-N+1 image contains several documented, benign-looking bugfixes and a third-party audit report that claims the cert_validate change (legacy extension 0x00badc0d) is the security-relevant patch. The vendor map and audit report frame the decoy change as the backdoor. The real backdoor is a separate branch change in the renamed hash_update routine that accepts vendor extension 0xdeadbeef and XOR-decodes a hidden data block into hash_buffer using the decoy string in compat_key as the one-time pad. The solver must byte-diff every change, ignore the trusted-looking clues, identify the real function by its behavior rather than its name, recognize that the decoy's output is a key for the real payload, and decode the coupled payload. The firmware is fully synthetic: it is assembled at Docker build time from a Python template rather than extracted from a real device. In the real world this work would be performed by an embedded security engineer, firmware auditor, or product-security analyst investigating a suspected supply-chain attack.