विकासकर्ताको लागि एउटा कार्य, वा हामीले कसरी विक्रेता बिना ह्यान्ड-होल्ड स्क्यानरहरू फ्ल्यास गर्यौं

सबैलाई नमस्कार।

हामी, Viktor Antipov र Ilya Aleshin, आज Python PyUSB मार्फत USB यन्त्रहरूसँग काम गर्ने हाम्रो अनुभव र रिभर्स इन्जिनियरिङको बारेमा कुरा गर्नेछौं।

प्रागितिहास

2019 मा, रूसी संघ नम्बर 224 को सरकारको डिक्री "पहिचानको माध्यम र अनिवार्य लेबलिंगको अधीनमा वस्तुहरूको परिसंचरण अनुगमनको लागि राज्य सूचना प्रणालीको कार्यान्वयनको पहिचान साधन र सुविधाहरूको साथ सुर्तिजन्य उत्पादनहरू लेबल गर्ने नियमहरूको स्वीकृतिमा। सुर्तीजन्य पदार्थको सम्बन्धमा" लागू भयो।
कागजातले बताउँछ कि जुलाई १, २०१९ देखि, निर्माताहरूले सुर्तीको प्रत्येक प्याकलाई लेबल गर्न आवश्यक छ। र प्रत्यक्ष वितरकहरूले यी उत्पादनहरू विश्वव्यापी स्थानान्तरण कागजात (UDD) को कार्यान्वयनको साथ प्राप्त गर्नुपर्छ। पसलहरू, बारीमा, नगद दर्ता मार्फत लेबल गरिएका उत्पादनहरूको बिक्री दर्ता गर्न आवश्यक छ।

साथै, जुलाई 1, 2020 देखि, लेबल बिना सुर्तिजन्य उत्पादनहरूको सर्कुलेशन निषेध गरिएको छ। यसको मतलब सबै सिगरेट प्याकहरू विशेष डाटामैट्रिक्स बारकोडको साथ चिन्ह लगाइएको हुनुपर्छ। यसबाहेक - एक महत्त्वपूर्ण बिन्दु - यो पत्ता लाग्यो कि Datamatrix साधारण हुनेछैन, तर उल्टो। त्यो हो, सेतोमा कालो कोड होइन, तर उल्टो।

हामीले हाम्रा स्क्यानरहरू परीक्षण गर्‍यौं, र यो पत्ता लाग्यो कि तिनीहरूमध्ये धेरैलाई रिफ्ल्याश/रिट्रेन गर्न आवश्यक छ, अन्यथा तिनीहरू यस बारकोडसँग सामान्य रूपमा काम गर्न सक्षम छैनन्। घटनाहरूको यो मोडले हामीलाई गम्भीर टाउको दुखाइको ग्यारेन्टी दियो, किनभने हाम्रो कम्पनीसँग धेरै पसलहरू छन् जुन विशाल क्षेत्रमा छरिएका छन्। हजारौं नगद दर्ताहरू - र धेरै थोरै समय।

के गर्नु पर्ने थियो ? त्यहाँ दुई विकल्प छन्। पहिलो: साइटमा इन्जिनियरहरूले म्यानुअल रूपमा स्क्यानरहरू रिफ्ल्याश र समायोजन गर्छन्। दोस्रो: हामी टाढैबाट काम गर्छौं र, अधिमानतः, धेरै स्क्यानरहरू एकै पटकमा एक पटकमा कभर गर्छौं।

पहिलो विकल्प, स्पष्ट रूपमा, हाम्रो लागि उपयुक्त थिएन: हामीले इन्जिनियरहरू भ्रमण गर्न पैसा खर्च गर्नुपर्नेछ, र यस अवस्थामा यो प्रक्रिया नियन्त्रण र समन्वय गर्न गाह्रो हुनेछ। तर सबैभन्दा महत्त्वपूर्ण कुरा यो हो कि मानिसहरूले काम गर्नेछन्, त्यो हो, हामीले सम्भावित रूपमा धेरै त्रुटिहरू पाउनेछौं र सम्भवतः समयसीमा पूरा गर्दैनौं।

दोस्रो विकल्प सबैको लागि राम्रो छ, यदि एक चीजको लागि होइन। केही विक्रेताहरूसँग हामीले सबै आवश्यक अपरेटिङ सिस्टमहरूको लागि आवश्यक रिमोट फ्ल्यासिङ उपकरणहरू थिएनन्। र समयसीमा सकिँदै गएपछि, मैले आफ्नै टाउकोले सोच्नुपर्‍यो।

अर्को, हामी तपाईंलाई डेबियन 9.x OS (हाम्रा सबै नगद दर्ताहरू डेबियनमा छन्) को लागि ह्यान्ड-होल्ड स्क्यानरहरूका लागि उपकरणहरू कसरी विकास गर्यौं भनेर बताउनेछौं।

पहेली हल गर्नुहोस्: कसरी स्क्यानर फ्लैश गर्ने

भिक्टर Antipov रिपोर्ट।

विक्रेता द्वारा प्रदान गरिएको आधिकारिक उपयोगिता Windows अन्तर्गत काम गर्दछ, र केवल IE को साथ। उपयोगिताले स्क्यानरलाई फ्ल्यास र कन्फिगर गर्न सक्छ।

हाम्रो लक्ष्य प्रणाली डेबियन भएकोले, हामीले डेबियनमा USB-पुनर्निर्देशक सर्भर र Windows मा USB-पुनर्निर्देशक क्लाइन्ट स्थापना गर्यौं। USB-Redirector उपयोगिताहरू प्रयोग गरेर, हामीले स्क्यानरलाई लिनक्स मेसिनबाट Windows मेसिनमा फर्वार्ड गर्यौं।

विन्डोज विक्रेताको उपयोगिताले स्क्यानर देख्यो र यसलाई सामान्य रूपमा फ्ल्यास पनि गर्‍यो। यसरी, हामीले पहिलो निष्कर्ष निकाल्यौं: केहि पनि OS मा निर्भर गर्दैन, यो फ्ल्याशिंग प्रोटोकलको कुरा हो।

ठिक छ। हामीले विन्डोज मेसिनमा फ्ल्यासिङ चलायौं, र लिनक्स मेसिनमा डम्प हटायौं।

हामीले WireShark मा डम्प भर्यौं र... दुःखी भयो (म डम्पको केही विवरणहरू छोड्नेछु, तिनीहरू कुनै चासोको छैनन्)।

डम्पले हामीलाई के देखायो:

ठेगानाहरू 0000-0030, Wireshark द्वारा न्याय गर्दै, USB सेवा जानकारी हो।

हामी भाग 0040-0070 मा रुचि राखेका थियौं।

MOCFT क्यारेक्टरहरू बाहेक एउटा प्रसारण फ्रेमबाट केही पनि स्पष्ट थिएन। यी क्यारेक्टरहरू फर्मवेयर फाइलबाट क्यारेक्टरहरू, साथै फ्रेमको अन्त्यसम्म बाँकी क्यारेक्टरहरू (फर्मवेयर फाइल हाइलाइट गरिएको छ):

fd 3e 02 01 fe प्रतीकहरूको अर्थ के हो, मलाई व्यक्तिगत रूपमा, इल्या जस्तै, थाहा थिएन।

मैले निम्न फ्रेममा हेरे (सेवा जानकारी यहाँ हटाइएको छ, फर्मवेयर फाइल हाइलाइट गरिएको छ):

के प्रष्ट भयो ? कि पहिलो दुई बाइटहरू कुनै प्रकारको स्थिर छन्। सबै पछिल्ला ब्लकहरूले यो पुष्टि गरे, तर प्रसारण ब्लकको अन्त्य हुनु अघि:

यो फ्रेम पनि स्तब्ध थियो, किनकि स्थिर परिवर्तन भएको थियो (हाइलाइट गरिएको) र, अनौठो रूपमा, त्यहाँ फाइलको अंश थियो। फाइलको स्थानान्तरण गरिएको बाइटको साइजले देखाउँछ कि 1024 बाइटहरू स्थानान्तरण गरिएको थियो। मलाई फेरि थाहा थिएन कि बाँकी बाइट्सको अर्थ के हो।

सबैभन्दा पहिले, पुरानो BBS उपनामको रूपमा, मैले मानक प्रसारण प्रोटोकलहरू समीक्षा गरें। कुनै प्रोटोकल 1024 बाइट प्रसारित छैन। मैले हार्डवेयर अध्ययन गर्न थालें र 1K Xmodem प्रोटोकलमा आएँ। यसले 1024 प्रसारण गर्न अनुमति दियो, तर एक चेतावनीको साथ: सुरुमा मात्र 128, र यदि त्यहाँ कुनै त्रुटिहरू थिएनन् भने, प्रोटोकलले प्रसारित बाइटहरूको संख्या बढायो। मसँग तुरुन्तै १०२४ बाइटको स्थानान्तरण थियो। मैले ट्रान्समिशन प्रोटोकलहरू, र विशेष गरी एक्स-मोडेम अध्ययन गर्ने निर्णय गरें।

त्यहाँ मोडेमको दुई भिन्नताहरू थिए।

पहिलो, XMODEM प्याकेज ढाँचा CRC8 समर्थनको साथ (मूल XMODEM):

दोस्रो, XMODEM प्याकेट ढाँचा CRC16 समर्थन (XmodemCRC):

यो समान देखिन्छ, SOH, प्याकेज नम्बर र CRC र प्याकेज लम्बाइ बाहेक।

मैले दोस्रो ट्रान्समिशन ब्लकको सुरुमा हेरे (र फेरि फर्मवेयर फाइल देखे, तर पहिले नै 1024 बाइट्स द्वारा इन्डेन्ट गरिएको):

मैले परिचित हेडर fd 3e 02 देखे, तर अर्को दुई बाइटहरू पहिले नै परिवर्तन भइसकेका थिए: यो 01 fe थियो, र 02 fd भयो। त्यसपछि मैले याद गरें कि दोस्रो ब्लक अब ०२ नम्बरमा थियो र यसरी बुझे: मेरो अगाडि ट्रान्समिशन ब्लकको नम्बरिंग थियो। पहिलो 02 गियर 1024 हो, दोस्रो 01 हो, तेस्रो 02 हो र यस्तै अन्य (तर हेक्समा, अवश्य पनि)। तर fe बाट fd मा परिवर्तनको अर्थ के हो? आँखाले १ ले घटेको देख्यो, मस्तिष्कले याद दिलायो कि प्रोग्रामरहरू ० बाट गणना गर्छन्, १ होइन। तर त्यसो भए किन पहिलो ब्लक १, ० होइन? मैले यो प्रश्नको उत्तर अझै फेला पारेको छैन। तर मैले बुझें कि दोस्रो ब्लक कसरी गणना गरिन्छ। दोस्रो ब्लक FF - (माइनस) पहिलो ब्लकको संख्या भन्दा बढी छैन। यसरी, दोस्रो ब्लक = ०२ (FF-03) = ०२ FD को रूपमा तोकिएको थियो। डम्पको पछिल्ला पढाइले मेरो अनुमानलाई पुष्टि गर्यो।

त्यसपछि प्रसारणको निम्न चित्र देखा पर्न थाल्यो:

प्रसारणको सुरुवात
fd 3e 02 - सुरु गर्नुहोस्
01 FE - प्रसारण काउन्टर
स्थानान्तरण (३४ ब्लक, १०२४ बाइट हस्तान्तरण)
fd 3e 1024 बाइट डाटा (30 बाइट ब्लकहरूमा विभाजित)।
प्रसारणको अन्त्य
fd 25

1024 बाइटहरूमा पङ्क्तिबद्ध गर्न बाँकी डाटा।

ब्लक प्रसारण अन्त फ्रेम कस्तो देखिन्छ:

fd 25 - ब्लक प्रसारण समाप्त गर्न संकेत। अर्को 2f 52 - फाइलको बाँकी 1024 बाइट सम्म साइजमा। 2f 52, प्रोटोकल द्वारा न्याय गर्दै, एक 16-बिट CRC चेकसम हो।

पुरानो समयको लागि, मैले C मा एउटा प्रोग्राम बनाएको छु जसले फाइलबाट 1024 बाइटहरू तान्यो र 16-बिट CRC गणना गर्यो। कार्यक्रम सुरु गर्दा यो 16-बिट CRC होइन भनेर देखियो। स्तब्ध फेरि - लगभग तीन दिनको लागि। यो सबै समय म यो के हुन सक्छ भनेर बुझ्न कोशिस गर्दै थिए, यदि चेकसम होइन। अङ्ग्रेजी-भाषा साइटहरू अध्ययन गर्दा, मैले एक्स-मोडेमले आफ्नै चेकसम गणना - CRC-CCITT (XModem) प्रयोग गरेको पत्ता लगाए। मैले यो गणनाको कुनै C कार्यान्वयन फेला पारेन, तर मैले यो चेकसम अनलाइन गणना गर्ने साइट फेला पारे। मेरो फाइलको 1024 बाइटहरू वेब पृष्ठमा स्थानान्तरण गरिसकेपछि, साइटले मलाई एउटा चेकसम देखायो जुन फाइलबाट चेकसमसँग पूर्ण रूपमा मेल खान्छ।

हुर्रे! अन्तिम पहेली हल भयो, अब मलाई आफ्नै फर्मवेयर बनाउन आवश्यक छ। त्यसपछि, मैले मेरो ज्ञान (र यो मेरो टाउकोमा मात्र रह्यो) इल्यालाई दिएँ, जो शक्तिशाली टुलकिट पाइथनसँग परिचित छन्।

कार्यक्रम सिर्जना गर्दै

इल्या अलेसिन रिपोर्ट गर्दछ।

उपयुक्त निर्देशनहरू पाएपछि, म धेरै "खुसी" भएँ।

कहाँ सुरु गर्ने? त्यो ठीक हो, सुरु देखि।  USB पोर्टबाट डम्प लिनबाट।

USB-pcap सुरु गर्नुहोस् https://desowin.org/usbpcap/tour.html

पोर्ट चयन गर्नुहोस् जसमा उपकरण जडान गरिएको छ र फाइल जहाँ हामी डम्प बचत गर्नेछौं।

हामी स्क्यानरलाई मेसिनमा जडान गर्छौं जहाँ Windows को लागि नेटिभ EZConfigScanning सफ्टवेयर स्थापना गरिएको छ।

यसमा हामी यन्त्रमा आदेशहरू पठाउनको लागि वस्तु फेला पार्छौं। तर टोलीहरूको बारेमा के हो? म तिनीहरूलाई कहाँ पाउन सक्छु?
जब कार्यक्रम सुरु हुन्छ, उपकरण स्वचालित रूपमा पोल हुन्छ (हामी यसलाई केहि पछि देख्नेछौं)। र त्यहाँ आधिकारिक उपकरण कागजातहरूबाट प्रशिक्षण बारकोडहरू थिए। DEFALT। यो हाम्रो टोली हो।

आवश्यक तथ्यांक प्राप्त भएको छ । wireshark मार्फत dump.pcap खोल्नुहोस्।

EZConfigScanning सुरु गर्दा रोक लगाउनुहोस्। तपाईंले ध्यान दिनु पर्ने ठाउँहरू रातोमा चिन्ह लगाइएका छन्।

यो सब पहिलो पटक देख्दा मन हार्यो । अब कहाँ खन्ने भन्ने स्पष्ट छैन।

अलिकति मंथन र-र-र... आहा! डम्पमा बाहिर - यो inर in यसलाई बाहिर.

मैले URB_INTERRUPT भनेको के हो भनेर गुगल गरें। मैले थाहा पाए कि यो डाटा ट्रान्सफर विधि हो। र त्यहाँ 4 यस्ता विधिहरू छन्: नियन्त्रण, अवरोध, आइसोक्रोनस, बल्क। तपाईं तिनीहरूको बारेमा छुट्टै पढ्न सक्नुहुन्छ।

र USB यन्त्र इन्टरफेसमा अन्तिम बिन्दु ठेगानाहरू "lsusb –v" आदेश वा pyusb प्रयोग गरेर प्राप्त गर्न सकिन्छ।

अब हामीले यो VID भएका सबै यन्त्रहरू फेला पार्न आवश्यक छ। तपाइँ विशेष गरी VID:PID द्वारा खोजी गर्न सक्नुहुन्छ।

यो यो जस्तो देखिन्छ:

त्यसैले, हामीसँग आवश्यक जानकारी छ: P_INFO आदेशहरू। वा DEFALT, ठेगानाहरू कहाँ लेख्ने आदेशहरू endpoint=03 र कहाँ प्रतिक्रिया endpoint=86 प्राप्त गर्ने। बाँकी सबै आदेशहरूलाई हेक्समा रूपान्तरण गर्न हो।

हामीले पहिले नै यन्त्र फेला पारेको हुनाले, यसलाई कर्नेलबाट विच्छेद गरौं...

...र ठेगाना ०x०३ को साथ अन्तिम बिन्दुमा लेख्नुहोस्,

... र त्यसपछि ठेगाना 0x86 को साथ अन्तिम बिन्दुबाट प्रतिक्रिया पढ्नुहोस्।

संरचित उत्तर:

P_INFOfmt: 1
mode: app
app-present: 1
boot-present: 1
hw-sn: 18072B44CA
hw-rev: 0x20
cbl: 4
app-sw-rev: CP000116BBA
boot-sw-rev: CP000014BAD
flash: 3
app-m_name: Voyager 1450g
boot-m_name: Voyager 1450g
app-p_name: 1450g
boot-p_name: 1450g
boot-time: 16:56:02
boot-date: Oct 16 2014
app-time: 08:49:30
app-date: Mar 25 2019
app-compat: 289
boot-compat: 288
csum: 0x6986

हामी यो डाटा dump.pcap मा देख्छौं।

महान! प्रणाली बारकोडहरूलाई हेक्समा रूपान्तरण गर्नुहोस्। त्यो हो, प्रशिक्षण कार्यक्षमता तयार छ।

फर्मवेयरको बारेमा के हो? सबै कुरा उस्तै देखिन्छ, तर त्यहाँ एक nuance छ।

फ्ल्यासिङ प्रक्रियाको पूर्ण डम्प लिइसकेपछि, हामीले केसँग व्यवहार गरिरहेका थियौं भन्ने कुरा हामीले लगभग बुझ्यौं। यहाँ XMODEM को बारेमा एउटा लेख छ, जुन यो संचार कसरी हुन्छ भनेर बुझ्न धेरै सहयोगी थियो, यद्यपि सामान्य सर्तहरूमा: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html म यसलाई पढ्न सिफारिस गर्दछु।

डम्पमा हेर्दै, तपाईंले फ्रेम आकार 1024 हो, र URB-डेटा आकार 64 हो भनेर देख्न सक्नुहुन्छ।

त्यसैले - 1024/64 - हामी एक ब्लकमा 16 लाइनहरू पाउँछौं, फर्मवेयर फाइल 1 क्यारेक्टर एक समयमा पढ्नुहोस् र ब्लक बनाउनुहोस्। विशेष क्यारेक्टरहरू fd1e3 + ब्लक नम्बर भएको ब्लकमा 02 रेखा पूरक।
XMODEM.calc_crc() को प्रयोग गरेर अर्को 14 लाइनहरू fd25 + को साथ पूरक छन्, हामी सम्पूर्ण ब्लकको चेकसम गणना गर्छौं (“FF – 1” CSUM हो भनेर बुझ्न धेरै समय लाग्यो) र अन्तिम, 16 औं लाइन पूरक छ। fd3e सँग।

यस्तो देखिन्छ, फर्मवेयर फाइल पढ्नुहोस्, ब्लकहरू हिट गर्नुहोस्, कर्नेलबाट स्क्यानर विच्छेद गर्नुहोस् र यसलाई उपकरणमा पठाउनुहोस्। तर यो त्यति सरल छैन। स्क्यानर फर्मवेयर मोडमा स्विच गर्न आवश्यक छ,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
यो टिम कहाँको हो?? डम्पबाट।

तर हामी 64 सीमाको कारणले स्क्यानरमा पूरै ब्लक पठाउन सक्दैनौं:

खैर, NEWAPP फ्ल्यासिङ मोडमा स्क्यानरले हेक्स स्वीकार गर्दैन। त्यसकारण, तपाईंले प्रत्येक लाइन bytes_array अनुवाद गर्नुपर्नेछ

[253, 10, 22, 78, 44, 78, 69, 87, 65, 80, 80, 13, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

र त्यसपछि यो डाटा स्क्यानरमा पठाउनुहोस्।

हामीले जवाफ पाउँछौं:

[2, 1, 0, 0, 0, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

यदि तपाईंले XMODEM को बारेमा लेख जाँच गर्नुभयो भने, यो स्पष्ट हुनेछ: डाटा स्वीकार गरिएको छ।

सबै ब्लकहरू स्थानान्तरण गरिसकेपछि, हामी स्थानान्तरण पूरा गर्छौं END_TRANSFER = 'xfdx01x04'।

ठिक छ, किनकि यी ब्लकहरूले साधारण मानिसहरूको लागि कुनै जानकारी बोक्दैन, हामी पूर्वनिर्धारित रूपमा लुकेको मोडमा फर्मवेयर स्थापना गर्नेछौं। र केवल केसमा, हामी tqdm मार्फत प्रगति पट्टी व्यवस्थित गर्नेछौं।

वास्तवमा, त्यसपछि यो साना चीजहरूको कुरा हो। बाँकी रहेको कुरा भनेको स्पष्ट रूपमा परिभाषित समयमा सामूहिक प्रतिकृतिको लागि स्क्रिप्टहरूमा समाधान बेर्नु हो, ताकि चेकआउटहरूमा काम गर्ने प्रक्रियालाई ढिलो नगर्नुहोस्, र लगिङ थप्नुहोस्।

परिणाम

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

स्रोत: www.habr.com