O firmware do baseband não é código Android. É um sistema embarcado separado no subsistema de rádio do SoC, com sua própria CPU, seu próprio RTOS e seu próprio espaço de memória, fora do sandbox de processos do Android.

### 2.2 Arquitetura do modem

A análise do binário extraído mostra que o processador do modem executa MIPS32 com instruções comprimidas MIPS16e2 em modo little-endian. MIPS16e2 é uma extensão de codificação de 16 bits para redução de tamanho de código embarcado — consistente com a abordagem da MediaTek para basebands da geração Helio, confirmada por pesquisa independente publicada sobre basebands desta família de SoC.

O sistema operacional é o Nucleus RTOS, fornecendo escalonamento de tarefas, filas de mensagens IPC e um alocador de memória baseado em pool. Não há separação de privilégios kernel/usuário, nem aplicação de unidade de proteção de memória entre tarefas, nem mecanismo de proteção de pilha por hardware.

Todos os endereços neste post são endereços virtuais, conforme carregados no Ghidra na base `0x90000000`.

### 2.3 Mitigações (observadas na build analisada)

| Mitigação | Status | Efeito |
|---|---|---|
| ASLR | Ausente | Os endereços do firmware são estáticos e previsíveis a partir da imagem |
| Stack canary | Ausente | `SAVE`/`RESTORE` armazena registradores salvos pelo chamador sem valor de guarda |
| NX / W^X | Ausente | A memória da pilha é executável |
| CFI | Ausente | Os endereços de retorno não são validados contra nenhuma política |

### 2.4 Abordagem de análise

Três trilhas paralelas:

**Análise estática.** Pacote de firmware Samsung → extração da partição CP → `md1img.img` → Ghidra (MIPS LE 32-bit, base `0x90000000`) com símbolos de engenharia da MediaTek recuperados da seção de debug do firmware usando o conjunto de ferramentas `mtk_bp` do NCC Group.

**Validação dinâmica.** O Unicorn Engine (emulação MIPS32) foi usado para executar rotinas específicas do firmware isoladamente em duas fases. A Fase 1 tentou provar a cópia não limitada de `si_count` no contexto do canal através do par de instruções nativo. A Fase 2 executou o loop vulnerável em bytes reais do firmware e confirmou que as próprias instruções do firmware corrompem o endereço de retorno salvo. Onde a Fase 1 não pôde ser executada totalmente de forma nativa — porque o ambiente de objetos de serviço do RTOS exigido pelo caminho de despacho CPHY não foi reconstruído — o efeito colateral foi modelado diretamente e rotulado como tal em toda a saída.

**Validação pelo lado do rádio.** srsRAN 4G com um loopback ZMQ — apenas software, sem emissão de RF — confirmou que o payload de teste sobrevive à codificação PHY do NB-IoT e à entrega do bloco de transporte.

---

## 3. Superfície de Ataque: NB-IoT e SIB1-NB

### 3.1 Superfície de ataque pré-associação

NB-IoT (Narrowband Internet of Things) é o 3GPP Release 13, projetado para conectar dispositivos IoT restritos usando espectro LTE licenciado existente. É implementado em uma ampla variedade de SoCs celulares modernos, incluindo os presentes em smartphones de consumo.

Enquanto em RRC_IDLE, antes que qualquer conexão RRC seja estabelecida, um dispositivo procurando serviço irá:

1. Sincronizar com os sinais de temporização da célula (NPSS/NSSS)
2. Decodificar o Master Information Block via NPBCH (janela de transmissão de 640 ms)
3. Decodificar o SIB1-NB do NPDSCH (agendamento de 2560 ms)
4. Usar as informações de agendamento no SIB1-NB para localizar blocos de informações de sistema adicionais

No passo 3, o modem processa uma mensagem de uma entidade que não autenticou, antes de qualquer conexão ou interação do usuário. Um transmissor malicioso que satisfaça as condições normais de seleção de célula será processado.```
+------------------+                   +---------------------+
|  Rogue Base Stn  |                   |  Target UE (Modem)  |
+--------+---------+                   +----------+----------+
         |                                        |
         |   NPSS/NSSS sync                      |
         |--------------------------------------->|
         |   MIB-NB (640 ms cycle)                |
         |--------------------------------------->|
         |   SIB1-NB (malformed, si_count > 8)    |
         |--------------------------------------->|   ← vulnerability triggered
         |   [no RRC connection established]      |

A seção de depuração CATI foi descomprimida e analisada com `mtk_dbg_extract.py symbols`, depois
importada para o Ghidra via `ImportSymbolsScript.py`. O resultado foram nomes de funções internas
completos em toda a pilha do modem — camada ERRC, gerenciamento de canais L1, subsistema IPC e a
cadeia de manipuladores NB-IoT BCCH — permitindo a reconstrução da cadeia guiada por semântica.

Todos os nomes de funções neste post vêm dos próprios símbolos de depuração incorporados da MediaTek extraídos
da imagem de firmware.

---

## 5. Vulnerabilidade

### 5.1 O loop vulnerável

`el1_ch_nbcch_resume_req` (`0x90213940`) trata o evento de retomada do canal de broadcast NB-IoT.
Seu prólogo de função MIPS16e2:```asm
90213940:  save  0xE8, ra, s0-s1

Do decompilado do Ghidra do binário real do firmware:```c
for (uVar6 = 0; uVar6 < (byte)param_2[0x40a]; uVar6 = uVar6 + 1) {
    si_type_arr[uVar6]  = /* SI type byte */;          // 1 byte/iter, base new_sp+0x78
    si_sched_arr[uVar6] = /* SI schedule halfword */;  // 2 bytes/iter, base new_sp+0x98
}

Stream B (gravações de byte `sb`) começa em `new_sp+0x78` e exigiria a iteração 108 para alcançar
o slot RA:```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 O construtor ERRC — Camada A

O buffer CPHY_CFG_REQ é construído na camada ERRC a partir do SIB1-NB decodificado. A função
`errc_chm_l1_set_bcch_si_reception` escreve `IPC_msg[+0x99]`:```c
// errc_chm_l1_set_bcch_si_reception — Layer A
// Loop bound: decoded schedulingInfoList entry count from SIB1-NB

while (bVar3 < *(byte *)(param_3 + 0x44) && (param_2 != 0)) {
    bVar3++;
    if (uVar2 != param_2) {
        *param_5 = *param_5 + 1;   // CPHY_CFG_REQ[+0x99]++ — no upper bound check
    }
}

### 5.6 Ausência de clamping em três camadas

| Camada | Função | Endereço | Clamp presente? |
|---|---|---|---|
| A — construtor ERRC | `errc_chm_l1_set_bcch_si_reception` | intervalo ERRC | **Nenhum** |
| B — cópia L1 | `el1_ch_nbcch_start` | `0x90213444` | **Nenhum** |
| C — loop L1 | `el1_ch_nbcch_resume_req` | `0x90213940` | **Nenhum** |

Qualquer verificação única em qualquer uma das camadas teria quebrado a cadeia.

### 5.7 Causa raiz

Uma invariante violada:

> O número de entradas de agendamento de SI nunca deve exceder a capacidade do array de destino.

O 3GPP fornece o limite de protocolo pretendido (8 entradas). O firmware precisava impor o
limite de segurança de memória em cada camada onde a contagem se torna um índice ou limite
de loop. Na build vulnerável, a contagem viajou do campo de broadcast SIB1-NB através do
decodificador ERRC, para a mensagem CPHY_CFG_REQ, através de uma fronteira IPC para a
tarefa L1, para o BSS de contexto de canal, e para um loop de escrita na stack — sem que
nenhuma camada a limitasse.

---

## 6. A Cadeia de Chamadas — Como Foi Encontrada

### 6.1 A confusão dos dois caminhos

Dois caminhos estruturalmente semelhantes mas distintos podem entregar um buffer de
configuração de 0x760 bytes a `el1_ch_nbcch_main`:

| Caminho | Origem | Valor de `[+0x99]` | Relevância |
|---|---|---|---|
| Caminho A (ERRC → L1 IPC) | ERRC constrói CPHY_CFG_REQ a partir do SIB1-NB decodificado | `schedulingInfoList.count` do OTA | **O caminho vulnerável** |
| Caminho B (L1 interno) | `el1_ch_scs_ind_send` constrói corpo IPC interno | `1` hardcoded | Não vulnerável |

O Caminho B confirmou o formato da mensagem — o byte `+0x99` é a contagem de SI consumida
por `el1_ch_nbcch_start`. Como a sua contagem é sempre hardcoded para 1, não pode
transbordar. O caminho influenciado externamente é o Caminho A.

### 6.2 A busca pelo escritor

A busca por padrões no firmware por qualquer instrução que escrevesse no offset `+0x99`
produziu ruído: T1 (`sb` direto, ~100 resultados), T2 (base dividida, 5 resultados), T3
(offset computado, 0), T4 (`sh`/`sw` sobrepostos, ~465). As funções de gestão de canal ERRC
estavam ausentes da lista de referências cruzadas de `msg_send6` porque o ERRC usa
`errc_com_send_msg`. Uma sonda de emulação confirmou que a escrita era do lado ERRC:
executar o harness Unicorn a partir do dispatcher L1 e observar escritas no offset `+0x99`
do buffer não capturou nada do lado L1.```
[RUN] dispatcher=0x90214418  watching IPC_msg+0x99

NO writes to IPC_msg+0x99 caught from dispatcher.
Write happened before el1_ch_nbcch_main — confirmed ERRC-side.

---

## 7. Validação

Este modelo específico SM-A145R não parece exercitar
o caminho de código NB-IoT vulnerável em operação normal de construção de navios, razão pela qual
emulação híbrida e análise estática foram usadas em vez de reprodução direta em hardware.

**Provado estaticamente.** O binário de firmware contém o par de instruções vulnerável. A cadeia
de chamadas é reconstruída a partir de símbolos, referências cruzadas e corpos de funções descompilados.

**Executado nativamente em emulação.** O loop dentro de `el1_ch_nbcch_resume_req` foi executado sobre bytes
reais do firmware MediaTek no Unicorn Engine (MIPS32). A própria instrução `sh` do firmware em
`0x90213B02` escreveu no slot do endereço de retorno salvo. A instrução `RESTORE` carregou o
valor corrompido em `$ra`, e `jrc ra` transferiu o controle.

**Modelado explicitamente.** A cópia `lbu`/`sb` em `el1_ch_nbcch_start` não pôde ser executada totalmente
de forma nativa porque o caminho de despacho da tabela de callbacks do RTOS dentro de `el1_ch_nbcch_cphy_cfg_req_
process` esperava objetos de heap Nucleus vivos que o emulador plano não fornecia. O manipulador
de retomada (`el1_ch_nbcch_resume_req`) na Fase 2 lê apenas do contexto de canal residente na BSS
e não atinge esse mesmo caminho de despacho, razão pela qual a Fase 2 foi executada nativamente sem
exigir a mesma estrutura de suporte. O efeito colateral da Fase 1 — um byte de `IPC_msg[+0x99]`
escrito em `ch_ctx[+0x40A]` — foi modelado diretamente e rotulado `[PHASE1-MODEL]`.

**Não alegado.** Uma reprodução completa de hardware ponta a ponta via rádio.

### 7.1 Anti-adulteração

O harness impôs uma regra: nenhum hook tinha permissão para escrever o marcador de prova no slot
do endereço de retorno salvo. Toda escrita em memória não pertencente ao firmware foi rastreada.```
[PROOF-W] saved_RA write: pc=0x90213b02  addr=new_sp+0xE4  value=0xbeef
[PROOF-W] saved_RA write: pc=0x90213b02  addr=new_sp+0xE6  value=0xdead
[ANTI-TAMPER] no hook wrote RA=0xDEADBEEF — firmware only
anti_tamper_fail = False

### 7.3 Entrega ZMQ

Para confirmar que o payload de teste sobrevive à codificação PHY do NB-IoT e à entrega do bloco de transporte, foi utilizado o srsRAN 4G com um loopback ZMQ (sem emissão RF). O payload era um vetor deliberadamente não conforme — a restrição ASN.1 SIZE em `schedulingInfoList` foi relaxada para permitir 40 entradas, com a decodificação round-trip do pycrate confirmando o campo de contagem no byte 14.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` reside no BSS e retém o valor do atacante até que o modem seja reiniciado ou uma
configuração de canal subsequente o sobrescreva.

### 8.2 Stack frame```
old_sp  (= new_sp + 0xE8)
new_sp + 0xE4   saved ra
new_sp + 0xE0   saved s1
new_sp + 0xDC   saved s0
new_sp + 0x98   si_sched_arr  [34 halfwords = 68 bytes]
new_sp + 0x78   si_type_arr   [32 bytes]

Uma verificação de limites de linha única apareceria como algumas instruções adicionadas dentro de uma função existente no mesmo endereço. O que o binário corrigido mostra é uma revisão arquitetural: o caminho de agendamento NBCCH foi redesenhado para que o padrão `si_count`-como-limite-de-loop não exista mais em nenhum lugar do caminho.

### 10.4 Atribuição de CVE

A vulnerabilidade aqui descrita corresponde à CVE-2024-20154, conforme publicada pela MediaTek em 6 de janeiro de 2025. Base da confirmação:

- A família de firmware afetada (LR12A) corresponde ao boletim da MediaTek.
- A classe da vulnerabilidade — estouro de pilha, verificação de limites ausente, RCE a partir de estação base maliciosa, sem interação do usuário — corresponde à descrição da CVE e ao registro do NVD.
- O firmware corrigido remove exatamente as estruturas de código identificadas como vulneráveis.
- ID do patch MOLY00720348 confirmado a partir do boletim da MediaTek e do Android Security Bulletin (A-376809176).
- A análise assistida por IA correspondeu independentemente o padrão reconstruído à CVE-2024-20154 antes da confirmação manual.

---

## 11. Ética e Divulgação Responsável

### 11.1 O que este post não contém

Nenhum exploit armado. Nenhum conteúdo de binário de firmware. Nenhum byte de payload malformado. Nenhum procedimento passo a passo para acionar a vulnerabilidade contra um dispositivo ativo. As informações necessárias para reproduzir um ataque funcional — construção completa de payload para o decodificador de modem específico, estruturação de objetos de heap do RTOS para emulação completa da Fase 1, configuração de rádio over-the-air — estão deliberadamente ausentes.

### 11.2 Por que loopback ZMQ e emulação são a abordagem ética

Loopback ZMQ significa que nenhum sinal foi jamais transmitido pelo ar. Nenhum dispositivo real foi alvo. Nenhuma rede de operadora foi envolvida. A prova é executada inteiramente em um ambiente de software contido, em hardware de propriedade do analista. Esta é a abordagem correta para validar uma vulnerabilidade de rádio de pré-associação — transmitir um broadcast malformado afetaria qualquer dispositivo ao alcance.

A emulação Unicorn demonstra que o comportamento vulnerável está no próprio binário do firmware, de forma reproduzível, independentemente de qualquer estado específico do dispositivo ou ambiente de rádio. Esta é uma afirmação tecnicamente mais forte do que uma única falha de hardware, e evita implantar qualquer coisa pelo ar.

### 11.3 Propriedade intelectual da MediaTek

Toda a análise foi realizada em firmware obtido legitimamente de um dispositivo de consumo e dos pacotes de firmware publicamente divulgados pela Samsung. Nenhuma documentação proprietária foi utilizada. Definições internas de structs da MediaTek e formatos de mensagens IPC são descritos apenas na medida necessária para explicar a falha de segurança de memória. Eles não são publicados como especificações.

---