Skip to main content
Blog
Blog

Inversões de Bits por Raios Cósmicos e o Risco Oculto em Escala

Quando um evento raro de uma em um milhão de chances acaba não sendo tão raro assim. Como nossa atmosfera transforma zeros em uns e como isso pode impactar a segurança.

Aug 08, 2025 Atualizado Jul 19, 2026 7 min read
blog-cover-cosmic-ray-bit-flips
Índice

Resumo: bit flips por raios cósmicos

  • Raios cósmicos causam single-event upsets (SEUs) que invertem bits na memória a uma taxa de aproximadamente um por gigabyte por mês ao nível do mar. Em escala planetária, não é uma curiosidade rara.
  • Incidentes famosos de bit flip incluem um eleitor belga contado a mais em 4.096 votos (2003) e o skip 'Upwarp' do speedrun de Super Mario 64 causado por um único bit invertido. Ambos são consistentes com a probabilidade SEU de raios cósmicos pela duração da exposição.
  • Em escala de aplicações web, bit flips por raios cósmicos são uma das pequenas causas residuais de bugs não reproduzíveis. Memória ECC, armazenamento com checksum e tratamento idempotente de requisições são as mitigações práticas.

Sem tempo? Veja o bloqueio in-browser de Magecart e skimmers da cside. Cobre tudo o que se segue numa única implementação.

Em 2013, o speedrunner competitivo de Super Mario 64 DOTA_Teabag estava percorrendo Tick Tock Clock, uma fase famosa por punir até os melhores jogadores devido a uma sequência desafiadora de saltos. Durante a corrida, Mario de repente disparou diretamente para cima através do chão, pulando uma seção inteira da fase e economizando segundos preciosos para DOTA_Teabag.

Vídeo do incidente de Bit Flip em Super Mario 64

TTC Upwarp: Ceiling Warp vs Byte Change

A comunidade de speedrun, que vinha jogando e dissecando Super Mario 64 por décadas, ficou atônita. Uma recompensa foi oferecida para quem conseguisse reproduzir o glitch; alguns speedrunners afirmaram que DOTA_Teabag havia "balançado o cartucho" (uma forma de às vezes provocar glitches de maneira previsível em jogos de Nintendo 64 alterando levemente o ângulo do cartucho). O mistério foi resolvido quando o YouTuber e renomado caçador de glitches em videogames pannenkoek12 (traduzido como 'Panqueca12') descobriu que um único bit na memória do Nintendo 64 era o responsável. A inversão de bit ocorreu em 0xC5837800, o endereço responsável pela posição vertical do Mario. A mudança em binário foi de 1100 0101 para 1100 0100, e por uma sorte extraordinária, exatamente a alteração necessária para teletransportar Mario para uma plataforma mais alta.

Então, o que causou isso? Tudo indica uma inversão de bit por raio cósmico, um erro aleatório em chips de computador causado por uma partícula de alta energia vinda do espaço que atinge um sistema exatamente no momento certo.

Ilustração de uma inversão de bit por raio cósmico atingindo um chip de memória de computador

O que é uma Inversão de Bit por Raio Cósmico?

Uma inversão de bit por raio cósmico (também chamada de "single-event upset", ou SEU) ocorre quando uma partícula ionizante errante de um raio cósmico do espaço atinge uma única célula de memória ou transistor, invertendo um bit binário de 0 para 1, ou de 1 para 0. Essas inversões de bit podem causar um erro suave, que não deixa danos físicos ao hardware, mas podem alterar dados armazenados na memória ou na lógica, modificando o comportamento de aplicações ou até desativando recursos de segurança.

O speedrun de Super Mario 64 não é o único caso documentado de um evento cósmico causando efeitos aqui na Terra. Durante as eleições belgas de 2003, uma candidata desconhecida recebeu exatamente 4.096 votos extras, aparentemente do nada, nas urnas eletrônicas do país. O erro só foi detectado porque ela recebeu mais votos do que o número de eleitores, tornando o resultado matematicamente impossível.

Após investigação, pesquisadores concluíram que um raio cósmico havia invertido um único bit na posição 13 da memória da urna eletrônica, dando à candidata 4.096 votos extras [1]. Em binário, cada bit dobra o valor, portanto o bit naquela posição foi calculado como 2^12, ou exatamente 4.096.

Raro Não Significa Impossível, Especialmente em Escala

As inversões de bit por raios cósmicos são incrivelmente raras em termos de bit individual, mas não são impossíveis. Em 1996, pesquisadores da IBM estimaram que um desktop típico com 256 megabytes de RAM poderia potencialmente sofrer uma inversão de bit induzida por raios cósmicos por mês. Avançando para os dias de hoje, onde sistemas modernos comumente operam com 16 gigabytes de RAM (62,5 vezes mais do que no estudo!), o risco escala proporcionalmente. Some a isso os milhões de raios cósmicos que atingem a Terra a cada segundo, e é só uma questão de tempo até que um acerte o bit errado na hora errada. Pesquisadores da Universidade Vanderbilt confirmaram isso, afirmando em sua pesquisa que o conjunto de roteadores de um provedor de internet com 25 gigabytes de memória poderia sofrer uma inversão de bit a cada 17 horas [2].

O ponto central é que um evento de "uma em um milhão" de chances acontecerá diariamente se você realizar mais de um milhão de operações por dia. Aqui na cside, escaneamos aproximadamente mais de 10 milhões de scripts a cada 24 horas em busca de comportamentos maliciosos. Mesmo que um erro de inversão de bit tenha uma chance de uma em 100 milhões, escanear nesse volume significa que essas probabilidades impossíveis são, na prática, bastante possíveis.

Embora memórias de nível empresarial possam não estar mais sujeitas a inversões de bit por raios cósmicos graças à adoção de memórias com correção de erros (ECC), que frequentemente detectam e corrigem erros de bit único, o hardware para consumidores geralmente não conta com essa proteção. É importante entender que "raro" em um mundo onde milhões de ações ocorrem significa que é apenas uma questão de tempo.

Proteção Cósmica e Resiliência como Princípio

Dado que as inversões de bit cósmicas são um jogo de estatísticas, como construir sistemas que estejam preparados para o inesperado? A resposta está na engenharia de tolerância a falhas. Por exemplo, as espaçonaves da NASA executam cálculos críticos em triplicata, múltiplos processadores realizam a mesma operação e, se um discordar devido a uma inversão de bit, os outros dois sobrepõem o processo. Aqui na Terra, a memória ECC pode desempenhar um papel na proteção de roteadores, servidores e infraestrutura em nuvem contra erros de bit único (e às vezes até detectar erros de dois bits!). Mas, como tudo, a memória ECC tem suas próprias limitações. Ela geralmente não protege o registrador da CPU, a memória da GPU ou os buffers de rede. Mesmo em ambientes corporativos equipados com memória ECC, inversões de múltiplos bits ou falhas no nível lógico podem passar despercebidas. Por isso, é fundamental ter uma estratégia de resiliência em camadas. Na cside, aplicamos a mesma filosofia à segurança do lado do cliente. Mesmo que um script malformado ou uma exploração de caso extremo seja raro individualmente, escanear milhões de arquivos JavaScript diariamente significa que eles não são raros no agregado.

No fim das contas, as inversões de bit por raios cósmicos nos lembram que, em escala, estamos lidando com probabilidades, não com certezas. Uma chance de uma em um milhão torna-se inevitável quando seus sistemas processam um bilhão de operações de uma vez. Seja construindo um banco de dados, um sistema eleitoral ou um proxy de navegador do lado do cliente, a lição permanece a mesma: planeje para todas as possibilidades. No lado do cliente, a imprevisibilidade escala com o volume. Por isso, seus sistemas devem ser construídos com a premissa de que nada é imune a falhas, e projetados para resistir até às anomalias mais improváveis, de nível cósmico.

Referências:

[1] https://web.archive.org/web/20070927185155/http://wiki.ael.be/index.php/ElectronicVotingRandomSpontaneousBitInversionExplained

[2] https://www.independent.co.uk/news/science/subatomic-particles-cosmic-rays-computers-change-elections-planes-autopilot-a7584616.html

Jack LaFond
Security Researcher

I'm a security engineer + security researcher at cside.

FAQ

Frequently Asked Questions

Um single-event upset, ou SEU, é um erro transitório em que uma partícula de alta energia, muitas vezes vinda de um raio cósmico, atinge uma célula de memória ou um transístor e inverte um único bit binário de 0 para 1 ou de 1 para 0. Não deixa dano físico no hardware, mas pode corromper dados armazenados ou alterar a lógica de forma silenciosa, mudando o comportamento de uma aplicação ou até desativando uma função de segurança até que a memória afetada seja reescrita.

Por bit são extremamente raras, mas a taxa agregada não é irrelevante. Uma estimativa aproximada do setor coloca-a perto de uma inversão por gigabyte de RAM por mês ao nível do mar. Investigadores da IBM estimaram que um computador de meados dos anos 90 com 256 MB de memória poderia ter cerca de uma por mês, e a Universidade Vanderbilt concluiu que um conjunto de routers com 25 GB poderia sofrer uma a cada 17 horas, aproximadamente. Mais memória e mais máquinas significam mais inversões no total.

Não. A memória com código de correção de erros (ECC) deteta e corrige a maioria dos erros de um único bit e pode assinalar alguns erros de dois bits, o que a torna valiosa para servidores, routers e infraestrutura na nuvem. Mas normalmente não cobre os registos da CPU, a memória da GPU nem os buffers de rede, e falhas de múltiplos bits ou de nível lógico podem passar despercebidas. O hardware de consumo geralmente não tem ECC. A ECC é uma camada de defesa importante, não uma garantia completa contra todos os erros transitórios.

São concebidos para tolerar falhas em vez de assumir hardware perfeito. As medidas comuns incluem memória ECC, armazenamento com somas de verificação ou hash que deteta corrupção na leitura, tratamento idempotente de pedidos para que uma operação repetida não conte a dobrar, e computação redundante. As naves da NASA, por exemplo, executam cálculos críticos em vários processadores e deixam dois que concordam sobrepor-se a um terceiro que diverge. O objetivo é detetar e recuperar dos erros, não fingir que nunca acontecem.

Parta do princípio de que, com volume suficiente, algo acabará por falhar, e construa para apanhar isso em vez de tentar prevenir todos os casos possíveis. Os padrões práticos incluem validar entradas e saídas, aplicar somas de verificação aos dados em trânsito e em repouso, tornar as escritas idempotentes, registar contexto suficiente para investigar um evento isolado e monitorizar anomalias que não consegue reproduzir a pedido. Um evento num milhão torna-se rotina quando um sistema executa milhões de operações por dia, por isso a resiliência vale mais do que perseguir a certeza.

Depende de onde está o seu risco. A memória ECC é o primeiro passo para servidores e infraestrutura de longa duração que mantêm estado em RAM. As somas de verificação e os hashes importam mais para dados que se movem ou persistem, pois apanham corrupção que a ECC não consegue ver depois de os dados saírem da memória. A computação redundante encaixa em cálculos críticos para a segurança que não podem falhar em silêncio. A maioria dos sistemas maduros combina os três em camadas em vez de escolher apenas um, porque cada um cobre uma lacuna que os outros deixam aberta.

São uma causa residual pequena, muito atrás das condições de corrida, dos erros de memória, dos testes instáveis e das diferenças de ambiente. Procure primeiro as explicações comuns. Considere um erro transitório de hardware apenas depois de descartar falhas de software reproduzíveis e de confirmar que o sintoma é uma única alteração de bit, não recorrente, coerente com a probabilidade de SEU na sua exposição. À escala do planeta, porém, esse pequeno residual continua a surgir com regularidade, por isso não o descarte por completo.

A cside analisa aproximadamente mais de 10 milhões de scripts a cada 24 horas, por isso assenta na mesma premissa que este artigo descreve: com esse volume, as falhas raras são inevitáveis e têm de ser apanhadas em vez de ignoradas. A plataforma trata um script malformado ou um exploit de caso limite como algo que vai surgir no conjunto, mesmo que cada caso isolado seja improvável, e o seu pipeline de análise foi concebido para assinalar comportamentos anómalos de scripts de terceiros em vez de confiar que cada entrada está bem formada.

Sim, esse é o cerne do desenho. A cside obtém e analisa os scripts de terceiros do seu lado e aplica hash às cargas úteis da sessão real, por isso uma alteração que só é acionada em condições específicas continua a aparecer como uma diferença face à versão conhecida como boa. Como um comportamento num milhão se torna comum com milhões de scripts por dia, a plataforma parte do princípio de que os casos limite vão ocorrer e foi construída para os revelar, em vez de amostrar um subconjunto e esperar que o resto esteja limpo.

A cside é implementada como uma única etiqueta JavaScript de origem própria, ou através do Scan Method sem agente, sem alteração de DNS. Não se coloca à frente do seu tráfego nem encaminha ou faz proxy dos seus visitantes. Em vez disso, obtém e analisa os scripts de terceiros na infraestrutura da cside e lê o comportamento do script na sessão real, por isso a análise pesada acontece do lado da cside enquanto as suas páginas continuam a carregar normalmente para os seus utilizadores.

Adiciona uma etiqueta JavaScript leve de origem própria ao seu site, sem alteração de DNS e sem encaminhar nada através da cside. Se preferir não adicionar qualquer script, o Scan Method sem agente pode monitorizar as suas páginas de forma externa. A partir daí, a cside obtém e analisa os seus scripts de terceiros e vigia o comportamento deles na sessão real à procura de adulteração ou skimming, por isso a cobertura do lado do cliente começa rapidamente sem reformular a forma como o seu site serve o tráfego aos visitantes.

A cside é cobrada por utilização, normalmente pelo volume de sessões ou de visualizações de página, com níveis que acompanham o crescimento do seu tráfego e um plano gratuito para começar. Não há custos associados a adicionar uma alteração de DNS ou um proxy, porque a cside não usa nenhum dos dois. Para um orçamento ajustado ao seu tráfego e à cobertura de que precisa, o melhor é falar com a equipa da cside em vez de adivinhar a partir de um preço de tabela fixo.

Monitore e proteja seus scripts de terceiros

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Comece grátis ou experimente o Business com um teste de 14 dias.

Interface do painel cside mostrando monitoramento de scripts e análises de segurança
Related Articles
Agende uma demonstração

Quer ver isso em detalhe com um engenheiro?

Trinta minutos, no seu próprio site. Sem slides.

Agende uma demo personalizada para ver:

Como alcançar a conformidade com os requisitos 6.4.3 e 11.6.1 do PCI DSS em 1 dia
Por que scripts de terceiros são um risco de segurança para você e seus visitantes
Como monitorar vazamentos de privacidade e consentimento (RGPD, CCPA) em cada terceiro
Como conter abuso de cadastros, compartilhamento de contas e fraude de chargeback com device intelligence
Como detectar e controlar agentes de IA e bots que acessam seu site em tempo real

Prefere só mandar uma pergunta?

Procurando horários livres…

Apenas humanos de verdade. A gente saberia.

Problemas para agendar? Abrir o agendador em uma nova aba

O que você está tentando resolver?

Conte em uma linha e voltamos com algo útil, não com um discurso genérico.

Costumamos ajudar com:

Ver quais scripts de terceiros rodam no seu site
Evidências para PCI DSS 6.4.3 e 11.6.1
Bots, agentes de IA e roubo de contas

Prefere agendar um horário? Escolher um horário