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’s decrypt この関数は、JSONを解析し、ソルトを抽出し、同じパラメータを使用してPBKDF2でキーを生成し、AES-GCMで復号し、その結果を再びキーリングオブジェクトとしてシリアル化解除します。復号されたキーリングは 記憶の中だけで – それらは memStore (an 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（2023年からChromeが導入を進めているサービスワーカーアーキテクチャ）の登場に伴い、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を使用していません。拡張機能のデータは 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 Vaultのデータが抽出可能になる前に。これは、私が目にするFirefoxの復旧作業における最もよくある間違いです。多くの人がバイナリファイルを開き、判読できないデータと認識できるテキストの断片が混在しているのを見て、Vaultが破損していると誤解してしまいます。しかし、そうではありません。単に圧縮されているだけです。
Firefox 63 以前では、拡張機能のストレージには、 storage.js profile ディレクトリ内です。かなり古いインストールを復元する場合は、 storage.js または storage.js.migrated.
LevelDBと、誰もが質問する「0001.ldb」ファイルについて
LevelDBはGoogleが開発したキーバリュー型ストレージエンジンであり、ChromiumベースのブラウザでMetaMaskを復元するには、そのファイル構造を理解することが不可欠です。
MetaMaskのLevelDBディレクトリには、いくつかの種類のファイルが含まれています。その .ldb ファイル （ソート済み文字列テーブル、またはSSTable）は、永続的なソート済みキー・バリュー型ストレージです。 .log ファイル これらは「Write-Ahead Log」であり、直近の書き込みがフラッシュされる前に一時的に保存されるバッファです。 .ldb ファイル。そこには MANIFEST-###### ファイル追跡データベースのメタデータ、a CURRENT アクティブなマニフェストを指すファイル、および LOCK ファイルへの同時アクセスを防止する。
Vaultのデータは通常、 番号の小さい .ldb ファイル – 000003.ldb, 000005.ldb、など。MetaMaskの公式ドキュメントには、「数値は小さいものであるべきです。大きな数値の場合は、Vaultではありません」と記載されています。その 0001.ldb ファイル（または 000001.ldb) は、MetaMask が最初に初期化された際に作成された最も初期の SSTable の 1 つです。多くの場合、ウォレット作成時に書き込まれた元のヴォールトが含まれています。
からVaultデータを抽出する .ldb ファイル Chromium では通常、手順は簡単です。テキストエディタ（Sublime Text、VS Code、あるいは Notepad++ など）でファイルを開き、次の文字列を検索します。 vault. 暗号化されたJSONブロブは、LevelDBのレコード構造内に埋め込まれています。以下の部分からすべてをコピーしてください。 {"data":" 決算期まで "} – それがあなたの金庫です。
Mac や Linux では、この 1 行のコマンドで解決できます：
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の公式ドキュメントでは、この点について率直に次のように説明されています。「ブラウザ拡張機能をアンインストールすると、その拡張機能のデータは削除されます。一般的に、これはヴォールトのデータが失われることを意味します。」
この「一般的に」という言葉には、大きな意味が込められています。データは論理的には削除されます（ファイルシステムがそれらのセクタを空き領域としてマークします）が、実際のバイトはすぐにはゼロに上書きされません。従来の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 in 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は 10,000回のPBKDF2反復 – のハードコーディングされたデフォルト値 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万回の反復処理で新しいボールトが生成されており、新しい keyMetadata フィールド。
これは、パスワードの試行1回あたりの計算コストが60倍になったことを意味します。 同じハードウェア上で、10,000回の反復で1日かかっていたブルートフォース攻撃が、600,000回の反復では2ヶ月かかるようになりました。hashcatコミュニティは、この新しい形式に対応するために、cyclone氏によって提供されたカスタムカーネル「モード26620」を開発する必要がありました。標準のモード26600には、10,000回の反復がハードコードされていました。
重要な点として、古い保管庫は自動的に再暗号化されるわけではありません。 2021年にウォレットを作成した場合、MetaMaskが明示的に再暗号化を実行しない限り、Vaultでは依然として10,000回の反復処理が使用されます（ 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回に変更されました。keyFromPassword10,000で下位互換性を確保。 - v4.3.0 （2023年11月）：追加
isVaultUpdatedVaultが目標パラメータを満たしているかどうかを確認するため。 - 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文字の小文字のみのパスワードの場合、キー空間は約2,080億通り（26^8）になります。 反復回数が1万回に設定された古いパスワード管理ツールに対して、最新のGPUを搭載したhashcatを使用すれば、1秒あたり数千のハッシュをテストできるため、数日で解読されてしまいます。反復回数が60万回に設定されたパスワード管理ツールに対しては、その時間を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. アカウントは、最終インデックスに1を加えることで算出されます： m/44'/60'/0'/0/0 （最初の記述）、 m/44'/60'/0'/0/1 (第二に)、 m/44'/60'/0'/0/2 （3番目）、以下同様。この手順は、すべてのEVM互換チェーンに適用されます。イーサリアム、ポリゴン、アービトラム、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: さまざまな派生パス方式にわたるテストを自動化できます。
1つ残念な制限として、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本体に統合し始めました。この移行に伴い、MetaMaskに接続する際にSuiteをバックグラウンドで実行する必要があるユーザーもいれば、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’s 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 専門的な無料相談をご希望の場合は、メールでお問い合わせいただくか、お問い合わせページをご覧ください。
