unisoc-su

CVE-2025-31710 के लिए एक विधि और अनपैच्ड unisoc मॉडलों पर cmd_skt एब्स्ट्रैक्ट सॉकेट से जुड़कर रूट शेल प्राप्त करना

सबके चिल्लाने से पहले, Unisoc ने स्वयं मुझे CVE-2025-31710 बुलेटिन के बाद इसे प्रकाशित करने का अधिकार दिया है, इसलिए शांत रहें।

चलिए एक मजाक से शुरू करते हैं

हाँ, आप सपना नहीं देख रहे हैं, आज मैं आपको com.sprd.engineermode ऐप पर एक सिस्टम शेल के लिए एक एक्सप्लॉइट प्रस्तुत करना चाहता हूँ और चूँकि यह cmd_skt के विश्वसनीय क्लाइंट्स में से एक है, मैं इसमें भी प्रवेश करने में सक्षम था। यह एब्स्ट्रैक्ट सॉकेट एक सेवा का हिस्सा है जो रूट (cmd_services) के रूप में चल रही है, तो हाँ, मुझे आपको unisoc-su प्रस्तुत करके खुशी हो रही है। यहाँ आप cmd_services बाइनरी से ghidra के साथ निकाले गए cmd_skt के विश्वसनीय क्लाइंट्स की एक सूची देख सकते हैं जो दर्शाती है कि com.sprd.engineermode मौजूद है:

इस एक्सप्लॉइट के लिए pascua28 द्वारा com.sammy.systools ऐप और TomKing062 द्वारा cli-pie का उपयोग किया जाता है। इस ऐप के दो संस्करण हैं, एक में सिस्टम शेल से उपयोग करने के लिए कई बाइनरी हैं, दूसरे में केवल cli-pie और अन्य विभिन्न सॉकेट्स से जुड़ने के लिए कुछ CLIs हैं (engpc के लिए आप अब सिस्टम शेल से यह सोर्स कर सकते हैं, मैं पहले tools.sh सोर्स करने का सुझाव देता हूँ), फिर दोनों के लिए Android 9 का एक संस्करण है (पुराने उपकरणों के लिए, वैसे भी आप Apktool M के साथ इच्छित संस्करण चुनकर ऐप को रीपैक कर सकते हैं)।

यह विधि कैसे काम करती है: आप पहले adb या shizuku rish के रूप में UnisocEngSyshell_Enabler_Script.sh निष्पादित करते हैं ताकि com.sprd.engineermode ऐप सक्षम हो सके (केवल नए मॉडलों पर आवश्यक), फिर निर्देशों का पालन करते हुए डायलर पर *#*#83781#*#* चलाएँ ताकि मुख्य गतिविधि चले, फिर यहाँ से Adb शेल गतिविधि में प्रवेश करें। फिर एक पंक्ति में पूर्ण cli-pie PATH (एप्लेट सहित) दर्ज करें, दूसरी पर "setprop persist.sys.cmdservice.enable enable", फिर setprop पर पहले और फिर cli-pie पंक्ति पर जितनी जल्दी हो सके स्टार्ट दबाएँ, और बूम यह कनेक्टेड दिखाएगा। फिर setprop गतिविधि पर एंड दबाएँ और उसका टेक्स्ट हटाएँ, "nc -s 127.0.0.1 -p 1234 -L sh -l" या जो भी आप रिवर्स शेल चलाने के लिए उपयोग करते हैं, इनपुट करें। फिर टर्मिनल पर जाएँ और संबंधित बाइनरी के साथ वापस कनेक्ट करें, यदि यह नहीं चलता है तो संबंधित स्क्रिप्ट सोर्स करें या बस "nc 127.0.0.1 1234" से कनेक्ट करें, उसके बाद "source /sdcard/Documents/unisoc-su.sh" (या जहाँ आपने स्क्रिप्ट रखी है, लेकिन यह सिस्टम शेल से सुलभ होनी चाहिए)। बस इतना ही, यदि सब कुछ सही है तो आपको अभी-अभी एक रूट शेल मिल गया।

अब, इस एक्सप्लॉइट के बारे में बात करते हैं, संदर्भ selinux द्वारा भारी सुरक्षित है, हमारे पास रूट है लेकिन सभी सुरक्षाएँ अभी भी सक्रिय हैं। यह रूट बहुत बड़ा है क्योंकि हमने इसे पाने के लिए अन्य समान एक्सप्लॉइट्स की तरह कुछ भी अक्षम नहीं किया। दुर्भाग्य से इस संदर्भ में selinux को अक्षम करने की पर्याप्त शक्ति नहीं है और निष्पादन केवल सिस्टम PATH पर काम करता प्रतीत होता है। सेवा के बारे में ही, Android 9 पर (इसलिए CVE-2022-47339 पैच से पहले) इसके सेवा rc पर कोई समूह नहीं है और इसलिए वे डिफ़ॉल्ट रूट हो जाते हैं, बाद में इसके बजाय समूह जोड़े गए (और रूट को gid/groups से हटा दिया गया) इसलिए यह स्पष्ट है कि सेवा अधिक प्रतिबंधित हो गई, लेकिन selinux सक्रिय होने पर यह वही है जो वैसे भी शासन करता है। सेवा कैसे काम करती है: नए उपकरणों पर सेवा तब तक चलती प्रतीत होती है जब तक कोई चीज़ इसका उपयोग करती है या इससे जुड़ी होती है, यदि कोई क्लाइंट कनेक्टेड नहीं है या कोई कमांड जारी नहीं किया गया है तो सेवा बंद हो जाएगी और इसे वापस चालू करने के लिए setprop गुण की आवश्यकता होगी, सेवा ऐसा लगभग तुरंत करती है, यही कारण है कि इस विधि में हम setprop चलाते हैं और तेज़ी से कनेक्ट करते हैं, Android 9 पर सेवा setprop जारी होने के बाद एक कमांड की प्रतीक्षा करती प्रतीत होती है, यह पुराने और नए उपकरणों के बीच का अंतर प्रतीत होता है, निष्पादन के बाद यह बंद हो जाती है, निश्चित रूप से socat या cli-pie के साथ (या ब्रिज चलाकर) इससे जुड़ना संभव है, इस स्थिति में सेवा तब तक सक्रिय रहेगी जब तक यह इस कनेक्शन द्वारा व्याप्त है, यदि कोई कमांड प्रदान नहीं किया गया है तो सेवा अनिश्चित काल तक प्रतीक्षा करती रहेगी।

cmd_services.rc एंड्रॉइड 13 यूज़र रॉम और एंड्रॉइड 9 इंजी रॉम से अंतर दिखाने के लिए

इस विधि को प्रेरित करने वाले CVEs: CVE-2022-47339 (cmd_services) लेवेई क्यू (曲乐炜) द्वारा और CVE-2025-31710 (com.sprd.engineermode सिस्टम शेल) मेरे द्वारा, हालाँकि लेवेई क्यू (曲乐炜) का com.sprd.engineermode पर एक समान CVE था प्रतीत होता है लेकिन मैंने इसे अपना पाने के बाद पाया।

इसके अलावा तीन विशेष मामले जो बाद में आए, वे प्रेरक CVEs सूची का हिस्सा नहीं हैं, पहला एक पुनः प्रस्तुत भेद्यता है, मैं इसे चीजों को साफ करने के लिए यहाँ जोड़ूँगा: CVE-2025-67264 (Doogee com.sprd.engineermode नए unisoc मॉडलों पर खराब पैच, यहाँ कवर किया गया) मेरे द्वारा भी, दूसरा मामला ZTE के नए मॉडलों से संबंधित है, यह स्पष्ट नहीं है कि यह सभी पर लागू होता है या केवल कुछ पर, com.sprd.engineermode की Adb शेल गतिविधि को रखा गया था, ZTE Blade V70 Vita पर वही समस्या होती है जो CVE-2025-67264 पर है, लेकिन बाद में ZTE ने इसे गतिविधि को userdebug/eng तक लॉक करके पैच किया (कोई CVE नहीं क्योंकि उन्होंने स्वयं इसे देखा) इसे हटाने के बजाय, परिणामस्वरूप गतिविधि ऐप UI पर दिखाई देती है लेकिन यूज़र बिल्ड पर नहीं खोली जा सकती, उपकरण इस पर असुरक्षित है (संभवतः इस परिवर्तन से पहले): ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20241231.044538:user/release-keys और ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20250527.224618:user/release-keys पर पैच किया गया, ZTE Blade A55 पर भी ऐसा ही होता है, ये मॉडल Android 14 चलाते हैं, वहाँ cmd_services को फिर से लिखा गया और इसका नाम बदलकर tool_service कर दिया गया (और इसे एक्सेस करने वाली सेवाएँ सिकुड़ गईं: com.sprd.engineermode, com.sprd.autoslt, com.sprd.runtime, com.spreadtrum.sgps, com.sprd.validationtools), यह नया संस्करण हमेशा सक्रिय है और किसी setprop की आवश्यकता नहीं है, तीसरा जो इस रिपॉजिटरी की भेद्यता के समान है और पुराने unisoc मॉडलों को प्रभावित करता है, यहाँ कवर किया गया।