Advanced users • Help Needed: Verifying EEPROM Integrity on a Used Raspberry Pi 5 – Confirm Genuine Flash and Avoid Malicious Trick

Hi everyone,
I'm a complete Raspberry Pi newbie, and I've recently acquired a second-hand Raspberry Pi 5. While the hardware looks normal (no unusual modifications that I can see), I'm a bit paranoid about potential security issues with the EEPROM, especially since it's a used device. I know this might sound overly cautious, but I can't help it—I want to make absolutely sure that when I flash new firmware, it's genuinely overwriting the existing EEPROM and not being tricked by any hypothetical malicious code that could be lingering there. I've read a lot about the boot sequence, OTP registers, and secure boot from the official docs, but I haven't found a foolproof way to confirm this. If I'm misunderstanding something fundamental, please correct me!

To give some context, my main concern is proving that the flashing process is authentic and not simulated by a malicious EEPROM firmware. For example, a bad actor could have tampered with the OTP bits to alter the boot flow, then mimic legitimate behaviors like accepting inputs from tools like rpiboot or SD card recovery, while only partially updating the EEPROM (e.g., leaving malicious parts intact in unused space). The goal is to either:

• Confirm I'm in a true recovery mode that bypasses the EEPROM entirely (and can't be imitated), or
• Directly verify the entire EEPROM contents after flashing to ensure complete overwrite.

Here's a breakdown of my thought process, based on the EEPROM boot flow (which I'll summarize below for reference). I'll explain the ideas I've considered, why they might work or fail, and what I'm hoping the community can help with. I've tried to integrate these into coherent methods, but they're a bit fragmented since I'm new to this—feel free to refine or debunk them.

Quick Summary of the Relevant Boot Flow (From Official Docs)
For Raspberry Pi 5 , the boot process starts with the BootROM (which is immutable and can't be written to):

• SoC powers up.
• Read OTP to check if nRPIBOOT GPIO is configured.
• If nRPIBOOT GPIO is high or OTP does NOT define it:
  • Check OTP to see if recovery.bin can be loaded from SD/eMMC.
    • If enabled, check primary SD/eMMC for recovery.bin.
      • Success: Run recovery.bin and update SPI EEPROM.
      • Fail: Continue.
    • Continue.
  • Check SPI EEPROM for second-stage loader.
    • Success: Run second-stage bootloader.
    • Fail: Continue.
• While True:
  • Attempt to load recovery.bin from USB device boot (this is the mode for rpiboot tool).
    • Success: Run recovery.bin and update SPI EEPROM or switch to USB mass storage mode.
    • Fail: Retry.

recovery.bin is basically a minimal program to reflash the EEPROM. OTP bits control things like whether SD recovery is allowed or if nRPIBOOT is defined/enabled.

The issue is that many "quick fixes" depend on OTP bits being unmodified, but I can't confirm that without a way to check them independently (not through steps controlled by the EEPROM). A malicious EEPROM could have altered OTPs to skip SD checks, boot from itself, detect an SD card with recovery.bin, and then simulate the flashing process—flashing lights, updating version numbers, reading config.txt, etc.—while preserving its malicious parts.

Method 1: Prove Full Overwrite by Flashing Random Data and Dumping the Entire EEPROM
This seems like the most robust way to me, as it doesn't rely on trusting the boot mode—it's based on the fact that the EEPROM is limited in size (and Pi 5 has no other persistent storage). The idea is to fill the entire EEPROM with random data to ensure no original/malicious code can hide in unused space, then verify by reading it back after a power cycle (to prevent RAM-based deception).

• Steps I'd Like to Do:
  • Use a tool like rpiboot to push a recovery.bin that writes random data to the entire EEPROM (not just a standard firmware, because standard firmwares leave unused space where malware could lurk and intercept reads to return fake values).
  • Power off and on.
  • Somehow dump the full raw contents of the EEPROM (not through a standard HASH flow, because the digest process are inside the Pi5 thus unreliable).
  • Compare the dumped data to what I wrote—if it matches exactly, the EEPROM must be clean, as random data can't be compressed/hidden while still allowing the malicious code to persist and fake responses.
• Why Random Data: It's like filling a room with random metal balls to confirm no intruder is hiding—if the balls match exactly what I put in (count, positions, etc.), there's no space left for anything else. A standard firmware only occupies a small portion, so malware could squat in the rest and fake dumps. But full random fill proves total overwrite.
• Challenges I've Hit:
  • rpiboot pushes the firmware and uses recovery.bin to verify checksum *before* power cycle, which isn't reliable if the EEPROM is simulating.
  • If I flash random data, the Pi won't boot normally afterward (which is fine for verification), but I need a way to extract the full dump post-flash without booting into a system controlled by the (now-random) EEPROM.
  • recovery.bin's behavior is rigid; rpiboot can't instruct it to "read only" without writing, because if it's a malicious EEPROM, it could receive the data, store it in memory, and fake later reads.

Question: Is there a tool or method to directly dump the entire EEPROM contents after flashing (e.g., via USB device mode or some debug interface), without relying on the booted system? Or a way to modify recovery.bin to do a full raw readback?

Method 2: Verify OTP Bits and Use SD Card Recovery
If I can confirm certain OTP bits haven't been tampered with (specifically, the one enabling recovery.bin from SD/eMMC—corresponding to "Check OTP to see if recovery.bin can be loaded from SD/EMMC"), then I could trust SD card flashing to overwrite the EEPROM.

• Why This Matters: If OTPs are stock, the boot ROM (immutable) should prioritize SD recovery before EEPROM. But if maliciously modified, it skips to EEPROM, which could then detect the SD card and fake the process (e.g., flash lights to mimic updating, update visible version numbers, but keep hidden payloads).
• Challenges: How to read OTP bits without the process being handed off to the EEPROM? It can't be through EEPROM-controlled steps, as that defeats the purpose.

Question: Is there a way to independently verify/read OTP bits (e.g., via a mode that doesn't involve EEPROM)?

Method 3: Look for Behaviors That EEPROM Can't Imitate
Prove the mode is genuine by observing something a malicious EEPROM *couldn't* fake, like precise LED blink patterns/timings during boot, debug serial output, or other hardware-level signals.

• Examples:
  • If entering EEPROM boot has unique LED behaviors or debug outputs controlled by BootROM that differ from USB device boot (the "While True" loop for rpiboot) .
  • Or if SD recovery mode has timings/outputs that can't be replicated if the EEPROM is in control.
• Challenges: I don't know the exact LED behaviors for each mode (e.g., how long they flash, patterns). I've never used debug outputs (like UART), so I don't know if that's viable. If a malicious EEPROM boots, it could mimic anything observable.
• Why This Could Work: The boot ROM controls initial steps, so if I see evidence of being in the ROM's loop (not EEPROM), I can trust flashing.

Question: What are the exact LED patterns or debug outputs for true ROM-controlled modes (e.g., USB device boot waiting for recovery.bin vs. EEPROM boot)? Are there any hardware behaviors that are impossible for EEPROM firmware to imitate? If so, how can I monitor them?

Notes and Why Standard Methods Aren't Enough

• Flashing from SD and checking reactions isn't reliable, as a tampered OTP could disable SD boot, then EEPROM simulates it perfectly (e.g., by checking for recovery.bin and faking outputs).
• Version numbers aren't proof, as malware could fake them.
• The key is distinguishing real modes from simulations.
• If recovery.bin ran a "read-only dump" without writing, that could help—but as is, writing first gives away the data for faking.
• I have also considered secure boot features, but secure boot on Pi 5 is ultimately enforced via OTP bits as well. So while having secure boot enabled could in theory prevent unauthorized changes, it doesn't solve the fundamental issue here: we still need a way to read or verify the OTP bits (or force certain behaviors) without the process being handed over to (and potentially lied about by) the EEPROM firmware. If there's any method to access/confirm OTP state independently of the EEPROM boot path, that would be valuable.

Hopefully I'm just overthinking this and there's actually a proper, built-in way to make sure I'm really in a legitimate recovery/flashing mode, or to confirm the EEPROM has been completely overwritten without any sleight-of-hand going on.

Thanks in advance for any insights!

Statistics: Posted by helloserif — Fri Jan 23, 2026 5:26 am

---