Një detyrë për një zhvillues, ose si ne ndezëm skanerët e dorës pa një shitës

Pershendetje te gjitheve

Ne, Viktor Antipov dhe Ilya Aleshin, sot do të flasim për përvojën tonë të punës me pajisjet USB përmes Python PyUSB dhe pak për inxhinierinë e kundërt.

parahistorinë

Në vitin 2019, Dekreti i Qeverisë së Federatës Ruse Nr. 224 "Për miratimin e Rregullave për etiketimin e produkteve të duhanit me mjete identifikimi dhe veçoritë e zbatimit të një sistemi informacioni shtetëror për monitorimin e qarkullimit të mallrave që i nënshtrohen etiketimit të detyrueshëm me mjete identifikimi në lidhje me produktet e duhanit” hyri në fuqi.
Dokumenti shpjegon se nga 1 korriku 2019, prodhuesve u kërkohet të etiketojnë çdo paketë duhani. Dhe shpërndarësit e drejtpërdrejtë duhet t'i marrin këto produkte me ekzekutimin e një dokumenti transferimi universal (UDD). Dyqanet, nga ana tjetër, duhet të regjistrojnë shitjen e produkteve të etiketuara përmes arkës.

Gjithashtu, nga data 1 korrik 2020 ndalohet qarkullimi i produkteve të duhanit pa etiketa. Kjo do të thotë që të gjitha paketat e cigareve duhet të shënohen me një barkod të veçantë Datamatrix. Për më tepër - një pikë e rëndësishme - doli që Datamatrix nuk do të jetë e zakonshme, por e kundërt. Kjo është, jo kodi i zi në të bardhë, por anasjelltas.

Ne testuam skanerët tanë dhe rezultoi se shumica e tyre duhet të rifreskohen / ritrajnohen, përndryshe ata thjesht nuk janë në gjendje të punojnë normalisht me këtë barkod. Kjo kthesë e ngjarjeve na garantoi një dhimbje koke të fortë, sepse kompania jonë ka shumë dyqane që janë të shpërndara në një territor të gjerë. Disa dhjetëra mijëra kasa - dhe shumë pak kohë.

Çfarë duhej bërë? Ka dy opsione. Së pari: inxhinierët në terren rifreskojnë dhe rregullojnë manualisht skanerët. Së dyti: ne punojmë nga distanca dhe, mundësisht, mbulojmë shumë skanerë në të njëjtën kohë në një përsëritje.

Opsioni i parë, padyshim, nuk ishte i përshtatshëm për ne: do të duhej të shpenzonim para për vizitën e inxhinierëve, dhe në këtë rast do të ishte e vështirë të kontrollohej dhe koordinohej procesi. Por gjëja më e rëndësishme është se njerëzit do të punonin, domethënë, ne potencialisht do të merrnim shumë gabime dhe, me shumë mundësi, nuk do të përmbushnim afatin.

Opsioni i dytë është i mirë për të gjithë, nëse jo për një gjë. Disa shitës nuk kishin mjetet e ndezjes në distancë që na duheshin për të gjitha sistemet operative të kërkuara. Dhe duke qenë se afatet po mbaronin, më duhej të mendoja me kokën time.

Më pas, ne do t'ju tregojmë se si kemi zhvilluar mjete për skanerët e dorës për sistemin operativ Debian 9.x (të gjitha arkat tona janë në Debian).

Zgjidheni enigmën: si të ndezni një skaner

Raporton Victor Antipov.

Shërbimi zyrtar i ofruar nga shitësi funksionon nën Windows, dhe vetëm me IE. Programi mund të pulsojë dhe të konfigurojë skanerin.

Meqenëse sistemi ynë i synuar është Debian, ne instaluam një server ridrejtues usb në Debian dhe një klient të ridrejtues usb në Windows. Duke përdorur shërbimet e ridrejtuesit të usb, ne e përcollëm skanerin nga një makinë Linux në një makinë Windows.

Një mjet nga një shitës i Windows e pa skanerin dhe madje e ndezi atë normalisht. Kështu, ne bëmë përfundimin e parë: asgjë nuk varet nga OS, është një çështje e protokollit ndezës.

NE RREGULL. Ne e ndezëm ndezjen në makinën Windows dhe hoqëm deponinë në makinën Linux.

Ne e futëm deponinë në WireShark dhe... u trishtuam (do të heq disa nga detajet e deponisë, ato nuk janë me interes).

Çfarë na tregoi hale:

Adresat 0000-0030, duke gjykuar nga Wireshark, janë informacione të shërbimit USB.

Na interesonte pjesa 0040-0070.

Asgjë nuk ishte e qartë nga një kornizë transmetimi përveç personazheve MOCFT. Këto karaktere rezultuan të ishin karaktere nga skedari i firmuerit, si dhe karakteret e mbetura deri në fund të kornizës (skedari i firmuerit është i theksuar):

Çfarë nënkuptonin simbolet fd 3e 02 01 fe, unë personalisht, si Ilya, nuk e kisha idenë.

Shikova kornizën e mëposhtme (informacioni i shërbimit është hequr këtu, skedari i firmuerit është theksuar):

Çfarë u bë e qartë? Se dy bajtët e parë janë një lloj konstante. Të gjitha blloqet pasuese e konfirmuan këtë, por para përfundimit të bllokut të transmetimit:

Ky kuadër ishte gjithashtu mahnitës, pasi konstantja kishte ndryshuar (e theksuar) dhe, çuditërisht, kishte një pjesë të skedarit. Madhësia e bajtëve të transferuar të skedarit tregoi se u transferuan 1024 bajtë. Përsëri nuk e dija se çfarë nënkuptonin bajtët e mbetur.

Para së gjithash, si një pseudonim i vjetër BBS, unë rishikova protokollet standarde të transmetimit. Asnjë protokoll i transmetuar 1024 bajt. Fillova të studioja harduerin dhe hasa në protokollin 1K Xmodem. Ai lejoi transferimin e 1024, por me një paralajmërim: në fillim vetëm 128, dhe vetëm nëse nuk kishte gabime, protokolli rriti numrin e bajteve të transferuara. Menjëherë pata një transferim prej 1024 bajt. Vendosa të studioj protokollet e transmetimit, dhe veçanërisht modemin X.

Kishte dy variacione të modemit.

Së pari, formati i paketës XMODEM me mbështetje CRC8 (XMODEM origjinal):

Së dyti, formati i paketës XMODEM me mbështetje CRC16 (XmodemCRC):

Duket e ngjashme, me përjashtim të SOH, numrit të paketës dhe CRC dhe gjatësisë së paketës.

Shikova fillimin e bllokut të dytë të transmetimit (dhe përsëri pashë skedarin e firmuerit, por tashmë i futur me 1024 bajt):

Pashë kokën e njohur fd 3e 02, por dy bajtët e ardhshëm kishin ndryshuar tashmë: ishte 01 fe dhe u bë 02 fd. Pastaj vura re se blloku i dytë tani kishte numër 02 dhe kështu kuptova: para meje ishte numërimi i bllokut të transmetimit. Ingranazhi i parë 1024 është 01, i dyti është 02, i treti është 03 dhe kështu me radhë (por në heks, natyrisht). Por çfarë do të thotë ndryshimi nga fe në fd? Sytë panë një ulje me 1, truri kujtoi se programuesit numërojnë nga 0, jo nga 1. Por atëherë pse blloku i parë është 1, dhe jo 0? Ende nuk e kam gjetur përgjigjen për këtë pyetje. Por kuptova se si llogaritet blloku i dytë. Blloku i dytë nuk është asgjë më shumë se FF - (minus) numri i bllokut të parë. Kështu, blloku i dytë u caktua si = 02 (FF-02) = 02 FD. Leximi i mëpasshëm i deponisë konfirmoi supozimin tim.

Pastaj filloi të shfaqej fotografia e mëposhtme e transmetimit:

Fillimi i transmetimit
fd 3e 02 – Fillimi
01 FE – numërues transmisioni
Transferimi (34 blloqe, 1024 bajt të transferuara)
fd 3e 1024 bajt të dhëna (të ndara në blloqe 30 bajte).
Fundi i transmetimit
fd 25

Të dhënat e mbetura për t'u rreshtuar në 1024 bajt.

Si duket korniza fundore e transmetimit të bllokut:

fd 25 – transmetimi i sinjalit në bllokun fundor. Tjetra 2f 52 – pjesa tjetër e skedarit deri në 1024 bajt në madhësi. 2f 52, duke gjykuar nga protokolli, është një kontroll CRC 16-bit.

Për hir të kohërave të vjetra, bëra një program në C që nxori 1024 bajt nga një skedar dhe llogariti një CRC 16-bit. Nisja e programit tregoi se ky nuk është një CRC 16-bit. Stupor përsëri - për rreth tre ditë. Gjatë gjithë kësaj kohe po përpiqesha të kuptoja se çfarë mund të ishte, nëse jo një kontroll. Ndërsa studioja faqet në gjuhën angleze, zbulova se modemi X përdor llogaritjen e tij të kontrollit - CRC-CCITT (XModem). Unë nuk gjeta ndonjë implementim C të kësaj llogaritjeje, por gjeta një faqe që llogariti këtë shumë kontrolli në internet. Pasi transferova 1024 bajt të skedarit tim në faqen e internetit, faqja më tregoi një shumë kontrolli që përputhej plotësisht me shumën e kontrollit nga skedari.

Hora! Gjëegjëza e fundit u zgjidh, tani më duhej të bëja firmware-in tim. Më pas, ia kalova njohuritë e mia (dhe më mbetën vetëm në kokë) Ilya-s, i cili është i njohur me paketën e fuqishme të mjeteve Python.

Krijimi i një programi

Raporton Ilya Aleshin.

Pasi mora udhëzimet e duhura, isha shumë "i lumtur".

Ku të fillojë? Ashtu është, që në fillim.  Nga marrja e një deponie nga porta USB.

Hapni USB-pcap https://desowin.org/usbpcap/tour.html

Zgjidhni portën në të cilën është lidhur pajisja dhe skedarin ku do të ruajmë deponinë.

Ne e lidhim skanerin me një makinë ku është instaluar softueri vendas EZConfigScanning për Windows.

Në të gjejmë artikullin për dërgimin e komandave në pajisje. Por çfarë ndodh me ekipet? Ku mund t'i marr ato?
Kur programi fillon, pajisja anketohet automatikisht (këtë do ta shohim pak më vonë). Dhe kishte barkode trajnimi nga dokumentet zyrtare të pajisjeve. SHFALTUAR. Ky është ekipi ynë.

Të dhënat e nevojshme janë marrë. Hapni dump.pcap nëpërmjet wireshark.

Blloko kur fillon EZConfigScanning. Vendet që duhet t'i kushtoni vëmendje janë shënuar me të kuqe.

Duke parë të gjitha këto për herë të parë, më humbi zemra. Nuk është e qartë se ku të gërmoni më pas.

Pak mendime dhe-dhe-dhe... Aha! Në hale nga - kjo inDhe in это nga.

Kërkova në google se çfarë është URB_INTERRUPT. Zbulova se kjo është një metodë e transferimit të të dhënave. Dhe ka 4 metoda të tilla: kontrolli, ndërprerja, izokron, pjesa më e madhe. Ju mund të lexoni rreth tyre veç e veç.

Dhe adresat e pikës fundore në ndërfaqen e pajisjes USB mund të merren ose përmes komandës "lsusb –v" ose duke përdorur pyusb.

Tani duhet të gjejmë të gjitha pajisjet me këtë VID. Ju mund të kërkoni në mënyrë specifike me VID:PID.

Duket kështu:

Pra, ne kemi informacionin e nevojshëm: komandat P_INFO. ose DEFALT, adreson ku të shkruajnë komandat endpoint=03 dhe ku të merret përgjigja endpoint=86. Gjithçka që mbetet është të konvertohen komandat në hex.

Meqenëse e kemi gjetur tashmë pajisjen, le ta shkëputim atë nga kerneli...

...dhe shkruani në pikën fundore me adresën 0x03,

... dhe më pas lexoni përgjigjen nga pika e fundit me adresën 0x86.

Përgjigje e strukturuar:

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

Ne i shohim këto të dhëna në dump.pcap.

E madhe! Konvertoni barkodet e sistemit në hex. Kjo është e gjitha, funksionaliteti i trajnimit është gati.

Po firmware-i? Gjithçka duket se është e njëjtë, por ka një nuancë.

Pasi morëm një hale të plotë të procesit të ndezjes, përafërsisht kuptuam se me çfarë kishim të bënim. Këtu është një artikull rreth XMODEM, i cili ishte shumë i dobishëm për të kuptuar se si ndodh ky komunikim, megjithëse në terma të përgjithshëm: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html Unë rekomandoj ta lexoni.

Duke parë deponinë, mund të shihni se madhësia e kornizës është 1024, dhe madhësia e të dhënave URB është 64.

Prandaj - 1024/64 – marrim 16 rreshta në një bllok, lexojmë skedarin e firmuerit 1 karakter në të njëjtën kohë dhe formojmë një bllok. Plotësimi i 1 rreshti në një bllok me karaktere speciale fd3e02 + numrin e bllokut.
14 rreshtat e ardhshëm plotësohen me fd25 +, duke përdorur XMODEM.calc_crc() ne llogarisim shumën e kontrollit të të gjithë bllokut (u desh shumë kohë për të kuptuar se "FF - 1" është CSUM) dhe rreshti i fundit, i 16-të plotësohet. me fd3e.

Duket se kjo është ajo, lexoni skedarin e firmuerit, goditni blloqet, shkëputni skanerin nga kerneli dhe dërgojeni në pajisje. Por nuk është kaq e thjeshtë. Skaneri duhet të kalojë në modalitetin e firmuerit,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Nga eshte ky ekip?? Nga hale.

Por ne nuk mund të dërgojmë një bllok të tërë në skaner për shkak të kufirit 64:

Epo, skaneri në modalitetin e ndezjes NEWAPP nuk pranon heks. Prandaj, do të duhet të përktheni çdo rresht 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]

Dhe pastaj dërgoni këto të dhëna në skaner.

Ne marrim përgjigjen:

[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]

Nëse kontrolloni artikullin për XMODEM, do të bëhet e qartë: të dhënat janë pranuar.

Pasi të jenë transferuar të gjitha blloqet, ne përfundojmë transferimin END_TRANSFER = 'xfdx01x04'.

Epo, meqenëse këto blloqe nuk mbajnë asnjë informacion për njerëzit e zakonshëm, ne do ta instalojmë firmware-in në modalitetin e fshehur si parazgjedhje. Dhe për çdo rast, ne do të organizojmë një shirit progresi përmes tqdm.

Në fakt, atëherë bëhet fjalë për gjëra të vogla. E tëra që mbetet është të mbështillni zgjidhjen në skriptet për përsëritje masive në një kohë të përcaktuar qartë, në mënyrë që të mos ngadalësoni procesin e punës në arka dhe të shtoni prerje.

Total

Pasi kemi shpenzuar shumë kohë, përpjekje dhe qime në kokë, ne kemi mundur të zhvillojmë zgjidhjet që na nevojiteshin, si dhe përmbushëm afatin. Në të njëjtën kohë, skanerët tani janë rifreskuar dhe ritrajnuar në mënyrë qendrore, ne kontrollojmë qartë të gjithë procesin. Kompania kurseu kohë dhe para, dhe ne fituam përvojë të paçmuar në pajisjet e inxhinierisë së kundërt të këtij lloji.

Burimi: www.habr.com