Every week we receive inquiries from people who found an old hard drive with a 10-year-old
wallet.dat file. Half the time, the file has funds. Half of those, the funds are
recoverable. This guide honestly explains what our engine does on a wallet.dat, why most services
fail with old wallets, and what you need to know if your case is viable.
Anatomy of a wallet.dat file
wallet.dat is NOT an encrypted text file. It's a BerkeleyDB
database (BDB 4.8 format in legacy versions, SQLite in Bitcoin Core 0.21+). Inside that DB
there are three relevant record types:
name_*: address ↔ label pairs (plaintext, not encrypted)tx_*: wallet transactions (partially encrypted — outputs yes, public inputs no)ckey_*: private keys encrypted with AES-256-CBC using a master key derived from the passwordmkey_*: master key with derivation metadata (n_iterations, salt, etc) — this is what we attack
The trick is that public addresses are extractable without password. You can
run bitcoin-cli dumpwallet against the file (after copying to a clean Bitcoin Core
instance) and obtain all addresses, which lets you check balance on
blockstream.info before investing a dollar in recovery.
At UnlockFile this is part of the USD 35 Diagnostic: we tell you if your wallet has funds before charging you for the full AI Scan. If wallet is empty (~30% of old archives we receive), we refund USD 35 minus operational cost and you didn't lose USD 2,000 AI Scan.
The encryption: AES-256-CBC + SHA-512 derivation
The password you enter when running encryptwallet "mykey" is NOT used directly to
encrypt. Bitcoin Core does the following:
1. Generates 8-byte random salt (stored in mkey_)
2. Derives master key: SHA-512(password || salt) iterated N times
- N depends on software version when encrypted
- Bitcoin Core 0.4 - 0.9: N = 25,000 iterations (2011-2013)
- Bitcoin Core 0.10 - 0.12: N = 25,000 - 50,000 (2014-2015)
- Bitcoin Core 0.13+: N = 50,000 - 200,000+ (2016+)
- Calibration: each release calibrates N to take ~100ms on
typical hardware of the era
3. Takes first 32 bytes as AES-256 key
4. Takes bytes 32-48 as IV
5. Encrypts each private key with AES-256-CBC + that key/IV
6. Stores ckey_ = AES-256-CBC(privkey, derived_key, IV)
This is why older wallets are easier to brute force: 25,000 SHA-512 iterations is a small computational cost on a modern RTX 3090. A 2013 wallet with reasonable password we can attack at millions of attempts/sec. A 2024 wallet with same password is in the order of hundreds of thousands/sec — 100x slower.
Why most services fail with pre-2017 wallets
There are three categories of wallet recovery services in the market:
1. "$0 upfront + 20-25%" services: use generic hashcat on cloud GPU
Hashcat has module -m 11300 for Bitcoin Core wallet.dat. It's a "best-effort"
service — they run a rented RTX 4090 on RunPod or Vast.ai for a few hours, try a common
dictionary + maybe rules, and if not found, abandon. The client doesn't find out they
abandoned until a month passes without news.
The technical problem: generic hashcat doesn't leverage non-standard hints (year-of-creation, language fingerprints, themes). And being rented hardware, every hour costs money — the incentive is to abandon hard cases fast.
2. "$2k+ upfront" services: custom GPU pipeline
KeychainX, ReWallet, Crypto Asset Recovery and us. We have dedicated hardware (not rented), custom CUDA kernels optimized for BTC ECDSA + SHA-512 batch, and the 40 hours we dedicate to your case is real compute, not burning office time. Throughput difference vs hashcat: our engine processes 100M SHA-512 attempts/second on a single RTX 3090. Generic hashcat does 10-15M.
3. "Services" that are scams
They ask you to send wallet.dat "for evaluation". Then they blackmail you with your
address info, or directly steal if they cracked and you don't have backup to move funds first.
NEVER send wallet.dat in plain text by email to anyone. Serious services work
with additionally-encrypted file, digital NDA, and you move funds first before paying success fee.
The "file size" factor
A little-known but useful heuristic:
| wallet.dat size | Probable content |
|---|---|
| ~20 KB | Newly created wallet, no transactions |
| 200 KB - 1 MB | Wallet with 5-50 transactions, possible balance |
| 1 - 5 MB | Wallet with 100+ transactions, high probability of balance |
| 5 - 20 MB | Active wallet for years, near certainty of significant balance |
| 20+ MB | Old exchange wallet or miner, 5+ figure crypto probable |
If your wallet weighs more than 8 MB and the file date is pre-2017, 100% worth paying the USD 35 Diagnostic. Probability of having funds is high and encryption is attackable.
The hints that make the difference
Without hints, attacking a 10-character password is mathematically infeasible (10^17 combinations at 100M/s = 30 years). With reasonable hints, search space reduces dramatically:
- Approximate length: knowing it was 8-10 chars eliminates 99% of space
- Charset: lowercase + numbers only reduces to 36 chars vs 95 (printable ASCII)
- Language: English passwords use different patterns (word + year + symbol)
- Year of creation: 2013 passwords rarely include symbols or uppercase
- Theme: pet name, birthday, meaningful word
- Known variants: if you used same pattern for other passwords
When you do AI Scan with us, our LSTM model generates plausible variants from your initial
hint. For example, if you remember "something with bitcoin and my birthday 1985", the engine
generates: bitcoin1985, Bitcoin1985!, btc85,
1985btc, Btc1985!, etc. Reduces search space 100-1000x vs blind brute force.
When we CAN'T recover (being honest)
- You remember absolutely nothing about password: if your hint is "I think it was English, but no idea about theme", search space is too large even for our cluster
- Password manager generated with 24+ random chars: mathematically out of reach
- wallet.dat with multiple encryption (someone encrypted it 2-3 times with different passwords)
- Corrupted file: broken BerkeleyDB we can't parse (rare, but happens with old disks)
- Wallet without original password that didn't have encryption but now asks for one: probably not the original file
If your case falls in any of those, we tell you in the viability report before charging the full AI Scan. The USD 35 Diagnostic is the filter.
Honest numerical comparison
| Case | Without us (DIY) | UnlockFile USD 2,000 |
|---|---|---|
| 2013 wallet, reasonable hint, 8 chars | Possible with hashcat + 1 RTX, ~30 days | 3-7 days |
| 2017 wallet, vague hint, 10 chars | Nearly impossible without pro GPU | 10-21 days, 60-70% success |
| 2020 wallet, no hint, 12+ chars | Impossible in lifetime | NOT viable, we tell you in report |
| 2014 wallet, password manager password | Impossible | NOT viable |
| 2015 wallet, hint "girlfriend name + year" | 1-2 months with hashcat + dictionary | 1-3 days with LSTM variants |
The step-by-step process if you hire us
- You pay Diagnostic USD 35: we confirm in 24h if wallet has funds and if it's attackable. If NOT viable, we explain why.
- If you decide to proceed, you pay AI Scan USD 2,000: we run 40h of dedicated GPU cluster with your hints. We deliver detailed technical report.
- If we find password, we send it encrypted: you open wallet on a clean Bitcoin Core instance, transfer funds to a new wallet of yours.
- Once you confirm receipt of funds, we invoice 30-40% success fee: comes out of recovered funds, not your prior pocket.
If you want to start, go to the main Wallet Recovery page or start directly with the USD 35 Diagnostic (we credit it back from the AI Scan if you proceed).