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

Si vous lisez ces lignes, c’est probablement que vous avez perdu l’accès à votre portefeuille MetaMask et que vous êtes à court de solutions. J’ai passé des années à récupérer des portefeuilles pour des utilisateurs – qu’il s’agisse de traders DeFi ayant reformaté leur ordinateur portable ou de grands-parents ayant « nettoyé » les extensions de leur navigateur. Ce guide couvre tout ce que je sais sur la manière dont MetaMask stocke vos clés, l’emplacement exact de ces données sur le disque dur, et comment les récupérer en cas de problème. Rien de tout cela n’est théorique. Chaque technique présentée ici est issue 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é le chambre forte, qui se trouve dans l’espace de stockage 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 coulisses. 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 – ainsi que 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 avec 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 chiffré 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 existe 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 autre 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 à la norme – 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 valeur).

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 caractères chiffrée du coffre-fort à partir du stockage persistant, puis la transmet à browser-passworder’s decrypt fonction qui analyse le JSON, extrait le sel, calcule la clé à l’aide de PBKDF2 avec les mêmes paramètres, déchiffre à l’aide d’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 trousseaux de 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 périphérique matériel).

Avec Manifest V3 (l’architecture de service worker que Chrome a mise en place à partir de 2023), MetaMask a ajouté la possibilité de mettre en cache la clé de chiffrement sous la forme d’un fichier JWK exporté, afin de pouvoir déchiffrer à nouveau le coffre-fort lors du redémarrage du service worker sans avoir à 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 ont leur importance pour la récupération.

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

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

Identifiant de l’extension Chrome est nkbihfbeogaeaoehlefnkodbefgpgknn – gravé dans la mémoire de chaque spécialiste de la réadaptation. Courageux utilise le même identifiant puisqu’il s’installe depuis le Chrome Web Store. Edge reçoit son propre identifiant s’il est installé à partir de la boutique d’extensions d’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 sous 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 Windows Store) :
C:\Users\<USER>\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\ejbalbakoplchlghecdalmeeeajnimhm\

Un détail essentiel : 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 à consulter 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 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/ Dans ce 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 la structure de ses 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 il y a 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é, il ne s’agit pas du 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 d’origine créé 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 sous Chromium. Ouvrez le fichier dans un éditeur de texte (Sublime Text, VS Code, voire Notepad++) et recherchez la chaîne vault. Vous trouverez le blob 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

Un point à surveiller : .ldb les fichiers peuvent utiliser Compression rapide sur les blocs de données. Si la recherche de chaîne échoue et que vous constatez la présence de 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 Le fichier, en revanche, n’est jamais 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 précise 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 ajout uniquement. 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 cacheraient dans des fichiers non compactés. Le cyclone-github/metamask_extractor Cet outil fait la même chose et permet d’exporter directement au format compatible avec hashcat.

Lorsque les fichiers du coffre-fort sont endommagés

La corruption du coffre-fort trouve généralement son origine dans l’une des causes suivantes : un plantage du navigateur lors d’une opération d’écriture (coupure de courant, « kernel panic », fermeture forcée), une mise à jour de MetaMask interrompue qui réécrit le stockage en cours de processus, des erreurs réelles du disque (secteurs défectueux, usure du SSD) ou, cas de plus en plus fréquent, la mise en quarantaine par un logiciel antivirus des 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 peut s’agir d’accolades manquantes, de chaînes Base64 tronquées ou d’octets nuls insérés au milieu du champ de données. Le décrypteur de coffre-fort MetaMask affichera le message « Problème lors du décodage du coffre-fort » ou échouera simplement sans afficher de message d’erreur.

La récupération dépend du type et de l’ampleur de la corruption. Si la structure JSON est endommagée mais que les données chiffrées sont pour l’essentiel intactes, il est souvent possible de reconstruire la voûte manuellement. Le format est rigide : il faut exactement le data, iv, et salt champs (plus 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 l’opération é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 d’analyse de LevelDB (CCL Solutions Group a publié des implémentations entièrement en Python pour l’analyse de 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 départ, l’ancienne entrée du coffre-fort peut subsister dans un fichier distinct .ldb fichier, voire au sein d’un 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 qui cause le plus de déception. Quelqu’un désinstalle MetaMask – peut-être dans le cadre d’un dépannage, 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 officielle 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 » revêt 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 adaptés à ce scénario, classés par ordre de priorité :

• Notre logiciel sur mesure (multiplateforme) dédié à la récupération des fichiers supprimés de manière logique
• 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 disque brut à la recherche de chaînes de caractères « vault »
• 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 qu’il recherche {"data":" motifs

J’ai déjà réussi à récupérer des coffres à partir de 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 chiffré 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 approche basée sur une clé dérivée de PBKDF2, mais présente des différences importantes par rapport à l’extension pour ordinateur de bureau : l’application mobile n’utilise traditionnellement que 5 000 itérations PBKDF2 et crypte à l’aide de 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 correspondant est 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 actif ; par ailleurs, des modifications apportées par Apple auraient rendu cette approche 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 Keychain d’iOS ou le Keystore d’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 la 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 mobile réside dans le fait que il n’y a pas d’extraction manuelle du coffre-fort ce qui revient à trouver .ldb fichiers sur le bureau. Vous ne pouvez pas vous connecter à votre iPhone via SSH et rechercher des chaînes de caractères dans le coffre-fort à l’aide de grep. À 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 votre appareil. Les mécanismes de sauvegarde d’Android sont particulièrement peu fiables pour conserver l’intégralité des données internes des applications. 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 codé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é calibré 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 de dérivation de 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 à 10 000 itérations prend désormais deux mois à 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 anciens coffres-forts ne sont PAS automatiquement rechiffrés. 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. Est-ce que keyMetadata avec "iterations": 600000? C’est le nouveau format.

Voici la chronologie complète des versions des bibliothèques de chiffrement qui ont une incidence sur la récupération :

• browser-passworder v1.x–v2.x (avant 2022) : 10 000 itérations, valeur codée en dur. Publié sans le @metamask champ d’application.
• v3.0.0 (août 2022) : Rebaptisé « @metamask/browser-passworder. Aucun changement au niveau des itérations.
• v4.2.0 (novembre 2023) : Ajouté keyMetadata prise en charge. Le nombre d’itérations par défaut pour le chiffrement a été fixé à 900 000. keyFromPassword compatible avec les versions antérieures à partir de la version 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. Cela 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, ni de chiffres, ni 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 une récupération par force brute, cela revêt une importance capitale. Un mot de passe de 8 caractères composé uniquement de lettres 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, exécuté sur un GPU moderne, peut tester des milliers de hachages par seconde, ce qui permet de le cracker 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 ? Il est pratiquement inviolable contre ces deux formats avec le matériel actuel.

L’outil de récupération pratique de prédilection 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 motifs, 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 recompilée du mode 26600 avec des itérations mises à jour) prend en charge 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 parcours de déduction que se situent la plupart des problèmes liés à la « disparition de mes fonds ». MetaMask utilise le chemin standard BIP-44 pour Ethereum : m/44'/60'/0'/0. Les calculs sont effectué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 d’accès. 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 d’accès 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 entraîne un scénario de défaillance très spécifique : un utilisateur restaure sa phrase de récupération 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 de 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 voie de dérivation « erronée », vous disposez des options suivantes :

• Contactez-nous par e-mail à l’adresse contact@cryptorecovery.io et nous ferons de notre mieux pour vous aider et vous accompagner.
• 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 d’Ian Coleman (à exécuter hors ligne) : saisissez la phrase mnémonique, sélectionnez ETH, basculez entre les onglets BIP-44 et ajustez manuellement les composants du chemin d’accès.
• btcrecover: Permet d’automatiser les tests selon 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 n° 9367), mais d’après les dernières informations, le ticket équivalent pour Trezor (ticket GitHub n° 11197) reste ouvert. 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 motif d’échec 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 parvient pas à détecter mon Trezor » que j’ai pu constater.

Autres problèmes courants et leurs solutions :

« À la recherche de votre Trezor… » : le message tourne en boucle indéfiniment – 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 incognito permet d’éviter les conflits entre extensions.

« Connexion à l’appareil 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é du Trezor sur Firefox repose entièrement sur Bridge. Chrome, Brave et Edge fonctionnent via l’implémentation Chromium de WebUSB/WebHID.

Avertissement concernant le chemin de dérivation du 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 s’exécuter en arrière-plan pour se connecter à MetaMask, tandis que d’autres devaient la fermer complètement. Pour configurer correctement cette option, rendez-vous dans Trezor Suite → Paramètres → Application → Trezor Connect.

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 périphérique 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 de l’appareil physique. 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 fonctionnent réellement 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 la manière dont je les gère.

Scénario 1 : Vous disposez du mot de passe, vous avez perdu votre phrase de récupération, mais l’extension est 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écrypteur 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 fichier .ldb et .log fichiers. Extrayez le 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 à mener une expertise informatique.

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 correspondant à celles du coffre-fort. Sous Linux : grep -rboa '{"data":"' /dev/sdX. La réussite dépend en grande partie du niveau d’activité du disque après la suppression et du type de disque (SSD ou HDD).

Scénario 3 : Mot de passe oublié, vous disposez du fichier de coffre-fort

Il s’agit d’un scénario de 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 efficacement ces combinaisons.

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

Retrouvez l’UUID de MetaMask à l’adresse suivante : 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 Un script Python automatise l’ensemble de ce 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 n° 5 : des fonds semblent manquer après l’importation des graines

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 à ne pas manquer dans votre trousse à outils

• Décrypteur MetaMask Vault – officiel, peut fonctionner hors ligne, prend en charge les connexions directes .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 consiste à continuer d’utiliser normalement son ordinateur équipé d’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 ne devez retenir que 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 – le protocole AES-256-GCM avec 600 000 itérations PBKDF2 ne peut pas être piraté par force brute à moins que le mot de passe ne soit faible –, mais les données elles-mêmes sont étonnamment fragiles. Elles ne représentent que quelques kilo-octets dans une base de données LevelDB et peuvent disparaître d’un simple clic lors du nettoyage de l’historique du navigateur.

Tous les portefeuilles que je n’ai pas réussi à récupérer avaient la même cause première : l’utilisateur avait 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