베이스밴드 펌웨어는 Android 코드가 아니다. 이는 SoC의 무선 서브시스템에 있는 별도의 임베디드 시스템으로, 자체 CPU, 자체 RTOS, 자체 메모리 공간을 가지며 Android 프로세스 샌드박스 외부에 존재한다.

### 2.2 모뎀 아키텍처

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

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

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

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

| 완화 기법 | 상태 | 효과 |
|---|---|---|
| ASLR | 없음 | 펌웨어 주소가 정적이며 이미지에서 예측 가능 |
| 스택 카나리 | 없음 | `SAVE`/`RESTORE`가 가드 값 없이 callee-saved 레지스터를 저장 |
| NX / W^X | 없음 | 스택 메모리가 실행 가능 |
| CFI | 없음 | 반환 주소가 어떤 정책에 대해서도 검증되지 않음 |

### 2.4 분석 접근 방식

세 가지 병렬 트랙:

**정적 분석.** Samsung 펌웨어 패키지 → CP 파티션 추출 → `md1img.img` → Ghidra (MIPS LE 32-bit, 베이스 `0x90000000`), NCC Group `mtk_bp` 툴셋을 사용하여 펌웨어 디버그 섹션에서 복구된 MediaTek 엔지니어링 심볼과 함께.

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

**무선 측 검증.** ZMQ 루프백을 사용한 srsRAN 4G — 소프트웨어 전용, RF 방출 없음 — 는 테스트 페이로드가 NB-IoT PHY 인코딩과 전송 블록 전달을 견뎌낸다는 것을 확인했다.

---

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

### 3.1 사전 연관 공격 표면

NB-IoT (Narrowband Internet of Things)는 3GPP Release 13으로, 기존 라이선스 LTE 스펙트럼을 사용하여 제약된 IoT 기기를 연결하도록 설계되었다. 소비자 스마트폰을 포함한 다양한 최신 셀룰러 SoC에 구현되어 있다.

RRC_IDLE 상태에서, RRC 연결이 설정되기 전에, 서비스를 검색하는 기기는:

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

3단계에서 모뎀은 인증하지 않은 엔티티로부터 온 메시지를, 어떤 연결이나 사용자 상호작용도 있기 전에 처리한다. 정상적인 셀 선택 조건을 충족하는 악성 송신기가 처리될 것이다.```
+------------------+                   +---------------------+
|  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]      |

CATI 디버그 섹션은 `mtk_dbg_extract.py symbols`로 압축 해제 및 파싱한 후,
`ImportSymbolsScript.py`를 통해 Ghidra로 임포트했습니다. 그 결과 모뎀 스택 전반에 걸쳐
전체 내부 함수 이름을 확보할 수 있었습니다 — ERRC 계층, L1 채널 관리, IPC 서브시스템,
그리고 NB-IoT BCCH 핸들러 체인 — 이를 통해 의미론 기반 체인 재구성이 가능해졌습니다.

이 글의 모든 함수 이름은 펌웨어 이미지에서 추출한 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 모델은 정상적인 ship-build 동작에서 취약한 NB-IoT 코드 경로를 실행하지 않는 것으로 보이며, 이 때문에 직접적인 하드웨어 재현 대신 하이브리드 에뮬레이션과 정적 분석이 사용되었다.

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

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

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

**주장하지 않음.** 완전한 종단 간 over-the-air 하드웨어 재현.

### 7.1 Anti-tamper

하네스는 한 가지 규칙을 강제했다: 어떤 훅도 저장된 반환 주소 슬롯에 증명 마커를 기록하는 것이 허용되지 않았다. 모든 비펌웨어 메모리 쓰기가 추적되었다.```
[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 루프백(무선 주파수 방출 없음)을 사용한 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 귀속

여기서 설명하는 취약점은 MediaTek이 2025년 1월 6일에 발표한 CVE-2024-20154와 일치한다. 확인 근거:

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

---

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

### 11.1 이 글에 포함되지 않은 것

무기화된 익스플로잇 없음. 펌웨어 바이너리 내용 없음. 변조된 페이로드 바이트 없음. 실제 기기를 대상으로 취약점을 트리거하는 단계별 절차 없음. 동작하는 공격을 재현하는 데 필요한 정보 — 특정 모뎀 디코더를 위한 완전한 페이로드 구성, 전체 Phase 1 에뮬레이션을 위한 RTOS 힙 객체 스캐폴딩, 무선 주파수 구성 — 는 의도적으로 빠져 있다.

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

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

Unicorn 에뮬레이션은 취약한 동작이 펌웨어 바이너리 자체에 존재하며, 특정 기기 상태나 무선 환경과 무관하게 재현 가능함을 보여준다. 이는 단일 하드웨어 충돌보다 기술적으로 더 강력한 주장이며, 무선으로 무엇도 배포하지 않는다.

### 11.3 MediaTek 지적 재산

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

---