CryptoRecovery.io – ウォレット復旧サービス

お問い合わせ

MetaMaskウォレットを復元する方法：パスワード紛失、Vaultストレージ、暗号化、およびデータフォレンジック

ピーター・クリプトリカバリーのアバター
ピーター・クリプトリカバリー
MetaMaskウォレットを復元する方法：パスワード紛失、Vaultストレージ、暗号化、およびデータフォレンジック

MetaMaskウォレットを復元する方法：パスワード紛失、Vaultストレージ、暗号化、およびデータフォレンジック

これを読んでいるということは、おそらくMetaMaskウォレットにアクセスできなくなり、手詰まりの状態なのではないでしょうか。私は長年にわたり、ノートパソコンを初期化してしまったDeFiトレーダーから、ブラウザの拡張機能を「整理」してしまったご高齢の方まで、多くの人々のウォレット復旧を支援してきました。このガイドでは、MetaMaskが鍵をどのように保存しているか、そのデータがディスク上のどこに実際に存在するか、そして問題が発生した際にどう取り戻すかについて、私が知っていることをすべて解説します。これらはすべて理論上の話ではありません。ここで紹介する手法はすべて、実際の復旧事例に基づいています。

MetaMaskは実際にどのように鍵を保存しているのか

何かを復元する前に、何を復元するのかを理解しておく必要があります。MetaMaskは、 private_keys.txt. それらを、 金庫これは、ブラウザの拡張機能ストレージ内に保存されています。

MetaMaskウォレットを作成してパスワードを設定すると、内部では次のような処理が行われます。MetaMaskはBIP-39準拠のニーモニック（12語の 秘密の復元フレーズ) を、インポートされた秘密鍵とともに「keyring」オブジェクトのJSON配列にまとめます。その配列は文字列にシリアライズされ、その後、 AES-256-GCM パスワードから導出された鍵を使用して PBKDF2-HMAC-SHA256その結果、3つまたは4つのフィールドを持つJSONデータが生成され、それが chrome.storage.local （Chromium系ブラウザでは）またはIndexedDB（Firefoxでは）。

以前のバージョンでは、暗号化された保管庫は次のような見た目になっています：

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

また、新しいバージョン（v11.16.x以降）では、4つ目のフィールドが追加されています：

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

それ keyMetadata この点が、数分で完了する復旧と数週間かかる復旧との違いとなります。これについては後ほど詳しく説明します。

暗号化の処理の流れは単純ですが、正確に理解しておくことが重要です。UTF-8形式のパスワードは、Web Crypto APIを介して生のPBKDF2キーとして読み込まれます。A 32バイトのランダムなソルト （以下から生成） crypto.getRandomValues()) をパスワードと組み合わせて、256ビットのAES-GCM鍵を導出します。その後、 16バイトのランダムなIV シリアライズされたキーリングデータを暗号化します。 data このフィールドには、暗号文とGCM認証タグの両方がBase64エンコードされた形で含まれています。注目すべき点として、MetaMaskは AES-GCM用の16バイトのIVこれは非標準的な仕様です――NIST SP 800-38Dでは12バイトが推奨されています。このため、一部の暗号ライブラリとの相互運用性に問題が生じます（例えば、RubyのOpenSSLではこれに対応できず、動作しません）。

パスワードでMetaMaskのロックを解除すると、そのプロセスが逆になります。 KeyringController 永続ストレージから暗号化されたVault文字列を取得し、それを browser-passworderの decrypt この関数は、JSONを解析し、ソルトを抽出し、同じパラメータを使用してPBKDF2で鍵を生成し、AES-GCMで復号し、その結果をキーリングオブジェクトとしてシリアライズ解除します。復号されたキーリングは 記憶の中だけで – それらは memStore (ある ObservableStore （例）であり、平文でディスクに書き込まれることは決してありません。

復号されたVaultには、通常次のような配列が含まれています：

[
  {
    "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年から導入を進めているサービスワーカーアーキテクチャ）の登場に伴い、MetaMaskは暗号化キーをエクスポートされたJWKとしてキャッシュする機能を追加しました。これにより、サービスワーカーが再起動した際にも、再度パスワードの入力を求められずにVaultを復号できるようになりました。 encryptionKey そして encryptionSalt フィールドは memStore いつ cacheEncryptionKey が有効になっています。

各プラットフォームでMetaMaskがデータをどこに保存しているか

金庫を見つけることが、成功への第一歩です。MetaMaskは、ブラウザやオペレーティングシステムによってデータを保存する場所が異なり、この違いは復旧作業において重要な意味を持ちます。

Chromiumベースのブラウザ（Chrome、Brave、Edge）

Chromiumベースのブラウザでは、 chrome.storage.local …に保存される LevelDBデータベース ディスク上に。拡張子IDによってフォルダ名が決定されます。

Chromeの拡張機能ID は nkbihfbeogaeaoehlefnkodbefgpgknn – すべての回復支援専門家の記憶に深く刻まれている。 勇敢 Chrome ウェブストアからインストールされるため、同じ ID を使用します。 エッジ Edge アドオン ストアからインストールした場合、独自の ID が割り当てられます： ejbalbakoplchlghecdalmeeeajnimhm。しかし、ユーザーがChrome Web Store（Edgeでも利用可能）経由でEdgeにMetaMaskをインストールした場合、ChromeのIDが引き継がれます。この違いに、多くの人が常に戸惑っています。

完全なパスは以下の通りです：

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を使用しません。拡張機能のデータは IndexedDBFirefoxが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の復旧作業における最もよくある間違いです。多くの人がバイナリファイルを開き、判読可能なテキストの断片が混ざった文字化けしたデータを見て、Vaultが破損していると誤解してしまいます。しかし、そうではありません。単に圧縮されているだけです。

Firefox 63 以前では、拡張機能のストレージには storage.js プロファイルディレクトリ内。かなり古いインストールを復元する場合は、 storage.js または storage.js.migrated.

LevelDBと、誰もが気にする0001.ldbファイル

LevelDBはGoogleが開発したキーバリュー型ストレージエンジンであり、ChromiumベースのブラウザでMetaMaskを復元するには、そのファイル構造を理解することが不可欠です。

MetaMaskのLevelDBディレクトリには、いくつかの種類のファイルが含まれています。その .ldb ファイル （ソート済み文字列テーブル、またはSSTable）は、永続的なソート済みキーバリュー型ストレージです。 .log ファイル これらは、Write-Ahead Log（WAL）です。これは、書き込みがディスクにフラッシュされる前の、直近の書き込みを一時的に保持するバッファです。 .ldb ファイル。そこには MANIFEST-###### ファイル追跡データベースのメタデータ、 CURRENT アクティブなマニフェストを指すファイル、および LOCK ファイルへの同時アクセスを防止する。

通常、Vaultのデータは 番号の小さい .ldb ファイル - 000003.ldb, 000005.ldb、またはそれに類するもの。MetaMaskの公式ドキュメントには、「数値は小さいものであるべきです。大きな数値の場合は、Vaultではありません」と記載されています。 0001.ldb ファイル（または 000001.ldb) は、MetaMaskの初回初期化時に作成される最も初期のSSTableの一つです。多くの場合、ウォレット作成時に書き込まれた元のVaultが含まれています。

からVaultデータを抽出する .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ファイルを使用してVaultを復元できない場合は、.logファイルが存在するかどうかを確認してください。」

LevelDBの回復処理において非常に役立つ特性：それは 追記専用. 更新や削除は既存のレコードを変更するものではなく、より大きなシーケンス番号を持つ新しいエントリを追加するものです。古いレコードは、コンパクションによって統合されるまで残ります。つまり、誰かが古いSRPの上に新しいSRPをインポートした場合でも、古いVaultデータは以前の .ldb まだ圧縮されていないファイルです。私はこの方法で、「上書きされた」ウォレットを何度も復元してきました。

プログラムによる抽出については、 btcrecover 本プロジェクトには以下が含まれます extract-metamask-vaults.pyこれは、LevelDBデータベースを適切に読み込み、未圧縮ファイルの中に隠れている可能性のある古いエントリも含め、すべてのVaultエントリを取得します。 cyclone-github/metamask_extractor このツールも同じ機能を持ち、hashcat互換形式で直接出力することができます。

Vaultファイルが破損した場合

Vaultの破損は、通常、以下のいくつかの原因のいずれかに起因します。書き込み操作中のブラウザのクラッシュ（停電、カーネルパニック、強制終了）、処理の途中でストレージの書き換えを行うMetaMaskの更新が中断された場合、実際のディスクエラー（不良セクタ、SSDの摩耗）、あるいは近年増加傾向にある、ウイルス対策ソフトによるMetaMaskのJavaScriptファイルの隔離などです。後者の場合、Vaultのデータ自体は無傷であっても、LevelDBデータベースが不整合な状態になってしまうことがあります。

JSONがパースできない場合は、Vaultが破損していることがわかります。中括弧の欠落、Base64文字列の切り詰め、データフィールドの途中にヌルバイトが混入しているなどです。MetaMask Vault Decryptorでは、「Vaultのデコードに問題が発生しました」というエラーが表示されるか、あるいは何のメッセージも表示されずに処理が失敗します。

復旧の可否は、破損の種類と程度によって異なります。JSON構造が破損していても、暗号化されたデータがほぼ無傷であれば、多くの場合 手動でボールトを再構築する。形式は厳格で、正確に data, iv、および salt フィールド（および keyMetadata （新しいVaultの場合）。ヌルバイトと制御文字を除去します。 data, iv、および salt 値は有効なBase64エンコードです。もし data フィールドが切り詰められてしまうと、困ったことになります―― AES-GCMでは、完全な暗号文が必要です さらに、その認証タグ（の最後の16バイト） data （フィールド）を復号化する必要があります。たった1バイトでも欠けると、全体が失敗してしまいます。

一部が破損したLevelDBデータベースにおいて、 .ldb ファイル自体が破損している場合は、 .log 代わりにファイルを使用してください。この形式はより単純（7バイトのヘッダーを持つ32KBの連続ブロック）であり、破損の事態を免れた、より新しいバージョンのVaultが含まれている可能性があります。 どちらの方法も効果がない場合、PythonのLevelDB解析ライブラリ（CCL Solutions Groupは、LevelDBの解析、Snappyの解凍、V8のデシリアライゼーションの純粋なPython実装を公開しています）を使用して、破損したブロックをスキップしながら、破損したデータベースファイルからレコードをピンポイントで抽出できる場合があります。

1つのLevelDBディレクトリ内に複数のSRPを共存させることができます。ユーザーが新しいシードフレーズをインポートした場合、古いVaultエントリは別の .ldb ファイル内、あるいは同じファイル内の別のオフセット位置でも検索します。常に すべてのインスタンス 「ヴォールト」パターンのうち、最初のものだけではなく。

ファイルの上書き問題とその対処法

これは、最も悲劇的な事態を招くシナリオです。誰かがMetaMaskをアンインストールしてしまうのです――トラブルシューティングをしていたのかもしれませんし、ブラウザの「整理」をしていたのかもしれませんし、あるいは自分が何をしているのか気づかなかったのかもしれません。Chromiumベースのブラウザでは、拡張機能をアンインストールすると 拡張データフォルダ全体を削除します、すべてを含めて .ldb, .log、およびmanifestファイル。Firefoxでは、 moz-extension+++<UUID> フォルダが削除され、再インストールを行うたびに新しいUUIDが生成されるため、新しいインストールでは以前の場所には影響しません（ただし、以前の場所は存在しなくなります）。

MetaMaskの公式ドキュメントでは、この点について率直に次のように説明されています。「ブラウザ拡張機能をアンインストールすると、そのデータは削除されます。一般的に、これはVaultのデータが失われることを意味します。」

「一般的に」という言葉には、多くの意味が込められています。データは論理的には削除されます――ファイルシステムがそれらのセクタを空き領域としてマークする――ものの、実際のバイトはすぐにはゼロで上書きされません。従来のHDDでは、それらのセクタが新しいファイルによって再利用されるまで、データは残ったままになります。一方、SSDでは、TRIMコマンドによって、削除されたデータを数分、場合によっては数秒以内に復元不可能な状態にすることができます。

上書きされた保管庫を復元する際の第一のルールは、直ちにそのコンピュータの使用を中止することです。ドライブに新しいファイルが書き込まれるたびに、保管庫がかつて存在していたセクタが上書きされてしまう可能性があります。可能であれば、ドライブを取り外し、別のマシンで読み取り専用としてマウントしてください。

この状況で私が真っ先に使う回復ツールは、以下の順です：

  • 論理的に削除されたファイルを復元するための当社開発のカスタムソフトウェア（クロスプラットフォーム）
  • Linuxのext3/ext4ファイルシステム向け「extundelete」または「ext4magic」
  • ディスクの未処理データ検索 最終手段として： grep -rboa "vault" /dev/sdX ディスクデバイスからVault文字列をスキャンする
  • 当社特注の工具 ファイルシステムのメタデータが失われた場合のファイルカービング用 – 検索対象を次のように設定してください {"data":" パターン

数週間前にアンインストールされたドライブから、HDDであればVaultを復元できたことがあります。しかしSSDの場合、数時間使い続けるだけで成功率は劇的に低下します。MetaMaskを再インストールするのは最悪の選択です。なぜなら、まったく同じディレクトリに新しいLevelDBデータベースが作成され、古いセクターが上書きされてしまう可能性があるからです。

この点において、Firefoxには1つ利点があります。インストールごとに新しいUUIDが割り当てられるため、再インストールを行うと、ファイルは新しいディレクトリパスに作成されます。以前の moz-extension+++<OLD-UUID> たとえそのフォルダが削除されたとしても、データは新しいインストール先のファイルによって上書きされることはありません。また、Firefoxには2つの隠し設定があり―― 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権限が必要です。Vaultの暗号化には、デスクトップ拡張機能と同じPBKDF2による鍵生成方式が採用されていますが、重要な違いがあります。モバイルアプリは従来、 5,000回のPBKDF2反復 そして、以下で暗号化します AES-CBC AES-GCMの代わりに。つまり、パスワードが同じであっても、モバイル用金庫とデスクトップ用金庫は互換性がありません。

iOSでは, データはアプリのサンドボックス内の <AppSandbox>/Documents/iCloudバックアップの復元については、関連するパスは Apps → MetaMask → Documents → persistStore → persist-root – MacでiOSのバックアップを閲覧するには、iMazingのようなツールが必要です。この方法が機能するかどうかは、MetaMaskが稼働中にユーザーがiCloudバックアップを有効にしていたかどうかに依存します。また、Apple側の変更により、この手法が時折機能しなくなっているとの報告もあります。

MetaMaskモバイル版では、さらに SecureKeychain モジュール（以下に構築された） react-native-keychain) これは、生体認証によるロック解除のために、ユーザーのウォレットパスワードをiOSのキーチェーンまたはAndroidのキーストアに保存するものです。セキュリティ監査の結果、SecureKeychainが「foxCode」というソルトを使用して追加の暗号化レイヤーを追加していることが判明しましたが、このソルトはハードコードされた文字列であることがわかりました "encrypt". MetaMaskのチームは、これはセキュリティ上極めて重要な秘密というよりは、多層防御の一環であると認めた。

モバイル端末の復旧における根本的な課題は、 手動での金庫の取り出し機能はありません ～を見つけることに相当する .ldb デスクトップ上のファイル。iPhoneにSSH接続して、Vaultの文字列をgrepで検索することはできません。 MetaMask モバイル版 v6.3.0このアプリには、データの破損が検出された際に自動的に起動する「ボールト復元」機能が搭載されていますが、アプリを削除してしまうと、デバイスのバックアップがない限り、ローカルのボールトデータは失われてしまいます。Androidのバックアップ機能は、アプリ内部のデータをすべて保存するという点において、特に信頼性が低いのです。 MetaMaskの公式見解 AndroidのVault復元機能に頼るのではなく、資産を新しいSRPに移行することを推奨します。

すべての復旧ツールを機能しなくしてしまったPBKDF2の反復回数の変更

長年にわたり、MetaMaskは PBKDF2を10,000回反復 – のハードコードされたデフォルト値 browser-passworder ライブラリ。あらゆる復旧ツール、あらゆるhashcatモジュール、あらゆるブルートフォーススクリプトは、10,000回の反復処理に合わせて調整されていた。しかし、2023年末から2024年初頭にかけて、状況は一変した。

その @metamask/browser-passworder ライブラリ v4.2.0（2023年11月13日リリース）では、設定可能な鍵導出オプションのサポートが追加されました。ライブラリの新しいデフォルト値は 90万回の反復ですが、MetaMaskの拡張機能では、それを次のように設定していました 60万回の反復 – OWASPの2023年推奨事項であるPBKDF2-HMAC-SHA256に準拠しています。MetaMask拡張機能による v11.16.11 （2024年6月のhashcatのリリースで確認されたように）、60万回の反復処理で新しいVaultが生成されており、新しい keyMetadata フィールド。

これは、パスワード1回あたりの計算コストが60倍になったことを意味します。 同じハードウェア上で、1万回の反復処理で1日かかっていたブルートフォース攻撃が、60万回の反復処理では2ヶ月かかるようになりました。hashcatコミュニティは、この新しい形式に対応するために、cyclone氏によって提供されたカスタムカーネル「モード26620」を開発する必要がありました。標準のモード26600には、1万回の反復処理がハードコードされていました。

重要な点として、古い保管庫は自動的に再暗号化されることはありません。 2021年にウォレットを作成した場合、MetaMaskが明示的に再暗号化を実行しない限り、Vaultでは依然として10,000回の反復処理が使用されます（ updateVault この目的のための関数は存在しますが、MetaMaskがロック解除時にこれをどの程度積極的に呼び出しているかは不明です）。使用しているバージョンがどれかは、 keyMetadata フィールド。いいえ keyMetadata？ 1万回の反復です。 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 サポート。デフォルトの暗号化反復回数が90万回に変更されました。 keyFromPassword 10,000で下位互換性を確保。
  • v4.3.0 （2023年11月）：追加 isVaultUpdated Vaultが目標パラメータを満たしているかを確認するため。
  • v5.0.0(2024年4月): 最低要件がNode.js v16に変更されました。暗号関連の変更はありません。
  • v6.0.0(2024年12月): 最低要件は Node.js v18.18 です。暗号関連の変更はありません。

復旧の専門家の方へ：まず必ずストレージのフォーマットを確認してください。それによって、復旧作業の進め方が決まります。

MetaMaskのパスワードポリシーと、それがブルートフォース攻撃に与える影響

MetaMaskでは、パスワードの最小文字数は8文字と定められています。それだけです。 大文字の使用義務も、数字や特殊文字の指定もありません。拡張機能には強度の目視インジケーター（「弱」／「強」）が表示されますが、最低文字数を満たしている限り、強度の低いパスワードでも使用をブロックすることはありません。最大文字数も設定されておらず、Unicode文字もサポートされています。このポリシーは少なくとも2018年初頭から適用されています（GitHubのIssue #3515を参照）。

いくつかのサードパーティのサイトでは、MetaMaskのパスワードに大文字、小文字、数字、特殊文字が必要だと誤って記載されています。これは間違いです。唯一の必須条件は、8文字であることです。

総当たり攻撃による復旧においては、これは極めて重要な要素となります。小文字のみの8文字のパスワードの場合、鍵空間は約2080億通り（26^8）になります。 10,000回の反復処理が行われた古いパスワード管理ツールに対して、最新のGPUを搭載したhashcatを使用すれば、1秒あたり数千のハッシュをテストできるため、数日で解読可能です。60万回の反復処理が行われたパスワード管理ツールに対しては、その時間を60倍に換算してください。大文字と小文字、記号を組み合わせた12文字以上の強力なパスワードであれば、現在のハードウェアではどちらの形式に対しても事実上解読不可能です。

実用的な復旧ツールとして最適なのは btcrecover – MetaMask 自身も、パスワードのヒントがだいたい分かっているユーザーにはこの方法をおすすめしています。トークンベースやパターンベースの推測に対応しており、次のようなテンプレートを定義することができます。 "my" + [dog|cat|bird] + [2019|2020|2021] + ["!"|"@"|"#"] そして、すべての組み合わせを効率的にテストします。GPU加速攻撃の場合、hashcatのモード26600は旧式のVaultに対応し、モード26610はモバイル版Vaultに対応し、モード26620（または反復回数を更新して再コンパイルした26600）は、新しい60万反復形式に対応しています。

資金の流れと「資金不足」の蔓延

「資金が消えた」という問題の多くは、この出金経路に起因しています。 MetaMask イーサリアム向けのBIP-44標準パスを使用します： m/44'/60'/0'/0. アカウントは、最終インデックスに1を加えることで算出されます： m/44'/60'/0'/0/0 （最初の記述）、 m/44'/60'/0'/0/1 (第二に)、 m/44'/60'/0'/0/2 （3番目）、以下同様です。この手順は、すべてのEVM互換チェーンに適用されます。イーサリアム、Polygon、Arbitrum、BSCでは、アドレスは同じです。

問題は、誰もが同じパスを使っているわけではないということです。 Ledger Live 用途 m/44'/60'/x'/0/0、をインクリメントして account の代わりに address_index. レジャー・レガシー （旧MEW/MyCryptoパス）では m/44'/60'/0'/x – レベルは5つではなく4つだけ。最初のアドレス（m/44'/60'/0'/0/0)は、MetaMask、Ledger Live、Trezorのいずれでも同じです。しかし、 2つ目のアカウント以降は、それ以降のものとは全く異なる…というのも、各ウォレットがパスの異なる要素をインクリメントするからです。

これにより、非常に特徴的な不具合が発生します。具体的には、ユーザーがMetaMaskでLedgerのシードフレーズを復元し、最初のアカウントとその残高を確認した後、2つ目のアカウントを追加すると……残高がゼロになっているのです。資金が消えたわけではありません。それらは、 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：同様のカスタム導出パスのサポート。
  • イアン・コールマンのBIP-39ツール（オフラインで実行）：ニーモニックを入力し、ETHを選択し、BIP-44タブを切り替え、パス構成要素を手動で調整します。
  • btcrecover: さまざまな派生パス構成にわたるテストを自動化できます。

残念な制限点として、MetaMaskのTrezor連携機能ではカスタム導出パスがサポートされていません。 Ledger向けのカスタムデリベーションパスオプションはマージ済み（PR #9367）ですが、最新の情報によると、Trezor向けの同等の機能（GitHub issue #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本体に統合し始めました。この変更に伴い、MetaMaskに接続する際にSuiteをバックグラウンドで実行する必要があるユーザーもいれば、完全に終了させる必要があるユーザーもいたため、接続に関する問題が相次ぎました。設定については、Trezor Suite → 設定 → アプリケーション → Trezor Connect をご確認ください。

MetaMaskがTrezorに接続すると、作成されるアカウントはMetaMaskのソフトウェアウォレットのアカウントとは根本的に異なります。Trezorから派生したアカウントは、Vault内に公開鍵と導出パスしか保存せず、秘密鍵はハードウェアデバイス上に残ります。 MetaMaskはTrezorが接続されていなくても残高を表示できます（公開鍵による読み取り専用）が、物理的なデバイスが手元にない限り、トランザクションに署名することはできません。Trezorアカウントの作成時にパスフレーズが使用されていた場合、同じアドレスを再生成するには、そのパスフレーズと全く同じものを入力する必要があります。

実際に効果のある回復法

何百件もの復旧作業を経て、私が最も頻繁に遭遇する状況と、その対処法をご紹介します。

ケース1：パスワードは持っているが、シードフレーズを紛失し、拡張機能はインストールされたまま

これは簡単です。MetaMaskのバックグラウンドページを以下から開いてください chrome://extensions → 開発者モード → 「サービスワーカー」（MV3）または「バックグラウンドページ」（MV2）をクリックします。コンソールで：

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

VaultのJSONをコピーし、それを MetaMask Vault 復号ツール (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 までご連絡ください。ディスクフォレンジックの調査をお手伝いいたします。

また、ドライブを読み取り専用としてマウントし、Vault文字列のパターンに対してRAWディスク検索を行うこともできます。Linuxの場合： grep -rboa '{"data":"' /dev/sdX. 成功するかどうかは、削除後にどれだけのディスクアクセスがあったか、またドライブがSSDかHDDかによって大きく左右されます。

シナリオ 3：パスワードを忘れたが、Vault ファイルは手元にある

これはブルートフォース攻撃のシナリオです。Vaultファイルを抽出し、以下のコマンドを使用してhashcat形式に変換します metamask2hashcat.py または cyclone-github/metamask_extractor. 次に、パスワードについて覚えている情報を記述したトークンファイルを使用して、hashcat（旧バージョンのVaultの場合はモード26600、新バージョンの場合は26620）またはbtcrecoverを実行します。パスワードが「myDog」に年と記号を組み合わせたようなものだったと分かっている場合、btcrecoverを使えば、それらの組み合わせを効率的に試すことができます。

シナリオ4：Firefoxの復旧

MetaMaskのUUIDは、以下の場所で確認できます about:debugging. ストレージディレクトリに移動します。IndexedDBのバイナリファイルを snappy-fox:

./snappy-fox input_file.snappy output.txt

解凍された出力ファイルの中からVault JSONを探してください。その後、Vault Decryptorを実行してください。 JesseBusman/FirefoxMetamaskWalletSeedRecovery このPythonスクリプトは、このプロセス全体を自動化します。FirefoxのプロファイルをスキャンしてVaultデータを見つけ出し、復号化可能な形式のJSONデータとして出力します。

シナリオ 5：シードのインポート後に資金が不足しているように見える

派生パスを確認してください。LedgerのシードをMetaMaskにインポートする場合、2つ目のアカウント以降は異なるアドレスが表示され、残高がゼロになります。Ledger Liveで資金を確認するには、MEWまたはMyCryptoを使用し、カスタム派生パスを設定してください（m/44'/60'/x'/0/0) または Ledger Legacy (m/44'/60'/0'/x) パス。Trezorのパスフレーズを使用する場合は、必ず全く同じパスフレーズを入力してください。パスフレーズが異なると、同じシードから生成されるアドレスのセットも全く異なるものになります。

ツールキットに入れておきたいフォレンジックツール

  • MetaMask Vault 復号ツール – 公式版、オフラインでも動作可能、ダイレクト対応 .ldb ファイルのアップロード
  • btcrecover– パターンマッチングによるパスワード復元、MetaMask推奨
  • hashcat– GPU加速による総当り攻撃（モード 26600、26610、26620）
  • snappy-fox– Firefox用Snappy解凍ツール
  • CCL Solutions GroupのPythonツール– 純粋なPythonによるLevelDBの解析、Snappyの解凍、V8のデシリアライズ

結論：回復の成功と失敗を分けるもの

財布を取り戻せるか、それとも永久に失うかの分かれ目は、ほとんどの場合、問題に気づいてからの最初の数分間に何をしたかによって決まります。最も致命的な行動は、同じブラウザプロファイルにMetaMaskを再インストールすることです。これにより、LevelDBディレクトリが新しいファイルで上書きされてしまいます。次に致命的なのは、Vaultを削除した後もSSDを通常通り使い続けることです。これによりTRIMがトリガーされ、セクタレベルでの復元が不可能になってしまいます。

このガイドから3つのことを覚えておいてください。シードフレーズを紙に書き留めてバックアップすること、保管庫が特定のフォルダ内にあり、そのフォルダをコピーして保存できることを理解すること、そして何か問題が発生した場合は、復旧を試みる前に直ちにそのコンピュータの使用を中止することです。 暗号化は堅牢です。AES-256-GCMに60万回のPBKDF2反復処理を施しているため、パスワードが脆弱でない限りブルートフォース攻撃で破られることはありません。しかし、データ自体は驚くほど脆弱です。LevelDBデータベース内のわずか数キロバイトのデータに過ぎず、ブラウザのクリーンアップを1回クリックするだけで消えてしまう可能性があります。

私が復旧できなかったウォレットには、すべて同じ根本的な原因がありました。それは、データが失われた後もユーザーがそのマシンを使い続けていたことです。一方、私が復旧に成功したウォレットは、すべてデータがディスク上に残っていたケースでした。時には意外な場所にあったり、LevelDBの追記専用アーキテクチャのおかげで複数のコピーが存在していたりしましたが、いずれの場合も、ユーザーが行動する前に一旦立ち止まって考えたからこそ、復旧できたのです。

Metamaskウォレットの復旧についてサポートが必要な場合は、メールにてお問い合わせください： contact@cryptorecovery.io 専門的な無料相談をご希望の場合は、メールでお問い合わせいただくか、お問い合わせページをご覧ください