Amazon Fire TV Stick 3rd Gen (sheldonp) पर CVE-2026-43499

एक Linux kernel privilege escalation को preloader downgrade और bootloader unlock में जोड़ना।

अवलोकन

यह repository एक Amazon Fire TV Stick 3rd Gen (sheldonp) पर CVE-2026-43499 exploitation chain के मेरे authorized reproduction का दस्तावेज़ीकरण करता है। इस chain ने एक controlled preloader downgrade चलाने के लिए temporary kernel root का उपयोग किया, फिर unlocked fastboot तक पहुँचने और bootloader unlock पूरा करने के लिए मौजूदा Kamakiri BootROM workflow का उपयोग किया।

यह एक reproduction और device-specific case study है। मैंने CVE-2026-43499 की खोज नहीं की, मूल IonStack/GhostLock exploit नहीं बनाया, या Kamakiri विकसित नहीं किया। upstream researchers और developers को नीचे श्रेय दिया गया है।

[!IMPORTANT] यह write-up एक तकनीकी रिकॉर्ड है, कोई सार्वभौमिक rooting guide नहीं। Build compatibility मायने रखती है, temporary root persistent root नहीं है, और Preloader, LK, TEE, या dm-verity-protected partitions से जुड़ी गलतियाँ device को स्थायी रूप से brick कर सकती हैं।

Reproduction record

End-to-end chain 12 सितंबर, 2026 को पूरी हुई। यह repository परीक्षण किए गए device और software versions, उपयोग किए गए सटीक archives, उनके SHA-256 hashes, और प्रक्रिया के दौरान कैप्चर किए गए मूल साक्ष्य को रिकॉर्ड करता है।

दायरा

दायरे से बाहर: vulnerability discovery, एक नया exploit implementation, remote exploitation, persistent root, या परीक्षण किए गए sheldonp unit के अलावा अन्य devices के लिए समर्थन। इस reproduction के दौरान कोई custom ROM install नहीं किया गया।

Reproduction archives

निम्नलिखित इस reproduction के दौरान उपयोग किए गए सटीक ZIP archives हैं। Archives इस repository में पुनर्वितरित नहीं किए गए हैं; उनके SHA-256 hashes रिकॉर्ड किए गए हैं ताकि स्वतंत्र रूप से प्राप्त copies की तुलना इस case study में उपयोग की गई files से की जा सके।

ये hashes इस case study में उपयोग की गई copies की पहचान करते हैं; पाठकों को अभी भी अपने downloads की तुलना मूल upstream sources से करनी चाहिए और लागू third-party licenses की समीक्षा करनी चाहिए।

तकनीकी पृष्ठभूमि

CVE-2026-43499, जिसे GhostLock के नाम से भी जाना जाता है, Linux kernel के priority-inheritance futex/rtmutex path में एक use-after-free है। Proxy-lock rollback के दौरान, remove_waiter() ने waiter->task में संग्रहीत task के बजाय current पर कार्य किया। परिणामस्वरूप, वास्तविक waiter userspace में लौट सकता था जबकि pi_blocked_on अभी भी एक released kernel stack frame में एक rt_mutex_waiter को संदर्भित कर रहा था।

मूल IonStack research उस dangling stack reference को एक local privilege-escalation primitive में बदल देती है। R0rt1z2 ने इस तकनीक को Fire TV Stick 3rd Gen और Fire TV Stick Lite (sheldonp/sheldon) पर adapt किया जो 4.4 kernel पर Fire OS 7 चला रहे थे।

इस case study में मुख्य अंतर यह है कि CVE-2026-43499 bootloader को सीधे unlock नहीं करता। यह temporary kernel-level access प्रदान करता है। वह अल्पकालिक access controlled preloader downgrade करना संभव बनाता है जो पुरानी Kamakiri BootROM chain चलने से पहले आवश्यक है।

Exploit chain

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]

यह chain दो अलग security boundaries को पार करती है:

1. Kernel boundary: एक unprivileged local process GhostLock के माध्यम से एक temporary root context प्राप्त करता है।
2. Boot-chain boundary: temporary root एक compatible preloader को पुनर्स्थापित करके device को एक ज्ञात BootROM-based unlock path के लिए तैयार करता है।

कार्यप्रणाली

1. Baseline स्थापित करें

Device बदलने से पहले, मैंने hardware codename की पहचान की और ADB के माध्यम से Fire OS, build, bootloader, और kernel versions रिकॉर्ड किए।

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

परिणामी baseline था sheldonp / AFTSSS, Fire OS PS7716.5666N, incremental 0036005356164, Android 9, और kernel 4.4.162+। Serial number जानबूझकर छोड़ा गया है।

2. GhostLock के साथ temporary root प्राप्त करें

मैंने ADB debugging सक्षम करके Fire TV को USB के माध्यम से जोड़ा और GhostLock 1.1.0 का उपयोग किया, जो R0rt1z2 XDA guide के साथ प्रकाशित sheldon/sheldonp package है। Device-specific launcher Fire TV को ताज़ा स्थिति से शुरू करने के लिए reboot करता है, exploit deploy करता है, और आवश्यक होने पर पुनः प्रयास करता है।

सफल exploitation एक temporary root environment बनाता है। मैंने केवल script completion को प्रमाण मानने के बजाय ADB shell से security context सत्यापित किया:

adb shell
su
id

Root context अल्पकालिक है और reboot पर खो जाता है। यह व्यवहार महत्वपूर्ण है: यह चरण downgrade के लिए एक enabling primitive है, न कि अंतिम persistence mechanism या स्वयं bootloader unlock।

सफल run ने uid=0 दिखाया, temporary environment के लिए SELinux को permissive में बदला, temporary su mount किया, और tool द्वारा संभाले जाने वाले Fire OS OTA packages को अक्षम किया।

पूरा GhostLock exploit trace supporting evidence के रूप में रखा गया है।

3. Preloader को downgrade करें

Temporary root उपलब्ध होने पर, मैंने firmware partitions को मैन्युअल रूप से लिखने के बजाय package के समर्पित downgrade workflow का उपयोग किया। इसने मौजूदा Kamakiri path के साथ संगत एक preloader को पुनर्स्थापित किया।

Downgrade के बाद, Fire TV ने जानबूझकर Fire OS में boot करना बंद कर दिया। इस विशिष्ट workflow में, वह non-booting state live-kernel stage और USB BootROM stage के बीच अपेक्षित handoff है। इसे इस प्रमाण के साथ भ्रमित नहीं किया जाना चाहिए कि कोई मनमाना failed flash recoverable है।

[!CAUTION] Preloader को कभी erase न करें। LK, TEE, Preloader, boot, recovery, system, vendor, या अन्य protected partitions में सुधार-रहित writes न करें। Upstream guides चेतावनी देते हैं कि critical firmware को नुकसान स्थायी hard brick का कारण बन सकता है क्योंकि एक कार्यशील recovery path उपलब्ध नहीं रह सकता।

4. Kamakiri BootROM chain चलाएँ

इस device के लिए उपयोग किया गया Kamakiri workflow Linux के लिए समर्थित और प्रलेखित था। इसलिए मैंने एक Ubuntu Live session boot किया और वहाँ पूरा unlock workflow किया, जिसमें low-level USB BootROM stage भी शामिल था, बिना host पर Ubuntu install किए। मैंने इस stage का Windows या macOS पर परीक्षण नहीं किया।

Unlock guide द्वारा संदर्भित sheldon/sheldonp Kamakiri package का उपयोग करते हुए, प्रक्रिया थी:

1. Kamakiri द्वारा आवश्यक Python, PySerial, PyUSB, ADB, Fastboot, और USB environment तैयार करें।
2. bootrom-step.sh शुरू करें और powered-off Fire TV को USB के माध्यम से जोड़ें।
3. BootROM stage को पूरा होने दें और device को संशोधित fastboot environment में transition करने दें।
4. Unlock workflow पूरा करने के लिए fastboot-step.sh चलाएँ।
5. Reboot करें और सत्यापित करें कि अपेक्षित unlocked boot path उपलब्ध था।

Kamakiri ने unit को sheldonp के रूप में पहचाना, RPMB downgrade पूरा किया, chain के आवश्यक TZ/LK components flash किए, microloader inject किया, और device को उसके hacked fastboot mode में मजबूर किया।

Archive hashes और Ubuntu release ऊपर रिकॉर्ड किए गए हैं। पाठकों को version-specific निर्देशों के लिए linked upstream guides का उपयोग करना चाहिए, बजाय यह मानने के कि ये high-level steps किसी अन्य build पर लागू होते हैं।

5. परिणाम सत्यापित करें

मैंने निम्नलिखित को अलग milestones माना और प्रत्येक के लिए साक्ष्य कैप्चर किया:

6. Fire OS को संरक्षित करें और post-unlock state समायोजित करें

मेरा लक्ष्य तुरंत custom ROM install करने के बजाय stock Fire OS बनाए रखना था। TWRP में मैंने data wipe करने या operating system को बदलने से बचा, फिर मौजूदा Fire OS installation में reboot किया। TWRP और unlocked boot path उपलब्ध रहे जबकि stock user environment संरक्षित रहा।

Fire OS में लौटने के बाद, मैंने OTA updates अक्षम रखे ताकि Amazon चुपचाप device को ऐसी build पर न ले जाए जो exploit को बदल दे या recovered boot chain को संशोधित कर दे। मैंने Amazon system app-protection component को भी अक्षम किया जिसे Fire TV community tooling में आमतौर पर ARCUS कहा जाता है। यह Amazon के OS-level app-blocking व्यवहार को बदलता है; यह Widevine, subscription checks, या व्यक्तिगत applications के भीतर लागू license enforcement को bypass नहीं करता।

वैकल्पिक अगले कदम

एक unlocked bootloader और TWRP संगत custom software install करना भी संभव बनाते हैं। इस device family के लिए एक community विकल्प है Android 13 पर आधारित LineageOS 20। अन्य संगत ROMs, recovery workflows, या persistent-root configurations भी संभव हो सकते हैं।

वे विकल्प इस reproduction का हिस्सा नहीं थे। उन्हें अपने स्वयं के firmware, TZ, data-wipe, DRM, memory, और recovery विचारों के साथ अलग प्रक्रियाओं के रूप में माना जाना चाहिए।

अवलोकन

• एक wired USB ADB connection बेहतर है क्योंकि exploit retries target को reboot कर सकते हैं और wireless ADB को बाधित कर सकते हैं।
• Exploit reliability target- और build-dependent है। एक retry या reboot इस बात का प्रमाण नहीं है कि कोई device असमर्थित है, लेकिन offsets और build compatibility अभी भी सत्यापित किए जाने चाहिए।
• Temporary-root stage और Kamakiri stage अलग-अलग समस्याओं को हल करते हैं और उन्हें स्वतंत्र रूप से प्रलेखित किया जाना चाहिए।
• अपेक्षित post-downgrade non-booting state केवल तभी सार्थक है जब downgrade tool सफलता की रिपोर्ट करता है और सटीक समर्थित workflow का पालन किया जा रहा है।
• एक सफल script exit, कैप्चर किए गए device state, root identity, और fastboot/recovery verification की तुलना में कमजोर साक्ष्य है।
• Bootloader unlock करने के लिए Fire OS को बदलने की आवश्यकता नहीं थी; stock Fire OS बनाए रखना एक जानबूझकर किया गया post-unlock विकल्प था।
• ARCUS को अक्षम करना Amazon की app-blocking layer को प्रभावित करता है, जबकि application DRM और content licenses अलग मामले बने रहते हैं।

सुरक्षा प्रभाव

एक vulnerable और समर्थित Fire OS build पर, device पर पहले से चल रहा code temporary root context प्राप्त करने के लिए kernel flaw का exploit कर सकता है। इस lab में, उस access ने चल रहे operating system से परे attack surface का विस्तार किया: इसने एक firmware downgrade सक्षम किया जिसने एक boot-chain condition को फिर से पेश किया जो पुराने BootROM exploit द्वारा उपयोग किया जा सकता था।

यह chain दर्शाती है कि device security केवल एक layer को patch करने से अधिक पर निर्भर क्यों करती है। एक kernel privilege escalation निम्न-स्तरीय persistence या boot-chain compromise का पुल बन सकता है जब privileged software security-critical firmware state को संशोधित कर सकता है।

Repository संरचना

.
├── README.md              # Case study and methodology
├── LICENSE                # CC BY 4.0 for original documentation and media
├── images/
│   ├── README.md          # Evidence index and redaction guidance
│   └── evidence/          # Sanitized screenshots and photographs
└── references/
    └── README.md          # Source ledger and artifact guidance

यह repository third-party ZIP archives को पुनर्वितरित नहीं करता। उन्हें मूल XDA guides से प्राप्त करें, उनकी लागू शर्तों की समीक्षा करें, और उनके hashes की तुलना ऊपर रिकॉर्ड किए गए मानों से करें।

श्रेय

• NebuSec / CyberMeowfia — CVE-2026-43499 के लिए discovery और मूल IonStack/GhostLock research और exploit implementation।
• R0rt1z2 — Fire OS adaptation, 4.4 GhostLock branch, और sheldon/sheldonp temporary-root और downgrade guide।
• IonStackQuest3 — Linux 5.10 kernels के लिए पहला सार्वजनिक GhostLock port, जिसे downstream Fire OS project द्वारा श्रेय दिया गया।
• Amonet/Kamakiri contributors, जिनमें xyz, k4y0z, Rortiz2, t0x1cSH, और मूल unlock thread में श्रेय दिए गए testers शामिल हैं — BootROM, fastboot, recovery, और device-specific unlock कार्य।

मेरा योगदान स्वतंत्र reproduction, device-specific execution record, stages कैसे जुड़ते हैं इसका विश्लेषण, और इस repository में प्रकाशित मूल साक्ष्य है।

संदर्भ

अनुरक्षित source ledger references/README.md में है। प्राथमिक स्रोतों में शामिल हैं:

• CVE-2026-43499 record
• NebuSec: GhostLock vulnerability entry
• NebuSec: IonStack Part III — Android exploitation
• CyberMeowfia: IonStack/CVE-2026-43499 source
• R0rt1z2/GhostLock, 4.4 branch
• XDA: temporary root and preloader downgrade for sheldon/sheldonp
• Amonet/Kamakiri source
• XDA: bootloader unlock, TWRP, and unbrick guide for sheldon/sheldonp
• Linux kernel fix for remove_waiter()

जिम्मेदार-उपयोग सूचना

यह सामग्री शैक्षिक उपयोग और उस hardware पर authorized security research के लिए प्रदान की गई है जिसका आप स्वामी हैं या जिसका परीक्षण करने की आपको स्पष्ट रूप से अनुमति है। यह बिना किसी वारंटी के आती है। कानूनी अनुपालन, डेटा हानि, सेवा व्यवधान, और आपके कार्यों से होने वाली hardware क्षति के लिए आप जिम्मेदार हैं।

लाइसेंस

इस repository के लिए लिखे गए मूल पाठ और चित्र Creative Commons Attribution 4.0 International License के अंतर्गत लाइसेंस प्राप्त हैं।

Third-party tools, exploit code, firmware, quotations, screenshots, trademarks, और संदर्भित सामग्री अपने संबंधित authorship और licenses के अधीन बनी रहती हैं। किसी link या credit का समावेश उस सामग्री को CC BY 4.0 के अंतर्गत पुनःलाइसेंस नहीं करता।