demining/pixnapping-attack-on-androidAtaque Pixnapping: Comprometer chaves privadas e frases-semente através da vulnerabilidade CVE-2025-48561 representa uma nova ameaça crítica para a rede Bitcoin e a infraestrutura Android
Este artigo examina a evolução das ameaças de segurança no espaço de armazenamento de criptomoedas, com foco em métodos modernos para comprometer chaves privadas e frases-semente, que protegem carteiras digitais. O ecossistema moderno de criptomoedas enfrenta uma ameaça crescente de ataques cibernéticos destinados a comprometer chaves privadas e frases-semente, que são a base da segurança das carteiras digitais. A complexidade e sofisticação dos ataques, que exploram não apenas o software, mas também o hardware dos dispositivos móveis modernos, aumenta a cada ano. Juntamente com ameaças tradicionais, como sequestro de área de transferência, keylogging, falsificação de QR code e exploração de vulnerabilidades em implementações de carteiras BIP32/BIP39, os pesquisadores identificam cada vez mais novas formas de comprometer dados criptográficos armazenados em smartphones.
No início de outubro de 2025, pesquisadores da Carnegie Mellon University e de várias universidades americanas apresentaram os resultados de um estudo que causou alvoroço nas comunidades científica e criptográfica. Eles descobriram uma vulnerabilidade crítica no sistema operacional Android, apelidada de “Pixnapping” e registrada sob o identificador CVE-2025-48561. Essa vulnerabilidade permite que atacantes reconstruam o conteúdo da tela de dispositivos Android passo a passo, extraindo assim informações visuais sensíveis, incluindo chaves privadas, frases-semente e códigos de autenticação 2FA de uso único de aplicativos como o Google Authenticator.
A ameaça identificada pelos pesquisadores depende da interação profunda entre as camadas de software e hardware do Android—desde APIs do sistema até o mecanismo de compressão gráfica da GPU. O Pixnapping combina técnicas de canal lateral GPU.zip com o uso legítimo de Android Intents e da API de desfoque de janelas, permitindo a reconstrução encoberta, pixel por pixel, da tela. Essa abordagem transforma um smartphone padrão em uma fonte de potencial vazamento de informações-chave usadas para gerenciar ativos digitais, incluindo Bitcoin (BTC), Ethereum (ETH), Litecoin (LTC), XRP e outras criptomoedas.
O perigo reside no fato de que o usuário não precisa conceder nenhuma permissão ao atacante—o aplicativo malicioso pode ser executado em segundo plano, permanecendo invisível para o sistema de segurança do Android. Como resultado, o atacante pode obter acesso visual às frases-semente durante backups ou retiradas de carteiras, o que equivale efetivamente ao controle total sobre os ativos de criptomoeda da vítima.
A combinação de tais ameaças—desde ataques Pixnapping até vazamentos de hardware via Rowhammer, Spectre, Meltdown e métodos relacionados de canal lateral—destaca a necessidade de repensar as estratégias de segurança na interseção entre sistemas operacionais móveis e tecnologias financeiras. Cada nova vulnerabilidade como a CVE-2025-48561 demonstra como o equilíbrio pode ser frágil entre a conveniência do acesso móvel a criptomoedas e a garantia de segurança criptográfica fundamental.
A transação decodificada 816760531f334651d711909a93a5959e74b3dbe126f50dbb6efb3e7d61f224ba representa evidência documentada do trabalho de pesquisa, registrada no livro-razão imutável da blockchain Bitcoin. Uma análise estrutural do RawTX revela a arquitetura clássica de uma transação Bitcoin versão 1, contendo um elemento crítico—o campo OP_RETURN com uma URL incorporada apontando para a pesquisa sobre o ataque Pixnapping.
https://github.com/zoeir/Bitcoin-Message-Transaction
Decomposição da estrutura da transação:
A transação usa uma única entrada (UTXO) da transação anterior e cria três saídas: a primeira saída, com valor zero, contém a mensagem OP_RETURN (77 bytes de dados), a segunda saída transfere 1000 satoshis (0,00001 BTC) para o endereço do destinatário 12ib7dApVFvg82TXKycWBNpN8kFyiAN1dr , e a terceira saída devolve o troco de 22.500 satoshis para o endereço do remetente 1G84gkhBsBM9B5Xsqw2s9b6H1oqg4nPEiW . A taxa da transação é de 1000 satoshis, o que garante processamento prioritário pelos mineradores da rede.
010000000147ac1bf5cff92293f1244c141103dd1ec46ce260f117a8f8df00e6ad0cd4d15a000000008a47304402204f0c3c52b5941993d92e85bda70f93d15b76ad3af6ceab4a1bbb9b33f5432f38022079458bd4071e7c9ab7a3a9d6872083218becb935dbe8eba7862cc30d59db1da10141049a296066ca26625e22c5759a0ed00120e0183b52454b4e6155cd3855bd689f5231497de3552b9a7b976933a803b76632f6f2ac1134acf9af248e697d19a15abbffffffff0300000000000000004d6a4b7777772e626974636f696e6d6573736167652e72752f536f757263655f436f64652f5069786e617070696e675f41747461636b5f746f5f457874726163745f507269766174655f4b657973e8030000000000001976a91412d5a845f2b212ce0c3bd65a4035881d9219090e88ace4570000000000001976a914a5dfdff9f85277310a40d2978fb7040f7af8ca4b88ac00000000
Assinatura criptográfica e autenticação:
O campo ScriptSig de 138 bytes contém uma assinatura ECDSA baseada na curva secp256k1, confirmando a posse da chave privada do remetente. Isso verifica a legitimidade da transação e impede gastos não autorizados. A mensagem decodificada no OP_RETURN: ” www.bitcoinmessage.ru/Source_Code/Pixnapping_Attack_to_Extract_Private_Keys “ serve como um marcador permanente na blockchain, vinculando a transação à pesquisa científica sobre a vulnerabilidade crítica.
CVE-2025-48561 é uma vulnerabilidade crítica de alta gravidade descoberta por uma equipe de pesquisa da University of California Berkeley, UC San Diego, University of Washington e Carnegie Mellon University em fevereiro de 2025. O ataque Pixnapping demonstra uma violação fundamental do modelo de segurança do Android, permitindo que um aplicativo arbitrário, sem nenhuma permissão especial, realize a reconstrução bit a bit do conteúdo visual de outros aplicativos.
Um diagrama dos três estágios de um ataque Pixnapping em dispositivos Android.O Pixnapping usa uma combinação de APIs Android e canal lateral de hardware GPU (zip) para extrair informações visuais das telas dos dispositivos. O ataque explora três mecanismos-chave do Android: a capacidade de enviar atividades de outros aplicativos para o pipeline de renderização via Android Intents, realizar operações gráficas (desfoque) nos pixels de outros aplicativos e medir os efeitos colaterais dessas operações, que dependem da cor do pixel. cylab.cmu+ 2
O Pixnapping é baseado na vulnerabilidade GPU.zip, descoberta pelo mesmo grupo de pesquisa em 2023. Esse ataque explora a compressão de dados gráficos baseada em hardware em GPUs modernas, que é dependente de dados, transparente para o software e presente em quase todas as GPUs modernas. cylab.cmu+ 2
A compressão de dados gráficos é uma otimização em GPUs integradas (iGPUs) que economiza largura de banda de memória e melhora o desempenho da renderização de quadros. O ataque GPU.zip permite que um site malicioso extraia pixels de iframes na versão mais recente do Google Chrome, violando o modelo de segurança do navegador. hertzbleed+ 1
O Pixnapping explora o SurfaceFlinger, um processo do sistema Android responsável por exibir e organizar elementos gráficos. O aplicativo malicioso usa Android Intents para iniciar aplicativos-alvo, fazendo com que eles exibam informações sensíveis na tela. Em seguida, é criada uma “atividade de mascaramento”—uma sobreposição translúcida que oculta o aplicativo-alvo, deixando apenas um único pixel selecionado transparente. bleepingcomputer+ 1
O ataque Pixnapping é realizado em três estágios principais, cada um dos quais usa APIs Android específicas e chamadas de sistema: pixnapping+ 1
Estágio 1: Invocando o Aplicativo-Alvo:
O aplicativo malicioso usa Android Intents para invocar atividades exportadas de aplicativos-alvo, como Google Authenticator ou Signal. Esse processo faz com que informações sensíveis (códigos 2FA, sementes) sejam exibidas na tela e passadas para o pipeline de renderização do SurfaceFlinger. bleepingcomputer+ 1
Estágio 2: Indução de Operações Gráficas
: Este estágio cria uma pilha de Android Activities translúcidas que usam técnicas de mascaramento, aumento e codificação para manipular pixels individuais da vítima. O ataque utiliza a API de desfoque de janelas do Android para realizar operações gráficas nos pixels e callbacks VSync para medir os tempos de renderização com precisão suficiente para extrair valores de pixels individuais. theregister+ 2
Estágio 3: Extração por Canal Lateral.
O estágio final usa o canal lateral GPU.zip para roubar pixels processados no estágio 2, um pixel de cada vez. Ao medir diferenças nos tempos de renderização causadas por otimizações de GPU dependentes de padrão, como compressão de dados de imagem, o ataque pode determinar informações de cor do pixel. gbhackers+ 1
A API de desfoque de janelas do Android, disponível desde o Android 12, fornece recursos para implementar efeitos de desfoque de janelas. Existem dois tipos de desfoque de janela: desfoque de fundo (cria um efeito de vidro fosco) e desfoque atrás (desfoca toda a tela atrás da janela). source.android
O Pixnapping abusa dessas APIs das seguintes maneiras:
// Exemplo de código usado no ataque (conceitual)
window.setBackgroundBlurRadius(blurRadius);
window.addFlags(WindowManager.LayoutParams.FLAG_BLUR_BEHIND);
WindowManager.LayoutParams.setBlurBehindRadius(blurRadius);
O ataque cria atividades translúcidas usando windowIsTranslucent e manipula o canal alfa de um drawable de fundo para isolar pixels individuais. source.android
Para medir com precisão os tempos de renderização, o Pixnapping usa callbacks VSync. VSync (sincronização vertical) é um sinal que sincroniza a taxa de quadros com a taxa de atualização do display. No Android, isso é implementado via Choreographer.VsyncCallback. blurbusters+ 1
// Exemplo conceitual de uso de callbacks VSync
Choreographer.getInstance().postVsyncCallback(new Choreographer.VsyncCallback() {
@Override
public void onVsync(long frameTimeNanos) {
// Medindo o tempo para extrair a cor do pixel
measureRenderingTime(frameTimeNanos);
}
});
Os pesquisadores testaram o Pixnapping em cinco dispositivos com versões do Android 13 a 16: cylab.cmu+ 1
Resultados dos testes de vulnerabilidade do Pixnapping em vários dispositivos Android
O ataque foi mais eficaz no Google Pixel 6, com uma taxa de sucesso de 73% na recuperação de códigos 2FA. O Samsung Galaxy S25 demonstrou resistência ao ataque devido a um "ruído significativo" no sinal. bleepingcomputer+ 1
Uma versão otimizada do ataque é capaz de extrair códigos 2FA de 6 dígitos do Google Authenticator em menos de 30 segundos. Esse intervalo de tempo se encaixa no período padrão de validade de 30 segundos dos códigos TOTP, tornando o ataque prático. cylab.cmu+ 2
Dados mais complexos levam mais tempo para serem extraídos:
O Pixnapping representa uma ameaça particular para usuários de criptomoedas. As frases-semente das carteiras permanecem visíveis na tela por mais tempo do que os códigos 2FA temporários, tornando-as vulneráveis ao deslizamento de pixels. Embora recuperar a frase-semente completa de 12 palavras leve um tempo considerável, o ataque continua viável se o usuário deixar a frase-semente visível ao anotá-la. currently.att.yahoo+3
Os pesquisadores forneceram vários vídeos demonstrando o ataque Pixnapping:
1. Demonstração básica do Pixnapping
2. Demonstração técnica do Tweakers
Os resultados da pesquisa foram formalmente apresentados na 32ª Conferência ACM sobre Segurança de Computadores e Comunicações (ACM CCS 2025) em Taipei, Taiwan, de 13 a 17 de outubro de 2025. A apresentação incluiu uma análise detalhada dos aspectos técnicos do ataque e uma demonstração de exemplos práticos. cylab.cmu+ 2
Até outubro de 2025, o Google e os pesquisadores não encontraram evidências de exploração da vulnerabilidade Pixnapping em ambientes reais. O Google afirmou: "Não vimos nenhuma evidência de exploração em ambientes reais." No entanto, isso não descarta a possibilidade de uso oculto por atacantes. bleepingcomputer+ 1
Os pesquisadores identificaram vários cenários potenciais para explorar a vulnerabilidade:
1. Roubo de códigos 2FA.
O cenário mais comum envolve o roubo de códigos de autenticação temporários do Google Authenticator, Authy e outros aplicativos 2FA. Um atacante pode usar os códigos roubados para contornar a autenticação de dois fatores e obter acesso não autorizado às contas da vítima. cylab.cmu+ 1
2. Comprometimento de carteiras de criptomoedas.
Um cenário particularmente perigoso é o roubo de frases-semente de carteiras de Bitcoin e outras criptomoedas. Se um usuário exibir sua frase-semente na tela para registro ou verificação, um aplicativo malicioso pode extrair gradualmente a frase inteira, obtendo controle total da carteira. currently.att.yahoo+ 2
3. Interceptação de correspondência privada.
O ataque pode ser usado para extrair mensagens de aplicativos de mensagens criptografadas como o Signal, mesmo com a Segurança de Tela ativada. Isso representa uma ameaça séria para usuários que dependem da segurança da criptografia de ponta a ponta. bleepingcomputer+ 1
Embora amostras específicas de malware usando Pixnapping não tenham sido detectadas, a técnica poderia ser integrada a famílias existentes de Trojans Android. Por exemplo, a família de malware SpyAgent já usa reconhecimento de imagem para roubar chaves mnemônicas, e adicionar capacidades do Pixnapping poderia expandir significativamente suas funcionalidades. currently.att.yahoo+ 1
Um aplicativo malicioso que executa o Pixnapping não exige que nenhuma permissão seja declarada em seu arquivo de manifesto Android. Isso o torna indistinguível de aplicativos benignos durante as verificações de segurança das lojas de aplicativos. pixnapping+ 1
Estrutura básica do manifesto:
xml:
<manifest xmlns:android="http://schemas.android.com/apk/res/android">
<application>
<activity android:name=".MaliciousActivity">
<!-- Sem declarar nenhuma permissão -->
</activity>
</application>
</manifest>
Um componente-chave do ataque é o uso de Intents do Android para iniciar aplicativos de destino:
java:
// Exemplo conceitual do código de ativação do aplicativo de destino
Intent intent = new Intent();
intent.setAction("com.google.android.apps.authenticator2.AUTHENTICATE");
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
Os pesquisadores analisaram quase 100.000 aplicativos na Google Play Store e encontraram centenas de milhares de ações invocadas por meio de Intents do Android, indicando a ampla aplicabilidade do ataque. bleepingcomputer
O processo de extração de pixels individuais envolve a criação de atividades translúcidas com uma configuração específica:
java:
// Exemplo conceitual de criação de uma atividade de mascaramento
Window window = getWindow();
WindowManager.LayoutParams params = window.getAttributes();
params.alpha = 0.99f; // Quase totalmente transparente
params.flags |= WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;
window.setAttributes(params);
// Configuração de desfoque para induzir operações gráficas
window.setBackgroundBlurRadius(20);
Após a extração de pixels, uma técnica semelhante ao reconhecimento óptico de caracteres (OCR) é usada para reconstruir o conteúdo original. O algoritmo analisa os padrões dos pixels extraídos e reconstrói os caracteres e números. pixnapping+ 1
O Google tentou corrigir a vulnerabilidade pela primeira vez na atualização de segurança do Android de setembro de 2025, limitando o número de atividades que um aplicativo poderia acionar para desfoque. A empresa observou em um boletim de segurança: "Um aplicativo que solicita vários desfoques: (1) permite o roubo de pixels medindo o tempo de desfoque entre janelas e (2) provavelmente é inválido." bleepingcomputer+ 2
Os pesquisadores rapidamente descobriram uma solução alternativa que restaurou a eficácia do ataque alterando as características de temporização. Essa solução alternativa ainda está sob embargo e não foi divulgada publicamente. pixnapping+ 2
O Google está desenvolvendo uma correção mais abrangente, que será lançada no Boletim de Segurança do Android de dezembro de 2025. No entanto, os pesquisadores observam que uma correção eficaz para o Pixnapping exigirá mudanças nos mecanismos centrais do Android, como permitir que os aplicativos impeçam que outros aplicativos sobreponham seu conteúdo confidencial. cylab.cmu+ 2
O problema fundamental é que o canal lateral subjacente GPU.zip permanece sem correção. Até outubro de 2025, nenhum fabricante de GPU se comprometeu a corrigir o GPU.zip. Isso significa que, mesmo com as correções do Android, a vulnerabilidade de hardware permanece suscetível a novos métodos de ataque. pixnapping+ 1
A Samsung foi notificada sobre a vulnerabilidade e alertada de que a correção do Google era insuficiente para proteger os dispositivos Samsung. A empresa reconheceu o problema, mas o classificou como "baixa gravidade" devido à complexidade do hardware. currently.att.yahoo+ 2
1. Atualizações oportunas:
A principal recomendação dos pesquisadores é instalar as correções do Android o mais rápido possível após o lançamento. Os usuários devem ativar as atualizações automáticas de segurança e verificar regularmente se há novas correções. cylab.cmu+ 1
2. Uso de carteiras de hardware.
Para usuários de criptomoedas, a proteção mais eficaz é o uso de carteiras de hardware. As carteiras de hardware armazenam chaves privadas e frases-semente offline, eliminando a possibilidade de comprometimento por meio de ataques de tela a tela. tradingview+ 1
3. Evite exibir informações confidenciais.
Os usuários são aconselhados a evitar exibir frases-semente ou outros dados altamente confidenciais em dispositivos conectados à internet. Se o armazenamento de frases-semente for necessário, use dispositivos offline. currently.att.yahoo+1
1. Proteção contra sobreposição:
Os desenvolvedores podem implementar proteção contra sobreposição detectando quando outros aplicativos tentam criar camadas translúcidas sobre os seus. Isso pode ser feito usando bitdefenderWindowManager.LayoutParams.FLAG_SECURE .
2. Minimize o tempo de exibição.
As informações críticas devem ser exibidas na tela pelo menor tempo possível. Por exemplo, os códigos 2FA podem ser ocultados automaticamente após intervalos curtos. bitdefender
3. Detecção de atividades anômalas:
Os aplicativos podem monitorar padrões de atividade anômalos, como chamadas frequentes à API de desfoque ou comportamento incomum de sobreposição. bitdefender
1. O aprimoramento de permissões do Android pode exigir permissões especiais para acessar a API de desfoque e outras operações gráficas que podem ser exploradas em ataques. cylab.cmu
2. Isolamento de Aplicativos
Reforçar o isolamento entre aplicativos pode impedir que outros aplicativos acessem pixels por meio de operações gráficas. bitdefender
3. Soluções de Hardware
Uma solução de longo prazo pode exigir mudanças no nível da GPU para eliminar o canal lateral GPU.zip. pixnapping+1
No contexto do ataque Pixnapping (CVE-2025-48561), que explora mecanismos de hardware e software do Android para interceptar visualmente frases-semente e chaves privadas, é fundamental considerar um vetor de ataque adicional que opera em um nível de hardware mais fundamental. O Phoenix Rowhammer ataque (CVE-2025-6202) representa uma nova geração de exploração das propriedades físicas da memória DRAM, permitindo que atacantes manipulem bits individuais de dados na RAM DDR5, incluindo estruturas de dados criptográficas críticas de carteiras Bitcoin. github+ 4
Um estudo conjunto do Computer Security Group (COMSEC) da ETH Zürich e do Google, publicado em setembro de 2025, demonstrou que a memória DDR5 da SK Hynix—o maior fabricante mundial de DRAM—permanece vulnerável a ataques Rowhammer apesar da implementação de mecanismos avançados de proteção Target Row Refresh (TRR). O Phoenix representa o primeiro ataque Rowhammer em nível de sistema capaz de contornar todos os esquemas TRR modernos implantados em dispositivos DDR5 usando uma técnica revolucionária de sincronização autocorretiva . linkedin+ 7
Rowhammer é uma vulnerabilidade de hardware na Dynamic Random-Access Memory (DRAM) que surge devido às limitações físicas da tecnologia moderna de fabricação de chips de memória. À medida que os padrões de fabricação de DRAM diminuem (para 10 nm, 7 nm e abaixo), a distância física entre células de memória individuais diminui significativamente, levando a um aumento da interferência eletromagnética entre linhas de memória adjacentes. kaspersky+ 6
Mecanismo de indução de inversão de bits:
Cada célula DRAM é um capacitor que armazena uma carga elétrica correspondente a um valor lógico de 0 ou 1. Para ler ou gravar dados em uma linha de memória específica, uma operação ACTIVATE é executada, que eleva o nível de tensão da linha alvo (linha agressora/linha alvo) a um nível alto enquanto as linhas vizinhas (linhas vítimas) permanecem em um nível de tensão baixo. Ativar repetidamente a mesma linha de memória em rápida sucessão cria interferência eletromagnética, que acelera a descarga dos capacitores nas linhas vizinhas, potencialmente levando a mudanças espontâneas nos valores de bits (inversões de bits) antes do próximo ciclo de atualização. tomshardware+ 6
Modelo matemático da degradação de carga:
A pesquisa mostra que a probabilidade de uma inversão de bit PflipP_{flip}Pflip em uma linha vítima depende do número de ativações da linha agressora NactN_{act}Nact, do tempo entre operações de atualização tREFt_{REF}tREF e da distância entre células dcelld_{cell}dcell:
onde VaggrV_{aggr}Vaggr é a tensão de ativação da linha agressora. Os módulos DDR5 modernos exigem comandos de atualização a cada 3,9 µs em média por padrão, o que é duas vezes mais frequente que o DDR4, precisamente para neutralizar o crescente efeito Rowhammer. arxiv+ 4
DDR4 TRR: Proteção de Primeira Geração
Começando com o DDR4, os fabricantes de DRAM implementaram o mecanismo Target Row Refresh (TRR)—um conjunto de contadores de hardware e lógica integrados diretamente nos chips DRAM para detectar padrões suspeitos de acesso à memória. O TRR opera com base em dois parâmetros-chave: o Maximum Activate Count (MAC)—o número máximo de ativações de linha—e a Maximum Activate Window (t~MAW~)—a janela de tempo durante a qual as ativações são contadas. csdn+4 youtube
Quando o número de ativações de uma linha específica atinge o limite MAC dentro de uma janela de tempo t~MAW~, o TRR inicia automaticamente uma operação de atualização para as linhas vítimas adjacentes, prevenindo inversões de bits. No entanto, o estudo TRRespass (2020) demonstrou uma vulnerabilidade crítica deste esquema: o mecanismo TRR usa amostragem —monitorando apenas um subconjunto limitado de linhas de memória, em vez de todas as linhas simultaneamente. O ataque Many-Sided Rowhammer explora essa limitação ativando simultaneamente múltiplas linhas agressoras (até 19 em alguns casos), o que sobrecarrega o mecanismo de amostragem do TRR e permite que linhas "não monitoradas" continuem martelando sem serem neutralizadas pelas operações de atualização. usenix+4 youtube
DDR5 TRR Aprimorado: Proteção Aprimorada de Segunda Geração
O DDR5 introduziu circuitos TRR em-DRAM significativamente melhorados com algoritmos mais sofisticados de detecção e contramedidas. Os fabricantes implementaram comandos de atualização mais frequentes (a cada 3,9 µs versus 7,8 µs no DDR4), Error Correction Code (ECC) integrado no chip e mecanismos mais avançados de rastreamento de ativação. Antes da publicação do Phoenix em setembro de 2025, acreditava-se que o DDR5 demonstrava maior resistência a ataques Rowhammer em ambientes de produção, e "inesperadamente, o DDR5 alcança isso sem comandos adicionais de controle de atualização." comsec-files.ethz+5
O problema da sincronização e o mecanismo autocorretivo
Uma descoberta-chave dos pesquisadores da ETH Zürich é que os métodos atuais de sincronização de última geração regularmente perdem comandos de atualização, tornando-os inadequados para ataques Rowhammer eficazes no DDR5. O Phoenix aborda esse problema com duas técnicas revolucionárias: securityweek+ 2.
A primeira técnica: divisão de threads. As operações de martelamento e sincronização são divididas em diferentes threads de execução para melhorar a detecção de atualizações. Embora seja uma melhoria em relação ao estado da arte, essa abordagem ainda não consegue manter a sincronização por um número suficientemente grande de intervalos de atualização, impedindo a indução de inversões de bits. github+ 1
A segunda técnica é a sincronização autocorretiva. Em vez de tentar prevenir comandos de atualização perdidos, o Phoenix detecta uma atualização perdida e ressincroniza a execução do padrão de acordo. Essa técnica permite que o Phoenix permaneça sincronizado com os comandos de atualização por janelas de atualização inteiras, o que é suficiente para induzir inversões de bits com novos padrões. security.googleblog+ 4
Modelo matemático da sincronização autocorretiva:
Contornando o TRR explorando pontos cegos
O Phoenix explora pontos cegos no mecanismo TRR—janelas temporais e espaciais onde o monitoramento de ativação de linhas é enfraquecido. Os pesquisadores descobriram que o amostrador TRR deve amostrar consistentemente acessos ao mesmo conjunto de linhas, permitindo que acessos (não amostrados) a outras linhas continuem martelando sem a intervenção das operações de atualização do TRR. O Phoenix sincroniza padrões de acesso com comandos de atualização para que as linhas vítimas estejam fora da zona ativa de monitoramento do TRR em pontos críticos no tempo. vusec+ 7
Configuração de teste e dispositivos afetados
Os pesquisadores da ETH Zurich testaram o Phoenix em 15 módulos UDIMM DDR5 fabricados pela SK Hynix, produzidos entre 2021 e 2024. Todos os dispositivos testados demonstraram vulnerabilidade ao Phoenix, induzindo com sucesso inversões de bits em segundos em cada módulo. O teste foi conduzido em uma plataforma com um processador AMD Zen 4 e plataformas especializadas de teste Rowhammer baseadas em FPGA desenvolvidas em conjunto com a Antmicro. theregister+ 8
A vulnerabilidade CVE-2025-6202 está registrada com uma pontuação CVSS base de 7.1 (Alta gravidade). Descrição da vulnerabilidade: «Vulnerabilidade no SK Hynix DDR5 em x86 permite que um atacante local acione inversões de bits Rowhammer que impactam a Integridade do Hardware e a segurança do sistema. Este problema afeta DDR5: DIMMs produzidos de 2021-1 até 2024-12».thehackernews+5
Lista de processadores AMD afetados com suporte a DDR5: amd
Processadores AMD EPYC 8004, 9004, 9005 Series; AMD EPYC 9004, 9005 Embedded Series; AMD Ryzen 6000, 7000, 7035, 7040, 7045, 8000, 8040, 9000 Series; AMD Ryzen 9000HX Series; AMD Ryzen AI 300, AI Max 300 Series; AMD Ryzen Threadripper 7000, 9000; AMD Ryzen Embedded 7000, 8000, 9000 Series.amd
Cenários práticos de ataque e características de tempo
Os pesquisadores demonstraram três cenários de exploração de ponta a ponta para o Phoenix: techradar+ 5
1. Manipulação de Page Table Entries (PTE) para Escalação de Privilégios: O Phoenix realiza com sucesso inversões de bits em Page Table Entries com taxa de sucesso de 100% , obtendo acesso não autorizado a áreas de memória restritas. Isso permite que um atacante local sem privilégios modifique sua própria tabela de páginas, obtendo acesso de leitura e gravação a toda a memória física do sistema. pmc.ncbi.nlm.nih+ 4
2. Extração de chaves SSH de máquinas virtuais: O Phoenix demonstra uma taxa de sucesso de 73% na extração de chaves SSH privadas RSA-2048 de uma máquina virtual co-localizada no mesmo servidor físico. Esta é uma ameaça crítica para ambientes de computação em nuvem onde múltiplas VMs compartilham a mesma memória física. kaspersky+ 5
3. Escalação de privilégios para root via manipulação do binário sudo: O Phoenix alcança uma chance de 33% de obter acesso root via manipulação do binário em memória do sudo. A escalação completa de privilégios para root em um sistema comum com configurações padrão é alcançada em aproximadamente 109 segundos (menos de 2 minutos). linkedin+5
Fundamentos Teóricos de um Ataque de Injeção de Falhas em ECDSA
O Elliptic Curve Digital Signature Algorithm (ECDSA) é uma primitiva criptográfica fundamental no Bitcoin, fornecendo autenticação de transações e prova de propriedade de ativos digitais. A chave privada no ECDSA é um valor escalar ddd (256 bits para secp256k1), a partir do qual a chave pública é calculada: Q = d⋅GQ = d \cdot GQ = d⋅G, onde GGG é o ponto base da curva elíptica. digital.wpi+ 7
Estrutura da assinatura ECDSA:
Para uma mensagem mmm com hash h=H(m)h = H(m)h=H(m), a assinatura consiste no par (r,s)(r, s)(r,s), onde:
onde kkk é um nonce aleatório, nnn é a ordem do grupo de pontos na curva secp256k1. securityboulevard+ 4
Ataque de injeção de falhas via inversões de bits induzidas por Rowhammer
A pesquisa Rubber Mallet (arXiv:2505.01518, maio de 2025) demonstrou que técnicas avançadas de Rowhammer podem induzir múltiplas inversões de bits adjacentes a uma taxa significativamente maior do que a documentada anteriormente. Criticamente, essas inversões correlacionadas permitem ataques eficazes de correção de assinaturas criptográficas, demonstrando como tais inversões podem permitir a recuperação de chaves privadas ECDSA de implementações OpenSSL onde abordagens de bit único seriam inviáveis. arxiv+ 2
Mecanismo de ataque de inversão de bits em uma chave privada:
Suponha que um atacante possa induzir uma inversão de bit no bit menos significativo (LSB) da chave privada ddd armazenada na RAM antes da operação de assinatura. Uma inversão de bit no LSB levará a um de dois resultados: trailofbits+ 2
Caso 1: Bit 0 → 1, que é equivalente a d′=d+1d’ = d + 1d′=d+1
Caso 2: Bit 1 → 0, que é equivalente a d′=d−1d’ = d − 1d′=d−1
Uma assinatura criada com a chave modificada d′d’d′ pode ser verificada usando a chave pública modificada:
Um atacante gera uma assinatura com uma chave privada invertida e, em seguida, verifica a verificação da assinatura usando Q + GQ + GQ + G e Q − GQ − GQ − GQ − G. Se a assinatura for verificada com Q + GQ + GQ + G, o bit original era 0; se com Q − GQ − GQ − G, o bit era 1. Ao repetir esse processo para outras posições de bits (invertendo bits nas posições 20, 21, 22, …, 2255 2^0, 2^1, 2^2, …, 2^{255} 20, 21, 22, …, 2255 e verificando com Q ±2i⋅GQ \pm 2^i \cdot GQ ±2i⋅G), o atacante pode reconstruir bit a bit toda a chave privada ddd. arxiv+ 5
Demonstração experimental no OpenSSL ECDSA
No artigo de Kwong et al. (arXiv:2505.01518), os pesquisadores demonstraram com sucesso a extração completa de chave privada ECDSA de uma implementação OpenSSL por meio de inversão de bits via Rowhammer. Os experimentos foram conduzidos em várias configurações de DRAM DDR4 (Corsair Vengeance, G.SKILL Ripjaws) usando as ferramentas Rowhammer TRRespass e BlackSmith. Uma descoberta crítica é a alta frequência de inversões de bits localizadas —múltiplas inversões de bits agrupadas na mesma linha de DRAM. arxiv+ 2
Um estudo de Rahman et al. (2023) (digital.wpi.edu) demonstrou um ataque à recuperação de chave secreta ECDSA em DRAM Samsung M378B5773DH0-2GB por meio de injeção de falhas em um servidor TLS. Os pesquisadores iniciaram 29.918 conexões ao servidor injetando falhas na memória do servidor e coletaram com sucesso assinaturas defeituosas para recuperar a chave privada. Embora o tamanho da chave ECDSA de 256 bits seja significativamente menor que o tamanho da página de memória de 32.768 bits (a maioria dos bits invertidos está fora da chave), o ataque ainda é bem-sucedido com um número suficiente de tentativas. digital.wpi
Armazenamento de chaves privadas na RAM e vetores de ataque
Carteiras Bitcoin, tanto de software quanto algumas de hardware, inevitavelmente carregam chaves privadas na RAM ao realizar operações críticas: assinatura de transações, inicialização da carteira, derivação de chaves a partir de frases-semente e descriptografia de arquivos wallet.dat. Mesmo ao usar criptografia AES-256-CBC para proteger o wallet.dat (como no Bitcoin Core), a chave privada deve ser temporariamente descriptografada e armazenada na RAM para assinar uma transação. cryptodeeptech+ 6
Modelo de ameaça para ataques Rowhammer em carteiras Bitcoin:
Cenário 1: Atacante local em um sistema desktop. O atacante executa um aplicativo malicioso no mesmo computador da carteira Bitcoin da vítima. O processo malicioso induz inversões de bits Rowhammer em regiões de memória onde o Bitcoin Core ou outra carteira armazena chaves privadas descriptografadas durante operações de assinatura. O Phoenix demonstrou a capacidade de ler e escrever dados arbitrários de memória de alta precisão em sistemas DDR5. github+ 9
Cenário 2: Ataque de co-localização em nuvem/VPS. Muitos usuários de nós e carteiras Bitcoin hospedam seus serviços em servidores virtuais privados (VPS) em plataformas de nuvem. O Phoenix demonstrou uma taxa de sucesso de 73% na extração de chaves SSH RSA-2048 de uma VM co-localizada. Um ataque semelhante poderia ter como alvo chaves privadas Bitcoin armazenadas na memória de uma VM executando um nó Bitcoin Core ou outros serviços de carteira. tomshardware+ 5
Cenário 3: Rowhammer em dispositivos Android para carteiras Bitcoin móveis. A combinação de Pixnapping (CVE-2025-48561) e possíveis variantes de Rowhammer para LPDDR4/LPDDR5 móvel cria uma ameaça em múltiplas camadas. Embora o Phoenix seja específico para DDR5 desktop, pesquisas mostram que o LPDDR4 também inclui mecanismos TRR e é potencialmente vulnerável a ataques Rowhammer adaptados. wikipedia+ 1
Modelo matemático para extrair uma chave privada Bitcoin por meio de inversões de bits:
Suponha que uma chave privada Bitcoin de 256 bits ddd esteja armazenada na memória no endereço AkeyA_{key}Akey. Um atacante rowhammer pode induzir uma inversão de bit no bit iii (onde 0≤i≤2550 \le i \le 2550≤i≤255), modificando a chave para d′=d⊕2id’ = d \oplus 2^id′=d⊕2i (XOR com 2i2^i2i). Para recuperar a chave original, o atacante coleta muitas assinaturas defeituosas {(rj,sj)}\{(r_j, s_j)\}{(rj,sj)}, cada uma criada com uma versão diferente da chave com bits invertidos dj′d_j’dj′.
Usando métodos de ataque de reticulado (por exemplo, solucionador de Hidden Number Problem), um atacante pode recuperar ddd com probabilidade de sucesso:
onde PflipP_{flip}Pflip é a probabilidade de inverter com sucesso o bit desejado, NsamplesN_{samples}Nsamples é o número de assinaturas defeituosas coletadas. pmc.ncbi.nlm.nih+ 3
ATTACKSAFE SOFTWARE e ferramenta rowhammer_attack
O ecossistema de segurança de criptomoedas inclui programas especializados para analisar vulnerabilidades relacionadas ao Rowhammer. O repositório GitHub demining/Rowhammer-Attack demonstra a aplicação prática da Análise Diferencial de Falhas de Assinatura para ECDSA, a fim de derivar chaves privadas de transações em cinco carteiras Bitcoin diferentes .
Exemplo prático de uso:
./attacksafe -tool rowhammer_attack -open RawTX.txt -save SecretKey.txtA ferramenta analisa transações Bitcoin RawTX e extrai parâmetros de assinatura ECDSA (r,s)(r,s)(r,s). Se um padrão indicando assinatura defeituosa ou reutilização de nonce for detectado, a ferramenta aplica técnicas criptoanalíticas para recuperar a chave secreta KKK (nonce) ou a chave privada ddd. github
Exemplo de extração bem-sucedida: github
Deployments ECDSA:
SecretKey = 0xe5fa9dccef88781e25e77bd1ea7830c0b33c57481b79007cda117da8139ea7c3
RawTX = 010000000104118e34a0d3c06c842d14707ed5f333d3ba1d35240086a4b5738a2fa810abec1d0000006a473044022004b1d0c7d278439811c27d9ff06b3bb0fd20d5cc90d97083266bdba7d0693bb20220282c6cea6b9ad6f4633596204ebad4716e2a086090faf62a6908bf63a1724ad501210335a395eca8191c43ccee4d91e98b9baef39476d7482cf636e5b71975c69feebdffffffff014e020000000000001976a914154813f71552c59487efa3b16d62bfb009dc5f1e88ac00000000O rótulo “Deployments ECDSA” indica uma vulnerabilidade crítica na transação da blockchain Bitcoin. A chave secreta “K” em formato HEX representa o nonce usado para gerar a assinatura. github
Plataformas de teste Rowhammer de código aberto baseadas em FPGA
O Google e a ETH Zürich desenvolveram plataformas de teste especializadas de código aberto baseadas em FPGA para analisar vulnerabilidades Rowhammer em DDR5. Em parceria com a Antmicro, duas plataformas foram criadas: security.googleblog
Plataforma DDR5 RDIMM: Nova placa de teste DDR5 Tester para testar memória Registered DIMM (RDIMM), comumente encontrada em servidores. security.googleblog
Plataforma SO-DIMM: Uma versão que suporta pinagens SO-DIMM padrão, compatível com módulos de memória DDR5 SO-DIMM prontos para uso, comuns em estações de trabalho e dispositivos de usuário final. security.googleblog
Essas plataformas estão disponíveis no GitHub (comsec.ethz.ch/phoenix) e permitem que pesquisadores de segurança conduzam análises detalhadas da suscetibilidade ao Rowhammer de várias configurações de DRAM. comsec.ethz+1
Aumentar a taxa de atualização: um tradeoff entre segurança e desempenho
Os pesquisadores do Phoenix recomendam aumentar a taxa de atualização por um fator de 3 (de 3,9 µs para ~1,3 µs) como uma contramedida eficaz. No entanto, isso resulta em uma queda de desempenho de 8,4% , representando um tradeoff significativo para sistemas de produção. Criticamente, dispositivos DRAM não podem ser corrigidos por meio de atualizações de firmware—a natureza física da vulnerabilidade significa que os módulos afetados permanecerão vulneráveis durante todo o seu ciclo de vida. techradar+ 5
Eficácia limitada de ECC e ECC on-die
O Phoenix provou que o Código de Correção de Erros (ECC) on-die integrado ao DDR5 não impede o Rowhammer . O ECC on-die é projetado para corrigir erros de bit único e alguns erros de múltiplos bits decorrentes da degradação natural das células DRAM. No entanto, o Rowhammer pode induzir múltiplas inversões de bits correlacionadas na mesma região de memória, excedendo a capacidade corretiva do ECC. reddit+ 7
Impossibilidade de correções de hardware retrospectivas
Ao contrário de vulnerabilidades de software que podem ser corrigidas com patches de segurança, o Rowhammer representa um problema físico fundamental da arquitetura DRAM. Em outubro de 2025, nenhum fabricante de GPU ou DRAM se comprometeu a corrigir a vulnerabilidade de hardware no nível do design do chip. Isso significa que bilhões de dispositivos que usam a memória afetada permanecerão potencialmente vulneráveis por anos. pixnapping+12
Estratégia de segurança em múltiplas camadas para detentores de criptomoedas:
1. Carteiras de hardware com memória isolada. Use carteiras de hardware (Ledger, Trezor, BC Vault One) com memória ferroelétrica de acesso aleatório (FeRAM) ou elementos seguros que isolam as chaves privadas da DRAM principal do sistema. A BC Vault One usa FeRAM para armazenar a chave privada, fornecendo isolamento físico contra ataques Rowhammer na memória do sistema. youtube itnext+ 3
2. Evite armazenar grandes quantias em carteiras quentes em sistemas DDR5. Usuários que executam Bitcoin Core ou outras carteiras de software em sistemas SK Hynix DDR5 (2021-2024) devem minimizar a exposição movendo seus ativos principais para armazenamento frio. github+ 3
3. Isole operações de assinatura em ambientes air-gapped. Para transações de alto valor, use assinatura offline em sistemas isolados que nunca se conectam à rede e não executam código não confiável. itnext+ 2
4. Auditoria regular de memória e detecção de anomalias. Monitore a memória do sistema em busca de padrões de acesso suspeitos característicos de ataques Rowhammer (ativações de linha de alta frequência, padrões de atualização anômalos). pmc.ncbi.nlm.nih+ 3
5. Atualize para sistemas corrigidos quando disponíveis. Embora uma correção de hardware não seja possível, futuros chips DDR5 (pós-2024) podem incluir mecanismos TRR aprimorados. Os usuários devem monitorar boletins de segurança dos fabricantes de DRAM e atualizar seu hardware quando módulos mais seguros forem lançados. github+4
A combinação dos ataques Pixnapping (CVE-2025-48561) e Phoenix Rowhammer (CVE-2025-6202) demonstra uma evolução crítica no cenário de ameaças à segurança de criptomoedas. O Pixnapping ataca a camada de hardware e software Android por meio de canais laterais GPU.zip e da API de desfoque de janela para interceptar visualmente frases-semente. O Phoenix ataca a camada física fundamental da DRAM por meio da indução de interferência eletromagnética, permitindo a manipulação direta de bits de chaves criptográficas na memória. bleepingcomputer+ 10
Ambos os ataques contornam as proteções tradicionais de software explorando características de hardware dos dispositivos que não podem ser corrigidas. Para usuários de Bitcoin, isso significa que uma reformulação fundamental do modelo de ameaça é necessária: a segurança criptográfica não é mais garantida apenas pela complexidade matemática do ECDSA ou pela confiabilidade das frases-semente—as propriedades físicas do hardware se tornam a superfície de ataque crítica. arxiv+ 9
Recuperar chaves privadas de carteiras Bitcoin perdidas explorando essas vulnerabilidades representa tanto uma tarefa legítima para serviços de recuperação quanto um vetor de ataque perigoso para atacantes. O futuro da segurança de criptomoedas exige uma abordagem holística que integre garantias de segurança em nível de hardware, implementações criptográficas com verificação formal e monitoramento contínuo de ameaças emergentes de canais laterais. trailofbits+ 7
A vulnerabilidade Pixnapping representa uma evolução significativa nos ataques móveis, demonstrando como otimizações modernas de desempenho podem ser exploradas. O ataque é particularmente perigoso para usuários de criptomoedas, pois comprometer a frase-semente pode levar à perda completa de fundos. gbhackers
A natureza fundamental das vulnerabilidades exploradas—o uso de APIs Android legítimas e otimizações de hardware de GPU—indica que uma solução completa exigirá um esforço coordenado do Google, fabricantes de dispositivos e fornecedores de GPU. pixnapping+ 1
A pesquisa do Pixnapping destaca a importância crítica de considerar as implicações de segurança ao implementar novos recursos de sistema e otimizações de hardware. À medida que os dispositivos móveis se tornam a principal ferramenta para gerenciar ativos digitais, proteger-se contra ataques tão sofisticados torna-se vital para a segurança do ecossistema.
Espera-se que o patch de dezembro do Google forneça proteção mais robusta, mas uma solução de longo prazo exigirá mudanças fundamentais na arquitetura do Android e possivelmente no hardware de GPU. Até lá, os usuários devem seguir as recomendações de segurança e ter cautela particular ao lidar com ativos de criptomoedas em dispositivos Android.
Assim, a vulnerabilidade Pixnapping (CVE-2025-48561) não é apenas mais um exemplo de falha de software, mas uma demonstração de uma classe fundamentalmente nova de ataques que ameaçam as bases da segurança criptográfica de ativos digitais. O estudo mostrou que até mesmo elementos visualmente invioláveis da interface do usuário Android podem se tornar uma fonte de vazamento crítico de dados—de chaves privadas e frases-semente a códigos 2FA de uso único que protegem carteiras de criptomoedas. Essencialmente, cada pixel na tela se torna um elo fraco na cadeia de autenticação criptográfica.
O Pixnapping é particularmente perigoso devido ao seu sigilo e versatilidade . O ataque não exige privilégios, escapa ao usuário e é capaz de reconstruir a imagem da tela até pixels individuais usando o canal lateral de hardware GPU.zip . Isso torna qualquer dispositivo Android uma fonte potencial de comprometimento de dados sensíveis, incluindo Bitcoin (BTC), Ethereum (ETH), XRP, Litecoin (LTC), e outras criptomoedas armazenadas em carteiras móveis.
O fato de esse ataque funcionar mesmo com as versões mais recentes do Android e GPUs modernas aponta para uma vulnerabilidade fundamental na arquitetura de sistemas móveis , onde otimizações de desempenho e visuais entram em conflito com os requisitos de privacidade. O Pixnapping quebra a ilusão de isolamento visual entre aplicativos, demonstrando que a proteção de informações criptográficas deve considerar não apenas vulnerabilidades de rede e lógicas, mas também os efeitos colaterais físicos e gráficos da computação .
Para garantir a estabilidade do ecossistema de criptomoedas, são necessárias medidas sistêmicas: endurecer as políticas de segurança do Android, restringir o acesso de aplicativos de terceiros a APIs gráficas de baixo nível e revisar os princípios arquitetônicos de compressão de dados de GPU. Sem tais barreiras, até mesmo os algoritmos de criptografia mais seguros podem ser vulneráveis a ataques capazes de roubar chaves literalmente da tela.
Em última análise, o Pixnapping serviu como um sério alerta para toda a indústria: a proteção criptográfica não tem sentido sem isolamento de hardware e visual . Se os dados visuais exibidos em uma tela podem ser reconstruídos por um processo externo, então cada animação na tela, cada frase-semente ou QR code se torna um canal direto para vazar fundos. Para usuários de criptomoedas, isso significa uma coisa: até mesmo a aparição instantânea de uma chave privada na tela pode agora custar-lhes todo o seu capital digital.
Este material foi criado para o portal CRYPTO DEEP TECH para garantir a segurança dos dados financeiros e a criptografia de curva elíptica (secp256k1) contra assinaturas ECDSA fracas na criptomoeda BITCOIN . Os desenvolvedores de software não são responsáveis pelo uso deste material.
Telegram: https://t.me/cryptodeeptech
Vídeo: https://youtu.be/qZvJUonp228
Tutorial em vídeo: https://dzen.ru/video/watch/68ff42ad9f0528014a4b1cf8
Fonte: https://cryptodeeptech.ru/phoenix-rowhammer-attack