प्रागितिहास

इंटर्नशिप ज्ञान और अनुभव प्राप्त करने की प्रक्रिया है। हमारी रैकोन सिक्योरिटी टीम का मानना ​​है कि इस ज्ञान और अनुभव को भावी पीढ़ियों को हस्तांतरित किए बिना उपकरणों और सॉफ्टवेयर की सूचना सुरक्षा में सुधार असंभव है। यही कारण है कि हम कई वर्षों से प्रतिभाशाली छात्रों और स्नातकों के लिए व्यक्तिगत इंटर्नशिप का आयोजन कर रहे हैं।

सुरक्षा अनुसंधान एक कौशल है जिसे विश्वविद्यालय में नहीं पढ़ाया जाता है। आप इसे ठोस उदाहरणों से और अनुभवी आकाओं के मार्गदर्शन में सीख सकते हैं। हर साल, हमारे इंटर्न जटिल तकनीकी समस्याओं को हल करते हैं, अपने लक्ष्यों को प्राप्त करते हैं और आगे बढ़ते हैं, अपने पेशेवर क्षितिज का विस्तार करते हैं और दुनिया को थोड़ा सुरक्षित करते हैं। उनमें से प्रत्येक की एक विशेषज्ञ बनने की अपनी कहानी है, और कटौती के तहत - उनमें से एक की शुरुआत।

परिचय

पिछले साल अक्टूबर में, मैं एनटीसी वल्कन कंपनी में एक तकनीकी इंटर्नशिप के लिए आया था। मेरी रुचि रिवर्स इंजीनियरिंग के क्षेत्र के लिए निर्देशित थी। मुझे पता था कि यह क्या था, मैंने पहले ही x86 के तहत स्वतंत्र रूप से क्रैकमे पर शोध करने की कोशिश की थी, लेकिन मैं समझ गया कि सबसे दिलचस्प बात सॉफ्टवेयर और हार्डवेयर के जंक्शन पर ठीक है। मुझे इस क्षेत्र में अनुभव नहीं था, लेकिन मुझे अपने हाथ आजमाने की इच्छा थी।

मुझे इस आयोजन से कोई विशेष उम्मीद नहीं थी - दोस्तों और परिचितों ने कई प्रसिद्ध कंपनियों में तकनीकी इंटर्नशिप के बारे में बात की। और जब मुझे USB-SATA अडैप्टर पर शोध करने के लिए हाथ आजमाने की पेशकश की गई, तो मुझे कुछ सीखने के नए अवसर की खुशी हुई। अनुभव प्राप्त हुआ और मैंने जो परिणाम प्राप्त किया, उसने इंटर्नशिप और भविष्य के पेशे की जगह की पसंद की शुद्धता को सत्यापित करना संभव बना दिया।

और अध्ययन हाथ पर एक नियमित यूएसबी-एसएटीए एडाप्टर प्राप्त करने के साथ शुरू हुआ। यहाँ मैंने आगे क्या किया है।

दृश्य सर्किट विश्लेषण

सबसे पहले आपको एडॉप्टर बोर्ड का निरीक्षण करने और डिवाइस के मूल तत्वों को निर्धारित करने की आवश्यकता है। नीचे दिए गए आंकड़ों में, उपकरणों के संचालन के लिए महत्वपूर्ण घटकों के मुख्य ब्लॉक चिह्नित हैं। शोध के बाद ली गई तस्वीरें:

SATA एडाप्टर के लिए USB। शीर्ष दृश्य

SATA एडाप्टर के लिए USB। नीचे का दृश्य

Google में कुछ समय बिताने के बाद, मुझे पता चला कि बोर्ड पर दो वोल्टेज कन्वर्टर्स हैं: एक 3.3 V पर, दूसरा 1.2 V पर। बोर्ड पर स्थापित फ्लैश मेमोरी को निर्धारित करना भी बहुत आसान है। ROM SPI इंटरफ़ेस पर काम करता है, और मेमोरी क्षमता 512 केबीपीएस है।

ऐसा लगता है कि सर्किट इंटेलिजेंस का चरण लगभग पूरा हो गया है, लेकिन इंटरनेट पर एक त्वरित खोज "ASM1051" के अनुरोध पर कोई परिणाम नहीं निकला। बोर्ड पर स्थापित चिप के लिए कोई दस्तावेज नहीं मिले। सच है, अभी भी सॉफ्टवेयर खोजने में कामयाब रहा जो आपको इसे अपडेट करने की अनुमति देता है। इसके अलावा, पुराने मॉडल ASM1053 के लिए एक छोटी डेटाशीट है ।

यूएसबी

कंप्यूटर से कनेक्ट होने पर, एडाप्टर USB संग्रहण डिवाइस के रूप में प्रकट होता है। मैंने फैसला किया कि USB का गहन ज्ञान शायद मेरे शोध के लिए उपयोगी होगा, इसलिए अगले दो घंटे मैंने इंटरफ़ेस का अध्ययन करने में बिताया।
सामान्य तौर पर, USB डिवाइस विभिन्न वर्गों के हो सकते हैं, जो उनकी कार्यक्षमता पर निर्भर करता है। उदाहरण के लिए, फ्लैश ड्राइव मास स्टोरेज डिवाइस हैं, और कीबोर्ड और चूहों मानव इंटरफ़ेस डिवाइस (HID) हैं । और चूंकि मेरा एडाप्टर डिवाइस मैनेजर में स्टोरेज डिवाइस के रूप में दिखाई देता है, इसका मतलब है कि इसे मास स्टोरेज के रूप में परिभाषित किया गया है और इसे एससीएसआई कमांड के साथ काम करना चाहिए।

ROM से मेमोरी पढ़ें

चूंकि बोर्ड पर स्थापित ASM1051 के बारे में कुछ भी ज्ञात नहीं है, इसलिए रोम से मेमोरी को सबसे स्पष्ट कार्रवाई माना जाता था। मैं प्रयोगशाला में स्थानांतरित हो गया। टांका लगाने वाले हेयर ड्रायर के साथ फ्लैश मेमोरी चिप को अलग किया, इसे चिपप्रोग -48 यूएसबी प्रोग्रामर से जोड़ा। पढ़ने में कोई समस्या नहीं थी, और मेरे हाथों पर एक बाइनरी फ़ाइल थी। उस समय, मैं यह नहीं कह सकता था कि फ्लैश ड्राइव पर क्या था, और डेटा का विश्लेषण करना शुरू किया।

बाइनरी फ़ाइल विश्लेषण

सबसे पहले, मैंने WinHex का उपयोग करके ROM से एक मेमोरी डंप खोला, लेकिन आप किसी भी हेक्स संपादक का उपयोग कर सकते हैं। बाइट्स को देखने लगे:

ROM से पढ़ने वाले मेमोरी डंप की शुरुआत

ऊपर स्क्रीनशॉट एडिटर का स्क्रीनशॉट है। लाइन ASMT1051 , जो 0x44 पते से शुरू होती है, तुरंत स्पष्ट हो जाती है। आप पता 0x18 से लाइन asmedia भी देख सकते हैं। प्रारंभिक डेटा विश्लेषण के लिए, मैंने आवृत्ति विश्लेषण उपकरण का उपयोग किया, जो कि WinHex में उपलब्ध है।

रोम मेमोरी की आवृत्ति विश्लेषण का हिस्टोग्राम

हिस्टोग्राम उन बाइट्स को दिखाता है जो फ़ाइल में सबसे अधिक हैं। ढेर 0x00 और 0xFF (हिस्टोग्राम पर चरम कॉलम) के अलावा, निम्नलिखित बाइट्स अक्सर मेमोरी में पाए जाते हैं:

• 0x02;
• 0x74;
• 0x90;
• 0xA3;
• 0xE0;
• 0xF0।

मेरी धारणा की पुष्टि करना संभव होगा कि रॉम में फर्मवेयर है। इसका एक आसान तरीका यह है कि बाइट के साथ माइक्रोकंट्रोलर्स (इसके बाद एमसी) के लिए उपयुक्त विभिन्न आर्किटेक्चर के ऑपकोड की तुलना करने की कोशिश की जाए जो अक्सर मेमोरी में पाए जाते हैं।

यदि मोटे तौर पर अनुमान लगाया जाए, तो कोडांतरक के किसी भी कोड में बहुत बार इस तरह के आदेश मिलने चाहिए:

• mov;
• JMP;
• कहते हैं;
• गीला करना।

बेशक, विभिन्न आर्किटेक्चर में इन आदेशों में भिन्न भिन्नताएं हो सकती हैं, लेकिन एक सामान्य ज्ञान है।

इससे पहले कि मैं सही पाया मुझे विभिन्न गुठली के लिए निर्देशों के कई सेटों से गुजरना पड़ा। इंटेल 8051 की वास्तुकला के साथ तुलना ने बहुत प्रशंसनीय परिणाम दिया। कुछ कमांड के ओपकोड एक फ़ाइल से लोकप्रिय बाइट्स के साथ मेल खाते हैं, उदाहरण के लिए:

• 0x02 - LJMP addr16;
• 0x74 - एमओवी ए, #immed;
• 0x90 - MOV DPTR, #immed;
• 0xA3 - INC DPTR;
• 0xE0 - MOVX A, @DPTR;
• 0xF0 - MOVX @DPTR, ए।

यह वास्तव में ऐसा लगता है कि ROM में MK के लिए फर्मवेयर है। एक व्यक्ति तुरंत IDA प्रो डिस्सेम्बलर में बाइनरी को लोड कर सकता है, लेकिन दोपहर के भोजन में एक सहयोगी ने पूछा:

"क्या आप सुनिश्चित हैं कि स्मृति में कोड शून्य पते से शुरू होता है?"

और वास्तव में, आपको इस बात पर ध्यान देने की आवश्यकता है कि 0x00 पते के कुछ "कचरा" या डेटा मेमोरी में हो सकते हैं।

सामान्य तौर पर, मुझे कोड के शुरुआती पते को निर्धारित करने के कार्य का सामना करना पड़ा। इस लक्ष्य को प्राप्त करने के लिए, EM100 SPI एमुलेटर का उपयोग करना सबसे अच्छा था। एमुलेटर बोर्ड पर मेमोरी चिप को बदल देता है, इसके साथ हर बार फर्मवेयर के साथ रॉम को मिलाप करने की आवश्यकता नहीं होती है, इसके अलावा, ईएम 100 मेमोरी एक्सेस लॉग रिकॉर्ड कर सकता है। यह देखते हुए कि ROM से फर्मवेयर पहले ही पढ़ा जा चुका है, अब आप इसे SPI एमुलेटर पर डाउनलोड कर सकते हैं। अगला, आपको एडाप्टर बोर्ड को एमुलेटर को मिलाप करने की आवश्यकता है और एडेप्टर को यूएसबी के माध्यम से पीसी से कनेक्ट करते समय एक लॉग रिकॉर्ड करना होगा।

एसपीआई एमुलेटर यूएसबी-एसएटीए एडेप्टर बोर्ड में मिलाप है

मैंने फ्लैश मेमोरी से एमुलेटर से पैड तक वायरिंग को सोल्डर किया और एमुलेटर को कुछ फर्मवेयर के साथ फ्लैश किया। अब यह देखना बाकी है कि एमके स्मृति को संबोधित करता है, और यदि ऐसा है तो क्या पते पर।

रॉम मेमोरी (एसपीआई एमुलेटर सॉफ्टवेयर का उपयोग करके प्राप्त किया गया) की पहुंच

ऊपर दिए गए आंकड़े से पता चलता है कि जब पावर एडाप्टर से जुड़ा होता है, तो बोर्ड पर स्थापित ASM1051 कंट्रोलर कई 0x03 (डेटा पढ़ें) कमांड भेजता है।

सबसे पहले, ASM1051 0x80 बाइट्स पढ़ता है, जो 0x0000 से शुरू होता है। निम्नलिखित दो बाइट्स हैं, 0x0080 पते पर शुरू करते हैं, फिर 0x8082 पते से दो और बाइट्स। फिर यह ROM से स्मृति को पढ़ता है, 0x0082 पते पर शुरू होता है।

हम मान सकते हैं कि बड़ी संख्या में बाइट्स जो कि ROM से पढ़े जाते हैं, पता 0x0082 से शुरू होता है, शायद यह कोड है। इससे पहले क्या और क्यों अनुरोध किया गया है यह अभी तक स्पष्ट नहीं है। यह केवल ज्ञात है कि पहले अनुरोध के जवाब में, ASM1051 फ्लैश मेमोरी से लाइनें प्राप्त करेगा जो ऊपर की आकृति में चिह्नित हैं। वे सिर्फ पहले 0x80 बाइट्स में स्थित थे।

यह अनुमान लगाने का समय है कि बोर्ड पर बाहरी मेमोरी में एमके के लिए 8051 कर्नेल के साथ फर्मवेयर है, और कोड स्वयं पता 0x0082 से स्थित है। आईडीए प्रो में मेमोरी डंप खोलें, प्रोसेसर प्रकार इंटेल 8051 निर्दिष्ट करें और कोड 0x0082 के लिए ऑफ़सेट करें।

ऑफसेट 0x82 के साथ आईडीए प्रो में बाइनरी फ़ाइल खोली गई

डिस्सेम्बलर में बाइनरी खोलने में कोई समस्या नहीं थी।

निष्कर्ष:

1. MK ASM1051 की वास्तुकला 8051 है।
2. ROM में एक कोड होता है जो 0x82 पते से शुरू होता है। कोड के अलावा कुछ और भी है।
3. पहले 0x80 बाइट्स ध्यान आकर्षित करते हैं।

कोड विश्लेषण

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

कोड के अध्ययन के दौरान, हमने सरल कार्यों को पाया, जैसे कि 32-बिट संख्याओं को घटाना, एस। मेलकली में switch () समान विभिन्न हैंडलर्स में आया, और बहुत ही सरल कार्य जैसे कि आर 7 रजिस्टर से मान को किसी पते पर सहेजना। सबसे महत्वपूर्ण पाता है जिसका मैं नीचे वर्णन करूंगा।

नंबर 1 खोजें

दिलचस्प बात यह है कि मेरे पूछताछ अनुरोध ( एससीएसआई कमांड ) के जवाब में, मुझे दो पंक्तियों वाली प्रतिक्रिया मिली, जिसे हमने रोम मेमोरी की शुरुआत में देखा था। बेशक, मैंने एमुलेटर की स्मृति में इन पंक्तियों को तुरंत बदल दिया, जो मैंने लिखा था उसे देखने के लिए एक अनुरोध के इंतजार में। ऐसा भोला सपना जल्दी से ढह गया। अब, कमांड के जवाब में, मैंने एक और लाइन देखी, ASM1051 ने ROM से अधिकांश मेमोरी का अनुरोध नहीं किया। एमके केवल पहले 0x80 बाइट्स और सभी पढ़ें। 8051 की वास्तुकला में, मुखौटा (हार्डवेयर) फर्मवेयर का उपयोग किया जा सकता है, जाहिर है, एएसएम 1051 ने इसे बूट करना शुरू किया।

तो यह स्पष्ट हो गया कि पहले 0x80 बाइट्स वास्तव में महत्वपूर्ण हैं, और उन्हें बदलना अभी काम नहीं करेगा। मैंने अधिक विस्तार से अध्ययन करने का फैसला किया जो एमके कोड डाउनलोड करने से पहले एसपीआई पर करता है।

ROM में SPI डेटा अनुरोध

दो बाइट्स के दो अनुरोध दिलचस्प लगे। आईडीए 0x00, 0x80 और 0xEB में खोज के परिणाम की एक बड़ी संख्या है जो मैंने विश्लेषण नहीं किया था, लेकिन बाइट 0x5A कम बार आया था।

बाइट 0x5 ए के साथ तुलना। काउंटिंग चेकसम -8

मूल रूप से छठे क्लिक ने मुझे ऊपर दिए गए चित्र में दिखाए गए कोड के अनुभाग में ले जाया। यह देखा जा सकता है कि 0x80 7E पते के साथ रजिस्टर से मूल्य की तुलना 0x5A के साथ की जाती है। फिर पता 0x80 04 से 0x80 7E पर स्थित मानों के लिए चेकसम -8 पढ़ा जाता है। अगला, 0x80 7F के मान की तुलना पहले प्राप्त राशि से की जाती है।

ROM में स्मृति की शुरुआत

इस तरह के ऑफसेट रोम से मेमोरी डंप की शुरुआत से मिलते जुलते थे। ऊपर दिए गए आंकड़े से पता चलता है कि पता 0x7E में बाइट 0x5A है। और यदि आप 0x04 से 0x7E की स्थिति के लिए बाइट्स के लिए चेकसम -8 की गणना करते हैं, तो हमें 0xA7 मिलता है, और यह मान केवल 0x7F पते पर है।

इसी तरह से, हमने पता 0x0082 से 0x807F (जाहिर है यह पूरा कोड है) पते के लिए बाइट्स के लिए चेक राशि की गणना का पता लगाने में कामयाब रहा, जिसे 0x8083 पते पर बाइट के साथ जांचा जाता है। और 0x8082 पर फिर से 0x5A मान निहित है।

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

निष्कर्ष:

1. बूट के दौरान, ASM1051 ROM से कोड डाउनलोड करने का प्रयास करता है।
2. सबसे पहले, ASM1051 0x7F पर मान के साथ पते 0x04 से 0x7E तक चेकसम -8 बाइट की तुलना करता है।
3. यदि प्रस्तावना के लिए चेक राशि की तुलना सफल होती है, तो हम इसे "कोड" (0x0082 से 0x807F के पते) के लिए विचार कर सकते हैं। ASM1051 पता 0x8083 के मान के साथ इस राशि की तुलना करता है और सत्यापित करता है कि बाइट 0x5A पता 0x8082 पर स्थित है।
4. यदि सभी जांच सही हैं, तो ASM1051 को रोम से लोड किया जाता है, अन्यथा यह मास्क फर्मवेयर का उपयोग करता है।

नंबर 2 खोजें

कार्यों की समीक्षा और टिप्पणी करते समय, मैंने पाया कि बहुत बार PRINTF फ़ंक्शन कोड में उपयोग किया जाता है (मैंने इसे कहा जाता है)। इसके बारे में दिलचस्प बात यह है कि इसे बुलाया जाने से पहले, एक मुद्रित चरित्र R7 रजिस्टर को लिखा जाता है।

आईडीए में PRINTF फ़ंक्शन प्रो

फ़ंक्शन को स्वयं ऊपर की आकृति में प्रस्तुत किया गया था। चलो उसके साथ सौदा करते हैं। सबसे पहले, आपको 0x7F6 पते के साथ रजिस्टर से मूल्य को बैटरी में स्थानांतरित करने की आवश्यकता है। यदि शून्य है, तो फ़ंक्शन से बाहर निकलें। शून्य न होने पर सबसे दिलचस्प बात होती है। तब रजिस्टर R7 का मान 0xC001 के पते के साथ रजिस्टर में चला जाता है, और, जैसा कि हम याद करते हैं, इस फ़ंक्शन को कॉल करने से पहले, एक मुद्रित चरित्र R7 को लिखा जाता है। अगला, जांचें कि क्या R7 का मान वर्ण कोड "" या "-" के बराबर है, यदि नहीं, तो फ़ंक्शन से बाहर निकलें। लेकिन अगर तुलना सफल रही, तो फ़ंक्शन 0x16A पते के साथ रजिस्टर से मूल्य लेता है और इसे 0xC001 में स्थानांतरित करता है, लेकिन क्या यह मुश्किल है। उदाहरण के लिए, बाइट 0x41 (ASCII में वर्ण "A") के बजाय, फ़ंक्शन 0xC001 बाइट 0x34 (ASCII में वर्ण "4" ), और उसके बाद 0x31 (ASCII में वर्ण "1" ) पर जाएगा। फ़ंक्शन से बाहर निकलें।

मुझे पता चला कि फ़ंक्शन की शुरुआत में चेक को पारित नहीं किया जा सकता है, क्योंकि पता 0x7F6 के साथ रजिस्टर शून्य से प्रारंभ किया जाता है, फिर यह कोड में नहीं बदलता है। यही है, यह फ़ंक्शन प्रोग्रामर द्वारा अक्षम है, हालांकि यह संकलित रहता है। यह तथ्य कि बाइट्स केवल 0xC001 रजिस्टर (और कभी-कभी एक पंक्ति में दो) में लिखे जाते हैं, ने सुझाव दिया कि यह सबसे अधिक संभावना है कि एक हार्डवेयर रजिस्टर है।

यह सब UART से मिलता जुलता है। यह पता लगाने के लिए कि क्या ऐसा है, आपको निम्नलिखित कार्य करना चाहिए:

1. ASM1051 पर पैर को पहचानें जहां UART आउटपुट है।
2. UART के मापदंडों को परिभाषित करें (गति, समता, स्टॉप बिट्स की संख्या)।
3. UART को कोड में सक्षम करना अच्छा होगा (जाहिर है, इसे बंद कर दिया गया है)।

सब कुछ काफी सरल दिखता है: आप एक तार्किक विश्लेषक के साथ पैरों को छू सकते हैं और उस पर एक नज़र डाल सकते हैं जिस पर UART भेजने का क्षण दिखाई देगा। एक संकेत की उपस्थिति में, गति को दालों के समय से निर्धारित किया जा सकता है। बाकी मापदंडों के साथ, सब कुछ भी स्पष्ट है, बस विश्लेषक पर एक बाइट भेजने का क्षण देखें।

इस फ़ंक्शन को "सक्षम" करने के लिए, आप पहले तीन पंक्तियों के बजाय शून्य लिख सकते हैं, जहां मान 0x7F6 पते के साथ रजिस्टर में चेक किया गया है। ऐसा करने के लिए, मैं फिर से WinHex में फर्मवेयर खोलता हूं।

रीसेट करने के लिए छह बाइट्स आवंटित किए जाते हैं।

संपादक में, मैं वांछित छह बाइट्स को शून्य में बदलता हूं। अब फर्मवेयर तैयार है और इसे ROM एमुलेटर पर डाउनलोड किया जा सकता है। यदि हम मानते हैं कि UART में बाइट्स के आउटपुट के लिए फ़ंक्शन चालू है, और इसकी कॉल पूरे कोड में बहुत बार स्थित है, तो हम उम्मीद कर सकते हैं कि एडेप्टर चलने पर UART से बाइट्स "उड़ना" चाहिए। मुझे उम्मीद है कि UART में बाइट्स में एक ट्रैसर को देखने के लिए कोड का कितना निष्पादन हो रहा है।

जैसा कि मैंने ऊपर लिखा है, आवश्यक आरएक्स और टीएक्स पैरों को खोजने के लिए, आप एक-एक करके तर्क विश्लेषक को देख सकते हैं। हालाँकि, मैंने मान लिया कि ASM1051 पर Rx और Tx क्रमशः ASM1053 - पैर 40 और 41 के समान हैं। मैंने एनालाइज़र जांच को 41 पिन करने के लिए रखा (टीएक्स मान लिया) और मुझे वांछित सिग्नल के समान कुछ दिखाई देता है:

पैर के साथ टाइमिंग आरेख 41 - टीएक्स

USB-UART कनवर्टर कनेक्ट करने और टर्मिनल में आने वाले मुद्रित वर्णों का निरीक्षण करने के लिए, मुझे एडेप्टर बोर्ड पर सीधे दो पतली तारों को मिलाप करना था और इसे गर्म गोंद के साथ ठीक करना था।

दो तारों RX और TX के लिए मिलाप

मैंने चित्र "लेग 41 से आरेख - टीएक्स" से आरेख का थोड़ा अध्ययन किया: एक नाड़ी का समय, जाहिर है, 1 μs है, और छह बिट्स के लिए - 6.3 μs। बाउड्स में मूल्य को पुनर्गठित करने के बाद, मुझे लगभग 950,000 बॉड मिले, निकटतम मानक UART की गति 921600 बॉड है। मुझे लगता है कि यह विसंगति तार्किक विश्लेषक द्वारा माप त्रुटि के कारण प्राप्त की जाती है, मैंने सबसे योग्य डिवाइस नहीं लिया, लेकिन चीनी "बेबी"। टर्मिनल 1.9 बी कार्यक्रम की विंडो में पैरामीटर सेट करने के बाद, मैं इसके संचालन के दौरान ASM1051 एमके से आने वाले बाइट्स का निरीक्षण करने में सक्षम था।

एडॉप्टर ऑपरेशन के दौरान टर्मिनल 1.9 बी प्रोग्राम विंडो

निष्कर्ष:

ASM1051 MK में UART हार्डवेयर मॉड्यूल है। डेटा भेजने के लिए रजिस्टर का पता 0xC001 है। डेटा दर 921600 बॉड है। एक स्टॉप बिट है। लेग 41 टीएक्स है और लेग 40 आरएक्स है (हालांकि यह सटीक नहीं है)।

नंबर 3 खोजें

असंतुष्ट में कोड के माध्यम से स्क्रॉल करना, टिप्पणियों को जोड़ना, आप रजिस्टर में एक संख्या लिखने से अधिक कठिन निर्माण पा सकते हैं। इसलिए मैं एक दिलचस्प हैंडलर में आया, जिसमें सी का हिस्सा, switch () तरह लग रहा था switch () ।

0x800F पते के साथ रजिस्टर से कमांड हैंडलर

यह समझते हुए कि कहीं न कहीं एससीएसआई कमांड को संसाधित किया जाना चाहिए, मैंने उन्हें बाइट्स के लिए देखना शुरू किया, जिसके साथ 0x800F पते वाले रजिस्टर की सामग्री की तुलना ऊपर की आकृति में की गई है। यह पता चला कि पहली चार शाखाएं रीड (10), राइट (10), रीड (16), राइट (16) कमांड की जांच करती हैं। इसमें कोई शक नहीं है कि यह SCSI कमांड हैंडलर है। इसके बाद, मैंने एक फ़ंक्शन को देखा, जिसे कहा जाता है यदि कमांड जो आया है वह रीड / राइट (u_Switch) नहीं है। यह, 0x16A (0x800F से मान लिया जाता है) पते के साथ रजिस्टर में बाइट के आधार पर, उस पते को पढ़ता है, जब हम इस फ़ंक्शन से बाहर निकलेंगे। यह switch () समान है।

SCSI कमांड स्विच करें

चूंकि मैंने पहले ही बाइट का निर्धारण किया था जिसके साथ मैं एससीएसआई कमांड की तुलना करता हूं जो एडेप्टर में आया था, मैंने जल्दी से कमांड द्वारा पतों के पत्राचार की व्यवस्था की। इसलिए, उदाहरण के लिए, ऊपर की आकृति में यह देखा जा सकता है कि यदि बाइट 0x1A पता 0x16A के साथ रजिस्टर में था, तो u_Switch फ़ंक्शन से बाहर निकलने के बाद हम 0x1B85 पते पर जाएंगे। दिलचस्प है, u_Switch के साथ तुलना में सभी बाइट्स SCSI मानक में परिभाषित नहीं हैं। यही है, एडेप्टर बाइट्स 0xE6 या 0xDF प्रोसेस कर सकता है, लेकिन वे मानक द्वारा तय नहीं हैं।

जैसा कि आप देख सकते हैं, एडाप्टर कस्टम कमांड निष्पादित कर सकता है और उनके लिए हैंडलर फ़ंक्शन हैं।

यूनिवर्सल सीरियल बस मास स्टोरेज क्लास का पेज 13

पते 0x8000 के सापेक्ष ऑफसेट 0x0F पर ध्यान दें। प्रोसेसर से पहले, यह 0x800F के पते के साथ रजिस्टर से है जिसे SCSI कमांड पढ़ा जाता है। यदि आप ऊपर दिए गए आंकड़े में तालिका को ध्यान से पढ़ते हैं, तो आप देख सकते हैं कि कमांड ब्लॉक रैपर (CBW) में CBWCB फ़ील्ड में 0x0F की ऑफसेट भी है। यह पता चला है कि 0x8000 से शुरू होने वाली ASM1051 रैम मेमोरी के पते, USB बफर हो सकते हैं, जैसा कि नीचे दी गई तालिका में दिखाया गया है।

नीचे दिया गया आंकड़ा कोड के अनुभाग को दर्शाता है जहां USBC स्ट्रिंग के साथ तुलना होती है (जैसे कि dCBWSignature हस्ताक्षर होना चाहिए) और प्रस्तावित हस्ताक्षर 0x8000 पते से स्थित है। मुझे लगता है कि यह सुनिश्चित करने के लिए पर्याप्त है कि यूएसबी बफर 0x8000 से शुरू होने वाली रैम मेमोरी में स्थित है।

USBC स्ट्रिंग के साथ मैच के लिए dCBWSignature क्षेत्र की जाँच करें

निष्कर्ष:

1. MK ASM1051 न केवल SCSI कमांड को संभाल सकता है, जो मानक में वर्णित है।
2. USB बफर का शुरुआती पता 0x8000 है। SCSI कमांड 0x800F पते के साथ रजिस्टर में स्थित है, जिसका अर्थ है कि कमांड के आगे डेटा / तर्क होंगे।

नंबर 4 पाएं

यह जानते हुए कि एमके गैर-मानक टीमों को संसाधित कर सकता है, मैं जानना चाहता था कि वे क्या कर रहे थे। उनमें से ज़्यादातर ने मेरी बात मानी। मैं इन आदेशों के कोड के अध्ययन का हवाला नहीं दूंगा, क्योंकि इसमें एक लंबा समय लग सकता है और "असेंबलर सरल है" नामक एक अलग लेख के लिए सामग्री हो सकती है, मैं नीचे दी गई तालिका में परिणामों का वर्णन करूंगा।

मैं मानता हूं कि मैंने आईडीए में फ़ंक्शन पढ़कर सभी आदेशों का पता नहीं लगाया। अनुसंधान के दौरान दीवार से टकराकर, मुझे याद आया कि मैंने ASM1051 के लिए सॉफ्टवेयर और कई फर्मवेयर देखे थे, जब मैं इस पर प्रलेखन की तलाश कर रहा था। पाए गए सॉफ़्टवेयर का उपयोग करके, आप फर्मवेयर को अपडेट कर सकते हैं और डिवाइस को रिबूट कर सकते हैं। इसलिए, मैंने फैसला किया कि यह डिवाइस मॉनिटरिंग स्टूडियो का उपयोग करने का समय था और देखें कि अपडेट के दौरान एडेप्टर को पीसी क्या भेजता है।

इस प्रकार, यह समझना संभव था कि फ़र्मवेयर अपडेट प्रक्रिया कैसे होती है: पहले प्रस्तावना भेजी जाती है (कमांड 0xE1 के साथ), फिर कोड 0xE3 कमांड के साथ लिखा जाता है, फिर यह सब रिबूट (0xE8 कमांड) द्वारा पॉलिश किया जाता है। एक त्वरित और सुविधाजनक अपडेट के लिए, मैंने एक पायथन स्क्रिप्ट लिखी जो आवश्यक लाइनों को प्रस्तावना में सम्मिलित करती है, फिर चेक सोम्स पढ़ता है और डिवाइस को अपडेट करता है। अब मुझे एमुलेटर की आवश्यकता नहीं है, मुझे USB के माध्यम से ASM1051 पर फर्मवेयर अपलोड करने का अवसर मिला, आप बोर्ड को मूल रोम वापस कर सकते हैं।

निष्कर्ष

फर्मवेयर को अपडेट करने के लिए, तीन SCSI कमांड को क्रमिक रूप से निष्पादित किया जाना चाहिए: 0xE1, 0xE3 और 0xE8।

नंबर 5 पाएं

अनिर्दिष्ट कमांड के अलावा, मानक कमांड के हैंडलर्स को देखना दिलचस्प था।

रजिस्टर 0xC884 से तीसरे बिट को रजिस्टर करते हुए रजिस्टर 0x8002 के सातवें बिट पर जा रहे हैं

MODE SENSE (10) SCSI कमांड के हैंडलर में एक दिलचस्प परीक्षण है। उपरोक्त आंकड़ा फ़ंक्शन कोड का हिस्सा दिखाता है। यह देखा जा सकता है कि तीसरे बिट को 0xC884 रजिस्टर से पढ़ा जा रहा है। फिर इस बिट का मान 0x8002 रजिस्टर में सेट किया गया है।

यहां दिलचस्प बात यह है कि 0xC884 रजिस्टर को कोड में कहीं भी आरंभीकृत नहीं किया गया है, जिसका अर्थ है कि यह सबसे अधिक संभावना वाला हार्डवेयर है।

SCSI कमांड्स संदर्भ मैनुअल की तालिका 362

इसके अतिरिक्त, यदि आप 0x5A SCSI कमांड (MODE SENSE) के लिए प्रलेखन को देखते हैं, तो यह स्पष्ट हो जाता है कि USB-SATA एडाप्टर MODE SENSE अनुरोध का जवाब देना चाहिए। प्रतिक्रिया की तीसरी बाइट में WP का सातवाँ हिस्सा होता है (राइट प्रोटेक्ट - राइट प्रोटेक्शन)। वैसे, मैंने पहले से ही 0x8002 में सातवें बिट को देखा था, और यूएसबी बफर (0x8000) की शुरुआत से ऑफसेट यहां ठीक 3 है ।

निष्कर्ष:

परीक्षण किए गए USB-SATA एडाप्टर 0xC884 पर हार्डवेयर रजिस्टर से तीसरा बिट पढ़ता है और इसे USB होस्ट को WP बिट के रूप में भेजता है।

संख्या 6 ज्ञात कीजिए

MODE SENSE SCSI कमांड हैंडलर की जांच के दौरान पाया गया हार्डवेयर रजिस्टर GPIO से काफी मिलता-जुलता है। इसकी पुष्टि करने के लिए, मैंने ASM1051 पैर को लाइव रोकनेवाला के साथ छूने का फैसला किया और 0xC884 पते के साथ रजिस्टर मान (SCSI कमांड 0xE4) पढ़ा । ऐसा करने के लिए, मैंने कस्टम SCSI कमांड्स का उपयोग करके एक पायथन स्क्रिप्ट लिखी जो 0xC884 रजिस्टर में मूल्य पर नज़र रखती है और इसे पीसी पर प्रदर्शित करती है।

इस तरह के प्रयोग को करने के बाद, मैंने एक तालिका संकलित की, जिसमें मैंने दिखाया कि 0xC884 रजिस्टर में कौन से बिट्स बदल गए जब ASM1051 रोकनेवाला ने पैरों को छुआ। यह पता चला है कि अध्ययन के तहत रजिस्टर GPIO के साथ निकटता से जुड़ा हुआ है, लेकिन इसे लिखने की कोशिश (SCSI- कमांड 0xE5 के साथ) असफल थी - मान नहीं बदला।

तब मैंने फैसला किया कि यह रजिस्टर या तो केवल-पढ़ने के लिए है, या कहीं न कहीं इसे लिखना हार्डवेयर स्तर पर निषिद्ध है। यदि, उदाहरण के लिए, एमके पैर शुरू में केवल पढ़ने के लिए स्थापित किए गए थे, तो, शायद, 0xC884 रजिस्टर पर लिखना उपलब्ध नहीं हो सकता है।

सामान्य तौर पर, GPIO से जुड़े रजिस्टरों को खोजने के लिए, मैं इनिशियलाइज़ेशन कोड MK पर गया। मैंने उन सभी रजिस्टरों को लिखा है जिनके पते 0xC884 के करीब हैं। मुझे उनमें से लगभग 10 मिले। मैं आपको याद दिलाता हूं कि एमके का दसवां पैर बोर्ड पर एलईडी से जुड़ा है, यह रजिस्टर 0xC884 में दूसरे बिट से मेल खाता है । – 0880 , (, ). , , 0880 (/), 0884 , - .

0880 , 0884 . 0884 . ASM1051.

:

GPIO ASM1051. 0880 / I/O. 0884 I/O.

№ 5.

GPIO- , 45- 0884 . WP , USB. 45- , HDD, , .

HDD, 45-

. GND 45- , HDD. .

45- ASM1051 HDD.

USB-SATA-. ASM1051. , - , . , GPIO. – ASM1051 , HDD. , , (« »), , , USB-SATA- ASM1051.

, footprint ASM1051, datasheet ASM1053. , ASM1051 .

ASM1051

, 3D- , .

3D-

WP . GPIO ASM1051 , UART. , SATA, HDD. USB 3.0 Micro-B Type-C. HDD USB, HDD 3.5" +12 , 12 21 . .

निष्कर्ष

, .

-, , . « «», . , .

, (, ) embedded-. , , . , , , , .

, datasheets, , . , !

Raccoon Security – «» , , , .
, , . .