CryptoRecovery.io – Services de récupération de portefeuilles

Contactez-nous

Comment récupérer son portefeuille MetaMask ? Mot de passe perdu, stockage du coffre-fort, cryptage et analyse des données

Avatar de Peter CryptoRecovery
Peter CryptoRecovery
Comment récupérer son portefeuille MetaMask ? Mot de passe perdu, stockage du coffre-fort, cryptage et analyse des données

Comment récupérer son portefeuille MetaMask ? Mot de passe perdu, stockage du coffre-fort, cryptage et analyse des données

Si vous lisez ceci, c'est probablement que vous avez perdu l'accès à votre portefeuille MetaMask et que vous êtes à court d'options. J'ai passé des années à récupérer des portefeuilles pour des gens – des traders DeFi qui ont reformaté leur ordinateur portable aux grands-parents qui ont « nettoyé » leurs extensions de navigateur. Ce guide couvre tout ce que je sais sur la façon dont MetaMask stocke vos clés, où ces données se trouvent réellement sur le disque, et comment les récupérer quand les choses tournent mal. Rien de tout cela n'est théorique. Chaque technique présentée ici provient de récupérations réelles.

Comment MetaMask stocke réellement vos clés

Avant de pouvoir récupérer quoi que ce soit, vous devez comprendre ce que vous récupérez. MetaMask ne stocke pas vos clés privées dans un fichier nommé private_keys.txt. Il les stocke dans un blob chiffré appelé chambre forte, qui se trouve dans le répertoire des extensions de votre navigateur.

Lorsque vous créez un portefeuille MetaMask et que vous définissez un mot de passe, voici ce qui se passe en arrière-plan. MetaMask génère une phrase mnémonique BIP-39 (votre phrase de 12 mots Phrase secrète de récupération) et l'intègre – avec toutes les clés privées importées – dans un tableau JSON d'objets « keyring ». Ce tableau est sérialisé en une chaîne de caractères, puis chiffré à l'aide de AES-256-GCM à l'aide d'une clé dérivée de votre mot de passe via PBKDF2-HMAC-SHA256. Le résultat est un bloc JSON comportant trois ou quatre champs qui est écrit dans chrome.storage.local (sur les navigateurs Chromium) ou IndexedDB (sur Firefox).

Dans les anciennes versions, le coffre-fort crypté se présente comme suit :

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

Et dans les versions plus récentes (postérieures à la v11.16.x), il y a un quatrième champ :

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

Cela keyMetadata C'est ce qui fait la différence entre une récupération qui ne prend que quelques minutes et une qui s'étale sur plusieurs semaines. Nous y reviendrons dans un instant.

Le processus de chiffrement est simple, mais il est important de bien le comprendre. Votre mot de passe au format UTF-8 est importé sous forme de clé PBKDF2 brute via l'API Web Crypto. A sel aléatoire de 32 octets (généré à partir de crypto.getRandomValues()) est utilisé conjointement avec le mot de passe pour générer une clé AES-GCM de 256 bits. Ensuite, un IV aléatoire de 16 octets chiffre les données sérialisées du trousseau de clés. Le data Ce champ contient à la fois le texte chiffré et la balise d'authentification GCM, encodés en Base64. Une particularité à noter : MetaMask utilise un IV de 16 octets pour AES-GCM, ce qui n'est pas conforme aux normes – la spécification NIST SP 800-38D recommande 12 octets. Cela pose des problèmes d'interopérabilité avec certaines bibliothèques cryptographiques (OpenSSL pour Ruby, par exemple, refusera de fonctionner avec cette configuration).

Lorsque vous déverrouillez MetaMask à l'aide de votre mot de passe, le processus s'inverse. Le KeyringController récupère la chaîne de chiffrement du coffre-fort dans le stockage persistant, puis la transmet à browser-passworder’s decrypt fonction qui analyse le JSON, extrait le sel, génère la clé à l'aide de PBKDF2 avec les mêmes paramètres, déchiffre le contenu avec AES-GCM, puis désérialise le résultat en objets de trousseau de clés. Les trousseaux de clés déchiffrés sont stockés uniquement en mémoire – elles sont stockées dans le memStore (un ObservableStore (par exemple) et ne sont jamais enregistrées sur le disque en clair.

Un coffre-fort déchiffré contient un tableau qui se présente généralement comme suit :

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

Le HD Key Tree Le trousseau de clés contient votre phrase mnémonique et le nombre de comptes dérivés. Simple Key Pair Les entrées correspondent à des clés privées importées individuellement. Si vous avez connecté des portefeuilles matériels, vous verrez également Trezor Hardware et Ledger Hardware types de porte-clés – bien que ceux-ci ne stockent que les chemins de dérivation et les adresses publiques, et non les clés privées (celles-ci restent sur le dispositif matériel).

Avec Manifest V3 (l'architecture de service worker que Chrome a commencé à déployer en 2023), MetaMask a ajouté la possibilité de mettre en cache la clé de chiffrement sous forme de fichier JWK exporté, afin de pouvoir déchiffrer à nouveau le coffre-fort lors du redémarrage du service worker sans demander à nouveau le mot de passe. Le encryptionKey et encryptionSalt les champs apparaissent dans memStore quand cacheEncryptionKey est activée.

Où MetaMask stocke vos données sur chaque plateforme

Trouver le coffre-fort, c'est déjà la moitié du chemin. MetaMask stocke les données à différents emplacements selon le navigateur et le système d'exploitation, et ces différences sont importantes pour la récupération.

Navigateurs basés sur Chromium (Chrome, Brave, Edge)

Sur les navigateurs basés sur Chromium, chrome.storage.local se maintient à un Base de données LevelDB sur le disque. L'identifiant de l'extension détermine le nom du dossier.

Identifiant de l'extension Chrome est nkbihfbeogaeaoehlefnkodbefgpgknn – gravé dans la mémoire de tous les spécialistes de la réadaptation. Courageux utilise le même identifiant, car il s'installe depuis le Chrome Web Store. Bord reçoit son propre identifiant s'il est installé à partir de la boutique d'extensions Edge : ejbalbakoplchlghecdalmeeeajnimhm. Mais si un utilisateur a installé MetaMask sur Edge via le Chrome Web Store (que Edge prend en charge), il conserve son identifiant Chrome. Cette distinction prête constamment à confusion.

Voici les chemins d'accès complets :

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

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

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

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

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

Edge sous Windows (installation depuis le Microsoft Store) :
C:\Users\<USER>\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\ejbalbakoplchlghecdalmeeeajnimhm\

Un détail important : si l'utilisateur dispose de plusieurs profils Chrome, remplacez Default avec Profile 1, Profile 2, etc. J'ai déjà vu des gens passer des heures à chercher sur le mauvais profil.

Firefox – un tout autre monde

Firefox n'utilise pas LevelDB. Il stocke les données des extensions dans IndexedDB, que Firefox implémente en s'appuyant sur SQLite. L'identifiant de l'extension est webextension@metamask.io, mais Firefox attribue un identifiant UUID interne unique à chaque installation – quelque chose comme 196319ec-3a5e-4efe-9413-c327a770d874. Vous le trouverez à l'adresse suivante : about:debugging sous « Ce Firefox ».

Les données se trouvent à l'adresse suivante :

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/

À l'intérieur du idb/ dossier, vous trouverez des fichiers binaires portant des noms numériques. Il s'agit de Compressé au format Snappy – on ne peut pas simplement les parcourir avec grep comme on le ferait avec des fichiers LevelDB. Il faut d'abord les décompresser à l'aide d'un outil tel que snappy-fox avant que les données du coffre-fort ne puissent être extraites. C'est l'erreur la plus courante que je constate lors de la récupération de données dans Firefox : les utilisateurs ouvrent le fichier binaire, voient des données illisibles mêlées à des fragments de texte reconnaissables, et en concluent que le coffre-fort est corrompu. Ce n'est pas le cas. Il est simplement compressé.

Avant Firefox 63, le stockage des extensions utilisait un simple fichier JSON nommé storage.js dans le répertoire des profils. Si vous restaurez une installation très ancienne, recherchez storage.js ou storage.js.migrated.

LevelDB et le fichier 0001.ldb dont tout le monde parle

LevelDB est le moteur de stockage clé-valeur de Google, et il est essentiel de bien comprendre sa structure de fichiers pour pouvoir restaurer MetaMask sur n'importe quel navigateur Chromium.

Un répertoire LevelDB de MetaMask contient plusieurs types de fichiers. Le .ldb fichiers Les tables de chaînes triées (ou SSTables) constituent un système de stockage permanent et trié de paires clé-valeur. .log fichiers sont le journal d'écriture anticipée (Write-Ahead Log) – une mémoire tampon temporaire contenant les écritures récentes avant qu'elles ne soient transférées vers .ldb fichiers. Il y a un MANIFEST-###### métadonnées de la base de données de suivi des fichiers, une CURRENT fichier pointant vers le manifeste actif, et un LOCK fichier empêchant les accès simultanés.

Les données du coffre-fort sont généralement stockées dans un à faible numéro .ldb fichier - 000003.ldb, 000005.ldb, ou quelque chose de similaire. La documentation de MetaMask précise : « Il doit s'agir d'une valeur numérique faible. Si le nombre est élevé, ce n'est pas le coffre-fort. » Le 0001.ldb fichier (ou 000001.ldb) est l'un des tout premiers fichiers SSTable créés lors de la première initialisation de MetaMask. Il contient souvent le coffre-fort d'origine enregistré lors de la création du portefeuille.

Extraction des données du coffre-fort à partir de .ldb fichiers C'est généralement très simple sur Chromium. Ouvrez le fichier dans un éditeur de texte (Sublime Text, VS Code, voire Notepad++) et recherchez la chaîne vault. Vous trouverez le bloc JSON chiffré intégré à la structure d'enregistrement LevelDB. Copiez tout ce qui se trouve à partir de {"data":" jusqu'à la clôture "} – c'est ton coffre-fort.

Sur Mac ou Linux, cette ligne de commande suffit :

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

À surveiller : .ldb les fichiers peuvent utiliser Compression rapide sur les blocs de données. Si la recherche de chaînes échoue et que vous voyez des blocs de données binaires aléatoires, le bloc de données dont vous avez besoin est peut-être compressé au format Snappy. Le .log fichier, en revanche, est toujours non compressé : il s'agit de données brutes de type clé-valeur organisées en blocs de 32 Ko. Si le .ldb si cette approche échoue, Vérifiez toujours le .log fichier. La documentation officielle de MetaMask indique ce qui suit : « Si vous ne parvenez pas à récupérer votre coffre-fort à l'aide du fichier .ldb, vérifiez s'il existe un fichier .log. »

Une fonctionnalité de LevelDB extrêmement utile pour la restauration : c'est en ajout seul. Les mises à jour et les suppressions ne modifient pas les enregistrements existants : elles ajoutent de nouvelles entrées avec des numéros de séquence plus élevés. Les anciens enregistrements sont conservés jusqu’à ce qu’une opération de compactage les fusionne. Cela signifie que si quelqu’un a importé un nouveau SRP par-dessus un ancien, les anciennes données du coffre-fort peuvent encore exister dans une version plus ancienne .ldb fichier qui n'a pas encore été compressé. J'ai déjà réussi à récupérer des portefeuilles « écrasés » de cette manière à plusieurs reprises.

Pour l'extraction programmatique, le btcrecover Le projet comprend extract-metamask-vaults.py, qui lit correctement la base de données LevelDB et extrait toutes les entrées du coffre-fort – y compris celles, potentiellement anciennes, qui se cachent dans des fichiers non compactés. Le cyclone-github/metamask_extractor Cet outil fait la même chose et peut générer directement un fichier au format compatible avec Hashcat.

Lorsque les fichiers du coffre-fort sont endommagés

La corruption du coffre-fort est généralement due à l'une des causes suivantes : un plantage du navigateur pendant une opération d'écriture (coupure de courant, panique du noyau, fermeture forcée), une mise à jour de MetaMask interrompue qui réécrit le stockage en cours de processus, des erreurs de disque réelles (secteurs défectueux, usure du SSD) ou, de plus en plus souvent, un logiciel antivirus qui met en quarantaine les fichiers JavaScript de MetaMask, ce qui peut laisser la base de données LevelDB dans un état incohérent même si les données du coffre-fort elles-mêmes sont intactes.

Vous savez que votre coffre-fort est corrompu lorsque le fichier JSON ne peut pas être analysé. Il manque des accolades, des chaînes Base64 sont tronquées, des octets nuls se sont glissés au milieu du champ de données. Le MetaMask Vault Decryptor affichera le message « Problème lors du décodage du coffre-fort » ou échouera tout simplement sans rien signaler.

La récupération dépend du type et de l'étendue de la corruption. Si la structure JSON est endommagée mais que les données chiffrées sont globalement intactes, il est souvent possible de reconstruire la voûte manuellement. Le format est strict : il faut exactement le data, iv, et salt champs (ainsi que keyMetadata (pour les coffres-forts plus récents). Supprimez les octets nuls et les caractères de contrôle. Vérifiez que le data, iv, et salt les valeurs sont au format Base64 valide. Si le data Si le champ est tronqué, vous allez avoir des problèmes – AES-GCM nécessite le texte chiffré complet ainsi que son jeton d'authentification (les 16 derniers octets du data (champ) pour le déchiffrer. Il suffit qu'un seul octet manque pour que tout échoue.

Pour les bases de données LevelDB partiellement endommagées où le .ldb Si les fichiers eux-mêmes sont endommagés, essayez de lire le .log fichier à la place : son format est plus simple (blocs séquentiels de 32 Ko avec des en-têtes de 7 octets) et il peut contenir une copie plus récente du coffre-fort qui a survécu à l'incident de corruption. Si aucune de ces deux approches ne fonctionne, vous pouvez parfois utiliser des bibliothèques Python de parsing LevelDB (CCL Solutions Group a publié des implémentations purement Python pour le parsing LevelDB, la décompression Snappy et la désérialisation V8) afin d'extraire avec précision des enregistrements à partir de fichiers de base de données endommagés, en ignorant les blocs corrompus.

Plusieurs SRP peuvent coexister dans un même répertoire LevelDB. Si un utilisateur a importé une nouvelle phrase de récupération, l'ancienne entrée du coffre-fort peut subsister dans un répertoire distinct .ldb fichier ou même au sein du même fichier à un autre emplacement. Recherchez toujours toutes les instances de la séquence de chiffres, et pas seulement le premier.

Le problème des fichiers écrasés et comment y remédier

C'est le scénario le plus déchirant. Quelqu'un désinstalle MetaMask – peut-être pour résoudre un problème, peut-être pour « nettoyer » son navigateur, peut-être sans se rendre compte de ce qu'il faisait. Sur les navigateurs Chromium, la désinstallation d'une extension supprime l'intégralité du dossier de données de l'extension, y compris tous les .ldb, .log, ainsi que les fichiers manifest. Sur Firefox, le moz-extension+++<UUID> Le dossier est supprimé, et comme chaque réinstallation génère un nouvel UUID, la nouvelle installation n'affectera pas l'ancien emplacement (mais celui-ci a disparu).

La documentation de MetaMask est très claire à ce sujet : « Les données de l'extension de navigateur sont supprimées lorsque celle-ci est désinstallée. En général, cela signifie que les données de votre coffre-fort sont perdues. »

Ce mot « généralement » a une grande importance. Les données sont logiquement supprimées – le système de fichiers marque ces secteurs comme libres –, mais les octets ne sont pas immédiatement mis à zéro. Sur un disque dur traditionnel, les données persistent jusqu’à ce que ces secteurs soient réutilisés par de nouveaux fichiers. Sur un SSD, les commandes TRIM peuvent rendre les données supprimées irrécupérables en quelques minutes, voire en quelques secondes.

Première règle pour récupérer un coffre-fort écrasé : cessez immédiatement d'utiliser l'ordinateur. Tout nouveau fichier enregistré sur le disque risque d'écraser les secteurs où se trouvait votre coffre-fort. Si possible, retirez le disque et montez-le en lecture seule sur un autre ordinateur.

Outils de récupération pour ce cas de figure, par ordre de préférence :

  • Notre logiciel sur mesure (multiplateforme) pour la récupération de fichiers supprimés logiquement
  • extundelete ou ext4magic pour les systèmes de fichiers ext3/ext4 sous Linux
  • Recherche sur le disque brut en dernier recours : grep -rboa "vault" /dev/sdX pour analyser le périphérique de disque brut à la recherche de chaînes de coffre-fort
  • Nos outils sur mesure pour la récupération de fichiers lorsque les métadonnées du système de fichiers ont disparu – configurez-le pour rechercher {"data":" motifs

J'ai déjà réussi à récupérer des coffres-forts sur des disques durs qui avaient été désinstallés plusieurs semaines auparavant. Sur les SSD, le taux de réussite chute considérablement après seulement quelques heures d'utilisation continue. Réinstaller MetaMask est la pire chose que vous puissiez faire, car cela crée une nouvelle base de données LevelDB dans le même répertoire, ce qui risque d'écraser les anciens secteurs.

Firefox présente ici un avantage. Étant donné que chaque installation se voit attribuer un nouvel UUID, la réinstallation crée des fichiers dans un nouveau chemin d'accès. L'ancien moz-extension+++<OLD-UUID> les données, même si le dossier a été supprimé, ne seront pas écrasées par les fichiers de la nouvelle installation. Il existe également deux paramètres cachés de Firefox – extensions.webextensions.keepUuidOnUninstall et extensions.webextensions.keepStorageOnUninstall – qui, s'il est réglé sur true dans about:config Avant la désinstallation, empêchez le navigateur d'effacer la mémoire de l'extension. Mais personne ne configure ces paramètres de manière proactive.

MetaMask sur mobile, c'est une tout autre histoire

L'application mobile MetaMask est développée avec React Native et stocke les données d'une manière totalement différente de l'extension de navigateur. Le coffre-fort crypté passe par @react-native-async-storage/async-storage, qui utilise des backends spécifiques à chaque plateforme.

Sur Android, AsyncStorage écrit généralement dans un Base de données SQLite à /data/data/io.metamask/databases/RKStorage. Ce chemin d'accès nécessite des droits d'administrateur pour permettre la lecture directe. Le chiffrement du coffre-fort utilise la même méthode de génération de clés dérivées de PBKDF2, mais présente des différences importantes par rapport à l'extension pour ordinateur : l'application mobile n'utilise traditionnellement que 5 000 itérations PBKDF2 et crypte avec AES-CBC au lieu de l'AES-GCM. Cela signifie que les coffres-forts mobiles ne sont pas interchangeables avec les coffres-forts de bureau, même si le mot de passe est identique.

Sur iOS, les données sont stockées dans le bac à sable de l'application sous <AppSandbox>/Documents/. Pour la restauration d'une sauvegarde iCloud, le chemin d'accès est le suivant : Apps → MetaMask → Documents → persistStore → persist-root – vous aurez besoin d'un outil tel qu'iMazing pour parcourir une sauvegarde iOS sur un Mac. Le bon fonctionnement de cette méthode dépend du fait que l'utilisateur ait activé la sauvegarde iCloud alors que MetaMask était en cours d'utilisation ; par ailleurs, des modifications apportées par Apple auraient rendu cette méthode intermittente.

L'application mobile MetaMask intègre également une SecureKeychain module (basé sur react-native-keychain) qui stocke le mot de passe du portefeuille de l'utilisateur dans le trousseau iOS ou le Keystore Android pour le déverrouillage biométrique. Un audit de sécurité a révélé que SecureKeychain ajoute une couche de chiffrement supplémentaire à l'aide d'un sel « foxCode » – qui s'est avéré être une chaîne de caractères codée en dur "encrypt". L'équipe de MetaMask a reconnu qu'il s'agissait d'une stratégie de défense en profondeur plutôt que d'un secret essentiel à la sécurité.

Le principal défi lié à la récupération des données sur les appareils mobiles réside dans le fait que il n'y a pas d'extraction manuelle du coffre-fort revient à trouver .ldb fichiers sur le bureau. Vous ne pouvez pas vous connecter à votre iPhone via SSH pour rechercher des chaînes de caractères dans le coffre-fort. À partir de MetaMask mobile v6.3.0, l'application intègre une fonctionnalité de restauration automatique du coffre-fort qui se déclenche dès qu'une corruption est détectée ; toutefois, si l'application est supprimée, les données locales du coffre-fort sont perdues, sauf si vous disposez d'une sauvegarde de l'appareil. Les mécanismes de sauvegarde d'Android ne sont pas particulièrement fiables pour conserver l'intégralité des données internes des applications. La position officielle de MetaMask est de recommander de transférer les données vers un nouveau SRP plutôt que de compter sur la fonctionnalité de récupération du coffre-fort Android.

La modification du nombre d'itérations de l'algorithme PBKDF2 qui a rendu inopérants tous les outils de récupération

Pendant des années, MetaMask a utilisé 10 000 itérations PBKDF2 – la valeur par défaut fixée en dur dans le browser-passworder bibliothèque. Chaque outil de récupération, chaque module Hashcat, chaque script de force brute avait été configuré pour 10 000 itérations. Puis, fin 2023 / début 2024, tout a changé.

Le @metamask/browser-passworder La version 4.2.0 de la bibliothèque (publiée le 13 novembre 2023) a introduit la prise en charge d'options configurables pour la dérivation des clés. La nouvelle valeur par défaut de la bibliothèque est passée à 900 000 itérations, mais l'extension MetaMask l'a configurée pour utiliser 600 000 itérations – conformément à la recommandation 2023 de l'OWASP concernant PBKDF2-HMAC-SHA256. Par l'extension MetaMask v11.16.11 (comme l'a confirmé un numéro de Hashcat de juin 2024), de nouveaux coffres-forts étaient créés avec 600 000 itérations et le nouveau keyMetadata champ.

Cela représente une multiplication par 60 du coût de calcul par tentative de mot de passe. Une attaque par force brute qui prenait une journée avec 10 000 itérations prend désormais deux mois avec 600 000 itérations sur le même matériel. La communauté Hashcat a dû développer des noyaux personnalisés – le mode 26620, proposé par cyclone – pour prendre en charge ce nouveau format. Le mode standard 26600 comportait 10 000 itérations codées en dur.

Il est important de noter que les anciennes clés de chiffrement ne sont PAS automatiquement rechiffrées. Si vous avez créé votre portefeuille en 2021, votre coffre-fort utilise toujours 10 000 itérations, à moins que MetaMask n'ait explicitement déclenché un nouveau chiffrement (le updateVault Il existe une fonction prévue à cet effet, mais on ne sait pas exactement à quelle fréquence MetaMask l'appelle lors du déverrouillage. Vous pouvez déterminer de quelle version il s'agit en vérifiant la présence ou l'absence de la keyMetadata champ. Non keyMetadata? Ça fait 10 000 itérations. A-t-il keyMetadata avec "iterations": 600000? C'est le nouveau format.

Voici la chronologie complète des versions des bibliothèques de chiffrement pertinentes pour la restauration :

  • browser-passworder v1.x–v2.x (avant 2022) : 10 000 itérations, valeur fixe. Publié sans le @metamask champ d'application.
  • v3.0.0 (août 2022) : Rebaptisé @metamask/browser-passworder. Aucun changement d'itération.
  • v4.2.0 (Novembre 2023) : Ajouté keyMetadata prise en charge. Le nombre d'itérations par défaut pour le chiffrement a été porté à 900 000. keyFromPassword rétrocompatible à 10 000.
  • v4.3.0 (Novembre 2023) : Ajouté isVaultUpdated pour vérifier si le coffre-fort respecte les paramètres cibles.
  • v5.0.0 (avril 2024) : Node.js v16 requis au minimum. Aucune modification concernant la cryptographie.
  • v6.0.0 (décembre 2024) : Node.js v18.18 requis au minimum. Aucune modification concernant la cryptographie.

À l'attention des spécialistes de la récupération : vérifiez toujours le format du coffre-fort en premier lieu. C'est lui qui détermine toute votre approche.

La politique de MetaMask en matière de mots de passe et ses implications pour les attaques par force brute

MetaMask impose une longueur minimale de 8 caractères pour les mots de passe. C'est tout. Pas d'obligation d'utiliser des majuscules, pas de chiffres, pas de caractères spéciaux. L'extension affiche un indicateur visuel de robustesse (« Faible » / « Bon »), mais ne bloque pas les mots de passe faibles qui respectent la longueur minimale. Il n'y a pas non plus de longueur maximale – les caractères Unicode sont pris en charge. Cette politique est en vigueur depuis au moins début 2018 (référencée dans le ticket GitHub n° 3515).

Plusieurs sites tiers affirment à tort que MetaMask exige l'utilisation de majuscules, de minuscules, de chiffres et de caractères spéciaux. C'est faux. La seule exigence impérative est que le mot de passe comporte 8 caractères.

Pour la récupération par force brute, cela a une importance considérable. Un mot de passe de 8 caractères composé uniquement de minuscules offre un espace de clés d'environ 208 milliards de combinaisons (26^8). Face à un ancien coffre-fort comportant 10 000 itérations, hashcat, sur un GPU moderne, peut tester des milliers de hachages par seconde, ce qui rend le mot de passe piratable en quelques jours. Face à un coffre-fort comportant 600 000 itérations, il faut multiplier ce temps par 60. Un mot de passe fort de plus de 12 caractères, mélangeant majuscules, minuscules et symboles ? Pratiquement inviolable contre l'un ou l'autre format avec le matériel actuel.

L'outil de récupération pratique de choix est btcrecover – MetaMask le recommande d'ailleurs aux utilisateurs qui ont une idée approximative de leur mot de passe. Il prend en charge la devinette par jetons et par schéma, ce qui vous permet de définir un modèle tel que "my" + [dog|cat|bird] + [2019|2020|2021] + ["!"|"@"|"#"] et tester efficacement toutes les permutations. Pour les attaques accélérées par GPU, le mode 26600 de hashcat prend en charge les anciens coffres-forts, le mode 26610 les coffres-forts mobiles, et le mode 26620 (ou une version 26600 recompilée avec des itérations mises à jour) le nouveau format à 600 000 itérations.

Les circuits de détournement et le fléau des « fonds manquants »

C'est souvent au niveau du chemin de dérivation que se situent les problèmes liés à la disparition des fonds. MetaMask utilise le chemin standard BIP-44 pour Ethereum : m/44'/60'/0'/0. Les comptes sont calculés en incrémentant l'indice final : m/44'/60'/0'/0/0 (premier récit), m/44'/60'/0'/0/1 (deuxièmement), m/44'/60'/0'/0/2 (troisième), et ainsi de suite. Cette procédure s'applique à toutes les chaînes compatibles EVM : la même adresse est utilisée sur Ethereum, Polygon, Arbitrum et BSC.

Le problème, c'est que tout le monde n'utilise pas le même chemin. Ledger Live utilisations m/44'/60'/x'/0/0, en incrémentant le account champ au lieu du address_index. L'héritage de Ledger (l'ancien chemin MEW/MyCrypto) utilise m/44'/60'/0'/x – seulement quatre niveaux au lieu de cinq. La première adresse (m/44'/60'/0'/0/0) est identique sur MetaMask, Ledger Live et Trezor. Mais le le deuxième récit et les suivants divergent complètement, car chaque portefeuille incrémente un élément différent du chemin d'accès.

Cela donne lieu à un scénario d'échec très particulier : une personne restaure la phrase de récupération de son Ledger dans MetaMask, voit son premier compte et son solde, puis ajoute un deuxième compte et constate… zéro. Les fonds n'ont pas disparu. Ils se trouvent à l'adresse dérivée de m/44'/60'/1'/0/0 (à la manière de Ledger Live), mais MetaMask envisage m/44'/60'/0'/0/1. Des clés totalement différentes, des adresses totalement différentes.

Chemin de dérivation Ethereum par défaut de Trezor correspond à celles de MetaMask : m/44'/60'/0'/0/x. La restauration d'un compte Trezor vers MetaMask fonctionne donc généralement pour tous les comptes. Les problèmes de compatibilité entre portefeuilles concernent principalement les combinaisons Ledger ↔ MetaMask et Ledger ↔ Trezor.

Pour trouver des fonds sur une « mauvaise » voie de dérivation, vous avez les options suivantes :

  • Écrivez-nous à l'adresse contact@cryptorecovery.io et nous ferons de notre mieux pour vous aider.
  • MyEtherWallet (MEW): Prend en charge les chemins de dérivation personnalisés via « Ajouter un chemin ». Saisissez manuellement m/44'/60'/1'/0/0, m/44'/60'/2'/0/0, etc. pour vérifier les adresses de type Ledger Live.
  • MyCrypto: prise en charge similaire des chemins de dérivation personnalisés.
  • L'outil BIP-39 de Ian Coleman (à exécuter hors ligne) : saisissez la phrase mnémonique, sélectionnez ETH, passez d'un onglet BIP-44 à l'autre et modifiez manuellement les éléments du chemin d'accès.
  • btcrecover: Permet d'automatiser les tests sur différents schémas de chemins de dérivation.

Une limitation frustrante : l'intégration de Trezor dans MetaMask ne prend pas en charge les chemins de dérivation personnalisés. Une option de chemin de dérivation personnalisé a été intégrée pour Ledger (PR #9367), mais d'après les dernières informations, l'équivalent pour Trezor (GitHub issue #11197) reste en suspens. Si vous essayez d'accéder à des comptes dérivés de Ledger via MetaMask + Trezor, vous devrez utiliser MEW ou MyCrypto à la place.

MetaMask et Trezor : un mariage difficile

L'intégration MetaMask-Trezor fonctionne via Trezor Bridge – un processus d'arrière-plan installé localement (trezord) qui écoute sur http://127.0.0.1:21325/ et comble le fossé entre le bac à sable du navigateur et l'accès au matériel USB. Vous pouvez vérifier s'il est en cours d'exécution en appuyant sur http://127.0.0.1:21325/status/.

Le problème le plus courant est d'une simplicité trompeuse : Trezor Suite est ouverte. Trezor Suite verrouille la connexion USB avec l'appareil, empêchant ainsi MetaMask de communiquer. Vous devez quitter complètement Suite – il ne suffit pas de la réduire, mais de la fermer depuis la barre d'état système. J'estime que cela représente environ 40 % des tickets « MetaMask ne détecte pas mon Trezor » que j'ai vus.

Autres problèmes courants et leurs solutions :

« À la recherche de votre Trezor… » tourne en boucle – Vérifiez que Bridge est installé et trezord est en cours d'exécution. Essayez un autre câble USB et un autre port. Désactivez le VPN, le pare-feu et les extensions de navigateur (les bloqueurs de publicités et les extensions de confidentialité causent souvent des interférences). Le mode de navigation privée permet d'éviter les conflits entre extensions.

« Connexion en cours » – Une autre application ou un autre onglet de navigateur est déjà en communication avec le Trezor. Fermez tous les autres onglets et applications susceptibles d'accéder à l'appareil.

Limites de WebUSB – Firefox ne prend absolument pas en charge WebUSB, ce qui signifie que la connectivité de Trezor sur Firefox repose entièrement sur Bridge. Chrome, Brave et Edge fonctionnent grâce à l'implémentation WebUSB/WebHID de Chromium.

Avertissement concernant le chemin de dérivation sur le Trezor Safe 5 – Des utilisateurs signalent l'apparition du message « Chemin de dérivation incorrect pour le compte sélectionné. m/44’/60’/0’/0 » sur l'écran du Trezor lors de la validation d'une transaction. Cet avertissement peut généralement être ignoré sans risque: le portefeuille fonctionne correctement malgré ce message. Il s'agit d'un problème purement esthétique lié à la manière dont le micrologiciel du Trezor valide les chemins qui ne respectent pas la norme.

En 2025, Trezor a commencé à intégrer les fonctionnalités de Bridge directement dans Trezor Suite. Cette transition a entraîné une série de problèmes de connectivité, car certains utilisateurs devaient laisser Trezor Suite tourner en arrière-plan pour se connecter à MetaMask, tandis que d'autres devaient la fermer complètement. Rendez-vous dans Trezor Suite → Paramètres → Application → Trezor Connect pour trouver la configuration appropriée.

Lorsque MetaMask se connecte à un Trezor, les comptes ainsi créés sont fondamentalement différents des comptes du portefeuille logiciel MetaMask. Les comptes dérivés de Trezor ne stockent que les clés publiques et les chemins de dérivation dans le coffre-fort ; les clés privées restent sur le dispositif matériel. MetaMask peut afficher les soldes (en lecture seule via les clés publiques) sans que le Trezor soit connecté, mais ne peut pas signer de transactions sans la présence physique de l'appareil. Si une phrase de passe a été utilisée lors de la création des comptes Trezor, il faut saisir exactement la même phrase de passe pour régénérer les mêmes adresses.

Des techniques de récupération qui s'avèrent efficaces dans la pratique

Après avoir effectué des centaines de récupérations de données, voici les situations que je rencontre le plus souvent et comment je les gère.

Scénario 1 : Mot de passe disponible, phrase de récupération perdue, extension toujours installée

C'est très simple. Ouvrez la page d'arrière-plan de MetaMask via chrome://extensions → Mode développeur → cliquez sur « service worker » (MV3) ou « page d'arrière-plan » (MV2). Dans la console :

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

Copiez le fichier JSON du coffre-fort, puis collez-le dans le Déschiffreur MetaMask Vault (metamask.github.io/vault-decryptor), saisissez votre mot de passe, et l'outil affichera votre phrase mnémonique ainsi que toutes les clés privées importées. Le Vault Decryptor a été développé par Dan Finlay, cofondateur de MetaMask – il prend également en charge .ldb fichiers directement via le téléchargement de fichiers.

Scénario 2 : Mot de passe disponible, l'extension a été désinstallée mais des données pourraient encore se trouver sur le disque

Accédez au répertoire de données de l'extension. Si le dossier existe toujours (il arrive parfois que la désinstallation ne parvienne pas à tout supprimer, ou que l'utilisateur ait simplement désactivé l'extension au lieu de la supprimer), récupérez le .ldb et .log fichiers. Extrayez le contenu du coffre-fort à l'aide de grep, d'un éditeur de texte ou btcrecover’s extract-metamask-vaults.py. Décryptez les fichiers à l'aide du Vault Decryptor.

Si le dossier a disparu, contactez-nous à l'adresse contact@cryptorecovery.io et nous vous aiderons à effectuer une analyse informatique du disque.

Vous pouvez également monter le disque en lecture seule et effectuer des recherches brutes sur le disque pour trouver des chaînes de caractères spécifiques. Sous Linux : grep -rboa '{"data":"' /dev/sdX. Le succès dépend en grande partie de l'activité du disque qui a eu lieu après la suppression et du type de disque (SSD ou HDD).

Scénario 3 : Mot de passe oublié, mais je dispose du fichier du coffre-fort

Il s'agit d'une attaque par force brute. Extrayez le fichier de chiffrement, puis convertissez-le au format hashcat à l'aide de metamask2hashcat.py ou cyclone-github/metamask_extractor. Lancez ensuite hashcat (mode 26600 pour les anciens coffres-forts, 26620 pour les nouveaux) ou btcrecover avec un fichier de jetons décrivant ce dont vous vous souvenez concernant le mot de passe. Si vous savez que votre mot de passe était quelque chose comme « myDog » suivi d'une année et d'un symbole, btcrecover peut tester ces combinaisons efficacement.

Scénario 4 : Récupération de Firefox

Retrouvez l'UUID de MetaMask à l'adresse about:debugging. Accédez au répertoire de stockage. Décompressez les fichiers binaires IndexedDB à l'aide de snappy-fox:

./snappy-fox input_file.snappy output.txt

Recherchez le fichier JSON du coffre-fort dans les données décompressées. Poursuivez ensuite avec le Vault Decryptor. Le JesseBusman/FirefoxMetamaskWalletSeedRecovery Ce script Python automatise l'ensemble du processus : il analyse le profil Firefox, identifie les données du coffre-fort et génère un fichier JSON formaté, prêt à être déchiffré.

Scénario 5 : Des fonds semblent manquer après l'importation des fonds de démarrage

Vérifiez les chemins de dérivation. Si vous importez une graine Ledger dans MetaMask, le deuxième compte et les suivants afficheront des adresses différentes et des soldes nuls. Utilisez MEW ou MyCrypto avec des chemins de dérivation personnalisés pour localiser vos fonds dans Ledger Live (m/44'/60'/x'/0/0) ou Ledger Legacy (m/44'/60'/0'/x) chemins d'accès. Si une phrase de passe Trezor a été utilisée, assurez-vous de saisir exactement la même phrase de passe : une phrase de passe différente génère un ensemble d'adresses totalement différent à partir de la même graine.

Les outils d'investigation à avoir dans sa trousse

  • Déschiffreur MetaMask Vault – officiel, fonctionne hors ligne, prend en charge la connexion directe .ldb téléchargement de fichiers
  • btcrecover – récupération de mot de passe par correspondance de motifs, recommandé par MetaMask
  • hashcat – Attaque par force brute accélérée par GPU (modes 26600, 26610, 26620)
  • snappy-fox – Décompression rapide pour Firefox
  • Outils Python de CCL Solutions Group: analyse syntaxique de LevelDB en Python pur, décompression Snappy, désérialisation V8

Conclusion : ce qui distingue les reprises réussies des échecs

La différence entre récupérer son portefeuille et le perdre définitivement tient presque toujours à ce qui s'est passé dans les premières minutes qui ont suivi la découverte du problème. L'action la plus néfaste consiste à réinstaller MetaMask sur le même profil de navigateur : cela écrase le répertoire LevelDB avec de nouveaux fichiers. La deuxième action la plus néfaste est de continuer à utiliser normalement l'ordinateur sur un SSD après la suppression du coffre-fort, ce qui déclenche la fonction TRIM et rend impossible toute récupération au niveau des secteurs.

Si vous devez retenir trois choses de ce guide : sauvegardez votre phrase de récupération sur papier, sachez que votre coffre-fort se trouve dans un dossier spécifique que vous pouvez copier et conserver, et si un problème survient, cessez immédiatement d'utiliser cet ordinateur avant de tenter toute opération de récupération. Le chiffrement est solide – l'AES-256-GCM avec 600 000 itérations PBKDF2 ne peut pas être forcé par une attaque par force brute à moins que le mot de passe ne soit faible – mais les données elles-mêmes sont étonnamment fragiles. Il ne s'agit que de quelques kilo-octets dans une base de données LevelDB, et elles peuvent disparaître d'un simple clic de nettoyage du navigateur.

Tous les portefeuilles que je n'ai pas réussi à récupérer avaient la même cause profonde : l'utilisateur a continué à utiliser l'appareil après la perte des données. Tous les portefeuilles que j'ai réussi à récupérer étaient ceux dont les données se trouvaient encore sur le disque – parfois à des endroits inattendus, parfois en plusieurs exemplaires grâce à l'architecture « append-only » de LevelDB, mais toujours parce que quelqu'un avait pris le temps de réfléchir avant d'agir.

Si vous avez besoin d'aide pour récupérer votre portefeuille MetaMask, contactez-nous par e-mail : contact@cryptorecovery.io pour bénéficier d'une consultation professionnelle et gratuite, ou rendez-vous sur notre page de contact