BIP-39 Seeds, Why a Simple Disk Scan Isn't Enough
Building a seed phrase scanner means confronting how data gets written and deleted, and why simple string matching misses the mark on truly recover...
BIP-39 Seeds, Why a Simple Disk Scan Isn't Enough
Someone building a BIP-39 seed phrase scanner that reads raw disk sectors is solving a very real problem. We've all heard stories, or maybe been part of one, where a wallet went missing. Reconstructing a seed from a damaged or partially overwritten disk isn't just about finding 12 or 24 words; it's a deep dive into file systems, data recovery, and the limitations of raw sector scans.
Here's why it's more complex than just hitting grep on a raw disk image:
The Fragmentation Problem
When you save a file, the operating system doesn't always write it in one contiguous block. Especially on older or heavily used drives, a single text file (like your seed.txt) can be fragmented, with parts scattered across different sectors. A simple linear scan might pick up "word1 word2 word3" but entirely miss "word4 word5" because there's a JPEG or an old log file in between.
Effective recovery needs to understand the file system's allocation tables to reassemble these fragments. Even then, if the allocation table itself is corrupted, you're looking at heuristic guesswork based on adjacent data and known file types.
Overwriting and Wear Levelling
SSDs complicate things significantly with wear levelling. Data isn't simply written to a specific physical sector and erased from it. The SSD controller actively moves data around, distributes writes to prolong the drive's life, and performs garbage collection. So, even if you "delete" a seed phrase, the original data might still exist in a different physical location, while the logical address is marked free. Conversely, a sector that used to hold part of a seed might now contain completely unrelated data due to this internal management.
For HDDs, overwriting is more straightforward. A new write usually obliterates the old data. But even then, residual magnetism can sometimes allow specialized forensic tools to recover a single overwritten layer. For a DIY scanner, this is generally out of reach.
Encoding and Entropy
BIP-39 seeds are derived from a high-entropy source. The word list itself is well-defined. But what if the original storage wasn't plain text? What if it was in a screenshot, a PDF, or an encrypted archive? A raw sector scanner needs to account for various encodings and data formats. It's not just about finding words; it's about finding valid sequences of those words in specific contexts, potentially after decoding or decrypting. The probability of randomly finding a valid BIP-39 sequence increases if you're just looking for words, but decreases dramatically if you demand the correct checksum and entropy rules.
The Engine's Real Challenge
Building an open-source engine for this is a great step. The true value comes not just from reading raw sectors, but from intelligently parsing them. It means implementing:
- File signature analysis: Identifying potential file fragments by their headers/footers.
- Contextual parsing: Understanding that "apple banana orange" is a valid sequence, but "apple banana cat" (if 'cat' isn't in the BIP-39 list) isn't.
- Checksum validation: The critical step to confirm if a found sequence is actually a real seed.
- Fuzzy matching: Accounting for typos or slight corruption in individual words.
Just scanning for strings will yield a lot of false positives. The real engineering challenge is filtering that noise and presenting only the sequences that have a high probability of being the actual seed. It's less about finding words and more about finding meaningful, cryptographically valid sequences within a sea of digital debris.