Extracting keys from MultiBit HD requires understanding the original wallet format and derivation behavior. It is not a general conversion from an encrypted JSON file to hexadecimal keys. Preserve the complete wallet and work on a separate copy.
Identify the backup before choosing a recovery method
mbhd.wallet.aes: the primary encrypted HD wallet.rolling-backup/*.wallet.aes: timestamped encrypted wallet snapshots.zip-backup/*.zip.aes: encrypted directory archives that can preserve additional application data.
For the documented software-wallet backup process, the primary wallet and rolling snapshots use password-based encryption; ZIP archives use a backup key derived from wallet words. An application password and wallet words are different recovery inputs. A file extension is a clue, not proof of its contents. A generic wallet.aes.json recipe is not a description of the MultiBit HD primary wallet format.
What decryption does and does not provide
The primary HD wallet uses the application’s encrypted wallet serialization. Decrypting its outer layer is only one step; a compatible parser must interpret the wallet and any remaining protected key material. An encrypted ZIP backup is a different input. Renaming it or applying an ordinary archive password command does not establish a valid recovery.
Why a generic OpenSSL/WIF script is insufficient
A one-line OpenSSL command does not reproduce all format-specific derivation, initialization and serialization requirements. Likewise, converting arbitrary bytes into WIF does not prove they represent the right private key. Key compression and network settings affect the corresponding address. Verify each candidate against independently recorded wallet addresses before using it.
Wallet words, password and restoration
Preserve the original words in their written order and record the original version if known. Do not identify a wallet solely by word count or assume that every HD wallet has a 13- or 18-word phrase. Keep any wallet date record: it helps choose a synchronization start point, but is not a replacement for the words.
The application password protects local wallet data. It should not automatically be entered into a modern recovery tool’s seed-passphrase field. The reviewed software-wallet creation methods use an empty seed passphrase; hardware-related and historical cases require separate identification.
The source distinguishes a BIP32 software wallet, an older beta implementation and hardware-related types. For the BIP32 software type, the source records the first receiving address at m/0'/0/0; this is not a universal recipe for every version. Verify a previously known address, receiving and change branches, and the search range before treating a zero balance as a failed recovery.
Export, import or sweep?
An export must cover the relevant receiving and change keys; recovering one key may leave other funds unaccounted for. Importing a key retains its address in another wallet. Sweeping spends funds to a new destination. Plan migration separately after verification, using current wallet instructions and a verified destination. Do not overwrite the original backups or broadcast transactions simply to test a hypothesis.
When to seek an assessment
Incorrect passwords, damaged files, missing words and an empty restored wallet are different problems. Record the exact error and available file types without disclosing the secrets. A recovery method needs evidence that matches the case; there is no universal extraction command.
Documentation and further reading
- HD primary wallet, rolling backups and ZIP backups
- Wallet words and verification
- Wallet types, paths and the beta exception
- Original MultiBit HD source at the reviewed revision
Need help with recovery?
Email mail@keychainx.io with the wallet type, approximate date, backup extensions and error message. Describe the problem first; do not send passwords, wallet words, private keys or wallet files in an initial message. KeychainX can assess a wallet you own or are legally authorized to recover. Recovery is not guaranteed.
Technical review: 7 October 2026. Recovery depends on the surviving material and the original wallet version.