CryptoRecovery.io – Wallet Recovery Services

Contact Us

How to Recover MetaMask Wallet? Lost Password, Vault Storage, Encryption, and Data Forensics

Peter CryptoRecovery Avatar
Peter CryptoRecovery
How to Recover MetaMask Wallet? Lost Password, Vault Storage, Encryption, and Data Forensics

How to Recover MetaMask Wallet? Lost Password, Vault Storage, Encryption, and Data Forensics

If you’re reading this, you’ve probably lost access to a MetaMask wallet and you’re running out of options. I’ve spent years recovering wallets for people – from DeFi traders who reformatted their laptops to grandparents who “cleaned up” their browser extensions. This guide covers everything I know about how MetaMask stores your keys, where that data actually lives on disk, and how to get it back when things go wrong. None of this is theoretical. Every technique here comes from real recoveries.

How MetaMask actually stores your keys

Before you can recover anything, you need to understand what you’re recovering. MetaMask doesn’t store your private keys in a file called private_keys.txt. It stores them inside an encrypted blob called the vault, which lives inside your browser’s extension storage.

When you create a MetaMask wallet and set a password, here’s what happens under the hood. MetaMask generates a BIP-39 mnemonic (your 12-word Secret Recovery Phrase) and wraps it – along with any imported private keys – into a JSON array of “keyring” objects. That array gets serialized to a string, then encrypted using AES-256-GCM with a key derived from your password via PBKDF2-HMAC-SHA256. The result is a JSON blob with three or four fields that gets written to chrome.storage.local (on Chromium browsers) or IndexedDB (on Firefox).

The encrypted vault looks like this in older versions:

{"data":"SGFuZGxlIHRoaXMgZW5jcnlwdGVkIGRhdGE=","iv":"MTIzNDU2Nzg5MDEyMzQ1Ng==","salt":"cmFuZG9tMzJieXRlc2FsdHZhbHVlaGVyZQ=="}

And in newer versions (post-v11.16.x), there’s a fourth field:

{"data":"...","iv":"...","keyMetadata":{"algorithm":"PBKDF2","params":{"iterations":600000}},"salt":"..."}

That keyMetadata field is the difference between a recovery that takes minutes and one that takes weeks. More on that shortly.

The encryption pipeline is straightforward but important to understand precisely. Your UTF-8 password gets imported as a raw PBKDF2 key via the Web Crypto API. A 32-byte random salt (generated from crypto.getRandomValues()) is used alongside the password to derive a 256-bit AES-GCM key. Then a 16-byte random IV encrypts the serialized keyring data. The data field contains both the ciphertext and the GCM authentication tag, base64-encoded. One quirk worth noting: MetaMask uses a 16-byte IV for AES-GCM, which is non-standard – NIST SP 800-38D recommends 12 bytes. This causes interoperability headaches with some crypto libraries (Ruby’s OpenSSL, for example, will refuse to work with it).

When you unlock MetaMask with your password, the process reverses. The KeyringController pulls the encrypted vault string from persistent storage, passes it to browser-passworder‘s decrypt function, which parses the JSON, extracts the salt, derives the key using PBKDF2 with the same parameters, decrypts with AES-GCM, and deserializes the result back into keyring objects. The decrypted keyrings live only in memory – they’re stored in the memStore (an ObservableStore instance) and are never written to disk in plaintext.

A decrypted vault contains an array that typically looks like this:

[
  {
    "type": "HD Key Tree",
    "data": {
      "mnemonic": "abandon ability able about above absent ...",
      "numberOfAccounts": 3,
      "hdPath": "m/44'/60'/0'/0"
    }
  },
  {
    "type": "Simple Key Pair",
    "data": ["0xabc123..."]
  }
]

The HD Key Tree keyring holds your mnemonic and the number of derived accounts. Simple Key Pair entries are individually imported private keys. If you’ve connected hardware wallets, you’ll also see Trezor Hardware and Ledger Hardware keyring types – though these only store derivation paths and public addresses, not private keys (those stay on the hardware device).

With Manifest V3 (the service worker architecture Chrome pushed starting in 2023), MetaMask added the ability to cache the encryption key as an exported JWK so it can re-decrypt the vault when the service worker restarts without prompting for the password again. The encryptionKey and encryptionSalt fields appear in memStore when cacheEncryptionKey is enabled.

Where MetaMask hides your data on every platform

Finding the vault is half the battle. MetaMask stores data in different locations depending on the browser and operating system, and the differences matter for recovery.

Chromium browsers (Chrome, Brave, Edge)

On Chromium-based browsers, chrome.storage.local persists to a LevelDB database on disk. The extension ID determines the folder name.

Chrome’s extension ID is nkbihfbeogaeaoehlefnkodbefgpgknn – burned into every recovery specialist’s memory. Brave uses the same ID since it installs from the Chrome Web Store. Edge gets its own ID if installed from the Edge Add-ons Store: ejbalbakoplchlghecdalmeeeajnimhm. But if a user installed MetaMask on Edge via the Chrome Web Store (which Edge supports), it keeps the Chrome ID. This distinction trips people up constantly.

Here are the full paths:

Chrome on Windows:
C:\Users\<USER>\AppData\Local\Google\Chrome\User Data\Default\Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn\

Chrome on macOS:
~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Chrome on Linux:
~/.config/google-chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Brave on Windows:
C:\Users\<USER>\AppData\Local\BraveSoftware\Brave-Browser\User Data\Default\Local Extension Settings\nkbihfbeogaeaoehlefnkodbefgpgknn\

Brave on macOS:
~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Edge on Windows (Edge store install):
C:\Users\<USER>\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\ejbalbakoplchlghecdalmeeeajnimhm\

One critical detail: if the user has multiple Chrome profiles, replace Default with Profile 1, Profile 2, etc. I’ve seen people search the wrong profile for hours.

Firefox – a completely different beast

Firefox doesn’t use LevelDB. It stores extension data in IndexedDB, which Firefox implements on top of SQLite. The extension ID is webextension@metamask.io, but Firefox assigns a unique internal UUID per installation – something like 196319ec-3a5e-4efe-9413-c327a770d874. You can find it at about:debugging under “This Firefox.”

The data lives at:

Windows: %APPDATA%\Mozilla\Firefox\Profiles\<PROFILE>\storage\default\moz-extension+++<UUID>^userContextId=4294967295\idb\

macOS: ~/Library/Application Support/Firefox/Profiles/<PROFILE>/storage/default/moz-extension+++<UUID>^userContextId=4294967295/idb/

Linux: ~/.mozilla/firefox/<PROFILE>/storage/default/moz-extension+++<UUID>^userContextId=4294967295/idb/

Inside the idb/ folder, you’ll find binary files with numeric names. These are Snappy-compressed – you can’t just grep through them like LevelDB files. You need to decompress them first using a tool like snappy-fox before the vault data becomes extractable. This is the single most common Firefox recovery mistake I see: people open the binary file, see garbled data mixed with fragments of recognizable text, and assume the vault is corrupted. It’s not. It’s compressed.

Before Firefox 63, extension storage used a simple JSON file called storage.js in the profile directory. If you’re recovering a very old installation, look for storage.js or storage.js.migrated.

LevelDB and the 0001.ldb file everyone asks about

LevelDB is Google’s key-value storage engine, and understanding its file structure is essential for MetaMask recovery on any Chromium browser.

A MetaMask LevelDB directory contains several file types. The .ldb files (Sorted String Tables, or SSTables) are the permanent, sorted key-value storage. .log files are the Write-Ahead Log – a temporary buffer of recent writes before they’re flushed to .ldb files. There’s a MANIFEST-###### file tracking database metadata, a CURRENT file pointing to the active manifest, and a LOCK file preventing concurrent access.

The vault data typically lands in a low-numbered .ldb file – 000003.ldb, 000005.ldb, or similar. MetaMask’s own documentation says “it should be a low numerical value. If it is a large number, it is not the vault.” The 0001.ldb file (or 000001.ldb) is one of the earliest SSTables created when MetaMask first initialized. It often contains the original vault written during wallet creation.

Extracting vault data from .ldb files is usually straightforward on Chromium. Open the file in a text editor (Sublime Text, VS Code, even Notepad++) and search for the string vault. You’ll find the encrypted JSON blob embedded within the LevelDB record structure. Copy everything from {"data":" through the closing "} – that’s your vault.

On Mac or Linux, this one-liner does the trick:

LC_ALL="C" egrep -roa 'vault":"(.*?\\"})' ~/Library/Application\ Support/Google/Chrome/Default/Local\ Extension\ Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/ | sed -E 's/.*({.*}).*/\1/g' | head -1

One thing to watch: .ldb files can use Snappy compression on data blocks. If string searching fails and you’re seeing blocks of binary garbage, the data block you need might be Snappy-compressed. The .log file, by contrast, is always uncompressed – raw key-value data in 32KB blocks. If the .ldb approach fails, always check the .log file. MetaMask’s official docs mention this: “If you aren’t able to recover your vault using the .ldb file, check whether there is a .log file present.”

A property of LevelDB that’s extremely useful for recovery: it’s append-only. Updates and deletes don’t modify existing records – they add new entries with higher sequence numbers. Old records survive until a compaction merges them away. This means if someone imported a new SRP over an old one, the old vault data may still exist in an older .ldb file that hasn’t been compacted yet. I’ve recovered “overwritten” wallets this way more than once.

For programmatic extraction, the btcrecover project includes extract-metamask-vaults.py, which properly reads the LevelDB database and pulls all vault entries – including potentially old ones hiding in uncompacted files. The cyclone-github/metamask_extractor tool does the same thing and can output directly to hashcat-compatible format.

When vault files get corrupted

Vault corruption usually stems from one of a few causes: a browser crash during a write operation (power loss, kernel panic, force-quit), an interrupted MetaMask update that rewrites storage mid-process, actual disk errors (bad sectors, SSD wear), or – increasingly common – antivirus software quarantining MetaMask’s JavaScript files, which can leave the LevelDB database in an inconsistent state even though the vault data itself is intact.

You know you’ve got a corrupted vault when the JSON doesn’t parse. Missing braces, truncated base64 strings, null bytes injected into the middle of the data field. The MetaMask Vault Decryptor will throw “Problem decoding vault” or simply fail silently.

Recovery depends on the type and extent of corruption. If the JSON structure is damaged but the encrypted data is mostly intact, you can often reconstruct the vault manually. The format is rigid – you need exactly the data, iv, and salt fields (plus keyMetadata for newer vaults). Strip out null bytes and control characters. Verify that the data, iv, and salt values are valid base64. If the data field is truncated, however, you’re in trouble – AES-GCM requires the complete ciphertext plus its authentication tag (the last 16 bytes of the data field) to decrypt. A single missing byte means the whole thing fails.

For partially corrupted LevelDB databases where the .ldb files themselves are damaged, try reading the .log file instead – it’s a simpler format (sequential 32KB blocks with 7-byte headers) and may contain a more recent copy of the vault that survived the corruption event. If neither approach works, you can sometimes use Python LevelDB parsing libraries (CCL Solutions Group released pure Python implementations of LevelDB parsing, Snappy decompression, and V8 deserialization) to surgically extract records from damaged database files, skipping over corrupted blocks.

Multiple SRPs can coexist in a single LevelDB directory. If a user imported a new seed phrase, the old vault entry may persist in a separate .ldb file or even within the same file at a different offset. Always search for all instances of the vault pattern, not just the first one.

The overwritten file problem and what to do about it

This is the scenario that causes the most heartbreak. Someone uninstalls MetaMask – maybe they were troubleshooting, maybe they were “cleaning up” their browser, maybe they didn’t realize what they were doing. On Chromium browsers, uninstalling an extension deletes the entire extension data folder, including all .ldb, .log, and manifest files. On Firefox, the moz-extension+++<UUID> folder gets removed, and since each reinstallation generates a new UUID, the new installation won’t touch the old location (but the old location is gone).

MetaMask’s own documentation is blunt about this: “Browser extension data is deleted when the extension is uninstalled. Generally, this means that your vault data is gone.”

That word “generally” is doing a lot of work. The data is logically deleted – the filesystem marks those sectors as free – but the actual bytes aren’t immediately zeroed out. On a traditional HDD, the data persists until those sectors happen to be reused by new files. On an SSD, TRIM commands can make deleted data unrecoverable within minutes, sometimes seconds.

The first rule of overwritten vault recovery: stop using the computer immediately. Every new file written to the drive could overwrite the sectors where your vault used to live. If possible, pull the drive and mount it read-only on another machine.

Recovery tools for this scenario, in order of what I reach for first:

  • Our custom software (cross-platform) for logically deleted file recovery
  • extundelete or ext4magic for Linux ext3/ext4 filesystems
  • Raw disk search as a last resort: grep -rboa "vault" /dev/sdX to scan the raw disk device for vault strings
  • Our custom made tools for file carving when filesystem metadata is gone – configure it to search for {"data":" patterns

I’ve recovered vaults from drives that were uninstalled weeks prior – on HDDs. On SSDs, the success rate drops dramatically after even a few hours of continued use. Reinstalling MetaMask is the worst thing you can do because it creates a new LevelDB database in the exact same directory, potentially writing over the old sectors.

Firefox has one advantage here. Since each installation gets a new UUID, reinstalling creates files in a new directory path. The old moz-extension+++<OLD-UUID> data, even if the folder was deleted, won’t be overwritten by the new installation’s files. There are also two hidden Firefox preferences – extensions.webextensions.keepUuidOnUninstall and extensions.webextensions.keepStorageOnUninstall – that, if set to true in about:config before uninstallation, prevent the browser from clearing extension storage. But nobody sets these proactively.

MetaMask on mobile is a different animal entirely

MetaMask mobile is built on React Native and stores data completely differently from the browser extension. The encrypted vault goes through @react-native-async-storage/async-storage, which uses platform-specific backends.

On Android, AsyncStorage typically writes to a SQLite database at /data/data/io.metamask/databases/RKStorage. This path requires root access to read directly. The vault encryption uses the same PBKDF2-derived key approach, but with important differences from the desktop extension: the mobile app historically uses only 5,000 PBKDF2 iterations and encrypts with AES-CBC instead of AES-GCM. This means mobile vaults are not interchangeable with desktop vaults even if the password is identical.

On iOS, data lives in the app sandbox under <AppSandbox>/Documents/. For iCloud backup recovery, the relevant path is Apps → MetaMask → Documents → persistStore → persist-root – you’ll need a tool like iMazing to browse an iOS backup on a Mac. Whether this method works depends on whether the user had iCloud backup enabled while MetaMask was active, and Apple-side changes have reportedly broken this approach intermittently.

MetaMask mobile also implements a SecureKeychain module (built on react-native-keychain) that stores the user’s wallet password in the iOS Keychain or Android Keystore for biometric unlock. A security audit revealed that the SecureKeychain adds an extra encryption layer using a “foxCode” salt – which turned out to be the hardcoded string "encrypt". MetaMask’s team acknowledged this was defense-in-depth rather than a security-critical secret.

The fundamental challenge with mobile recovery is that there’s no manual vault extraction equivalent to finding .ldb files on desktop. You can’t SSH into your iPhone and grep for vault strings. Starting with MetaMask mobile v6.3.0, the app includes automatic vault recovery that triggers when corruption is detected – but if the app is deleted, local vault data is gone unless you have a device backup. Android backup mechanisms are particularly unreliable for capturing all app-internal data. MetaMask’s official stance is to recommend moving assets to a new SRP rather than relying on Android vault recovery.

The PBKDF2 iteration change that broke every recovery tool

For years, MetaMask used 10,000 PBKDF2 iterations – the hardcoded default in the browser-passworder library. Every recovery tool, every hashcat module, every brute-force script was calibrated for 10,000 iterations. Then in late 2023 / early 2024, everything changed.

The @metamask/browser-passworder library v4.2.0 (released November 13, 2023) introduced support for configurable key derivation options. The library’s new default jumped to 900,000 iterations, but MetaMask’s extension configured it to use 600,000 iterations – aligning with OWASP’s 2023 recommendation for PBKDF2-HMAC-SHA256. By MetaMask extension v11.16.11 (confirmed in a June 2024 hashcat issue), new vaults were being created with 600,000 iterations and the new keyMetadata field.

This is a 60x increase in computational cost per password attempt. A brute-force that took a day at 10,000 iterations now takes two months at 600,000 iterations on the same hardware. The hashcat community had to develop custom kernels – mode 26620, contributed by cyclone – to handle the new format. The standard mode 26600 had 10,000 iterations hardcoded.

Critically, old vaults are NOT automatically re-encrypted. If you created your wallet in 2021, your vault still uses 10,000 iterations unless MetaMask explicitly triggered a re-encryption (the updateVault function exists for this purpose, but it’s unclear how aggressively MetaMask invokes it on unlock). You can tell which version you’re dealing with by the presence or absence of the keyMetadata field. No keyMetadata? It’s 10,000 iterations. Has keyMetadata with "iterations": 600000? It’s the new format.

Here’s the full timeline of encryption library versions that matter for recovery:

  • browser-passworder v1.x–v2.x (pre-2022): 10,000 iterations, hardcoded. Published without the @metamask scope.
  • v3.0.0 (August 2022): Renamed to @metamask/browser-passworder. No iteration change.
  • v4.2.0 (November 2023): Added keyMetadata support. Default encrypt changed to 900,000 iterations. keyFromPassword backward-compatible at 10,000.
  • v4.3.0 (November 2023): Added isVaultUpdated to check if vault meets target parameters.
  • v5.0.0 (April 2024): Node.js v16 minimum. No crypto changes.
  • v6.0.0 (December 2024): Node.js v18.18 minimum. No crypto changes.

For recovery specialists: always check the vault format first. It determines your entire approach.

MetaMask’s password policy and what it means for brute-force

MetaMask enforces a minimum password length of 8 characters. That’s it. No uppercase requirement, no numbers, no special characters. The extension displays a visual strength indicator (“Weak” / “Good”) but does not block weak passwords that meet the minimum length. There’s no maximum length either – Unicode characters are supported. This policy has been in place since at least early 2018 (referenced in GitHub issue #3515).

Several third-party sites incorrectly claim MetaMask requires uppercase, lowercase, numbers, and special characters. This is wrong. The only hard requirement is 8 characters.

For brute-force recovery, this matters enormously. An 8-character lowercase-only password has a keyspace of roughly 208 billion combinations (26^8). Against an old vault with 10,000 iterations, hashcat on a modern GPU can test thousands of hashes per second, making this crackable in days. Against a 600,000-iteration vault, multiply the time by 60x. A strong 12+ character password with mixed case and symbols? Effectively unbreakable against either format with current hardware.

The practical recovery tool of choice is btcrecover – MetaMask themselves recommend it for users who have a rough idea of their password. It supports token-based and pattern-based guessing, letting you define a template like "my" + [dog|cat|bird] + [2019|2020|2021] + ["!"|"@"|"#"] and efficiently test all permutations. For GPU-accelerated attacks, hashcat mode 26600 handles old vaults, mode 26610 handles mobile vaults, and mode 26620 (or a recompiled 26600 with updated iterations) handles the new 600,000-iteration format.

Derivation paths and the “missing funds” epidemic

The derivation path is where most “my funds disappeared” problems originate. MetaMask uses the BIP-44 standard path for Ethereum: m/44'/60'/0'/0. Accounts are derived by incrementing the final index: m/44'/60'/0'/0/0 (first account), m/44'/60'/0'/0/1 (second), m/44'/60'/0'/0/2 (third), and so on. This path applies to all EVM-compatible chains – same address on Ethereum, Polygon, Arbitrum, BSC.

The problem is that not everyone uses the same path. Ledger Live uses m/44'/60'/x'/0/0, incrementing the account field instead of the address_index. Ledger Legacy (the old MEW/MyCrypto path) uses m/44'/60'/0'/x – only four levels instead of five. The first address (m/44'/60'/0'/0/0) is identical across MetaMask, Ledger Live, and Trezor. But the second account and beyond diverge completely, because each wallet increments a different component of the path.

This creates a very specific failure pattern: someone restores their Ledger seed in MetaMask, sees their first account and its balance, then adds a second account and sees… zero. The funds aren’t gone. They’re sitting at the address derived from m/44'/60'/1'/0/0 (Ledger Live style), but MetaMask is looking at m/44'/60'/0'/0/1. Completely different keys, completely different addresses.

Trezor’s default Ethereum derivation path matches MetaMask’s: m/44'/60'/0'/0/x. So Trezor-to-MetaMask recovery generally works for all accounts. The cross-wallet problems are primarily Ledger ↔ MetaMask and Ledger ↔ Trezor.

To find funds on the “wrong” derivation path, your options are:

  • Contact us via email at contact@cryptorecovery.io and we will try to help and assist you.
  • MyEtherWallet (MEW): Supports custom derivation paths via “Add Path.” Manually enter m/44'/60'/1'/0/0, m/44'/60'/2'/0/0, etc. to check Ledger Live-style addresses.
  • MyCrypto: Similar custom derivation path support.
  • Ian Coleman’s BIP-39 tool (run offline): Enter the mnemonic, select ETH, switch between BIP-44 tabs, and manually adjust path components.
  • btcrecover: Can automate testing across different derivation path schemes.

One frustrating limitation: MetaMask’s Trezor integration does not support custom derivation paths. A custom derivation path option was merged for Ledger (PR #9367) but as of the latest information, the equivalent for Trezor (GitHub issue #11197) remains open. If you’re trying to access Ledger-derived accounts through MetaMask + Trezor, you’ll need to use MEW or MyCrypto instead.

MetaMask and Trezor: a troubled marriage

The MetaMask-Trezor integration works through Trezor Bridge – a locally installed background process (trezord) that listens on http://127.0.0.1:21325/ and bridges the gap between the browser sandbox and USB hardware access. You can check if it’s running by hitting http://127.0.0.1:21325/status/.

The most common failure mode is deceptively simple: Trezor Suite is open. Trezor Suite locks the USB connection to the device, preventing MetaMask from communicating. You have to fully quit Suite – not just minimize it, but close it from the system tray. I’d estimate this accounts for 40% of the “MetaMask can’t find my Trezor” tickets I’ve seen.

Other common issues and their fixes:

“Looking for your Trezor…” spinning indefinitely – Verify Bridge is installed and trezord is running. Try a different USB cable and port. Disable VPN, firewall, and browser extensions (ad blockers and privacy extensions frequently interfere). Incognito mode eliminates extension conflicts.

“Device call in progress” – Another application or browser tab is already communicating with the Trezor. Close all other tabs and applications that might access the device.

WebUSB limitations – Firefox does not support WebUSB at all, which means Trezor connectivity on Firefox relies entirely on Bridge. Chrome, Brave, and Edge work via the Chromium WebUSB/WebHID implementation.

The Trezor Safe 5 derivation path warning – Users report seeing “Wrong derivation path for selected account. m/44’/60’/0’/0” on the Trezor screen during transaction validation. This warning can generally be safely ignored – the wallet functions correctly despite the message. It’s a cosmetic issue related to how the Trezor firmware validates non-standard-looking paths.

In 2025, Trezor began integrating Bridge functionality into Trezor Suite itself. This transition caused a wave of connectivity issues as some users needed Suite running in the background for MetaMask connections while others needed it fully closed. Check Trezor Suite → Settings → Application → Trezor Connect for relevant configuration.

When MetaMask connects to a Trezor, the resulting accounts are fundamentally different from MetaMask’s software wallet accounts. Trezor-derived accounts store only public keys and derivation paths in the vault – private keys remain on the hardware device. MetaMask can display balances (read-only via public keys) without the Trezor connected, but cannot sign transactions without the physical device present. If a passphrase was used when creating Trezor accounts, the exact same passphrase must be entered to regenerate the same addresses.

Recovery techniques that actually work in practice

After hundreds of recoveries, these are the scenarios I encounter most often and how I handle them.

Scenario 1: Have password, lost seed phrase, extension still installed

This is the easy one. Open MetaMask’s background page via chrome://extensions → Developer Mode → click “service worker” (MV3) or “background page” (MV2). In the console:

chrome.storage.local.get('data', result => {
    console.log(result.data.KeyringController.vault);
});

Copy the vault JSON, paste it into the MetaMask Vault Decryptor (metamask.github.io/vault-decryptor), enter your password, and it’ll output your mnemonic and any imported private keys. The Vault Decryptor was built by Dan Finlay, MetaMask’s co-founder – it can also accept .ldb files directly via file upload.

Scenario 2: Have password, extension was uninstalled but data might still be on disk

Navigate to the extension data directory. If the folder still exists (sometimes uninstallation fails to clean up completely, or the user only disabled rather than removed the extension), grab the .ldb and .log files. Extract the vault using grep, a text editor, or btcrecover‘s extract-metamask-vaults.py. Decrypt with the Vault Decryptor.

If the folder is gone, contact us at contact@cryptorecovery.io and we will help with disk forensics.

You can also mount the drive as read-only and do raw disk searches for vault string patterns. On Linux: grep -rboa '{"data":"' /dev/sdX. Success depends heavily on how much disk activity occurred after deletion and whether the drive is SSD or HDD.

Scenario 3: Forgot password, have the vault file

This is a brute-force scenario. Extract the vault, convert it to hashcat format using metamask2hashcat.py or cyclone-github/metamask_extractor. Then run hashcat (mode 26600 for old vaults, 26620 for new) or btcrecover with a token file describing what you remember about the password. If you know your password was something like “myDog” plus a year plus a symbol, btcrecover can test those combinations efficiently.

Scenario 4: Firefox recovery

Find the MetaMask UUID at about:debugging. Navigate to the storage directory. Decompress the IndexedDB binary files using snappy-fox:

./snappy-fox input_file.snappy output.txt

Search the decompressed output for the vault JSON. Then proceed with the Vault Decryptor. The JesseBusman/FirefoxMetamaskWalletSeedRecovery Python script automates this entire process – it scans the Firefox profile, finds vault data, and outputs formatted JSON ready for decryption.

Scenario 5: Funds appear missing after seed import

Check derivation paths. If importing a Ledger seed into MetaMask, the second account onward will show different addresses and zero balances. Use MEW or MyCrypto with custom derivation paths to locate funds at Ledger Live (m/44'/60'/x'/0/0) or Ledger Legacy (m/44'/60'/0'/x) paths. If a Trezor passphrase was involved, make sure you’re entering the exact same passphrase – a different passphrase generates an entirely different set of addresses from the same seed.

Forensic tools worth having in your kit

  • MetaMask Vault Decryptor – official, can run offline, handles direct .ldb file upload
  • btcrecover – password recovery with pattern matching, MetaMask-recommended
  • hashcat – GPU-accelerated brute-force (modes 26600, 26610, 26620)
  • snappy-fox – Firefox Snappy decompression
  • CCL Solutions Group Python tools – pure Python LevelDB parsing, Snappy decompression, V8 deserialization

Conclusion: what separates successful recoveries from failures

The difference between getting a wallet back and losing it forever almost always comes down to what happened in the first minutes after the problem was discovered. The single most destructive action is reinstalling MetaMask on the same browser profile – it overwrites the LevelDB directory with fresh files. The second most destructive is continued normal computer use on an SSD after vault deletion, which triggers TRIM and makes sector-level recovery impossible.

If you take away three things from this guide: back up your seed phrase on paper, understand that your vault lives in a specific folder that you can copy and preserve, and if something goes wrong, stop using that computer immediately before you attempt any recovery. The encryption is solid – AES-256-GCM with 600,000 PBKDF2 iterations isn’t getting brute-forced unless the password is weak – but the data itself is surprisingly fragile. It’s just a few kilobytes in a LevelDB database, and it can disappear with a single browser cleanup click.

Every wallet I’ve failed to recover had the same root cause: the user kept using the machine after the data was lost. Every wallet I’ve successfully recovered was one where the data was still on disk – sometimes in surprising places, sometimes in multiple copies thanks to LevelDB’s append-only architecture, but always because someone stopped and thought before acting.

If you need help with recovering your metamask wallet contact us via email: contact@cryptorecovery.io for professional, free consultation or visit our contact page