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

(सब कुछ deepseek ने लिखा है, मुझे कुछ समझ नहीं आता)

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

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

अस्वीकरण

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

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

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

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

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

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

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

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

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

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

2. प्रिविलेज एस्केलेशन पथ का पूर्ण दृश्य

┌─ सामग्री ────────────────────────────────────────────────┐
│ boot.img + xbl_config.elf (डिवाइस फर्मवेयर से निकाला गया)            │
│        ↓ symbol विश्लेषण                                       │
│ target.h (kernel symbol address, kallsyms से बाइट-दर-बाइट सत्यापित)      │
│        ↓ निर्माण                                           │
│ preload.so ──► डिवाइस पर /data/local/tmp/*.so             │
└────────────────────────────────────────────────────────┘
                 ↓  LD_PRELOAD इंजेक्शन
     ┌──────────── दो-चरणीय (दो स्वतंत्र प्रोसेस अनिवार्य)────────────┐
     │ चरण 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. Address मॉडल KASLR से स्वतंत्र है। पूरा शोषण केवल linear mapping alias का उपयोग करता है alias(image) = PAGE_OFFSET | (image − KIMAGE_TEXT_BASE + Δ), रीबूट के पार स्थिर; तथाकथित "slide चरण" का वास्तविक मूल्य write primitive का स्व-परीक्षण है, KASLR बायपास नहीं।

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

3. सामग्री सूची

4. समयरेखा

5. आने वालों के लिए एक पंक्ति

यदि आप भी BL लॉक डिवाइस पर हमला कर रहे हैं, तो पहले सोच लें कि root लेकर क्या करना है, क्योंकि ऐसे डिवाइस पर root संभवतः केवल दसियों मिनट की खिड़की होगी। "root चाहिए और रीबूट के पार बना रहे" वाले कार्यों की सूची बनाएँ, एक बार में पूरा चलाएँ, फिर reboot करके साफ़ स्थिति में लौटें। "दुष्प्रभाव हटाने" की कोशिश न करें —— वह तकनीक की स्वयं की कीमत है।