Pozdravljeni vsi.
Midva, Viktor Antipov in Ilya Aleshin, bova danes govorila o naših izkušnjah pri delu z napravami USB prek Python PyUSB in malo o obratnem inženirstvu.
prazgodovina
Leta 2019 je bila izdana Uredba Vlade Ruske federacije št. 224 »O potrditvi Pravil za označevanje tobačnih izdelkov z identifikacijskimi sredstvi in značilnostih izvajanja državnega informacijskega sistema za spremljanje prometa blaga, ki je predmet obveznega označevanja z identifikacijskimi sredstvi v zvezi s tobačnimi izdelki«.
Dokument pojasnjuje, da morajo proizvajalci od 1. julija 2019 označiti vsako škatlico tobaka. In neposredni distributerji morajo te izdelke prejeti z izvedbo univerzalnega prenosnega dokumenta (UDD). Trgovine pa morajo registrirati prodajo označenih izdelkov prek blagajne.
Prav tako je s 1. julijem 2020 prepovedan promet neoznačenih tobačnih izdelkov. To pomeni, da morajo biti vse škatlice cigaret označene s posebno črtno kodo Datamatrix. Poleg tega - pomembna točka - izkazalo se je, da Datamatrix ne bo navaden, ampak inverzen. Se pravi, ne črna koda na belem, ampak obratno.
Preizkusili smo naše skenerje in izkazalo se je, da jih je večino treba na novo preoblikovati/preučiti, sicer preprosto ne morejo normalno delati s to črtno kodo. Ta razplet dogodkov nam je zagotovil hud glavobol, saj ima naše podjetje veliko trgovin, ki so razpršene na velikem ozemlju. Nekaj deset tisoč blagajn – in zelo malo časa.
Kaj je bilo storiti? Obstajata dve možnosti. Prvič: inženirji na kraju samem ročno osvežijo in prilagodijo skenerje. Drugič: delamo na daljavo in po možnosti pokrivamo več skenerjev hkrati v eni ponovitvi.
Prva možnost za nas očitno ni bila primerna: morali bi porabiti denar za gostujoče inženirje, v tem primeru pa bi bilo težko nadzorovati in koordinirati proces. Najpomembneje pa je, da bi ljudje delali, se pravi, potencialno bi dobili veliko napak in najverjetneje ne bi dosegli roka.
Druga možnost je dobra za vse, če ne za eno stvar. Nekateri prodajalci niso imeli orodij za daljinsko utripanje, ki smo jih potrebovali za vse zahtevane operacijske sisteme. In ker so se roki iztekali, sem moral razmišljati s svojo glavo.
Nato vam bomo povedali, kako smo razvili orodja za ročne skenerje za OS Debian 9.x (vse naše blagajne so na Debianu).
Rešite uganko: kako bliskati skener
Victor Antipov poroča.
Uradni pripomoček, ki ga ponuja prodajalec, deluje v sistemu Windows in samo v IE. Pripomoček lahko utripa in konfigurira optični bralnik.
Ker je naš ciljni sistem Debian, smo na Debian namestili strežnik usb-redirector, v Windows pa odjemalca usb-redirector. S pomožnimi programi usb-redirector smo posredovali skener iz stroja Linux v stroj Windows.
Pripomoček proizvajalca sistema Windows je videl optični bralnik in ga celo normalno utripal. Tako smo naredili prvi zaključek: nič ni odvisno od OS, to je stvar utripajočega protokola.
V REDU. Zagnali smo utripanje na računalniku Windows in odstranili izpis na računalniku Linux.
Dump smo stlačili v WireShark in ... postali žalostni (nekatere podrobnosti dumpa bom izpustil, niso zanimivi).
Kaj nam je pokazalo smetišče:
Naslovi 0000-0030, sodeč po Wiresharku, so informacije o storitvi USB.
Zanimal nas je del 0040-0070.
Iz enega prenosnega okvirja ni bilo nič jasno, razen znakov MOCFT. Izkazalo se je, da so ti znaki znaki iz datoteke vdelane programske opreme, pa tudi preostali znaki do konca okvira (datoteka vdelane programske opreme je označena):
Kaj pomenijo simboli fd 3e 02 01 fe, osebno, tako kot Ilya, nisem imel pojma.
Ogledal sem si naslednji okvir (servisne informacije so bile tukaj odstranjene, datoteka vdelane programske opreme je bila označena):
Kaj je postalo jasno? Da sta prva dva bajta nekakšna konstanta. Vsi naslednji bloki so to potrdili, vendar pred koncem bloka prenosa:
Tudi ta okvir je bil osupljiv, saj se je konstanta spremenila (poudarjena) in, kar je nenavadno, obstajal del datoteke. Velikost prenesenih bajtov datoteke je pokazala, da je bilo prenesenih 1024 bajtov. Spet nisem vedel, kaj pomenijo preostali bajti.
Najprej sem kot stari vzdevek BBS pregledal standardne protokole prenosa. Noben protokol ni prenesel 1024 bajtov. Začel sem preučevati strojno opremo in naletel na protokol 1K Xmodem. Omogočal je prenos 1024, vendar z opozorilom: sprva le 128 in šele če ni bilo napak, je protokol povečal število prenesenih bajtov. Takoj sem imel prenos 1024 bajtov. Odločil sem se preučiti prenosne protokole, še posebej X-modem.
Obstajali sta dve različici modema.
Prvič, format paketa XMODEM s podporo za CRC8 (izvirni XMODEM):
Drugič, format paketa XMODEM s podporo CRC16 (XmodemCRC):
Videti je podobno, razen SOH, številke paketa in CRC ter dolžine paketa.
Pogledal sem na začetek drugega prenosnega bloka (in spet videl datoteko vdelane programske opreme, vendar že zamaknjeno za 1024 bajtov):
Videl sem znano glavo fd 3e 02, vendar sta se naslednja dva bajta že spremenila: bila je 01 fe in postala 02 fd. Potem sem opazil, da je drugi blok zdaj oštevilčen z 02 in tako razumel: pred menoj je oštevilčenje oddajnega bloka. Prva prestava 1024 je 01, druga je 02, tretja je 03 in tako naprej (seveda v hex). Toda kaj pomeni sprememba iz fe v fd? Oči so videle zmanjšanje za 1, možgani so se spomnili, da programerji štejejo od 0, ne od 1. Toda zakaj je potem prvi blok 1 in ne 0? Še vedno nisem našel odgovora na to vprašanje. Sem pa razumel, kako se šteje drugi blok. Drugi blok ni nič drugega kot FF – (minus) številka prvega bloka. Tako je bil drugi blok označen kot = 02 (FF-02) = 02 FD. Naknadno branje odlagališča je potrdilo mojo domnevo.
Nato se je začela pojavljati naslednja slika prenosa:
Začetek prenosa
fd 3e 02 – Začetek
01 FE – števec prenosa
Prenos (34 blokov, 1024 bajtov prenesenih)
fd 3e 1024 bajtov podatkov (razdeljenih na 30 bajtne bloke).
Konec prenosa
fd 25
Preostale podatke je treba poravnati na 1024 bajtov.
Kako izgleda končni okvir prenosa bloka:
fd 25 – prenos signala do končnega bloka. Naprej 2f 52 – preostali del datoteke do velikosti 1024 bajtov. 2f 52 je, sodeč po protokolu, 16-bitna kontrolna vsota CRC.
Za stare čase sem naredil program v C, ki je iz datoteke potegnil 1024 bajtov in izračunal 16-bitni CRC. Zagon programa je pokazal, da to ni 16-bitni CRC. Spet omamljenost - kakšne tri dni. Ves ta čas sem poskušal razumeti, kaj bi lahko bilo, če ne kontrolna vsota. Med preučevanjem spletnih strani v angleškem jeziku sem odkril, da X-modem uporablja lasten izračun kontrolne vsote - CRC-CCITT (XModem). Nisem našel nobene izvedbe tega izračuna v jeziku C, sem pa našel spletno mesto, ki je na spletu izračunalo to kontrolno vsoto. Po prenosu 1024 bajtov moje datoteke na spletno stran mi je spletno mesto pokazalo kontrolno vsoto, ki se popolnoma ujema s kontrolno vsoto iz datoteke.
Hura! Zadnja uganka je bila rešena, zdaj sem moral izdelati svojo strojno programsko opremo. Nato sem svoje znanje (in je ostalo le v moji glavi) prenesel na Ilya, ki pozna zmogljiv komplet orodij Python.
Ustvarjanje programa
Poroča Ilya Aleshin.
Ko sem prejel ustrezna navodila, sem bil zelo »srečen«.
Kje začeti? Tako je, od začetka. Iz kopiranja podatkov iz vrat USB.
Zaženite USB-pcap
Izberemo vrata, na katera je naprava povezana in datoteko, kamor bomo shranili izpis.
Skener povežemo s strojem, kjer je nameščena izvorna programska oprema EZConfigScanning za Windows.
V njem najdemo postavko za pošiljanje ukazov napravi. Kaj pa ekipe? Kje jih lahko dobim?
Ko se program zažene, se oprema samodejno vpraša (to bomo videli malo kasneje). In tam so bile črtne kode za usposabljanje iz uradnih dokumentov opreme. DEFALT. To je naša ekipa.
Potrebni podatki so bili prejeti. Odprite dump.pcap prek wireshark.
Blokiraj ob zagonu EZConfigScanning. Mesta, na katera morate biti pozorni, so označena z rdečo barvo.
Ko sem vse to videl prvič, mi je padlo srce. Ni jasno, kje kopati naprej.
Malo pametovanja in-in-in... Aha! Na smetišču ven - Je inIn in это ven.
Poguglal sem, kaj je URB_INTERRUPT. Ugotovil sem, da je to način prenosa podatkov. In obstajajo 4 takšne metode: nadzor, prekinitev, izokrono, razsuto. O njih lahko preberete ločeno.
In naslove končne točke v vmesniku naprave USB je mogoče pridobiti prek ukaza »lsusb –v« ali z uporabo pyusb.
Zdaj moramo najti vse naprave s tem VID. Iščete lahko posebej po VID:PID.
Izgleda takole:
Torej imamo potrebne informacije: ukaze P_INFO. ali DEFALT, naslovi, kam napisati ukaze endpoint=03 in kje dobiti odgovor endpoint=86. Vse, kar ostane, je pretvoriti ukaze v hex.
Ker smo napravo že našli, jo odklopimo od jedra ...
...in pisati na končno točko z naslovom 0x03,
... in nato preberi odgovor s končne točke z naslovom 0x86.
Strukturiran odgovor:
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: 0x6986Te podatke vidimo v dump.pcap.
Super! Pretvori sistemske črtne kode v hex. To je to, funkcionalnost usposabljanja je pripravljena.
Kaj pa firmware? Zdi se, da je vse enako, vendar obstaja odtenek.
Po popolnem pregledu procesa utripanja smo približno razumeli, s čim imamo opravka. Tukaj je članek o XMODEM, ki je bil v veliko pomoč pri razumevanju, kako poteka ta komunikacija, čeprav na splošno: Priporočam v branje.
Če pogledate izpis, lahko vidite, da je velikost okvirja 1024, velikost podatkov URB pa 64.
Torej – 1024/64 – dobimo 16 vrstic v bloku, preberemo firmware datoteko po 1 znak naenkrat in oblikujemo blok. Dopolnitev 1 vrstice v bloku s posebnimi znaki fd3e02 + številka bloka.
Naslednjih 14 vrstic je dopolnjenih s fd25 +, z uporabo XMODEM.calc_crc() izračunamo kontrolno vsoto celotnega bloka (tradilo je veliko časa, da smo razumeli, da je "FF – 1" CSUM) in zadnja, 16. vrstica je dopolnjena z fd3e.
Zdi se, da je to to, preberite datoteko vdelane programske opreme, pritisnite bloke, odklopite skener iz jedra in ga pošljite v napravo. A ni tako preprosto. Optični bralnik je treba preklopiti v način vdelane programske opreme,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Od kod je ta ekipa?? Iz smetišča.
Vendar ne moremo poslati celotnega bloka v skener zaradi omejitve 64:
No, optični bralnik v utripajočem načinu NEWAPP ne sprejema hex. Zato boste morali prevesti vsako vrstico 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]In nato te podatke pošljite v skener.
Dobimo odgovor:
[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]Če pogledate članek o XMODEM-u, bo jasno: podatki so bili sprejeti.
Ko so vsi bloki preneseni, zaključimo prenos END_TRANSFER = 'xfdx01x04'.
No, ker ti bloki ne nosijo nobenih informacij za navadne ljudi, bomo vdelano programsko opremo privzeto namestili v skritem načinu. In za vsak slučaj bomo prek tqdm organizirali vrstico napredka.
Pravzaprav gre potem za malenkosti. Preostane le, da rešitev zavijemo v skripte za množično replikacijo ob točno določenem času, da ne upočasnimo procesa dela na blagajnah, in dodamo beleženje.
Skupaj
Po porabi veliko časa in truda ter las na glavi nam je uspelo razviti rešitve, ki smo jih potrebovali, in se tudi držati roka. Hkrati so skenerji zdaj centralno osveženi in preučeni, jasno nadzorujemo celoten proces. Podjetje je prihranilo čas in denar, pridobili pa smo neprecenljive izkušnje s tovrstno opremo za obratno inženirstvo.
Vir: www.habr.com