Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
mt6985-CVE-2026-43499 — MT6985 MediaTek Dimensity 9300 (vivo PD2241) के लिए CVE-2026-43499 exploit अडैप्टर | Kitploit
उपकरण/GitHubGitHub/233laoliu/mt6985-cve-2026-43499
शोषण फ्रेमवर्कभेद्यता विश्लेषणशोषणरिवर्स इंजीनियरिंगफोरेंसिकमोबाइल सुरक्षाफर्मवेयर विश्लेषणबाइनरी शोषण
GitHub233laoliu/mt6985-cve-2026-43499

mt6985-CVE-2026-43499

MT6985 MediaTek Dimensity 9300 (vivo PD2241) के लिए CVE-2026-43499 exploit अडैप्टर

रिपॉजिटरी देखें
1131 महीना पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

CVE-2026-43499 विफलता रिकॉर्ड: MT6985 अनुकूलन प्रयास

निष्कर्ष: 68M टोकन खर्च किए, root नहीं मिला।
कारण: MTK Dimensity 9200 पर KernelSnitch टाइमिंग अटैक अविश्वसनीय है, CONFIG_PANIC_ON_OOPS=y परीक्षण-और-त्रुटि के लिए जगह नहीं देता।
यह लेख पूरी गलती-सीखने की प्रक्रिया दर्ज करता है, ताकि भविष्य के लोग इन गड्ढों से बच सकें।

पृष्ठभूमि

परियोजनामान
डिवाइसvivo PD2241 (Dimensity 9200 / MT6985), Android 15
फर्मवेयरPD2241_A_15.2.10.2.W10.V000L1
कर्नेल5.15.178-android13-8-gfb31f5bdd612-dirty
बूटलोडरलॉक (ro.boot.flash.locked=1)
SELinuxEnforcing
panic_on_oopsचालू → कोई भी कर्नेल OOPS = तुरंत रिबूट
एक्सप्लॉइटCyberMeowfia — CVE-2026-43499 (IonStack)
सोर्स ट्रीandroid_15.0_kernel_MT6985 (5.15.178) — डिवाइस संस्करण से मेल नहीं खाता (सोर्स android15 GKI है, डिवाइस android13 GKI चलाता है)

क्या किया गया

1. सोर्स विश्लेषण → स्ट्रक्चर ऑफसेट निकालना

arch/arm64/include/asm/memory.h + include/linux/fs.h + android/abi_gki_aarch64.xml से निकाला गया:

  • मेमोरी लेआउट: KIMAGE_TEXT_BASE = 0xffffffc008000000, VA_BITS=39, DIRECT_MAP=256GB
  • task_struct: 36864 बिट्स, पूरी तरह पार्स किया गया (ABI XML layout-offset-in-bits)
  • file_operations: कोई iopoll नहीं (android13 GKI), IOCTL=0x48, open=0x68
  • cred: atomic_t usage = 4 बाइट, uid=0x04
  • struct page: 64 बाइट, slab_cache=0x18

मुख्य खोज: सोर्स android15 GKI है, डिवाइस android13 GKI है — task_struct ऑफसेट 0x40~0x88 बाइट तक भिन्न हैं, सोर्स को सीधे कॉपी नहीं किया जा सकता।

2. फर्मवेयर अनपैक → सिंबल निकालना

root@kitploit:~
OTA zip (8.3GB)
  → payload.bin (8.2GB)
    → payload_dumper → boot.img (96MB, v4 header)
      → LZ4 डीकंप्रेस → Image (50MB ARM64)
        → kallsyms-finder → 187810 सिंबल

दो फर्मवेयर संस्करणों (15.2.7.6 / 15.2.10.2) से सिंबल निकाले गए — एक ही सिंबल दो संस्करणों के बीच 10KB~200KB तक भिन्न है, सही संस्करण का उपयोग करना अनिवार्य है।

3. डिसअसेंबली सत्यापन → capstone से मुख्य ऑफसेट की पुष्टि

root@kitploit:~
# rt_mutex_adjust_pi में:
LDR x21, [x19, #0x8b0]  → pi_blocked_on = 0x8b0 (android15 मान, frankel नहीं)

इससे पुष्टि हुई कि task_struct लेआउट android15 शाखा का है, frankel के android13 का नहीं।

4. कंपाइलेशन → सफल

NDK r29, make PROJECT=android_15.0_kernel_MT6985 → preload.so (150KB)।

5. रन → बार-बार क्रैश

root@kitploit:~
[+] preload starting pid=25414
[+] p0 profile ... सभी सिंबल सही ढंग से लोड हुए
[-] KernelSnitch mm_struct leak failed     ← कभी-कभी यह लाइन नहीं आती (कभी-कभी सफल)
[+] slide child context route=pselect      ← slide KASLR leak चाइल्ड प्रोसेस शुरू
[कर्नेल panic]                                ← rt_mutex_adjust_prio_chain+0x1b0

क्रैश इंस्ट्रक्शन (capstone):

root@kitploit:~
ldar w8, [x27]    ; x27 = waiter->lock ([x28, #0x38] से लोड किया गया)
                  ; x27 मान कचरा है → पेज टेबल में कोई मैपिंग नहीं → translation fault
                  ; → die() → panic → रिबूट

विफलता के कारण

मूल कारण 1: MTK पर KernelSnitch अविश्वसनीय है

KernelSnitch पूरे एक्सप्लॉइट का प्रवेश द्वार है — यह futex हैश बकेट के टाइमिंग अंतर के माध्यम से mm_struct पता लीक करता है:

  1. कोलिजन डिटेक्शन सफल — कम थ्रेशोल्ड पर 5 कोलिजन मिले
  2. bruteforce मैचिंग लगभग हमेशा विफल — मुख्य समस्या यहाँ है:
root@kitploit:~
MT6985 में CONFIG_KASAN_HW_TAGS=y है → कर्नेल slab आवंटन को MTE टैग से चिह्नित करता है
mm_struct का पॉइंटर KASAN टैग के साथ है → futex_hash tagged pointer पर आधारित गणना करता है

लेकिन bruteforce direct map (untagged पता) स्कैन करता है → गणना किया गया hash मेल नहीं खाता
भले ही MTE टैग ट्रैवर्सल जोड़ा जाए (0-14 कुल 15 प्रकार), VA_BITS=39 वाले सिस्टम पर
टैग बिट्स (bit56-59) साइन-एक्सटेंशन बिट्स से ओवरलैप होते हैं → कुछ टैग संयोजन अमान्य पता बनाते हैं → मिस डिटेक्शन

Pixel डिवाइस में KASAN_HW_TAGS नहीं है, यह तंत्र वहाँ काम करता है। MTK पर नहीं।

मूल कारण 2: CONFIG_PANIC_ON_OOPS घातक है

root@kitploit:~
Pixel:  कर्नेल OOPS → dump_stack → चलता रहता है → एक्सप्लॉइट पुनः प्रयास कर सकता है
MT6985: कर्नेल OOPS → die() → panic() → तुरंत रिबूट → परीक्षण-और-त्रुटि की कोई गुंजाइश नहीं
π चेन में थोड़ी सी भी गड़बड़ी पूरी तरह क्रैश कर देती है, Pixel पर गड़बड़ी का मतलब सिर्फ "इस बार सफल नहीं, दूसरे पते के सेट से फिर कोशिश करो" होता है।

और बूटलोडर लॉक है (flash.locked=1) → इस विकल्प को हटाने के लिए कस्टम कर्नेल फ्लैश नहीं किया जा सकता।

मूल कारण 3: कर्नेल संस्करण विचलन

root@kitploit:~
सोर्स ट्री: 5.15.178 android15 GKI
डिवाइस:   5.15.178-android13 (vivo vendor)

हालाँकि मुख्य संस्करण संख्या दोनों 5.15.178 है, GKI शाखा अलग है (android13 बनाम android15), task_struct/cred जैसे महत्वपूर्ण स्ट्रक्चर का लेआउट असंगत है। frankel/android15 दोनों ऑफसेट सेट के बीच बार-बार स्विच करने के बाद, अंततः डिसअसेंबली से ही सही ऑफसेट लॉक हुआ।

किए गए समायोजन (सभी बेकार)

बदलावउद्देश्यपरिणाम
THRESHOLD_MULT 10→5→3कोलिजन डिटेक्शन थ्रेशोल्ड कम करना<5 पर बहुत अधिक फॉल्स पॉज़िटिव
APPENDED_FUTEXES 4096→8192हैश चेन अंतर बढ़ानाकोई प्रभाव नहीं
REPEAT_MEASUREMENT/AVERAGEसैंपलिंग सटीकता बढ़ानाकोई प्रभाव नहीं
MTE=1bruteforce को टैग ट्रैवर्स करने देनाधीमा, क्रैश कम हुए
MM_STRUCT_SZ 0x500→0x400mm_struct स्टेप साइज़ सुधारनाआवश्यक, ABI वास्तव में 992 बाइट
IDENTITY_END 64GB→256GBस्कैन रेंज बढ़ानाबहुत धीमा (MTE ट्रैवर्सल), फिर भी मेल नहीं खाता
TASK ऑफसेट: android15↔frankelसही ऑफसेट लॉक करनाडिसअसेंबली से android15 की पुष्टि
FOPS ऑफसेट: android15↔frankelandroid13 में iopoll नहीं हैfrankel का उपयोग किया

target.h की वर्तमान स्थिति

exploit/targets/android_15.0_kernel_MT6985/target.h में:

श्रेणीविश्वसनीयतासत्यापन विधि
मेमोरी लेआउटसहीmemory.h गणना + kallsyms _text सत्यापन
सिंबल ऑफसेट (22)सही15.2.10.2 boot.img से निकाले गए
task_struct ऑफसेटसहीABI XML + capstone डिसअसेंबली (pi_blocked_on=0x8b0)
FOPS ऑफसेटगलत (2026-07-31 को सुधारा गया)मूल मान frankel से कॉपी किए गए (android13 में iopoll नहीं); सोर्स ट्री ABI में वास्तव में iopoll@0x30, ioctl=0x50, open=0x70 है — देखें VERIFICATION.md
CRED ऑफसेटसही (सत्यापित)ABI XML: uid=0x04, securebits=0x24, caps=0x28, security=0x78

असेंबली पास हो जाती है, चल जाता है, बस आखिरी मील में हार गए।

यदि आप जारी रखना चाहते हैं

आवश्यक शर्तें (सभी अनिवार्य)

  1. CONFIG_PANIC_ON_OOPS हटाएँ — या तो कस्टम कर्नेल फ्लैश करें (बूटलोडर अनलॉक चाहिए), या ऐसा MT6985 डिवाइस खोजें जिसमें यह विकल्प डिफ़ॉल्ट रूप से बंद हो
  2. KernelSnitch को हल करें — MTK Dimensity 9200 के लिए कैश टाइमिंग कैलिब्रेशन चाहिए, या एक्सप्लॉइट में KernelSnitch को पूरी तरह बदलकर mm_struct लीक करने का दूसरा तरीका अपनाएँ

संभावित वैकल्पिक दृष्टिकोण

  • /proc/self/pagemap — इस डिवाइस पर प्रतिबंधित है (सभी शून्य लौटाता है)
  • MTK-विशिष्ट डिबग इंटरफेस (/proc/mtk_*) — मौजूद हैं लेकिन आगे विश्लेषण की आवश्यकता है
  • MTK कैमरा/GPU ड्राइवर ioctl कमजोरियाँ — विशेषाधिकार वृद्धि का आसान रास्ता
  • समुदाय द्वारा MTK वेरिएंट अनुकूलन की प्रतीक्षा करें

इस रिपॉजिटरी का शेष मूल्य

  • symbols/kallsyms_PD2241_15.2.10.2.txt — पूर्ण 15.2.10.2 सिंबल टेबल, भविष्य के लोग सीधे उपयोग कर सकते हैं
  • device_config.txt — डिवाइस का वास्तविक कर्नेल कॉन्फ़िगरेशन, देख सकते हैं कि vendor ने क्या बदला
  • exploit/targets/android_15.0_kernel_MT6985/target.h — स्ट्रक्चर ऑफसेट सत्यापित हैं
  • scripts/server_compile.py — स्वचालित कंपाइलेशन, पैरामीटर बदलकर जल्दी रीकंपाइल कर सकते हैं

गड्ढों की सूची (भविष्य के लोगों के लिए बचाव हेतु)

  1. Windows पर फ़ाइल अनज़िप करना: बड़े zip के लिए tar -xf विफल हो सकता है, Python zipfile का उपयोग करें या पहले मैन्युअल रूप से अनज़िप करें
  2. payload_dumper का protobuf संस्करण विरोध: उत्पन्न update_metadata_pb2.py को protobuf 5.x चाहिए, runtime_version इम्पोर्ट लाइन को मैन्युअल रूप से हटाना होगा
  3. सीधे ./preload.so चलाने पर segfault: /system/bin/linker64 /data/local/tmp/preload.so का उपयोग करना अनिवार्य है
  4. ABI XML सोर्स से अधिक सटीक है: layout-offset-in-bits कंपाइलर द्वारा गणना किया गया है, 5000 बाइट मैन्युअल गिनने से 100 गुना अधिक सटीक
  5. GKI शाखा लेआउट को प्रभावित करती है: android13/14/15 के task_struct अलग हैं, शाखाओं के बीच ऑफसेट कॉपी नहीं किए जा सकते
  6. फर्मवेयर संस्करण अलग होने पर सिंबल ऑफसेट अलग होते हैं: 15.2.7.6 और 15.2.10.2 में 10KB~200KB का अंतर
  7. vivo vendor ने बहुत सारे OEM फ़ील्ड जोड़े हैं: CONFIG_ANDROID_VENDOR_OEM_DATA=y, CONFIG_SCHED_INFO=y, CONFIG_RSC_* → मानक GKI से विचलन
  8. फ्रंट-एंड/बैक-एंड सिंबल निष्कर्षण टूलचेन: boot.img → kernel.bin → LZ4 डीकंप्रेस → Image → kallsyms-finder → सिंबल टेबल

समयरेखा

root@kitploit:~
07/28  CyberMeowfia रिपॉजिटरी + MT6985 सोर्स डाउनलोड
07/29  सोर्स विश्लेषण (memory.h, fs.h, ABI XML, विभिन्न struct)
       फर्मवेयर अनपैक (payload.bin → boot.img → Image)
       सिंबल निष्कर्षण (kallsyms-finder → 187810 सिंबल)
       कई राउंड कंपाइलेशन + कई राउंड क्रैश + डिसअसेंबली सत्यापन
       5 बार स्वचालित पुनः प्रयास → सभी विफल
       यह लेख लिखा गया
-------------------------------------------
कुल: ~68M टोकन, 0 root शेल

2026-07-29, कहानी सुनाने के लिए जीवित बचे

2026-07-31 परिशिष्ट: सोर्स मिलने के बाद सत्यापन और सुधार

android_15.0_kernel_MT6985.tar.gz (5.15.178 सोर्स ट्री + ABI XML) मिलने के बाद पूर्ण क्रॉस-सत्यापन किया गया, विवरण के लिए देखें VERIFICATION.md। सारांश:

  1. MT6985 = Dimensity 9200 (MT6989 ही 9300 है), ऊपर सुधारा गया।
  2. सिंबल ऑफसेट 23/23 सही (kallsyms सत्यापन), task_struct / cred / waiter / page / pipe / configfs ऑफसेट सभी सोर्स ट्री ABI से मेल खाते हैं।
  3. FOPS ऑफसेट गलत थे: मूल मान frankel से कॉपी किए गए (android13 GKI, कोई iopoll नहीं, ioctl=0x48); लेकिन डिवाइस का task_struct लेआउट (pi_blocked_on=0x8b0, रनटाइम डिसअसेंबली से पुष्टि) इस सोर्स ट्री से मेल खाता है, उसी कर्नेल के file_operations में iopoll@0x30, ioctl=0x50, open=0x70 आदि होने चाहिए — target.h सुधारा गया, और एक्सप्लॉइट के साथ आने वाले leak_kernel_base() से वास्तविक डिवाइस पर स्व-सत्यापन बैकअप के रूप में उपयोग किया गया।
  4. KernelSnitch का MTK संगतता पैच (patches/kernelsnitch_mtk_fixes.patch):
    • यूज़र-स्पेस futex हैश टेबल का आकार कर्नेल के अनुरूप किया गया (possible CPU + 2 की पावर), जिससे possible≠online होने पर bruteforce की अनिवार्य विफलता टली;
    • MTE टैग ट्रैवर्सल में 0xf (untagged) जोड़ा गया, और KSNITCH_MTE_ENABLED=1 को वास्तव में प्रभावी बनाया गया (मूल util.c में mte=0 हार्डकोड था);
    • गैर-MTK target पर कोई प्रभाव नहीं।
  5. क्रैश बिंदु rt_mutex_adjust_prio_chain+0x1b0 pselect/pi चेन चरण में है, FOPS स्व-सत्यापन से पहले; उपरोक्त सुधारों के बाद पुनः वास्तविक डिवाइस पर परीक्षण उचित है।

2026-07-31 वास्तविक डिवाइस परीक्षण: KernelSnitch पास, slide चरण अभी भी बाधा

डिवाइस (PD2241, compiler251203103903) पर 8+ राउंड वास्तविक परीक्षण:

  • KernelSnitch ठीक हो गया और सत्यापित: MM_STRUCT_SZ=0x400 (मूल 0x500 के कारण स्कैन ग्रिड गलत था, केवल फॉल्स पॉज़िटिव आते थे) + MTE टैग 0..15 ट्रैवर्सल (डिवाइस के mm पॉइंटर टैग बदलते हैं) + नकली पते का untag। अब वास्तविक mm_struct स्थिर रूप से मिल जाता है।
  • हर राउंड फिर भी rt_mutex_adjust_prio_chain+0x1b0 पर क्रैश: pselect/pi चेन टाइमिंग रेस (नकली waiter कर्नेल स्टैक के सही ऑफसेट पर नहीं पहुँच पाता)। vivo RSC शेड्यूलर ने futex/pi पथ बदल दिया है, संभवतः इस रेस को मूल रूप से तोड़ दिया है। slide स्टैक अलाइनमेंट को SLIDE_SHIFT एनवायरनमेंट वेरिएबल के रूप में पैरामीटराइज़ किया गया है, स्कैन पूरा नहीं हुआ।
  • FOPS/pipe/cred चरण अभी तक नहीं पहुँचे, वास्तविक डिवाइस सत्यापन जारी है।

अंतिम विकल्प: भुगतान करके बूटलोडर अनलॉक करवाना (अब इस पथ पर निर्भर नहीं)।

टूल डाउनलोड करें