Segurança de Alarmes Automotivos na Rússia: Uma Análise Profunda (Parte 1)
Este artigo mergulha nas vulnerabilidades de segurança de sistemas de alarme automotivo populares no mercado russo. O autor detalha os métodos de engenharia reversa e as descobertas, incluindo falhas na criptografia e na verificação de assinaturas de firmware.
MundiX News·01 de julho de 2026·15 min de leitura·👁 1 views
Olá a todos. Desta vez, decidi abordar a segurança de dispositivos utilizados pela maioria dos proprietários de automóveis. Falaremos sobre os três sistemas de alarme automotivo (imobilizadores) mais populares no mercado russo.
Para adiantar, informo que os relatórios sobre todas as falhas encontradas foram enviados aos fabricantes, bem como ao FSTEC da Rússia. Da resposta do regulador, soube que os relatórios não serão registrados como vulnerabilidades, pois "este meio de software e hardware não é utilizado em objetos de GIS e KII". Os fabricantes, por sua vez, informaram que as deficiências descritas serão corrigidas em novos modelos de alarmes. Para informações sobre o que fazer com os modelos já existentes, recomendo contatar os fabricantes.
Sobre o Projeto
As pesquisas foram realizadas com um grande intervalo de tempo. A primeira foi realizada no final de 2022, e as outras duas em 2024, com um pequeno intervalo. O objetivo do projeto não era de forma alguma encontrar vulnerabilidades, mas sim um simples desafio: se algo está criptografado, eu quero descriptografá-lo. A experiência foi bastante interessante. É sobre ela que falaremos neste artigo.
Sobre o Primeiro Dispositivo Pesquisado
O que me agrada no meu trabalho é a oportunidade de dedicar tempo a pesquisas próprias. Assim, em busca de um "cobaia", decidi olhar o conteúdo de uma caixinha que estava na prateleira com artefatos de projetos anteriores. A descrição nela dizia: "Microalarme de segurança e anti-roubo — Imobilizador CAN PANDECT X-1000 BT", e dentro da caixa havia alguns fios, um manual, um botão em um cabo, o módulo principal do alarme, além de um chaveiro e um "bipador".
[Imagem: Caixa com o alarme e seu conteúdo]
A primeira coisa a fazer é entender o que procurar e onde cavar. E o mais fácil é começar com... a inicialização do alarme. Mais precisamente, com sua configuração básica e conexão ao PC e smartphone. Leio o manual, instalo os aplicativos correspondentes, conecto o cabo USB e, claro, não me esqueço de coletar o tráfego USB de tudo isso usando o Wireshark para análise posterior.
[Imagem: Manual de conexão de energia e outros fios]
Por exemplo, um dos vetores potenciais de pesquisa pode ser o processo de atualização do dispositivo via USB. Em teoria, se eu conseguir entender como ele funciona e encontrar deficiências nele, poderei criar meus próprios arquivos de atualização e carregá-los no alarme.
[Imagem: Interface do software do fabricante]
Processo de Atualização
De acordo com o Wireshark, o dispositivo USB conectado é reconhecido como HID, e toda a comunicação no tráfego parece um conjunto de pacotes GET_REPORT / SET_REPORT. Se olharmos atentamente para o conteúdo de um dos primeiros pacotes, podemos notar que os bytes enviados são idênticos aos bytes no cabeçalho do arquivo de firmware (que encontrei no site oficial do fabricante). Por que decidi que era o cabeçalho? Já que o conteúdo vai em um pacote separado, tem coincidências com o início do arquivo e contém a string de versão — é definitivamente o cabeçalho!
[Imagem: String de versão em um dos pacotes]
[Imagem: Comparação do cabeçalho do firmware e do pacote enviado]
Como pode ser visto, a partir do próximo pacote, o próprio conteúdo criptografado do firmware (corpo) é enviado — 64 bytes por vez (limite HID?). É possível fazer algo com esse conhecimento?
[Imagem: Comparação do corpo do firmware e do pacote enviado]
Decidi mudar um único bit em algum lugar do cabeçalho do firmware, sem enviar o resto (ou, se necessário, enviar o primeiro bloco do corpo) e ver o que aconteceria. Resultado — o software do alarme parou de reconhecer o dispositivo, embora o próprio dispositivo USB apareça, e as luzes do alarme indiquem que ele está iniciando algo. Portanto, é preciso entender o que exatamente está dando errado e por que o software parou de "reconhecer". Uma pessoa normal estudaria o tráfego USB, mas eu, por algum motivo, fui estudar o próprio utilitário.
[Imagem: Mudando 1 bit no pacote com o cabeçalho]
O Utilitário do Fabricante
Um estudo rápido do programa mostrou o seguinte:
Ele definitivamente usa JS.
Compilado usando o Awesomium SDK.
Não contém strings legíveis.
O arquivo data.asr na verdade é um arquivo ZIP protegido por senha.
Sem depuração, não dá para entender.
Senha do data.asr
Após uma breve depuração do aplicativo, consegui descobrir a senha do arquivo: aoeuiqjkxb. Em seguida, adicionei ao arquivo js (não me lembro mais qual) uma linha que ajudaria a entender as diferenças entre os dois alarmes: um quase brickado e um normal.
[Imagem: Prints de depuração]
O resultado dessa depuração mostrou diferenças no campo de versão. Em um caso, o conteúdo do campo version estava normal, e no outro — ilegível. Com base nisso, podemos tirar as seguintes conclusões:
O conteúdo do pacote USB com o cabeçalho modificado foi imediatamente gravado na memória interna do dispositivo.
Ao interagir via USB, o conteúdo é lido da memória, o software não consegue compará-lo com a string de versão normal do firmware, e o dispositivo deixa de ser visível.
[Imagem: Resultado do patch de um bit]
Para experimentos futuros, eu queria restaurar o funcionamento do alarme, então coloquei um breakpoint na saída de ReadFile() e simplesmente substituí os bytes necessários em lpBuffer pelos corretos. Graças a isso, consegui iniciar o processo de atualização completamente e regravar um cabeçalho normal, após o qual o alarme voltou à vida.
[Imagem: Ponteiro para o buffer com o resultado]
Continuando a Atualização
Se permitirmos que o processo de atualização seja concluído, mantendo o bit modificado no cabeçalho, podemos descobrir: qual quer que seja a soma de verificação (assinatura digital), ela é verificada no final, após o envio de todos os bytes. Isso seria indicado por uma mensagem de erro no programa (desculpe, mas não tenho o print salvo devido à antiguidade do projeto).
É possível agora juntar todo o conhecimento obtido em um script e substituir o firmware do alarme pelo meu? Infelizmente, ainda não. Jogar "me desbricka" após cada tentativa não era muito atraente para mim. Portanto, foi decidido finalmente desmontar o dispositivo e ver o que poderia ser feito, possuindo, por assim dizer, "algumas habilidades de solda".
O Mundo Interior
No bloco principal do alarme, foram encontrados chips com firmware próprio:
STM32 (não me lembro mais qual).
nRF52832 (módulo principal).
nRF51822 (chaveiro).
Também no módulo principal, foram facilmente encontradas duas fileiras de cinco pinos cada: uma perto do STM32, a outra — perto do nRF52. A medição de continuidade mostrou que dois dos cinco pinos são terra e alimentação em ambos os grupos de contatos. Os demais (não me lembro por quê, mas talvez porque na época os contatos dos chips eram muito pequenos para mim) eu não medi, e imediatamente decidi que era SWD. Após uma breve tentativa de várias opções, foi isso mesmo.
[Imagem: Depuração]
Conectando o depurador JLink ao STM32, consegui descobrir que a memória interna do chip não é lida, mas a SRAM pode ser lida — isso indica que o modo RDP1 está ativado. Em princípio, já é possível trabalhar com isso. A ideia era a seguinte:
Iniciar o modo de atualização de firmware.
Enviar o primeiro bloco.
Conectar o depurador.
Ler a SRAM para o arquivo dump1.bin.
Enviar o segundo bloco.
Ler a SRAM para o arquivo dump2.bin.
Comparar os arquivos e procurar por padrões.
Surgiu um problema com essa sequência: após conectar o depurador, o alarme não conseguia receber pacotes USB — isso está relacionado ao funcionamento do modo RDP1, que não permite uma "pausa" completa no STM32. Foi necessário adaptar o algoritmo: na etapa de envio do segundo bloco, primeiro reiniciar o dispositivo, enviar o primeiro bloco, depois o segundo e, após isso, ler a SRAM.
Automação
Para automatizar o processo, pedi a um colega para escrever um pequeno "dropper" de energia no Arduino, que esperaria por um comando de reset em um dos pinos GPIO e, usando o MAX4619 (switch), interromperia a linha de 5V no cabo USB por um tempo.
[Imagem: MAX4619]
[Código: Script para Arduino]
Como resultado, além de grandes áreas com memória não inicializada, foi possível detectar duas regiões onde algo interessante estava acontecendo. Mas não pude dizer nada definitivo sobre elas — era preciso coletar mais dumps, cerca de mil.
[Imagem: Setup básico]
Infelizmente, as medições da duração de uma iteração, juntamente com a progressão aritmética do tempo de carregamento de cada bloco subsequente (lembre-se que cada novo bloco exigia o carregamento de todos os anteriores), mostraram um quadro desanimador: o firmware completo levaria cerca de três meses, e mil blocos — aproximadamente uma semana. Os números são aproximados — devido à antiguidade do projeto, não consigo dizer com mais precisão. No entanto, algo precisava ser feito com isso.
[Imagem: Bytes alterados na SRAM após receber o cabeçalho]
[Imagem: Comparação da SRAM após receber o primeiro bloco criptografado]
Super Automação
Felizmente, nas prateleiras com artefatos, encontrei mais dois alarmes deste modelo (totalizando três). Além disso, tínhamos dois J-Link no trabalho, e eu trouxe um EDU de casa. O que mais pode ser necessário para uma automação de qualidade, além de três cabos USB preparados, vocês acham?
A resposta correta: três clipes de papel enrolados em fita isolante. Não me perguntem por quê — não me lembro. Mas aqui está uma foto com a prova de que isso era definitivamente necessário.
[Imagem: Algo que você definitivamente não viu em nenhum outro lugar]
Após depurar essa construção, deixei-a funcionando por uma semana inteira... Pensei eu, até chegar ao trabalho no dia seguinte. Lá me esperava uma surpresa: uma janela do JLink com a oferta de aceitar os termos de uso da versão EDU. Muitos que trabalham com este depurador veem a janela constantemente, mas com certeza, assim como eu, clicam mecanicamente no botão Accept e se esquecem dela. Como se descobriu, o próprio JLink se lembra dela exatamente à meia-noite. Como contornei isso — é outra questão e, talvez, não valha a pena mencionar neste artigo.
[Imagem: Aquela janela]
Alguns Sucessos
Após alguns dias, foram coletados dumps de SRAM suficientes para detectar e atribuir neles:
8 bytes criptografados do bloco atual,
8 bytes da chave XOR para este bloco,
8 bytes descriptografados.
Assim, se coletarmos bytes suficientes da chave XOR para os primeiros N bytes do firmware, podemos criptografar o nosso próprio, que, por exemplo, bloco a bloco, despejará na SRAM o conteúdo do bootloader (que, presumivelmente, conterá o algoritmo de criptografia completo). Dito e feito! Os detalhes estarão no final do artigo, e por enquanto, vamos passar para o segundo chip na placa do alarme — o nRF52.
nRF52 e nRF51
No momento do trabalho no projeto, infelizmente, eu não tinha experiência com falhas de energia (fault injection), mas meu colega, felizmente, tinha. Portanto, com sua ajuda, e também com base em um artigo publicamente disponível descrevendo uma vulnerabilidade no chip nRF52 (Wayback Machine), obtive um dump completo do firmware da parte sem fio do alarme.
[Imagem: Locais de solda para nRF52 e capacitores de desacoplamento]
[Imagem: Circuito típico para nRF52]
Quanto ao chaveiro: ele tem um chip nRF51 semelhante, que não requer técnicas de bypass de proteção tão avançadas. E, claro, um artigo sobre como fazer um dump do firmware dele (Wayback Machine).
[Imagem: Chaveiro]
[Imagem: Processo de exploração da vulnerabilidade no nRF51]
Em vez de Conclusões
O algoritmo usado para criptografar o firmware acabou sendo o GOST 28147-89. Graças à capacidade de obter o conteúdo da SRAM passo a passo e ao uso incorreto do algoritmo (resultados intermediários do trabalho permaneciam na memória), consegui restaurar completamente o firmware do bloco principal e estudar o mecanismo de sua atualização via USB. E também escrevi um script que permite descriptografar completamente os arquivos de atualização e criptografá-los de volta.
[Imagem: Implementação manual do GOST 28147-89]
Interação com o Fabricante
No final de 2022, os resultados que poderiam ser enviados ao fornecedor com tranquilidade foram formados. Escrevi uma carta com uma descrição detalhada dos passos realizados, bem como recomendações para corrigir os problemas encontrados. O fabricante informou que estava ciente das vulnerabilidades identificadas, mas o imobilizador já havia sido descontinuado. As correções serão levadas em conta em modelos futuros.
Resultados
O que obtemos no final:
O algoritmo de criptografia GOST é usado incorretamente (vestígios da chave aplicada permanecem na memória).
A verificação de assinatura de arquivos não é implementada.
É possível carregar um firmware modificado no alarme (incluindo bootloaders de baixo nível), seja alterando os arquivos de atualização ou através dos pinos SWD.
P.S. Obrigado pela atenção. Em breve publicarei um artigo sobre o próximo fabricante de alarmes automotivos — Starline. Fiquem ligados!
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Olá a todos. Desta vez, decidi abordar a segurança de dispositivos utilizados pela maioria dos proprietários de automóveis. Falaremos sobre os três sistemas de alarme automotivo (imobilizadores) mais populares no mercado russo.
Para adiantar, informo que os relatórios sobre todas as falhas encontradas foram enviados aos fabricantes, bem como ao FSTEC da Rússia. Da resposta do regulador, soube que os relatórios não serão registrados como vulnerabilidades, pois "este meio de software e hardware não é utilizado em objetos de GIS e KII". Os fabricantes, por sua vez, informaram que as deficiências descritas serão corrigidas em novos modelos de alarmes. Para informações sobre o que fazer com os modelos já existentes, recomendo contatar os fabricantes.
Sobre o Projeto
As pesquisas foram realizadas com um grande intervalo de tempo. A primeira foi realizada no final de 2022, e as outras duas em 2024, com um pequeno intervalo. O objetivo do projeto não era de forma alguma encontrar vulnerabilidades, mas sim um simples desafio: se algo está criptografado, eu quero descriptografá-lo. A experiência foi bastante interessante. É sobre ela que falaremos neste artigo.
Sobre o Primeiro Dispositivo Pesquisado
O que me agrada no meu trabalho é a oportunidade de dedicar tempo a pesquisas próprias. Assim, em busca de um "cobaia", decidi olhar o conteúdo de uma caixinha que estava na prateleira com artefatos de projetos anteriores. A descrição nela dizia: "Microalarme de segurança e anti-roubo — Imobilizador CAN PANDECT X-1000 BT", e dentro da caixa havia alguns fios, um manual, um botão em um cabo, o módulo principal do alarme, além de um chaveiro e um "bipador".
[Imagem: Caixa com o alarme e seu conteúdo]
A primeira coisa a fazer é entender o que procurar e onde cavar. E o mais fácil é começar com... a inicialização do alarme. Mais precisamente, com sua configuração básica e conexão ao PC e smartphone. Leio o manual, instalo os aplicativos correspondentes, conecto o cabo USB e, claro, não me esqueço de coletar o tráfego USB de tudo isso usando o Wireshark para análise posterior.
[Imagem: Manual de conexão de energia e outros fios]
Por exemplo, um dos vetores potenciais de pesquisa pode ser o processo de atualização do dispositivo via USB. Em teoria, se eu conseguir entender como ele funciona e encontrar deficiências nele, poderei criar meus próprios arquivos de atualização e carregá-los no alarme.
[Imagem: Interface do software do fabricante]
Processo de Atualização
De acordo com o Wireshark, o dispositivo USB conectado é reconhecido como HID, e toda a comunicação no tráfego parece um conjunto de pacotes GET_REPORT / SET_REPORT. Se olharmos atentamente para o conteúdo de um dos primeiros pacotes, podemos notar que os bytes enviados são idênticos aos bytes no cabeçalho do arquivo de firmware (que encontrei no site oficial do fabricante). Por que decidi que era o cabeçalho? Já que o conteúdo vai em um pacote separado, tem coincidências com o início do arquivo e contém a string de versão — é definitivamente o cabeçalho!
[Imagem: String de versão em um dos pacotes]
[Imagem: Comparação do cabeçalho do firmware e do pacote enviado]
Como pode ser visto, a partir do próximo pacote, o próprio conteúdo criptografado do firmware (corpo) é enviado — 64 bytes por vez (limite HID?). É possível fazer algo com esse conhecimento?
[Imagem: Comparação do corpo do firmware e do pacote enviado]
Decidi mudar um único bit em algum lugar do cabeçalho do firmware, sem enviar o resto (ou, se necessário, enviar o primeiro bloco do corpo) e ver o que aconteceria. Resultado — o software do alarme parou de reconhecer o dispositivo, embora o próprio dispositivo USB apareça, e as luzes do alarme indiquem que ele está iniciando algo. Portanto, é preciso entender o que exatamente está dando errado e por que o software parou de "reconhecer". Uma pessoa normal estudaria o tráfego USB, mas eu, por algum motivo, fui estudar o próprio utilitário.
[Imagem: Mudando 1 bit no pacote com o cabeçalho]
O Utilitário do Fabricante
Um estudo rápido do programa mostrou o seguinte:
Ele definitivamente usa JS.
Compilado usando o Awesomium SDK.
Não contém strings legíveis.
O arquivo data.asr na verdade é um arquivo ZIP protegido por senha.
Sem depuração, não dá para entender.
Senha do data.asr
Após uma breve depuração do aplicativo, consegui descobrir a senha do arquivo: aoeuiqjkxb. Em seguida, adicionei ao arquivo js (não me lembro mais qual) uma linha que ajudaria a entender as diferenças entre os dois alarmes: um quase brickado e um normal.
[Imagem: Prints de depuração]
O resultado dessa depuração mostrou diferenças no campo de versão. Em um caso, o conteúdo do campo version estava normal, e no outro — ilegível. Com base nisso, podemos tirar as seguintes conclusões:
O conteúdo do pacote USB com o cabeçalho modificado foi imediatamente gravado na memória interna do dispositivo.
Ao interagir via USB, o conteúdo é lido da memória, o software não consegue compará-lo com a string de versão normal do firmware, e o dispositivo deixa de ser visível.
[Imagem: Resultado do patch de um bit]
Para experimentos futuros, eu queria restaurar o funcionamento do alarme, então coloquei um breakpoint na saída de ReadFile() e simplesmente substituí os bytes necessários em lpBuffer pelos corretos. Graças a isso, consegui iniciar o processo de atualização completamente e regravar um cabeçalho normal, após o qual o alarme voltou à vida.
[Imagem: Ponteiro para o buffer com o resultado]
Continuando a Atualização
Se permitirmos que o processo de atualização seja concluído, mantendo o bit modificado no cabeçalho, podemos descobrir: qual quer que seja a soma de verificação (assinatura digital), ela é verificada no final, após o envio de todos os bytes. Isso seria indicado por uma mensagem de erro no programa (desculpe, mas não tenho o print salvo devido à antiguidade do projeto).
É possível agora juntar todo o conhecimento obtido em um script e substituir o firmware do alarme pelo meu? Infelizmente, ainda não. Jogar "me desbricka" após cada tentativa não era muito atraente para mim. Portanto, foi decidido finalmente desmontar o dispositivo e ver o que poderia ser feito, possuindo, por assim dizer, "algumas habilidades de solda".
O Mundo Interior
No bloco principal do alarme, foram encontrados chips com firmware próprio:
STM32 (não me lembro mais qual).
nRF52832 (módulo principal).
nRF51822 (chaveiro).
Também no módulo principal, foram facilmente encontradas duas fileiras de cinco pinos cada: uma perto do STM32, a outra — perto do nRF52. A medição de continuidade mostrou que dois dos cinco pinos são terra e alimentação em ambos os grupos de contatos. Os demais (não me lembro por quê, mas talvez porque na época os contatos dos chips eram muito pequenos para mim) eu não medi, e imediatamente decidi que era SWD. Após uma breve tentativa de várias opções, foi isso mesmo.
[Imagem: Depuração]
Conectando o depurador JLink ao STM32, consegui descobrir que a memória interna do chip não é lida, mas a SRAM pode ser lida — isso indica que o modo RDP1 está ativado. Em princípio, já é possível trabalhar com isso. A ideia era a seguinte:
Iniciar o modo de atualização de firmware.
Enviar o primeiro bloco.
Conectar o depurador.
Ler a SRAM para o arquivo dump1.bin.
Enviar o segundo bloco.
Ler a SRAM para o arquivo dump2.bin.
Comparar os arquivos e procurar por padrões.
Surgiu um problema com essa sequência: após conectar o depurador, o alarme não conseguia receber pacotes USB — isso está relacionado ao funcionamento do modo RDP1, que não permite uma "pausa" completa no STM32. Foi necessário adaptar o algoritmo: na etapa de envio do segundo bloco, primeiro reiniciar o dispositivo, enviar o primeiro bloco, depois o segundo e, após isso, ler a SRAM.
Automação
Para automatizar o processo, pedi a um colega para escrever um pequeno "dropper" de energia no Arduino, que esperaria por um comando de reset em um dos pinos GPIO e, usando o MAX4619 (switch), interromperia a linha de 5V no cabo USB por um tempo.
[Imagem: MAX4619]
[Código: Script para Arduino]
Como resultado, além de grandes áreas com memória não inicializada, foi possível detectar duas regiões onde algo interessante estava acontecendo. Mas não pude dizer nada definitivo sobre elas — era preciso coletar mais dumps, cerca de mil.
[Imagem: Setup básico]
Infelizmente, as medições da duração de uma iteração, juntamente com a progressão aritmética do tempo de carregamento de cada bloco subsequente (lembre-se que cada novo bloco exigia o carregamento de todos os anteriores), mostraram um quadro desanimador: o firmware completo levaria cerca de três meses, e mil blocos — aproximadamente uma semana. Os números são aproximados — devido à antiguidade do projeto, não consigo dizer com mais precisão. No entanto, algo precisava ser feito com isso.
[Imagem: Bytes alterados na SRAM após receber o cabeçalho]
[Imagem: Comparação da SRAM após receber o primeiro bloco criptografado]
Super Automação
Felizmente, nas prateleiras com artefatos, encontrei mais dois alarmes deste modelo (totalizando três). Além disso, tínhamos dois J-Link no trabalho, e eu trouxe um EDU de casa. O que mais pode ser necessário para uma automação de qualidade, além de três cabos USB preparados, vocês acham?
A resposta correta: três clipes de papel enrolados em fita isolante. Não me perguntem por quê — não me lembro. Mas aqui está uma foto com a prova de que isso era definitivamente necessário.
[Imagem: Algo que você definitivamente não viu em nenhum outro lugar]
Após depurar essa construção, deixei-a funcionando por uma semana inteira... Pensei eu, até chegar ao trabalho no dia seguinte. Lá me esperava uma surpresa: uma janela do JLink com a oferta de aceitar os termos de uso da versão EDU. Muitos que trabalham com este depurador veem a janela constantemente, mas com certeza, assim como eu, clicam mecanicamente no botão Accept e se esquecem dela. Como se descobriu, o próprio JLink se lembra dela exatamente à meia-noite. Como contornei isso — é outra questão e, talvez, não valha a pena mencionar neste artigo.
[Imagem: Aquela janela]
Alguns Sucessos
Após alguns dias, foram coletados dumps de SRAM suficientes para detectar e atribuir neles:
8 bytes criptografados do bloco atual,
8 bytes da chave XOR para este bloco,
8 bytes descriptografados.
Assim, se coletarmos bytes suficientes da chave XOR para os primeiros N bytes do firmware, podemos criptografar o nosso próprio, que, por exemplo, bloco a bloco, despejará na SRAM o conteúdo do bootloader (que, presumivelmente, conterá o algoritmo de criptografia completo). Dito e feito! Os detalhes estarão no final do artigo, e por enquanto, vamos passar para o segundo chip na placa do alarme — o nRF52.
nRF52 e nRF51
No momento do trabalho no projeto, infelizmente, eu não tinha experiência com falhas de energia (fault injection), mas meu colega, felizmente, tinha. Portanto, com sua ajuda, e também com base em um artigo publicamente disponível descrevendo uma vulnerabilidade no chip nRF52 (Wayback Machine), obtive um dump completo do firmware da parte sem fio do alarme.
[Imagem: Locais de solda para nRF52 e capacitores de desacoplamento]
[Imagem: Circuito típico para nRF52]
Quanto ao chaveiro: ele tem um chip nRF51 semelhante, que não requer técnicas de bypass de proteção tão avançadas. E, claro, um artigo sobre como fazer um dump do firmware dele (Wayback Machine).
[Imagem: Chaveiro]
[Imagem: Processo de exploração da vulnerabilidade no nRF51]
Em vez de Conclusões
O algoritmo usado para criptografar o firmware acabou sendo o GOST 28147-89. Graças à capacidade de obter o conteúdo da SRAM passo a passo e ao uso incorreto do algoritmo (resultados intermediários do trabalho permaneciam na memória), consegui restaurar completamente o firmware do bloco principal e estudar o mecanismo de sua atualização via USB. E também escrevi um script que permite descriptografar completamente os arquivos de atualização e criptografá-los de volta.
[Imagem: Implementação manual do GOST 28147-89]
Interação com o Fabricante
No final de 2022, os resultados que poderiam ser enviados ao fornecedor com tranquilidade foram formados. Escrevi uma carta com uma descrição detalhada dos passos realizados, bem como recomendações para corrigir os problemas encontrados. O fabricante informou que estava ciente das vulnerabilidades identificadas, mas o imobilizador já havia sido descontinuado. As correções serão levadas em conta em modelos futuros.
Resultados
O que obtemos no final:
O algoritmo de criptografia GOST é usado incorretamente (vestígios da chave aplicada permanecem na memória).
A verificação de assinatura de arquivos não é implementada.
É possível carregar um firmware modificado no alarme (incluindo bootloaders de baixo nível), seja alterando os arquivos de atualização ou através dos pinos SWD.
P.S. Obrigado pela atenção. Em breve publicarei um artigo sobre o próximo fabricante de alarmes automotivos — Starline. Fiquem ligados!
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
