The baseband firmware is not Android code. It is a separate embedded system on the radio
subsystem of the SoC with its own CPU, its own RTOS, and its own memory space, outside the
Android process sandbox.

베이스밴드 펌웨어는 Android 코드가 아닙니다. 이는 SoC의 무선(radio) 하위 시스템에 있는 별도의 임베디드 시스템으로, 자체 CPU, 자체 RTOS, 자체 메모리 공간을 가지며 Android 프로세스 샌드박스 밖에 있습니다.

### 2.2 Modem architecture

### 2.2 모뎀 아키텍처

Analysis of the extracted binary shows the modem processor runs MIPS32 with MIPS16e2
compressed instructions in little-endian mode. MIPS16e2 is a 16-bit encoding extension for
embedded code-size reduction — consistent with MediaTek's approach for Helio-generation
basebands, confirmed by independent published baseband research on this SoC family.

추출된 바이너리 분석 결과, 모뎀 프로세서는 little-endian 모드에서 MIPS16e2 압축 명령어가 포함된 MIPS32를 실행합니다. MIPS16e2는 임베디드 코드 크기 축소를 위한 16비트 인코딩 확장으로, Helio 세대 베이스밴드에 대한 MediaTek의 방식과 일치하며, 이 SoC 제품군에 대한 독립적으로 발표된 베이스밴드 연구로 확인되었습니다.

The operating system is Nucleus RTOS, providing task scheduling, IPC message queues, and a
pool-based memory allocator. There is no kernel/user privilege separation, no memory
protection unit enforcement between tasks, and no hardware stack-guard mechanism.

운영체제는 Nucleus RTOS로, 태스크 스케줄링, IPC 메시지 큐, 풀 기반 메모리 할당자를 제공합니다. 커널/사용자 권한 분리, 태스크 간 메모리 보호 유닛(MPU) 적용, 하드웨어 스택 가드 메커니즘은 없습니다.

All addresses in this post are virtual addresses, as loaded in Ghidra at base `0x90000000`.

이 글의 모든 주소는 Ghidra에서 베이스 `0x90000000`로 로드된 가상 주소입니다.

### 2.3 Mitigations (observed in analyzed build)

### 2.3 완화 조치 (분석된 빌드에서 관찰됨)

| Mitigation | Status | Effect |
|---|---|---|
| ASLR | Absent | Firmware addresses are static and predictable from the image |
| Stack canary | Absent | `SAVE`/`RESTORE` stores callee-saved registers with no guard value |
| NX / W^X | Absent | Stack memory is executable |
| CFI | Absent | Return addresses are not validated against any policy |

| 완화 조치 | 상태 | 효과 |
|---|---|---|
| ASLR | 부재 | 펌웨어 주소는 이미지로부터 정적이고 예측 가능함 |
| Stack canary | 부재 | `SAVE`/`RESTORE`는 가드 값 없이 호출자 저장 레지스터를 저장함 |
| NX / W^X | 부재 | 스택 메모리는 실행 가능함 |
| CFI | 부재 | 반환 주소는 어떤 정책으로도 검증되지 않음 |

### 2.4 Analysis approach

### 2.4 분석 접근법

Three parallel tracks:

세 개의 병렬 트랙:

**Static analysis.** Samsung firmware package → CP partition extraction → `md1img.img` →
Ghidra (MIPS LE 32-bit, base `0x90000000`) with MediaTek engineering symbols recovered from
the firmware debug section using the NCC Group `mtk_bp` toolset.

**정적 분석.** Samsung 펌웨어 패키지 → CP 파티션 추출 → `md1img.img` → Ghidra (MIPS LE 32-bit, base `0x90000000`) 및 NCC Group `mtk_bp` 도구 모음을 사용해 펌웨어 디버그 섹션에서 복구한 MediaTek 엔지니어링 심볼.

**Dynamic validation.** Unicorn Engine (MIPS32 emulation) was used to execute specific
firmware routines in isolation across two phases. Phase 1 attempted to prove the unclamped
copy of `si_count` into channel context through the native instruction pair. Phase 2 executed
the vulnerable loop on real firmware bytes and confirmed that the firmware's own instructions
corrupt the saved return address. Where Phase 1 could not run fully natively — because the
RTOS service-object environment required by the CPHY dispatch path was not reconstructed —
the side effect was modeled directly and labeled as such in all output.

**동적 검증.** Unicorn Engine(MIPS32 에뮬레이션)을 사용하여 두 단계에 걸쳐 특정 펌웨어 루틴을 격리된 상태로 실행했습니다. 1단계에서는 네이티브 명령어 쌍을 통해 `si_count`를 채널 컨텍스트로 복사할 때 클램프(clamp) 없이 복사하는 동작을 증명하려 했습니다. 2단계에서는 실제 펌웨어 바이트로 취약한 루프를 실행하여 펌웨어 자체의 명령어가 저장된 반환 주소를 손상시킨다는 것을 확인했습니다. 1단계가 완전히 네이티브로 실행되지 못한 경우(CPHY 디스패치 경로에 필요한 RTOS 서비스 객체 환경이 재구성되지 않았기 때문에) 부수 효과를 직접 모델링했고, 모든 출력에 그렇게 표시했습니다.

**Radio-side validation.** srsRAN 4G with a ZMQ loopback — software-only, no RF emission —
confirmed that the test payload survives NB-IoT PHY encoding and transport-block delivery.

**무선 측 검증.** ZMQ 루프백을 사용하는 srsRAN 4G — 소프트웨어 전용, RF 방사 없음 — 를 통해 테스트 페이로드가 NB-IoT PHY 인코딩과 전송 블록(transport block) 전달을 통과함을 확인했습니다.

---

## 3. Attack Surface: NB-IoT and SIB1-NB

## 3. 공격 표면: NB-IoT 및 SIB1-NB

### 3.1 Pre-association attack surface

### 3.1 연결 전(pre-association) 공격 표면

NB-IoT (Narrowband Internet of Things) is 3GPP Release 13, designed to connect constrained
IoT devices using existing licensed LTE spectrum. It is implemented in a wide range of modern
cellular SoCs including those in consumer smartphones.

NB-IoT(Narrowband Internet of Things)는 3GPP Release 13으로, 기존의 면허 LTE 대역을 사용하여 제한된(constrained) IoT 기기를 연결하도록 설계되었습니다. 소비자용 스마트폰에 탑재된 SoC를 포함한 다양한 최신 셀룰러 SoC에 구현되어 있습니다.

While in RRC_IDLE, before any RRC connection is established, a device searching for service
will:

RRC_IDLE 상태에서 RRC 연결이 설정되기 전에, 서비스를 검색하는 기기는 다음을 수행합니다:

1. Synchronize with the cell's timing signals (NPSS/NSSS)
2. Decode the Master Information Block over NPBCH (640 ms transmission window)
3. Decode SIB1-NB from NPDSCH (2560 ms schedule)
4. Use the scheduling information in SIB1-NB to locate additional system information blocks

1. 셀의 타이밍 신호(NPSS/NSSS)와 동기화
2. NPBCH를 통해 마스터 정보 블록(Master Information Block)을 디코딩(640 ms 전송 창)
3. NPDSCH에서 SIB1-NB를 디코딩(2560 ms 스케줄)
4. SIB1-NB의 스케줄링 정보를 사용하여 추가 시스템 정보 블록을 찾음

At step 3, the modem processes a message from an entity it has not authenticated, before any
connection or user interaction. A rogue transmitter satisfying normal cell selection
conditions will be processed.

3단계에서 모뎀은 연결이나 사용자 상호작용이 발생하기 전에 인증되지 않은 엔티티로부터 온 메시지를 처리합니다. 정상적인 셀 선택 조건을 충족하는 악성(rogue) 송신기도 처리됩니다.```
+------------------+                   +---------------------+
|  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]      |

The CATI debug section was decompressed and parsed with `mtk_dbg_extract.py symbols`, then  
imported into Ghidra via `ImportSymbolsScript.py`. The result was full internal function  
names throughout the modem stack — ERRC layer, L1 channel management, IPC subsystem, and the  
NB-IoT BCCH handler chain — allowing semantics-guided chain reconstruction.

이 게시물의 모든 함수 이름은 펌웨어 이미지에서 추출한 MediaTek 자체 임베디드 디버그 심볼에서 비롯된 것입니다.

---

## 5. 취약점

### 5.1 취약한 루프

`el1_ch_nbcch_resume_req` (`0x90213940`)는 NB-IoT 브로드캐스트 채널 재개 이벤트를 처리합니다.  
해당 MIPS16e2 함수 프롤로그:```asm
90213940:  save  0xE8, ra, s0-s1

실제 펌웨어 바이너리의 Ghidra 디컴파일 결과:```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(바이트 `sb` 쓰기)는 `new_sp+0x78`에서 시작하며 RA 슬롯에 도달하려면 반복 108이 필요합니다:```
new_sp + 0x78 + i = new_sp + 0xE4
i = 0xE4 - 0x78 = 108

### 5.4 ERRC 빌더 — 레이어 A

CPHY_CFG_REQ 버퍼는 디코딩된 SIB1-NB로부터 ERRC 레이어에서 빌드됩니다. 함수
`errc_chm_l1_set_bcch_si_reception`은 `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 3계층 클램핑 부재

| 계층 | 함수 | 주소 | 클램프 존재? |
|---|---|---|---|
| A — ERRC 빌더 | `errc_chm_l1_set_bcch_si_reception` | ERRC 범위 | **없음** |
| B — L1 복사 | `el1_ch_nbcch_start` | `0x90213444` | **없음** |
| C — L1 루프 | `el1_ch_nbcch_resume_req` | `0x90213940` | **없음** |

어느 한 계층에서라도 단 하나의 검사만 있었어도 체인이 끊어졌을 것이다.

### 5.7 근본 원인

위반된 불변 조건 하나:

> SI 스케줄링 항목 수는 대상 배열 용량을 절대 초과해서는 안 된다.

3GPP는 의도된 프로토콜 상한(8개 항목)을 제공한다. 펌웨어는 카운트가 인덱스 또는 루프 한계가 되는 모든 계층에서 메모리 안전 상한을 강제해야 했다. 취약한 빌드에서는 카운트가 SIB1-NB 브로드캐스트 필드에서 ERRC 디코더를 거쳐 CPHY_CFG_REQ 메시지로, IPC 경계를 넘어 L1 태스크로, 채널 컨텍스트 BSS로, 그리고 스택에 쓰는 루프로 이동했다 — 어떤 계층에서도 클램핑되지 않은 채.

---

## 6. 호출 체인 — 발견 경위

### 6.1 두 경로의 혼동

구조적으로 유사하지만 서로 다른 두 경로가 0x760바이트 구성 버퍼를 `el1_ch_nbcch_main`로 전달할 수 있다:

| 경로 | 출처 | `[+0x99]` 값 | 관련성 |
|---|---|---|---|
| 경로 A (ERRC → L1 IPC) | ERRC가 디코딩된 SIB1-NB에서 CPHY_CFG_REQ 구성 | OTA의 `schedulingInfoList.count` | **취약 경로** |
| 경로 B (L1 내부) | `el1_ch_scs_ind_send`가 내부 IPC 본문 구성 | 하드코딩된 `1` | 취약하지 않음 |

경로 B가 메시지 형식을 확인해 주었다 — 바이트 `+0x99`는 `el1_ch_nbcch_start`가 소비하는 SI 카운트다. 그 카운트는 항상 1로 하드코딩되어 있으므로 오버플로될 수 없다. 외부에서 영향받는 경로는 경로 A다.

### 6.2 쓰기 명령 탐색

펌웨어에서 오프셋 `+0x99`에 쓰는 명령어를 패턴 검색하면 노이즈가 발생했다: T1(직접 `sb`, 약 100건), T2(분할 베이스, 5건), T3(계산된 오프셋, 0건), T4(겹치는 `sh`/`sw`, 약 465건). ERRC 채널 관리 함수는 `msg_send6` 크로스-레퍼런스 목록에 없었는데, ERRC가 `errc_com_send_msg`를 사용하기 때문이다. 에뮬레이션 프로브로 해당 쓰기가 ERRC 측임을 확인했다: L1 디스패처에서 Unicorn 하네스를 실행하고 버퍼의 `+0x99` 오프셋에 대한 쓰기를 감시했지만 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. 검증

이 특정 SM-A145R 모델은 일반적인 출고 빌드 운영에서
취약한 NB-IoT 코드 경로를 실행하지 않는 것으로 보이므로, 하이브리드
에뮬레이션과 정적 분석이 직접적인 하드웨어 재현 대신 사용되었습니다.

**정적으로 입증됨.** 펌웨어 바이너리에는 취약한 명령어 쌍이 포함되어 있습니다. 호출
체인은 심볼, 상호 참조, 그리고 디컴파일된 함수 본문에서 재구성되었습니다.

**에뮬레이션에서 네이티브로 실행됨.** `el1_ch_nbcch_resume_req` 내부의 루프는 실제
MediaTek 펌웨어 바이트로 Unicorn Engine (MIPS32)에서 실행되었습니다.
`0x90213B02`에 있는 펌웨어 자체의 `sh` 명령어가 저장된 복귀 주소 슬롯에 기록했습니다. `RESTORE` 명령어는 손상된 값을
`$ra`에 로드했고, `jrc ra`가 제어권을 전달했습니다.

**명시적으로 모델링됨.** `el1_ch_nbcch_start`의 `lbu`/`sb` 복사는 완전히
네이티브로 실행될 수 없었습니다. RTOS 콜백 테이블 디스패치 경로가 `el1_ch_nbcch_cphy_cfg_req_
process` 내부에 있기 때문인데, 이 경로는 플랫 에뮬레이터가 제공하지 않는 라이브 Nucleus 힙 객체를
기대했습니다. Phase 2의 재개 핸들러(`el1_ch_nbcch_resume_req`)는 BSS 상주 채널 컨텍스트에서만
읽으며 동일한 디스패치 경로를 만나지 않으므로, Phase 2는 동일한 스캐폴딩 없이도
네이티브로 실행되었습니다. Phase 1 부작용 — `IPC_msg[+0x99]`의 1바이트가
`ch_ctx[+0x40A]`에 기록됨 — 은 직접 모델링되어 `[PHASE1-MODEL]`로 표시되었습니다.

**주장하지 않음.** 완전한 종단 간 OTA 하드웨어 재현.

### 7.1 변조 방지

하네스는 한 가지 규칙을 강제했습니다: 어떤 후크도 저장된
복귀 주소 슬롯에 증명 마커를 기록하도록 허용되지 않았습니다. 모든 비펌웨어 메모리 쓰기가 추적되었습니다.```
[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 전달

테스트 페이로드가 NB-IoT PHY 인코딩 및 전송 블록 전달을 통과하는지 확인하기 위해 ZMQ 루프백(RF 방출 없음)이 포함된 srsRAN 4G를 사용했습니다. 페이로드는 의도적으로 비준수한 벡터였습니다. `schedulingInfoList`의 ASN.1 SIZE 제약 조건을 완화하여 40개 항목을 허용했으며, pycrate 라운드트립 디코딩을 통해 바이트 14의 카운트 필드를 확인했습니다.```
SIB1 received
SIB2 activated
exit 0

`ch_ctx[0x40A]`는 BSS에 있으며, 모뎀이 재설정되거나 이후의 채널 구성이 이를 덮어쓸 때까지 공격자의 값을 유지한다.

### 8.2 스택 프레임```
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]

단일 라인 경계 검사는 동일한 주소의 기존 함수 내부에 몇 개의 추가 명령어로 나타날 수 있습니다. 그러나 패치된 바이너리가 보여주는 것은 아키텍처 개정입니다: NBCCH 스케줄링 경로가 재설계되어 `si_count`를 루프 경계로 사용하는 패턴이 더 이상 해당 경로 어디에도 존재하지 않게 되었습니다.

### 10.4 CVE 귀속

여기에 설명된 취약점은 2025년 1월 6일 MediaTek이 공개한 CVE-2024-20154와 일치합니다. 확인 근거:

- 영향받는 펌웨어 제품군(LR12A)이 MediaTek의 게시판과 일치합니다.
- 취약점 유형 — 스택 오버플로, 경계 검사 누락, 악성 기지국으로부터의 RCE, 사용자 상호작용 불필요 — 이 CVE 설명 및 NVD 기록과 일치합니다.
- 패치된 펌웨어는 취약한 것으로 식별된 코드 구조를 정확히 제거합니다.
- 패치 ID MOLY00720348은 MediaTek 게시판 및 Android 보안 게시판(A-376809176)에서 확인되었습니다.
- AI 지원 분석은 수동 확인 전에 재구성된 패턴을 CVE-2024-20154에 독립적으로 매칭했습니다.

---

## 11. 윤리 및 책임 있는 공개

### 11.1 이 게시물에 포함되지 않은 것

무기화된 익스플로잇이 없습니다. 펌웨어 바이너리 콘텐츠가 없습니다. 변조된 페이로드 바이트가 없습니다. 실제 기기를 대상으로 취약점을 트리거하는 단계별 절차가 없습니다. 동작하는 공격을 재현하는 데 필요한 정보 — 특정 모뎀 디코더를 위한 완전한 페이로드 구성, 전체 Phase 1 에뮬레이션을 위한 RTOS 힙 객체 스캐폴딩, 무선(over-the-air) 라디오 구성 —는 의도적으로 누락되었습니다.

### 11.2 ZMQ 루프백과 에뮬레이션이 윤리적 접근 방식인 이유

ZMQ 루프백은 어떠한 신호도 무선으로 전송되지 않았음을 의미합니다. 실제 기기를 대상으로 하지 않았습니다. 통신사 네트워크도 관여하지 않았습니다. 이 증명은 분석가가 소유한 하드웨어의 완전히 격리된 소프트웨어 환경에서 실행됩니다. 이는 연결 전(pre-association) 라디오 취약점을 검증하는 올바른 접근 방식입니다 — 변조된 브로드캐스트를 전송하면 범위 내의 모든 기기에 영향을 미칠 것입니다.

Unicorn 에뮬레이션은 취약한 동작이 특정 기기 상태나 라디오 환경과 무관하게 펌웨어 바이너리 자체에 재현 가능하게 존재함을 입증합니다. 이는 단일 하드웨어 크래시보다 기술적으로 더 강력한 주장이며, 무선으로 무엇이든 배포하는 것을 피합니다.

### 11.3 MediaTek 지식재산권

모든 분석은 소비자 기기에서 합법적으로 획득한 펌웨어와 삼성이 공개 배포한 펌웨어 패키지를 대상으로 수행되었습니다. 독점 문서는 사용되지 않았습니다. MediaTek 내부 구조체 정의와 IPC 메시지 형식은 메모리 안전 실패를 설명하는 데 필요한 범위에서만 설명되었습니다. 이들은 사양으로 공개되지 않습니다.

---