विकसकासाठी कार्य, किंवा आम्ही विक्रेत्याशिवाय हाताने पकडलेले स्कॅनर कसे फ्लॅश केले

नमस्कार.

आम्ही, व्हिक्टर अँटिपोव्ह आणि इल्या अलेशिन, आज पायथन PyUSB द्वारे USB उपकरणांसह काम करण्याच्या आमच्या अनुभवाबद्दल आणि रिव्हर्स इंजिनिअरिंगबद्दल थोडेसे बोलू.

prehistory

2019 मध्ये, रशियन फेडरेशनच्या सरकारचा डिक्री क्रमांक 224 “ओळखण्याच्या साधनांसह तंबाखू उत्पादनांवर लेबल लावण्याच्या नियमांच्या मंजुरीवर आणि वस्तूंच्या अभिसरणावर देखरेख ठेवण्यासाठी राज्य माहिती प्रणालीच्या अंमलबजावणीच्या वैशिष्ट्यांसह ओळख साधनांसह अनिवार्य लेबलिंगच्या अधीन आहे. तंबाखू उत्पादनांच्या संदर्भात” लागू झाला.
दस्तऐवज स्पष्ट करते की 1 जुलै 2019 पासून, उत्पादकांना तंबाखूच्या प्रत्येक पॅकवर लेबल लावणे आवश्यक आहे. आणि थेट वितरकांना ही उत्पादने सार्वत्रिक हस्तांतरण दस्तऐवज (UDD) च्या अंमलबजावणीसह प्राप्त करणे आवश्यक आहे. स्टोअर्स, यामधून, कॅश रजिस्टरद्वारे लेबल केलेल्या उत्पादनांच्या विक्रीची नोंदणी करणे आवश्यक आहे.

तसेच, 1 जुलै 2020 पासून, लेबल नसलेल्या तंबाखू उत्पादनांचे संचलन प्रतिबंधित आहे. याचा अर्थ असा की सर्व सिगारेट पॅक विशेष डेटामॅट्रिक्स बारकोडने चिन्हांकित करणे आवश्यक आहे. शिवाय - एक महत्त्वाचा मुद्दा - हे निष्पन्न झाले की डेटामॅट्रिक्स सामान्य नसून उलट असेल. म्हणजेच, पांढर्‍यावर काळा कोड नाही, तर उलट.

आम्ही आमच्या स्कॅनरची चाचणी केली आणि असे दिसून आले की त्यापैकी बहुतेकांना रिफ्लेश/पुन्हा प्रशिक्षित करणे आवश्यक आहे, अन्यथा ते या बारकोडसह सामान्यपणे कार्य करण्यास सक्षम नाहीत. घटनांच्या या वळणामुळे आम्हाला तीव्र डोकेदुखीची हमी मिळाली, कारण आमच्या कंपनीची बरीच स्टोअर्स आहेत जी मोठ्या प्रदेशात विखुरलेली आहेत. अनेक हजारो रोख नोंदणी – आणि खूप कमी वेळ.

काय करायचे होते? दोन पर्याय आहेत. प्रथम: ऑन-साइट अभियंते मॅन्युअली रिफ्लॅश करतात आणि स्कॅनर समायोजित करतात. दुसरे: आम्ही दूरस्थपणे कार्य करतो आणि शक्यतो एकाच पुनरावृत्तीमध्ये अनेक स्कॅनर कव्हर करतो.

पहिला पर्याय, अर्थातच, आमच्यासाठी योग्य नव्हता: आम्हाला अभियंत्यांना भेट देण्यासाठी पैसे खर्च करावे लागतील आणि या प्रकरणात प्रक्रिया नियंत्रित करणे आणि समन्वयित करणे कठीण होईल. परंतु सर्वात महत्वाची गोष्ट म्हणजे लोक काम करतील, म्हणजेच आम्हाला संभाव्यत: बर्‍याच त्रुटी मिळतील आणि बहुधा, अंतिम मुदत पूर्ण होणार नाही.

दुसरा पर्याय प्रत्येकासाठी चांगला आहे, जर एका गोष्टीसाठी नाही. काही विक्रेत्यांकडे सर्व आवश्यक ऑपरेटिंग सिस्टमसाठी आवश्यक असलेली रिमोट फ्लॅशिंग साधने नाहीत. आणि डेडलाईन संपत असल्याने मला स्वतःच्या डोक्याने विचार करावा लागला.

पुढे, आम्ही तुम्हाला डेबियन 9.x OS (आमची सर्व रोख नोंदणी डेबियनवर आहेत) साठी हाताने पकडलेल्या स्कॅनरसाठी साधने कशी विकसित केली ते सांगू.

कोडे सोडवा: स्कॅनर फ्लॅश कसा करायचा

व्हिक्टर अँटिपोव्ह सांगतात.

विक्रेत्याने प्रदान केलेली अधिकृत उपयुक्तता Windows अंतर्गत आणि फक्त IE सह कार्य करते. युटिलिटी स्कॅनर फ्लॅश आणि कॉन्फिगर करू शकते.

आमची टार्गेट सिस्टम डेबियन असल्याने, आम्ही डेबियनवर यूएसबी-रीडिरेक्टर सर्व्हर आणि विंडोजवर यूएसबी-रीडिरेक्टर क्लायंट इन्स्टॉल केले. usb-redirector युटिलिटिज वापरून, आम्ही स्कॅनरला Linux मशीनवरून Windows मशीनवर पाठवले.

विंडोज विक्रेत्याकडील युटिलिटीने स्कॅनर पाहिले आणि ते सामान्यपणे फ्लॅश केले. अशा प्रकारे, आम्ही पहिला निष्कर्ष काढला: काहीही OS वर अवलंबून नाही, ही फ्लॅशिंग प्रोटोकॉलची बाब आहे.

ठीक आहे. आम्ही विंडोज मशीनवर फ्लॅशिंग चालवले आणि लिनक्स मशीनवरील डंप काढला.

आम्ही WireShark मध्ये डंप भरला आणि... दुःखी झालो (मी डंपचे काही तपशील वगळेन, ते काही स्वारस्य नाहीत).

डंपने आम्हाला काय दाखवले:

पत्ते 0000-0030, वायरशार्कच्या न्यायाने, USB सेवा माहिती आहेत.

आम्हाला भाग 0040-0070 मध्ये स्वारस्य आहे.

एका ट्रान्समिशन फ्रेममधून MOCFT अक्षरांशिवाय काहीही स्पष्ट नव्हते. हे वर्ण फर्मवेअर फाइलमधील वर्ण आहेत, तसेच फ्रेमच्या शेवटपर्यंत उर्वरित वर्ण (फर्मवेअर फाइल हायलाइट केली आहे):

fd 3e 02 01 fe चिन्हांचा अर्थ काय आहे, मला वैयक्तिकरित्या, इल्याप्रमाणे, कल्पना नव्हती.

मी खालील फ्रेम पाहिली (सेवा माहिती येथे काढली गेली आहे, फर्मवेअर फाइल हायलाइट केली गेली आहे):

काय स्पष्ट झाले? की पहिले दोन बाइट काही प्रकारचे स्थिर आहेत. त्यानंतरच्या सर्व ब्लॉक्सनी याची पुष्टी केली, परंतु ट्रान्समिशन ब्लॉक संपण्यापूर्वी:

ही फ्रेम देखील स्तब्ध करणारी होती, कारण स्थिरांक बदलला होता (हायलाइट केलेला) आणि विचित्रपणे, फाइलचा काही भाग होता. फाइलच्या हस्तांतरित बाइट्सच्या आकारावरून 1024 बाइट्स हस्तांतरित झाल्याचे दिसून आले. मला पुन्हा उरलेल्या बाइट्सचा अर्थ कळला नाही.

सर्व प्रथम, जुने बीबीएस टोपणनाव म्हणून, मी मानक ट्रान्समिशन प्रोटोकॉलचे पुनरावलोकन केले. 1024 बाइट प्रसारित केलेला कोणताही प्रोटोकॉल नाही. मी हार्डवेअरचा अभ्यास करण्यास सुरुवात केली आणि 1K Xmodem प्रोटोकॉलमध्ये आलो. याने 1024 प्रसारित करण्याची परवानगी दिली, परंतु सावधगिरीने: प्रथम फक्त 128, आणि केवळ त्रुटी नसल्यास, प्रोटोकॉलने प्रसारित बाइट्सची संख्या वाढवली. माझ्याकडे लगेच १०२४ बाइट्सचे हस्तांतरण झाले. मी ट्रान्समिशन प्रोटोकॉल आणि विशेषतः एक्स-मॉडेमचा अभ्यास करण्याचा निर्णय घेतला.

मोडेमचे दोन प्रकार होते.

प्रथम, CRC8 समर्थनासह XMODEM पॅकेज स्वरूप (मूळ XMODEM):

दुसरे म्हणजे, CRC16 समर्थन (XmodemCRC) सह XMODEM पॅकेट स्वरूप:

SOH, पॅकेज नंबर आणि CRC आणि पॅकेजची लांबी वगळता हे समान दिसते.

मी दुसऱ्या ट्रान्समिशन ब्लॉकच्या सुरूवातीस पाहिले (आणि पुन्हा फर्मवेअर फाइल पाहिली, परंतु आधीच 1024 बाइट्सने इंडेंट केलेली):

मी परिचित हेडर fd 3e 02 पाहिले, परंतु पुढील दोन बाइट्स आधीच बदलले होते: ते 01 fe होते, आणि 02 fd झाले. मग माझ्या लक्षात आले की दुसरा ब्लॉक आता 02 क्रमांकावर आहे आणि अशा प्रकारे मला समजले: माझ्या समोर ट्रान्समिशन ब्लॉकची संख्या होती. पहिला 1024 गियर 01 आहे, दुसरा 02 आहे, तिसरा 03 आहे आणि असेच (परंतु हेक्समध्ये, नक्कीच). पण fe ते fd बदल म्हणजे काय? डोळ्यांनी 1 ने घट पाहिली, मेंदूने आठवण करून दिली की प्रोग्रामर 0 वरून मोजतात, 1 नाही. पण मग पहिला ब्लॉक 1 का आहे, 0 नाही? मला अजूनही या प्रश्नाचे उत्तर सापडलेले नाही. पण मला समजले की दुसरा ब्लॉक कसा मोजला जातो. दुसरा ब्लॉक FF - (वजा) पहिल्या ब्लॉकच्या संख्येपेक्षा अधिक काही नाही. अशा प्रकारे, दुसरा ब्लॉक = 02 (FF-02) = 02 FD म्हणून नियुक्त केला गेला. डंपच्या नंतरच्या वाचनाने माझ्या अंदाजाची पुष्टी केली.

त्यानंतर ट्रान्समिशनचे खालील चित्र दिसू लागले:

प्रसारणाची सुरुवात
fd 3e 02 - प्रारंभ करा
01 FE - ट्रान्समिशन काउंटर
हस्तांतरण (34 ब्लॉक, 1024 बाइट हस्तांतरित)
fd 3e 1024 बाइट्स डेटा (30 बाइट ब्लॉक्समध्ये विभागलेला).
प्रसारण समाप्त
fd 25

उर्वरित डेटा 1024 बाइटशी संरेखित करायचा आहे.

ब्लॉक ट्रांसमिशन एंड फ्रेम कशी दिसते:

fd 25 - ब्लॉक ट्रांसमिशन समाप्त करण्यासाठी सिग्नल. पुढील 2f 52 - उर्वरित फाइल 1024 बाइट्स पर्यंत आकारात आहे. 2f 52, प्रोटोकॉलनुसार, 16-बिट CRC चेकसम आहे.

जुन्या काळासाठी, मी C मध्ये एक प्रोग्राम बनवला ज्याने फाइलमधून 1024 बाइट्स काढले आणि 16-बिट CRC ची गणना केली. हा 16-बिट सीआरसी नाही हे प्रोग्रॅम लाँच केल्याने दिसून आले. पुन्हा स्तब्ध - सुमारे तीन दिवस. हा सर्व वेळ मी चेकसम नसल्यास काय असू शकते हे समजून घेण्याचा प्रयत्न करत होतो. इंग्रजी-भाषेच्या साइट्सचा अभ्यास करताना, मला आढळले की एक्स-मॉडेम स्वतःची चेकसम गणना वापरते - CRC-CCITT (XModem). मला या गणनेची कोणतीही C अंमलबजावणी आढळली नाही, परंतु मला एक साइट सापडली ज्याने या चेकसमची ऑनलाइन गणना केली. माझ्या फाइलचे 1024 बाइट्स वेब पृष्ठावर हस्तांतरित केल्यावर, साइटने मला एक चेकसम दाखवला जो फाइलमधील चेकसमशी पूर्णपणे जुळतो.

हुर्रे! शेवटचे कोडे सोडवले गेले, आता मला माझे स्वतःचे फर्मवेअर बनवायचे आहे. पुढे, मी माझे ज्ञान (आणि ते फक्त माझ्या डोक्यातच राहिले) इल्याकडे दिले, जो Python या शक्तिशाली टूलकिटशी परिचित आहे.

एक कार्यक्रम तयार करणे

इल्या अलेशिन सांगतात.

योग्य सूचना मिळाल्यामुळे, मी खूप “आनंदी” झालो.

कुठून सुरुवात करायची? बरोबर आहे, सुरुवातीपासून.  यूएसबी पोर्टवरून डंप घेण्यापासून.

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:PID द्वारे शोधू शकता.

हे असे दिसते:

तर, आमच्याकडे आवश्यक माहिती आहे: P_INFO कमांड. किंवा DEFALT, कमांड्स एंडपॉइंट=03 कुठे लिहायच्या आणि एंडपॉइंट=86 प्रतिसाद कुठे मिळवायचा हे पत्ते. फक्त कमांड्स हेक्समध्ये रूपांतरित करणे बाकी आहे.

आम्हाला डिव्हाइस आधीच सापडले असल्याने, ते कर्नलमधून डिस्कनेक्ट करूया...

...आणि शेवटच्या बिंदूवर 0x03 पत्त्यासह लिहा,

... आणि नंतर पत्ता 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 मध्ये पाहतो.

छान! सिस्टम बारकोड हेक्समध्ये रूपांतरित करा. तेच, प्रशिक्षण कार्यक्षमता तयार आहे.

फर्मवेअर बद्दल काय? सर्व काही समान असल्याचे दिसते, परंतु एक सूक्ष्मता आहे.

फ्लॅशिंग प्रक्रियेचा संपूर्ण डंप घेतल्यावर, आम्ही काय हाताळत आहोत हे आम्हाला अंदाजे समजले. येथे XMODEM बद्दलचा एक लेख आहे, जो सामान्य शब्दात असला तरीही हा संवाद कसा होतो हे समजून घेण्यासाठी खूप उपयुक्त होता: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html मी ते वाचण्याची शिफारस करतो.

डंपकडे पाहताना, आपण पाहू शकता की फ्रेमचा आकार 1024 आहे आणि URB-डेटा आकार 64 आहे.

म्हणून - 1024/64 - आम्हाला एका ब्लॉकमध्ये 16 ओळी मिळतात, फर्मवेअर फाइल एका वेळी 1 कॅरेक्टर वाचा आणि ब्लॉक तयार करा. विशेष अक्षरे fd1e3 + ब्लॉक क्रमांक असलेल्या ब्लॉकमध्ये 02 ओळ पूरक करणे.
पुढील 14 ओळी fd25 + सह पूरक आहेत, XMODEM.calc_crc() वापरून आम्ही संपूर्ण ब्लॉकच्या चेकसमची गणना करतो (“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