ایک ڈویلپر کے لیے ایک کام، یا ہم نے کسی وینڈر کے بغیر ہینڈ ہیلڈ اسکینرز کو کیسے چمکایا

سب کو سلام۔

ہم، وکٹر اینٹیپوف اور الیا الیشین، آج Python PyUSB کے ذریعے USB آلات کے ساتھ کام کرنے کے اپنے تجربے اور ریورس انجینئرنگ کے بارے میں تھوڑا سا بات کریں گے۔

پس منظر

2019 میں، روسی فیڈریشن کی حکومت کا فرمان نمبر 224 "تباکو کی مصنوعات کو شناخت کے ذرائع اور خصوصیات کے ساتھ لیبل لگانے کے قوانین کی منظوری پر اشیا کی گردش کی نگرانی کے لیے ریاستی معلوماتی نظام کے نفاذ کے لیے شناختی ذرائع کے ساتھ لازمی لیبلنگ کے تابع تمباکو کی مصنوعات کے سلسلے میں" نافذ ہوا۔
دستاویز میں وضاحت کی گئی ہے کہ 1 جولائی 2019 سے، مینوفیکچررز کو تمباکو کے ہر پیکٹ پر لیبل لگانے کی ضرورت ہے۔ اور براہ راست تقسیم کاروں کو یہ پروڈکٹس یونیورسل ٹرانسفر دستاویز (UDD) کے نفاذ کے ساتھ وصول کرنا ہوں گی۔ اسٹورز، بدلے میں، کیش رجسٹر کے ذریعے لیبل لگی مصنوعات کی فروخت کو رجسٹر کرنے کی ضرورت ہے۔

نیز، 1 جولائی 2020 سے، بغیر لیبل والے تمباکو کی مصنوعات کی گردش ممنوع ہے۔ اس کا مطلب یہ ہے کہ سگریٹ کے تمام پیک کو خصوصی ڈیٹا میٹرکس بارکوڈ سے نشان زد کیا جانا چاہیے۔ اس کے علاوہ - ایک اہم نقطہ - یہ پتہ چلا کہ Datamatrix عام نہیں ہو گا، لیکن الٹا. یعنی سفید پر بلیک کوڈ نہیں بلکہ اس کے برعکس۔

ہم نے اپنے سکینرز کا تجربہ کیا، اور یہ پتہ چلا کہ ان میں سے اکثر کو ری فلیش/دوبارہ تربیت دینے کی ضرورت ہے، بصورت دیگر وہ اس بارکوڈ کے ساتھ عام طور پر کام کرنے کے قابل نہیں ہیں۔ واقعات کے اس موڑ نے ہمیں شدید سر درد کی ضمانت دی، کیونکہ ہماری کمپنی کے بہت سارے اسٹورز ہیں جو ایک وسیع علاقے میں بکھرے ہوئے ہیں۔ کئی دسیوں ہزار نقدی رجسٹر – اور بہت کم وقت۔

کیا کرنا تھا؟ دو آپشنز ہیں۔ پہلا: سائٹ پر موجود انجینئرز دستی طور پر سکینر کو ری فلیش اور ایڈجسٹ کرتے ہیں۔ دوسرا: ہم دور سے کام کرتے ہیں اور ترجیحی طور پر، ایک بار میں کئی سکینرز کا احاطہ کرتے ہیں۔

پہلا آپشن، ظاہر ہے، ہمارے لیے موزوں نہیں تھا: ہمیں انجینئرز کا دورہ کرنے پر پیسہ خرچ کرنا پڑے گا، اور اس صورت میں اس عمل کو کنٹرول اور مربوط کرنا مشکل ہوگا۔ لیکن سب سے اہم بات یہ ہے کہ لوگ کام کریں گے، یعنی ہمیں ممکنہ طور پر بہت سی غلطیاں ملیں گی اور غالباً، آخری تاریخ کو پورا نہیں کریں گے۔

دوسرا آپشن سب کے لیے اچھا ہے، اگر ایک چیز کے لیے نہیں۔ کچھ دکانداروں کے پاس ریموٹ فلیشنگ ٹولز نہیں تھے جو ہمیں تمام مطلوبہ آپریٹنگ سسٹمز کے لیے درکار تھے۔ اور چونکہ ڈیڈ لائن ختم ہو رہی تھی اس لیے مجھے اپنے سر سے سوچنا پڑا۔

اگلا، ہم آپ کو بتائیں گے کہ ہم نے Debian 9.x OS (ہمارے تمام کیش رجسٹر Debian پر ہیں) کے لیے ہاتھ سے پکڑے ہوئے اسکینرز کے لیے ٹولز کیسے تیار کیے ہیں۔

پہیلی کو حل کریں: اسکینر کو کیسے فلیش کریں۔

وکٹر اینٹیپوف کی رپورٹ۔

وینڈر کی طرف سے فراہم کردہ آفیشل یوٹیلیٹی ونڈوز کے تحت کام کرتی ہے، اور صرف IE کے ساتھ۔ یوٹیلیٹی اسکینر کو فلیش اور کنفیگر کر سکتی ہے۔

چونکہ ہمارا ٹارگٹ سسٹم ڈیبین ہے، اس لیے ہم نے ڈیبیان پر ایک USB-ری ڈائرکٹر سرور اور ونڈوز پر ایک USB-ری ڈائرکٹر کلائنٹ انسٹال کیا۔ یو ایس بی ری ڈائرکٹر یوٹیلیٹیز کا استعمال کرتے ہوئے، ہم نے اسکینر کو لینکس مشین سے ونڈوز مشین پر بھیج دیا۔

ونڈوز وینڈر کی ایک افادیت نے اسکینر کو دیکھا اور یہاں تک کہ اسے عام طور پر چمکایا۔ اس طرح، ہم نے پہلا نتیجہ اخذ کیا: کچھ بھی OS پر منحصر نہیں ہے، یہ چمکتا پروٹوکول کا معاملہ ہے.

ٹھیک ہے. ہم نے ونڈوز مشین پر فلیشنگ چلائی، اور لینکس مشین پر موجود ڈمپ کو ہٹا دیا۔

ہم نے ڈمپ کو وائر شارک میں بھر دیا اور... اداس ہو گئے (میں ڈمپ کی کچھ تفصیلات کو چھوڑ دوں گا، ان میں کوئی دلچسپی نہیں ہے)۔

ڈمپ نے ہمیں کیا دکھایا:

ایڈریس 0000-0030، Wireshark کے مطابق، USB سروس کی معلومات ہیں۔

ہم حصہ 0040-0070 میں دلچسپی رکھتے تھے۔

MOCFT حروف کے علاوہ ایک ٹرانسمیشن فریم سے کچھ بھی واضح نہیں تھا۔ یہ حروف فرم ویئر فائل کے حروف نکلے، ساتھ ہی ساتھ فریم کے اختتام تک باقی حروف (فرم ویئر فائل کو نمایاں کیا گیا ہے):

fd 3e 02 01 fe کی علامتوں کا کیا مطلب ہے، مجھے ذاتی طور پر، الیا کی طرح، کوئی اندازہ نہیں تھا۔

میں نے مندرجہ ذیل فریم کو دیکھا (سروس کی معلومات کو یہاں ہٹا دیا گیا ہے، فرم ویئر فائل کو نمایاں کیا گیا ہے):

کیا واضح ہوا؟ کہ پہلے دو بائٹس کسی قسم کی مستقل ہیں۔ اس کے بعد کے تمام بلاکس نے اس کی تصدیق کی، لیکن ٹرانسمیشن بلاک کے اختتام سے پہلے:

یہ فریم بھی حیران کن تھا، کیونکہ مستقل بدل گیا تھا (ہائی لائٹ کیا گیا) اور، عجیب بات ہے، فائل کا کچھ حصہ تھا۔ فائل کے ٹرانسفر کردہ بائٹس کے سائز سے پتہ چلتا ہے کہ 1024 بائٹس کو منتقل کیا گیا تھا۔ میں دوبارہ نہیں جانتا تھا کہ باقی بائٹس کا کیا مطلب ہے۔

سب سے پہلے، ایک پرانے BBS عرفیت کے طور پر، میں نے معیاری ٹرانسمیشن پروٹوکولز کا جائزہ لیا۔ کوئی پروٹوکول 1024 بائٹس منتقل نہیں ہوا۔ میں نے ہارڈ ویئر کا مطالعہ شروع کیا اور 1K Xmodem پروٹوکول میں آیا۔ اس نے 1024 کو منتقل کرنے کی اجازت دی، لیکن ایک انتباہ کے ساتھ: پہلے صرف 128، اور صرف اس صورت میں جب کوئی غلطیاں نہ ہوں، پروٹوکول نے منتقل ہونے والے بائٹس کی تعداد میں اضافہ کیا۔ میرے پاس فوری طور پر 1024 بائٹس کی منتقلی تھی۔ میں نے ٹرانسمیشن پروٹوکول اور خاص طور پر ایکس موڈیم کا مطالعہ کرنے کا فیصلہ کیا۔

موڈیم کی دو مختلف حالتیں تھیں۔

سب سے پہلے، 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 بائٹ بلاکس میں تقسیم)
ٹرانسمیشن کا اختتام
ایف ڈی 25۔

باقی ڈیٹا کو 1024 بائٹس کے ساتھ منسلک کرنا ہے۔

بلاک ٹرانسمیشن اینڈ فریم کیسا لگتا ہے:

fd 25 - بلاک ٹرانسمیشن کو ختم کرنے کا سگنل۔ اگلا 2f 52 - بقیہ فائل سائز میں 1024 بائٹس تک۔ 2f 52، پروٹوکول کے مطابق، ایک 16 بٹ CRC چیکسم ہے۔

پرانے وقتوں کی خاطر، میں نے C میں ایک پروگرام بنایا جس نے فائل سے 1024 بائٹس نکالے اور 16 بٹ CRC کا حساب لگایا۔ پروگرام شروع کرنے سے معلوم ہوا کہ یہ 16 بٹ CRC نہیں ہے۔ دوبارہ بیوقوف - تقریبا تین دن کے لئے. اس سارے وقت میں میں یہ سمجھنے کی کوشش کر رہا تھا کہ یہ چیکسم نہیں تو کیا ہو سکتا ہے۔ انگریزی زبان کی سائٹس کا مطالعہ کرتے ہوئے، میں نے دریافت کیا کہ ایکس موڈیم اپنا چیکسم کیلکولیشن - CRC-CCITT (XModem) استعمال کرتا ہے۔ مجھے اس حساب کا کوئی C نفاذ نہیں ملا، لیکن مجھے ایک ایسی سائٹ ملی جس نے اس چیکسم کا آن لائن حساب لگایا۔ میری فائل کے 1024 بائٹس کو ویب پیج پر منتقل کرنے کے بعد، سائٹ نے مجھے ایک چیکسم دکھایا جو فائل کے چیکسم سے مکمل طور پر مماثل تھا۔

ہورے! آخری پہیلی حل ہو گئی، اب مجھے اپنا فرم ویئر بنانے کی ضرورت ہے۔ اس کے بعد، میں نے اپنا علم الیا کو دیا (اور یہ صرف میرے دماغ میں ہی رہا)، جو طاقتور ٹول کٹ Python سے واقف ہے۔

ایک پروگرام بنانا

الیا الیشین کی رپورٹ۔

مناسب ہدایات ملنے کے بعد، میں بہت "خوش" تھا۔

کہاں سے شروع کریں؟ یہ شروع سے ہی ٹھیک ہے۔  USB پورٹ سے ڈمپ لینے سے۔

USB-pcap لانچ کریں۔ https://desowin.org/usbpcap/tour.html

وہ پورٹ منتخب کریں جس سے ڈیوائس منسلک ہے اور وہ فائل جہاں ہم ڈمپ کو محفوظ کریں گے۔

ہم اسکینر کو ایک مشین سے جوڑتے ہیں جہاں ونڈوز کے لیے مقامی EZConfigScanning سافٹ ویئر انسٹال ہوتا ہے۔

اس میں ہمیں ڈیوائس پر کمانڈ بھیجنے کے لیے آئٹم ملتا ہے۔ لیکن ٹیموں کا کیا ہوگا؟ میں انہیں کہاں سے حاصل کر سکتا ہوں؟
جب پروگرام شروع ہوتا ہے، سامان خود بخود پول ہو جاتا ہے (ہم اسے تھوڑی دیر بعد دیکھیں گے)۔ اور سرکاری سامان کی دستاویزات سے تربیتی بارکوڈز موجود تھے۔ ڈیفالٹ۔ یہ ہماری ٹیم ہے۔

ضروری ڈیٹا موصول ہو گیا ہے۔ wireshark کے ذریعے dump.pcap کھولیں۔

EZConfigScanning شروع کرتے وقت بلاک کریں۔ جن جگہوں پر آپ کو توجہ دینے کی ضرورت ہے وہ سرخ رنگ میں نشان زد ہیں۔

یہ سب پہلی بار دیکھ کر میرا دل ہار گیا۔ یہ واضح نہیں ہے کہ اگلا کہاں کھودنا ہے۔

تھوڑا سا ذہن سازی اور اور... آہ! کوڑے دان میں باہر ہے - inاور in اس باہر.

میں نے گوگل کیا کہ URB_INTERRUPT کیا ہے۔ مجھے پتہ چلا کہ یہ ڈیٹا کی منتقلی کا طریقہ ہے۔ اور اس طرح کے 4 طریقے ہیں: کنٹرول، انٹرپٹ، آئسوکرونس، بلک۔ آپ ان کے بارے میں الگ سے پڑھ سکتے ہیں۔

اور 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 میں دیکھتے ہیں۔

زبردست! سسٹم بارکوڈز کو ہیکس میں تبدیل کریں۔ بس، تربیت کی فعالیت تیار ہے۔

فرم ویئر کے بارے میں کیا خیال ہے؟ سب کچھ ایک جیسا لگتا ہے، لیکن ایک nuance ہے.

چمکنے کے عمل کا مکمل ڈمپ لینے کے بعد، ہم تقریباً سمجھ گئے کہ ہم کس چیز سے نمٹ رہے ہیں۔ یہاں 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