CVE-2026-43499 · 荣耀 WIN RT (AAK-AN00) 임시 Root 연구 노트

(전부 deepseek가 작성했고, 나는 아무것도 모름)

기기 Bootloader 영구 잠금(ro.oem_unlock.supported 비어 있음), fastboot 없음, 영구 su 없음, Magisk 없음. 유일하게 남은 길은 커널 취약점. 이 저장소는 「공격 가능한가」부터 「공격 후 얼마나 안정적인가」까지의 전체 과정을 기록한다.

성격: 임시 root, 재부팅 시 무효화.

면책 조항

이 저장소는 본인 소유 기기에서 수행한 보안 연구 과정을 기록한 것으로, 목적은 커널 PI 경쟁 상태의 원인과 안정성 경계를 이해하는 것이다.

• 어떠한 exploit 바이너리나 직접 실행 가능한 공격 페이로드도 포함하지 않는다 —— 페이로드와 프레임워크는 업스트림 공개 프로젝트에서 가져온 것이며, 이 저장소는 인용만 하고 재배포하지 않는다.
• 특정 제조사의 우회 수단에 대한 튜토리얼을 제공하지 않으며, 비인가 기기에서의 사용을 권장하지 않는다.
• 저장소 내의 오프셋, 심볼 주소는 본문에 나열된 그 하나의 커널 build에만 유효하며, 커널이 바뀌면 전부 무효가 된다.
• 관련 결함은 upstream에서 이미 수정되었다(아래 참조). 본문의 장기적 가치는 「이 기록 자체」에 있다 —— 실제적이고 비이상적인 조건에서의 경쟁 상태 취약점 실전 복기, 그 모든 불편한 부작용을 포함하여.

0. 한 줄 결론

유일하게 성공한 경로는:

CVE-2026-43499 (futex PI 경쟁 상태 write-what-where) + rt_sigreturn 캐리어
  → LD_PRELOAD로 shell 도메인 프로세스에 주입
  → 2단계: 먼저 SELinux Permissive로 전환, 그다음 task->real_cred / cred를 init_cred로 변경
  → uid=0(root) context=u:r:kernel:s0, 그리고 su 데몬 이식

하지만 진짜 기록할 가치가 있는 것은 「어떻게 root를 얻는가」가 아니다 —— root를 얻은 후에 벌어지는 일이다.

얻은 것은 안정적인 root가 아니라, 「언제든 폭발할 수 있는 상태」다.

exploit의 쓰기 원시 연산은 위조된 rt_mutex_waiter를 실제 futex PI 체인에 삽입하며, 이 waiter의 운반체는 이후 시스템 콜에 의해 재사용될 커널 스택 / 스프레이 페이지다. 따라서 root가 착지한 그 순간부터, 어떤 시스템 수준 스케줄링이나 우선순위 변동이든 그것을 밟을 수 있고, 곧바로 커널 panic 재부팅으로 이어진다. 이것은 버그가 아니라 이 공격 기법의 내재적 대가다 —— 자세한 내용은 docs/03 참조.

1. 적용 경계 (불일치 시 전체 방안 무효)

왜 커널 버전을 반드시 고정해야 하는가: 결함은 6.6.140에서 수정되었고, 본 기기는 6.6.118 < 6.6.140이므로 아직 남아 있다; 동시에 exploit의 모든 커널 심볼 주소와 「캐리어 기하학」이 이 하나의 build에 고정되어 있어, 커널이 바뀌면 오프셋 테이블이 즉시 무효가 되며, 일반적으로 롤백 불가하다.

2. 권한 상승 경로 전체도

┌─ 재료 ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (기기 펌웨어에서 추출)       │
│        ↓ 심볼 해석                                      │
│ target.h (커널 심볼 주소, kallsyms와 바이트 단위 대조 완료) │
│        ↓ 빌드                                           │
│ preload.so ──► 기기 측 /data/local/tmp/*.so            │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD 주입
     ┌──────────── 2단계 (반드시 두 개의 독립 프로세스) ────┐
     │ 단계 A  GW_SELINUX=1        → selinux_state.enforcing = 0   │
     │ 단계 B  GW_CHAIN=1 RTSIG_TASK_INIT=1 GW_SU=1               │
     │         → task->real_cred ← &init_cred                      │
     │         → task->cred      ← &init_cred ("사전 배치 라이터" 프로세스가 수행)│
     │         → setresuid(0,0,0) 정규화                           │
     │         → 내장 su + daemon 이식                             │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

반드시 정확히 해야 하는 세 가지 (틀리면 멈추거나 곧바로 panic):

1. 순서 철칙: 먼저 real_cred, 그다음 cred. 반대로 하면 순간적으로 완전 권한이 되어 스레드가 통제 불능이 된다.
2. 두 번의 쓰기 사이에는 반드시 cred ≠ real_cred인 과도 상태가 존재한다. 이때 어떤 sched_setaffinity든 EPERM → 전체 라운드가 멈춘다. 정답은 첫 번째 쓰기 이전에 「사전 배치 라이터」 프로세스를 fork하는 것(자격 증명이 깨끗함), 부모 프로세스가 첫 번째 쓰기를, 라이터가 두 번째 쓰기를 수행하여, 누구도 과도 상태에서 syscall을 발행하지 않게 하는 것이다.
3. 주소 모델은 KASLR과 무관하다. 전체 공격은 선형 매핑 별칭만 사용한다 alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), 재부팅 간 안정적; 소위 "slide 단계"의 진짜 가치는 쓰기 원시 연산 자체 점검이지, KASLR 우회가 아니다.

업스트림 프레임워크: Linuxoid-cn/CVE-2026-43499-Poc-Analysis. 이것은 GhostLock이 아니다 —— GhostLock은 pselect 경로를 사용하며, 본 build의 waiter 착지 기하학과 일치하지 않는다, 자세한 내용은 docs/06 참조.

3. 목차

4. 타임라인

5. 후발 주자에게 한마디

당신도 BL이 잠긴 기종을 공략하고 있다면, 먼저 root로 무엇을 할지 명확히 생각하라, 왜냐하면 이런 기종에서 root는 아마 겨우 십몇 분만 쓸 수 있는 창일 것이기 때문이다. 「root가 필요하고 재부팅을 넘어 유지되어야 하는」 작업을 목록으로 만들고, 한 번에 전부 실행한 뒤 reboot하여 깨끗한 상태로 돌아가라. 「부작용을 제거」하려 하지 마라 —— 그것은 기법 자체의 대가다.