Pesquisa em firmware de áudio baseado em Tensilica Xtensa mostrou que mensagens IPI enviadas do espaço de usuário Android alcançam manipuladores no DSP, com risco de escalonamento local quando combinadas a bibliotecas OEM vulneráveis.
| Componente | DSP de áudio em SoCs MediaTek modernos, incluindo plataforma testada com MT6853 Dimensity 800U e firmware audio_dsp.img. |
| Vetor | Mensagens IPI enviadas a partir do espaço de usuário Android por meio do driver /dev/audio_ipi, de bibliotecas de áudio do fornecedor e de áreas DMA compartilhadas entre AP e DSP. |
| Impacto | As falhas identificadas são acessíveis a partir do Android; encadeadas com vulnerabilidades em bibliotecas de parceiros OEM, podem levar a escalonamento local de privilégio e, potencialmente, permitir escuta de conversas ou ocultação de código malicioso. |
| Prioridade | Inventariar aparelhos MediaTek afetados, acompanhar atualizações do OEM, restringir exposição de interfaces de áudio a aplicativos não confiáveis e monitorar uso anômalo de IPI, DMA e bibliotecas de áudio do fornecedor. |
| Artefatos | Caminhos e interfaces relevantes incluem /vendor/lib/hw/audio.primary.mt6853.so, AudioMessengerIPI, sendIpiMsg, /dev/audio_ipi, AUDIO_IPI_INIT_DSP, AUDIO_IPI_LOAD_SCENE, AUDIO_IPI_REG_DMA e AUDIO_IPI_SEND_DRAM. |
| Ambiente de pesquisa | A análise usou um Xiaomi Redmi Note 9 5G com chipset MT6853, MIUI Global 12[.]5[.]2[.]0 e Android 11 RP1A.200720.011. |
A investigação descreve vulnerabilidades no DSP de áudio usado em SoCs MediaTek modernos, uma superfície que fica abaixo da camada comum de aplicativos Android, mas que ainda recebe dados originados no espaço de usuário. O ponto central é a comunicação entre o processador de aplicação, onde o Android executa, e o processador de sinal digital dedicado ao áudio. Essa comunicação passa por um driver de dispositivo, por chamadas de controle específicas e por mensagens IPI encaminhadas até tarefas internas do firmware de áudio. Como essas mensagens podem ser influenciadas pelo lado Android, os manipuladores do DSP se tornam uma fronteira de validação crítica.
O risco não é descrito como exploração remota pela rede. A condição técnica apresentada é local: um aplicativo Android, especialmente quando combinado com falhas em bibliotecas de parceiros OEM, poderia alcançar caminhos que terminam no DSP. O encadeamento citado pode resultar em escalonamento local de privilégio. Em um cenário de exploração bem-sucedida das falhas do DSP, o impacto potencial inclui acesso indevido ao fluxo de áudio de conversas do usuário e ocultação de código malicioso em uma camada menos visível para ferramentas tradicionais de segurança do sistema operacional.
A superfície é relevante porque a MediaTek é apresentada como fornecedora ampla de SoCs para smartphones e dispositivos IoT, com presença em aparelhos de marcas como Xiaomi, Oppo, Realme e Vivo. A pesquisa também destaca que os SoCs recentes, incluindo a série Dimensity, incorporam uma unidade de processamento de IA e um DSP de áudio para melhorar desempenho multimídia e reduzir carga da CPU. Ambos usam arquitetura Tensilica Xtensa customizada, o que dificulta engenharia reversa e reduz a visibilidade de análises convencionais baseadas apenas em componentes Android conhecidos.
O fluxo começa no Android, no processador de aplicação, que precisa enviar solicitações ao processador de áudio. No aparelho analisado, o caminho passa por um conjunto limitado de drivers relacionados a mídia, até chegar ao driver /dev/audio_ipi. A biblioteca de áudio do fornecedor /vendor/lib/hw/audio.primary.mt6853.so exporta o singleton AudioMessengerIPI, que contém o método sendIpiMsg usado para enviar mensagens de interrupção interprocessador ao DSP de áudio. A pesquisa tratou esse caminho como mecanismo de exploração e também como guia para entender o contrato entre espaço de usuário, núcleo Android e firmware do DSP.
Antes de enviar mensagens, o firmware do DSP precisa ser inicializado com AUDIO_IPI_INIT_DSP. Depois disso, cenas de tarefa são carregadas com AUDIO_IPI_LOAD_SCENE. Cada cena representa uma área funcional no DSP, como processamento associado a chamada telefônica, aprimoramento de fala, tarefas comuns de áudio, controle, descarregamento de processamento e componentes auxiliares. A mensagem inclui campos como identificador de cena, identificador de mensagem e parâmetros de dados. Esse desenho cria um roteamento interno: o lado Android seleciona o destino lógico, e o dispatcher no firmware entrega a requisição ao manipulador correspondente.
A transferência de dados também pode usar memória compartilhada. O controle AUDIO_IPI_REG_DMA solicita ao driver a alocação de regiões DMA dedicadas, uma para tráfego do processador de aplicação para a cena do DSP e outra para o caminho inverso. O contexto informa que o lado Android controla tamanhos como a2d_size e d2a_size, e que offsets dessas regiões aparecem em logs do núcleo. A persistência do endereço físico calculado para a região compartilhada no dispositivo de teste é um detalhe importante para defesa e análise forense, pois mostra que o fluxo não é apenas uma chamada abstrata de API, mas uma troca de dados com endereçamento previsível dentro daquela configuração.
O driver /dev/audio_ipi não conversa diretamente com o DSP de áudio. Ele encaminha a mensagem para o System Control Processor por meio de uma fila SCP, e o firmware do DSP registra um dispatcher para receber mensagens de áudio vindas desse intermediário. No lado do firmware, o sistema operacional do DSP é uma adaptação do FreeRTOS, com lógica de áudio e mensageria implementada pela MediaTek. Tarefas de áudio são criadas na inicialização, associadas a identificadores de cena e representadas por objetos que contêm ponteiros para funções recv_message. Essas funções são o ponto onde dados vindos do Android começam a ser interpretados no ambiente do DSP.
A engenharia reversa exigiu lidar com firmware em formato próprio. A imagem audio_dsp.img aparece tanto em pacote de atualização de fábrica quanto em partição dedicada de dispositivo com acesso root. Ela contém partições como cert1, cert2, hifi3_a_dram, hifi3_a_iram e hifi3_a_sram. As duas primeiras são certificados em DER usados para verificar integridade das partições hifi3. As demais carregam memória dinâmica, código e dados do firmware. A arquitetura Xtensa com opcodes customizados dificulta desmontagem direta, mas mensagens de log no firmware incluem nomes de funções, o que ajudou a localizar rotinas relevantes de recepção e processamento.
A superfície afetada fica na interseção entre Android, bibliotecas de áudio de fornecedor, driver de IPI, SCP e firmware do DSP. Não se trata apenas de uma biblioteca de usuário nem apenas de uma rotina embarcada isolada: a cadeia atravessa várias camadas de privilégio e confiança. O lado Android consegue formar mensagens, selecionar cenas e fornecer parâmetros ou payloads para manipuladores no DSP. Esse modelo é comum em arquiteturas heterogêneas, mas a pesquisa mostra que ele exige validação consistente tanto no driver quanto nas tarefas de firmware que consomem as mensagens.
O dispositivo usado como base foi um Xiaomi Redmi Note 9 5G com MT6853 Dimensity 800U, MIUI Global 12[.]5[.]2[.]0 e Android 11. O contexto também afirma que SoCs MediaTek estão presentes em uma parcela ampla de smartphones e IoT, inclusive em aparelhos de várias marcas. Isso não significa que todo modelo esteja automaticamente explorável na mesma forma, porque a cadeia pode depender de bibliotecas OEM, versão de firmware, configuração do driver e exposição das interfaces. Para defesa, a conclusão prática é tratar dispositivos com DSP de áudio MediaTek e pilhas OEM derivadas como candidatos a revisão, não presumir equivalência entre todos os modelos.
A pesquisa aponta que as falhas descobertas são acessíveis a partir do espaço de usuário Android e que o impacto aumenta quando há encadeamento com vulnerabilidades em bibliotecas de parceiros OEM. Essa condição é importante: a superfície direta observada permite alcançar o DSP, mas o escalonamento local citado depende da composição com outros problemas na pilha do fabricante do aparelho. Em ambientes corporativos com frota móvel, o risco deve ser avaliado por modelo, versão de firmware, política de instalação de aplicativos e capacidade de aplicar atualizações do OEM.
- Driver
/dev/audio_ipicomo interface de envio de mensagens IPI relacionadas ao áudio. - Biblioteca
/vendor/lib/hw/audio.primary.mt6853.socomo componente de fornecedor que expõeAudioMessengerIPIesendIpiMsg. - Firmware
audio_dsp.imgcom partiçõeshifi3_a_dram,hifi3_a_iramehifi3_a_sramexecutando lógica de áudio sobre FreeRTOS adaptado. - Cenas de tarefa do DSP com funções
recv_messageque interpretam mensagens vindas do Android.
A detecção deve partir da premissa de que a exploração é local e passa por interfaces de dispositivo, bibliotecas de fornecedor e tráfego interno entre processadores. Em endpoints Android gerenciados, sinais úteis incluem acesso incomum ao driver /dev/audio_ipi, carregamento inesperado da biblioteca de áudio do fornecedor por processos que não fazem parte do fluxo normal de mídia, chamadas repetidas a controles de inicialização, carregamento de cena ou registro de DMA, e padrões de mensagens IPI fora do comportamento típico do aparelho. A ausência de telemetria profunda em dispositivos móveis pode limitar a visibilidade, então inventário e integridade de firmware ganham peso.
Logs do núcleo podem registrar informações sobre regiões DMA reservadas e offsets associados a cenas do DSP. Esse dado é sensível para análise porque mostra quando uma área compartilhada entre AP e DSP foi alocada e usada. Em um cenário defensivo, correlação temporal entre execução de aplicativo suspeito, mensagens de áudio, alocações DMA e alterações de comportamento no subsistema de mídia pode indicar abuso. A análise deve evitar depender de um único evento, já que áudio legítimo também usa essas rotas; o diferencial tende a estar em processo chamador, frequência, parâmetros, contexto de uso e associação com aplicativos recém-instalados ou não confiáveis.
Para engenharia e resposta a incidentes, a imagem audio_dsp.img e suas partições são artefatos relevantes. Mudanças não explicadas em partições do firmware, divergência entre versões esperadas para o modelo e o pacote de atualização oficial, ou presença de componentes de fornecedor fora do conjunto de fábrica devem ser tratadas como sinais de investigação. O contexto não apresenta indicadores de compromisso de rede, domínio, hash ou família de malware, portanto a caça não deve ser construída em IoCs externos inventados. O foco defensivo é comportamento local, integridade de firmware, uso de interfaces e cadeia de bibliotecas OEM.
- Acesso ao nó
/dev/audio_ipipor processos sem relação clara com áudio, telefonia ou serviços de mídia do sistema. - Uso incomum de controles como
AUDIO_IPI_INIT_DSP,AUDIO_IPI_LOAD_SCENE,AUDIO_IPI_REG_DMAe envio de mensagens com payload por DMA. - Alocações DMA para cenas de áudio registradas em logs do núcleo fora de sessões legítimas de mídia ou chamada.
- Carregamento de
/vendor/lib/hw/audio.primary.mt6853.sopor contexto de aplicativo suspeito ou recém-instalado. - Divergência entre a imagem
audio_dsp.imgpresente no dispositivo e a versão esperada para o firmware do OEM.
A resposta deve começar pelo inventário de aparelhos que usam SoCs MediaTek com DSP de áudio e pela correlação com versões de firmware fornecidas pelo OEM. Como o encadeamento citado envolve bibliotecas de parceiros, a atualização não deve ser vista apenas como correção de um componente MediaTek isolado; ela precisa abranger imagem de sistema, bibliotecas em /vendor, driver de áudio e firmware do DSP. Em frotas gerenciadas, dispositivos que não recebem mais atualizações do fabricante devem ser tratados com prioridade maior, principalmente quando executam aplicativos de origem pouco controlada ou perfis de trabalho com dados sensíveis.
No lado preventivo, a medida mais objetiva é reduzir a capacidade de aplicativos não confiáveis alcançarem caminhos de fornecedor sensíveis. Isso inclui política rígida de instalação, bloqueio de sideload quando aplicável, revisão de permissões, separação entre perfil pessoal e corporativo, e monitoramento de aplicativos que interagem de forma anômala com áudio e telefonia. Essas ações não substituem correção de firmware, mas diminuem a probabilidade de um aplicativo local ser usado como primeiro estágio para acionar a cadeia descrita.
Para fabricantes e equipes que mantêm imagens Android, a validação precisa cobrir o contrato completo de mensagens entre espaço de usuário, driver, SCP e DSP. Campos de tamanho, identificadores de cena, identificadores de mensagem, parâmetros e payloads transferidos por DMA devem ser tratados como entrada não confiável. Manipuladores recv_message no firmware precisam verificar limites, estados de inicialização, cena carregada, tamanho real do buffer e formato esperado antes de consumir dados. A presença de opcodes customizados e firmware menos observável torna essa validação ainda mais importante, porque falhas nessa camada são mais difíceis de auditar depois da distribuição.
Na resposta a suspeita de abuso, a contenção deve priorizar remoção do aplicativo suspeito, coleta de logs disponíveis, verificação de integridade de firmware e restauração para imagem oficial quando houver indício de alteração persistente. Como o impacto potencial inclui escuta de conversas e ocultação de código, investigações devem considerar eventos de áudio, permissões concedidas, instalações recentes e alterações no subsistema de mídia. Não há no contexto IoCs de infraestrutura externa, então a erradicação deve se apoiar em evidência local e em atualização do sistema, não em bloqueios de rede genéricos.
- Aplicar atualizações do fabricante que cubram bibliotecas de fornecedor, driver de áudio e firmware do DSP.
- Inventariar modelos MediaTek na frota e priorizar aparelhos sem atualização de segurança disponível.
- Restringir instalação de aplicativos fora de canais confiáveis e revisar permissões relacionadas a áudio e telefonia.
- Monitorar acesso a
/dev/audio_ipi, alocações DMA e carregamento anômalo da biblioteca de áudio do fornecedor. - Validar no desenvolvimento OEM todos os campos de mensagens IPI e payloads DMA antes de entregá-los a manipuladores do DSP.
0 Comentários