accessmodifier364/cve-2026-43499-firetv-sheldonp-writeupAmazon Fire TV Stick 3rd Gen (sheldonp) पर CVE-2026-43499 का शोषण करने पर सुरक्षा शोध लेख, अस्थायी रूट से बूटलोडर अनलॉक तक।
sheldonp) पर CVE-2026-43499एक Linux कर्नेल विशेषाधिकार वृद्धि (privilege escalation) को प्रीलोडर डाउनग्रेड और बूटलोडर अनलॉक में श्रृंखलाबद्ध करना।
यह रिपॉज़िटरी Amazon Fire TV Stick 3rd Gen (sheldonp) पर CVE-2026-43499 शोषण श्रृंखला के मेरे अधिकृत पुनरुत्पादन का दस्तावेज़ीकरण करती है। इस श्रृंखला ने एक नियंत्रित प्रीलोडर डाउनग्रेड चलाने के लिए अस्थायी कर्नेल रूट का उपयोग किया, फिर अनलॉक किए गए fastboot तक पहुँचने और बूटलोडर अनलॉक पूरा करने के लिए मौजूदा Kamakiri BootROM वर्कफ़्लो का उपयोग किया।
यह एक पुनरुत्पादन और डिवाइस-विशिष्ट केस स्टडी है। मैंने CVE-2026-43499 की खोज नहीं की, मूल IonStack/GhostLock शोषण नहीं बनाया, और न ही Kamakiri विकसित किया। अपस्ट्रीम शोधकर्ताओं और डेवलपर्स को नीचे श्रेय दिया गया है।
[!IMPORTANT] यह लेख एक तकनीकी रिकॉर्ड है, सार्वभौमिक रूटिंग गाइड नहीं। बिल्ड संगतता मायने रखती है, अस्थायी रूट स्थायी रूट नहीं है, और Preloader, LK, TEE, या dm-verity-संरक्षित पार्टीशन से जुड़ी गलतियाँ डिवाइस को स्थायी रूप से ब्रिक कर सकती हैं।
एंड-टू-एंड श्रृंखला 12 सितंबर, 2026 को पूरी हुई। यह रिपॉज़िटरी परीक्षण किए गए डिवाइस और सॉफ़्टवेयर संस्करणों, उपयोग किए गए सटीक आर्काइव, उनके SHA-256 हैश, और प्रक्रिया के दौरान कैप्चर किए गए मूल साक्ष्य को रिकॉर्ड करती है।
| फ़ील्ड | पुनरुत्पादन लक्ष्य |
|---|---|
| डिवाइस | Amazon Fire TV Stick 3rd Gen |
| मॉडल | AFTSSS |
| कोडनेम | sheldonp |
| ऑपरेटिंग सिस्टम | Fire OS 7.7.1.6 / बिल्ड PS7716.5666N |
| इंक्रीमेंटल | 0036005356164 |
| Android आधार | Android 9 |
| कर्नेल | 4.4.162+ |
| BootROM चरण के लिए उपयोग किया गया होस्ट | Ubuntu 26.04.1 LTS, लाइव USB सत्र के रूप में बूट किया गया |
| Android प्लेटफ़ॉर्म टूल्स | 37.0.1 |
| अस्थायी-रूट कार्यान्वयन | R0rt1z2/GhostLock 1.1.0, 4.4 ब्रांच |
| BootROM कार्यान्वयन | kamakiri-sheldon-1.0 |
| परिणाम | अस्थायी रूट, प्रीलोडर डाउनग्रेड, अनलॉक किया गया बूटलोडर, TWRP, और संरक्षित Fire OS |
दायरे से बाहर: भेद्यता खोज, एक नया शोषण कार्यान्वयन, रिमोट शोषण, स्थायी रूट, या परीक्षण किए गए sheldonp यूनिट के अलावा अन्य डिवाइस के लिए समर्थन। इस पुनरुत्पादन के दौरान कोई कस्टम ROM इंस्टॉल नहीं किया गया।
निम्नलिखित इस पुनरुत्पादन के दौरान उपयोग किए गए सटीक ZIP आर्काइव हैं। आर्काइव इस रिपॉज़िटरी में पुनर्वितरित नहीं किए गए हैं; उनके SHA-256 हैश रिकॉर्ड किए गए हैं ताकि स्वतंत्र रूप से प्राप्त प्रतियों की तुलना इस केस स्टडी में उपयोग की गई फ़ाइलों से की जा सके।
| आर्काइव | स्रोत | संस्करण | SHA-256 |
|---|---|---|---|
ghostlock-sheldon-v1.1.0.zip | XDA पर अस्थायी-रूट और डाउनग्रेड गाइड | GhostLock 1.1.0 | 8D541F7DF58487AF6D6D45D778482D3455A71F62E32651751CFE0B2DDFC6554F |
kamakiri-sheldon-1.0.zip | XDA पर बूटलोडर-अनलॉक गाइड | Kamakiri Sheldon 1.0 | 1B07161D9F894935E5918A9B8F9A230F67B9487E9863C242E758338E8C6C5784 |
ये हैश इस केस स्टडी में उपयोग की गई प्रतियों की पहचान करते हैं; पाठकों को अभी भी अपने डाउनलोड की तुलना मूल अपस्ट्रीम स्रोतों से करनी चाहिए और लागू तृतीय-पक्ष लाइसेंस की समीक्षा करनी चाहिए।
CVE-2026-43499, जिसे GhostLock के नाम से भी जाना जाता है, Linux कर्नेल के प्राथमिकता-विरासत (priority-inheritance) futex/rtmutex पथ में एक use-after-free है। प्रॉक्सी-लॉक रोलबैक के दौरान, remove_waiter() ने waiter->task में संग्रहीत टास्क के बजाय current पर कार्य किया। परिणामस्वरूप, वास्तविक वेटर pi_blocked_on के साथ उपयोगकर्ता स्थान (userspace) में लौट सकता था जो अभी भी एक जारी किए गए कर्नेल स्टैक फ़्रेम में एक rt_mutex_waiter को संदर्भित करता था।
मूल IonStack शोध उस लटकते स्टैक संदर्भ को एक स्थानीय विशेषाधिकार-वृद्धि प्रिमिटिव में बदल देता है। R0rt1z2 ने इस तकनीक को 4.4 कर्नेल पर Fire OS 7 चलाने वाले Fire TV Stick 3rd Gen और Fire TV Stick Lite (sheldonp/sheldon) के लिए अनुकूलित किया।
इस केस स्टडी में मुख्य अंतर यह है कि CVE-2026-43499 बूटलोडर को सीधे अनलॉक नहीं करता है। यह अस्थायी रूप से कर्नेल-स्तरीय एक्सेस प्रदान करता है। वह अल्पकालिक एक्सेस नियंत्रित प्रीलोडर डाउनग्रेड करना संभव बनाता है, जो पुरानी Kamakiri BootROM चेन चलने से पहले आवश्यक है।
flowchart LR
A[Fire OS 7 on sheldonp] --> B[CVE-2026-43499 / GhostLock]
B --> C[Temporary root shell]
C --> D[Controlled preloader downgrade]
D --> E[Expected non-booting transition state]
E --> F[Kamakiri BootROM stage]
F --> G[Unlocked fastboot]
G --> H[Bootloader unlocked]
यह श्रृंखला दो अलग-अलग सुरक्षा सीमाओं को पार करती है:
डिवाइस में बदलाव करने से पहले, मैंने हार्डवेयर कोडनेम की पहचान की और ADB के माध्यम से Fire OS, बिल्ड, बूटलोडर और कर्नेल संस्करणों को रिकॉर्ड किया।
adb devices -l
adb shell getprop ro.product.device
adb shell getprop ro.product.model
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.incremental
adb shell getprop ro.build.fingerprint
adb shell getprop ro.bootloader
adb shell uname -a
adb shell id
परिणामी बेसलाइन sheldonp / AFTSSS, Fire OS PS7716.5666N, इंक्रीमेंटल 0036005356164, Android 9, और कर्नेल 4.4.162+ थी। सीरियल नंबर जानबूझकर छोड़ा गया है।
मैंने ADB डिबगिंग सक्षम करके Fire TV को USB से कनेक्ट किया और GhostLock 1.1.0 का उपयोग किया, जो R0rt1z2 XDA गाइड के साथ प्रकाशित sheldon/sheldonp पैकेज है। डिवाइस-विशिष्ट लॉन्चर Fire TV को ताज़ा स्थिति से शुरू करने के लिए रीबूट करता है, एक्सप्लॉइट तैनात करता है, और आवश्यकता पड़ने पर पुनः प्रयास करता है।
सफल शोषण एक अस्थायी रूट वातावरण बनाता है। मैंने केवल स्क्रिप्ट पूर्ण होने को प्रमाण नहीं माना, बल्कि ADB शेल से सुरक्षा कॉन्टेक्स्ट सत्यापित किया:
adb shell
su
id
रूट कॉन्टेक्स्ट अल्पकालिक (ephemeral) है और रीबूट पर खो जाता है। यह व्यवहार महत्वपूर्ण है: यह चरण डाउनग्रेड के लिए एक सक्षम करने वाला प्रिमिटिव (enabling primitive) है, न कि अंतिम पर्सिस्टेंस मैकेनिज़्म या स्वयं बूटलोडर अनलॉक।
सफल रन ने uid=0 दिखाया, अस्थायी वातावरण के लिए SELinux को permissive में बदला, अस्थायी su को माउंट किया, और टूल द्वारा संभाले जाने वाले Fire OS OTA पैकेजों को अक्षम किया।
पूरा GhostLock एक्सप्लॉइट ट्रेस सहायक साक्ष्य के रूप में सुरक्षित रखा गया है।
अस्थायी रूट उपलब्ध होने पर, मैंने फर्मवेयर पार्टीशनों को मैन्युअल रूप से लिखने के बजाय पैकेज के समर्पित डाउनग्रेड वर्कफ़्लो का उपयोग किया। इसने मौजूदा Kamakiri पथ के साथ संगत प्रीलोडर को पुनर्स्थापित किया।
डाउनग्रेड के बाद, Fire TV ने जानबूझकर Fire OS में बूट होना बंद कर दिया। इस विशिष्ट वर्कफ़्लो में, वह नॉन-बूटिंग स्थिति लाइव-कर्नेल चरण और USB BootROM चरण के बीच अपेक्षित हैंडऑफ़ है। इसे इस बात के प्रमाण के रूप में नहीं समझा जाना चाहिए कि कोई भी मनमाना विफल फ़्लैश पुनर्प्राप्त करने योग्य है।