Cryptocurrency Recovery Case Files:
Forensics from the Digital Frontier.

In the nascent era of Bitcoin (circa 2010-2013), storing cryptocurrency was a digital "wild west." There were no Hierarchical Deterministic (HD) wallets, no 12-word seed phrases, and certainly no hardware devices like Trezor or Ledger. There was only the "Satoshi Client" (now known as Bitcoin Core) and a single, critically important file: wallet.dat.

We were recently contacted by a client in Auckland who had been an early enthusiast. He had mined Bitcoin on his university laptop in 2013, back when mining difficulty was low enough to solve blocks with a standard CPU. He had backed up his wallet.dat file to a generic 4GB USB stick, tossed it into a desk drawer, and largely forgotten about it for over a decade.

The Corruption Event

When the price of Bitcoin surged in early 2025, the client retrieved the USB drive to access his funds. He plugged it into his modern Windows 11 PC, but instead of a file directory, he was met with the dreaded prompt: "The disk structure is corrupted and unreadable." Panic naturally set in. He attempted to use free third-party recovery software, which managed to pull a file named wallet.dat, but when he loaded it into Bitcoin Core, the software crashed immediately. The file header was damaged.

Upon receiving the physical drive at the BlockWise secure lab, our first step was to create a sector-by-sector forensic image of the USB using write-blocking hardware. This ensures that no data is ever written to the fragile original drive during analysis, preserving the evidence.

DB Forensics

The wallet.dat file is technically a Berkeley DB database environment. It stores private keys as key-value pairs. Using a hex editor, we inspected the header bytes of the recovered file. The header was completely zeroed out, a common symptom of a file system (FAT32) failing to update the directory table before the drive was yanked out.

Standard database tools failed to open it. We had to utilize a custom Python script based on pywallet logic to scan the raw binary data for the specific byte signature of a Bitcoin private key (ECDSA key pairs). We weren't looking for the file structure; we were hunting for the mathematical signature of the keys themselves within the digital noise.

"We located 140 potential key pairs in the raw dump. However, they were encrypted."

The Brute-Force Attack

Bitcoin Core uses AES-256-CBC encryption. It is mathematically impossible to break without the password. However, we didn't need to break the encryption; we just needed to guess the password. The client believed he had used a password related to his "old World of Warcraft guild," but he couldn't remember the specifics.

We utilized our onsite GPU cluster (running 8x NVIDIA RTX 4090s). We built a custom wordlist based on the client's psychological profile: World of Warcraft terminology from 2013 (Lich King era), combined with his usual password habits (capitalizing the first letter, adding years).

The attack ran at a speed of 22 million passwords per second. After 4 days of silence, the console flashed green. The password was a combination of his Tamagotchi's name, his favourite class, and a memorable year: mametchimath1997.

We decrypted the private keys, imported them into a fresh Electrum environment, and watched as the balance synced: 47.3 BTC. The client was in tears. We helped him migrate the funds to a multisig cold storage setup immediately.

Cryptocurrency wallets rely on the BIP-39 standard, which converts a complex 256-bit binary number (your private key) into 24 human-readable words. This makes backups easier, but it also introduces the potential for physical degradation.

Our client, a DAO contributor from Wellington, had written his 24-word seed phrase on a piece of paper in 2016. Over time, entropy had blurred the ink on the bottom corner of the page. When his laptop died, he went to restore his Ledger, only to realize he could not read the last 3 words.

The Math of Missing Words

The BIP-39 wordlist contains 2048 distinct words. If you are missing 1 word, there are 2,048 possibilities. Simple enough to guess manually. However, if you are missing 3 words, the math becomes exponential: 2048 * 2048 * 2048 = 8,589,934,592 combinations. Trying 8.5 billion combinations manually is impossible.

The Checksum Constraint

The saving grace of BIP-39 is that the 24th word is not random. It contains a checksum (a verification code) derived from the previous 23 words. This means that for every combination of the first 23 words, there is only one valid 24th word.

This drastically reduces the search space. Since our client was missing words 22, 23, and 24, we essentially had to brute-force words 22 and 23, and then calculate word 24 to see if it matched the faint ink blot on the paper (which looked like it started with 's').

Executing the Attack

We wrote a script in Rust (chosen for memory safety and processing speed) to generate every possible pair for words 22 and 23. For each pair, the script calculated the required checksum word (word 24).

We then checked each valid generated mnemonic against the Ethereum blockchain. We were looking for an address that had a history of transactions, specifically, the large balance the client reported.

The Execution Loop:
1. Generate candidate phrase from wordlist.
2. Derive the Ethereum address (using the standard m/44'/60'/0'/0/0 path).
3. Check address against a local copy of the Ethereum address index (to avoid API rate limits).

It took our cluster 22 hours to crunch through the permutations. Finally, we found a match. The missing words were token, utility, and submit. The wallet contained 924 ETH, untouched since 2017.

Electrum is one of the oldest and most trusted Bitcoin desktop wallets. It protects your wallet file using AES-256 encryption derived from your password using a Key Derivation Function (KDF). This KDF is intentionally designed to be slow to compute, making brute-force attacks computationally expensive.

Our client had 28.7 BTC in an Electrum wallet he created in 2017. He knew the password was a sentence he used to use, but he had varied the capitalization and special characters. He estimated the password was over 20 characters long.

The Problem: A 20-character password is unbreakable by standard brute force. The heat death of the universe would occur before we tried 1% of the combinations. We needed a smarter approach.

The Tokenized Mask Attack

We interviewed the client for two hours. We didn't ask for the password directly; we asked for his habits.

• "Do you use spaces?" (No)
• "Do you capitalize every word?" (Usually)
• "What special characters do you like?" (! and @)

He remembered an old password containing "Poker" and "Winning". He wasn't sure of the order or the filler words.

We constructed a Combinatorial Token Attack. Instead of guessing letter-by-letter, we treated whole words as tokens: [Poker], [poker], [Win], [win], [Winning], [winning], [2017], [!].

We programmed our software (Hashcat with custom kernels) to rearrange these tokens in every possible order, very quickly.

Attempt 1: PokerWin2017! (Fail)
Attempt 2: WinningPoker!2017 (Fail)
...Attempt 4,592,031: PokerKing!Winning2017 (Success)

Because the client had inserted the exclamation mark in the middle of the phrase rather than the end, he had locked himself out for years. Once the correct permutation was found, the decryption took less than a second.

Hardware wallets like Trezor are generally the safest way to store crypto. However, they are still electronic devices subject to physical failure. A client came to us with a Trezor Model One that was stuck in a boot loop.

He had attempted to update the firmware. During the update, the USB cable was bumped, severing the connection at the critical "write" moment. Now, the device would only show a static glitch pattern on the OLED screen. The client had lost his seed phrase backup two years prior. The Trezor was his only copy of the key.

Flash Memory Forensics

When a firmware update fails, the operating system (OS) is often corrupted, but the data sectors (where the seed is stored) usually remain intact until the new OS overwrites them. The device was effectively "soft-bricked", the brain was dead, but the memory was alive.

We could not use the USB interface, as the USB stack requires the OS to be running. We had to go deeper.

We opened the device casing to access the STM32 microcontroller directly. Using a method known as Voltage Glitching (in a strictly controlled forensic environment), we attempted to force the chip into a diagnostic bootloader mode that bypasses the standard startup checks.

By briefly dropping the voltage to the chip at the exact clock cycle where it checks for a valid OS, we tricked the processor into entering a "wait" state. From here, we could dump the raw contents of the flash memory to a binary file.

The dump was encrypted with the client's PIN. Since the client knew his PIN, we were able to decrypt the specific memory address range 0x08000000 where Trezor stores the mnemonic. We extracted the 24 words, verified them on an air-gapped machine, and restored the wallet. The $890,000 in assets were safe.

The Solana ecosystem moves fast. A client contacted us after accidentally deleting his browser extension data. He was using the Phantom wallet on Chrome and, in an attempt to troubleshoot a connection issue, he clicked "Remove from Chrome."

He didn't realize that removing the extension instantly deletes the local database containing the encrypted private keys. He did not have his seed phrase written down.

Data Recovery & LevelDB

Browser extensions like Phantom store data in a format called LevelDB (.ldb files) deep within the Windows AppData folder. When you delete the extension, Windows marks these files as "free space," but it doesn't immediately overwrite the zeros and ones, unless you are using an SSD with "TRIM" enabled.

TRIM is an SSD feature that permanently wipes deleted data to maintain speed. We instructed the client to unplug his computer immediately. Every second the computer was on, the SSD background processes were eating his data.

He shipped the SSD to our lab. We mounted it in a write-blocker and scanned the physical drive for the specific hexadecimal signature of a LevelDB log file.

We found fragments of the deleted ldb file. It was corrupted and incomplete. However, LevelDB is a "log-structured merge-tree." This means it keeps a history of changes. We located an older "compaction" of the database that hadn't been fully overwritten.

Inside this fragment was a JSON string containing the encryptedSecretKey. We extracted this string and used a custom script to wrap it in a fresh Phantom wallet container. We then used the client's password to decrypt the container. The 450 SOL was recovered.