Anatomy of a fake wallet.dat

1 · The container: a genuine Berkeley DB

The box is real. That says nothing about what was packed into it.

A Bitcoin Core wallet.dat is a Berkeley DB database (Hash or Btree). The manufacturers use the same container — which is why file reports “Berkeley DB (Btree, version 9, little-endian)” and why these files feel genuine at first touch. But the container format says nothing about the origin of the content. Inside live the same record types Core would write: version, minversion, flags, mkey, key/ckey (the keys), keymeta (metadata), pool (keypool), tx, name, defaultkey, bestblock, hdchain…

2 · The counterfeiter's signature: the custom mkey

One swapped field layout makes every password useless — by construction.

When it encrypts a wallet, Core writes the master key (mkey) in one fixed layout. Every encrypted BTC file in this corpus — 1,219 of 1,219 — uses another one:

genuine Bitcoin Core mkey                        salt[8] + key[32] + iters + method
08 [salt · 8]   20 [encrypted key · 32]   [iters · u32]   [method · u32]   00 [params]

counterfeiter tooling (this corpus: 1,219 / 1,219)   IV[16] + key[32] + salt[8] + 0 + iters
30 [IV 16 + encrypted key 32]   08 [salt · 8]   00000000   [iters · u32]   00
                                   ↑ Core misreads: “salt” = 48 B, “key” = 8 B, iters = 0
                                     → decryption impossible, password correct or not

It is the layout of a purpose-built tool: an explicit IV, then the key, then the salt at the end. Bitcoin Core, reading it, takes 48 bytes as the “salt”, 8 as the “key” and 0 as the iteration count: decryption is impossible even if you guess the password. The file only “works” as a hashcat/John hash — which is exactly what the seller attaches (.hash, PasswordHash.txt, wallet.hash).

3 · The dates that betray the factory

Every key carries its birth date in keymeta. Labels can be faked; time cannot.

• “0'1_BTC_13-05-2011”: ~2,000 keys generated in bursts across 2019–2021 — the last batch on 13-05-2021 — with internal Core version 0.20.1.
• “10000BTC”: 2,000 keys on 20-04-2020, in 24 minutes, with a 1,000-key keypool — a Core ≥ 0.16 feature (2018). Impossible for a “2011 wallet”.
• Internal versions from 0.14.2 to 24.0.1 (2017-2022) inside folders labeled 2011-2015.

An authentic 2011 wallet may well have been opened with a modern Core — that updates its version record — but it cannot regenerate its entire keypool with 2020 dates without having been rebuilt.

4 · Mass production: shared keypools

“Unique” wallets that share addresses, iteration counts — even one default key.

• “Different” wallets contain identical addresses: the “2.08763448 BTC” and “2.29597675 BTC” wallets share a keypool.
• Pairs of wallets share the exact mkey iteration count (34090, 35714, 125631…) — each factory run reused parameters.
• Most of the cuda8 series share one factory defaultkey (1LV8yhFejYPkZb1MT7pf4Hkvq2LhQ1G4TL; 177 of 235 corpus files, 25 distinct defaultkeys). Factory-key dust plus third-party bait where present: 190 of 235 synthetic-86 wallets have ≥1 active sampled address — none of it is yours.

specimen: samples/synthetic-86__a8b8fe3afe_17.dat — custom-iv mkey; embeds 3 active third-party addresses (~3.74 BTC today) — not yours.

5 · The bait: real addresses belonging to third parties

Embed funded addresses copied from the chain. The money stays where it was.

The most effective trick in the “premium” packs (folders with a date + a balance): choose real Bitcoin addresses with a real balance — mostly P2PK mining-pool payouts from 2013-2015, whose pubkeys are public on the chain — and embed them as defaultkey/ckey in a rebuilt wallet.

• The folder name encodes the balance the address had at tagging time (32'85679 = 32.85679 BTC — verified to the satoshi).
• Today ≈ 12,332 BTC remain on the 319 active third-party addresses embedded in corpus files: it belongs to their original owners (source: data/summary.json). The two “whales” of the pack (20,000 BTC at 1LfV1tSt…, 25 BTC at 14PcoSTA…) were drained years ago.
• There is no offline way to verify the attached ckey contains the authentic private key; every fabrication marker points to random payloads or freshly generated keys.

specimen: samples/dated-reconstruction__90e3045c33_36.04910000.dat — the name promises 36.0491 BTC; the address belongs to a third party.

6 · The props

Every “premium” wallet ships with its costume.

Password-Hints.txt with marketing copy (“American OTC trader… still receives whale alerts”), pywallet dumps, hashcat-ready hashes — and sometimes genuinely old imported transactions (2012, uncompressed P2PK) to give the tx record historical texture. The repo's data/seller_evidence/ folder preserves the originals verbatim.

7 · And when they don't even bother: non-BDB fakes

A “19,414 BTC Electrum wallet” that is a text file, and a JSON dump with a wallet's name.

• “Electrum wallet 19,414 BTC” → a 1.8 MB base64 text blob (a BIP38-style trick) — nothing to do with Electrum's real JSON format.
• A 23 MB wallet(3).dat → loose JSON with an addr_history: a dump, not a wallet.
• “Test” BIP38 keys (f4lc0npass123) and plaintext “test keys” (clavepruebas.txt = “Bit”) as garnish.

specimen: samples/bait-electrum-19414BTC__base64.txt.dat — 1.8 MB of base64 text with a price tag.

Moral: the pack invoices every format a buyer might recognize by name.

Addendum — the careless fillers: the padding also includes unencrypted wallets of dead altcoins (Primecoin, BBQCoin, Namecoin, old Litecoin…): readable today, networks mostly dead, coins worth cents. Class altcoin-plaintext → samples/altcoin-plaintext__8e799e84df_wallet2.dat

8 · The quick checklist

Five rows that separate an authentic wallet from a pack file.

Open a file right now

Is your file not in the database but shows these signals? Report it on GitHub — this database grows from reports. GitHub issues →