🎤 🍁 🤰🏾 MAG250 पर UID और स्टाकर प्राधिकरण 🤗 🦏 🛁

मैं लंबे समय से स्टाकर पोर्टल में मीडिया कंसोल के प्राधिकरण के विषय में रुचि रखता था, लेकिन यह इससे पहले नहीं था। एक दिन गलती से मुझे Infomir MAG250 उपसर्ग मिल गया और मैंने इस मुद्दे से निपटने का फैसला किया।

प्रशिक्षण

सबसे पहले, मैंने उपसर्ग को विघटित किया, केबल को कनेक्टर से मिलाया और इसे कंप्यूटर से जोड़ा। टर्मिनल प्रोग्राम लॉन्च करने के बाद, मैं परिचित यू-बूट से प्रसन्न था। किसी भी कुंजी को दबाकर बूट प्रक्रिया को भी बाधित किया जा सकता है (आमतौर पर निर्माता ऐसे चिप्स को निष्क्रिय कर देता है और आपको यू-बूट को वांछित स्थिति में लाने के लिए बहुत समय बिताना पड़ता है)। रूट विशेषाधिकारों के साथ प्रवेश भी ssh के माध्यम से उपलब्ध था।

कंसोल 256MB DRAM और दो फ्लैश ड्राइव, NOR 1 MB और NAND 256 MB से लैस है। NOR के साथ, U-Boot प्रक्रिया में लोड होता है, जो NAND से कर्नेल और फाइल सिस्टम को लोड करता है।

Getuid () फ़ंक्शन

उपसर्ग खुद को स्टाकर पोर्टल में अधिकृत करता है, किसी भी जानकारी का एक गुच्छा भेज रहा है, जैसे, उदाहरण के लिए, प्रकार, फर्मवेयर संस्करण, हार्डवेयर संस्करण, सीरियल नंबर, आदि। लेकिन मुझे विशेष रूप से device_id पैरामीटर में दिलचस्पी थी, जिसे gSTB.GetUID () फ़ंक्शन जारी किया गया था। पहली नज़र में, यह SHA256 या MD5 की तरह एक हैश था। आधिकारिक दस्तावेज soft.infomir.com/stbapi/JS/v343/gSTB.html#.GetUID का उल्लेख करते हुए , फ़ंक्शन दो मापदंडों तक ले जा सकता है, लेकिन पहली बात मुझे इसमें दिलचस्पी थी जो मापदंडों के बिना विकल्प था। आईडीए में stbapp लोड करके, हम आसानी से इस फ़ंक्शन को पा सकते हैं।

थोड़ा आगे जाने पर हमें एक दिलचस्प क्षण दिखाई देता है

यहाँ, प्रोग्राम स्मृति के 0x41 बाइट्स आवंटित करता है, इसे nullify करता है, और ड्राइवर फ़ंक्शन / dev / stapi / stevt_ioctl को कॉल करता है, स्मृति के इस टुकड़े को पारित कर रहा है और इसके लिए पैरामीटर 0xC004C919। इसलिए, एक निश्चित stevt_ioctl ड्राइवर UID को बनाने के लिए जिम्मेदार है। इसे जांचने के लिए, मैंने जल्दी से इस कोड को स्केच किया:

कंसोल पर चल रहा है, मैंने एक परिचित यूआईडी देखा।

stevt_ioctl

अगला कदम stapi_ioctl_stripped.ko ड्राइवर को अलग करना है, जो / रूट / मॉड्यूल में स्थित है। हम ड्राइवर को आईडीए में लोड करते हैं और हैंडलर 0xC004C919 ioctl (मैं इस फ़ंक्शन कैल्कैश कहा जाता है) को ढूंढता हूं।

तीन दिलचस्प बिंदु हैं। सबसे पहले, 0x41 बाइट्स की मेमोरी को यूजर स्पेस से कर्नेल स्पेस में कॉपी किया जाता है (यह ठीक वही है जो यूजर द्वारा प्रसारित किया जाता है और हमारे मामले में शून्य से होता है), get_mem_type फ़ंक्शन को कहा जाता है(कर्नेल में ही रास्ते के साथ) और परिणाम (फिर से 0x41 बाइट्स) को फिर उपयोगकर्ता के पते क्षेत्र में कॉपी किया जाता है। Get_mem_type फ़ंक्शन का पता खोजने के लिए, मैंने दो संभावनाएँ देखीं: बस / proc / kallysms फ़ाइल को देखें, यह आशा करते हुए कि पहुँच प्रतिबंधित नहीं है, या, अन्यथा, ड्राइवर के लिए असेंबली में एक असेंबली स्वयं लिखें, जो सही जगह पर रजिस्टर r0 का मान लौटाता है। / Proc / kallysms में देखने के बाद, मुझे सुखद आश्चर्य हुआ और get_mem_type 0x8080E380 फ़ंक्शन का पता मिला ।

कोर

आगे के विश्लेषण के लिए, आपको कर्नेल का विश्लेषण करने की आवश्यकता होगी। कर्नेल स्वयं निर्माता के फर्मवेयर में पाया जा सकता है, या आप यू-बूट का उपयोग करके डंप को हटा सकते हैं

या वांछित विभाजन को माउंट कर सकते हैं।

U- बूट जानकारी के आधार पर, कर्नेल को 0x80800000 पर लोड किया जाता है, और प्रवेश बिंदु 0x80801000 पर है। हम IDA में कर्नेल को लोड करते हैं और get_mem_type फ़ंक्शन ढूंढते हैं ।

कोड का विश्लेषण करने के बाद, मैंने इस खंड की खोज की, जो माना जाता है कि यूआईडी वापस कर दिया गया है।

तो UID 0x80D635EC पर संग्रहीत है। अगला, हम आईडीए में तलाश कर रहे हैं, जहां यह मान बनता है। यह init_board_extra फ़ंक्शन में था (मैंने पूरी सूची का अनुवाद नहीं किया)

तो यह r4 रजिस्टर के पते पर समान अज्ञात मूल्य है जिसमें से ब्याज के हैश की गणना की जाती है (जिस तरह से SH_256 द्वारा हल किया गया था) भरें। मैं वास्तव में यह पता लगाने के लिए उत्सुक था कि यह क्या था और मैंने जल्दी से कोडांतरक में एक प्रविष्टि लिखी, जो कि प्रिंट फ़ंक्शन के माध्यम से, रजिस्टर r2 के पते पर मेमोरी की सामग्री लौटा दी। इस तरह से कर्नेल को संशोधित करने के बाद, मैंने एक नया uImage बनाया और इसे USB ड्राइव पर अपलोड किया। और टर्मिनल U- बूट सेट में:

usb start
fatload usb 0:1 80000000 uImage
bootm

लेकिन आखिरी टीम के बाद, इस तरह की उदासी मेरा इंतजार कर रही थी।

यू-बूट ने विनम्रतापूर्वक मेरे नए कर्नेल को जहाज करने से इनकार कर दिया।

यू-बूट का संपादन

अपने कर्नेल को बूट करने के लिए U- बूट को समझाने के लिए, मैंने इसे mw कमांड के साथ मेमोरी में पैच करने का निर्णय लिया । शुरू करने के लिए, मैंने NOR फ्लैश का एक पूर्ण डंप बनाया, जो 0xA0000000 पर स्थित है। आईडीए में डंप को संचालित करने के बाद, मैंने मेमोरी एड्रेस की खोज की, जहां यू-बूट ने खुद को कॉपी किया था। यह 0x8FD00000 था। फिर से, मेमोरी के इस हिस्से को चलाने और आईडीए चलाने के बाद, मुझे आसानी से एक फ़ंक्शन मिला जिसने हस्ताक्षर की जांच की। यदि सब कुछ सही था, तो वह 0. वापस आ गई। इसके अलावा, उसे दो अलग-अलग जगहों पर बुलाया गया।

वास्तव में इस समारोह ने क्या किया मेरे लिए दिलचस्प नहीं था। उसे बस इस तरह 0 वापस करने की आवश्यकता थी:

mov #0x0, r0
rts
nop

U- बूट के लिए संबंधित कोड अब इस तरह था:

usb start
mw.l 8fd0ec08 000b200a;
mw.l 8fd0ec0c 00900009
fatload usb 0:1 80000000 uImage
bootm

फिर यू-बूट ने खुशी से मेरा कर्नेल लोड किया, जो जारी किया

EF0F3A38FF7FD567012016J04501200:1a:79:23:7e:2MAG250pq8UK0DAOQD1JzpmBx1Vwdb58f9jP7SN

पूर्ण विश्लेषण

तो, यूआईडी में क्या शामिल था? यह 8 बाइट्स की कुछ अज्ञात संख्या, कंसोल का सीरियल नंबर, मैक एड्रेस, कंसोल का प्रकार और कचरे का एक टुकड़ा था। यह पता लगाने के लिए रहता है कि यह किस प्रकार की अज्ञात संख्या थी और कचरा कहां से आया था। मैं init_board_extra फ़ंक्शन पर फिर से लौटा ।

इस कोड अनुभाग से एक अज्ञात नंबर लिया गया था:

यहां, __ioremap फ़ंक्शन का उपयोग करते हुए, कर्नेल ने 0x00000000 (जो फ्लैश का NOR पता था) पर भौतिक मेमोरी एक्सेस की, 0x0F को 0x00000000 लिखा, फिर 0x98 से 0x000000AA और 8x को 0x000000C2 से प्रारंभ करने के लिए पढ़ा। और वो क्या है? ये CFI प्रोटोकॉल कमांड हैं जिनके साथ कर्नेल ने NOR के साथ संचार किया। 0x0F NOR को उसकी मूल स्थिति में लाया, और 0x98 स्विच कमांड mods CFI के साथ। इस मॉड्यूल में, 0x000000C2 पते पर सुरक्षा कोड क्षेत्र या 64-बिट अद्वितीय डिवाइस नंबर है। उन। अज्ञात संख्या एक अद्वितीय NOR फ़्लैश संख्या है। निम्नलिखित CFI पहचान का एक डंप है।

आप सेटिंग करके सीधे यू-बूट में अपना डंप बना सकते हैं

mw.w a0000000 f0
mw.w a00000aa 98
md.b a1000000 100

कचरे का एक टुकड़ा सिर्फ एक साधारण 32-बाइट वर्ण सेट था जिसे कर्नेल में ही सीवन किया गया था।

और इस कचरे को एन्क्रिप्शन फ़ंक्शन swap_pairs का उपयोग करने से पहले संसाधित किया गया था , जिसने बस बाइट्स की स्थिति बदल दी थी।

[0x00000003]<->[0x0000000F]
[0x00000005]<->[0x0000001F]
[0x00000009]<->[0x00000002]
[0x0000000A]<->[0x0000001D]
[0x00000010]<->[0x00000015]
[0x00000004]<->[0x00000013]
[0x0000000D]<->[0x00000018]

प्राप्त जानकारी के आधार पर, मैं यह मानने का साहस करता हूं कि निर्माता के डेटाबेस में प्रत्येक ID NOR फ्लैश और संबंधित क्रम संख्या और मैक पते की जानकारी है।
बेशक, यह सब चुनना असंभव है, लेकिन आप अपना खुद का सॉफ़्टवेयर लिख सकते हैं, जो कंसोल को पूरी तरह से अनुकरण करेगा।

MAG250 पर UID और स्टाकर प्राधिकरण

प्रशिक्षण

Getuid () फ़ंक्शन

stevt_ioctl

कोर

यू-बूट का संपादन

पूर्ण विश्लेषण

More articles: