Honda Civics e o valet malicioso

• O head unit do Honda Civic modelo 2021 pode aceitar atualizações pelo caminho de update via USB assinadas com chaves públicas de teste do AOSP, permitindo que alguém com acesso físico execute código arbitrário
• As atualizações da Honda são aplicadas via Android recovery e, mesmo com o binário recovery modificado, a lógica de verificação de assinatura verify_file corresponde à do AOSP padrão
• Ao assinar com a chave pública de teste do AOSP e formatar corretamente o pendrive, é possível instalar qualquer código desejado sem su nem setuid; esse ataque é chamado de EvilValet
• A nova ferramenta ota-builder facilita preparar arquivos de atualização aceitos pelo head unit, e o apk-rebuilder converte arquivos de atualização em uma árvore de saída útil para engenharia reversa
• O projeto já concluiu a maior parte da investigação, mas o repositório não foi abandonado; ainda são necessárias contribuições em informações de versão, toolchain, temas customizados e melhorias no mapeamento de AIDL

---

Contexto da atualização do projeto

• Há 3 anos foi publicado o trabalho inicial para entender e fazer engenharia reversa do head unit do Honda Civic modelo 2021, e esta atualização resume o progresso desde então
• A reação inicial foi muito encorajadora, e o maior avanço veio do processo de entender o mecanismo de atualização

As chaves do reino

• A Honda oferece suporte a atualização do head unit via USB e, no fim, um arquivo de atualização AOSP assinado dentro do pendrive é preparado e aplicado pelo Android recovery
• Existem várias verificações específicas da Honda, mas a chave pública de teste do AOSP conhecida publicamente continuava em res/keys, e a lógica de assinatura verify_file do binário recovery modificado também corresponde à do AOSP padrão
• Ao formatar o pendrive de forma adequada e assinar com a chave pública de teste do AOSP, é possível instalar qualquer conteúdo desejado no head unit sem acesso root prévio
  • Não é necessário o tipo comum de acesso root que envolve definir setuid em su
  • Se o head unit estiver ligado e o invasor tiver acesso físico à porta USB mais frontal, é possível executar código arbitrário no head unit pelo caminho de atualização
• O ataque é semelhante a um evil maid attack, em que há acesso físico a um quarto de hotel, mas como aqui é preciso acessar o interior do carro, ele foi chamado de EvilValet
  • Em um cenário de exemplo, um manobrista de hotel instala a atualização por USB e, quando o carro é devolvido, o motorista não percebe que o head unit foi alterado
• Este texto não é uma documentação técnica detalhada; os detalhes completos estão em Display Audio Update Files
• A nova ferramenta ota-builder facilita a preparação de arquivos de atualização aceitos pelo head unit
  • Ainda está em estágio inicial, mas por exemplo já tornou trivial criar um arquivo de atualização que instala um binário su com setuid habilitado
• Há fortes razões para acreditar que todas as atualizações sejam assinadas com a chave pública de teste do AOSP, mas não houve acesso a todos os arquivos de atualização oficiais possíveis nem aos sistemas de arquivos de todas as variantes do head unit
  • Nos head units verificados, havia uma chave de teste do AOSP em res/keys, mas como havia histórico de instalação do HondaHack, também é possível que a chave tenha sido injetada no keystore
  • O arquivo de atualização de software da UE disponível publicamente, MRC_EU_SW_v12_4.zip, é assinado com a chave de teste e foi baixado de um fórum público sem modificações
  • É muito provável que todas as atualizações sejam assinadas com a chave de teste do AOSP, mas ainda são necessárias contribuições para sustentar ou refutar essa hipótese

Construção de ferramentas

• Além do processo de atualização, o trabalho mais útil foi o desenvolvimento do apk-rebuilder
• O apk-rebuilder recebe como entrada arquivos de atualização do Honda Civic obtidos na internet e gera uma árvore de arquivos de saída limpa, automatizando tarefas que um engenheiro reverso precisaria fazer manualmente
  • Faz interpretação de recursos
  • Faz reconstrução de código .smali
  • Faz reempacotamento de arquivos APK
  • Faz extração de ramdisk
  • E também outras tarefas
• Como o código-fonte real da Honda não pode ser publicado, o apk-rebuilder atua como uma função que recebe arquivos de atualização não hospedados no repositório público e gera código .smali da Honda, recursos de imagem e outros artefatos
• A saída gerada segue uma estrutura de diretórios clara, permitindo referência na documentação sem enviar os próprios arquivos sensíveis

Trabalho restante e pedido de contribuições

• Versões conhecidas

  • O processo de atualização é vulnerável e depende fortemente do número da versão
  • O número da versão pode ser falsificado, portanto isso não limita a capacidade de executar código não assinado
  • Para criar um arquivo de atualização, é preciso saber qual versão o head unit espera
  • Alterações no software do head unit que não correspondam ao build em uso podem causar comportamento inesperado e um recovery loop
  • Usuários que dirigem um Honda Civic de 10ª geração e têm familiaridade técnica podem contribuir para a seção Known Versions, Display Audio Software do repositório
  • Usuários especialmente ousados podem ler o código do ota-builder e tentar gravar uma atualização, mas se o head unit diferir do dispositivo de referência, ele pode entrar em recovery loop e sofrer soft brick

• Toolchain

  • Existe uma toolchain experimental e ainda em desenvolvimento na máquina local
  • Essa toolchain recebe código .c candidato e o compila para ARMv7 com a mesma versão de compilador e as mesmas flags de build do binário original do fornecedor
  • Ela foi essencial para o trabalho de entender o processo de atualização
  • Na forma atual, usa muito Docker, mas está desorganizada e fortemente ajustada a fluxos de trabalho específicos; a intenção é publicar uma implementação mais limpa

• Temas customizados

  • Enquanto fazia vibe-coding do apk-renderer, houve alguma exploração de temas customizados
  • Os temas customizados ficam dentro de um fork do framework AOSP da Mitsubishi, e os apps do head unit foram reduzidos esperando IDs de recurso hardcoded, o que provavelmente dificulta a distribuição
  • Para distribuir temas customizados, provavelmente será necessário modificar cirurgicamente o framework do fornecedor e escrever ferramentas para automatizar isso
  • Esse trabalho não é simples e talvez não valha muito o esforço, mas contribuições são bem-vindas

• Melhorias no aidl-rebuilder

  • Foi iniciado o trabalho em uma ferramenta que analisa arquivos .smali para gerar e mapear todas as interfaces AIDL do head unit
  • A ferramenta funciona, mas sua precisão ainda não foi revisada o suficiente
  • Esse trabalho abre possibilidades para apps customizados, como um velocímetro virtual

Documentação e reflexões sobre LLM

• Foi dada prioridade maior à instrumentação de ferramentas do que a documentos de referência
• Se ferramentas confiáveis e determinísticas mapearem o código do head unit para formas mais fáceis de entender, os usuários poderão consultar essas formas com LLMs para responder perguntas específicas
• Como o código do head unit é a fonte da verdade, isso reduz a carga de manter documentos de referência que podem divergir do código real
• Guias para conectar ao head unit via ADB continuam úteis
• Quando o próprio código Java pode ser consumido por LLMs, manter documentação separada sobre o comportamento desse código Java se torna um peso de manutenção

Encerramento

• A maior parte da investigação planejada sobre o head unit já foi concluída
• É um projeto no qual ainda seria possível continuar mexendo, mas daqui para frente é provável que o foco mude para outros projetos
• O repositório não está abandonado, e PRs são sempre bem-vindos

[GN⁺]

Comentários do Hacker News

• A atualização do Honda Civic de 10ª geração é distribuída pela Honda em um pendrive USB de formato especial e, na prática, é um pacote de recuperação da época do Android 4.2.2rc1 com apenas uma verificação de versão adicionada pela Honda
  Essa verificação de versão pode ser burlada, e o pacote é assinado com a chave de teste pública do AOSP, então basta ter acesso físico à porta USB frontal para assinar e gravar um pacote arbitrário e executar código arbitrário na central multimídia
  Não é necessário root/su, isso foi testado até o fim em um Civic 2021, e também foi confirmado separadamente que os arquivos oficiais de atualização da UE usam assinatura com a chave de teste do AOSP

  • AOSP significa Android Open Source Project
  • As centrais multimídia da Acura do mesmo período também são baseadas em Android 4.x, então houve tentativa de analisá-las, mas o processo travou na etapa de conseguir os arquivos de atualização; fica a curiosidade de como esses arquivos foram obtidos
  • Há vários sistemas de infotainment de outros carros que também são baseados em AOSP. Ao baixar atualizações da Hyundai, a lembrança é de que eram essencialmente imagens Android

• A maioria dos carros nas ruas tem segurança péssima no infotainment e na eletrônica embarcada, e, com microfones, câmeras, receptores GNSS, Wi‑Fi e Bluetooth nos carros atuais, eles estão virando plataformas móveis de vigilância
  No Information Security Manual do governo australiano de março de 2026, foi adicionado um controle orientando a não conectar dispositivos governamentais ao infotainment do veículo e a não visualizar material sensível nem ter conversas sensíveis dentro ou perto de carros conectados
  https://www.cyber.gov.au/business-government/asds-cyber-secu...

  • NC não é o nível mais baixo no esquema de classificação de sensibilidade?
  • Acho isso razoável. É um rádio de carro, não um sistema central
    As pessoas que podem ser vulneráveis a esse tipo de ataque já têm procedimentos e equipamentos confiáveis separados para trabalhar, e agências policiais dos EUA já tinham regras parecidas para carros alugados desde o surgimento do OnStar
    A maior parte dos dados telemáticos perigosos para o cidadão comum já está sendo vendida de qualquer forma

• De um lado, luta-se contra a perda contínua de propriedade sobre o hardware na maioria dos dispositivos do nosso dia a dia, mas, quando aparece um dispositivo mais aberto, o clima vira de ataque também
  No modelo de ameaça em tecnologia, sempre existiu a premissa de que, se o atacante tiver acesso físico ao dispositivo e tempo, acabou

  • Mas também não é como se estivesse aberto para o público modificar, certo? O fabricante precisa decidir a direção: ou abre tudo para que quem precisa possa endurecer o sistema por conta própria e entender os trade-offs, ou fecha tudo e faz de forma segura
    Esse meio-termo atual, em que o carro é um dispositivo de violação de privacidade que vigia o usuário durante toda a condução e, ao mesmo tempo, um dispositivo inseguro que entrega esses dados para qualquer pessoa minimamente interessada, é o pior cenário
  • Dá para ver situação parecida na vulnerabilidade do BitLocker recente. Fico curioso se novos casos serão resolvidos ou se pessoas serão presas por causa de hardware apreendido que agora pode ser desbloqueado
    Se os dados podem ser apreendidos, talvez seja melhor não mantê-los localmente; pela lei, em alguns lugares pode até haver obrigação de desbloqueá-los, mas nos EUA deveria ser seguro recusar-se a fornecer a senha
    Tecnicamente, Google e Apple melhoraram muito a segurança física, e o GrapheneOS vai além em cima dessa base, reduzindo a superfície de ataque e adicionando bons recursos. Em especial, com a ampla adoção do reinício automático, talvez dê para revisar a conclusão de que, em celulares, “acesso físico significa game over”
    https://grapheneos.org/features#auto-reboot
    https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
  • Isso não quer dizer que se possa desistir da segurança em dispositivos locais. Dispositivos físicos ainda têm proteção de login e talvez até criptografia total de disco
    Só porque um atacante suficientemente sofisticado e persistente pode comprometer qualquer dispositivo com acesso físico não significa que seja aceitável facilitar isso para qualquer um

• Aqui a Honda parece muito mais razoável do que outras montadoras
  Se um manobrista malicioso tiver acesso físico ao carro, ele não vai perder tempo hackeando a central multimídia; vai simplesmente esconder um dispositivo de escuta em algum lugar do veículo
  Além disso, não parece que motoristas de Civic seriam alvo de serviços de inteligência

  • Não sei se é piada, mas faz bem pouco sentido. Também é improvável que a Honda tenha feito isso de propósito
    A central multimídia normalmente contém informações históricas, como banco de dados SQLite de contatos restantes após sincronização, histórico de localização e dados antigos deixados em telemetria ou arquivos de log
    Além disso, a central costuma ter acesso ao barramento interno do veículo e, mesmo quando existe um firewall como um módulo gateway, ele tende a ser fraco. Como naquele caso famoso da Honda em que foi possível destravar e autorizar a partida sem material criptográfico, via barramento CAN como o dos faróis, o infotainment pode ser muito mais poderoso do que um simples rastreador
    E, além disso, inserir código na central ou extrair os dados já presentes nela deixa muito menos rastros do que instalar um rastreador separado
  • Se é sarcasmo, tudo bem; se não, não entendo por que um motorista de Civic não poderia ser alvo de serviços de inteligência
    O Civic é um dos carros mais comuns, então é ótimo para passar despercebido no ambiente, e pessoas “com cara de comuns”, como cientistas, engenheiros, jornalistas e advogados, podem perfeitamente dirigir um Honda Civic
    Um dispositivo de escuta escondido no carro pode ser descoberto, mas algo instalado diretamente no firmware do veículo tem chance ainda menor de ser encontrado
  • Você acha que um cientista ou engenheiro sem graça, com acesso a informações confidenciais, não vai para o trabalho em um Civic comum?

• Já ouvi gerente de produto dizer com orgulho que o firmware havia sido assinado por um serviço interno de assinatura da empresa. Isso, por si só, é bom
  Mas a pergunta que realmente estava sendo feita era se o firmware havia sido assinado por exigência interna, e não se o processo de atualização de firmware verificava a assinatura; na prática, não verificava nada

  • Já vi uma “solução” parecida. O algoritmo de assinatura estava sendo executado diretamente a partir do próprio pacote de atualização

• Era algo do tipo “senão, como você atualiza o algoritmo de assinatura”, e o pior é que em algum momento isso já tinha sido feito corretamente
  A forma de assinatura mudou quando a equipe de segurança exigiu assinaturas “seguras contra computação pós-quântica”, e nisso entrou um bug de regressão

  • Com um nome como BobbyTables2, eu teria esperado que a forma correta de verificar assinaturas PGP de e-mail viesse imediatamente à mente

• Acho que existe uma linha entre segurança e manter o aparelho útil no longo prazo. A ameaça de instalar malware de escuta no carro por meio de um ataque estilo empregada mal-intencionada parece baixa
  Mas, quando esses carros tiverem mais de 10 anos e forem parar nas mãos de pessoas dispostas a mexer neles, a capacidade de abrir o software e customizá-lo será uma grande vantagem
  Seria ótimo se surgisse uma comunidade criando modificações úteis e prolongando a vida útil do equipamento. Parece muito melhor do que o usuário final arrancar a unidade principal original e colocar uma unidade estilo “tablet Android” do Aliexpress, provavelmente com segurança e qualidade de engenharia piores do que as do dispositivo da Honda

• Isso também pode ser um bom sinal de que eles nem sequer pensaram em bloquear o sistema contra o proprietário

  • Não é bom permitir acesso root a qualquer pessoa que entre no carro por um instante. É parecido com deixar um notebook sempre ligado no escritório com um shell aberto
    Se não iam confiar em todas as atualizações por padrão, deveriam ter fornecido um mecanismo para o verdadeiro proprietário aprovar as atualizações
  • É mais provável que isso seja resultado de incompetência do que algo amigável a hackers
    Se fosse realmente intencional, haveria algo como um bootloader desbloqueável que exigisse uma chave especial, ou um interruptor de difícil acesso

• Talvez tenha sido ruim transformar o carro em um grande computador sobre rodas. Mais pesquisas são necessárias

• Fico curioso sobre quão boa é a segurança do resto. A unidade principal provavelmente está conectada a um gateway CAN; talvez dê para chamá-la via telemática, ou possa existir uma nova forma de abusar do CarPlay/Android Auto para fazê-la se comunicar com a sua casa

  • Se você tem acesso físico ao carro e quer comunicação com a sua casa, eu recomendaria colocar um rastreador GPS embaixo do tapete
    Isso funciona em mais marcas do que um método que só serve para uma geração do Honda Civic, e provavelmente também é mais rápido de instalar

• Vejo cada vez mais projetos reduzindo a documentação do código com a ideia de que “código bem projetado pode ser consultado com um LLM”, e focando mais em documentação de procedimentos funcionais de execução
  Em qualquer momento, a chance de toda a documentação de um projeto estar realmente alinhada e atualizada com o código é muito baixa
  Em geral, concordo com essa direção, mas a premissa é justamente a parte de o código estar bem projetado

  • Em vez de documentação, é melhor encarar testes unitários como documentação
    Os testes podem mostrar o uso pretendido e casos de borda interessantes, e como continuam sendo executados e passando, você também sabe que estão atualizados
    Essa é uma grande vantagem subestimada ao adicionar mais testes
    Se parece provável que um desenvolvedor vá perguntar sobre algum comportamento ou caso de borda, vale a pena ter um teste que possa demonstrar diretamente a resposta à pergunta, em vez de obrigá-lo a raciocinar tudo de novo