سڀني کي سلام.
اڄ، وڪٽر اينٽيپوف ۽ اليا اليشن پٿون پائي يو ايس بي ذريعي USB ڊوائيسز سان ڪم ڪرڻ جا پنهنجا تجربا ۽ ريورس انجنيئرنگ بابت ٿورو شيئر ڪندا.
prehistory
2019 ۾، روسي حڪومت جي قرارداد نمبر 224 "تمباکو جي شين کي سڃاڻپ جي ذريعن سان نشان لڳائڻ جي ضابطن جي منظوري تي ۽ تمباکو جي شين جي حوالي سان سڃاڻپ جي ذريعن سان لازمي نشان لڳائڻ جي تابع شين جي گردش جي نگراني لاءِ رياستي معلوماتي نظام لاڳو ڪرڻ جي وضاحتن تي" عمل ۾ آيو.
دستاويز ۾ وضاحت ڪئي وئي آهي ته، 1 جولاءِ 2019 کان، ٺاهيندڙن کي تمباکو جي هر پيڪٽ تي ليبل لڳائڻ جي ضرورت آهي. سڌو سنئون ورهائيندڙن کي اهي شيون هڪ عالمگير منتقلي دستاويز (UTD) سان وصول ڪرڻ گهرجن. دڪانن کي، موڙ ۾، چيڪ آئوٽ تي ليبل ٿيل شين جي وڪرو رجسٽر ڪرڻ گهرجي.
ان کان علاوه، 1 جولاءِ 2020 کان، غير نشان ٿيل تمباکو جي شين جي گردش تي پابندي آهي. ان جو مطلب آهي ته سڀني سگريٽ جي پيڪن کي هڪ خاص ڊيٽا ميٽرڪس بارڪوڊ سان نشان لڳايو وڃي. اهم طور تي، اهو ظاهر ڪيو ويو آهي ته ڊيٽا ميٽرڪس هڪ معياري بارڪوڊ نه هوندو، پر هڪ الٽو هوندو. يعني، اڇي تي ڪارو ڪوڊ نه، پر ان جي برعڪس.
اسان پنهنجن اسڪينرن جي جانچ ڪئي، ۽ اهو ظاهر ٿيو ته انهن مان گھڻن کي ٻيهر پروگرام ڪرڻ يا ٻيهر تربيت ڏيڻ جي ضرورت آهي، ٻي صورت ۾ اهي صرف هن بارڪوڊ سان صحيح طريقي سان ڪم نه ڪندا. واقعن جي هن موڙ اسان کي هڪ وڏي سر درد جي ضمانت ڏني، ڇاڪاڻ ته اسان جي ڪمپني وٽ هڪ وڏي علائقي ۾ وڏي تعداد ۾ اسٽور آهن. هزارين چيڪ آئوٽ - ۽ تمام گهٽ وقت.
اسان کي ڇا ڪرڻ گهرجي؟ ٻه آپشن آهن. پهريون، انجنيئر سائيٽ تي دستي طور تي اسڪينرز کي ري فليش ۽ فائن ٽيون ڪندا آهن. ٻيو، اسان ريموٽ ڪم ڪندا آهيون ۽، مثالي طور تي، هڪ ئي ورهاڱي ۾ ڪيترن ئي اسڪينرز کي ڍڪيندا آهيون.
پهريون آپشن اسان لاءِ واضح طور تي نامناسب هو: اسان کي انجنيئرن جي دورن تي پئسا خرچ ڪرڻا پوندا هئا، ۽ عمل جي نگراني ۽ هم آهنگي ڪرڻ ڏکيو هوندو هو. پر سڀ کان اهم ڳالهه اها آهي ته ان ۾ ماڻهو شامل هوندا، جنهن جو مطلب آهي ته اسان ممڪن طور تي ڪيتريون ئي غلطيون منهن ڏيون ها ۽ ممڪن طور تي آخري تاريخ وڃائي ڇڏيون ها.
ٻيو آپشن مڪمل هوندو، سواءِ هڪ مسئلي جي. ڪجهه وينڊرز وٽ ريموٽ فليشنگ ٽولز نه هئا جيڪي اسان کي سڀني گهربل آپريٽنگ سسٽم لاءِ گهربل هئا. ۽ جيئن ته آخري تاريخون سخت هيون، اسان کي پاڻ کي اهو سمجهڻو پيو.
اڳيون، اسان توهان کي ٻڌائينداسين ته اسان ڊيبين 9.x هلائيندڙ هٿ ۾ هلندڙ اسڪينرن لاءِ اوزار ڪيئن ٺاهيا (اسان جا سڀئي چيڪ آئوٽ ڊيبين تي آهن).
پہیلی کي حل ڪريو: اسڪينر کي ڪيئن چمڪائجي
Viktor Antipov ڪهاڻي ٻڌائي ٿو.
وينڊر پاران مهيا ڪيل سرڪاري يوٽيلٽي ونڊوز تي ڪم ڪري ٿي، پر صرف انٽرنيٽ ايڪسپلورر سان. اهو اسڪينر کي فليش ۽ ترتيب ڏئي سگهي ٿو.
جيئن ته اسان جو ٽارگيٽ سسٽم ڊيبين آهي، اسان ڊيبين تي USB-ريڊائريڪٽ سرور ۽ ونڊوز تي USB-ريڊائريڪٽ ڪلائنٽ انسٽال ڪيو. USB-ريڊائريڪٽ يوٽيلٽيز استعمال ڪندي، اسان اسڪينر کي لينڪس مشين کان ونڊوز مشين ڏانهن ريڊائريڪٽ ڪيو.
وينڊر جي ونڊوز يوٽيليٽي اسڪينر کي ڳولي لڌو ۽ ان کي ڪاميابي سان فليش به ڪيو. تنهن ڪري، اسان جو پهريون نتيجو: او ايس جو ان سان ڪو به تعلق ناهي؛ مسئلو فليشنگ پروٽوڪول ۾ آهي.
ٺيڪ آهي. اسان ونڊوز مشين تي فرم ويئر اپڊيٽ شروع ڪئي ۽ لينڪس مشين تي ڊمپ ورتو.
اسان ڊمپ کي وائر شارڪ ۾ اڇلائي ڇڏيو ۽... اداس محسوس ٿيو (مان ڊمپ جي ڪجهه تفصيلن کي ڇڏي ڏيندس، اهي ڪا به دلچسپي نه رکندا).
ڊمپ اسان کي ڇا ڏيکاريو:
وائرشرڪ جي مطابق، ايڊريس 0000-0030، USB سروس جي معلومات آهن.
اسان کي حصو 0040-0070 ۾ دلچسپي هئي.
MOCFT علامتن کان سواءِ سنگل ٽرانسميشن فريم مان ڪجھ به واضح نه هو. اهي علامتون فرم ويئر فائل مان نڪتيون، جيئن فريم جي آخر تائين باقي علامتون هيون (فرم ويئر فائل نمايان ٿيل آهي):
ذاتي طور تي، مون کي، اليا وانگر، ڪابه خبر نه هئي ته علامتن fd 3e 02 01 fe جو مطلب ڇا آهي.
مون هيٺ ڏنل فريم ڏٺو (سروس جي معلومات هتي هٽائي وئي آهي، فرم ويئر فائل نمايان ٿيل آهي):
ڇا واضح ٿيو؟ ته پهرين ٻه بائيٽ ڪنهن قسم جي مستقل آهن. سڀني بعد وارن بلاڪن هن جي تصديق ڪئي، پر ٽرانسميشن بلاڪ جي آخر تائين نه:
هن فريم مون کي به پريشان ڪيو، ڇاڪاڻ ته مسلسل (نمايان ٿيل) تبديل ٿي چڪو هو ۽، عجيب طور تي، فائل جو حصو موجود هو. منتقل ٿيل بائيٽس جي سائيز ڏيکاري ٿي ته 1024 بائيٽس منتقل ڪيا ويا هئا. باقي بائيٽس جو مطلب ڇا هو - ٻيهر، مون کي ڪا به خبر نه هئي.
هڪ تجربيڪار بي بي ايس اي آر جي حيثيت سان، مون پهريون ڪم جيڪو ڪيو، اهو هو معياري ٽرانسميشن پروٽوڪول جو جائزو وٺڻ. انهن مان ڪو به 1024 بائيٽ منتقل نه ڪري سگهيو. مون هارڊويئر تي تحقيق شروع ڪئي ۽ 1K ايڪس موڊيم پروٽوڪول تي ٺوڪر هنيو. اهو 1024 بائيٽ جي اجازت ڏني، پر هڪ ڪيچ سان: شروعات ۾، صرف 128، ۽ صرف جيڪڏهن ڪا غلطي نه هجي ها ته پروٽوڪول منتقل ٿيل بائيٽس جو تعداد وڌائيندو. مان فوري طور تي 1024 بائيٽ منتقل ڪري رهيو هوس. مون ٽرانسميشن پروٽوڪول جو مطالعو ڪرڻ جو فيصلو ڪيو، خاص طور تي ايڪس موڊيم.
موڊيم جا ٻه قسم هئا.
پهريون، CRC8 سپورٽ سان XMODEM پيڪٽ فارميٽ (اصل XMODEM):
ٻيو، CRC16 سپورٽ سان XMODEM پيڪٽ فارميٽ (XmodemCRC):
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 طور نامزد ڪيو ويو. ڊمپ جي بعد ۾ پڙهڻ منهنجي اندازي جي تصديق ڪئي.
پوءِ ٽرانسميشن جي هيٺ ڏنل تصوير سامهون اچڻ شروع ٿي:
ٽرانسميشن جي شروعات
ايف ڊي 3e 02 - شروع ڪريو
01 FE - ٽرانسميشن ڪائونٽر
ٽرانسميشن (34 بلاڪ، 1024 بائيٽ منتقل ڪيا ويا)
fd 3e 1024 بائيٽ ڊيٽا (30-بائيٽ بلاڪن ۾ ورهايل).
ٽرانسميشن جو اختتام
ايف ڊي 25
ڊيٽا کي 1024 بائيٽس سان ترتيب ڏيڻو آهي.
بلاڪ ٽرانسميشن فريم جو آخر ڪيئن نظر ايندو:
fd 25 بلاڪ ٽرانسميشن کي ختم ڪرڻ لاءِ سگنل آهي. پوءِ 2f 52 فائل جو باقي حصو 1024 بائيٽ تائين آهي. 2f 52، پروٽوڪول جي مطابق، 16-بٽ CRC چيڪسم آهي.
عادت کان ٻاهر، مون سي ۾ هڪ پروگرام ٺاهيو جيڪو هڪ فائل مان 1024 بائيٽ ڪڍيو ۽ 16-بٽ سي آر سي جو حساب ڪيو. پروگرام هلائڻ سان ظاهر ٿيو ته اهو 16-بٽ سي آر سي نه هو. ٻيهر، مان ٽن ڏينهن تائين ٿڪجي پيو هوس. هن سڄي وقت، مان اهو معلوم ڪرڻ جي ڪوشش ڪري رهيو هوس ته اهو چيڪسم نه هجڻ جي صورت ۾ ڇا ٿي سگهي ٿو. انگريزي ٻولي جي ويب سائيٽن تي تحقيق ڪندي، مون دريافت ڪيو ته ايڪس موڊيم پنهنجي چيڪسم حساب ڪتاب استعمال ڪري ٿو - سي آر سي-سي سي آءِ ٽي ٽي (ايڪس موڊيم). مون کي هن حساب ڪتاب جو ڪو به سي لاڳو نه ملي سگهيو، پر مون هڪ ويب سائيٽ ڳولي لڌي جيڪا هن چيڪسم کي آن لائن حساب ڪيو. پنهنجي فائل جي 1024 بائيٽ کي ويب پيج تي اپ لوڊ ڪرڻ کان پوءِ، ويب سائيٽ مون کي هڪ چيڪسم ڏيکاريو جيڪو فائل مان چيڪسم سان مڪمل طور تي ملائي ٿو.
هورا! آخري معما حل ٿي ويو، هاڻي مون کي پنهنجو فرم ويئر ٺاهڻ جي ضرورت هئي. پوءِ، مون پنهنجو علم (جيڪو صرف منهنجي ذهن ۾ رهيو) اليا ڏانهن منتقل ڪيو، جيڪو هڪ طاقتور ٽول ڪٽ - پٿون کان واقف آهي.
پروگرام ٺاهڻ
اليا اليشن ڪهاڻي ٻڌائي ٿو.
لاڳاپيل هدايتون ملڻ کان پوءِ، مون کي تمام گهڻو "خوشي" ٿي.
ڪٿان شروع ڪجي؟ اهو صحيح آهي، شروعات کان. USB پورٽ کي ڊمپ ڪندي.
USB-pcap لانچ ڪريو
اهو پورٽ چونڊيو جنهن سان ڊوائيس ڳنڍيل آهي ۽ فائل جتي اسان ڊمپ محفوظ ڪنداسين.
اسين اسڪينر کي هڪ مشين سان ڳنڍيندا آهيون جتي ونڊوز لاءِ اصلي EZConfigScanning سافٽ ويئر نصب ٿيل آهي.
اتي اسان کي ڊوائيس ڏانهن حڪم موڪلڻ جو آپشن ملندو. پر حڪمن بابت ڇا؟ مان اهي ڪٿان حاصل ڪري سگهان ٿو؟
جڏهن پروگرام شروع ٿئي ٿو، ته سامان پاڻمرادو پڇاڻو ڪيو ويندو آهي (اسين هن کي ٿوري دير بعد ڏسنداسين). سامان جي سرڪاري دستاويزن مان تربيتي بارڪوڊ پڻ هئا. ڊفالٽ. هي اسان جي ٽيم آهي.
ضروري ڊيٽا حاصل ڪئي وئي آهي. Wireshark استعمال ڪندي dump.pcap کوليو.
جڏهن EZConfigScanning شروع ٿئي ته بلاڪ ڪريو. ڌيان جي ضرورت وارن علائقن کي ڳاڙهي رنگ ۾ نمايان ڪيو ويندو.
پهريون ڀيرو اهو سڀ ڪجهه ڏسي، مان مايوس ٿي ويس. اهو واضح نه هو ته اڳتي ڪٿي کوٽجي.
ٿورو غور ۽... آها! ڪچري ۾ ٻاهر - آهي in۽ in ان ٻاهر.
مون گوگل تي URB_INTERRUPT ڳوليو ۽ معلوم ٿيو ته اهو ڊيٽا ٽرانسفر جو طريقو آهي. انهن مان چار طريقا آهن: ڪنٽرول، انٽرپٽ، آئسوڪرونس، ۽ بلڪ. توهان انهن بابت الڳ الڳ پڙهي سگهو ٿا.
۽ USB ڊوائيس انٽرفيس ۾ اينڊ پوائنٽ ايڊريس يا ته "lsusb -v" ڪمانڊ ذريعي يا pyusb استعمال ڪندي حاصل ڪري سگهجي ٿو.
هاڻي اسان کي هن VID سان سڀئي ڊوائيسز ڳولڻ جي ضرورت آهي. توهان خاص طور تي 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 ۾ ڏسون ٿا.
بهترين! اسان سسٽم بارڪوڊ کي هيڪس ۾ تبديل ڪري رهيا آهيون. بس، تربيتي ڪارڪردگي تيار آهي.
فرم ويئر بابت ڇا؟ اهو ساڳيو لڳي ٿو، پر هڪ nuance آهي.
فرم ويئر اپڊيٽ جي عمل جي مڪمل ڊمپ کي ڪيپچر ڪرڻ کان پوءِ، اسان کي هڪ اندازي مطابق خيال آيو ته اسان ڇا سان ڊيل ڪري رهيا آهيون. هتي XMODEM بابت هڪ مضمون آهي، جنهن واقعي اسان کي سمجهڻ ۾ مدد ڪئي ته هي ڪميونيڪيشن ڪيئن ڪم ڪري ٿو، جيتوڻيڪ عام اصطلاحن ۾: مان ان کي پڙهڻ جي صلاح ڏيان ٿو.
ڊمپ کي ڏسندي، توهان ڏسي سگهو ٿا ته فريم سائيز 1024 آهي، ۽ URB-ڊيٽا سائيز 64 آهي.
تنهن ڪري - 1024/64 - اسان کي هڪ بلاڪ ۾ 16 لائينون ملن ٿيون، هڪ وقت ۾ فرم ويئر فائل کي هڪ اکر پڙهون ٿا، ۽ بلاڪ ٺاهيون ٿا. اسان بلاڪ ۾ هڪ لائين کي خاص اکرن fd3e02 + بلاڪ نمبر سان شامل ڪريون ٿا.
اسين ايندڙ 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
