Üdvözlet mindenkinek.
Mi, Viktor Antipov és Ilya Aleshin ma a Python PyUSB-n keresztüli USB-eszközökkel kapcsolatos tapasztalatainkról és egy kicsit a visszafejtésről beszélünk.
őstörténet
2019-ben az Orosz Föderáció kormányának 224. számú rendelete „A dohánytermékek azonosító eszközökkel történő címkézésére vonatkozó szabályok jóváhagyásáról és az azonosító eszközökkel kötelező címkézés alá eső áruk forgalmának ellenőrzésére szolgáló állami információs rendszer megvalósításának jellemzőiről” dohánytermékekkel kapcsolatban” lépett hatályba.
A dokumentum kifejti, hogy 1. július 2019-től a gyártók kötelesek minden egyes dohánycsomagot címkézni. A közvetlen forgalmazóknak pedig ezeket a termékeket egy univerzális transzferdokumentum (UDD) végrehajtásával kell megkapniuk. Az üzleteknek pedig a pénztárgépen keresztül regisztrálniuk kell a feliratozott termékek értékesítését.
Ezenkívül 1. július 2020-től tilos a címkézetlen dohánytermékek forgalmazása. Ez azt jelenti, hogy minden cigarettásdobozt speciális Datamatrix vonalkóddal kell megjelölni. Sőt - fontos szempont - kiderült, hogy a Datamatrix nem közönséges, hanem inverz lesz. Vagyis nem fekete kód fehérre, hanem fordítva.
Kipróbáltuk a szkennereinket, és kiderült, hogy a legtöbbjüket újra kell frissíteni/tanítani, különben egyszerűen nem tudnak normálisan működni ezzel a vonalkóddal. Ez a fordulat komoly fejfájást okozott nekünk, mert cégünknek rengeteg üzlete van, amelyek hatalmas területen vannak szétszórva. Több tízezer pénztárgép – és nagyon kevés idő.
Mit kellett tenni? Két lehetőség van. Először is: a helyszíni mérnökök manuálisan frissítik és beállítják a szkennereket. Másodszor: távolról dolgozunk, és lehetőleg több szkennert fedünk le egyszerre egy iterációban.
Az első lehetőség nyilvánvalóan nem volt megfelelő számunkra: pénzt kellene költenünk mérnökök felkeresésére, és ebben az esetben nehéz lenne ellenőrizni és koordinálni a folyamatot. De a legfontosabb az, hogy az emberek dolgozzanak, vagyis potenciálisan sok hibát kapunk, és nagy valószínűséggel nem tartjuk be a határidőt.
A második lehetőség mindenkinek jó, ha nem egy dologra. Egyes gyártók nem rendelkeztek az összes szükséges operációs rendszerhez szükséges távoli villogó eszközzel. És mivel fogytak a határidők, a saját fejemmel kellett gondolkodnom.
Ezután elmondjuk, hogyan fejlesztettünk eszközöket kézi szkennerekhez a Debian 9.x operációs rendszerhez (minden pénztárgépünk Debianon van).
Oldja meg a rejtvényt: hogyan kell szkennert flashelni
Victor Antipov jelenti.
A gyártó által biztosított hivatalos segédprogram Windows alatt működik, és csak IE-vel. A segédprogram villoghat és konfigurálhatja a szkennert.
Mivel a célrendszerünk a Debian, telepítettünk egy usb-redirector szervert Debianra és egy usb-redirector klienst Windowsra. Az usb-redirector segédprogramok segítségével a szkennert Linuxos gépről Windows-os gépre továbbítottuk.
Egy Windows-gyártó segédprogramja látta a szkennert, és még rendesen fel is villantotta. Így levontuk az első következtetést: semmi sem függ az operációs rendszertől, ez a villogó protokoll kérdése.
RENDBEN. Futtattuk a flashinget a Windows gépen, és eltávolítottuk a kiíratást a Linuxos gépen.
A WireShark-ba tömtük a szemétlerakót, és... elszomorodtunk (a lerakó néhány részletét kihagyom, nem érdekelnek).
Amit a szeméttelep mutatott nekünk:
A 0000-0030 címek a Wireshark alapján USB-szolgáltatási információk.
Érdekelt minket a 0040-0070-es rész.
Az egyik átviteli keretből semmi sem volt egyértelmű, kivéve a MOCFT karaktereket. Ezek a karakterek a firmware fájl karakterei, valamint a keret végéig fennmaradó karakterek (a firmware fájl kiemelve van):
Hogy mit jelentenek az fd 3e 02 01 fe szimbólumok, én személy szerint, akárcsak Ilja, fogalmam sem volt.
Megnéztem a következő keretet (itt a szolgáltatási információk eltávolítva, a firmware fájl kiemelve):
Mi vált világossá? Hogy az első két bájt valamiféle állandó. Minden további blokk megerősítette ezt, de az átviteli blokk vége előtt:
Ez a képkocka is döbbenetes volt, mivel a konstans megváltozott (kiemelve), és furcsa módon ott volt a fájl egy része. A fájl átvitt bájtjainak mérete 1024 bájtot mutatott. Megint nem tudtam, mit jelentenek a fennmaradó bájtok.
Először is, mint régi BBS becenév, átnéztem a szabványos átviteli protokollokat. Nem küldött 1024 bájt protokollt. Elkezdtem tanulmányozni a hardvert, és ráakadtam az 1K Xmodem protokollra. Lehetővé tette 1024 átvitelét, de egy kitétellel: eleinte csak 128, és csak akkor, ha nem volt hiba, a protokoll növelte a továbbított bájtok számát. Azonnal 1024 bájt átvitelem volt. Úgy döntöttem, hogy tanulmányozom az átviteli protokollokat, és különösen az X-modemet.
A modemnek két változata volt.
Először is, az XMODEM csomagformátum CRC8 támogatással (az eredeti XMODEM):
Másodszor, az XMODEM csomagformátum CRC16 támogatással (XmodemCRC):
Hasonlóan néz ki, kivéve az SOH-t, a csomagszámot és a CRC-t és a csomag hosszát.
Megnéztem a második átviteli blokk elejét (és ismét láttam a firmware fájlt, de már 1024 bájttal behúzva):
Láttam az ismerős fejlécet, az fd 3e 02, de a következő két bájt már megváltozott: 01 fe volt, és 02 fd lett. Aztán észrevettem, hogy a második blokk most 02-es számozású, és így érthető: előttem az átviteli blokk számozása. Az első 1024-es fokozat 01-es, a második 02-es, a harmadik 03-as és így tovább (de persze hatszögben). De mit jelent a fe-ről fd-re való váltás? A szem 1-gyel csökkent, az agy emlékeztetett arra, hogy a programozók 0-tól számolnak, nem 1-től. De akkor miért 1 az első blokk, és nem 0? Még mindig nem találtam meg a választ erre a kérdésre. De megértettem, hogyan számolják a második blokkot. A második blokk nem más, mint FF – (mínusz) az első blokk száma. Így a második blokk = 02 (FF-02) = 02 FD. A szemétlerakás későbbi olvasása megerősítette sejtésemet.
Aztán a következő kép rajzolódott ki az átvitelről:
Az átvitel kezdete
fd 3e 02 – Start
01 FE – átviteli számláló
Átvitel (34 blokk, 1024 bájt áthelyezve)
fd 3e 1024 bájt adat (30 bájtos blokkra osztva).
Az átvitel vége
fd 25
A fennmaradó adatokat 1024 bájtra kell igazítani.
Hogyan néz ki a blokk átviteli végkeret:
fd 25 – jel-blokk átvitel. Következő 2f 52 – a fájl többi része legfeljebb 1024 bájt méretű. A 2f 52, a protokollból ítélve, egy 16 bites CRC ellenőrző összeg.
A régi idők kedvéért csináltam egy programot C nyelven, ami 1024 bájtot vett ki egy fájlból, és egy 16 bites CRC-t számított ki. A program elindítása megmutatta, hogy ez nem 16 bites CRC. Ismét kábulat – körülbelül három napig. Egész idő alatt próbáltam megérteni, mi lehet ez, ha nem ellenőrző összeg. Az angol nyelvű oldalak tanulmányozása közben rájöttem, hogy az X-modem saját ellenőrzőösszeg-számítást használ - CRC-CCITT (XModem). Ennek a számításnak nem találtam C megvalósítását, de találtam egy webhelyet, amely online kiszámította ezt az ellenőrző összeget. Miután 1024 bájtnyi fájlt átvitt a weboldalra, a webhely olyan ellenőrző összeget mutatott, amely teljesen megegyezett a fájlból származó ellenőrző összeggel.
Hurrá! Az utolsó rejtvény megoldódott, most saját firmware-t kellett készítenem. Ezután átadtam tudásomat (és csak a fejemben maradt) Ilyának, aki ismeri a Python hatékony eszköztárát.
Program készítése
Ilya Aleshin jelenti.
Miután megkaptam a megfelelő utasításokat, nagyon „boldog” voltam.
Hol kezdjem? Így van, kezdettől fogva. Az USB-portról való kiírásból.
Indítsa el az USB-pcap programot
Válassza ki a portot, amelyhez az eszköz csatlakozik, és azt a fájlt, ahová a kiíratást menteni fogjuk.
A szkennert egy olyan géphez csatlakoztatjuk, amelyre telepítve van a natív EZConfigScanning for Windows szoftver.
Ebben megtaláljuk a parancsok eszközre küldéséhez szükséges elemet. De mi a helyzet a csapatokkal? Hol szerezhetem be őket?
A program indulásakor a berendezés automatikusan lekérdezésre kerül (ezt egy kicsit később látni fogjuk). És voltak képzési vonalkódok a hivatalos felszerelési dokumentumokból. DEFALT. Ez a mi csapatunk.
A szükséges adatok megérkeztek. Nyissa meg a dump.pcap fájlt a wiresharkon keresztül.
Blokkolás az EZConfigScanning indításakor. Piros színnel jelölik azokat a helyeket, amelyekre figyelni kell.
Amikor mindezt először láttam, elment a kedvem. Nem világos, merre kell tovább ásni.
Egy kis ötletelés és-és-és... Aha! A szeméttelepen ki - Van inÉs in ezt ki.
Megnéztem a google-ban, hogy mi az URB_INTERRUPT. Rájöttem, hogy ez egy adatátviteli módszer. És 4 ilyen módszer létezik: vezérlés, megszakítás, izokron, tömeges. Külön olvashatsz róluk.
Az USB-eszköz interfészének végpontcímei pedig az „lsusb –v” paranccsal vagy a pyusb használatával szerezhetők be.
Most meg kell találnunk az összes eszközt ezzel a VID-vel. Kifejezetten a VID:PID alapján kereshet.
Ez így néz ki:
Tehát megvan a szükséges információ: a P_INFO parancsok. vagy DEFALT, megcímzi, hogy hova kell írni az endpoint=03 parancsokat, és hol kapja meg a végpont=86 választ. Már csak a parancsokat hexadecimálissá kell konvertálni.
Mivel már megtaláltuk az eszközt, válasszuk le a kernelről...
...és írjon a végpontra 0x03 címmel,
... majd olvassa el a választ a 0x86-os végponttól.
Strukturált válasz:
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: 0x6986Ezeket az adatokat a dump.pcap fájlban látjuk.
Nagy! Konvertálja a rendszer vonalkódjait hexadecimálissá. Ez az, a képzési funkció készen áll.
Mi a helyzet a firmware-rel? Úgy tűnik, minden ugyanaz, de van egy árnyalat.
Miután a villogási folyamatot teljesen kidobtuk, nagyjából megértettük, mivel is van dolgunk. Íme egy cikk az XMODEM-ről, amely nagyon hasznos volt a kommunikáció folyamatának megértésében, bár általánosságban: Olvasásra ajánlom.
A kiíratást nézve láthatja, hogy a keret mérete 1024, az URB-adat mérete pedig 64.
Ezért – 1024/64 – 16 sort kapunk egy blokkban, 1 karakterenként olvassuk be a firmware fájlt és blokkot képezünk. Egy blokk 1 sorának kiegészítése speciális karakterekkel fd3e02 + blokkszám.
A következő 14 sort kiegészítjük az fd25 +-al, az XMODEM.calc_crc() segítségével kiszámítjuk a teljes blokk ellenőrző összegét (sok időbe telt megérteni, hogy „FF – 1” a CSUM) és az utolsó, 16. sort kiegészítjük fd3e-vel.
Úgy tűnik, ez az, olvassa el a firmware fájlt, nyomja meg a blokkokat, válassza le a szkennert a kernelről, és küldje el az eszközre. De ez nem ilyen egyszerű. A szkennert firmware módba kell kapcsolni,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Honnan van ez a csapat?? A szeméttelepről.
De a 64-es korlát miatt nem tudunk teljes blokkot küldeni a szkennernek:
Nos, a szkenner NEWAPP villogó módban nem fogadja el a hexadecimális értékeket. Ezért a bytes_array minden sort le kell fordítania
[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]Ezután küldje el ezeket az adatokat a szkennernek.
Megkapjuk a választ:
[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]Ha megnézi az XMODEM-ről szóló cikket, világossá válik: az adatokat elfogadták.
Az összes blokk átvitele után befejezzük az átvitelt END_TRANSFER = 'xfdx01x04'.
Nos, mivel ezek a blokkok nem hordoznak semmilyen információt a hétköznapi emberek számára, alapértelmezés szerint rejtett módban telepítjük a firmware-t. És minden esetre egy folyamatjelző sávot szervezünk a tqdm-en keresztül.
Valójában akkor apró dolgokról van szó. Nem kell mást tenni, mint a megoldást szkriptekbe csomagolni a tömeges replikációhoz egy jól meghatározott időpontban, hogy ne lassítsák le a pénztáraknál végzett munka folyamatát, és hozzáadja a naplózást.
Teljes
Rengeteg időt, fáradságot és hajszálakat eltöltöttünk a fejünkön, így sikerült kidolgozni a szükséges megoldásokat, és a határidőt is betartottuk. Ezzel párhuzamosan a szkennerek most már központilag frissülnek és képeznek át, egyértelműen mi irányítjuk a teljes folyamatot. A cég időt és pénzt takarított meg, és felbecsülhetetlen értékű tapasztalatot szereztünk az ilyen típusú visszafejtő berendezések terén.
Forrás: will.com