Wie lässt sich eine MetaMask-Wallet wiederherstellen? Verlorenes Passwort, Vault-Speicher, Verschlüsselung und Datenforensik

Wenn Sie dies lesen, haben Sie wahrscheinlich den Zugriff auf eine MetaMask-Wallet verloren und wissen nicht mehr weiter. Ich habe jahrelang Wallets für andere Leute wiederhergestellt – von DeFi-Händlern, die ihre Laptops neu formatiert haben, bis hin zu Großeltern, die ihre Browser-Erweiterungen „aufgeräumt“ haben. Dieser Leitfaden deckt alles ab, was ich darüber weiß, wie MetaMask deine Schlüssel speichert, wo diese Daten tatsächlich auf der Festplatte liegen und wie du sie zurückbekommst, wenn etwas schiefgeht. Nichts davon ist Theorie. Jede hier beschriebene Technik stammt aus echten Wiederherstellungsfällen.

Wie MetaMask Ihre Schlüssel tatsächlich speichert

Bevor Sie irgendetwas wiederherstellen können, müssen Sie verstehen, was Sie eigentlich wiederherstellen. MetaMask speichert Ihre privaten Schlüssel nicht in einer Datei namens private_keys.txt. Es speichert sie in einem verschlüsselten Blob namens Tresorraum, das sich im Erweiterungsspeicher Ihres Browsers befindet.

Wenn Sie eine MetaMask-Wallet erstellen und ein Passwort festlegen, läuft im Hintergrund Folgendes ab: MetaMask generiert eine BIP-39-Mnemonik (Ihre 12 Wörter Geheime Wiederherstellungsphrase) und bündelt es – zusammen mit etwaigen importierten privaten Schlüsseln – in einem JSON-Array aus „keyring“-Objekten. Dieses Array wird in eine Zeichenkette serialisiert und anschließend verschlüsselt unter Verwendung von AES-256-GCM mit einem Schlüssel, der über Ihr Passwort abgeleitet wird, und zwar über PBKDF2-HMAC-SHA256. Das Ergebnis ist ein JSON-Blob mit drei oder vier Feldern, der in chrome.storage.local (in Chromium-Browsern) oder IndexedDB (in Firefox).

In älteren Versionen sieht der verschlüsselte Tresor wie folgt aus:

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

Und in neueren Versionen (ab v11.16.x) gibt es ein viertes Feld:

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

Das keyMetadata Dieser Aspekt entscheidet darüber, ob die Genesung nur wenige Minuten oder mehrere Wochen dauert. Dazu gleich mehr.

Die Verschlüsselungspipeline ist zwar einfach, muss aber genau verstanden werden. Ihr UTF-8-Passwort wird über die Web Crypto API als PBKDF2-Rohschlüssel importiert. Ein 32-Byte-Zufalls-Salt (generiert aus crypto.getRandomValues()) wird zusammen mit dem Passwort verwendet, um einen 256-Bit-AES-GCM-Schlüssel abzuleiten. Anschließend wird ein 16-Byte-Zufalls-IV verschlüsselt die serialisierten Schlüsselbunddaten. Die data Das Feld enthält sowohl den Chiffretext als auch das GCM-Authentifizierungstag, beides Base64-kodiert. Eine erwähnenswerte Besonderheit: MetaMask verwendet ein 16-Byte-IV für AES-GCM, was nicht dem Standard entspricht – NIST SP 800-38D empfiehlt 12 Byte. Dies führt zu Kompatibilitätsproblemen mit einigen Krypto-Bibliotheken (Rubys OpenSSL beispielsweise weigert sich, damit zu arbeiten).

Wenn Sie MetaMask mit Ihrem Passwort entsperren, läuft der Vorgang umgekehrt ab. Die KeyringController ruft die verschlüsselte Vault-Zeichenkette aus dem persistenten Speicher ab und übergibt sie an browser-passworder‘s decrypt Funktion, die das JSON-Datenformat analysiert, das Salt extrahiert, den Schlüssel mithilfe von PBKDF2 mit denselben Parametern ableitet, mit AES-GCM entschlüsselt und das Ergebnis wieder in Schlüsselbundobjekte deserialisiert. Die entschlüsselten Schlüsselbunde befinden sich nur in Erinnerung – sie werden im memStore (ein ObservableStore (Beispiel) und werden niemals im Klartext auf die Festplatte geschrieben.

Ein entschlüsselter Tresor enthält ein Array, das in der Regel wie folgt aussieht:

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

Die HD Key Tree Der Schlüsselbund enthält Ihre Mnemonik und die Anzahl der abgeleiteten Konten. Simple Key Pair Bei den Einträgen handelt es sich um einzeln importierte private Schlüssel. Wenn Sie Hardware-Wallets verbunden haben, werden außerdem Trezor Hardware und Ledger Hardware Schlüsselringtypen – diese speichern jedoch nur Ableitungspfade und öffentliche Adressen, nicht aber private Schlüssel (diese verbleiben auf dem Hardwaregerät).

Mit Manifest V3 (der Service-Worker-Architektur, die Chrome ab 2023 einführt) hat MetaMask die Möglichkeit hinzugefügt, den Verschlüsselungsschlüssel als exportierten JWK zwischenzuspeichern, sodass der Tresor beim Neustart des Service-Workers erneut entschlüsselt werden kann, ohne dass erneut nach dem Passwort gefragt wird. Der encryptionKey und encryptionSalt Felder erscheinen in memStore wenn cacheEncryptionKey ist aktiviert.

Wo MetaMask Ihre Daten auf den verschiedenen Plattformen speichert

Das Auffinden des Tresors ist schon die halbe Miete. MetaMask speichert Daten je nach Browser und Betriebssystem an unterschiedlichen Orten, und diese Unterschiede sind für die Wiederherstellung von Bedeutung.

Chromium-basierte Browser (Chrome, Brave, Edge)

In Chromium-basierten Browsern, chrome.storage.local bleibt bestehen bis zu einem LevelDB-Datenbank auf der Festplatte. Die Erweiterungs-ID bestimmt den Ordnernamen.

Die Erweiterungs-ID von Chrome ist nkbihfbeogaeaoehlefnkodbefgpgknn – das hat sich jedem Sanierungsspezialisten tief ins Gedächtnis eingebrannt. Tapfer verwendet dieselbe ID, da es über den Chrome Web Store installiert wird. Kante erhält eine eigene ID, wenn es aus dem Edge-Add-ons-Store installiert wird: ejbalbakoplchlghecdalmeeeajnimhm. Hat ein Nutzer MetaMask jedoch über den Chrome Web Store (den Edge unterstützt) in Edge installiert, bleibt die Chrome-ID erhalten. Diese Unterscheidung sorgt immer wieder für Verwirrung.

Hier sind die vollständigen Pfade:

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

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

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

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

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

Edge unter Windows (Installation über den Edge Store):
C:\Users\<USER>\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\ejbalbakoplchlghecdalmeeeajnimhm\

Ein wichtiges Detail: Wenn der Nutzer mehrere Chrome-Profile hat, ersetzen Sie Default mit Profile 1, Profile 2, usw. Ich habe schon erlebt, dass Leute stundenlang im falschen Profil gesucht haben.

Firefox – ein ganz anderes Kaliber

Firefox verwendet LevelDB nicht. Es speichert die Daten der Erweiterungen in IndexedDB, das Firefox auf Basis von SQLite implementiert. Die Erweiterungs-ID lautet webextension@metamask.io, aber Firefox weist jeder Installation eine eindeutige interne UUID zu – etwa so wie 196319ec-3a5e-4efe-9413-c327a770d874. Sie finden es unter about:debugging unter „Dieser Firefox“.

Die Daten befinden sich unter:

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/

Im Inneren des idb/ In diesem Ordner finden Sie Binärdateien mit numerischen Namen. Dabei handelt es sich um Snappy-komprimiert – Man kann sie nicht einfach wie LevelDB-Dateien mit `grep` durchsuchen. Man muss sie zunächst mit einem Tool wie snappy-fox bevor die Daten aus dem Tresor extrahiert werden können. Das ist der häufigste Fehler, den ich bei der Wiederherstellung von Firefox beobachte: Die Nutzer öffnen die Binärdatei, sehen unlesbare Daten, die mit Fragmenten erkennbaren Textes vermischt sind, und gehen davon aus, dass der Tresor beschädigt ist. Das ist jedoch nicht der Fall. Die Daten sind lediglich komprimiert.

Vor Firefox 63 wurde für den Speicher der Erweiterungen eine einfache JSON-Datei namens storage.js im Profilverzeichnis. Wenn Sie eine sehr alte Installation wiederherstellen, suchen Sie nach storage.js oder storage.js.migrated.

LevelDB und die Datei „0001.ldb“, nach der alle fragen

LevelDB ist Googles Schlüssel-Wert-Speicher-Engine, und das Verständnis ihrer Dateistruktur ist für die Wiederherstellung von MetaMask in jedem Chromium-Browser unerlässlich.

Ein MetaMask-LevelDB-Verzeichnis enthält verschiedene Dateitypen. Das .ldb Dateien (Sorted String Tables, kurz SSTables) sind der permanente, sortierte Schlüssel-Wert-Speicher. .log Dateien sind das Write-Ahead-Log – ein temporärer Puffer für die zuletzt vorgenommenen Schreibvorgänge, bevor diese in den .ldb Dateien. Es gibt eine MANIFEST-###### Metadaten der Datenbank zur Dateiverfolgung, a CURRENT Datei, die auf das aktive Manifest verweist, und eine LOCK Datei, die gleichzeitigen Zugriff verhindert.

Die Vault-Daten werden in der Regel in einem mit niedrigen Nummern .ldb Datei – 000003.ldb, 000005.ldb, oder so ähnlich. In der Dokumentation von MetaMask heißt es: „Es sollte sich um einen niedrigen Zahlenwert handeln. Wenn es sich um eine große Zahl handelt, handelt es sich nicht um den Tresor.“ Die 0001.ldb Datei (oder 000001.ldb) ist eine der ersten SSTables, die bei der Erstinitialisierung von MetaMask erstellt wurden. Sie enthält häufig den ursprünglichen Tresor, der bei der Erstellung der Wallet angelegt wurde.

Extrahieren von Tresordaten aus .ldb Dateien ist unter Chromium in der Regel ganz einfach. Öffnen Sie die Datei in einem Texteditor (Sublime Text, VS Code, sogar Notepad++) und suchen Sie nach der Zeichenfolge vault. Den verschlüsselten JSON-Blob findest du in die LevelDB-Datensatzstruktur eingebettet. Kopiere alles von {"data":" bis zum Abschluss "} – Das ist dein Tresor.

Auf einem Mac oder unter Linux reicht dieser Einzeiler aus:

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

Was man im Auge behalten sollte: .ldb Dateien können verwendet werden Schnelle Komprimierung in Datenblöcken. Wenn die Zeichenkettensuche fehlschlägt und Sie Blöcke mit binärem Müll sehen, ist der benötigte Datenblock möglicherweise mit Snappy komprimiert. Der .log Die Datei hingegen ist immer unkomprimiert – es handelt sich um rohe Schlüssel-Wert-Daten in 32-KB-Blöcken. Wenn die .ldb der Ansatz schlägt fehl, Überprüfen Sie immer die .log Datei. In der offiziellen Dokumentation von MetaMask heißt es dazu: „Wenn Sie Ihren Tresor nicht mithilfe der .ldb-Datei wiederherstellen können, prüfen Sie, ob eine .log-Datei vorhanden ist.“

Eine Eigenschaft von LevelDB, die für die Wiederherstellung äußerst nützlich ist: Es ist nur zum Anfügen. Aktualisierungen und Löschungen ändern keine bestehenden Datensätze – sie fügen neue Einträge mit höheren Sequenznummern hinzu. Alte Datensätze bleiben erhalten, bis sie im Rahmen einer Komprimierung zusammengeführt werden. Das bedeutet: Wenn jemand ein neues SRP über ein altes importiert hat, können die alten Vault-Daten möglicherweise noch in einer älteren .ldb Datei, die noch nicht komprimiert wurde. Ich habe auf diese Weise schon mehrmals „überschriebene“ Wallets wiederhergestellt.

Für die programmatische Extraktion wird die btcrecover Das Projekt umfasst extract-metamask-vaults.py, das die LevelDB-Datenbank ordnungsgemäß ausliest und alle Vault-Einträge abruft – einschließlich potenziell alter Einträge, die sich in nicht komprimierten Dateien verbergen. Das cyclone-github/metamask_extractor Das Tool erfüllt denselben Zweck und kann die Ausgabe direkt in ein mit Hashcat kompatibles Format erstellen.

Wenn Vault-Dateien beschädigt werden

Eine Beschädigung des Tresors hat in der Regel eine der folgenden Ursachen: einen Browserabsturz während eines Schreibvorgangs (Stromausfall, Kernel Panic, erzwungenes Beenden), ein unterbrochenes MetaMask-Update, bei dem der Speicher mitten im Vorgang neu geschrieben wird, tatsächliche Festplattenfehler (fehlerhafte Sektoren, SSD-Verschleiß) oder – was immer häufiger vorkommt – Antivirensoftware, die die JavaScript-Dateien von MetaMask unter Quarantäne stellt, wodurch die LevelDB-Datenbank in einen inkonsistenten Zustand geraten kann, obwohl die Tresordaten selbst intakt sind.

Sie wissen, dass Ihr Vault beschädigt ist, wenn das JSON nicht geparst werden kann. Fehlende Klammern, abgeschnittene Base64-Zeichenfolgen, Null-Bytes, die mitten in das Datenfeld eingefügt wurden. Der MetaMask Vault Decryptor gibt die Fehlermeldung „Problem beim Dekodieren des Vaults“ aus oder bricht einfach ohne Meldung ab.

Die Wiederherstellung hängt von der Art und dem Ausmaß der Beschädigung ab. Wenn die JSON-Struktur beschädigt ist, die verschlüsselten Daten jedoch größtenteils intakt sind, kann man oft das Gewölbe manuell wiederherstellen. Das Format ist streng vorgegeben – man braucht genau die data, iv, und salt Felder (sowie keyMetadata (für neuere Tresore). Entfernen Sie Null-Bytes und Steuerzeichen. Vergewissern Sie sich, dass die data, iv, und salt Die Werte sind gültiges Base64. Wenn die data Das Feld wird jedoch abgeschnitten – dann hast du ein Problem – AES-GCM erfordert den vollständigen Chiffretext sowie dessen Authentifizierungs-Tag (die letzten 16 Bytes der data Feld) zur Entschlüsselung. Schon ein einziges fehlendes Byte führt dazu, dass der gesamte Vorgang fehlschlägt.

Bei teilweise beschädigten LevelDB-Datenbanken, bei denen die .ldb Wenn die Dateien selbst beschädigt sind, versuchen Sie, die .log Stattdessen sollten Sie die Datei verwenden – sie hat ein einfacheres Format (sequenzielle 32-KB-Blöcke mit 7-Byte-Headern) und enthält möglicherweise eine aktuellere Kopie des Tresors, die den Beschädigungsvorfall überstanden hat. Wenn keiner der beiden Ansätze funktioniert, können Sie manchmal Python-Bibliotheken zum Parsen von LevelDB verwenden (die CCL Solutions Group hat reine Python-Implementierungen für das Parsen von LevelDB, die Snappy-Dekomprimierung und die V8-Deserialisierung veröffentlicht), um Datensätze präzise aus beschädigten Datenbankdateien zu extrahieren und dabei beschädigte Blöcke zu überspringen.

In einem einzelnen LevelDB-Verzeichnis können mehrere SRPs nebeneinander bestehen. Wenn ein Benutzer eine neue Seed-Phrase importiert hat, bleibt der alte Vault-Eintrag möglicherweise in einem separaten .ldb Datei oder sogar innerhalb derselben Datei an einer anderen Stelle. Suche immer nach alle Fälle des Gewölbemusters, nicht nur das erste.

Das Problem mit überschriebenen Dateien und wie man es beheben kann

Das ist das Szenario, das am meisten Kummer bereitet. Jemand deinstalliert MetaMask – vielleicht, um ein Problem zu beheben, vielleicht, um seinen Browser „aufzuräumen“, vielleicht auch, weil er gar nicht bemerkt hat, was er da tat. Bei Chromium-Browsern führt die Deinstallation einer Erweiterung dazu, dass löscht den gesamten Ordner mit den Erweiterungsdaten, einschließlich aller .ldb, .log, sowie Manifest-Dateien. In Firefox wird die moz-extension+++<UUID> Der Ordner wird gelöscht, und da bei jeder Neuinstallation eine neue UUID generiert wird, greift die neue Installation nicht auf den alten Speicherort zu (der alte Speicherort ist jedoch nicht mehr vorhanden).

Die Dokumentation von MetaMask drückt sich diesbezüglich ganz klar aus: „Die Daten der Browser-Erweiterung werden gelöscht, wenn die Erweiterung deinstalliert wird. Im Allgemeinen bedeutet dies, dass Ihre Tresordaten verloren gehen.“

Das Wort „im Allgemeinen“ hat hier eine große Bedeutung. Die Daten werden logisch gelöscht – das Dateisystem markiert diese Sektoren als frei –, aber die eigentlichen Bytes werden nicht sofort auf Null gesetzt. Auf einer herkömmlichen Festplatte bleiben die Daten so lange erhalten, bis diese Sektoren zufällig von neuen Dateien wiederverwendet werden. Auf einer SSD können TRIM-Befehle gelöschte Daten innerhalb von Minuten, manchmal sogar Sekunden, unwiederherstellbar machen.

Die erste Regel bei der Wiederherstellung eines überschriebenen Tresors lautet: Stellen Sie die Nutzung des Computers sofort ein. Jede neue Datei, die auf das Laufwerk geschrieben wird, könnte die Sektoren überschreiben, auf denen sich Ihr Tresor zuvor befand. Wenn möglich, bauen Sie das Laufwerk aus und schließen Sie es schreibgeschützt an einen anderen Rechner an.

Wiederherstellungswerkzeuge für dieses Szenario, in der Reihenfolge, in der ich sie als Erstes heranziehe:

• Unsere maßgeschneiderte Software (plattformübergreifend) zur Wiederherstellung logisch gelöschter Dateien
• extundelete oder ext4magic für Linux-Dateisysteme vom Typ ext3/ext4
• Raw-Disk-Suche als letztes Mittel: grep -rboa "vault" /dev/sdX um das Raw-Disk-Gerät nach Vault-Zeichenfolgen zu durchsuchen
• Unsere maßgeschneiderten Werkzeuge für das „File Carving“, wenn die Metadaten des Dateisystems verloren gegangen sind – konfigurieren Sie es so, dass es nach {"data":" Muster

Ich habe bereits Tresore von Laufwerken wiederhergestellt, die bereits vor Wochen deinstalliert worden waren – auf Festplatten. Bei SSDs sinkt die Erfolgsquote bereits nach wenigen Stunden fortgesetzter Nutzung drastisch. Die Neuinstallation von MetaMask ist das Schlimmste, was man tun kann, da dabei eine neue LevelDB-Datenbank im exakt gleichen Verzeichnis angelegt wird, wodurch die alten Sektoren möglicherweise überschrieben werden.

Firefox hat hier einen Vorteil. Da jede Installation eine neue UUID erhält, werden bei einer Neuinstallation Dateien in einem neuen Verzeichnispfad angelegt. Die alten moz-extension+++<OLD-UUID> Die Daten werden – selbst wenn der Ordner gelöscht wurde – nicht durch die Dateien der neuen Installation überschrieben. Außerdem gibt es zwei versteckte Firefox-Einstellungen – extensions.webextensions.keepUuidOnUninstall und extensions.webextensions.keepStorageOnUninstall – das, wenn es auf true in about:config Verhindern Sie vor der Deinstallation, dass der Browser den Speicher der Erweiterung löscht. Aber niemand richtet diese Einstellungen proaktiv ein.

MetaMask auf dem Handy ist eine ganz andere Sache

MetaMask Mobile basiert auf React Native und speichert Daten ganz anders als die Browser-Erweiterung. Der verschlüsselte Tresor durchläuft @react-native-async-storage/async-storage, das plattformspezifische Backends verwendet.

Auf Android, AsyncStorage schreibt in der Regel in eine SQLite-Datenbank bei /data/data/io.metamask/databases/RKStorage. Dieser Weg erfordert Root-Zugriff, um direkt lesen zu können. Die Verschlüsselung des Tresors nutzt denselben PBKDF2-basierten Schlüsselansatz, weist jedoch wesentliche Unterschiede zur Desktop-Erweiterung auf: Die mobile App verwendet seit jeher nur 5.000 PBKDF2-Iterationen und verschlüsselt mit AES-CBC anstelle von AES-GCM. Das bedeutet, dass mobile Tresore nicht mit Desktop-Tresoren austauschbar sind, selbst wenn das Passwort identisch ist.

Unter iOS, die Daten befinden sich in der App-Sandbox unter <AppSandbox>/Documents/. Für die Wiederherstellung eines iCloud-Backups lautet der entsprechende Pfad Apps → MetaMask → Documents → persistStore → persist-root – Sie benötigen ein Tool wie iMazing, um ein iOS-Backup auf einem Mac zu durchsuchen. Ob diese Methode funktioniert, hängt davon ab, ob der Nutzer das iCloud-Backup aktiviert hatte, während MetaMask aktiv war, und Änderungen seitens Apple haben diesen Ansatz Berichten zufolge zeitweise unbrauchbar gemacht.

MetaMask Mobile implementiert außerdem eine SecureKeychain Modul (basierend auf react-native-keychain), das das Wallet-Passwort des Benutzers im iOS-Schlüsselbund oder im Android-Keystore speichert, um die biometrische Entsperrung zu ermöglichen. Eine Sicherheitsprüfung ergab, dass SecureKeychain mithilfe eines „foxCode“-Salts eine zusätzliche Verschlüsselungsebene hinzufügt – bei dem es sich, wie sich herausstellte, um die fest codierte Zeichenfolge handelte "encrypt". Das MetaMask-Team räumte ein, dass es sich hierbei eher um eine mehrschichtige Sicherheitsstrategie als um ein sicherheitskritisches Geheimnis handelte.

Die grundlegende Herausforderung bei der Wiederherstellung mobiler Geräte besteht darin, dass Es gibt keine manuelle Entnahme aus dem Tresor. entspricht dem Finden von .ldb Dateien auf dem Desktop. Man kann sich nicht per SSH in sein iPhone einloggen und dort nach Vault-Zeichenfolgen suchen. Ab MetaMask Mobile v6.3.0, die App verfügt über eine automatische Wiederherstellungsfunktion für den Tresor, die bei Feststellung einer Beschädigung ausgelöst wird – wird die App jedoch gelöscht, gehen die lokalen Tresordaten verloren, sofern Sie kein Gerätesicherungs-Backup haben. Die Sicherungsmechanismen von Android sind besonders unzuverlässig, wenn es darum geht, alle app-internen Daten zu erfassen. Die offizielle Stellungnahme von MetaMask Es wird empfohlen, die Daten auf ein neues SRP zu übertragen, anstatt sich auf die Wiederherstellung über den Android-Tresor zu verlassen.

Die Änderung bei der PBKDF2-Iterationsanzahl, die alle Wiederherstellungstools lahmlegte

Seit Jahren verwendete MetaMask 10.000 PBKDF2-Iterationen – der fest codierte Standardwert in der browser-passworder Bibliothek. Jedes Wiederherstellungstool, jedes Hashcat-Modul, jedes Brute-Force-Skript war auf 10.000 Iterationen ausgelegt. Dann, Ende 2023 / Anfang 2024, änderte sich alles.

Die @metamask/browser-passworder Mit der Version 4.2.0 der Bibliothek (veröffentlicht am 13. November 2023) wurde die Unterstützung für konfigurierbare Optionen zur Schlüsselableitung eingeführt. Der neue Standardwert der Bibliothek wurde auf 900.000 Iterationen, aber die MetaMask-Erweiterung hat es so konfiguriert, dass es 600.000 Iterationen – Anpassung an die OWASP-Empfehlung für 2023 bezüglich PBKDF2-HMAC-SHA256. Von der MetaMask-Erweiterung v11.16.11 (bestätigt in einer Hashcat-Version vom Juni 2024) wurden neue Tresore mit 600.000 Iterationen erstellt, und die neue keyMetadata Feld.

Dies entspricht einer 60-fachen Erhöhung des Rechenaufwands pro Passwortversuch. Ein Brute-Force-Angriff, der bei 10.000 Iterationen einen Tag dauerte, benötigt nun bei 600.000 Iterationen auf derselben Hardware zwei Monate. Die Hashcat-Community musste eigene Kernel entwickeln – den Modus 26620, beigesteuert von cyclone –, um das neue Format zu verarbeiten. Der Standardmodus 26600 hatte 10.000 Iterationen fest einprogrammiert.

Wichtig: Alte Tresore werden NICHT automatisch neu verschlüsselt. Wenn Sie Ihre Wallet im Jahr 2021 erstellt haben, verwendet Ihr Tresor weiterhin 10.000 Iterationen, es sei denn, MetaMask hat explizit eine Neuverschlüsselung ausgelöst (die updateVault Zu diesem Zweck gibt es zwar eine Funktion, aber es ist unklar, wie intensiv MetaMask diese beim Entsperren aufruft. Anhand des Vorhandenseins bzw. Fehlens des keyMetadata Feld. Nein keyMetadata? Es sind 10.000 Iterationen. Hat keyMetadata mit "iterations": 600000? Das ist das neue Format.

Hier ist die vollständige Zeitleiste der Versionen der Verschlüsselungsbibliothek, die für die Wiederherstellung von Bedeutung sind:

• browser-passworder v1.x–v2.x (vor 2022): 10.000 Iterationen, fest programmiert. Veröffentlicht ohne die @metamask Geltungsbereich.
• v3.0.0 (August 2022): Umbenannt in @metamask/browser-passworder. Keine Änderung der Iterationsanzahl.
• v4.2.0 (November 2023): Hinzugefügt keyMetadata Unterstützung. Die Standardanzahl der Verschlüsselungsiterationen wurde auf 900.000 geändert. keyFromPassword abwärtskompatibel bei 10.000.
• v4.3.0 (November 2023): Hinzugefügt isVaultUpdated um zu überprüfen, ob der Tresor die Zielparameter erfüllt.
• v5.0.0 (April 2024): Node.js v16 als Mindestversion. Keine Änderungen im Bereich Kryptografie.
• v6.0.0 (Dezember 2024): Mindestens Node.js v18.18 erforderlich. Keine Änderungen im Bereich Kryptografie.

An alle Wiederherstellungsspezialisten: Überprüfen Sie immer zuerst das Vault-Format. Davon hängt Ihre gesamte Vorgehensweise ab.

Die Passwortrichtlinie von MetaMask und was sie für Brute-Force-Angriffe bedeutet

MetaMask schreibt eine Mindestlänge des Passworts von 8 Zeichen vor. Das ist alles. Keine Großbuchstaben, keine Zahlen, keine Sonderzeichen. Die Erweiterung zeigt eine visuelle Sicherheitsanzeige an („Schwach“ / „Gut“), blockiert jedoch keine schwachen Passwörter, die die Mindestlänge erfüllen. Es gibt auch keine maximale Länge – Unicode-Zeichen werden unterstützt. Diese Richtlinie gilt mindestens seit Anfang 2018 (siehe GitHub-Issue #3515).

Auf einigen Websites von Drittanbietern wird fälschlicherweise behauptet, dass MetaMask Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen erfordert. Das ist falsch. Die einzige zwingende Vorgabe ist eine Länge von 8 Zeichen.

Für die Brute-Force-Wiederherstellung spielt dies eine enorme Rolle. Ein Passwort aus 8 Zeichen, das ausschließlich aus Kleinbuchstaben besteht, hat einen Schlüsselraum von etwa 208 Milliarden Kombinationen (26^8). Bei einem alten Tresor mit 10.000 Iterationen kann „hashcat“ auf einer modernen GPU Tausende von Hashes pro Sekunde testen, sodass dieser innerhalb weniger Tage geknackt werden kann. Bei einem Tresor mit 600.000 Iterationen vergrößert sich die benötigte Zeit um das 60-Fache. Ein starkes Passwort mit mehr als 12 Zeichen, Groß- und Kleinbuchstaben sowie Sonderzeichen? Mit aktueller Hardware ist es gegen beide Formate praktisch unknackbar.

Das praktische Wiederherstellungstool der Wahl ist btcrecover – MetaMask selbst empfiehlt diese Funktion für Nutzer, die eine ungefähre Vorstellung von ihrem Passwort haben. Sie unterstützt das Erraten anhand von Tokens und Mustern, sodass Sie eine Vorlage definieren können, wie zum Beispiel "my" + [dog|cat|bird] + [2019|2020|2021] + ["!"|"@"|"#"] und alle Permutationen effizient zu testen. Bei GPU-beschleunigten Angriffen unterstützt der Hashcat-Modus 26600 ältere Tresore, der Modus 26610 mobile Tresore und der Modus 26620 (oder eine neu kompilierte Version von 26600 mit aktualisierten Iterationen) das neue Format mit 600.000 Iterationen.

Herkunftswege und die „Fehlbeträge“-Epidemie

Der Abrechnungspfad ist der Ort, an dem die meisten Probleme vom Typ „Mein Geld ist verschwunden“ ihren Ursprung haben. MetaMask verwendet den BIP-44-Standardpfad für Ethereum: m/44'/60'/0'/0. Die Berechnungen erfolgen durch Inkrementieren des Endindex: m/44'/60'/0'/0/0 (erster Bericht), m/44'/60'/0'/0/1 (zweitens), m/44'/60'/0'/0/2 (drittens) und so weiter. Dieser Pfad gilt für alle EVM-kompatiblen Blockchains – dieselbe Adresse auf Ethereum, Polygon, Arbitrum und BSC.

Das Problem ist, dass nicht jeder denselben Pfad verwendet. Ledger Live Verwendungszwecke m/44'/60'/x'/0/0, wobei die account Feld anstelle des address_index. Ledger-Erbe (der alte MEW/MyCrypto-Pfad) verwendet m/44'/60'/0'/x – nur vier Stufen statt fünf. Die erste Adresse (m/44'/60'/0'/0/0) ist in MetaMask, Ledger Live und Trezor identisch. Aber die Der zweite Bericht und alle folgenden weichen völlig davon ab, da jede Wallet einen anderen Bestandteil des Pfades erhöht.

Dies führt zu einem ganz bestimmten Fehlerbild: Jemand stellt seinen Ledger-Seed in MetaMask wieder her, sieht sein erstes Konto und dessen Guthaben, fügt dann ein zweites Konto hinzu und sieht … null. Das Guthaben ist nicht verschwunden. Es befindet sich an der Adresse, die sich aus m/44'/60'/1'/0/0 (im Stil von Ledger Live), aber MetaMask prüft derzeit m/44'/60'/0'/0/1. Völlig unterschiedliche Schlüssel, völlig unterschiedliche Adressen.

Der Standard-Derivationspfad für Ethereum bei Trezor entspricht dem von MetaMask: m/44'/60'/0'/0/x. Die Wiederherstellung von Trezor zu MetaMask funktioniert also grundsätzlich für alle Konten. Die Probleme bei der Übertragung zwischen verschiedenen Wallets betreffen in erster Linie Ledger ↔ MetaMask und Ledger ↔ Trezor.

Um Mittel auf dem „falschen“ Ableitungsweg zu finden, haben Sie folgende Möglichkeiten:

• Schreiben Sie uns eine E-Mail an contact@cryptorecovery.io, und wir werden versuchen, Ihnen zu helfen und Sie zu unterstützen.
• MyEtherWallet (MEW): Unterstützt benutzerdefinierte Ableitungspfade über „Pfad hinzufügen“. Geben Sie diese manuell ein m/44'/60'/1'/0/0, m/44'/60'/2'/0/0, usw., um Adressen im Ledger-Live-Format zu überprüfen.
• MyCrypto: Unterstützung für ähnliche benutzerdefinierte Ableitungspfade.
• Das BIP-39-Tool von Ian Coleman (Offline-Betrieb): Geben Sie die Mnemonik ein, wählen Sie „ETH“ aus, wechseln Sie zwischen den BIP-44-Registerkarten und passen Sie die Pfadkomponenten manuell an.
• btcrecover: Kann Tests über verschiedene Ableitungspfadschemata hinweg automatisieren.

Eine frustrierende Einschränkung: Die Trezor-Integration von MetaMask unterstützt keine benutzerdefinierten Ableitungspfade. Eine Option für benutzerdefinierte Ableitungspfade wurde für Ledger integriert (PR #9367), doch nach den neuesten Informationen ist das entsprechende Ticket für Trezor (GitHub-Issue #11197) weiterhin offen. Wenn Sie versuchen, über MetaMask + Trezor auf von Ledger abgeleitete Konten zuzugreifen, müssen Sie stattdessen MEW oder MyCrypto verwenden.

MetaMask und Trezor: eine schwierige Verbindung

Die Integration von MetaMask und Trezor funktioniert über Trezor Bridge – ein lokal installierter Hintergrundprozess (trezord), das auf http://127.0.0.1:21325/ und überbrückt die Lücke zwischen der Browser-Sandbox und dem Zugriff auf USB-Hardware. Sie können überprüfen, ob es läuft, indem Sie auf http://127.0.0.1:21325/status/.

Die häufigste Fehlerursache ist trügerisch einfach: Die Trezor Suite ist geöffnet. Die Trezor Suite sperrt die USB-Verbindung zum Gerät und verhindert so die Kommunikation mit MetaMask. Sie müssen die Suite vollständig beenden – nicht nur minimieren, sondern über die Taskleiste schließen. Ich schätze, dass dies auf 40 % der Support-Anfragen zurückzuführen ist, bei denen es heißt: „MetaMask kann meinen Trezor nicht finden“.

Weitere häufige Probleme und deren Lösungen:

„Auf der Suche nach Ihrem Trezor…“ – dreht sich endlos – Überprüfen Sie, ob Bridge installiert ist, und trezord ist aktiv. Probieren Sie ein anderes USB-Kabel und einen anderen Anschluss aus. Deaktivieren Sie VPN, Firewall und Browser-Erweiterungen (Werbeblocker und Datenschutz-Erweiterungen verursachen häufig Störungen). Im Inkognito-Modus werden Konflikte mit Erweiterungen vermieden.

„Geräteverbindung wird hergestellt“ – Eine andere Anwendung oder ein anderer Browser-Tab kommuniziert bereits mit dem Trezor. Schließen Sie alle anderen Tabs und Anwendungen, die möglicherweise auf das Gerät zugreifen.

Einschränkungen bei WebUSB – Firefox unterstützt WebUSB überhaupt nicht, was bedeutet, dass die Verbindung mit Trezor in Firefox vollständig über Bridge erfolgt. Chrome, Brave und Edge funktionieren über die Chromium-Implementierung von WebUSB/WebHID.

Die Warnung zum Ableitungspfad beim Trezor Safe 5 – Nutzer berichten, dass während der Transaktionsüberprüfung auf dem Trezor-Bildschirm die Meldung „Falscher Ableitungspfad für das ausgewählte Konto. m/44’/60’/0’/0“ angezeigt wird. Diese Warnung kann in der Regel bedenkenlos ignoriert werden – die Wallet funktioniert trotz dieser Meldung einwandfrei. Es handelt sich um ein rein optisches Problem, das damit zusammenhängt, wie die Trezor-Firmware nicht standardmäßig aussehende Pfade überprüft.

Im Jahr 2025 begann Trezor damit, die Bridge-Funktionalität in die Trezor Suite selbst zu integrieren. Dieser Übergang führte zu einer Reihe von Verbindungsproblemen, da einige Nutzer die Suite für MetaMask-Verbindungen im Hintergrund laufen lassen mussten, während andere sie vollständig geschlossen halten mussten. Überprüfen Sie die entsprechenden Einstellungen unter Trezor Suite → Einstellungen → Anwendung → Trezor Connect.

Wenn MetaMask eine Verbindung zu einem Trezor herstellt, unterscheiden sich die daraus resultierenden Konten grundlegend von den Konten der MetaMask-Software-Wallet. Bei Trezor-abgeleiteten Konten werden im Tresor lediglich öffentliche Schlüssel und Ableitungspfade gespeichert – die privaten Schlüssel verbleiben auf dem Hardware-Gerät. MetaMask kann Guthaben (schreibgeschützt über öffentliche Schlüssel) anzeigen, ohne dass der Trezor angeschlossen ist, kann jedoch keine Transaktionen signieren, ohne dass das physische Gerät vorhanden ist. Wenn bei der Erstellung der Trezor-Konten eine Passphrase verwendet wurde, muss genau dieselbe Passphrase eingegeben werden, um dieselben Adressen neu zu generieren.

Wiederherstellungstechniken, die in der Praxis tatsächlich funktionieren

Nach Hunderten von Datenwiederherstellungen sind dies die Szenarien, denen ich am häufigsten begegne, und so gehe ich damit um.

Szenario 1: Passwort vorhanden, Seed-Phrase verloren, Erweiterung weiterhin installiert

Das ist ganz einfach. Öffnen Sie die Hintergrundseite von MetaMask über chrome://extensions → Entwicklermodus → Klicken Sie auf „Service Worker“ (MV3) oder „Hintergrundseite“ (MV2). In der Konsole:

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

Kopieren Sie den JSON-Code des Tresors und fügen Sie ihn in die MetaMask-Vault-Entschlüsseler (metamask.github.io/vault-decryptor), geben Sie Ihr Passwort ein, und das Programm zeigt Ihre Mnemonik sowie alle importierten privaten Schlüssel an. Der „Vault Decryptor“ wurde von Dan Finlay, dem Mitbegründer von MetaMask, entwickelt – er unterstützt außerdem .ldb Dateien direkt per Datei-Upload.

Szenario 2: Passwort ist bekannt, die Erweiterung wurde deinstalliert, aber die Daten könnten noch auf der Festplatte vorhanden sein

Wechseln Sie in das Datenverzeichnis der Erweiterung. Falls der Ordner noch vorhanden ist (manchmal wird er bei der Deinstallation nicht vollständig entfernt, oder der Benutzer hat die Erweiterung nur deaktiviert, anstatt sie zu entfernen), kopieren Sie die .ldb und .log Dateien. Entpacken Sie das Archiv mit grep, einem Texteditor oder btcrecover‘s extract-metamask-vaults.py. Mit dem Vault Decryptor entschlüsseln.

Sollte der Ordner nicht mehr vorhanden sein, kontaktieren Sie uns bitte unter contact@cryptorecovery.io – wir helfen Ihnen dann bei der Festplattenforensik.

Sie können das Laufwerk auch schreibgeschützt einbinden und eine Rohdatensuche nach bestimmten Zeichenfolgenmustern im Datenspeicher durchführen. Unter Linux: grep -rboa '{"data":"' /dev/sdX. Der Erfolg hängt stark davon ab, wie viel Festplattenaktivität nach dem Löschen stattgefunden hat und ob es sich bei dem Laufwerk um eine SSD oder eine HDD handelt.

Szenario 3: Passwort vergessen, die Tresordatei ist vorhanden

Dies ist ein Brute-Force-Szenario. Extrahieren Sie den Tresor und konvertieren Sie ihn mithilfe von metamask2hashcat.py oder cyclone-github/metamask_extractor. Führen Sie anschließend hashcat (Modus 26600 für alte Tresore, 26620 für neue) oder btcrecover mit einer Token-Datei aus, in der Sie Ihre Erinnerungen an das Passwort festgehalten haben. Wenn Sie wissen, dass Ihr Passwort etwa aus „myDog“ plus einer Jahreszahl plus einem Symbol bestand, kann btcrecover diese Kombinationen effizient durchprobieren.

Szenario 4: Firefox-Wiederherstellung

Die MetaMask-UUID finden Sie unter about:debugging. Wechseln Sie in das Speicherverzeichnis. Entpacken Sie die IndexedDB-Binärdateien mit snappy-fox:

./snappy-fox input_file.snappy output.txt

Durchsuchen Sie die entpackte Ausgabe nach der Vault-JSON-Datei. Fahren Sie anschließend mit dem Vault Decryptor fort. Der JesseBusman/FirefoxMetamaskWalletSeedRecovery Ein Python-Skript automatisiert diesen gesamten Vorgang – es durchsucht das Firefox-Profil, findet die Daten im Tresor und gibt sie in einem zur Entschlüsselung geeigneten JSON-Format aus.

Szenario 5: Nach dem Import der Startguthaben scheinen Guthaben zu fehlen

Überprüfen Sie die Ableitungspfade. Wenn Sie einen Ledger-Seed in MetaMask importieren, werden ab dem zweiten Konto unterschiedliche Adressen und ein Guthaben von null angezeigt. Verwenden Sie MEW oder MyCrypto mit benutzerdefinierten Ableitungspfaden, um Ihre Guthaben in Ledger Live zu finden (m/44'/60'/x'/0/0) oder „Ledger Legacy“ (m/44'/60'/0'/x) Pfade. Falls eine Trezor-Passphrase verwendet wurde, stellen Sie sicher, dass Sie genau dieselbe Passphrase eingeben – eine andere Passphrase erzeugt aus demselben Seed einen völlig anderen Satz von Adressen.

Forensische Tools, die in Ihrem Werkzeugkasten nicht fehlen sollten

• MetaMask-Vault-Entschlüsseler – offiziell, kann offline betrieben werden, unterstützt Direktverbindungen .ldb Datei hochladen
• btcrecover – Passwortwiederherstellung mittels Musterabgleich, von MetaMask empfohlen
• hashcat – GPU-beschleunigte Brute-Force-Angriffe (Modi 26600, 26610, 26620)
• snappy-fox – Firefox Snappy-Entpackung
• Python-Tools der CCL Solutions Group – LevelDB-Parsing in reinem Python, Snappy-Dekomprimierung, V8-Deserialisierung

---

Fazit: Was erfolgreiche Sanierungen von gescheiterten unterscheidet

Ob man seine Wallet zurückbekommt oder sie für immer verliert, hängt fast immer davon ab, was in den ersten Minuten nach der Entdeckung des Problems passiert ist. Die mit Abstand schädlichste Maßnahme ist die Neuinstallation von MetaMask im selben Browserprofil – dadurch wird das LevelDB-Verzeichnis mit neuen Dateien überschrieben. Die zweitgrößte Gefahr besteht darin, den Computer nach dem Löschen des Tresors weiterhin wie gewohnt auf einer SSD zu nutzen, da dies den TRIM-Befehl auslöst und eine Wiederherstellung auf Sektorebene unmöglich macht.

Wenn Sie drei Dinge aus diesem Leitfaden mitnehmen sollten: Sichern Sie Ihre Seed-Phrase auf Papier, machen Sie sich bewusst, dass sich Ihr Tresor in einem bestimmten Ordner befindet, den Sie kopieren und aufbewahren können, und sollten Probleme auftreten, stellen Sie die Nutzung dieses Computers sofort ein, bevor Sie versuchen, die Daten wiederherzustellen. Die Verschlüsselung ist solide – AES-256-GCM mit 600.000 PBKDF2-Iterationen lässt sich nicht durch Brute-Force-Angriffe knacken, es sei denn, das Passwort ist schwach –, aber die Daten selbst sind überraschend anfällig. Es handelt sich lediglich um wenige Kilobyte in einer LevelDB-Datenbank, die mit einem einzigen Klick zum Leeren des Browserverlaufs verschwinden können.

Jede Wallet, die ich nicht wiederherstellen konnte, hatte dieselbe Ursache: Der Nutzer hat das Gerät nach dem Datenverlust weiter genutzt. Jede Wallet, die ich erfolgreich wiederherstellen konnte, war eine, bei der die Daten noch auf der Festplatte vorhanden waren – manchmal an überraschenden Orten, manchmal in mehreren Kopien dank der „Append-Only“-Architektur von LevelDB, aber immer deshalb, weil jemand innegehalten und nachgedacht hat, bevor er handelte.

Wenn Sie Hilfe bei der Wiederherstellung Ihrer MetaMask-Wallet benötigen, kontaktieren Sie uns bitte per E-Mail: contact@cryptorecovery.io für eine professionelle, kostenlose Beratung oder besuchen Sie unsere Kontaktseite