Hei kaikki
Me, Viktor Antipov ja Ilja Aleshin, puhumme tänään kokemuksistamme työskentelystä USB-laitteiden kanssa Python PyUSB:n kautta ja hieman käänteissuunnittelusta.
esihistoria
Vuonna 2019 Venäjän federaation hallituksen asetus nro 224 "Tupakkatuotteiden merkitsemistä tunnistusvälineillä koskevien sääntöjen hyväksymisestä ja valtion tietojärjestelmän toteuttamisen ominaisuuksista sellaisten tavaroiden liikkumisen valvomiseksi, jotka on merkitty tunnistusvälineillä tupakkatuotteiden osalta” tuli voimaan.
Asiakirjassa selitetään, että 1. heinäkuuta 2019 alkaen valmistajien on merkittävä jokainen tupakkapakkaus. Ja suorien jakelijoiden on vastaanotettava nämä tuotteet yleisen siirtoasiakirjan (UDD) avulla. Kauppojen puolestaan on rekisteröitävä merkittyjen tuotteiden myynti kassakoneen kautta.
Myös 1 alkaen merkitsemättömien tupakkatuotteiden kierto on kielletty. Tämä tarkoittaa, että kaikki tupakka-askit on merkittävä erityisellä Datamatrix-viivakoodilla. Lisäksi - tärkeä kohta - kävi ilmi, että Datamatrix ei ole tavallinen, vaan käänteinen. Eli ei mustaa koodia valkoisella, vaan päinvastoin.
Testasimme skannereitamme ja kävi ilmi, että suurin osa niistä on päivitettävä/koulutettava uudelleen, muuten ne eivät yksinkertaisesti pysty toimimaan normaalisti tällä viivakoodilla. Tämä tapahtumien käänne toi meille kovan päänsäryn, sillä yrityksellämme on paljon myymälöitä, jotka ovat hajallaan laajalla alueella. Useita kymmeniä tuhansia kassakoneita – ja hyvin vähän aikaa.
Mitä piti tehdä? Vaihtoehtoja on kaksi. Ensinnäkin: paikan päällä toimivat insinöörit päivittävät ja säätävät skannerit manuaalisesti. Toiseksi: työskentelemme etänä ja mieluiten peitämme useita skannereita kerralla yhdessä iteraatiossa.
Ensimmäinen vaihtoehto ei tietenkään sopinut meille: meidän täytyisi käyttää rahaa vieraileviin insinööreihin, ja tässä tapauksessa prosessin hallinta ja koordinointi olisi vaikeaa. Mutta tärkeintä on, että ihmiset tekisivät töitä, eli saisimme mahdollisesti paljon virheitä ja mitä todennäköisimmin emme noudata määräaikaa.
Toinen vaihtoehto on hyvä kaikille, ellei yhdelle asialle. Joillakin toimittajilla ei ollut etävilkkutyökaluja, joita tarvitsimme kaikkia tarvittavia käyttöjärjestelmiä varten. Ja koska määräajat olivat loppumassa, jouduin ajattelemaan omalla päällään.
Seuraavaksi kerromme, kuinka kehitimme työkaluja käsiskannereille Debian 9.x -käyttöjärjestelmälle (kaikki kassakoneemme ovat Debianissa).
Ratkaise arvoitus: kuinka salata skanneri
Victor Antipov raportoi.
Toimittajan tarjoama virallinen apuohjelma toimii Windowsissa ja vain IE:n kanssa. Apuohjelma voi vilkkua ja määrittää skannerin.
Koska kohdejärjestelmämme on Debian, asensimme usb-uudelleenohjauspalvelimen Debianiin ja usb-uudelleenohjauspalvelimen Windowsiin. Usb-redirector-apuohjelmien avulla välitimme skannerin Linux-koneesta Windows-koneeseen.
Windows-toimittajan apuohjelma näki skannerin ja jopa välähti sen normaalisti. Näin ollen teimme ensimmäisen johtopäätöksen: mikään ei riipu käyttöjärjestelmästä, kyse on vilkkuvasta protokollasta.
OK. Suoritimme vilkkumisen Windows-koneella ja poistimme dumpin Linux-koneelta.
Töimme kaatopaikan WireSharkiin ja... tulimme surullisiksi (jätän pois joitakin kaatopaikan yksityiskohtia, ne eivät kiinnosta).
Mitä kaatopaikka meille näytti:
Osoitteet 0000-0030 ovat Wiresharkin perusteella USB-palvelutietoja.
Olimme kiinnostuneita osasta 0040-0070.
Yhdestä lähetyskehyksestä ei ollut selvää mitään paitsi MOCFT-merkkejä. Nämä merkit osoittautuivat merkeille laiteohjelmistotiedostosta, samoin kuin jäljellä olevat merkit kehyksen loppuun asti (laiteohjelmistotiedosto on korostettu):
Mitä symbolit fd 3e 02 01 fe tarkoittivat, minulla henkilökohtaisesti, kuten Ilja, ei ollut aavistustakaan.
Katsoin seuraavaa kehystä (palvelutiedot on poistettu täältä, laiteohjelmistotiedosto on korostettu):
Mikä tuli selväksi? Että kaksi ensimmäistä tavua ovat jonkinlaisia vakioita. Kaikki myöhemmät lohkot vahvistivat tämän, mutta ennen lähetyslohkon loppua:
Tämä kehys oli myös hämmästyttävä, koska vakio oli muuttunut (korostettu) ja kummallista kyllä, tiedostosta oli osa. Tiedoston siirrettyjen tavujen koko osoitti, että 1024 tavua siirrettiin. En taaskaan tiennyt, mitä jäljellä olevat tavut tarkoittivat.
Ensinnäkin vanhana BBS-lempinimenä tarkistin vakiolähetysprotokollat. Protokollaa ei lähetetty 1024 tavua. Aloin tutkia laitteistoa ja törmäsin 1K Xmodem -protokollaan. Se salli 1024:n lähettämisen, mutta varoin: aluksi vain 128, ja vain jos virheitä ei ollut, protokolla lisäsi lähetettyjen tavujen määrää. Minulla oli heti 1024 tavun siirto. Päätin tutkia siirtoprotokollia ja erityisesti X-modeemia.
Modeemista oli kaksi muunnelmaa.
Ensinnäkin XMODEM-pakettimuoto CRC8-tuella (alkuperäinen XMODEM):
Toiseksi XMODEM-pakettimuoto CRC16-tuella (XmodemCRC):
Se näyttää samalta, paitsi SOH, paketin numero ja CRC ja paketin pituus.
Katsoin toisen lähetyslohkon alkua (ja näin jälleen laiteohjelmistotiedoston, joka oli jo sisennetty 1024 tavulla):
Näin tutun otsikon fd 3e 02, mutta seuraavat kaksi tavua olivat jo muuttuneet: se oli 01 fe, ja siitä tuli 02 fd. Sitten huomasin, että toinen lohko oli nyt numeroitu 02 ja näin ymmärsin: edessäni oli lähetyslohkon numerointi. Ensimmäinen 1024-vaihde on 01, toinen on 02, kolmas on 03 ja niin edelleen (mutta tietysti kuusiovaihteella). Mutta mitä muutos fe:stä fd:ksi tarkoittaa? Silmät näkivät laskun yhdellä, aivot muistuttivat, että ohjelmoijat laskevat 1:sta, eivät 0:stä. Mutta miksi sitten ensimmäinen lohko on 1 eikä 1? En ole vieläkään löytänyt vastausta tähän kysymykseen. Mutta ymmärsin kuinka toinen lohko lasketaan. Toinen lohko ei ole muuta kuin FF – (miinus) ensimmäisen lohkon numero. Siten toinen lohko nimettiin = 0 (FF-02) = 02 FD. Kaatopaikan myöhempi lukeminen vahvisti arvaukseni.
Sitten lähetyksestä alkoi syntyä seuraava kuva:
Lähetyksen aloitus
fd 3e 02 – Aloitus
01 FE – lähetyslaskuri
Siirto (34 lohkoa, 1024 tavua siirretty)
fd 3e 1024 tavua dataa (jaettu 30 tavun lohkoihin).
Lähetyksen loppu
fd 25
Loput tiedot tasataan 1024 tavuun.
Miltä lohkolähetyksen päätekehys näyttää:
fd 25 – signaalin siirto lohkoon. Seuraava 2f 52 – loput tiedostosta kooltaan enintään 1024 tavua. 2f 52 on protokollan perusteella 16-bittinen CRC-tarkistussumma.
Vanhojen aikojen vuoksi tein C:lle ohjelman, joka poimi 1024 tavua tiedostosta ja laski 16-bittisen CRC:n. Ohjelman käynnistäminen osoitti, että tämä ei ole 16-bittinen CRC. Stupor jälleen - noin kolme päivää. Koko tämän ajan yritin ymmärtää, mikä se voisi olla, ellei tarkistussumma. Tutkiessani englanninkielisiä sivustoja huomasin, että X-modeemi käyttää omaa tarkistussummalaskentaa - CRC-CCITT (XModem). En löytänyt tämän laskelman C-toteutuksia, mutta löysin sivuston, joka laski tämän tarkistussumman verkosta. Siirrettyään 1024 tavua tiedostostani verkkosivulle, sivusto näytti minulle tarkistussumman, joka vastasi täysin tiedoston tarkistussummaa.
Hurraa! Viimeinen arvoitus ratkesi, nyt minun piti tehdä oma laiteohjelmisto. Seuraavaksi välitin tietoni (ja se jäi vain päähäni) Iljalle, joka tuntee tehokkaan Python-työkalusarjan.
Ohjelman luominen
Ilja Aleshin raportoi.
Saatuani asianmukaiset ohjeet olin hyvin "onnellinen".
Mistä aloittaa? Aivan, alusta asti. USB-portista vedetystä.
Käynnistä USB-pcap
Valitse portti, johon laite on kytketty, ja tiedosto, johon tallennamme vedos.
Yhdistämme skannerin koneeseen, johon on asennettu alkuperäinen EZConfigScanning-ohjelmisto Windowsille.
Siitä löydämme kohteen komentojen lähettämiseksi laitteeseen. Mutta entä joukkueet? Mistä niitä saa?
Kun ohjelma käynnistyy, laitteisto pollataan automaattisesti (näemme tämän vähän myöhemmin). Ja siellä oli koulutusviivakoodeja virallisista laiteasiakirjoista. OLETUS. Tämä on meidän tiimimme.
Tarvittavat tiedot on saatu. Avaa dump.pcap wiresharkin kautta.
Estä, kun käynnistetään EZConfigScanning. Paikat, joihin sinun on kiinnitettävä huomiota, on merkitty punaisella.
Kun näin kaiken tämän ensimmäistä kertaa, menetin sydämeni. Ei ole selvää, mistä kaivella seuraavaksi.
Pientä aivoriihiä ja-ja-ja... Ahaa! Kaatopaikalla ulos - Onko inJa in это ulos.
Googletin, mikä on URB_INTERRUPT. Huomasin, että tämä on tiedonsiirtomenetelmä. Ja tällaisia menetelmiä on 4: ohjaus, keskeytys, isokroninen, bulkki. Voit lukea niistä erikseen.
Ja USB-laitteen rajapinnan päätepisteiden osoitteet saadaan joko komennolla “lsusb –v” tai pyusb:llä.
Nyt meidän on löydettävä kaikki laitteet, joissa on tämä VID. Voit etsiä nimenomaan VID:PID:llä.
Näyttää siltä:
Joten meillä on tarvittavat tiedot: P_INFO-komennot. tai DEFALT, osoittaa, mihin kirjoitetaan komennot endpoint=03 ja mistä saadaan vastaus endpoint=86. Jäljelle jää vain muuntaa komennot hex-muotoon.
Koska olemme jo löytäneet laitteen, irrotetaan se ytimestä...
...ja kirjoita päätepisteeseen osoitteella 0x03,
... ja lue sitten vastaus päätepisteestä, jonka osoite on 0x86.
Strukturoitu vastaus:
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: 0x6986Näemme nämä tiedot tiedostossa dump.pcap.
Loistava! Muunna järjestelmän viivakoodit heksadesimaalimuotoisiksi. Siinä kaikki, harjoitustoiminto on valmis.
Entä laiteohjelmisto? Kaikki näyttää olevan samanlaista, mutta siinä on vivahde.
Otettuamme täydellisen kaatopaikan vilkkumisprosessista, ymmärsimme suunnilleen, mitä olimme tekemisissä. Tässä on artikkeli XMODEMistä, joka auttoi ymmärtämään, miten tämä viestintä tapahtuu, vaikkakin yleisesti: Suosittelen lukemista.
Kun katsot vedosta, näet, että kehyksen koko on 1024 ja URB-tietojen koko on 64.
Siksi - 1024/64 – saamme 16 riviä lohkoon, luemme laiteohjelmistotiedoston 1 merkin kerrallaan ja muodostamme lohkon. Täydennetään 1 riviä lohkossa erikoismerkeillä fd3e02 + lohkon numero.
Seuraavat 14 riviä täydennetään fd25 +:lla, XMODEM.calc_crc() -komennolla lasketaan koko lohkon tarkistussumma (meni paljon aikaa ymmärtää, että “FF – 1” on CSUM) ja viimeinen, 16. rivi täydennetään. fd3e:n kanssa.
Vaikuttaa siltä, että se on siinä, lue laiteohjelmistotiedosto, osu lohkoihin, irrota skanneri ytimestä ja lähetä se laitteeseen. Mutta se ei ole niin yksinkertaista. Skanneri on vaihdettava laiteohjelmistotilaan,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Mistä tämä joukkue on?? Kaatopaikalta.
Emme kuitenkaan voi lähettää koko lohkoa skanneriin 64-rajoituksen vuoksi:
No, skanneri NEWAPP-vilkkutilassa ei hyväksy hex-lukua. Siksi sinun on käännettävä jokainen rivi 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]Ja sitten lähetä nämä tiedot skannerille.
Saamme vastauksen:
[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]Jos tarkistat artikkelin XMODEMistä, käy selväksi: tiedot on hyväksytty.
Kun kaikki lohkot on siirretty, suoritamme siirron END_TRANSFER = 'xfdx01x04'.
No, koska nämä lohkot eivät sisällä mitään tietoa tavallisille ihmisille, asennamme laiteohjelmiston oletuksena piilotettuun tilaan. Ja varmuuden vuoksi järjestämme edistymispalkin tqdm:n kautta.
Itse asiassa silloin on kyse pienistä asioista. Jäljelle jää vain kääriä ratkaisu skripteihin massareplikointia varten selkeästi määriteltynä ajankohtana, jotta kassalla työskentely ei hidastu, ja lisää kirjaamista.
Koko
Vietettyämme paljon aikaa ja vaivaa ja hiuksia päähän pystyimme kehittämään tarvitsemamme ratkaisut ja myös noudatimme määräaikaa. Samalla skannerit päivitetään ja koulutetaan uudelleen keskitetysti, joten hallitsemme selkeästi koko prosessia. Yritys säästi aikaa ja rahaa, ja saimme korvaamattoman kokemuksen tämän tyyppisistä käänteissuunnittelulaitteista.
Lähde: will.com