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

سب کو سلام۔

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

پس منظر

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

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

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

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

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

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

اگلا، ہم آپ کو بتائیں گے کہ ہم نے Debian 9.x چلانے والے ہینڈ ہیلڈ اسکینرز کے لیے ٹولز کیسے تیار کیے (ہمارے تمام چیک آؤٹ Debian پر ہیں)۔

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

وکٹر اینٹیپوف کہانی سناتے ہیں۔

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

چونکہ ہمارا ٹارگٹ سسٹم Debian ہے، اس لیے ہم نے USB-redirector سرور Debian پر اور USB-redirector کلائنٹ Windows پر انسٹال کیا۔ USB-redirector افادیت کا استعمال کرتے ہوئے، ہم نے سکینر کو لینکس مشین سے ونڈوز مشین پر ری ڈائریکٹ کیا۔

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

ٹھیک ہے ہم نے ونڈوز مشین پر فرم ویئر اپ ڈیٹ شروع کیا اور لینکس مشین پر ڈمپ لیا۔

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

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

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

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

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

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

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

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

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

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

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

سب سے پہلے، CRC8 سپورٹ کے ساتھ XMODEM پیکٹ فارمیٹ (اصل XMODEM):

دوسرا، XMODEM پیکٹ فارمیٹ CRC16 سپورٹ کے ساتھ (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 کے طور پر نامزد کیا گیا تھا۔ ڈمپ کے بعد کے پڑھنے نے میرے اندازے کی تصدیق کی۔

پھر ٹرانسمیشن کی مندرجہ ذیل تصویر سامنے آنا شروع ہوئی:

ٹرانسمیشن کا آغاز
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 بائٹس اپ لوڈ کرنے کے بعد، ویب سائٹ نے مجھے ایک چیکسم دکھایا جو فائل کے چیکسم سے مکمل طور پر مماثل تھا۔

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

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

الیا الیشین کہانی سناتی ہے۔

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

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

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

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

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

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

ضروری ڈیٹا حاصل کر لیا گیا ہے۔ Wireshark کا استعمال کرتے ہوئے dump.pcap کھولیں۔

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

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

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

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

اور 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 لائنیں ملتی ہیں، فرم ویئر فائل کو ایک وقت میں ایک کریکٹر پڑھتے ہیں، اور بلاک بناتے ہیں۔ ہم بلاک میں ایک لائن کو خصوصی حروف 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 فلیشنگ موڈ میں ہیکس کو قبول نہیں کرتا ہے۔ لہذا، آپ کو بائٹس_ارے کی ہر سطر کا ترجمہ کرنا پڑے گا۔

[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