Бүгдээрээ сайн байцгаана уу.
Бид Виктор Антипов, Илья Алешин нар өнөөдөр Python PyUSB-ээр дамжуулан USB төхөөрөмжтэй ажиллах туршлага, урвуу инженерийн талаар бага зэрэг ярих болно.
Эрьт урьдын түүх
ОХУ-ын Засгийн газрын 2019 оны 224 тоот "Тамхины бүтээгдэхүүнийг таних хэрэгслээр шошголох журам, таних хэрэгслээр заавал шошголох ёстой барааны эргэлтэд хяналт тавих төрийн мэдээллийн системийг хэрэгжүүлэх онцлог шинж чанаруудыг батлах тухай" тогтоол. тамхины бүтээгдэхүүнтэй холбоотой” хууль хүчин төгөлдөр болсон.
Баримт бичигт 1 оны долдугаар сарын 2019-нээс тамхины хайрцаг бүрийг үйлдвэрлэгчид шошголох шаардлагатай гэж тайлбарлажээ. Шууд борлуулагчид эдгээр бүтээгдэхүүнийг бүх нийтийн шилжүүлгийн баримт бичгийн (UDD) гүйцэтгэснээр хүлээн авах ёстой. Дэлгүүрүүд эргээд хаяг шошготой бүтээгдэхүүнээ кассын машинаар дамжуулан бүртгэх шаардлагатай болдог.
Мөн 1 оны долдугаар сарын 2020-нээс шошгогүй тамхины бүтээгдэхүүнийг эргэлтэд оруулахыг хориглосон. Энэ нь бүх тамхины хайрцаг нь тусгай Datamatrix бар кодоор тэмдэглэгдсэн байх ёстой гэсэн үг юм. Түүнээс гадна - нэг чухал зүйл бол Датаматриц нь энгийн биш, харин урвуу байх болно. Энэ нь цагаан дээр хар код биш, харин эсрэгээр.
Бид сканнеруудаа туршиж үзсэн бөгөөд ихэнхийг нь дахин шинэчлэх/дахин сургах шаардлагатай, эс тэгвээс тэд энэ бар кодтой хэвийн ажиллах боломжгүй болох нь тогтоогдсон. Манай компани өргөн уудам нутаг дэвсгэрт тархсан олон дэлгүүртэй тул үйл явдлын энэ эргэлт нь бидний толгойны өвчинг ихэсгэсэн. Хэдэн арван мянган кассын машин - маш бага хугацаа.
Юу хийх ёстой байсан бэ? Хоёр сонголт байна. Нэгдүгээрт: газар дээрх инженерүүд сканнеруудыг гараар сэргээж, тохируулдаг. Хоёрдугаарт: бид алсаас ажилладаг бөгөөд нэг давталтаар олон сканнерыг нэг дор хамрах нь дээр.
Эхний сонголт нь бидний хувьд тохиромжгүй байсан нь ойлгомжтой: бид инженерүүдээр зочлоход мөнгө зарцуулах шаардлагатай байсан бөгөөд энэ тохиолдолд үйл явцыг хянах, зохицуулахад хэцүү байх болно. Гэхдээ хамгийн чухал зүйл бол хүмүүс ажиллах болно, өөрөөр хэлбэл бид маш их алдаа гаргаж магадгүй бөгөөд эцсийн хугацаа нь дуусахгүй байх магадлалтай.
Хоёрдахь сонголт нь нэг зүйл биш юмаа гэхэд хүн бүрт тохиромжтой. Зарим үйлдвэрлэгчид шаардлагатай бүх үйлдлийн системд хэрэгтэй алсын зайнаас анивчих хэрэгсэл байхгүй байсан. Тэгээд хугацаа дуусч байгаа болохоор өөрийнхөөрөө бодох хэрэгтэй болсон.
Дараа нь бид Debian 9.x үйлдлийн системд (манай бүх кассын машинууд Debian дээр байдаг) гарын авлагын сканнерын хэрэгслүүдийг хэрхэн бүтээсэн тухай танд хэлэх болно.
Оньсого шийд: сканнерыг хэрхэн яаж асаах вэ
Виктор Антипов мэдээлэв.
Үйлдвэрлэгчээс өгсөн албан ёсны хэрэгсэл нь Windows үйлдлийн систем дээр зөвхөн IE дээр ажилладаг. Уг хэрэгсэл нь сканнерыг анивчуулж, тохируулах боломжтой.
Бидний зорилтот систем Debian учраас бид Debian дээр USB дахин чиглүүлэгч сервер, Windows дээр USB дахин чиглүүлэгч клиент суулгасан. Usb-redirector хэрэгслийг ашиглан бид сканнерыг Линукс машинаас Windows машин руу шилжүүлсэн.
Windows үйлдвэрлэгчийн хэрэгсэл нь скан хийгчийг хараад, тэр ч байтугай ердийн байдлаар анивчсан. Тиймээс бид эхний дүгнэлтийг хийсэн: үйлдлийн системээс юу ч хамаарахгүй, энэ нь анивчсан протоколын асуудал юм.
БОЛЖ БАЙНА УУ. Бид Windows машин дээр анивчдаг төхөөрөмжийг ажиллуулж, Линукс машин дээрх хогийн цэгийг устгасан.
Бид хогийн цэгийг WireShark руу чихээд... гунигтай байлаа (Би овоолгын зарим нарийн ширийнийг орхих болно, тэдгээр нь ямар ч сонирхолгүй).
Хогийн цэг бидэнд юу харуулав:
Wireshark-аас үзэхэд 0000-0030 хаягууд нь USB үйлчилгээний мэдээлэл юм.
Бид 0040-0070 хэсгийг сонирхож байсан.
Нэг дамжуулалтын хүрээнээс MOCFT тэмдэгтүүдээс өөр юу ч тодорхой байсангүй. Эдгээр тэмдэгтүүд нь програмын файлын тэмдэгтүүд, мөн хүрээний төгсгөл хүртэл үлдсэн тэмдэгтүүд болж хувирав (програм хангамжийн файлыг тодруулсан):
fd 3e 02 01 fe тэмдэгтүүд юу гэсэн үг болохыг би хувьдаа Илья шиг мэдэхгүй байсан.
Би дараах фреймийг харлаа (үйлчилгээний мэдээллийг энд устгасан, програм хангамжийн файлыг тодруулсан):
Юу тодорхой болсон бэ? Эхний хоёр байт нь зарим төрлийн тогтмол байдаг. Дараагийн бүх блокууд үүнийг баталгаажуулсан боловч дамжуулах блок дуусахаас өмнө:
Тогтмол өөрчлөгдсөн (тодруулсан) бөгөөд хачирхалтай нь файлын нэг хэсэг байсан тул энэ хүрээ бас тэнэг байсан. Файлын шилжүүлсэн байтуудын хэмжээ нь 1024 байтыг шилжүүлсэн болохыг харуулсан. Би үлдсэн байт нь юу гэсэн үг болохыг дахин мэдэхгүй байна.
Юуны өмнө, хуучин BBS хочны хувьд би стандарт дамжуулах протоколуудыг хянаж үзсэн. 1024 байтыг ямар ч протокол дамжуулаагүй. Би техник хангамжийг судалж эхэлсэн бөгөөд 1K Xmodem протоколтой танилцсан. Энэ нь 1024-ийг дамжуулахыг зөвшөөрсөн боловч анхааруулгатай: эхлээд зөвхөн 128, алдаа байхгүй тохиолдолд л протокол дамжуулагдсан байтын тоог нэмэгдүүлсэн. Би тэр даруй 1024 байт шилжүүлэг хийсэн. Би дамжуулах протоколууд, ялангуяа X-модемийг судлахаар шийдсэн.
Модемийн хоёр хувилбар байсан.
Нэгдүгээрт, 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 гэж тэмдэглэв. Хогийн цэгийг дараа нь уншсан нь миний таамаглалыг баталгаажуулав.
Дараа нь дамжуулалтын дараах зураг гарч эхлэв.
Дамжуулах эхлэл
fd 3e 02 - Эхлэх
01 FE - дамжуулах тоолуур
Дамжуулах (34 блок, 1024 байт шилжүүлсэн)
fd 3e 1024 байт өгөгдөл (30 байт блокт хуваагдана).
Дамжуулалтын төгсгөл
fd 25
Үлдсэн өгөгдлийг 1024 байттай зэрэгцүүлэх шаардлагатай.
Блок дамжуулалтын төгсгөлийн хүрээ ямар харагдаж байна:
fd 25 - блок дамжуулалтыг дуусгах дохио. Дараагийн 2f 52 - 1024 байт хүртэлх хэмжээтэй файлын үлдсэн хэсэг. Протоколоос харахад 2f 52 нь 16 битийн CRC шалгах нийлбэр юм.
Эрт дээр үед би C хэл дээр файлаас 1024 байт татаж аваад 16 битийн CRC тооцоолсон программ хийсэн. Хөтөлбөрийг эхлүүлснээр энэ нь 16 битийн CRC биш гэдгийг харуулсан. Дахин тэнэг - гурван өдөр орчим. Энэ бүх хугацаанд би шалгах нийлбэр биш юмаа гэхэд юу байж болохыг ойлгохыг хичээсэн. Англи хэл дээрх сайтуудыг судалж байхдаа би X-модем нь CRC-CCITT (XModem) гэсэн өөрийн хяналтын нийлбэр тооцоог ашигладаг болохыг олж мэдсэн. Би энэ тооцооны ямар ч C хэрэгжилтийг олж чадаагүй, гэхдээ би энэ шалгах нийлбэрийг онлайнаар тооцдог сайтыг олсон. Миний файлын 1024 байтыг вэб хуудас руу шилжүүлсний дараа сайт надад файлын шалгах нийлбэртэй бүрэн нийцсэн шалгах нийлбэрийг үзүүлэв.
Өө! Сүүлчийн оньсого тайлагдсан тул одоо би өөрөө програм хангамж хийх хэрэгтэй болсон. Дараа нь би өөрийн мэдлэгээ (мөн энэ нь зөвхөн миний толгойд үлдсэн) хүчирхэг хэрэгсэл Python-ийг мэддэг Илья руу дамжуулсан.
Програм үүсгэх
Илья Алешин мэдээлэв.
Тохирох зааварчилгааг хүлээн авсны дараа би маш их "баяртай" байлаа.
Хаанаас эхлэх вэ? Энэ бол анхнаасаа зөв. USB портоос дамп авахаас.
USB-pcap-г ажиллуулна уу
Төхөөрөмжийг холбосон порт болон хогийн цэгийг хадгалах файлыг сонгоно уу.
Бид сканнерыг Windows-д зориулсан EZConfigScanning програм хангамж суулгасан машинтай холбодог.
Үүнээс бид төхөөрөмж рүү тушаал илгээх зүйлийг олдог. Харин багууд яах вэ? Би тэднийг хаанаас авах вэ?
Хөтөлбөр эхлэхэд тоног төхөөрөмжийг автоматаар асуудаг (бид үүнийг дараа нь харах болно). Тэгээд албан ёсны тоног төхөөрөмжийн баримтаас сургалтын бар кодууд байсан. АНХААРСАН. Энэ бол манай баг.
Шаардлагатай мэдээллийг хүлээн авлаа. Wireshark-ээр дамжуулан dump.pcap-г нээнэ үү.
EZConfigScanning-г эхлүүлэх үед блокло. Таны анхаарах ёстой газруудыг улаанаар тэмдэглэсэн байна.
Энэ бүхнийг анх удаа хараад сэтгэл минь уналаа. Цаашид хаана ухах нь тодорхойгүй байна.
Жаахан оюуны довтолгоо ба-ба-ба... Аха! Хогийн цэгт гарч - байна inболон in энэ нь гарч.
Би URB_INTERRUPT гэж юу болохыг google-ээс хайлаа. Энэ бол өгөгдөл дамжуулах арга гэдгийг би олж мэдсэн. Ийм 4 арга байдаг: хяналт, тасалдал, изохрон, бөөн. Та тэдгээрийн талаар тусад нь уншиж болно.
USB төхөөрөмжийн интерфэйс дэх эцсийн цэгийн хаягийг "lsusb –v" команд эсвэл pyusb ашиглан авах боломжтой.
Одоо бид энэ VID бүхий бүх төхөөрөмжийг олох хэрэгтэй. Та VID:PID-ээр тусгайлан хайлт хийх боломжтой.
Энэ нь иймэрхүү харагдаж байна:
Тиймээс бидэнд шаардлагатай мэдээлэл байна: P_INFO тушаалууд. эсвэл DEFALT, командыг хаана бичих төгсгөлийн цэг=03, хариултын төгсгөлийн цэг=86 хаанаас авах хаягууд. Зөвхөн командуудыг hex болгон хөрвүүлэх л үлдлээ.
Бид төхөөрөмжийг аль хэдийн олсон тул цөмөөс нь салгацгаая...
...болон төгсгөлийн цэг рүү 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 тэмдэгтээр уншиж, блок үүсгэдэг. 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