Como recuperar a carteira MetaMask? Senha perdida, armazenamento do cofre, encriptação e análise forense de dados

Se estás a ler isto, provavelmente perdeste o acesso a uma carteira MetaMask e estás a ficar sem opções. Passei anos a recuperar carteiras para pessoas – desde traders de DeFi que reformataram os seus portáteis até avós que «limparam» as extensões dos seus navegadores. Este guia abrange tudo o que sei sobre como o MetaMask armazena as tuas chaves, onde esses dados se encontram realmente no disco e como os recuperar quando algo corre mal. Nada disto é teórico. Todas as técnicas aqui apresentadas provêm de recuperações reais.

Como é que o MetaMask armazena realmente as suas chaves

Antes de poder recuperar qualquer coisa, é necessário compreender o que está a recuperar. O MetaMask não armazena as suas chaves privadas num ficheiro chamado private_keys.txt. Armazena-os num blob encriptado denominado cofre, que fica armazenado na área de extensões do seu navegador.

Quando cria uma carteira MetaMask e define uma palavra-passe, eis o que acontece nos bastidores. O MetaMask gera uma frase mnemónica BIP-39 (as suas 12 palavras Frase secreta de recuperação) e envolve-a – juntamente com quaisquer chaves privadas importadas – num conjunto JSON de objetos «keyring». Esse conjunto é serializado para uma cadeia de caracteres e, em seguida, encriptado utilizando AES-256-GCM com uma chave derivada da sua palavra-passe através de PBKDF2-HMAC-SHA256. O resultado é um bloco JSON com três ou quatro campos que é gravado em chrome.storage.local (nos navegadores baseados no Chromium) ou IndexedDB (no Firefox).

O cofre encriptado tem este aspeto nas versões mais antigas:

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

E nas versões mais recentes (posteriores à v11.16.x), existe um quarto campo:

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

Isso keyMetadata essa diferença pode significar uma recuperação que demora apenas alguns minutos ou que se prolonga por semanas. Falaremos mais sobre isso em breve.

O processo de encriptação é simples, mas é importante compreendê-lo com precisão. A sua palavra-passe UTF-8 é importada como uma chave PBKDF2 em formato bruto através da API Web Crypto. A Sal aleatório de 32 bytes (gerado a partir de crypto.getRandomValues()) é utilizada em conjunto com a palavra-passe para gerar uma chave AES-GCM de 256 bits. Em seguida, um IV aleatório de 16 bytes encripta os dados serializados do chaveiro. O data O campo contém tanto o texto cifrado como a etiqueta de autenticação GCM, codificados em base64. Uma particularidade que vale a pena referir: o MetaMask utiliza um IV de 16 bytes para AES-GCM, o que não é o padrão – a norma NIST SP 800-38D recomenda 12 bytes. Isto causa problemas de interoperabilidade com algumas bibliotecas de criptografia (o OpenSSL do Ruby, por exemplo, recusa-se a funcionar com este valor).

Quando desbloqueia o MetaMask com a sua palavra-passe, o processo inverte-se. O KeyringController recupera a cadeia de caracteres encriptada do cofre a partir do armazenamento persistente e passa-a para browser-passworderde decrypt função que analisa o JSON, extrai o salt, gera a chave utilizando PBKDF2 com os mesmos parâmetros, descodifica com AES-GCM e deserializa o resultado de volta para objetos de chaveiro. Os chaveiros descodificados ficam apenas na memória – estão armazenados no memStore (um ObservableStore (por exemplo) e nunca são gravadas no disco em texto simples.

Um cofre descodificado contém uma matriz que, normalmente, tem o seguinte aspeto:

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

O HD Key Tree O porta-chaves contém a sua frase mnemónica e o número de contas derivadas. Simple Key Pair As entradas são chaves privadas importadas individualmente. Se tiver ligado carteiras de hardware, também verá Trezor Hardware e Ledger Hardware tipos de porta-chaves – embora estes apenas armazenem caminhos de derivação e endereços públicos, e não chaves privadas (estas permanecem no dispositivo físico).

Com o Manifest V3 (a arquitetura de service workers que o Chrome começou a implementar a partir de 2023), o MetaMask adicionou a capacidade de armazenar em cache a chave de encriptação como um JWK exportado, para que possa desencriptar novamente o cofre quando o service worker for reiniciado, sem solicitar a senha novamente. O encryptionKey e encryptionSalt os campos aparecem em memStore quando cacheEncryptionKey está ativada.

Onde o MetaMask guarda os seus dados em cada plataforma

Encontrar o cofre é metade do caminho andado. O MetaMask armazena os dados em locais diferentes, dependendo do navegador e do sistema operativo, e essas diferenças são importantes para a recuperação.

Navegadores baseados no Chromium (Chrome, Brave, Edge)

Nos navegadores baseados no Chromium, chrome.storage.local persiste em Base de dados LevelDB no disco. O ID da extensão determina o nome da pasta.

ID da extensão do Chrome é nkbihfbeogaeaoehlefnkodbefgpgknn – gravado na memória de todos os especialistas em recuperação. Corajoso utiliza o mesmo ID, uma vez que é instalado a partir da Chrome Web Store. Borda recebe o seu próprio ID se for instalado a partir da Loja de Complementos do Edge: ejbalbakoplchlghecdalmeeeajnimhm. No entanto, se um utilizador tiver instalado o MetaMask no Edge através da Chrome Web Store (que o Edge suporta), este mantém o ID do Chrome. Esta distinção confunde constantemente as pessoas.

Aqui estão os caminhos completos:

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

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

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

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

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

Edge no Windows (instalação a partir da Loja do Edge):
C:\Users\<USER>\AppData\Local\Microsoft\Edge\User Data\Default\Local Extension Settings\ejbalbakoplchlghecdalmeeeajnimhm\

Um pormenor importante: se o utilizador tiver vários perfis do Chrome, substitua Default com Profile 1, Profile 2, etc. Já vi pessoas a procurarem o perfil errado durante horas.

Firefox – uma coisa completamente diferente

O Firefox não utiliza o LevelDB. Armazena os dados das extensões em IndexedDB, que o Firefox implementa com base no SQLite. O ID da extensão é webextension@metamask.io, mas o Firefox atribui um UUID interno único por instalação – algo como 196319ec-3a5e-4efe-9413-c327a770d874. Pode encontrá-lo em about:debugging na secção «Este Firefox».

Os dados encontram-se em:

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/

No interior do idb/ pasta, encontrará ficheiros binários com nomes numéricos. Estes são Comprimido com Snappy – não é possível simplesmente pesquisar neles com o grep, como se fossem ficheiros LevelDB. É necessário descomprimir os ficheiros primeiro, utilizando uma ferramenta como snappy-fox antes de os dados do cofre ficarem disponíveis para extração. Este é o erro mais comum que vejo na recuperação do Firefox: as pessoas abrem o ficheiro binário, veem dados ilegíveis misturados com fragmentos de texto reconhecível e assumem que o cofre está corrompido. Não está. Está comprimido.

Antes do Firefox 63, o armazenamento de extensões utilizava um ficheiro JSON simples chamado storage.js no diretório de perfis. Se estiver a recuperar uma instalação muito antiga, procure storage.js ou storage.js.migrated.

O LevelDB e o ficheiro 0001.ldb de que toda a gente fala

O LevelDB é o motor de armazenamento de pares chave-valor do Google, e compreender a sua estrutura de ficheiros é essencial para a recuperação do MetaMask em qualquer navegador Chromium.

Um diretório LevelDB do MetaMask contém vários tipos de ficheiros. O .ldb ficheiros (Tabelas de cadeias ordenadas, ou SSTables) são um sistema de armazenamento permanente e ordenado de pares chave-valor. .log ficheiros são o Write-Ahead Log – um buffer temporário das gravações recentes antes de estas serem transferidas para .ldb ficheiros. Há um MANIFEST-###### metadados da base de dados de rastreamento de ficheiros, um CURRENT ficheiro que aponta para o manifesto ativo, e um LOCK ficheiro que impede o acesso simultâneo.

Os dados do cofre são normalmente armazenados num com números baixos .ldb ficheiro – 000003.ldb, 000005.ldb, ou algo semelhante. A própria documentação do MetaMask indica que «deve ser um valor numérico baixo. Se for um número elevado, não se trata do cofre». O 0001.ldb ficheiro (ou 000001.ldb) é uma das primeiras SSTables criadas quando o MetaMask foi inicializado pela primeira vez. Geralmente contém o cofre original criado durante a criação da carteira.

Extrair dados do cofre a partir de .ldb ficheiros é normalmente simples no Chromium. Abra o ficheiro num editor de texto (Sublime Text, VS Code, ou mesmo o Notepad++) e procure a sequência vault. Encontrará o blob JSON encriptado incorporado na estrutura do registo LevelDB. Copie tudo a partir de {"data":" até ao encerramento "} – esse é o teu cofre.

No Mac ou no Linux, esta linha de comando resolve o problema:

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

Uma coisa a ter em conta: .ldb os ficheiros podem utilizar Compressão rápida nos blocos de dados. Se a pesquisa de cadeias de caracteres falhar e se estiver a ver blocos de dados binários sem sentido, o bloco de dados de que precisa poderá estar comprimido com o Snappy. O .log O ficheiro, por outro lado, está sempre descomprimido – dados brutos de chave-valor em blocos de 32 KB. Se o .ldb se a abordagem falhar, verifique sempre o .log ficheiro. A documentação oficial do MetaMask refere o seguinte: «Se não conseguir recuperar o seu cofre utilizando o ficheiro .ldb, verifique se existe um ficheiro .log.»

Uma característica do LevelDB que é extremamente útil para a recuperação: é apenas de adição. As atualizações e eliminações não alteram os registos existentes – apenas adicionam novas entradas com números de sequência mais elevados. Os registos antigos permanecem até que uma compactação os elimine. Isto significa que, se alguém importar um novo SRP sobre um antigo, os dados antigos do cofre podem ainda existir numa versão mais antiga .ldb ficheiro que ainda não foi compactado. Já recuperei carteiras «sobrescritas» desta forma mais do que uma vez.

Para a extração programática, o btcrecover O projeto inclui extract-metamask-vaults.py, que lê corretamente a base de dados LevelDB e extrai todas as entradas do cofre – incluindo aquelas potencialmente antigas que se encontram em ficheiros não compactados. O cyclone-github/metamask_extractor Esta ferramenta faz o mesmo e pode gerar resultados diretamente num formato compatível com o hashcat.

Quando os ficheiros do cofre ficam corrompidos

A corrupção do cofre decorre geralmente de uma das seguintes causas: uma falha do navegador durante uma operação de gravação (queda de energia, kernel panic, encerramento forçado), uma atualização interrompida do MetaMask que reescreve o armazenamento a meio do processo, erros reais no disco (setores danificados, desgaste do SSD) ou — cada vez mais comum — o software antivírus colocar em quarentena os ficheiros JavaScript do MetaMask, o que pode deixar a base de dados LevelDB num estado inconsistente, mesmo que os dados do cofre propriamente ditos estejam intactos.

Sabe que tem um cofre corrompido quando o JSON não é analisado. Faltam chaves, cadeias Base64 truncadas, bytes nulos inseridos no meio do campo de dados. O MetaMask Vault Decryptor apresentará a mensagem «Problema ao descodificar o cofre» ou simplesmente falhará sem aviso prévio.

A recuperação depende do tipo e da extensão da corrupção. Se a estrutura JSON estiver danificada, mas os dados encriptados estiverem praticamente intactos, muitas vezes é possível reconstruir a abóbada manualmente. O formato é rígido – é necessário exatamente o data, iv, e salt campos (mais keyMetadata (para cofres mais recentes). Remova os bytes nulos e os caracteres de controlo. Verifique se o data, iv, e salt os valores são válidos em base64. Se o data Se o campo estiver truncado, no entanto, está em apuros – O AES-GCM requer o texto cifrado completo além da sua etiqueta de autenticação (os últimos 16 bytes do data (campo) para descodificar. Basta faltar um único byte para que todo o processo falhe.

No caso de bases de dados LevelDB parcialmente danificadas em que o .ldb Se os próprios ficheiros estiverem danificados, tente ler o .log em vez disso – trata-se de um formato mais simples (blocos sequenciais de 32 KB com cabeçalhos de 7 bytes) e pode conter uma cópia mais recente do cofre que tenha sobrevivido ao incidente de corrupção. Se nenhuma das abordagens funcionar, por vezes pode utilizar bibliotecas de análise LevelDB em Python (o CCL Solutions Group lançou implementações em Python puro para análise LevelDB, descompressão Snappy e deserialização V8) para extrair com precisão registos de ficheiros de base de dados danificados, ignorando os blocos corrompidos.

Podem coexistir várias SRP num único diretório LevelDB. Se um utilizador importar uma nova frase-semente, a entrada antiga do cofre poderá permanecer num diretório separado .ldb ficheiro ou mesmo dentro do mesmo ficheiro, numa posição diferente. Procure sempre por todas as instâncias do padrão em abóbada, e não apenas o primeiro.

O problema dos ficheiros sobrescritos e o que fazer para o resolver

Este é o cenário que causa mais transtornos. Alguém desinstala o MetaMask – talvez estivesse a resolver um problema, talvez estivesse a «limpar» o navegador, talvez nem se tivesse apercebido do que estava a fazer. Nos navegadores baseados no Chromium, desinstalar uma extensão elimina toda a pasta de dados da extensão, incluindo todos .ldb, .log, e ficheiros manifest. No Firefox, o moz-extension+++<UUID> A pasta é removida e, uma vez que cada reinstalação gera um novo UUID, a nova instalação não afetará a localização anterior (mas a localização anterior já não existe).

A própria documentação do MetaMask é clara quanto a isto: «Os dados da extensão do navegador são eliminados quando a extensão é desinstalada. Em geral, isto significa que os dados do seu cofre desaparecem.»

A palavra «geralmente» tem um grande peso. Os dados são logicamente eliminados — o sistema de ficheiros marca esses setores como livres —, mas os bytes em si não são imediatamente zerados. Num disco rígido tradicional (HDD), os dados permanecem até que esses setores venham a ser reutilizados por novos ficheiros. Num SSD, os comandos TRIM podem tornar os dados eliminados irrecuperáveis em poucos minutos, por vezes em segundos.

A primeira regra para recuperar um cofre sobrescrito: pare de utilizar o computador imediatamente. Qualquer novo ficheiro gravado na unidade pode sobrescrever os setores onde o seu cofre estava armazenado. Se possível, retire a unidade e monte-a em modo de leitura apenas noutro computador.

Ferramentas de recuperação para este cenário, por ordem de preferência:

O nosso software personalizado (multiplataforma) para a recuperação de ficheiros apagados logicamente
extundelete ou ext4magic para sistemas de ficheiros ext3/ext4 do Linux
Pesquisa no disco bruto como último recurso: grep -rboa "vault" /dev/sdX para analisar o dispositivo de disco bruto em busca de cadeias de caracteres do cofre
As nossas ferramentas personalizadas para a recuperação de ficheiros quando os metadados do sistema de ficheiros estão perdidos – configure-o para procurar {"data":" padrões

Já recuperei cofres de unidades que tinham sido desinstaladas semanas antes – em discos rígidos (HDD). Nos SSD, a taxa de sucesso diminui drasticamente após apenas algumas horas de utilização contínua. Reinstalar o MetaMask é a pior coisa que se pode fazer, porque cria uma nova base de dados LevelDB exatamente no mesmo diretório, o que pode sobrescrever os setores antigos.

O Firefox tem aqui uma vantagem. Uma vez que cada instalação recebe um novo UUID, a reinstalação cria ficheiros num novo caminho de diretório. O antigo moz-extension+++<OLD-UUID> os dados, mesmo que a pasta tenha sido eliminada, não serão substituídos pelos ficheiros da nova instalação. Existem também duas preferências ocultas do Firefox – extensions.webextensions.keepUuidOnUninstall e extensions.webextensions.keepStorageOnUninstall – que, se definido para true em about:config Antes da desinstalação, evite que o navegador apague o armazenamento das extensões. Mas ninguém configura isso de forma proativa.

O MetaMask na versão móvel é algo completamente diferente

A aplicação móvel MetaMask foi desenvolvida com React Native e armazena os dados de forma completamente diferente da extensão do navegador. O cofre encriptado passa por @react-native-async-storage/async-storage, que utiliza back-ends específicos para cada plataforma.

No Android, o AsyncStorage grava normalmente num Base de dados SQLite em /data/data/io.metamask/databases/RKStorage. Este caminho requer acesso de root para leitura direta. A encriptação do cofre utiliza a mesma abordagem de chave derivada de PBKDF2, mas com diferenças importantes em relação à extensão para computador: a aplicação móvel utiliza historicamente apenas 5 000 iterações do PBKDF2 e encripta com AES-CBC em vez de AES-GCM. Isto significa que os cofres móveis não são intercambiáveis com os cofres de computador, mesmo que a palavra-passe seja idêntica.

No iOS, os dados ficam armazenados na área restrita da aplicação, em <AppSandbox>/Documents/. Para a recuperação de uma cópia de segurança do iCloud, o caminho relevante é Apps → MetaMask → Documents → persistStore → persist-root – vai precisar de uma ferramenta como o iMazing para explorar uma cópia de segurança do iOS num Mac. O funcionamento deste método depende do facto de o utilizador ter a cópia de segurança do iCloud ativada enquanto o MetaMask estava ativo; além disso, alterações por parte da Apple terão, alegadamente, impedido o funcionamento desta abordagem de forma intermitente.

A aplicação móvel MetaMask também implementa um SecureKeychain módulo (baseado em react-native-keychain) que armazena a palavra-passe da carteira do utilizador no Keychain do iOS ou no Keystore do Android para o desbloqueio biométrico. Uma auditoria de segurança revelou que o SecureKeychain adiciona uma camada extra de encriptação utilizando um «foxCode» como salt – que acabou por ser a sequência de caracteres codificada de forma rígida "encrypt". A equipa do MetaMask reconheceu que se tratava de uma estratégia de defesa em profundidade e não de um segredo essencial para a segurança.

O principal desafio da recuperação de dados em dispositivos móveis é que não é possível extrair manualmente o cofre equivale a encontrar .ldb ficheiros no ambiente de trabalho. Não é possível ligar-se ao iPhone via SSH e procurar strings do Vault com o grep. A partir de MetaMask para dispositivos móveis v6.3.0, a aplicação inclui uma recuperação automática do cofre que se ativa quando é detetada uma corrupção – mas, se a aplicação for eliminada, os dados locais do cofre desaparecem, a menos que tenha uma cópia de segurança do dispositivo. Os mecanismos de cópia de segurança do Android são particularmente pouco fiáveis para capturar todos os dados internos da aplicação. A posição oficial da MetaMask é recomendar a transferência dos ficheiros para um novo SRP, em vez de se recorrer à recuperação do cofre do Android.

A alteração no número de iterações do PBKDF2 que deixou todas as ferramentas de recuperação inoperantes

Durante anos, o MetaMask utilizou 10 000 iterações PBKDF2 – o valor predefinido fixo no browser-passworder biblioteca. Todas as ferramentas de recuperação, todos os módulos do Hashcat, todos os scripts de força bruta foram configurados para 10 000 iterações. Depois, no final de 2023 / início de 2024, tudo mudou.

O @metamask/browser-passworder A biblioteca v4.2.0 (lançada a 13 de novembro de 2023) introduziu o suporte a opções configuráveis de derivação de chaves. O novo valor predefinido da biblioteca passou a ser 900 000 iterações, mas a extensão do MetaMask configurou-o para utilizar 600 000 iterações – em conformidade com a recomendação da OWASP para 2023 relativa ao PBKDF2-HMAC-SHA256. Pela extensão MetaMask v11.16.11 (confirmado numa edição do Hashcat de junho de 2024), estavam a ser criados novos cofres com 600 000 iterações e o novo keyMetadata campo.

Isto representa um aumento de 60 vezes no custo computacional por tentativa de senha. Um ataque de força bruta que demorava um dia com 10 000 iterações demora agora dois meses com 600 000 iterações no mesmo hardware. A comunidade hashcat teve de desenvolver kernels personalizados – o modo 26620, contribuído por cyclone – para lidar com o novo formato. O modo padrão 26600 tinha 10 000 iterações codificadas de forma rígida.

É importante referir que os cofres antigos NÃO são automaticamente encriptados novamente. Se criou a sua carteira em 2021, o seu cofre continua a utilizar 10 000 iterações, a menos que o MetaMask tenha desencadeado explicitamente uma recodificação (o updateVault existe uma função para esse efeito, mas não é claro com que frequência o MetaMask a invoca ao desbloquear). É possível saber com que versão se está a lidar pela presença ou ausência do keyMetadata campo. Não keyMetadata? São 10 000 iterações. Tem keyMetadata com "iterations": 600000? É o novo formato.

Aqui está a cronologia completa das versões da biblioteca de encriptação relevantes para a recuperação:

browser-passworder v1.x–v2.x (antes de 2022): 10 000 iterações, valor fixo. Publicado sem o @metamask âmbito.
v3.0.0 (Agosto de 2022): Renomeado para @metamask/browser-passworder. Sem alteração na iteração.
v4.2.0 (Novembro de 2023): Adicionado keyMetadata suporte. A configuração padrão de encriptação foi alterada para 900 000 iterações. keyFromPassword compatível com versões anteriores a partir da versão 10.000.
v4.3.0 (Novembro de 2023): Adicionado isVaultUpdated para verificar se o cofre cumpre os parâmetros pretendidos.
v5.0.0 (abril de 2024): Node.js v16 (versão mínima). Sem alterações na criptografia.
v6.0.0 (dezembro de 2024): Node.js v18.18 (versão mínima). Sem alterações na criptografia.

Para especialistas em recuperação: verifique sempre primeiro o formato do cofre. Isso determina toda a sua estratégia.

A política de senhas do MetaMask e o que isso significa para os ataques de força bruta

O MetaMask exige que a senha tenha um comprimento mínimo de 8 caracteres. É só isso. Não há exigência de letras maiúsculas, números ou caracteres especiais. A extensão exibe um indicador visual de segurança (“Fraca” / “Boa”), mas não bloqueia senhas fracas que cumpram o comprimento mínimo. Também não há comprimento máximo – são suportados caracteres Unicode. Esta política está em vigor desde, pelo menos, o início de 2018 (referenciada na issue #3515 do GitHub).

Vários sites de terceiros afirmam, incorretamente, que o MetaMask exige letras maiúsculas, minúsculas, números e caracteres especiais. Isso está errado. O único requisito obrigatório é que a senha tenha 8 caracteres.

Para a recuperação por força bruta, isto é extremamente importante. Uma palavra-passe de 8 caracteres, composta apenas por letras minúsculas, tem um espaço de chaves de cerca de 208 mil milhões de combinações (26^8). Contra um cofre antigo com 10 000 iterações, o hashcat numa GPU moderna pode testar milhares de hashes por segundo, tornando-o quebrável em poucos dias. Contra um cofre de 600 000 iterações, multiplique o tempo por 60. Uma palavra-passe forte com mais de 12 caracteres, com maiúsculas e minúsculas e símbolos? Efetivamente inquebrável contra qualquer um dos formatos com o hardware atual.

A ferramenta prática de recuperação mais indicada é btcrecover – A própria MetaMask recomenda-o para utilizadores que tenham uma ideia aproximada da sua palavra-passe. Suporta a adivinhação baseada em tokens e em padrões, permitindo-lhe definir um modelo como "my" + [dog|cat|bird] + [2019|2020|2021] + ["!"|"@"|"#"] e testar de forma eficiente todas as permutações. No caso de ataques acelerados por GPU, o modo 26600 do hashcat lida com cofres antigos, o modo 26610 lida com cofres móveis e o modo 26620 (ou um 26600 recompilado com iterações atualizadas) lida com o novo formato de 600 000 iterações.

As vias de derivação e a epidemia dos «fundos em falta»

O caminho de derivação é onde se originam a maioria dos problemas do tipo «os meus fundos desapareceram». MetaMask utiliza o caminho padrão BIP-44 para a Ethereum: m/44'/60'/0'/0. Os cálculos são obtidos incrementando o índice final: m/44'/60'/0'/0/0 (primeiro relato), m/44'/60'/0'/0/1 (segundo), m/44'/60'/0'/0/2 (terceiro), e assim por diante. Este procedimento aplica-se a todas as cadeias compatíveis com EVM – o mesmo endereço na Ethereum, Polygon, Arbitrum e BSC.

O problema é que nem toda a gente usa o mesmo caminho. Ledger Live utilizações m/44'/60'/x'/0/0, aumentando o account campo em vez do address_index. O Legado de Ledger (o antigo caminho MEW/MyCrypto) utiliza m/44'/60'/0'/x – apenas quatro níveis em vez de cinco. O primeiro endereço (m/44'/60'/0'/0/0) é idêntica no MetaMask, no Ledger Live e no Trezor. Mas o A partir da segunda conta, as versões divergem completamente, porque cada carteira incrementa um componente diferente do caminho.

Isto cria um padrão de falha muito específico: alguém restaura a sua semente do Ledger no MetaMask, vê a sua primeira conta e o seu saldo, depois adiciona uma segunda conta e vê… zero. Os fundos não desapareceram. Estão no endereço derivado de m/44'/60'/1'/0/0 (ao estilo do Ledger Live), mas a MetaMask está a considerar m/44'/60'/0'/0/1. Chaves completamente diferentes, endereços completamente diferentes.

Caminho de derivação padrão do Ethereum no Trezor corresponde ao do MetaMask: m/44'/60'/0'/0/x. Assim, a recuperação do Trezor para o MetaMask funciona, em geral, para todas as contas. Os problemas entre carteiras dizem respeito principalmente ao Ledger ↔ MetaMask e ao Ledger ↔ Trezor.

Para localizar fundos que se encontram na «trajetória de derivação errada», as suas opções são:

Contacte-nos por e-mail para contact@cryptorecovery.io e faremos o possível para o ajudar.
MyEtherWallet (MEW): Suporta caminhos de derivação personalizados através da opção «Adicionar caminho». Introduza manualmente m/44'/60'/1'/0/0, m/44'/60'/2'/0/0, etc., para verificar endereços do tipo Ledger Live.
MyCrypto: Suporte a caminhos de derivação personalizados semelhantes.
Ferramenta BIP-39 de Ian Coleman (a executar offline): Introduza a frase mnemónica, selecione ETH, alterne entre os separadores BIP-44 e ajuste manualmente os componentes do caminho.
btcrecover: Permite automatizar testes em diferentes esquemas de caminhos de derivação.

Uma limitação frustrante: a integração do MetaMask com o Trezor não suporta caminhos de derivação personalizados. Uma opção de caminho de derivação personalizado foi incorporada para o Ledger (PR #9367), mas, de acordo com as informações mais recentes, o equivalente para o Trezor (GitHub issue #11197) continua em aberto. Se estiver a tentar aceder a contas derivadas do Ledger através do MetaMask + Trezor, terá de utilizar o MEW ou o MyCrypto em vez disso.

MetaMask e Trezor: um casamento conturbado

A integração entre o MetaMask e o Trezor funciona através de Trezor Bridge – um processo em segundo plano instalado localmente (trezord) que escuta no http://127.0.0.1:21325/ e faz a ponte entre a área restrita do navegador e o acesso ao hardware USB. Pode verificar se está a funcionar clicando em http://127.0.0.1:21325/status/.

O motivo mais comum para esta falha é aparentemente simples: o Trezor Suite está aberto. O Trezor Suite bloqueia a ligação USB ao dispositivo, impedindo o MetaMask de comunicar. É necessário encerrar completamente o Suite – não basta minimizá-lo, mas sim fechá-lo a partir da bandeja do sistema. Estimo que isto seja responsável por 40% dos pedidos de assistência do tipo «O MetaMask não consegue encontrar o meu Trezor» que tenho visto.

Outros problemas comuns e as respetivas soluções:

«À procura do seu Trezor…» a girar indefinidamente – Verifique se o Bridge está instalado e trezord está em execução. Experimente utilizar um cabo USB e uma porta diferentes. Desative a VPN, a firewall e as extensões do navegador (os bloqueadores de anúncios e as extensões de privacidade costumam causar interferências). O modo de navegação anónima elimina os conflitos entre extensões.

«Ligação ao dispositivo em curso» – Outra aplicação ou separador do navegador já está a comunicar com o Trezor. Feche todos os outros separadores e aplicações que possam aceder ao dispositivo.

Limitações do WebUSB – O Firefox não suporta o WebUSB de todo, o que significa que a conectividade do Trezor no Firefox depende inteiramente do Bridge. O Chrome, o Brave e o Edge funcionam através da implementação do WebUSB/WebHID do Chromium.

Aviso relativo ao caminho de derivação do Trezor Safe 5 – Os utilizadores relatam ver a mensagem «Caminho de derivação incorreto para a conta selecionada. m/44’/60’/0’/0» no ecrã do Trezor durante a validação da transação. Em geral, este aviso pode ser ignorado com segurança – a carteira funciona corretamente apesar da mensagem. Trata-se de uma questão de aparência relacionada com a forma como o firmware do Trezor valida caminhos que não parecem estar em conformidade com o padrão.

Em 2025, a Trezor começou a integrar a funcionalidade Bridge na própria Trezor Suite. Esta transição provocou uma série de problemas de conectividade, uma vez que alguns utilizadores precisavam de ter a Suite a funcionar em segundo plano para as ligações ao MetaMask, enquanto outros precisavam de a ter totalmente encerrada. Consulte Trezor Suite → Definições → Aplicação → Trezor Connect para obter as configurações relevantes.

Quando o MetaMask se liga a um Trezor, as contas resultantes são fundamentalmente diferentes das contas da carteira de software do MetaMask. As contas derivadas do Trezor armazenam apenas chaves públicas e caminhos de derivação no cofre – as chaves privadas permanecem no dispositivo de hardware. O MetaMask pode exibir saldos (apenas para leitura através de chaves públicas) sem o Trezor ligado, mas não pode assinar transações sem o dispositivo físico presente. Se tiver sido utilizada uma frase-passe ao criar contas Trezor, deve ser introduzida exatamente a mesma frase-passe para regenerar os mesmos endereços.

Técnicas de recuperação que realmente funcionam na prática

Após centenas de recuperações, eis os cenários com que me deparo com mais frequência e a forma como os lido.

Cenário 1: Possui a palavra-passe, perdeu a frase-semente, mas a extensão continua instalada

Esta é a parte fácil. Abra a página de fundo do MetaMask através de chrome://extensions → Modo de programador → clique em «service worker» (MV3) ou «página em segundo plano» (MV2). No console:

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

Copie o JSON do cofre e cole-o no Descriptor do MetaMask Vault (metamask.github.io/vault-decryptor), introduza a sua palavra-passe e o programa apresentará a sua frase mnemónica e quaisquer chaves privadas importadas. O Vault Decryptor foi desenvolvido por Dan Finlay, cofundador da MetaMask – também aceita .ldb ficheiros diretamente através do carregamento de ficheiros.

Cenário 2: Possui a palavra-passe; a extensão foi desinstalada, mas os dados podem ainda estar no disco

Aceda ao diretório de dados da extensão. Se a pasta ainda existir (por vezes, a desinstalação não consegue limpar tudo completamente, ou o utilizador apenas desativou a extensão em vez de a remover), selecione o .ldb e .log ficheiros. Extraia o cofre utilizando o grep, um editor de texto ou btcrecoverde extract-metamask-vaults.py. Descriptografar com o Vault Decryptor.

Se a pasta tiver desaparecido, contacte-nos através do endereço contact@cryptorecovery.io e iremos ajudá-lo com a análise forense do disco.

Também pode montar a unidade como de leitura apenas e realizar pesquisas diretas no disco por padrões de cadeias de caracteres do cofre. No Linux: grep -rboa '{"data":"' /dev/sdX. O sucesso depende em grande medida da quantidade de atividade do disco que ocorreu após a eliminação e do tipo de unidade (SSD ou HDD).

Cenário 3: Esqueceu-se da palavra-passe, mas tem o ficheiro do cofre

Este é um cenário de força bruta. Extraia o cofre e converta-o para o formato hashcat utilizando metamask2hashcat.py ou cyclone-github/metamask_extractor. Em seguida, execute o hashcat (modo 26600 para cofres antigos, 26620 para os novos) ou o btcrecover com um ficheiro de token que descreva o que se lembra da palavra-passe. Se sabe que a sua palavra-passe era algo como «myDog» mais um ano mais um símbolo, o btcrecover pode testar essas combinações de forma eficiente.

Cenário 4: Recuperação do Firefox

Encontre o UUID do MetaMask em about:debugging. Navegue até ao diretório de armazenamento. Descompacte os ficheiros binários do IndexedDB utilizando snappy-fox:

./snappy-fox input_file.snappy output.txt

Procure o ficheiro JSON do cofre na pasta descompactada. Em seguida, avance com o Vault Decryptor. O JesseBusman/FirefoxMetamaskWalletSeedRecovery Este script em Python automatiza todo este processo – analisa o perfil do Firefox, localiza os dados do cofre e gera um ficheiro JSON formatado, pronto para ser descodificado.

Cenário 5: Os fundos parecem ter desaparecido após a importação de sementes

Verifique os caminhos de derivação. Se importar uma semente do Ledger para o MetaMask, a partir da segunda conta, serão apresentados endereços diferentes e saldos nulos. Utilize o MEW ou o MyCrypto com caminhos de derivação personalizados para localizar os fundos no Ledger Live (m/44'/60'/x'/0/0) ou Ledger Legacy (m/44'/60'/0'/x) caminhos. Se tiver sido utilizada uma frase-passe do Trezor, certifique-se de que introduz exatamente a mesma frase-passe – uma frase-passe diferente gera um conjunto de endereços totalmente diferente a partir da mesma semente.

Ferramentas forenses que vale a pena ter no seu kit

Descriptor do MetaMask Vault – oficial, pode funcionar sem ligação à Internet, suporta transferências diretas .ldb carregamento de ficheiros
btcrecover – recuperação de palavra-passe com correspondência de padrões, recomendado pela MetaMask
hashcat – Ataque de força bruta acelerado por GPU (modos 26600, 26610, 26620)
snappy-fox – Descompressão Snappy do Firefox
Ferramentas Python do CCL Solutions Group – análise de LevelDB em Python puro, descompressão Snappy, deserialização V8

Conclusão: o que distingue as recuperações bem-sucedidas das que fracassam

A diferença entre recuperar uma carteira e perdê-la para sempre resume-se, quase sempre, ao que aconteceu nos primeiros minutos após a descoberta do problema. A ação mais prejudicial é reinstalar o MetaMask no mesmo perfil do navegador – isso substitui o diretório LevelDB por ficheiros novos. A segunda ação mais prejudicial é continuar a utilizar normalmente o computador com um SSD após a eliminação do cofre, o que ativa o TRIM e torna impossível a recuperação ao nível do setor.

Se houver três coisas que deve reter deste guia: faça uma cópia de segurança da sua frase de semente em papel, tenha em conta que o seu cofre se encontra numa pasta específica que pode copiar e guardar, e, se algo correr mal, pare de utilizar esse computador imediatamente antes de tentar qualquer recuperação. A encriptação é sólida – AES-256-GCM com 600 000 iterações PBKDF2 não é vulnerável a ataques de força bruta, a menos que a palavra-passe seja fraca –, mas os dados em si são surpreendentemente frágeis. São apenas alguns kilobytes numa base de dados LevelDB e podem desaparecer com um único clique para limpar o navegador.

Todas as carteiras que não consegui recuperar tinham a mesma causa principal: o utilizador continuou a utilizar o computador após a perda dos dados. Todas as carteiras que recuperei com sucesso eram aquelas em que os dados ainda se encontravam no disco – por vezes em locais inesperados, por vezes em várias cópias graças à arquitetura de gravação apenas de acréscimos do LevelDB, mas sempre porque alguém parou para pensar antes de agir.

Se precisar de ajuda para recuperar a sua carteira Metamask, contacte-nos por e-mail: contact@cryptorecovery.io para uma consulta profissional e gratuita ou visite a nossa página de contacto

CryptoRecovery.io – Serviços de recuperação de carteiras