CryptoRecovery.io – 钱包恢复服务

联系我们

如何恢复 MetaMask 钱包？密码丢失、金库存储、加密及数据取证

彼得·CryptoRecovery 头像
彼得·加密恢复
如何恢复 MetaMask 钱包？密码丢失、金库存储、加密及数据取证

如何恢复 MetaMask 钱包？密码丢失、金库存储、加密及数据取证

如果您正在阅读这篇文章，那么您很可能已经无法访问 MetaMask 钱包，并且已经束手无策。多年来，我一直帮助人们恢复钱包——从因重新格式化笔记本电脑而丢失钱包的DeFi交易者，到因“清理”浏览器扩展程序而丢失钱包的祖父母。本指南涵盖了我所了解的关于MetaMask如何存储密钥、这些数据在磁盘上的实际存储位置，以及在出现问题时如何找回数据的所有知识。这些内容绝非理论，这里介绍的每种方法都源自真实的恢复案例。

MetaMask 实际上是如何存储您的密钥的

在恢复任何内容之前，您需要先了解要恢复的是什么。MetaMask 不会将您的私钥存储在一个名为 private_keys.txt. 它将这些数据存储在一个名为 金库，它存储在浏览器的扩展程序存储中。

当您创建 MetaMask 钱包并设置密码时，其背后的运作原理如下。MetaMask 会生成一个 BIP-39 助记词（即您的 12 个单词 秘密恢复短语) 并将它——连同任何导入的私钥——封装成一个由“keyring”对象组成的 JSON 数组。该数组会被序列化为字符串，然后使用 AES-256-GCM 使用通过您的密码生成的密钥 PBKDF2-HMAC-SHA256. 结果是一个包含三到四个字段的 JSON 数据块，该数据块会被写入 chrome.storage.local （在 Chromium 浏览器上）或 IndexedDB（在 Firefox 上）。

在旧版本中，加密保险库的外观如下：

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

而在较新版本（v11.16.x 之后）中，还新增了一个字段：

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

那个 keyMetadata 这正是几分钟就能恢复与数周才能恢复之间的区别。稍后将对此进行详细说明。

加密流程虽然简单，但必须准确理解。您的 UTF-8 密码会通过 Web Crypto API 作为原始 PBKDF2 密钥导入。一个 32字节随机盐值 （由...生成） crypto.getRandomValues()) 与密码结合使用，以生成一个 256 位 AES-GCM 密钥。然后一个 16字节随机初始化向量 对序列化的密钥环数据进行加密。该 data 该字段同时包含经过 Base64 编码的密文和 GCM 认证标记。值得注意的一点是：MetaMask 使用一个 AES-GCM 的 16 字节初始向量，这不符合标准——NIST SP 800-38D 建议使用 12 字节。这会导致与某些加密库的互操作性问题（例如，Ruby 的 OpenSSL 就会拒绝与之配合使用）。

当您使用密码解锁 MetaMask 时，该过程将反向进行。该 KeyringController 从持久化存储中读取加密的保险库字符串，并将其传递给 browser-passworder的 decrypt 该函数负责解析 JSON，提取盐值，使用相同的参数通过 PBKDF2 生成密钥，使用 AES-GCM 进行解密，并将结果反序列化回密钥环对象。解密后的密钥环存储在 仅存于记忆中 – 它们存储在 memStore (一个 ObservableStore （例如）且绝不会以明文形式写入磁盘。

解密后的保险库包含一个数组，其结构通常如下所示：

[
  {
    "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..."]
  }
]

该 HD Key Tree 密钥环中存储了您的助记词以及由此生成的账户数量。 Simple Key Pair 这些条目是单独导入的私钥。如果您已连接硬件钱包，您还会看到 Trezor Hardware 以及 Ledger Hardware 密钥环类型——尽管它们仅存储派生路径和公钥地址，而不存储私钥（私钥仍保存在硬件设备上）。

借助 Manifest V3（Chrome 自 2023 年起推广的服务 worker 架构），MetaMask 新增了将加密密钥作为导出的 JWK 进行缓存的功能，这样当服务 worker 重启时，它就能重新解密金库，而无需再次提示输入密码。该 encryptionKey 以及 encryptionSalt 字段出现在 memStore 当 cacheEncryptionKey 已启用。

MetaMask 在各个平台上如何隐藏您的数据

找到钱包位置就成功了一半。MetaMask 会根据浏览器和操作系统的不同将数据存储在不同的位置，而这些差异对恢复过程至关重要。

Chromium 浏览器（Chrome、Brave、Edge）

在基于 Chromium 的浏览器上， chrome.storage.local 保存到 LevelDB 数据库 在磁盘上。扩展 ID 决定了文件夹名称。

Chrome 的扩展程序 ID 是 nkbihfbeogaeaoehlefnkodbefgpgknn ——这一幕深深烙印在每位康复专家的记忆中。 勇敢 由于它是从 Chrome 应用商店安装的，因此使用相同的 ID。 Edge 如果从 Edge 扩展程序商店安装，它将获得一个独立的 ID： ejbalbakoplchlghecdalmeeeajnimhm. 但如果用户通过 Chrome 应用商店（Edge 支持该商店）在 Edge 上安装了 MetaMask，它会保留 Chrome 账号。这种区别经常让人们感到困惑。

以下是完整路径：

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

macOS 上的 Chrome：
~/Library/Application Support/Google/Chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Linux 版 Chrome：
~/.config/google-chrome/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

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

macOS 版 Brave：
~/Library/Application Support/BraveSoftware/Brave-Browser/Default/Local Extension Settings/nkbihfbeogaeaoehlefnkodbefgpgknn/

Windows 版 Edge（通过 Edge 应用商店安装）：
C:\Users\<USER>\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\ejbalbakoplchlghecdalmeeeajnimhm\

一个关键细节：如果用户拥有多个 Chrome 配置文件，请将 Default 使用 Profile 1, Profile 2等等。我见过有人在错误的个人资料页面上搜索了好几个小时。

Firefox——截然不同的存在

Firefox 不使用 LevelDB。它将扩展数据存储在 IndexedDB，Firefox 是基于 SQLite 实现的。该扩展的 ID 是 webextension@metamask.io，但 Firefox 会为每次安装分配一个唯一的内部 UUID——类似于 196319ec-3a5e-4efe-9413-c327a770d874. 您可以在 about:debugging 在“此版 Firefox”下

数据位于：

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/

在 idb/ 文件夹中，你会发现一些名称为数字的二进制文件。这些是 Snappy压缩 – 你不能像处理 LevelDB 文件那样直接用 grep 命令搜索它们。你需要先使用类似 snappy-fox 在保险库数据能够被提取出来之前。这是我见过的最常见的 Firefox 数据恢复错误：人们打开二进制文件，看到乱码数据中夹杂着可识别的文本片段，便以为保险库已损坏。其实并非如此，它只是被压缩了。

在 Firefox 63 之前，扩展程序存储使用了一个名为 storage.js 在配置文件目录中。如果您正在恢复一个非常旧的安装，请查找 storage.js 或 storage.js.migrated.

LevelDB 以及大家常问的 0001.ldb 文件

LevelDB 是谷歌的键值存储引擎，了解其文件结构对于在任何 Chromium 浏览器上恢复 MetaMask 至关重要。

一个 MetaMask LevelDB 目录包含多种类型的文件。该 .ldb 文件 （排序字符串表，即 SSTables）是一种永久性的、按键值排序的存储结构。 .log 文件 是预写日志（Write-Ahead Log）——这是在写入操作被刷新到 .ldb 文件。有一个 MANIFEST-###### 文件跟踪数据库元数据，一个 CURRENT 指向活动清单的文件，以及一个 LOCK 文件阻止并发访问。

金库数据通常会存储在 序号较小的 .ldb 文件 – 000003.ldb, 000005.ldb，或类似的。MetaMask 的官方文档中提到：“该数值应较小。如果数值很大，则不是金库。”该 0001.ldb 文件（或 000001.ldb) 是 MetaMask 首次初始化时创建的最早的 SSTable 之一。它通常包含在创建钱包时生成的原始保险库。

从 .ldb 文件 在 Chromium 上通常很简单。用文本编辑器（Sublime Text、VS Code，甚至 Notepad++）打开该文件，然后搜索字符串 vault. 您会发现加密的 JSON 数据块嵌入在 LevelDB 记录结构中。请复制从 {"data":" 直至交割 "} ——那就是你的保险库。

在 Mac 或 Linux 上，这条一行命令就能搞定：

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

值得关注的一点： .ldb 文件可以使用 高效压缩 关于数据块。如果字符串搜索失败且看到大段二进制垃圾数据，您需要的数据块可能采用了 Snappy 压缩。该 .log 相比之下，文件始终是未压缩的——以32KB为单位块的原始键值数据。如果 .ldb 该方法失败， 请务必检查 .log 文件. MetaMask 的官方文档中提到：“如果您无法使用 .ldb 文件恢复保险库，请检查是否存在 .log 文件。”

LevelDB 的一项对恢复工作极其有用的特性：它是 仅追加. 更新和删除操作不会修改现有记录——它们会添加序列号更大的新条目。旧记录会一直保留，直到压缩操作将其合并删除。这意味着，如果有人将新的 SRP 导入到旧的 SRP 上，旧的保险库数据可能仍然存在于较旧的 .ldb 尚未压缩的文件。我曾多次通过这种方式恢复“被覆盖”的钱包。

对于程序化提取， btcrecover 该项目包括 extract-metamask-vaults.py，该工具能正确读取 LevelDB 数据库并提取所有存储库条目——包括那些可能隐藏在未压缩文件中的旧条目。该 cyclone-github/metamask_extractor 该工具功能相同，且可直接输出为与 hashcat 兼容的格式。

当保险库文件损坏时

保险库损坏通常源于以下几种原因之一：写入操作过程中浏览器崩溃（断电、内核恐慌、强制退出）、MetaMask 更新过程中被中断（此时存储正在重写）、实际的磁盘错误（坏道、SSD 磨损），或者——这种情况越来越常见——杀毒软件将 MetaMask 的 JavaScript 文件隔离，这可能会导致 LevelDB 数据库处于不一致状态，即使保险库数据本身完好无损。

当 JSON 无法解析时，你就知道金库已损坏。可能出现缺失的大括号、截断的 base64 字符串，或是数据字段中间被注入了空字节。MetaMask 金库解密工具会报错“解码金库时出错”，或者直接无提示地失败。

恢复情况取决于损坏的类型和程度。如果 JSON 结构已损坏，但加密数据基本完好，通常可以 手动重建存储库. 格式要求严格——你必须完全按照 data, iv，以及 salt 字段（加上 keyMetadata （针对较新的存储库）。去除空字节和控制字符。验证 data, iv，以及 salt 这些值是有效的 Base64 编码。如果 data 如果字段被截断，那你就麻烦了—— AES-GCM 需要完整的密文 加上其认证标签（数据包末尾的最后 16 个字节） data 字段) 进行解密。只要缺失一个字节，整个过程就会失败。

对于部分损坏的 LevelDB 数据库，其中 .ldb 如果文件本身已损坏，请尝试读取 .log 改用文件——该格式更为简单（由带7字节头部的32KB顺序块组成），且可能包含在数据损坏事件中幸存下来的、更新版本的保险库副本。 如果这两种方法均无效，有时可以使用 Python LevelDB 解析库（CCL Solutions Group 发布了 LevelDB 解析、Snappy 解压和 V8 反序列化的纯 Python 实现），从损坏的数据库文件中精准提取记录，同时跳过受损的块。

一个 LevelDB 目录中可以同时存在多个 SRP。如果用户导入了新的助记词，旧的保险库条目可能会保留在另一个 .ldb 文件中，甚至是在同一文件的不同偏移量处。始终搜索 所有实例 拱顶图案的全部，而不仅仅是第一个。

文件被覆盖的问题及应对措施

这种情况最令人扼腕。有人卸载了 MetaMask——也许是在排查故障，也许是在“清理”浏览器，也许只是没意识到自己在做什么。在基于 Chromium 的浏览器上，卸载扩展程序 删除整个扩展数据文件夹，包括所有 .ldb, .log以及 manifest 文件。在 Firefox 中， moz-extension+++<UUID> 文件夹会被删除，而且由于每次重新安装都会生成一个新的 UUID，因此新安装不会使用旧的位置（但旧的位置已经不存在了）。

MetaMask 的官方文档对此直言不讳：“卸载扩展程序时，浏览器扩展程序的数据将被删除。通常来说，这意味着您的金库数据将不复存在。”

“通常”这个词的作用很大。数据在逻辑上已被删除——文件系统会将这些扇区标记为空闲——但实际的字节并不会立即被清零。在传统硬盘上，数据会一直保留，直到这些扇区被新文件重新占用为止。而在固态硬盘上，TRIM命令可以在几分钟内，有时甚至几秒钟内，使已删除的数据无法恢复。

恢复被覆盖的保险库的第一条规则是：立即停止使用该计算机。写入该硬盘的任何新文件都可能覆盖保险库原先所在的磁区。如果可能的话，请取出该硬盘，并在另一台计算机上以只读模式挂载它。

针对这种情况的恢复工具，按我优先使用的顺序排列如下：

  • 我们专为逻辑删除文件恢复开发的定制软件（跨平台）
  • 适用于 Linux ext3/ext4 文件系统的extundelete或ext4magic
  • 原始磁盘搜索 作为最后的手段： grep -rboa "vault" /dev/sdX 扫描原始磁盘设备以查找保险库字符串
  • 我们的定制工具 用于文件系统元数据丢失时的文件恢复——将其配置为搜索 {"data":" 模式

我曾成功从数周前已卸载的硬盘（HDD）中恢复过钱包。但在固态硬盘（SSD）上，即使仅持续使用几小时，成功率也会急剧下降。重新安装 MetaMask 是最糟糕的做法，因为它会在完全相同的目录下创建一个新的 LevelDB 数据库，这可能会覆盖旧的数据扇区。

Firefox 在这方面有一个优势。由于每次安装都会生成一个新的 UUID，因此重新安装时文件会保存在新的目录路径下。旧的 moz-extension+++<OLD-UUID> 即使该文件夹已被删除，其中的数据也不会被新安装的文件覆盖。此外，还有两个隐藏的 Firefox 首选项—— extensions.webextensions.keepUuidOnUninstall 以及 extensions.webextensions.keepStorageOnUninstall – 若设置为 true 在 about:config 在卸载之前，请防止浏览器清除扩展程序的存储数据。但没有人会主动进行这些设置。

移动端的 MetaMask 完全是另一回事

MetaMask 移动版基于 React Native 构建，其数据存储方式与浏览器扩展完全不同。加密保险库会经过 @react-native-async-storage/async-storage，该系统使用针对特定平台的后端。

在 Android 系统上, AsyncStorage 通常会写入一个 SQLite 数据库 在 /data/data/io.metamask/databases/RKStorage. 此路径需要 root 权限才能直接读取。保险库加密采用相同的 PBKDF2 派生密钥方法，但与桌面扩展程序存在重要区别：移动应用历来仅使用 5,000 次 PBKDF2 迭代 并使用 AES-CBC 而不是 AES-GCM。这意味着，即使密码相同，移动端保险库也无法与桌面端保险库互换使用。

在 iOS 上, 数据存储在应用程序沙盒下的 <AppSandbox>/Documents/. 对于 iCloud 备份恢复，相关路径是 Apps → MetaMask → Documents → persistStore → persist-root – 您需要使用 iMazing 之类的工具，才能在 Mac 上浏览 iOS 备份。此方法能否奏效，取决于用户在使用 MetaMask 期间是否启用了 iCloud 备份；此外，据称苹果方面的更新已导致该方法时有失效。

MetaMask 移动版还实现了 SecureKeychain 模块（基于 react-native-keychain) 该功能将用户的钱包密码存储在 iOS 钥匙串或 Android 密钥库中，以便通过生物识别方式解锁。安全审计发现，SecureKeychain 通过使用名为“foxCode”的盐值添加了一层额外的加密——结果发现该盐值竟是一段硬编码的字符串 "encrypt". MetaMask 团队承认，这属于多层次防御措施，而非关乎安全的关键机密。

移动数据恢复面临的核心挑战在于 无法手动提取保险库 相当于找到 .ldb 桌面上的文件。你无法通过 SSH 连接到 iPhone 并使用 grep 命令查找保险库字符串。从 MetaMask 移动版 v6.3.0该应用包含自动保险库恢复功能，当检测到数据损坏时会自动触发——但如果应用被删除，除非你有设备备份，否则本地保险库数据将不复存在。Android 的备份机制在保存所有应用内部数据方面尤其不可靠。 MetaMask的官方立场 建议将资产转移到新的 SRP，而不是依赖 Android 保险柜恢复功能。

那个导致所有恢复工具失效的PBKDF2迭代次数变更

多年来，MetaMask一直使用 10,000 次 PBKDF2 迭代 – 该文件中的硬编码默认值 browser-passworder 库。每款数据恢复工具、每个hashcat模块、每个暴力破解脚本都经过了10,000次迭代的校准。直到2023年底/2024年初，一切都发生了变化。

该 @metamask/browser-passworder 库 v4.2.0（2023 年 11 月 13 日发布）引入了对可配置密钥派生选项的支持。该库的新默认值已调整为 90万次迭代，但 MetaMask 的扩展程序将其配置为使用 60万次迭代 – 符合 OWASP 针对 PBKDF2-HMAC-SHA256 的 2023 年建议。由 MetaMask 扩展程序提供 v11.16.11 （已在2024年6月的hashcat版本中得到确认），新创建的保险库采用60万次迭代，而新的 keyMetadata 字段。

这意味着每次密码尝试的计算成本增加了60倍。 在相同的硬件上，原本以10,000次迭代耗时一天的暴力破解，现在以600,000次迭代需耗时两个月。hashcat社区不得不开发定制内核——由cyclone贡献的mode 26620——以应对这种新格式。标准的mode 26600将迭代次数硬编码为10,000次。

需要特别注意的是，旧的保险库并不会自动重新加密。 如果您是在 2021 年创建的钱包，那么您的保险库仍会使用 10,000 次迭代，除非 MetaMask 明确触发了重新加密（该 updateVault 虽然有专门用于此目的的函数，但目前尚不清楚 MetaMask 在解锁时会以何种频率调用它。您可以通过该函数是否存在来判断当前使用的版本。 keyMetadata 字段。否 keyMetadata？是 10,000 次迭代。有 keyMetadata 使用 "iterations": 600000？这是新格式。

以下是与恢复相关的加密库版本完整时间线：

  • browser-passworder v1.x–v2.x （2022年前）：10,000次迭代，硬编码。发布时未包含 @metamask 范围。
  • v3.0.0 （2022年8月）：更名为 @metamask/browser-passworder. 迭代次数未变。
  • v4.2.0 （2023年11月）：已添加 keyMetadata 支持。默认加密迭代次数已更改为 900,000 次。 keyFromPassword 向后兼容至 10,000。
  • v4.3.0 （2023年11月）：已添加 isVaultUpdated 以检查金库是否符合目标参数。
  • v5.0.0（2024年4月）：最低要求 Node.js v16。加密功能无变更。
  • v6.0.0（2024年12月）：最低要求 Node.js v18.18。加密功能无变更。

致数据恢复专家：请务必先确认数据保险库的格式。这将决定您的整个处理方案。

MetaMask 的密码策略及其对暴力破解的影响

MetaMask 要求密码长度至少为 8 个字符。仅此而已。 无需大写字母、数字或特殊字符。该扩展程序会显示一个可视化强度指示器（“弱”/“好”），但不会阻止符合最小长度要求的弱密码。密码长度也没有上限——支持 Unicode 字符。该政策至少自 2018 年初起便已实施（参见 GitHub 问题 #3515）。

一些第三方网站错误地声称MetaMask要求密码必须包含大写字母、小写字母、数字和特殊字符。这种说法是错误的。唯一硬性要求是密码长度必须为8个字符。

对于暴力破解而言，这一点至关重要。一个仅含8个小写字母的密码，其密钥空间大约有2080亿种组合（26^8）。 针对一个仅进行过10,000次迭代的旧保险库，现代GPU上的hashcat每秒可测试数千个哈希值，因此只需几天就能破解。若针对一个进行了600,000次迭代的保险库，所需时间则需乘以60倍。而一个由12个以上字符组成、包含大小写字母和符号的强密码呢？以当前硬件水平来看，无论哪种破解方式，它都几乎是无法攻破的。

首选的实用恢复工具是 btcrecover – MetaMask 官方建议，该功能适合大致记得自己密码的用户。它支持基于代币和基于模式的猜测，允许您定义一个模板，例如 "my" + [dog|cat|bird] + [2019|2020|2021] + ["!"|"@"|"#"] 并高效地测试所有排列组合。对于基于 GPU 加速的攻击，hashcat 的 26600 模式用于处理旧版保险库，26610 模式用于处理移动端保险库，而 26620 模式（或经过重新编译、迭代次数已更新的 26600 模式）则用于处理新的 600,000 次迭代格式。

资金流向与“资金缺口”现象

资金流向正是大多数“我的资金不翼而飞”问题产生的根源。 MetaMask 使用以太坊的 BIP-44 标准路径： m/44'/60'/0'/0. 通过增加最终索引来计算结果： m/44'/60'/0'/0/0 （第一种说法）， m/44'/60'/0'/0/1 （第二）， m/44'/60'/0'/0/2 （第三），以此类推。此路径适用于所有兼容 EVM 的链——在以太坊、Polygon、Arbitrum 和 BSC 上地址均相同。

问题在于，并非所有人都使用相同的路径。 Ledger Live 用途 m/44'/60'/x'/0/0，将 account 字段，而不是 address_index. Ledger Legacy （旧版 MEW/MyCrypto 的路径）使用 m/44'/60'/0'/x – 只有四个级别，而不是五个。第一个地址（m/44'/60'/0'/0/0) 在 MetaMask、Ledger Live 和 Trezor 中是完全相同的。但 第二个账户及之后的账户则完全不同，因为每个钱包都会递增路径中的不同部分。

这会导致一种非常典型的故障现象：用户在 MetaMask 中导入 Ledger 助记词，看到第一个账户及其余额，随后添加第二个账户时却发现……余额为零。资金并没有丢失，它们正存放在由 m/44'/60'/1'/0/0 （类似 Ledger Live 的风格），但 MetaMask 正在考虑 m/44'/60'/0'/0/1. 完全不同的密钥，完全不同的地址。

Trezor 的默认以太坊派生路径 与 MetaMask 的设置一致： m/44'/60'/0'/0/x因此，Trezor 到 MetaMask 的恢复功能通常适用于所有账户。跨钱包的问题主要集中在 Ledger ↔ MetaMask 和 Ledger ↔ Trezor 之间。

若要在“错误”的派生路径上查找资金，您可以采取以下措施：

  • 请通过电子邮件contact@cryptorecovery.io联系我们，我们将尽力为您提供帮助。
  • MyEtherWallet (MEW)：支持通过“添加路径”自定义派生路径。手动输入 m/44'/60'/1'/0/0, m/44'/60'/2'/0/0……等，用于验证类似 Ledger Live 的地址。
  • MyCrypto：支持类似的自定义派生路径。
  • 伊恩·科尔曼（Ian Coleman）的 BIP-39 工具（离线运行）：输入助记词，选择 ETH，在 BIP-44 标签页之间切换，并手动调整路径组件。
  • btcrecover：可对不同派生路径方案进行自动化测试。

一个令人沮丧的限制：MetaMask 的 Trezor 集成不支持自定义派生路径。 虽然针对 Ledger 的自定义派生路径选项已合并（PR #9367），但据最新消息，Trezor 的对应功能（GitHub 问题 #11197）仍处于待解决状态。如果您试图通过 MetaMask + Trezor 访问由 Ledger 派生出的账户，则需要改用 MEW 或 MyCrypto。

MetaMask 与 Trezor：一段波折不断的“婚姻”

MetaMask 与 Trezor 的集成是通过 Trezor Bridge – 一个本地安装的后台进程（trezord) 监听 http://127.0.0.1:21325/ 并弥合了浏览器沙箱与 USB 硬件访问之间的鸿沟。您可以通过点击 http://127.0.0.1:21325/status/.

最常见的故障原因看似简单：Trezor Suite 处于打开状态。Trezor Suite 会锁定与设备的 USB 连接，从而阻止 MetaMask 进行通信。您必须完全退出 Suite——不仅是将其最小化，还要从系统托盘中彻底关闭它。据我估计，这占了我所见“MetaMask 无法找到我的 Trezor”工单的 40%。

其他常见问题及解决方法：

“正在查找您的 Trezor……” 循环显示 – 请确认已安装 Bridge，并且 trezord 正在运行。请尝试更换USB数据线和接口。关闭VPN、防火墙以及浏览器扩展程序（广告拦截器和隐私保护扩展程序经常会造成干扰）。无痕模式可避免扩展程序冲突。

“设备正在连接”– 另一款应用程序或浏览器标签页正在与 Trezor 通信。请关闭所有可能访问该设备的其他标签页和应用程序。

WebUSB 的限制——Firefox 完全不支持 WebUSB，这意味着在 Firefox 上连接 Trezor 完全依赖于 Bridge。Chrome、Brave 和 Edge 则通过 Chromium 的 WebUSB/WebHID 实现来工作。

Trezor Safe 5 派生路径警告——有用户反映，在交易验证过程中，Trezor 屏幕上会显示“所选账户的派生路径错误。m/44’/60’/0’/0”。通常可以安全地忽略此警告——尽管出现该提示，钱包仍能正常运行。这是 Trezor 固件在验证外观非标准的路径时出现的一个界面显示问题。

2025年，Trezor 开始将 Bridge 功能集成到 Trezor Suite 本身中。这一转变引发了一系列连接问题，因为部分用户需要让 Suite 在后台运行才能连接 MetaMask，而另一些用户则需要将其完全关闭。请前往 Trezor Suite → 设置 → 应用程序 → Trezor Connect 查看相关配置。

当 MetaMask 连接到 Trezor 时，由此生成的账户与 MetaMask 的软件钱包账户在根本上有所不同。由 Trezor 生成的账户仅在保险库中存储公钥和派生路径——私钥仍保存在硬件设备上。 即使未连接 Trezor，MetaMask 也能显示余额（通过公钥进行只读操作），但若无实体设备在场则无法签署交易。若在创建 Trezor 账户时使用了密码短语，则必须输入完全相同的密码短语才能重新生成相同的地址。

在实践中真正有效的恢复技巧

经过数百次数据恢复，以下是我最常遇到的情况以及我的处理方法。

情况 1：有密码，但丢失了助记词，且扩展程序仍已安装

这个很简单。通过以下方式打开 MetaMask 的后台页面： chrome://extensions → 开发者模式 → 点击“服务 worker”（MV3）或“后台页面”（MV2）。在控制台中：

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

复制金库 JSON，将其粘贴到 MetaMask 保险库解密工具 (metamask.github.io/vault-decryptor)，输入密码，它就会显示您的助记词以及任何已导入的私钥。Vault Decryptor 由 MetaMask 的联合创始人 Dan Finlay 开发——它还支持 .ldb 直接通过文件上传功能上传文件。

情况 2：已知密码，扩展程序已被卸载，但数据可能仍保存在磁盘上

导航至扩展程序的数据目录。如果该文件夹仍然存在（有时卸载无法彻底清理，或者用户只是禁用了扩展程序而非将其删除），请获取 .ldb 以及 .log 文件。使用 grep、文本编辑器或 btcrecover的 extract-metamask-vaults.py. 使用 Vault Decryptor 进行解密。

如果文件夹不见了，请通过 contact@cryptorecovery.io 联系我们，我们将协助进行磁盘取证分析。

您还可以将该驱动器挂载为只读模式，并对原始磁盘进行搜索，查找保险库字符串模式。在 Linux 系统中： grep -rboa '{"data":"' /dev/sdX. 成功与否在很大程度上取决于删除后磁盘活动的情况，以及该驱动器是固态硬盘（SSD）还是机械硬盘（HDD）。

情况 3：忘记密码，但拥有保险库文件

这是一个暴力破解场景。提取保险库，使用 metamask2hashcat.py 或 cyclone-github/metamask_extractor. 然后运行 hashcat（旧版保险库使用模式 26600，新版使用模式 26620）或 btcrecover，并提供一个记录了您对密码记忆的提示文件。如果您知道自己的密码类似于“myDog”加上年份再加一个符号，btcrecover 可以高效地测试这些组合。

场景 4：Firefox 恢复

在以下位置查找 MetaMask UUID： about:debugging. 导航至存储目录。使用 snappy-fox:

./snappy-fox input_file.snappy output.txt

在解压后的输出中查找 Vault JSON 文件。然后继续使用 Vault Decryptor。该 JesseBusman/FirefoxMetamaskWalletSeedRecovery Python 脚本可自动完成整个过程——它会扫描 Firefox 配置文件，查找保险库数据，并输出经过格式化的 JSON 数据，以便进行解密。

场景 5：导入种子后资金显示缺失

检查派生路径。如果将 Ledger 的种子短语导入 MetaMask，从第二个账户开始，显示的地址将不同且余额为零。请使用 MEW 或 MyCrypto 并设置自定义派生路径，以便在 Ledger Live 中查找资金（m/44'/60'/x'/0/0) 或 Ledger Legacy (m/44'/60'/0'/x) 路径。如果涉及 Trezor 密码短语，请确保输入的密码短语完全一致——不同的密码短语会从相同的种子生成完全不同的地址集。

法证工具箱中值得备有的工具

  • MetaMask 保险库解密工具 – 官方版本，支持离线运行，支持直接处理 .ldb 文件上传
  • btcrecover– 支持模式匹配的密码恢复工具，MetaMask 推荐
  • hashcat– GPU加速的暴力破解（模式 26600、26610、26620）
  • snappy-fox– Firefox Snappy 解压
  • CCL Solutions Group 的 Python 工具——纯 Python 实现的 LevelDB 解析、Snappy 解压、V8 反序列化

结论：成功复苏与失败复苏的区别

能否找回钱包，还是永远失去它，几乎总是取决于发现问题后的最初几分钟内发生了什么。最具破坏性的行为莫过于在同一浏览器配置文件中重新安装 MetaMask——这会用新文件覆盖 LevelDB 目录。其次最具破坏性的行为是在删除金库后继续在 SSD 上正常使用电脑，这会触发 TRIM 机制，导致无法进行扇区级别的数据恢复。

如果你从本指南中只能记住三点：将助记词备份在纸上；明白你的钱包存储在特定的文件夹中，你可以将其复制并妥善保存；如果出现问题，在尝试任何恢复操作之前，请立即停止使用该电脑。 加密机制非常牢固——采用 AES-256-GCM 算法并经过 600,000 次 PBKDF2 迭代，除非密码过于简单，否则无法被暴力破解——但数据本身却意外地脆弱。它仅仅是 LevelDB 数据库中区区几千字节的数据，只需点击一次浏览器清理按钮，它就会消失无踪。

我未能恢复的每一个钱包，其根本原因都是一样的：用户在数据丢失后仍继续使用该设备。而我成功恢复的每一个钱包，其数据都仍保存在磁盘上——有时出现在意想不到的地方，有时则因 LevelDB 的“仅追加”架构而存在多份副本，但归根结底，都是因为有人在采取行动前停下来仔细思考了一番。

如果您需要恢复 MetaMask 钱包的帮助，请通过电子邮件联系我们： contact@cryptorecovery.io 获取专业、免费的咨询服务，或访问我们的联系页面