O firmware de banda base 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 da
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 bandas base
da geração Helio, confirmada por pesquisas independentes publicadas sobre banda base nesta família de SoCs.

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, nenhuma aplicação
de unidade de proteção de memória entre tarefas e nenhum mecanismo de guarda 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 compilação analisada)

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

### 2.4 Abordagem de análise

Três frentes 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` da NCC Group.

**Validação dinâmica.** O Unicorn Engine (emulação MIPS32) foi usado para executar rotinas
específicas do firmware de forma isolada em duas fases. A Fase 1 tentou provar a cópia sem
verificação de limites de `si_count` para o 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 objeto 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 no 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 NB-IoT e à entrega de bloco de transporte.

---

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

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

NB-IoT (Internet das Coisas de Banda Estreita) é o 3GPP Release 13, projetado para conectar
dispositivos IoT com recursos limitados usando o espectro LTE licenciado existente. É implementado em uma
ampla gama de SoCs celulares modernos, incluindo aqueles em smartphones de consumo.

Enquanto no estado 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 SIB1-NB via NPDSCH (agendamento de 2560 ms)
4. Usar as informações de agendamento em 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 fraudulento 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 debug do CATI foi descomprimida e analisada com `mtk_dbg_extract.py symbols` e, em seguida, importada no Ghidra via `ImportSymbolsScript.py`. O resultado foram nomes completos de funções internas em toda a pilha do modem — camada ERRC, gerenciamento de canal 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 símbolos de debug incorporados da MediaTek extraídos da imagem do firmware.

---

## 5. Vulnerabilidade

### 5.1 O loop vulnerável

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

A partir da descompilação do Ghidra do binário de firmware real:```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 (byte `sb` writes) começa em `new_sp+0x78` e precisaria da 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 restrição em três camadas

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

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

### 5.7 Causa raiz

Um invariante violado:

> O número de entradas de agendamento 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 compilação 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 um limite IPC para a tarefa L1, para o contexto do canal BSS, e para um loop de escrita na pilha — sem qualquer camada a restringir.

---

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

### 6.1 A confusão de dois caminhos

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

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

O Caminho B confirmou o formato da mensagem — o byte `+0x99` é a contagem SI consumida por `el1_ch_nbcch_start`. Como sua contagem está sempre codificada como 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 escreva no offset `+0x99` produziu ruído: T1 (`sb` direto, ~100 ocorrências), T2 (base dividida, 5 ocorrências), T3 (offset computado, 0), T4 (sobreposição `sh`/`sw`, ~465). As funções de gerenciamento de canal ERRC estavam ausentes da lista de referências cruzadas `msg_send6` porque 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 na operação normal de fábrica, razão pela qual foram utilizadas emulação híbrida e análise estática em vez de reprodução direta em hardware.

**Comprovado estaticamente.** O binário do 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 em bytes reais de 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 nativamente 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 ativos 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 em BSS e não atinge o mesmo caminho de despacho, razão pela qual a Fase 2 foi executada nativamente sem exigir a mesma estrutura. O efeito colateral da Fase 1 — um byte de `IPC_msg[+0x99]` escrito em `ch_ctx[+0x40A]` — foi modelado diretamente e rotulado como `[PHASE1-MODEL]`.

**Não reivindicado.** Uma reprodução completa de hardware ponta a ponta over-the-air.

### 7.1 Anti-adulteração

O harness impôs uma regra: nenhum hook podia escrever o marcador de prova no slot do endereço de retorno salvo. Cada escrita de 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 ZMQ delivery

Para confirmar que a carga de teste sobrevive à codificação PHY NB-IoT e à entrega de blocos de transporte, foi utilizado o srsRAN 4G com um loopback ZMQ (sem emissão RF). A carga 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 de ida e volta do pycrate confirmando o campo de contagem no byte 14.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]` vive na BSS e retém o valor do atacante até que o modem reinicie ou uma configuração de canal subsequente o substitua.

### 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 uma única linha 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 descrita aqui corresponde à CVE-2024-20154 conforme publicada pela MediaTek em 6 de janeiro de 2025. Base de confirmação:

- Família de firmware afetada (LR12A) corresponde ao boletim da MediaTek.
- Classe de vulnerabilidade — estouro de pilha, falta de verificação de limites, RCE a partir de estação base falsa, sem interação do usuário — corresponde à descrição da CVE e ao registro NVD.
- O firmware corrigido remove exatamente as estruturas de código identificadas como vulneráveis.
- ID do patch MOLY00720348 confirmado pelo boletim da MediaTek e pelo Android Security Bulletin (A-376809176).
- Análise assistida por IA combinou independentemente o padrão reconstruído com a 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 binário de firmware. Nenhum byte de payload malformado. Nenhum procedimento passo a passo para desencadear a vulnerabilidade contra um dispositivo real. As informações necessárias para reproduzir um ataque funcional — construção completa de payload para o decodificador de modem específico, scaffolding de objeto heap 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 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 pré-associação — transmitir uma transmissão malformada afetaria qualquer dispositivo dentro do 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 disponíveis da Samsung. Nenhuma documentação proprietária foi utilizada. Definições internas de estruturas da MediaTek e formatos de mensagens IPC são descritas apenas na medida necessária para explicar a falha de segurança de memória. Elas não são publicadas como especificações.

---