KSuRoot

⚠️ सुझाव: ब्लू-ब्रांड मॉडल्स की शेड्यूलिंग नीति काफ़ी सख़्त होती है, प्रिविलेज एस्केलेशन के दौरान चाइल्ड प्रोसेस को सिस्टम द्वारा आसानी से रिक्लेम कर लिया जाता है। कृपया पहले "डेवलपर विकल्प" में "चाइल्ड प्रोसेस को रोकना बंद करें" सक्षम करें, फिर प्रिविलेज एस्केलेशन करें — सफलता दर अधिक होगी।

CVE-2026-43499 (GhostLock) कर्नेल वल्नरेबिलिटी पर आधारित वन-क्लिक KernelSU प्रिविलेज एस्केलेशन टूल।

यह ब्रांच KSuRoot को आधार बनाकर Root-My-Galaxy v0.2.6 मुख्यलाइन अपडेट के साथ पूरी तरह सिंक है, और इसके ऊपर पेलोड निर्माण, विक्रेता पेलोड अंतर्निहित तथा एक पूरा लिक्विड ग्लास UI जोड़ा गया है।

Mod by hmascs · संस्करण 4.1.2 · Apache-2.0 रिपॉज़िटरी: https://github.com/hmascs/KSuRoot

---

4.1.2 में क्या बदला

इस राउंड (4.1.2) में नया: इमेज से vr.ko का मार्कर ऑफ़सेट पढ़ना

vr.ko ऐप से आने वाले task पर मार्कर लगाता है, उस ऑफ़सेट के 0x04 / 0x06 दो रूप हैं, और यह कंपाइल-टाइम पर पेलोड में बेक होता है, patch नहीं किया जा सकता। और भी मुश्किल बात यह है कि एक ही डिवाइस की दो vr.ko फ़ाइलों में अलग-अलग रूप होते हैं (Y300 Pro+ के vendor_boot में दो हैं, srcversion बिल्कुल समान) — गलत चुनने पर नतीजा यह होता है कि "गलत बाइट साफ़ हो गई, मार्कर नहीं मिटा, चाइल्ड प्रोसेस फिर भी मार दिया गया", जबकि लॉग में सब सामान्य दिखता है।

अब ब्लू-ब्रांड समाधान आपसे एक vendor_boot.img मांगेगा: ऐप उसमें से वास्तव में लोड होने वाले lib/modules/vr.ko से इस मशीन का असली ऑफ़सेट पढ़ेगा, फिर पेलोड को फिर से लिखेगा। चारों सह-आपूर्त/स्व-निर्मित लाइब्रेरी (libbaseline_6_1 / libbaseline_6_12 / libbs / libionstack) अपने-अपने स्लॉट के लिए बाध्य हैं, गलत चुनने पर ज़ीरो-हिट गेट द्वारा तुरंत रोक दिया जाएगा, बजाय आपको ज्यों-का-त्यों कॉपी किया गया उत्पाद देने के।

इसके अलावा नया "पूरा फ़्लैश पैकेज आयात करें": सीधे अपना डाउनलोड किया हुआ OTA zip या fastboot tgz चुनें, यह स्वयं boot और vendor_boot निकाल लेगा, आपको पहले अनज़िप करने या मैन्युअल रूप से निकालने की ज़रूरत नहीं।

⚠️ पूरे पैकेज को पूरा ऐप कैश में कॉपी करना होगा तभी रैंडम रीड हो सकेगा (ZIP केंद्रीय निर्देशिका पैकेज के अंत में होती है, और SAF का uri File में नहीं बदल सकता)। जगह कम होने पर तुरंत मना कर देगा, निकालने के बाद तुरंत कैश हटा देगा।

4.1.2 = 4.1.0 + 19 कमिट। ये कमिट मूल रूप से fix/baseline-routing ब्रांच पर रुके थे, अब main में मर्ज कर दिए गए हैं। जारी किए गए 4.1.0 इंस्टॉल पैकेज में ये शामिल नहीं हैं —— नीचे दी गई हर बात उसके बाद ही ठीक की गई।

ठीक किए गए साइलेंट फ़ेल्योर

#	दोष	परिणाम
1	6.1 का VR_TAG_A_OFF 0x06 भर दिया गया (वास्तविक मापन में यह 0x04 होना चाहिए)	ब्लू-ब्रांड 6.1 मॉडल्स पर मार्कर का एक बाइट भी नहीं मिटा, जबकि स्व-जाँच सफल बताती रही। अभिव्यक्ति यह है कि "प्रिविलेज एस्केलेशन सफल होने के बाद चाइल्ड प्रोसेस तुरंत मार दिया जाता है", इसका कारण पता नहीं चलता
2	kallsyms ऑफ़सेट टेबल लोकेट करने में ऋणात्मक मॉड्यूलो का उपयोग (Python सिमैंटिक्स का सीधा अनुवाद)	6.4+ कर्नेल में पूरा स्लॉट फ़ेल, बेस एड्रेस एक ASCII टेक्स्ट से ले लिया गया
3	ऑफ़सेट टेबल की कसौटी केवल "पहले तीन आइटम मोनोटोनिक" देखती थी	लगभग शून्य विभेदन क्षमता (टेबल में कहीं भी मोनोटोनिक होता है); इसे टेबल के आकार की जाँच में बदल दिया गया
4	BASELINE_6_12.imageBase में लक्ष्य बेस एड्रेस भर दिया गया	निरपेक्ष एड्रेस रूप के निर्माण बिंदु सभी छूट गए (39 स्थान → 9 स्थान)
5	सिंबल मेल न खाने पर केवल उत्पाद खाली किया जाता था, gate अभी भी Proceed रहता था	blocked=false और उत्पाद 0 B, UI में ब्लॉक डायलॉग नहीं आता
6	FopsSlot का fallback कभी उपयोग ही नहीं हुआ	टेबल न मिलने पर सीधे छोड़ देता था, बैकअप सिंबल तक नहीं पहुँचता था

सुविधा पूर्णता

• 6.12 वास्तव में चल पड़ा: ashmem 6.12 में Rust कार्यान्वयन बन गया, सिंबल नाम सभी mangled → रनटाइम पर miscdevice के fops स्लॉट से पढ़ने में बदल दिया गया (TARGET_ASHMEM_FOPS_UNSYMBOLED)
• 6.1 / 6.12 सामान्य / ब्लू-ब्रांड दोनों समाधानों के अंतर्गत उपलब्ध (चारों संयोजन क्रमशः 16 / 16 / 13 / 13 स्लॉट), सूची देखें संग्रह 07-文档/6.1-6.12-双方案清单.md
• vr.ko मार्कर ऑफ़सेट प्रति-डिवाइस वास्तविक मापन: 6.1 = 0x04, 6.6 / 6.12 = 0x06 (तीन असली डिवाइसों के विक्रेता फ़र्मवेयर में vr.ko)
• पेलोड निर्माण रेसिपी रिपॉज़िटरी के साथ (载荷构建/): पहले रिपॉज़िटरी में 15 स्थानों पर संदर्भ एक अनुपस्थित निर्देशिका की ओर इशारा कर रहे थे

★ असली डिवाइस पर पकड़ा गया: 6.1 पर 26 ऑफ़सेट में एक भी नहीं बदला, फिर भी पैकेज बन गया

X100 Pro (6.1.145) पर बिल्ड चलाने का परिणाम यह रहा:

偏移解析: 28 / 28 项
需要改写: 26 项 · 校验通过: 0 项
该动态库未引用 26 项偏移

यह "कुछ बदलने को नहीं है" नहीं है, बल्कि "ये दो चीज़ें एक सेट की नहीं हैं"। मूल कारण यह है कि दो स्वतंत्र रास्तों ने गलत मोड़ ले लिया:

क्या चुनें	किसके अनुसार चुनें	6.1.145 पर क्या चुना गया
आधार लाइब्रेरी	संरचना परिवार (F6_1)	libbaseline_6_1.so (पुराना मान baseline-6.1-tokay/target.h से)
प्रोफ़ाइल	तीन-स्तरीय रूटिंग (कर्नेल स्ट्रिंग)	up-6-1-145-… (पुराना मान GhostLock के offsets.h से)

पैच लगाने का तरीका है "प्रोफ़ाइल के पुराने मान को .so में ले जाकर शाब्दिक खोजना"। दोनों पुराने मानों का कोई प्रतिच्छेदन नहीं है, इसलिए 26 आइटम में से एक भी मेल नहीं खाया, और परिणाम यह हुआ कि आधार लाइब्रेरी की यथावत प्रतिलिपि बन गई।

पुराने हार्ड गेट ने क्यों नहीं रोका: hasFailures की कसौटी है changed && !ok && !absent —— absent को स्पष्ट रूप से बाहर रखा गया है। वह तर्क ("पुराने संस्करण के .so में संबंधित कोड पथ नहीं हो सकता") व्यक्तिगत कुंजियों के लिए तो सही है, लेकिन "सभी कुंजियों के absent होने" के लिए सही नहीं है।

सुधार के दो तरीके:

1. लाइब्रेरी और प्रोफ़ाइल को अनिवार्य रूप से एक ही स्रोत से होना चाहिए: स्व-निर्मित परिवार बेसलाइन (libbaseline_6_1.so / libbaseline_6_12.so) को अपनी प्रोफ़ाइल (baseline-6-1-tokay / baseline-6-12-honor) के साथ ही होना चाहिए, अपस्ट्रीम up-* प्रोफ़ाइल केवल अपस्ट्रीम वाले .so पर लागू होती हैं। नया BaselineLibraries.profileIdForLibrary() जोड़ा गया।
2. शून्य-हिट हार्ड गेट: यदि ऑफ़सेट विनिर्देश का एक भी साइट पर न पहुँचे तो पैकेजिंग रोक दें (बेस एड्रेस वाला नहीं गिना जाता —— वह पूरी तरह बेमेल होने पर भी अक्सर बदल जाता है, जो "एक भी ऑफ़सेट नहीं बदला" को छिपा देगा)। इसके लिए SpecOutcome में kind फ़ील्ड जोड़ा गया।

रिग्रेशन केस BaselineLibraryPairingTest (4 केस) में हैं, जिनमें से एक सीधे यह दावा करता है कि दोनों पुराने मानों का कोई प्रतिच्छेदन नहीं है —— इसने "पेयरिंग क्यों अनिवार्य है" को एक निष्पादन-योग्य तथ्य बना दिया।

डायनामिक लाइब्रेरी: आयात के बाद "क्लिक करने पर कुछ नहीं होता" वाली समस्याएँ

#	दोष	परिणाम
1	"पेलोड निर्माण → पेलोड के रूप में उपयोग" मेमोरी में बने उत्पाद का उपयोग करता है, प्रक्रिया रीसाइकल होने पर outputLibrary null हो जाता है, जबकि पुराना कोड ?: return था	क्लिक करने पर कुछ भी नहीं होगा: न Toast, न त्रुटि, बटन अपरिवर्तित —— उपयोगकर्ता को बस "क्लिक करने पर कुछ नहीं हुआ" दिखता है
2	PayloadStaging की कैश कुंजी "समान नाम + समान लंबाई" है	कस्टम पेलोड निजी निर्देशिका में हमेशा payload.so कहलाता है, बाइट्स की संख्या बिल्कुल समान वाला दूसरा पेलोड बदलने पर चुपचाप पिछले वाले का पुनः उपयोग हो जाता है
3	shizukuStage की कैश कुंजी केवल लंबाई है	वही गड्ढा Shizuku पथ पर फिर से पड़ा
4	केवल एक कस्टम पेलोड संग्रहीत कर सकते हैं	दूसरा आयात करने पर पहला ओवरराइट हो जाता है, कोई सूचना नहीं
5	सभी फ़ाइलें ऐप की निजी निर्देशिका में हैं	उपयोगकर्ता फ़ाइल प्रबंधक में नहीं देख सकता, न ही स्वयं बैकअप/व्यवस्थित कर सकता है

डायनामिक लाइब्रेरी भंडार: Download/动态库/<机型>/<文件名>.so

• भंडार (उपयोगकर्ता को दिखने वाला, स्वयं व्यवस्थित करने योग्य): Download/动态库/<机型>/<文件名>.so
• सक्रिय प्रतिलिपि (वह जो वास्तव में लोड होती है): files/active_payload/payload.so —— नीचे देखें "दो प्रतिलिपियाँ क्यों अनिवार्य हैं"
• इंटरफ़ेस में नई मॉडल के अनुसार समूहित भंडार सूची, प्रत्येक को सीधे "उपयोग करें" से वर्तमान के रूप में सेट किया जा सकता है
• समान नाम पर भिन्न सामग्री वाली दो प्रतिलिपियाँ एक-दूसरे को ओवरराइट नहीं करेंगी (स्वतः हैश प्रत्यय जुड़ता है)