Uma nota sobre financiamento: o CypherpunkGuide não veicula publicidade de vigilância — nada de redes de anúncios, pixels de rastreamento ou conteúdo patrocinado. O projeto se sustenta com fontes transparentes de receita: doações de leitores agora; assinatura e afiliados alinhados à linha editorial mais adiante. Respondemos aos leitores, não aos anunciantes. Nenhum serviço de recuperação nem fornecedor de carteira pagou por este teste.
Perder uma senha de Bitcoin não descreve um único problema técnico. Pode ser o login de uma conta sob custódia, a senha de um arquivo de carteira criptografado, uma passphrase BIP39, palavras de recuperação ausentes ou apenas um backup que você não consegue localizar. O Bitcoin Core não redefine nem revela a passphrase esquecida de uma carteira. Isso, porém, não impede que uma ferramenta offline teste um conjunto pequeno de hipóteses delimitado pela memória (Bitcoin Core, “Managing the Wallet”).
A promessa perigosa é que a “recuperação por IA” teria mudado a criptografia. Não mudou. Executamos 11 testes sintéticos de geração de candidatos no BTCRecover, sem carteira, semente, chave, endereço, hash, fundos nem senha real. Ao acrescentar uma estrutura lembrada, uma busca fictícia caiu de 2.080 candidatos para 16, sem perder o alvo. Em outro teste, ampliar cinco classes de erro de uma alteração possível para duas elevou a busca de 60 para 1.681 candidatos.
Portanto, a pergunta útil não é “qual IA quebra a minha carteira?”. É esta: qual é o tipo de falha, quais evidências não secretas podem reduzir o espaço de busca e em que lugar existirá o conjunto completo de desbloqueio? Esse conjunto reúne a carteira criptografada ou a semente e candidatos reais suficientes para tentar abri-la. Mantenha as duas metades separadas até a verificação offline.
É realmente possível recuperar uma senha de Bitcoin perdida?#
Recuperar uma senha de Bitcoin significa testar candidatos contra a carteira criptografada correta; não existe redefinição. O processo pode funcionar quando a memória delimita as tentativas, mas não recria uma chave ausente nem adivinha do nada um segredo aleatório.
Comece identificando a camada de acesso. Dar o nome errado ao problema leva à ferramenta errada — e, às vezes, a um golpe.
Um mnemônico é o backup ordenado das palavras de recuperação. A semente é o segredo-raiz derivado desse backup, às vezes em conjunto com uma passphrase; depois, o software da carteira deriva as chaves privadas que autorizam gastos.
| O que você perdeu | O que isso controla | Primeiro caminho correto | O que não fazer |
|---|---|---|---|
| Login de corretora ou aplicativo custodial | Acesso a uma conta mantida pelo provedor | Use o processo oficial de recuperação de conta do provedor | Não baixe um “quebrador de carteira” nem entregue o login a um estranho |
| Senha de arquivo de carteira criptografado | Descriptografia das chaves privadas guardadas localmente | Preserve o arquivo, identifique o formato exato e teste candidatos lembrados numa cópia | Não sobrescreva o original nem envie o arquivo junto com as possíveis senhas |
| Passphrase BIP39 | Derivação de outra semente a partir do mesmo mnemônico | Use o mnemônico exato e um endereço conhecido ou uma chave pública estendida — um identificador público que não gasta fundos, mas pode expor o histórico de endereços — inteiramente offline | Não espere uma mensagem de “passphrase incorreta”; toda passphrase deriva uma semente |
| Palavras do mnemônico ausentes ou digitadas incorretamente | Reconstrução do backup da semente | Siga o processo de recuperação específico da carteira, usando um alvo conhecido | Não cole as palavras num site nem numa IA hospedada |
| Arquivo da carteira ausente | Localização do material criptografado das chaves | Procure em aparelhos antigos e backups sem alterar os originais | Não suponha que uma busca de senha substitui um arquivo que já não existe |
| Bitcoin roubado ou perdido num golpe | O controle já passou para outra chave | Comunique o caso rapidamente à corretora pertinente, às autoridades competentes e a um profissional local | Não confunda rastreamento ou recuperação jurídica com recuperação de senha esquecida |
Uma passphrase BIP39 é o texto opcional combinado com o mnemônico para derivar a semente de uma carteira. Pela especificação BIP39, qualquer passphrase produz uma semente válida. Um erro de digitação pode, portanto, abrir outra carteira vazia sem mostrar erro. Essa validação é diferente de destrancar um arquivo wallet.dat criptografado.
Se você ainda não tem uma prova independente de backup e recuperação, o nosso teste de custódia de Bitcoin em 10 passos mostra como evitar que a mesma falha se repita.
O que a IA fez num caso de recuperação relatado em 2026#
Uma notícia de 2026 apresentada como “IA quebrou uma carteira Bitcoin” descreveu a descoberta de um arquivo, não a quebra da criptografia. Segundo a CoinDesk, o Claude ajudou a localizar um backup antigo da carteira; em seguida, o dono o descriptografou com uma senha que já estava anotada.
As ações decisivas foram encontrar o backup antigo e usar a senha existente. De modo mais geral, uma IA pode ajudar a comparar metadados de arquivos que não sejam secretos ou transformar padrões abstratos da memória num modelo. Ainda é o software da carteira que determina se um candidato descriptografa o material correto das chaves.
Uma passwordlist, ou lista de senhas, contém uma tentativa completa por linha. Uma tokenlist, ou lista de fragmentos, contém partes lembradas que o BTCRecover combina para formar candidatos completos.
| A IA pode ajudar a | A IA não consegue comprovar | Evidência mais segura |
|---|---|---|
| Classificar o formato da carteira a partir de metadados que não sejam secretos | Que a carteira pertence a você | Registros de procedência e inspeção offline da mídia original |
| Transformar padrões lembrados num modelo de passwordlist ou tokenlist | Que a senha correta está na lista | --listpass — uma prévia dos candidatos sem carteira — e a contagem resultante na máquina offline |
| Localizar prováveis backups por nome, data e tamanho | Que o arquivo contém as chaves procuradas | Análise específica do formato e um endereço ou alvo público conhecido |
| Explicar opções documentadas da ferramenta | Que o comando gerado é seguro para a sua carteira específica | Documentação oficial da mesma versão e uma cópia descartável para o teste |
| Ajudar a diagnosticar uma execução que falhou a partir de erros censurados | O próprio segredo ausente | Uma verificação bem-sucedida por software fixo, seguida de um gasto controlado |
O caso é útil por mostrar onde a IA funciona melhor: na recuperação do contexto. Não é uma estimativa da taxa de sucesso, um benchmark reproduzível nem autorização para enviar um computador antigo a um modelo na nuvem. Discos antigos podem guardar declarações fiscais, documentos de identidade, perfis do navegador, outras carteiras e vestígios de senhas. Não envie o disco nem material real de recuperação; trabalhe apenas com padrões abstratos e marcadores fictícios, seguindo o limite de dados explicado na nossa auditoria de privacidade para assistentes de IA.
A IA planeja os candidatos; o software os verifica#
Num sistema de recuperação assistida por IA, o modelo só planeja a ordem dos candidatos; um verificador fixo testa cada um. A decisão final — se alguma tentativa descriptografa a carteira — continua sendo do BTCRecover ou do Hashcat.
Um verificador determinístico é um software que devolve o mesmo resultado para a mesma carteira e o mesmo candidato. Chamar a camada de planejamento de “IA” não reduz, por si só, um espaço ilimitado de senhas aleatórias.
Num benchmark publicado em 4 de julho de 2026, com 30 segundos por teste, o BTCRecover 1.13.0, no Windows 11 com Ryzen 9 9950X e RTX 5090, mediu 3.209,22 senhas por segundo para a amostra Bitcoin Core em SQLite e 11.948,17 para a amostra Berkeley DB (BDB) (JSON de resultados). O Bitcoin Core calibra o trabalho de derivação de chave quando uma carteira é criptografada. Assim, as contagens de iterações e velocidades dessas amostras não são constantes do backend nem taxas universais do Core (código-fonte do Core).
A escala ainda é instrutiva. À velocidade de 3.209,22 tentativas por segundo dessa amostra, percorrer todas as sequências de dez letras minúsculas — 26^10, ou 141.167.095.653.376 candidatos — levaria cerca de 1.393,9 anos. Se a posição do alvo fosse uniforme, a média seria de aproximadamente 697,0 anos. É apenas uma ilustração baseada numa amostra, não um modelo dos hábitos humanos ao criar senhas.
O BTCRecover também publica uma avaliação de habilidades de IA. As porcentagens são pontuações máximas numa rubrica de comportamento do fluxo de trabalho, não a parcela de carteiras recuperadas. Calculamos as diferenças entre os pares das tabelas oficiais de chat e Docker: cinco dos seis modelos listados tiveram no Docker/com ferramentas uma pontuação inferior à do chat, e a variação mediana foi de -3,7 pontos percentuais.
| Modelo na tabela do BTCRecover | Pontuação no chat | Pontuação com Docker/ferramentas | Variação |
|---|---|---|---|
| qwen3.6-27b | 70,9% | 58,4% | -12,5 pontos |
| gemma-4-31b | 67,5% | 65,0% | -2,5 pontos |
| gemma-4-26b-a4b | 57,6% | 39,9% | -17,7 pontos |
| gemma-4-12b | 54,2% | 51,7% | -2,5 pontos |
| qwen3.5-9b | 52,4% | 47,5% | -4,9 pontos |
| gemma-4-e4b | 30,8% | 33,4% | +2,6 pontos |
Essa avaliação não demonstra que ferramentas pioram os modelos em geral nem explica a queda das cinco pontuações. No modo chat, o modelo aconselha sem ferramentas; no Docker, o modelo avaliado executa comandos num ambiente isolado e recebe instruções próprias de pontuação. Portanto, as tabelas comparam comportamentos observáveis diferentes, não um efeito causal controlado do acesso a ferramentas. O fluxo de IA do BTCRecover procura limitar esse processo.
O que descobrimos no laboratório sintético de 11 execuções#
O laboratório de espaço de candidatos da Cora mede como os detalhes estruturais de que você se lembra alteram a quantidade de tentativas. Ele usa apenas dados fictícios: não abre uma carteira nem prevê a chance de recuperação.
Clonamos o BTCRecover do repositório oficial no commit 1457088acf17630eb12a5b53989982ac34e55f2a, registramos a árvore do repositório, confirmamos que o diretório de trabalho não tinha alterações em arquivos rastreados e calculamos os hashes do ponto de entrada e do script do laboratório. Depois, usamos a versão 1.13.0-Cryptoguide com o Python 3.12.10 para executar 11 cenários com --listpass. Todos preservaram o alvo fictício, e nenhuma execução produziu candidatos duplicados.
Mantivemos quatro famílias de fragmentos: duas alternativas em cada uma de duas famílias de palavras, mais dois anos e dois símbolos. Então acrescentamos uma restrição conhecida por vez:
| Estrutura dos candidatos | Candidatos únicos | Alvo fictício preservado? | Variação em relação à busca sem estrutura |
|---|---|---|---|
| Oito fragmentos relacionados, cada um numa linha | 2.080 | Sim | Base |
| Variantes da mesma família tornadas mutuamente exclusivas | 632 | Sim | 69,62% menos |
| As quatro famílias de fragmentos tornadas obrigatórias | 384 | Sim | 81,54% menos |
| Obrigatórias e fixadas nas posições lembradas | 16 | Sim | 99,2308% menos |
O conjunto estruturado final tinha 1/130 do tamanho do conjunto sem estrutura. Isso não significa que toda lembrança esteja correta. Significa que o trabalho mais valioso costuma ser separar as restrições realmente conhecidas das suposições que apenas gostaríamos que fossem verdadeiras.
Também partimos de uma tentativa fictícia e fixa de senha completa, com 16 caracteres. Quatro buscas direcionadas a um único erro geraram apenas 12 a 17 candidatos cada. Ativar cinco classes de erro em conjunto produziu 60 candidatos com uma alteração possível e 1.681 com duas — um conjunto 28,02 vezes maior.
O resultado sustenta uma política por etapas: primeiro, tentativas completas e exatas; depois, uma classe plausível de erro; por último, combinações mais amplas. Um modelo pode ajudar a expressar esse plano, mas não deve inventar palavras biográficas, datas ou padrões e apresentá-los como lembranças.
Você pode examinar o JSON de resultados sem informações reais e repetir o laboratório de candidatos usando o checkout fixado do BTCRecover. Os arquivos contêm apenas sequências sintéticas e fixas. A opção que suprime o aviso no script só vale para a enumeração sem carteira e não deve ser copiada para um trabalho real de recuperação.
BTCRecover, Hashcat, IA local ou serviço de recuperação?#
O método certo precisa corresponder ao formato da carteira e expor a menor quantidade possível de material secreto. BTCRecover e Hashcat verificam candidatos; a IA planeja; ao contratar um serviço humano, você também precisa decidir em quem confiar.
No Hashcat, um modo seleciona o verificador de um formato de carteira ou hash armazenado. Ele não seleciona a senha correta.
| Método | Melhor uso | Principal vantagem | Principal limite | Limite do segredo |
|---|---|---|---|---|
| Passwordlist do BTCRecover | Algumas tentativas completas | As linhas são testadas sem alteração; classes conservadoras de erro podem ser acrescentadas por etapas | Uma lista de senhas completas não combina as linhas como fragmentos | Mantenha a carteira ou o extrato reduzido documentado separado até a execução offline; mesmo um extrato pode revelar dados identificadores ou de correlação |
| Tokenlist do BTCRecover | Fragmentos, variantes e posições lembradas | Exclusão mútua, tokens obrigatórios, âncoras e curingas codificam a memória | Uma estrutura ruim pode excluir o candidato correto ou fazer a busca explodir | Crie online apenas uma estrutura com marcadores fictícios; substitua pelos fragmentos reais offline se a carteira correspondente estiver presente |
| Hashcat | Um modo compatível com a carteira, combinado com máscaras — padrões de caracteres — ou regras — alterações nos candidatos | Motor maduro voltado a GPU e matriz explícita de modos | O suporte do modo não garante recuperação; extração e regras dependem do formato | Siga a documentação oficial do modo exato e nunca envie o conjunto completo de desbloqueio |
| Agente de IA local | Triagem, busca de arquivos, montagem do modelo e revisão de comandos | Pode trabalhar com arquivos locais e adaptar o procedimento | “Local” não significa automaticamente offline, sem registros ou seguro | Confirme o estado da rede, onde o modelo roda, logs, extensões e diretório de trabalho |
| IA hospedada | Explicações sem segredo e planejamento com marcadores fictícios | Acessível e útil para dúvidas limitadas sobre a documentação | O provedor recebe prompts, anexos, metadados da conta e da rede e, talvez, retenha os dados | Forneça somente padrões abstratos e marcadores fictícios — nunca carteira real, semente, chave, senha ou qualquer senha candidata real |
| Serviço humano de recuperação | Casos de alto valor e grande dificuldade técnica, após a devida verificação | Conhecimento especializado de formatos e equipamentos | Fraude, método opaco, disputa de honorários, exposição de identidade e roubo das chaves | Prefira um extrato reduzido documentado ou mantenha sob seu controle uma das partes indispensáveis; mesmo dados sem capacidade de gasto podem continuar sensíveis para a privacidade |
A página oficial de hashes de exemplo do Hashcat lista modos para wallet.dat do Bitcoin Core/Litecoin, Electrum, Blockchain.com/My Wallet, Bisq e outros formatos. A lista comprova que existem verificadores. Não comprova que o seu backup esteja íntegro, que a senha possa ser deduzida nem que o modo escolhido corresponda ao seu arquivo.
Um protocolo de recuperação que prioriza o trabalho offline#
Um protocolo que prioriza o trabalho offline mantém o material da carteira separado das tentativas reais até que uma máquina desconectada faça a verificação. Desligar a rede depois não desfaz um vazamento anterior para a nuvem.
Pare de alterar o original. Preserve o aparelho antigo e, quando possível, crie uma cópia byte a byte ou documentada pela ferramenta. Registre o hash criptográfico — uma impressão digital do arquivo — de cada cópia para detectar mudanças. Não tente reparar, migrar nem importar diretamente o seu único arquivo de carteira.
Classifique a falha antes de escolher o software. Anote fatos que não sejam secretos: produto e versão aproximada da carteira, sistema operacional, nome e tamanho do arquivo, período de criação, presença ou não de mnemônico e erro exato. Não anote semente, passphrase, chave privada ou candidatos na mesma nota online.
Comprove a autorização e defina um alvo. Trabalhe somente numa carteira que você possua ou esteja legalmente autorizado a recuperar. Guarde offline um registro mínimo de propriedade, autorização e procedência do arquivo, sem segredos da carteira. Numa busca de semente ou passphrase BIP39, identifique as regras documentadas de conta e caminho usadas para derivar endereços e um alvo público conhecido, sem divulgar todo o seu histórico.
Obtenha e confira a ferramenta ainda online. Comece pelo repositório oficial de um projeto que continue mantido. Fixe o commit, confirme que os arquivos rastreados e a árvore do repositório correspondem a ele e use a verificação de versão assinada quando o projeto documentar esse procedimento. Teste a instalação com amostras sintéticas incluídas, não com a sua carteira.
Planeje etapas pequenas e fiéis ao que você lembra. Ponha tentativas completas na passwordlist e fragmentos que precisam ser combinados na tokenlist. Comece pelas tentativas completas sem transformações, depois acrescente uma incerteza lembrada e só então amplie erros de digitação ou curingas. Use marcadores fictícios online sempre que a carteira ou a semente correspondente estiver na mesma máquina.
Reúna o conjunto de desbloqueio apenas offline. Desconecte a máquina de recuperação antes de ela conter tanto o material criptografado da carteira quanto os candidatos reais. Confirme se a contagem de candidatos é plausível antes de iniciar uma execução longa. O BTCRecover documenta extratos reduzidos de carteira para alguns formatos; use-os somente quando a documentação oficial atual disser que não podem gastar fundos sozinhos e, ainda assim, trate-os como dados de correlação sensíveis.
Trate o desbloqueio como uma migração. Numa carteira confiável, crie e confira uma nova configuração de recuperação. Depois, mova os fundos após verificar o destino e a taxa. Preserve uma nota de auditoria sem segredos, nunca a senha recuperada ou as chaves privadas. Use a nossa auditoria de migração de gerenciador de senhas para outras credenciais relacionadas.
Não combine “deixar o modelo na nuvem examinar tudo” com “ficar offline antes do último comando”. O vazamento já ocorreu. Um modelo hospedado deve receber apenas a estrutura abstrata e marcadores fictícios — nem sequer uma lista real de candidatos sem a carteira. Use o guia de modelagem de ameaças na era da IA para mapear onde o modelo roda, logs, plugins, pastas sincronizadas e identidade da conta antes de considerar um agente local.
Como avaliar um serviço de recuperação sem entregar a carteira#
Avaliar um serviço de recuperação é auditar a custódia dos segredos. A pergunta central não é se a história de sucesso parece impressionante, mas se o prestador consegue produzir trabalho útil sem receber todos os componentes necessários para desbloquear e movimentar os fundos.
O alerta do FBI trata principalmente de empresas que prometem recuperar criptomoedas perdidas em fraudes de investimento. A orientação da FTC sobre golpes de recuperação também alerta contra contato não solicitado, pagamento antecipado, garantias e pedidos de informações financeiras. Essas fontes não demonstram que todo especialista em recuperação de senhas esquecidas seja fraudulento, mas os sinais de risco fazem parte da avaliação.
Faça estas perguntas por escrito:
- Quais formatos e versões exatos de carteira vocês aceitam, e como confirmam a compatibilidade antes de receber material secreto?
- Vocês conseguem trabalhar com um extrato reduzido documentado que não permita gastar sozinho, e que dados de identificação ou correlação ele ainda revela? Se não, posso manter sob meu controle uma das partes indispensáveis do conjunto de desbloqueio?
- Algum arquivo de carteira, lista de candidatos, chave, log ou backup entrará em armazenamento na nuvem, software de suporte remoto, sistemas de subcontratados ou um provedor de IA?
- Como os honorários são calculados, o que se paga antes do resultado e como o contrato define “sucesso”?
- Quem controla as chaves recuperadas antes da movimentação, e posso direcionar a primeira transferência para uma carteira nova que eu preparei?
- Que termos de exclusão, retenção, resposta a incidentes e responsabilidade constam por escrito?
- Vocês apresentam identidade jurídica estável, método técnico e histórico independente sem depender apenas de depoimentos?
Rejeite garantias que ignoram o estado da carteira e a imprevisibilidade da senha. Trate contato não solicitado, pressão, exigência de acesso remoto e pedidos simultâneos da carteira e da provável senha como sinais de alto risco. Mesmo um profissional competente não recupera um segredo fora de qualquer espaço de busca viável.
Conclusão: escolha pela falha e pelo limite do segredo#
Escolha primeiro pelo tipo de falha e, depois, pelo limite do segredo. Use a recuperação oficial do provedor para login custodial, um verificador compatível para a carteira local e IA apenas no planejamento sem segredos.
Use o BTCRecover quando houver suporte ao formato e a memória puder ser representada como tentativas completas ou fragmentos. Considere o Hashcat quando você já tiver confirmado um modo compatível e entender o conteúdo dos dados extraídos. Mantenha a validação conjunta offline.
Se você não consegue identificar a carteira, preserve a mídia e procure backups antes de começar a adivinhar. Se um modelo hospedado receberia material real da carteira ou senhas candidatas reais, pare. Se um serviço receberia todas as partes indispensáveis, trate a situação como custódia completa das chaves e redesenhe o processo — ou aceite o risco de forma explícita. Uma senha realmente aleatória, sem nenhuma restrição útil, pode continuar inviável apesar do hardware ou da IA.
Perguntas frequentes#
A IA só ajuda quando as informações de que você se lembra mantêm o espaço de candidatos finito. O BTCRecover não redefine a senha de uma carteira, uma passphrase BIP39 exige um alvo conhecido e todo desbloqueio bem-sucedido deve terminar numa carteira nova.
A IA consegue recuperar a senha esquecida de uma carteira Bitcoin?#
Às vezes, a IA ajuda a recuperar o contexto necessário para uma busca viável: locais de arquivos antigos, estrutura da senha, hábitos de digitação e opções corretas da ferramenta. Ela não deduz da carteira uma senha aleatória e difícil nem contorna a criptografia. Um software fixo ainda precisa testar um candidato que esteja correto.
O BTCRecover consegue usar força bruta contra qualquer senha de Bitcoin?#
Não. O BTCRecover oferece suporte a muitos formatos e gera candidatos com eficiência, mas o sucesso prático depende do material correto da carteira, de um formato compatível, de um alvo válido e de um espaço de busca pequeno o bastante para terminar. O suporte da ferramenta não é garantia.
Uma passphrase BIP39 é igual à senha da carteira?#
Não. A senha de uma carteira costuma descriptografar material de chaves armazenado. A passphrase BIP39 se combina com o mnemônico para derivar uma semente; toda passphrase deriva uma semente válida, mas normalmente leva a outra carteira. A recuperação exige o mnemônico exato e um alvo conhecido, sempre tratados offline.
É seguro entregar o meu arquivo wallet.dat a um serviço de recuperação?#
Um arquivo criptografado de carteira continua sendo sensível. A documentação do Bitcoin Core diz que a criptografia protege as chaves privadas, não todos os campos do banco de dados; informações de transações continuam visíveis. Prefira um extrato reduzido apenas quando a documentação oficial afirmar que ele não consegue gastar sozinho e, mesmo assim, trate-o como dado sensível para a privacidade. Se o prestador exigir o conjunto completo de desbloqueio, encare isso como custódia integral das chaves.
O que devo fazer imediatamente depois de recuperar o acesso?#
Prepare e confira uma carteira nova em equipamento confiável. Depois, mova os fundos após revisar o destino e a taxa. Parta do princípio de que computadores antigos, arquivos de candidatos, logs e terceiros envolvidos podem ter aumentado a exposição. Não continue usando a configuração recuperada apenas porque ela abriu uma vez.
Fontes e arquivos#
As afirmações se apoiam em documentação oficial de software, especificações, orientações governamentais contra fraude e uma reportagem de escopo delimitado. Todos os originais estavam acessíveis em 21 ou 23 de agosto de 2026; em 23 de agosto, confirmamos que as doze reproduções exatas do Wayback abaixo retornavam HTTP 200.
