CVE-2026-43499 · 荣耀 WIN RT (AAK-AN00) अस्थायी Root शोध नोट्स

(सब कुछ deepseek ने लिखा है, मुझे कुछ समझ नहीं आता) (कुछ और दिन बर्बाद किए, प्रगति शून्य, छोड़ दिया) (फिलहाल root प्राप्त किया जा सकता है, लेकिन बहुत अस्थिर है, root के बाद नेटवर्क कट जाता है, केबल निकालने पर रीबूट हो जाता है) (इस रिपॉज़िटरी के सभी निष्कर्ष केवल 荣耀 WIN RT, CVE-2026-43499 vulnerability, 6.6.118-android15-8-gf17133276a57-abogki518694926-4k kernel पर लागू होते हैं, निष्कर्षों को अस्थायी root तक न फैलाएं, अस्थायी root लगातार और अपेक्षाकृत स्थिर रूप से चल सकता है)

डिवाइस Bootloader स्थायी रूप से लॉक है (ro.oem_unlock.supported खाली है), न fastboot, न स्थायी su, न Magisk। एकमात्र शेष मार्ग kernel vulnerability है। यह रिपॉज़िटरी "हमला संभव है या नहीं" से लेकर "हमले के बाद वास्तव में कितना स्थिर है" तक की पूरी प्रक्रिया दर्ज करती है।

प्रकृति: अस्थायी root, रीबूट पर समाप्त।

---

अस्वीकरण

यह रिपॉज़िटरी स्वयं के स्वामित्व वाले डिवाइस पर किए गए सुरक्षा शोध की प्रक्रिया दर्ज करती है, जिसका उद्देश्य kernel PI race के कारणों और स्थिरता की सीमाओं को समझना है।

• इसमें कोई exploit binary या सीधे चलाने योग्य payload शामिल नहीं है —— payload और framework upstream के सार्वजनिक प्रोजेक्ट से हैं, यह रिपॉज़िटरी केवल संदर्भ देती है, पुनःवितरित नहीं करती।
• किसी विशिष्ट निर्माता के bypass उपायों के लिए ट्यूटोरियल प्रदान नहीं करती, अनधिकृत डिवाइस पर उपयोग को प्रोत्साहित नहीं करती।
• रिपॉज़िटरी के offsets और symbol addresses केवल इस दस्तावेज़ में सूचीबद्ध उस एक kernel build के लिए मान्य हैं, kernel बदलते ही सब अमान्य हो जाते हैं।
• संबंधित दोष upstream में पहले ही ठीक किए जा चुके हैं (नीचे देखें)। इस दस्तावेज़ का दीर्घकालिक मूल्य "यह अभिलेख स्वयं" में है —— एक वास्तविक, गैर-आदर्श परिस्थितियों में race vulnerability का व्यावहारिक पुनरावलोकन, जिसमें इसके सभी असहज दुष्प्रभाव शामिल हैं।

---

0. एक पंक्ति में निष्कर्ष

एकमात्र सफल मार्ग यह है:

CVE-2026-43499（futex PI race write-what-where） + rt_sigreturn carrier
  → LD_PRELOAD से shell domain process में inject
  → दो-चरणीय: पहले SELinux Permissive, फिर task->real_cred / cred को init_cred में बदलें
  → uid=0(root) context=u:r:kernel:s0, और su daemon स्थापित करें

लेकिन वास्तव में लिखने योग्य बात "root कैसे मिला" नहीं है —— बल्कि उसके बाद जो हुआ वह है।

जो मिला वह स्थिर root नहीं, बल्कि "कभी भी विस्फोट हो सकने वाली स्थिति" है।

exploit का write primitive नकली rt_mutex_waiter को असली futex PI chain में लटका देता है, और इस waiter का वाहक वह kernel stack / spray page है जिसे आगे के system calls पुनः उपयोग करेंगे। इसलिए root मिलने के क्षण से ही, कोई भी system-level scheduling या priority परिवर्तन उस पर पैर रख सकता है, सीधे kernel panic और reboot। यह bug नहीं है, यह इस exploitation तकनीक की अंतर्निहित कीमत है —— विस्तार के लिए देखें docs/03।

---

1. लागू सीमाएँ (मेल न खाने पर पूरी योजना अमान्य)

मद	मान	विवरण
मॉडल	荣耀 WIN RT, मॉडल AAK-AN00	प्रचलित नाम "荣耀 WIN RT"
SoC	Snapdragon 8 Elite SM8750-AB	荣耀 WIN (AAP-AN00, SM8850-AC) के साथ firmware असंगत
सिस्टम	Android 16 / MagicOS 10	—
Kernel	6.6.118-android15-8-gf17133276a57-abogki518694926-4k	★ कठोर शर्त, अक्षर-दर-अक्षर मिलान
Kernel config	4K pages, VA_BITS=39, CONFIG_FUTEX_PI=y	carrier geometry की पूर्वापेक्षा
Firmware पैकेज	.170	.160 / .175 का परीक्षण नहीं किया गया
Bootloader	स्थायी रूप से लॉक	न fastboot / न स्थायी su

kernel संस्करण क्यों बाध्यकारी है: दोष 6.6.140 में ठीक किया गया, इस डिवाइस का 6.6.118 < 6.6.140 इसलिए अभी भी मौजूद है; साथ ही exploit के सभी kernel symbol addresses और "carrier geometry" इसी एक build पर आधारित हैं, kernel बदलने पर offset table तुरंत अमान्य हो जाती है, और सामान्यतः वापस नहीं जा सकते।

---

2. privilege escalation पथ का पूर्ण दृश्य

┌─ सामग्री ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf（डिवाइस firmware से निकाला）    │
│        ↓ symbol resolution                              │
│ target.h（kernel symbol addresses, kallsyms से byte-by-byte सत्यापित）│
│        ↓ build                                          │
│ preload.so ──► डिवाइस पर /data/local/tmp/*.so            │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD inject
     ┌──────────── दो-चरणीय（दो स्वतंत्र processes अनिवार्य）────────────┐
     │ चरण 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（"प्री-सेट राइटर" process द्वारा）│
     │         → setresuid(0,0,0) सामान्यीकरण                       │
     │         → अंतर्निहित su + daemon स्थापित                     │
     └─────────────────────────────────────────────────────────────┘
                 ↓
     uid=0(root) context=u:r:kernel:s0

तीन बातें जो सही करनी ही होंगी (गलत करने पर अटक जाएंगे या सीधे panic):

1. क्रम का नियम: पहले real_cred, फिर cred। उल्टा करने पर तुरंत पूर्ण अनुमतियाँ, threads बेकाबू।
2. दो कटों के बीच अनिवार्यतः cred ≠ real_cred की क्षणिक अवस्था होती है। इस समय कोई भी sched_setaffinity EPERM देगा → पूरा दौर अटक जाएगा। सही उपाय है पहले कट से पहले ही "प्री-सेट राइटर" process fork कर लेना (credentials साफ), parent पहला कट करे, writer दूसरा कट, कोई भी क्षणिक अवस्था में syscall न करे।
3. address model KASLR से स्वतंत्र है। पूरी exploitation केवल linear mapping alias से चलती है alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), reboot के पार स्थिर; तथाकथित "slide चरण" का वास्तविक मूल्य write primitive का स्व-परीक्षण है, KASLR bypass नहीं।

upstream framework: Linuxoid-cn/CVE-2026-43499-Poc-Analysis। ध्यान दें यह GhostLock नहीं है —— GhostLock pselect मार्ग लेता है, इस build की waiter landing geometry से मेल नहीं खाता, विस्तार के लिए देखें docs/06।

---

3. विषय-सूची