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

(전부 deepseek가 작성했고, 나는 아무것도 모름) (며칠 더 삽질했지만 진전은 0, 포기함) (현재 root 획득은 가능하지만 매우 불안정하고, root 후 네트워크가 끊기며, 케이블을 뽑으면 재부팅됨) (이 저장소의 모든 결론은 荣耀 WIN RT, CVE-2026-43499 취약점, 6.6.118-android15-8-gf17133276a57-abogki518694926-4k 커널에만 적용되며, 결론을 임시 root로 확대 해석하지 마십시오. 임시 root는 지속적이고 상대적으로 안정적으로 동작할 수 있습니다)

기기 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가 아니라, 「언제든 폭발할 수 있는 상태」다.

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

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

항목	값	설명
기종	荣耀 WIN RT, 모델 AAK-AN00	통칭 「荣耀 WIN RT」
SoC	스냅드래곤 8 엘리트 SM8750-AB	荣耀 WIN(AAP-AN00, SM8850-AC)과 펌웨어 호환 안 됨
시스템	Android 16 / MagicOS 10	—
커널	`6.6.118-android15-8-gf17133276a57-abogki518694926-4k`	★ 필수 조건, 문자 단위 일치
커널 설정	4K pages, `VA_BITS=39`, `CONFIG_FUTEX_PI=y`	캐리어 기하학의 전제
펌웨어 패키지	`.170`	`.160` / `.175` 미검증
Bootloader	영구 잠금	fastboot 없음 / 영구 su 없음

왜 커널 버전을 반드시 고정해야 하는가: 결함은 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):

순서 철칙: 먼저 real_cred, 그다음 cred. 역순이면 순간적으로 완전 권한이 되어 스레드가 통제 불능이 된다.
두 번의 쓰기 사이에는 반드시 cred ≠ real_cred인 과도 상태가 존재한다. 이때 어떤 sched_setaffinity든 EPERM → 전체 라운드가 멈춘다. 정답은 첫 번째 쓰기 이전에 「사전 배치 라이터」 프로세스를 fork하는 것(자격 증명이 깨끗함), 부모 프로세스가 첫 번째 쓰기를, 라이터가 두 번째 쓰기를 하면 누구도 과도 상태에서 syscall을 호출하지 않는다.
주소 모델은 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. 목차

문서	내용
01 · 실현 가능성 분석	왜 `rt_sigreturn` 하나만 캐리어로 남았는가
02 · 권한 상승 체인과 성공 요소	쓰기 원시 연산, 6단계 체인, 사전 배치 라이터, 성공 판정 기준
03 · 안정성의 진짜 원인: PI 체인 잔류	★ 핵심. 네트워크 끊김이 아니라 panic; 크래시 지점 디스어셈블리 포함
04 · PC 불필요 채널: Shizuku	Shizuku의 rish로 adb를 대체하여 exploit 실행
05 · KernelSU의 late-load	LKM 활성화 방식과 그것이 왜 가장 위험한 기폭 장치인가
06 · 막다른 길 목록	시도했지만 안 되는 길, 다른 사람이 재시도하지 않도록
07 · 함정과 환경	root 없이 panic 스택 얻기, 스크립트 환경 함정
08 · 흔한 오진 변별	가장 널리 퍼진 잘못된 해석을 항목별로 검증 (「KSU 모듈로 잔류 정리」가 왜 불가능한지 포함)
09 · 두 채널 운영 실무	★ 손을 어떻게 움직이는가 —— adb 측 / Shizuku 측 전체 흐름, 환경 변수, 판독과 마무리
10 · B류 네트워크 끊김 정론	★ 재부팅은 안 되지만 네트워크 마비; `ping 127.0.0.1` 전부 손실; 30초 속판
tools/	재사용 가능 스크립트 (비식별화 범용판)

4. 타임라인

날짜	진전
09-08	BL 영구 잠금, OEM 언락 채널 제거 확인 ⇒ 공식 경로 포기, 취약점 경로로 전환
09-09	제조사 A/S 펌웨어 라이브러리 공략, boot.img 확보, 커널과 심볼 추출
09-10	캐리어 탐색이 `rt_sigreturn`으로 수렴; 권한 상승 성공(20:14), `uid=0`
09-11	PC 불필요 채널(Shizuku) 개통; KernelSU 활성화 가능; 「네트워크 끊김」 진짜 원인 = PI 체인 잔류로 규정
09-12	① 「late-load가 최우선 기폭 장치」라는 귀인 편향 반박 ⇒ 기본을 KSU 켜기로 변경; ② USB 판정 기준을 「뽑으면 기폭, 꽂으면 안전」으로 세분화; ③ B류 네트워크 끊김 정론 = 커널 IP 출력 경로 마비(`ping 127.0.0.1` 전부 손실, `OutDiscards 53%`)
09-13	도구 확정 v6(분할 창 대기 / 메트로놈 / `.stop` 중단 / 진단은 fd3로, 두 포트 기준 통일); 본 문서에 운영 실무와 B류 정론 보강

5. 가장 헷갈리기 쉬운 네 가지

#	흔한 오해	실제
1	「USB를 뽑든 꽂든 위험하다」	뽑는 것이 위험, 꽂는 것이 안전(09-12 실측, docs/08 §2.2 참조)
2	「late-load KernelSU가 최우선 기폭 장치다」	09-11의 귀인 편향; 진짜 원인은 PI 체인 잔류이며, 실측 late-load 후 43분 안정(docs/05)
3	「권한 상승 후 네트워크 끊김 = Wi-Fi 고장」	먼저 `ping 127.0.0.1`. loopback도 안 되면 ⇒ 커널 IP 스택 마비, 온라인으로는 고칠 수 없음(docs/10)
4	「`ps`에서 NAME이 `true`인 프로세스는 정리해도 된다」	그것의 `comm`은 `GWROOT42`이며 스프레이 페이지를 쥐고 있음 ⇒ kill하면 즉시 panic할 수 있음

6. 후발 주자에게 한마디

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

cve-2026-43499-aak-an00

인기