smt878u-ionstack-poc

[!CAUTION] यह प्रोजेक्ट अधूरा है — यह अभी काम नहीं करता। 2026-10-06 तक किसी भी डिवाइस पर कोई कार्यशील रूट नहीं है। नीचे दिए गए क्विक-स्टार्ट के सफल होने की अपेक्षा न करें। कुछ भी बनाने या चलाने से पहले वर्तमान स्थिति पढ़ें।

[!WARNING] स्थिति: कार्य प्रगति पर — रिंग 1 अभी तक पूरी नहीं हुई

• प्राप्त नहीं हुआ: SM-T878U पर स्थायी या एक-बार का root भी नहीं।
• अंतिम सत्यापित विफलता: स्टैक-रीक्लेम पेलोड कर्नेल के राइट पाथ तक कभी नहीं पहुँचता। लगभग 470 इंस्ट्रुमेंटेड रन्स में नकली लॉक को rtmutex.c:585 पर कभी लिया जाता हुआ नहीं देखा गया, इसलिए स्टोर *(ASHMEM_MISC_FOPS) = fake_fops कभी निष्पादित नहीं होता।
• पूर्व अवरोधक, अब हल हो गया: क्रैश फोरेंसिक्स पहले uid 2000 shell के लिए उपलब्ध नहीं था (/proc/kmsg, /proc/last_kmsg, /sys/fs/pstore, dmesg → सभी EACCES)। अब एक टिकाऊ write()+fsync() लॉग मिरर (IONSTACK_LOG_MIRROR) CONFIG_PANIC_ON_OOPS=y के बाद भी बचा रहता है, इसलिए पैनिक हुए रन का भी पूरा ट्रेल छूटता है।
• पूरा साक्ष्य ट्रेल देखने के लिए docs/RTMUTEX_WEAPONIZATION.md §15.16–§15.18 देखें।

Samsung Galaxy Tab S7 (SM-T878U / gts7l) के लिए CVE-2026-43499 (IonStack / GhostLock) के विरुद्ध शुद्ध-C, होस्ट-सहायता प्राप्त री-रूट प्रूफ़ ऑफ़ कॉन्सेप्ट।

रनटाइम चेन केवल नेटिव C/ELF कंपोनेंट्स का उपयोग करती है। इसे Android टारगेट पर Python, Java, DEX, app_process, या JVM की आवश्यकता नहीं होती। ADB का उपयोग डिप्लॉयमेंट और सत्यापन के लिए किया जाता है।

---

वर्तमान स्थिति (अधूरी)

कोई रूट प्राप्त नहीं हुआ है। यह अनुभाग चेन की वर्तमान स्थिति का आधिकारिक, अद्यतित विवरण है (अंतिम संशोधन 2026-10-06)। नीचे सब कुछ वास्तविक हार्डवेयर (SM-T878U, T878USQS8DXE1, कर्नेल 4.19.113-27114284) पर मापा गया है, सिद्धांत नहीं।

जो काम करता हुआ सिद्ध है

चरण	स्थिति	साक्ष्य
टारगेट पहचान + KASLR लीक	कार्यशील	[reroot] LEAK_OK kaslr_base=… task=… (perf साइड-चैनल)
CVE ट्रिगर: FUTEX_CMP_REQUEUE_PI → -EDEADLK	कार्यशील	[*] requeue ret=-1 errno=35 — Linux पर EDEADLK == 35
बगी रोलबैक एक लटकता pi_blocked_on छोड़ता है	अपस्ट्रीम फ़िक्स से मेल खाता है	अपस्ट्रीम 3bfdc63936dd current->pi_blocked_on → waiter->task->pi_blocked_on बदलता है
struct rt_mutex_waiter लेआउट (4.19)	स्रोत से सत्यापित	tree_entry@0x00 pi_tree_entry@0x18 task@0x30 lock@0x38 prio@0x40 deadline@0x48
स्टैक ज्यामिति paint == rt_waiter + 0x28	4× सत्यापित, objdump सहित	rt_waiter = do_futex_sp+0xC0; address = ___sys_sendmsg_sp+0xB8
टिकाऊ क्रैश फोरेंसिक्स	कार्यशील	IONSTACK_LOG_MIRROR write()+fsync() ट्रेल पैनिक रीबूट के बाद भी बचता है
प्रति-संदेश फ्रैग-पेज पहचान टैग	कार्यशील	reclaim-scan tag=1 sent=8201 range=1..8201 ok=8192 bad=0 dup=0 undecoded=0 absent=9
क्यू स्कैन: कर्नेल ने 8192 क्यूड फ्रैग पेजों में 0 बाइट लिखे	सत्यापित	256 MB की पेलोड से बाइट-दर-बाइट तुलना, hits=0
rt_mutex_adjust_prio_chain राइट पाथ तक पहुँचता है	डिसअसेम्बली से सत्यापित	top_waiter == NULL ⇒ requeue true रहता है ⇒ 664/682/685/716-725 संरचनात्मक रूप से पहुँच योग्य

जो काम नहीं कर रहा है

1. लेखन पथ कभी निष्पादित नहीं होता। लगभग 470 इंस्ट्रुमेंटेड रनों में, सभी 174 page-dump और 45 ring1-page अवलोकन first_diff=8000 (pristine), owner_cpu=00000000, case1_gate=0, और lock_root/lock_leftmost को पेलोड मान के बिल्कुल बराबर रिपोर्ट करते हैं। वॉक को कभी भी rtmutex.c:585 पर fake_lock->wait_lock लेते हुए नहीं देखा गया है, इसलिए 664/682/685/716-725 — जो एकमात्र शाखा है जो *(ASHMEM_MISC_FOPS) में संग्रहीत कर सकती है — कभी नहीं चली है। ध्यान दें कि _raw_spin_trylock()/_raw_spin_unlock() आउट-ऑफ-लाइन हेल्पर्स के माध्यम से रूट करते हैं और इस वेंडर ट्री में कोई arm64 queued_spin_unlock ओवरराइड नहीं है, इसलिए wait_lock.val == 1 विश्वसनीय 585 साक्षी है और owner_cpu != 0 केवल एक द्वितीयक साक्षी है।
2. प्रकाशित वाहन यहाँ उपलब्ध नहीं है। इस CVE का एकमात्र सार्वजनिक सफल एक्सप्लॉइट (NebuSec, IonStack part II) फ्रेम को prctl(PR_SET_MM, PR_SET_MM_MAP, …) के साथ पुनःप्राप्त करता है। यह कर्नेल # CONFIG_CHECKPOINT_RESTORE is not set के साथ आता है, इसलिए वह सिस्कॉल कंपाइल से बाहर है। यह sendmsg का भी कभी उपयोग नहीं करता — जो हमारा वाहन है — जो बहुत संभवतः (1) का मूल कारण है।
3. ring1-read कभी नहीं चला है। रिंग 1 का एकमात्र यूज़रस्पेस रीड-बैक (configfs_read_once(fd, data_addr(ASHMEM_MISC_FOPS), …)) क्यू-स्कैन गेट के पीछे और हार्नेस MARKER डिफ़ॉल्ट के पीछे स्थित है, जो 8 सेकंड पहले ring1-page पर रुक जाता है। गेट तक पहुँचने वाला प्रत्येक रन page-dump tag=pre-arm और page-dump tag=post-arm के बीच मर गया।

तत्काल अगले कदम (प्राथमिकता क्रम में)

1. उस एक कॉन्फ़िगरेशन को पुनः चलाएँ जिसमें 664/682/685 हमारे अपने पेज के भीतर पूर्ण हो सकते हैं — IONSTACK_FOPS_WAIT_LOCK_WORD=0 के साथ IONSTACK_PAINT_WAITER_TASK_MODE=fake-task — और wait_lock=00000001 के लिए page-dump tag=post-arm / ring1-lock585 पढ़ें।
2. ring1-read को निष्पादित करवाएँ: IONSTACK_RECLAIM_SCAN_QUEUE को अनसेट रखकर और MARKER='ring1-read|…' के साथ चलाएँ ताकि हार्नेस ring1-page पर न रुके।
3. धारित पेज की पहचान करें: IONSTACK_RECLAIM_TAG=1 के साथ चलाएँ और page-dump में pipe_tag की msg_tag से तुलना करें। सभी फ्रैग पेज पेलोड की बाइट-समान प्रतियाँ हैं, इसलिए अकेला first_diff उन्हें अलग नहीं बता सकता।
4. IONSTACK_FOPS_WAIT_LOCK_WORD प्रश्न को उचित रूप से प्रस्तुत आधार पर पुनः परीक्षण करें — IONSTACK_RECLAIM_TAG को स्थिर रखते हुए wlw=0 बनाम wlw=1। पहले का सहसंबंध दो चरों के साथ-साथ बदलने से दूषित था।
5. K40 4.19 पोर्ट से res_in/res_out pselect6 पेंट सरफेस को पोर्ट करें।
6. केवल तब लेखन प्रिमिटिव को विशेषाधिकार वृद्धि में परिवर्तित करें।

असंबंधित खुला बग

fops.c:3157 reason=selinux_write ret=-1 errno=22 EINVAL — अभी भी अनसुलझा।

---

प्रलेखन

दस्तावेज़	क्या
docs/RTMUTEX_WEAPONIZATION.md	rtmutex श्रृंखला के लिए पूर्ण साक्ष्य-पथ (सबसे बड़ा दस्तावेज़)
docs/ROOT_CHAIN_THEORY.md	एंड-टू-एंड रिंग 0→4 रूट श्रृंखला डिज़ाइन
docs/PAINT_ORACLE_ANALYSIS.md	स्टैक-पेंट ओरेकल ऐसा क्यों पढ़ता है जैसा पढ़ता है
docs/PSELECT_GEOMETRY_FINDINGS.md	वैकल्पिक पेंट वाहन के रूप में pselect6
docs/RING1_RECLAIM_IDENTITY_2026-10-06.md	प्रति-संदेश फ्रैग-पेज पहचान टैग; क्यू-स्कैन सत्यापन
docs/RING1_585_NEVER_SUCCEEDED_2026-10-06.md	प्रमाण कि rtmutex.c:585 कभी सफल नहीं हुआ
docs/RING1_ORACLE_FIX_2026-10-05.md	ओरेकल सुधार
docs/RING1_ORACLE_WRONG_FRAGMENT_2026-10-06.md	धारित फ्रैगमेंट की गलत पहचान क्यों हुई

---

लक्ष्य आर्टिफैक्ट (बाहरी विश्लेषण के लिए)

target-artifacts/ में इस लक्ष्य का विश्लेषण डिवाइस के बिना करने के लिए आवश्यक सब कुछ है: