هڪ ڊولپر لاءِ هڪ ڪم، يا ڪيئن اسان هٿ ۾ رکيل اسڪينر کي بغير ڪنهن وينڊر جي فليش ڪيو

سڀني کي سلام.

اسان، Viktor Antipov ۽ Ilya Aleshin، اڄ Python PyUSB ذريعي USB ڊوائيسز سان ڪم ڪرڻ جي اسان جي تجربي بابت ۽ ٿورڙو ريورس انجنيئرنگ بابت ڳالهائينداسين.

prehistory

2019 ۾، روسي فيڊريشن جي حڪومت جو فرمان نمبر 224 "تمام تمباکو جي شين جي ليبلنگ جي ضابطن جي منظوري تي سڃاڻپ جي ذريعن ۽ خاصيتن سان گڏ سامان جي گردش جي نگراني لاء رياستي معلوماتي نظام جي عمل جي خاصيتن جي سڃاڻپ جي ذريعن سان لازمي ليبلنگ جي تابع. تمباکو جي شين جي سلسلي ۾" عمل ۾ آيو.
دستاويز بيان ڪري ٿو ته 1 جولاء 2019 کان، ٺاهيندڙن کي تمباکو جي هر پيڪ کي ليبل ڪرڻ جي ضرورت آهي. ۽ سڌو ورهائيندڙن کي لازمي طور تي اهي پراڊڪٽس هڪ عالمگير منتقلي دستاويز (UDD) جي عمل سان حاصل ڪرڻ گهرجن. اسٽور، موڙ ۾، نقد رجسٽر ذريعي ليبل ٿيل شين جي وڪرو کي رجسٽر ڪرڻ جي ضرورت آهي.

گڏوگڏ، جولاء 1، 2020 کان، بغير ليبل ٿيل تمباکو جي شين جي گردش منع ٿيل آهي. هن جو مطلب اهو آهي ته سڀني سگريٽ پيڪ کي خاص Datamatrix بارڪوڊ سان نشان لڳايو وڃي. ان کان سواء - هڪ اهم نقطو - اهو نڪتو ته Datamatrix عام نه ٿيندو، پر ان جي ابتڙ. اھو آھي، اڇي تي ڪارو ڪوڊ نه، پر ان جي برعڪس.

اسان پنهنجي اسڪينر کي آزمايو، ۽ اهو ظاهر ٿيو ته انهن مان گھڻا کي ٻيهر فليش ڪرڻ / ٻيهر تربيت ڏيڻ جي ضرورت آهي، ٻي صورت ۾ اهي هن بارڪوڊ سان عام طور تي ڪم ڪرڻ جي قابل نه هوندا. واقعن جو اهو موڙ اسان کي سخت سر درد جي ضمانت ڏئي ٿو، ڇاڪاڻ ته اسان جي ڪمپني جا ڪيترائي اسٽور آهن جيڪي وسيع علائقي تي پکڙيل آهن. ڪيترائي هزارين نقد رجسٽر - ۽ تمام ٿورو وقت.

ڇا ٿيڻو هو؟ اتي ٻه آپشن آهن. پهريون: سائيٽ تي انجنيئر دستي طور تي ريفليش ۽ اسڪينرز کي ترتيب ڏيو. ٻيو: اسان دور کان ڪم ڪريون ٿا ۽، ترجيحي طور تي، ڪيترن ئي اسڪينر کي هڪ ئي وقت ۾ ڍڪيندا آهيون.

پهريون اختيار، ظاهر آهي، اسان لاء مناسب نه هو: اسان کي انجنيئرن جو دورو ڪرڻ تي پئسا خرچ ڪرڻو پوندو، ۽ انهي صورت ۾ ان کي ڪنٽرول ڪرڻ ۽ عمل کي منظم ڪرڻ ڏکيو ٿيندو. پر سڀ کان اهم شيء اها آهي ته ماڻهو ڪم ڪن ها، اهو آهي ته، اسان ممڪن طور تي تمام گهڻيون غلطيون حاصل ڪنداسين ۽ گهڻو ڪري، آخري حد تائين نه ملندا.

ٻيو اختيار هر ڪنهن لاء سٺو آهي، جيڪڏهن هڪ شيء لاء نه. ڪجهه وينڊرز وٽ ريموٽ چمڪندڙ اوزار نه هئا جيڪي اسان کي گهربل آپريٽنگ سسٽم لاءِ گهربل هئا. ۽ جڏهن کان آخري وقت ختم ٿي رهيو هو، مون کي پنهنجي سر سان سوچڻو پيو.

اڳيون، اسان توهان کي ٻڌائينداسين ته اسان ڪيئن ٺاهيا اوزار هٿ ۾ رکيل اسڪينر لاءِ Debian 9.x OS لاءِ (اسان جا سڀ ڪيش رجسٽر ڊيبين تي آهن).

پہیلی حل ڪريو: اسڪينر کي ڪيئن چمڪيو

وڪٽر انٽيپوف رپورٽ ڪري ٿو.

وينڊر پاران مهيا ڪيل سرڪاري افاديت ونڊوز جي تحت ڪم ڪري ٿي، ۽ صرف IE سان. افاديت اسڪينر کي چمڪي ۽ ترتيب ڏئي سگھي ٿي.

جيئن ته اسان جو ٽارگيٽ سسٽم ڊيبين آهي، اسان ڊيبين تي يو ايس بي ريڊريڪٽر سرور ۽ ونڊوز تي يو ايس بي ريڊريڪٽر ڪلائنٽ نصب ڪيو. usb-redirector افاديت استعمال ڪندي، اسان اسڪينر کي لينڪس مشين کان ونڊوز مشين ڏانهن موڪليو.

ونڊوز لاءِ وينڊر جي افاديت اسڪينر کي ڏٺو ۽ ان کي عام طور تي چمڪيو. اهڙيء طرح، اسان پهريون نتيجو ڪيو: ڪجھ به OS تي منحصر ناهي، اهو چمڪندڙ پروٽوڪول جو معاملو آهي.

ٺيڪ. اسان ونڊوز مشين تي چمڪايو، ۽ لينڪس مشين تي ڊمپ کي هٽايو.

اسان ڊمپ کي وائر شارڪ ۾ ڀريو ۽ ... اداس ٿي ويا (مان ڊمپ جي ڪجهه تفصيلن کي ڇڏي ڏيندس، اهي ڪنهن به دلچسپي جي نه آهن).

ڊمپ اسان کي ڇا ڏيکاريو:

ايڊريس 0000-0030، وائر شارڪ پاران فيصلو ڪندي، يو ايس بي سروس جي معلومات آهن.

اسان حصو 0040-0070 ۾ دلچسپي وٺندا هئاسين.

MOCFT اکرن کانسواءِ ھڪڙي ٽرانسميشن فريم مان ڪجھ به واضح نه ھو. اهي ڪردار فرم ویئر فائل مان ڪردارن مان نڪرندا آهن، انهي سان گڏ باقي ڪردار فريم جي آخر تائين (فرم ویئر فائل نمايان ٿيل آهي):

fd 3e 02 01 fe جي علامتن جو ڇا مطلب آهي، مون کي ذاتي طور تي، اليا وانگر، ڪا به خبر نه هئي.

مون ھيٺ ڏنل فريم کي ڏٺو (خدمت جي معلومات ھتي ختم ڪئي وئي آھي، فرم ویئر فائل کي نمايان ڪيو ويو آھي):

ڇا پڌرو ٿيو؟ ته پھريون ٻه بائٽس ڪجھ مستقل آھن. سڀ ايندڙ بلاڪ هن جي تصديق ڪئي، پر ٽرانسميشن بلاڪ جي آخر کان اڳ:

اهو فريم پڻ بيوقوف هو، ڇاڪاڻ ته مسلسل تبديل ٿي چڪو هو (نمايان) ۽، عجيب ڪافي، فائل جو حصو هو. فائل جي منتقل ٿيل بائيٽ جي ماپ ڏيکاري ٿي ته 1024 بائيٽ منتقل ڪيا ويا. مون کي ٻيهر خبر نه هئي ته باقي بائيٽس جو مطلب ڇا آهي.

سڀ کان پهريان، هڪ پراڻي BBS جي نالي سان، مون جائزو ورتو معياري ٽرانسميشن پروٽوڪول. ڪوبه پروٽوڪول 1024 بائيٽ منتقل نه ڪيو ويو. مون هارڊويئر پڙهڻ شروع ڪيو ۽ 1K Xmodem پروٽوڪول ۾ آيو. اهو 1024 کي منتقل ڪرڻ جي اجازت ڏني وئي، پر هڪ احتياط سان: پهرين صرف 128، ۽ صرف جيڪڏهن ڪو غلطيون نه هيون، پروٽوڪول منتقل ٿيل بائيٽ جو تعداد وڌايو. مون کي فوري طور تي 1024 بائيٽ جي منتقلي هئي. مون ٽرانسميشن پروٽوڪول جو مطالعو ڪرڻ جو فيصلو ڪيو، ۽ خاص طور تي ايڪس موڊيم.

موڊيم جا ٻه مختلف قسم هئا.

پهريون، CRC8 سپورٽ سان XMODEM پيڪيج فارميٽ (اصل XMODEM):

ٻيو، CRC16 سپورٽ سان XMODEM پيڪيٽ فارميٽ (XmodemCRC):

اهو ساڳيو ڏسڻ ۾ اچي ٿو، سواء SOH، پيڪيج نمبر ۽ CRC ۽ پيڪيج جي ڊيگهه.

مون ٻئي ٽرانسميشن بلاڪ جي شروعات ۾ ڏٺو (۽ وري فرم ویئر فائل ڏٺو، پر اڳ ۾ ئي 1024 بائيٽس جي ترتيب ڏنل):

مون ڏٺو ته واقف هيڊر fd 3e 02، پر ايندڙ ٻه بائيٽ اڳ ۾ ئي تبديل ٿي چڪا هئا: اهو 01 fe هو، ۽ 02 fd بڻجي ويو. پوءِ مون ڏٺو ته ٻئي بلاڪ جو نمبر هاڻي 02 هو ۽ اهڙيءَ طرح سمجهي ويس: منهنجي سامهون ٽرانسميشن بلاڪ جو نمبر هو. پهريون 1024 گيئر 01 آهي، ٻيو 02 آهي، ٽيون آهي 03 ۽ پوءِ (پر هيڪس ۾، يقينا). پر في کان ايف ڊي ۾ تبديلي جو ڇا مطلب آهي؟ اکين 1 جي گهٽتائي ڏٺي، دماغ ياد ڏياريو ته پروگرامر 0 کان شمار ڪن ٿا، 1 نه. پر پوء ڇو پهريون بلاڪ 1 آهي، ۽ 0 نه؟ مون کي اڃا تائين ان سوال جو جواب نه مليو آهي. پر مون سمجهيو ته ٻيو بلاڪ ڪيئن ڳڻيو وڃي ٿو. ٻيو بلاڪ FF کان وڌيڪ ڪجھ به نه آهي - (مائنس) پهرين بلاڪ جو تعداد. ان ڪري، ٻيو بلاڪ نامزد ڪيو ويو = 02 (FF-02) = 02 FD. بعد ۾ ڊمپ جي پڙهڻ منهنجي اندازي جي تصديق ڪئي.

ان کان پوء ٽرانسميشن جي هيٺ ڏنل تصوير ظاهر ٿيڻ لڳو:

ٽرانسميشن جي شروعات
fd 3e 02 - شروع ڪريو
01 FE - ٽرانسميشن ڪائونٽر
منتقلي (34 بلاڪ، 1024 بائيٽ منتقل ٿيل)
fd 3e 1024 بائيٽ ڊيٽا (30 بائيٽ بلاڪ ۾ ورهايل).
ٽرانسميشن جي پڄاڻي
ايف ڊي 25

باقي ڊيٽا کي 1024 بائيٽ سان ترتيب ڏيڻ لاء.

بلاڪ ٽرانسميشن جي آخر واري فريم کي ڇا نظر اچي ٿو:

fd 25 - بلاڪ ٽرانسميشن کي ختم ڪرڻ لاءِ سگنل. اڳيون 2f 52 - باقي فائل سائيز ۾ 1024 بائيٽ تائين. 2f 52، پروٽوڪول طرفان فيصلو ڪندي، هڪ 16-bit CRC چيڪسم آهي.

پراڻي وقت جي خاطر، مون سي ۾ هڪ پروگرام ٺاهيو جيڪو هڪ فائل مان 1024 بائيٽ ڪڍيو ۽ 16-bit CRC حساب ڪيو. پروگرام شروع ڪندي ڏيکاريو ته هي 16-bit CRC نه آهي. بيوقوف ٻيهر - اٽڪل ٽن ڏينهن لاء. اهو سڄو وقت مان سمجهڻ جي ڪوشش ڪري رهيو هوس ته اهو ڇا ٿي سگهي ٿو، جيڪڏهن چيڪسم نه هجي. انگريزي ٻوليءَ جي سائيٽن جو مطالعو ڪرڻ دوران، مون دريافت ڪيو ته ايڪس موڊيم استعمال ڪري ٿو پنهنجي چيڪسم جي حساب سان - CRC-CCITT (XModem). مون کي هن حساب جي ڪا به C لاڳو ڪرڻ نه ملي، پر مون کي هڪ سائيٽ مليو جنهن هن چيڪسم کي آن لائن حساب ڪيو. منهنجي فائل جي 1024 بائيٽ کي ويب پيج تي منتقل ڪرڻ، سائيٽ مون کي هڪ چيڪسم ڏيکاريو جيڪو مڪمل طور تي فائل مان چيڪسم سان ملندو هو.

هوري! آخري معما حل ٿي ويو، ھاڻي مون کي پنھنجي فرم ویئر ٺاهڻ جي ضرورت آھي. ان کان پوء، مون پنهنجي ڄاڻ (۽ اهو صرف منهنجي سر ۾ رهي) اليا ڏانهن منتقل ڪيو، جيڪو طاقتور ٽول ڪٽ Python سان واقف آهي.

هڪ پروگرام ٺاهڻ

Ilya Aleshin رپورٽ ڪري ٿو.

مناسب هدايتون حاصل ڪرڻ بعد، مان ڏاڍو خوش ٿيو.

ڪٿي شروع ڪرڻ لاء؟ اھو صحيح آھي، شروعات کان.  يو ايس بي پورٽ مان ڊمپ وٺڻ کان.

USB-pcap لانچ ڪريو https://desowin.org/usbpcap/tour.html

پورٽ چونڊيو جنهن سان ڊوائيس ڳنڍيل آهي ۽ فائل جتي اسان ڊمپ کي محفوظ ڪنداسين.

اسان اسڪينر کي هڪ مشين سان ڳنڍيندا آهيون جتي ونڊوز لاءِ اصلي EZConfigScanning سافٽ ويئر انسٽال ٿيل آهي.

ان ۾ اسان شيون ڳوليون ٿا ڊوائيس ڏانهن حڪم موڪلڻ لاءِ. پر ٽيمن بابت ڇا؟ مان انهن کي ڪٿي حاصل ڪري سگهان ٿو؟
جڏهن پروگرام شروع ٿئي ٿو، سامان خودڪار طريقي سان پول ڪيو ويندو آهي (اسان هن کي ٿوري دير بعد ڏسنداسين). ۽ سرڪاري سامان جي دستاويزن مان ٽريننگ بارڪوڊس موجود هئا. DEFALT. هي اسان جي ٽيم آهي.

ضروري ڊيٽا حاصل ڪئي وئي آهي. wireshark ذريعي dump.pcap کوليو.

EZConfigScanning شروع ڪرڻ وقت بلاڪ ڪريو. جڳهيون توهان کي ڌيان ڏيڻ جي ضرورت آهي ڳاڙهي ۾ نشان لڳل آهن.

اهو سڀ ڪجهه پهريون ڀيرو ڏسي، دل هارائي وئي. اهو واضح ناهي ته اڳتي ڪٿي کڏڻ.

ٿورڙو دماغي طوفان ۽ ۽ ۽... آه! ڊپ ۾ ٻاهر - آهي in۽ in ان ٻاهر.

مون گوگل ڪيو ته URB_INTERRUPT ڇا آهي. مون کي معلوم ٿيو ته هي هڪ ڊيٽا جي منتقلي جو طريقو آهي. ۽ اهڙا 4 طريقا آهن: ڪنٽرول، مداخلت، isochronous، بلڪ. توهان انهن جي باري ۾ الڳ الڳ پڙهي سگهو ٿا.

۽ آخري پوائنٽ ايڊريس USB ڊوائيس انٽرفيس ۾ حاصل ڪري سگھجن ٿيون يا ته "lsusb -v" حڪم ذريعي يا pyusb استعمال ڪندي.

هاڻي اسان کي هن VID سان سڀني ڊوائيسز کي ڳولڻ جي ضرورت آهي. توھان خاص طور تي ڳولي سگھو ٿا VID:PID.

اهو هن طرح نظر اچي ٿو:

تنهن ڪري، اسان وٽ ضروري معلومات آهي: P_INFO حڪم. يا DEFALT، ايڊريس ڪٿي لکڻ لاءِ ڪمانڊ endpoint=03 ۽ ڪٿي حاصل ڪجي جواب endpoint=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 ۾ ڏسون ٿا.

زبردست! سسٽم بارڪوڊ کي هيڪس ۾ تبديل ڪريو. اھو اھو آھي، تربيتي ڪارڪردگي تيار آھي.

firmware بابت ڇا؟ سڀ ڪجهه ساڳيو ئي لڳي ٿو، پر اتي هڪ nuance آهي.

چمڪائڻ واري عمل جي مڪمل ڊمپ وٺڻ کان پوء، اسان تقريبا سمجهي رهيا آهيون ته اسان ڇا سان معاملو ڪري رهيا آهيون. هتي XMODEM بابت هڪ مضمون آهي، جيڪو سمجھڻ ۾ تمام مددگار هو ته هي رابطي ڪيئن ٿئي ٿي، جيتوڻيڪ عام اصطلاحن ۾: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html مان ان کي پڙهڻ جي صلاح ڏيان ٿو.

ڊمپ کي ڏسي، توهان ڏسي سگهو ٿا ته فريم سائيز 1024 آهي، ۽ URB-ڊيٽا سائيز 64 آهي.

تنهن ڪري - 1024/64 - اسان هڪ بلاڪ ۾ 16 لائينون حاصل ڪندا آهيون، هڪ وقت ۾ firmware فائل 1 ڪردار پڙهو ۽ هڪ بلاڪ ٺاهيو. خاص اکرن سان بلاڪ ۾ 1 لائن کي مڪمل ڪرڻ fd3e02 + بلاڪ نمبر.
ايندڙ 14 لائينون fd25 + سان مڪمل ڪيون ويون آھن، XMODEM.calc_crc() استعمال ڪندي اسان سڄي بلاڪ جي چيڪسم کي ڳڻيو آھي (ان کي سمجھڻ ۾ گھڻو وقت لڳو ته ”FF – 1“ CSUM آھي) ۽ آخري، 16هين لائين مڪمل ڪئي وئي آھي. fd3e سان.

اهو لڳي ٿو ته اهو ئي آهي، پڙهو firmware فائل، بلاڪ کي هٽايو، اسڪينر کي ڪنييل مان ڊسڪ ڪيو ۽ ان کي ڊوائيس ڏانهن موڪليو. پر اهو ايترو سادو ناهي. اسڪينر کي فرم ویئر موڊ ۾ تبديل ڪرڻ جي ضرورت آهي،
отправив ему 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