ټولو ته سلام.
موږ، ویکتور انټیپوف او الیا الیشین، نن به د Python PyUSB له لارې د USB وسیلو سره د کار کولو تجربې او د ریورس انجینرۍ په اړه لږ څه خبرې وکړو.
له تاریخ څخه دمخه
په 2019 کې، د روسیې د فدراسیون د حکومت فرمان نمبر 224 "د پیژندنې وسیلو او ځانګړتیاو سره د تمباکو محصولاتو د لیبل کولو مقرراتو تصویب په اړه د پیژندنې وسیلو سره د اجباري لیبل کولو سره د توکو جریان نظارت کولو لپاره د دولتي معلوماتو سیسټم پلي کول د تنباکو د محصولاتو په تړاو" نافذ شو.
سند تشریح کوي چې د جولای 1، 2019 څخه، تولید کونکي اړ دي چې د تنباکو هر کڅوړه لیبل کړي. او مستقیم توزیع کونکي باید دا محصولات د نړیوال لیږد سند (UDD) اجرا کولو سره ترلاسه کړي. پلورنځي، په بدل کې، اړتیا لري د نغدو راجستر له لارې د لیبل شوي محصولاتو پلور ثبت کړي.
همدارنګه، د جولای له 1، 2020 څخه، د غیر لیبل شوي تنباکو محصولاتو جریان منع دی. دا پدې مانا ده چې د سګرټ ټول کڅوړې باید د ځانګړي ډیټامټریکس بارکوډ سره نښه شي. سربیره پردې - یو مهم ټکی - دا معلومه شوه چې ډیټامټریکس به عادي نه وي، مګر برعکس. دا په سپینه تور کوډ نه دی، مګر برعکس.
موږ خپل سکینرونه ازمویل، او دا معلومه شوه چې ډیری یې د بیا ځلولو / بیا روزنې ته اړتیا لري، که نه نو دوی د دې بارکوډ سره په نورمال ډول کار کولو توان نلري. د پیښو دا بدلون موږ ته د سخت سر درد تضمین کړی، ځکه چې زموږ شرکت ډیری پلورنځي لري چې په پراخه ساحه کې ویشل شوي دي. په لسګونو زره نغدي راجسترونه - او ډیر لږ وخت.
څه باید وشي؟ دوه اختیارونه شتون لري. لومړی: په سایټ کې انجینران په لاسي ډول سکینرونه ریفلیش او تنظیموي. دوهم: موږ له لیرې کار کوو او په غوره توګه په یو تکرار کې ډیری سکینرونه په یوځل پوښو.
لومړی اختیار، په ښکاره ډول، زموږ لپاره مناسب نه و: موږ باید د انجنیرانو په لیدلو پیسې ولګوو، او پدې حالت کې به د پروسې کنټرول او همغږي ستونزمن وي. مګر ترټولو مهمه خبره دا ده چې خلک به کار وکړي، دا دا دی چې موږ به په احتمالي توګه ډیری غلطۍ ترلاسه کړو او ډیری احتمال به د وخت نیټه پوره نه کړو.
دوهم اختیار د هرچا لپاره ښه دی، که نه د یو شی لپاره. ځینې پلورونکي د ریموټ فلش کولو وسیلې نلري چې موږ د ټولو اړین عملیاتي سیسټمونو لپاره ورته اړتیا درلوده. او له هغه وخته چې ضرب الاجل پای ته ورسید ، ما باید په خپل سر فکر وکړ.
بل ، موږ به تاسو ته ووایو چې څنګه موږ د Debian 9.x OS لپاره د لاسي سکینرونو لپاره وسیلې رامینځته کړې (زموږ ټولې نغدي راجسټرې په Debian کې دي).
معما حل کړئ: د سکینر فلش کولو څرنګوالی
ویکتور انتیپوف راپور ورکوي.
د پلورونکي لخوا چمتو شوي رسمي ګټه د وینډوز لاندې کار کوي، او یوازې د IE سره. افادیت کولی شي سکینر فلش او تنظیم کړي.
څرنګه چې زموږ د هدف سیسټم دیبیان دی، موږ په ډیبیان کې د یو ایس بی ریډیریټر سرور او په وینډوز کې د یو ایس بی ریډیریکټر مراجع نصب کړ. د usb-redirector اسانتیاوو په کارولو سره، موږ سکینر د لینکس ماشین څخه وینډوز ماشین ته لیږلی.
د وینډوز پلورونکي څخه یو افادیت سکینر لیدلی او حتی په نورمال ډول یې فلش کړی. په دې توګه، موږ لومړۍ پایله وکړه: هیڅ شی په OS پورې اړه نلري، دا د فلش پروتوکول مسله ده.
سمه ده. موږ په وینډوز ماشین کې چمکۍ چلولې، او د لینوکس ماشین کې ډمپ لرې کړ.
موږ ډمپ په WireShark کې ډک کړ او غمجن شو (زه به د ډمپ ځینې توضیحات له پامه غورځوم، دوی هیڅ علاقه نلري).
ډمپ موږ ته څه وښودل:
پته 0000-0030، د Wireshark لخوا قضاوت، د USB خدماتو معلومات دي.
موږ د 0040-0070 برخې سره علاقه درلوده.
د MOCFT کرکټرونو پرته د یو لیږد چوکاټ څخه هیڅ شی روښانه نه و. دا کرکټرونه د فرم ویئر فایل څخه کرکټرونه وګرځیدل ، په بیله بیا د چوکاټ پای پورې پاتې حروف (د فرم ویئر فایل روښانه شوی):
د fd 3e 02 01 fe سمبولونه څه معنی لري، زه په شخصي توګه، د الیا په څیر، هیڅ نه پوهیږم.
ما لاندې چوکاټ ته وکتل (د خدماتو معلومات دلته لرې شوي، د فرم ویئر فایل روښانه شوی):
څه روښانه شول؟ دا چې لومړی دوه بایټونه یو ډول ثابت دي. ټولو راتلونکو بلاکونو دا تایید کړه، مګر د لیږد بلاک پای ته رسیدو دمخه:
دا چوکاټ هم حیرانوونکی و، ځکه چې ثابت بدل شوی (روښانه شوی) او په عجیب ډول، د فایل یوه برخه وه. د فایل لیږدول شوي بایټ اندازه ښودلې چې 1024 بایټونه لیږدول شوي. زه بیا نه پوهیدم چې پاتې بایټس څه معنی لري.
تر ټولو لومړی، د زاړه BBS مستعار نوم په توګه، ما د معیاري لیږد پروتوکولونو بیاکتنه وکړه. هیڅ پروتوکول نه دی لیږدول شوی 1024 بایټ. ما د هارډویر مطالعه پیل کړه او د 1K Xmodem پروتوکول ته ورسیدم. دې د 1024 لیږدولو ته اجازه ورکړه ، مګر د احتیاط سره: په لومړي سر کې یوازې 128 ، او یوازې که چیرې هیڅ غلطی شتون ونلري ، پروتوکول د لیږد شوي بایټس شمیر ډیر کړ. ما سمدلاسه د 1024 بایټ لیږد درلود. ما پریکړه وکړه چې د لیږد پروتوکولونه مطالعه کړم، او په ځانګړې توګه د ایکس موډیم.
د موډیم دوه توپیرونه شتون درلود.
لومړی، د XMODEM بسته بڼه د CRC8 ملاتړ سره (اصلي 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 بایټ بلاکونو ویشل شوي).
د لیږد پای
fd 25
پاتې ډاټا باید د 1024 بایټس سره سمون ولري.
د بلاک لیږد پای چوکاټ څه ډول ښکاري:
fd 25 - د بلاک لیږد پای ته رسیدو سیګنال. راتلونکی 2f 52 - پاتې فایل تر 1024 بایټ پورې اندازه کې. 2f 52، د پروتوکول لخوا قضاوت کول، د 16-bit CRC چکسم دی.
د زاړه وختونو لپاره ، ما په C کې یو برنامه رامینځته کړې چې له فایل څخه 1024 بایټونه راوباسي او د 16-bit CRC محاسبه کړي. د برنامه په لاره اچولو وښودله چې دا د 16-bit CRC نه دی. بیا ستومانه - د شاوخوا دریو ورځو لپاره. دا ټول وخت زه هڅه کوم چې پوه شم چې دا څه کیدی شي، که چکسم نه وي. په داسې حال کې چې د انګلیسي ژبې سایټونه مطالعه کول، ما وموندله چې ایکس موډیم خپل د چکسم محاسبه کاروي - CRC-CCITT (XModem). ما د دې محاسبې هیڅ C تطبیق ونه موندل، مګر ما یو سایټ وموند چې دا چیکسم آنلاین محاسبه کړي. زما د فایل 1024 بایټس ویب پاڼې ته لیږدولو سره، سایټ ما ته یو چکسم وښوده چې په بشپړه توګه د فایل څخه چکسم سره سمون لري.
هورې! وروستۍ معما حل شوه، اوس زه اړتیا لرم چې خپل فرم ویئر جوړ کړم. بیا، ما خپله پوهه (او دا یوازې زما په سر کې پاتې شوه) الیا ته انتقال کړه، څوک چې د پیتون پیاتون پیژني.
د پروګرام جوړول
الیا الیشین راپور ورکوي.
د مناسبو لارښوونو په ترلاسه کولو سره، زه ډیر "خوښ" وم.
له کومه ځایه پیل کړو؟ دا سمه ده، له پیل څخه. د USB پورټ څخه د ډمپ اخیستلو څخه.
USB-pcap پیل کړئ
هغه بندر غوره کړئ چې وسیله ورسره وصل ده او هغه فایل چې موږ به یې ډمپ خوندي کړو.
موږ سکینر له ماشین سره وصل کوو چیرې چې د وینډوز لپاره اصلي EZConfigScanning سافټویر نصب شوی.
پدې کې موږ وسیله ته د امرونو لیږلو لپاره توکي پیدا کوو. مګر د ټیمونو په اړه څه؟ زه دوی چیرته ترلاسه کولی شم؟
کله چې برنامه پیل شي ، تجهیزات په اوتومات ډول رایه ورکول کیږي (موږ به دا یو څه وروسته وګورو). او د رسمي تجهیزاتو اسنادو څخه د روزنې بارکوډونه شتون درلود. DEFALT. دا زموږ ټیم دی.
اړین معلومات ترلاسه شوي. د wireshark له لارې dump.pcap خلاص کړئ.
بلاک کول کله چې د EZConfigScanning پیل کول. هغه ځایونه چې تاسو ورته اړتیا لرئ پاملرنه وکړئ په سور نښه شوي.
د لومړي ځل لپاره د دې ټولو په لیدو، زړه مې له لاسه ورکړ. دا روښانه نده چې چیرته کیندل شي.
یو څه مغز او او... آه! په ډنډ کې څخه - ده inاو in دا څخه.
ما ګوګل وکړ چې URB_INTERRUPT څه شی دی. ما وموندله چې دا د معلوماتو لیږد طریقه ده. او دلته 4 داسې میتودونه شتون لري: کنټرول، مداخله، isochronous، بلک. تاسو کولی شئ د دوی په اړه په جلا توګه ولولئ.
او د 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 کې ګورو.
غوره! د سیسټم بارکوډونه هیکس ته واړوئ. دا دی، د روزنې فعالیت چمتو دی.
د فرم ویئر په اړه څه؟ هر څه ورته ښکاري، مګر یو څه توپیر شتون لري.
د فلش کولو پروسې بشپړ ډمپ اخیستو سره ، موږ نږدې پوهیږو چې موږ ورسره څه معامله کوو. دلته د XMODEM په اړه یوه مقاله ده، کوم چې په دې پوهیدلو کې خورا ګټور و چې دا اړیکه څنګه واقع کیږي، که څه هم په عمومي شرایطو کې: زه یې د لوستلو وړاندیز کوم.
ډمپ ته په کتلو سره، تاسو لیدلی شئ چې د چوکاټ اندازه 1024 ده، او د URB ډیټا اندازه 64 ده.
نو ځکه - 1024/64 - موږ په یو بلاک کې 16 لینونه ترلاسه کوو، د فرم ویئر فایل 1 کریکٹر په یو وخت کې ولولئ او یو بلاک جوړ کړئ. په بلاک کې د 1 کرښې بشپړول د ځانګړي حروف 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