Voltage Glitching no STM32F1 Read-Out Protection: Um Ataque Crowbar Passo a Passo

Hook & Contexto

O STM32F1 está em toda parte. Alimenta controladores industriais, nós CAN automotivos, dispositivos médicos, módulos de borda IoT e eletrônicos de consumo. Quando engenheiros protegem a propriedade intelectual do firmware nesses dispositivos, recorrem à Read-Out Protection do STM32 — um mecanismo executado por hardware que, em teoria, impede que qualquer pessoa leia o conteúdo da memória flash pela interface de debug. A palavra-chave é em teoria.

A verdade incômoda é que RDP Level 1 no STM32F1 não é um cadeado criptográfico — é uma verificação de permissão executada pela lógica de silício que roda no mesmo ambiente físico que você controla. Ataques de voltage glitching exploram a física desse ambiente. Ao privar momentaneamente a alimentação do processador no momento certo, você pode corromper a decisão interna que executa a proteção, fazendo o chip se comportar como se a bandeira de proteção nunca tivesse sido definida. O firmware, não criptografado e intacto na flash, fica completamente legível. Isso não é uma vulnerabilidade teórica — foi demonstrado repetidamente em pesquisa acadêmica e auditorias de segurança em hardware de produção real, e é a razão pela qual as famílias modernas de STM32 introduziram RDP Level 2.

Este artigo decompõe o ataque a partir dos primeiros princípios: por que o voltage fault funciona no nível de hardware, como a arquitetura de proteção do STM32F1 cria a superfície de ataque, e como construir e afinar um harness de glitch crowbar mínimo para explorá-la. Se você está auditando segurança de firmware embarcado, avaliando postura de hardening de produtos, ou construindo defesas — este é o modelo mental que você precisa.

TL;DR

Alvo: STM32F1 RDP Level 1 (bandeira de proteção do Option Byte) Classe de ataque: Injeção de falha de voltagem (crowbar glitch em VDD) O que quebra: A verificação de permissão do controlador flash na memória durante o caminho de leitura de debug Ferramentas: Circuito crowbar MOSFET ou ChipWhisperer, OpenOCD, osciloscópio Resultado: Dump completo de firmware via SWD após glitch bem-sucedido Correção: Use RDP Level 2 (irreversível) + criptografia de flash externa; Level 1 sozinho é insuficiente para segredos

Fundações & Teoria

Por Que Voltage Glitching Funciona

Um microcontrolador moderno executa instruções transicionando milhões de transistores entre estados lógicos a cada ciclo de clock. Esses transistores têm limiares de voltagem — abaixo de um certo nível de VDD, o gate não comuta de forma confiável. Ataques de injeção de falha exploram o hiato entre "apenas funcionando" e "funcionando corretamente".

Quando você cria um dip de voltagem curto e controlado em VDD — um glitch durando dezenas a centenas de nanossegundos — você não trava a CPU. Em vez disso, você causa um ou poucos erros na execução de instruções: um branch pode não ser tomado, uma comparação pode resolver para o valor errado, uma escrita de registro pode não ser confirmada. Esta é a base de todo voltage glitching crowbar: induzir uma falha de hardware precisamente sincronizada que corrompa exatamente o caminho lógico que você quer subverter.

O ataque é probabilístico e sensível a parâmetros. A maioria das tentativas de glitch ou não tem efeito (pulso muito curto ou muito fraco) ou trava o dispositivo (pulso muito longo ou muito profundo). O trabalho do pesquisador é encontrar a janela de parâmetro estreita — glitch width e glitch offset relativos a um trigger — onde a falha corrompe a instrução alvo sem derrubar o sistema.

A Arquitetura RDP do STM32F1

O STM32F1 armazena sua configuração de proteção em uma região dedicada de Option Byte começando no endereço 0x1FFFF800. O status RDP é codificado no byte RDP no offset 0: um valor de 0xA5 significa sem proteção (Level 0); qualquer outro valor ativa Level 1. Este byte é lido pelo controlador de memória flash na inicialização e cacheado no registro FLASH_OBR (bit 1: RDPRT).

O mecanismo de proteção funciona da seguinte forma:

O insight crítico: Esta verificação não é criptografia — é um branch condicional em lógica de silício que avalia um valor de registro cacheado. O registro reside no mesmo domínio VDD que você pode manipular. Se você conseguir corromper a avaliação de RDPRT durante a verificação, o controlador flash pode conceder acesso que deveria negar.

O STM32F1 não implementa circuitaria alguma de detecção de glitch. Ele não tem um monitor de voltagem que bloqueia o dispositivo em anomalia de VDD. Isso o distingue de famílias STM32 posteriores onde brown-out detection está ligado ao estado de segurança.

Onde Isso Se Encaixa no Workflow

Em uma avaliação de segurança de hardware, voltage glitching se situa na fase de exploitation depois que reconnaissance confirmou o alvo, identificou o nível de proteção, e descartou caminhos de extração somente por software.

O workflow em contexto:

Você geralmente tenta extração mais simples primeiro — verificando exposição de bootloader UART, JTAG/SWD sem RDP, ou arquivos de atualização de firmware em pacotes OTA — antes de investir em injeção de falha física. Glitching é uma ferramenta de precisão para quando a superfície de software está hardened.

Conceitos-Chave em Profundidade

1. O Circuito Crowbar: Como um MOSFET Vira uma Arma

Um glitch crowbar funciona shortando momentaneamente VDD para ground através de um caminho de baixa resistência, criando um dip de voltagem controlado. A implementação mais simples usa um MOSFET canal N:

VDD ──────────────────┬───── Target VDD pin
                      │
                   [Decoupling
                    capacitor]
                      │
                   Drain
                   [NFET]   ← Gate driven by glitch controller (FPGA/MCU/ChipWhisperer)
                   Source
                      │
                     GND

Quando o gate é acionado alto, o MOSFET puxa VDD em direção ao ground. Os parâmetros-chave são:

• Seleção do MOSFET: Você precisa de um dispositivo com muito baixo R_DS(on) (< 50 mΩ) e comutação rápida (< 5 ns gate transition). O BSS138 ou Si2302 funcionam para experimentos iniciais; o DMN3404 é uma escolha comum para bordas mais agudas.
• Colocação de capacitor de desacoplamento: Isso é contraintuitivo — você quer remover capacitores de desacoplamento perto do pino VDD alvo. Eles atuam como reservatórios de energia que combatem seu glitch, suavizando-o. Para glitching, uma linha VDD nua responde mais rápido.
• Resistência série: Um pequeno resistor (10–33 Ω) entre o drain e VDD evita surtos de corrente catastróficos enquanto ainda permite um dip agudo. Muito grande e o glitch é muito suave; muito pequeno e você pode danificar o dispositivo.

O hardware ChipWhisperer implementa isso de forma mais sofisticada com um driver de saída de glitch dedicado projetado para essa aplicação, mas o princípio subjacente é idêntico.

2. Timing de Trigger: NRST Release Como a Âncora

Timing é tudo. O glitch deve chegar quando o controlador flash está avaliando a verificação de permissão RDP — não durante inicialização não relacionada, não durante execução de código do usuário. A pergunta é: que evento você sincroniza?

No STM32F1, o trigger mais confiável é o evento de NRST deassertion — o momento em que o pino de reset é liberado e a CPU começa a executar do vetor de reset. A sequência de boot procede como:

1. NRST liberado → CPU busca stack pointer e reset handler no endereço 0x00000000
2. Inicialização do sistema (setup de clock, flash wait states, carregamento de option byte)
3. Option bytes processados → registro FLASH_OBR populado → ponto de verificação RDP
4. Se RDP definido, acesso debug SWD é bloqueado

A janela de ataque é em algum lugar entre passos 2 e 3. O offset, medido do NRST release, está tipicamente na faixa de 5–50 µs para o STM32F103 a 8 MHz de oscilador interno, mas isso varia com configuração de clock e revisão de silício.

Seu controlador de glitch observa NRST, detecta a borda crescente, espera offset microsegundos, então dispara um pulso de width nanossegundos. Ambos os parâmetros devem ser varridos sistematicamente.

# Pseudocode de varrimento de parâmetro conceitual (estilo API ChipWhisperer)
for offset_us in range(5, 50, step=0.1):
    for width_ns in range(20, 200, step=5):
        scope.glitch.ext_offset = offset_us
        scope.glitch.width = width_ns
        
        reset_target()         # Assert NRST
        time.sleep(0.001)
        release_reset()        # Deassertion triggers glitch sequence
        time.sleep(0.1)        # Wait for boot
        
        result = probe_swd_access()   # Attempt flash read via OpenOCD
        
        if result == SUCCESS:
            log_parameters(offset_us, width_ns)
            dump_firmware()
            break
        elif result == CRASH:
            log_crash(offset_us, width_ns)
        else:
            log_no_effect(offset_us, width_ns)

Este varrimento pode exigir milhares de tentativas. Uma taxa de sucesso de 1-em-500 a 1-em-5000 é realista. Automação não é opcional — é a metodologia.

3. Confirmando Sucesso: Interrogação SWD Pós-Glitch

Após cada tentativa de glitch, você precisa determinar rapidamente se o bypass ocorreu antes do dispositivo se re-bloquear ou resetar. A sequência de verificação via OpenOCD é:

# Attempt connection and read FLASH_OBR register
openocd -f interface/cmsis-dap.cfg -f target/stm32f1x.cfg \
        -c "init; halt; mdw 0x4002201C; exit"

O registro em 0x4002201C é FLASH_OBR. Se bit 1 (RDPRT) ler como 0 pós-glitch, a verificação de proteção foi bypassada na instância em execução. Você então imediatamente faz dump da flash antes de qualquer reset ocorrer:

openocd -f interface/cmsis-dap.cfg -f target/stm32f1x.cfg \
        -c "init; halt; dump_image firmware.bin 0x08000000 0x20000; exit"

Nuance crítica: Um glitch bem-sucedido não remove permanentemente RDP. O Option Byte em flash ainda mantém o valor de proteção. O que você conseguiu é um bypass transitório — a verificação de permissão da CPU em execução foi faultada, mas um hardware reset irá re-bloquear o dispositivo. Você deve fazer dump do firmware no mesmo ciclo de potência que o glitch.

4. Topologia do Espaço de Parâmetros e Por Que Importa

Entender a forma do espaço de sucesso torna o varrimento mais eficiente. O espaço de parâmetros de glitch tem uma estrutura característica:

Eixos: Glitch Width (vertical) vs Glitch Offset (horizontal). A região de sucesso é uma faixa estreita entre sem efeito e crash.

A região de sucesso não é uniformemente distribuída — tende a formar bandas diagonais estreitas. Isso é porque ambas as dimensões interagem: um pulso ligeiramente mais largo a um offset posterior pode se comportar igual a um pulso mais estreito a um offset anterior. Pesquisadores experientes começam com um varrimento de grade grossa para localizar a região de sucesso aproximada, depois refinam com um varrimento fino em aquele neighborhood.

Temperatura afeta significativamente a janela de parâmetro. Silício mais frio exige parâmetros de glitch diferentes de silício morno. Se você está tendo dificuldade em reproduzir um hit, variação de temperatura é frequentemente o culpado. Alguns pesquisadores deliberadamente resfriam alvos (embora isso introduza risco de condensação) para ampliar a janela de sucesso.

5. Validação de Osciloscópio: Vendo O Que Você Está Fazendo

Rodar na escuridão é como desperdiçar dias. Antes de começar a varrimentos de parâmetro, valide seu setup físico com um osciloscópio:

• Teste VDD diretamente no pino VDD do alvo (não na alimentação)
• Trigger na borda crescente de NRST
• Verifique que seu circuito de glitch produz um dip limpo e agudo da profundidade e duração esperadas
• Verifique ringing ou oscilações secundárias — estas podem causar glitches adicionais não intencionais

Um glitch bem formado se parece com um dip retangular agudo: borda caindo rápida (< 10 ns), fundo plano na profundidade desejada (tipicamente 0.5–1.5 V abaixo da nominal 3.3 V), recuperação rápida. Um glitch ruim se parece com um dip arredondado com uma cauda longa — ainda capaz de derrubar o dispositivo mas improvável de produzir uma falha precisa.

O osciloscópio não é equipamento opcional. É como você fecha o loop de feedback entre o que seu software pensa estar acontecendo e o que silício está realmente experimentando.

Alternativas & Comparação

Clock glitching é uma alternativa viável — inserindo um ciclo de glitch no clock externo para causar uma falha de instrução única similar. Requer que o STM32F1 rode de uma fonte de clock externo (HSE), o que nem sempre é o caso. Voltage glitching funciona independentemente da fonte de clock.

EM fault injection usa uma pequena bobina acionada por um pulso de corrente alta para induzir mudanças de corrente localizadas na superfície do die. Não requer acesso VDD físico mas exige precisão espacial (um estágio XY) e equipamento mais caro. Brilha em dispositivos com linhas VDD inacessíveis ou monitoramento ativo de potência.

Decapping e microprobing é a opção nuclear — remover quimicamente ou mecanicamente o pacote, expor o die, e testar nós internos diretamente. Fornece resultados definitivos mas destrói a amostra e requer equipamento de nível laboratorial.

Para o STM32F1, o voltage glitch crowbar atinge a melhor interseção de baixo custo, complexidade moderada, e taxa de sucesso alta, o que é por que permanece a demonstração canônica para essa família de chips.

Leitura adicional e referências

• "Shaping the Glitch" — Miloš Žúbor, Jakub Breier et al. (TCHES 2019) — análise rigorosa de espaços de parâmetros de glitch
• Documentação ChipWhisperer de Colin O'Flynn — chipwhisperer.readthedocs.io
• "Breaking Code Read Protection on the NXP LPC-family Microcontrollers" — Obermaier & Tatschner (WOOT 2017)
• AN4701 — ST Application Note on RDP — documentação do fornecedor sobre níveis de proteção e limitações
• "Fault Injection Attacks on Cryptographic Devices" — Verbauwhede et al.
• Wallet.fail (35C3) — ataque de glitch na carteira de hardware Trezor

Pratique essas técnicas apenas em hardware que você possui ou está explicitamente autorizado a testar.