Sveiki visi.
Mes, Viktoras Antipovas ir Ilja Aleshinas, šiandien kalbėsime apie savo patirtį dirbant su USB įrenginiais per Python PyUSB ir šiek tiek apie atvirkštinę inžineriją.
priešistorė
2019 „Dėl Tabako gaminių ženklinimo identifikavimo priemonėmis taisyklių ir valstybinės informacinės sistemos, skirtos prekių, kurias privaloma ženklinti identifikavimo priemonėmis, apyvartos stebėjimo ypatybių patvirtinimo patvirtinimo“ 224 m. tabako gaminių atžvilgiu“ įsigaliojo.
Dokumente paaiškinama, kad nuo 1 metų liepos 2019 dienos gamintojai privalo ženklinti kiekvieną tabako pakuotę. O tiesioginiai platintojai šiuos produktus turi gauti su universalaus perdavimo dokumento (UDD) įforminimu. Parduotuvės savo ruožtu turi registruoti paženklintų produktų pardavimą per kasą.
Taip pat nuo 1 metų liepos 2020 dienos draudžiama neženklintų tabako gaminių apyvarta. Tai reiškia, kad visi cigarečių pakeliai turi būti pažymėti specialiu Datamatrix brūkšniniu kodu. Be to – svarbus momentas – paaiškėjo, kad Datamatrix bus ne įprasta, o atvirkštinė. Tai yra, ne juodas kodas ant balto, o atvirkščiai.
Išbandėme savo skaitytuvus, ir paaiškėjo, kad daugumą jų reikia atnaujinti/permokyti, kitaip jie tiesiog negali normaliai dirbti su šiuo brūkšniniu kodu. Toks įvykių posūkis mums garantavo stiprų galvos skausmą, nes mūsų įmonė turi daugybę parduotuvių, išsibarsčiusių didžiulėje teritorijoje. Kelios dešimtys tūkstančių kasų – ir labai mažai laiko.
Ką reikėjo daryti? Yra du variantai. Pirma: vietoje dirbantys inžinieriai rankiniu būdu atkuria ir sureguliuoja skaitytuvus. Antra: dirbame nuotoliniu būdu ir, pageidautina, vienu pakartojimu apimsime daug skaitytuvų.
Pirmas variantas, aišku, mums netiko: tektų išleisti pinigus atvykusiems inžinieriams, o tokiu atveju būtų sunku kontroliuoti ir koordinuoti procesą. Bet svarbiausia, kad žmonės dirbtų, tai yra potencialiai gautume daug klaidų ir, greičiausiai, nesilaikytume termino.
Antrasis variantas tinka visiems, jei ne vienam dalykui. Kai kurie pardavėjai neturėjo nuotolinio mirksėjimo įrankių, kurių mums reikėjo visoms reikiamoms operacinėms sistemoms. O kadangi terminai baigėsi, teko galvoti savo galva.
Toliau papasakosime, kaip sukūrėme įrankius rankiniams skaitytuvams, skirtiems Debian 9.x OS (visi mūsų kasos aparatai yra Debian'e).
Įspėkite mįslę: kaip paleisti skaitytuvą
Viktoras Antipovas praneša.
Oficiali pardavėjo teikiama programa veikia Windows sistemoje ir tik su IE. Priemonė gali mirksėti ir konfigūruoti skaitytuvą.
Kadangi mūsų tikslinė sistema yra Debian, mes įdiegėme usb peradresavimo serverį Debian ir usb peradresavimo klientą sistemoje Windows. Naudodami USB peradresavimo programas, persiuntėme skaitytuvą iš „Linux“ įrenginio į „Windows“ įrenginį.
„Windows“ pardavėjo programinė įranga pamatė skaitytuvą ir net normaliai suaktyvino. Taigi padarėme pirmąją išvadą: niekas nepriklauso nuo OS, tai yra mirksinčio protokolo reikalas.
GERAI. „Windows“ įrenginyje paleidome mirksėjimą ir pašalinome „Linux“ įrenginio iškeltą.
Įdėjome sąvartyną į WireShark ir... pasidarėme liūdni (praleisiu kai kurias sąvartyno detales, jos neįdomios).
Ką mums parodė sąvartynas:
Adresai 0000-0030, sprendžiant pagal Wireshark, yra USB paslaugos informacija.
Mus domino 0040-0070 dalis.
Iš vieno perdavimo kadro nieko nebuvo aišku, išskyrus MOCFT simbolius. Paaiškėjo, kad šie simboliai yra simboliai iš programinės aparatinės įrangos failo, taip pat likę simboliai iki kadro pabaigos (firmware failas yra paryškintas):
Ką reiškia simboliai fd 3e 02 01 fe, aš asmeniškai, kaip ir Ilja, net neįsivaizdavau.
Pažiūrėjau į šį rėmelį (paslaugos informacija čia pašalinta, programinės įrangos failas buvo paryškintas):
Kas tapo aišku? Kad pirmieji du baitai yra kažkokios konstantos. Visi tolesni blokai tai patvirtino, bet dar nepasibaigus perdavimo blokui:
Šis kadras taip pat pribloškė, nes konstanta pasikeitė (paryškinta) ir, kaip bebūtų keista, buvo dalis failo. Perduotų failo baitų dydis parodė, kad buvo perkelti 1024 baitai. Aš vėl nežinojau, ką reiškia likę baitai.
Visų pirma, kaip seną BBS slapyvardį, peržiūrėjau standartinius perdavimo protokolus. Joks protokolas neperdavė 1024 baitų. Pradėjau studijuoti aparatinę įrangą ir susidūriau su 1K Xmodem protokolu. Jis leido perduoti 1024, bet su įspėjimu: iš pradžių tik 128, o tik jei nebuvo klaidų, protokolas padidino perduodamų baitų skaičių. Iš karto turėjau 1024 baitų perdavimą. Nusprendžiau studijuoti perdavimo protokolus, o ypač X modemą.
Buvo du modemo variantai.
Pirma, XMODEM paketo formatas su CRC8 palaikymu (originalus XMODEM):
Antra, XMODEM paketo formatas su CRC16 palaikymu (XmodemCRC):
Atrodo panašiai, išskyrus SOH, pakuotės numerį ir CRC bei pakuotės ilgį.
Pažiūrėjau į antrojo perdavimo bloko pradžią (ir vėl pamačiau programinės įrangos failą, bet jau įtrauktą 1024 baitais):
Mačiau pažįstamą antraštę fd 3e 02, bet kiti du baitai jau pasikeitė: buvo 01 fe ir tapo 02 fd. Tada pastebėjau, kad antrasis blokas dabar buvo sunumeruotas 02 ir taip supratau: priešais mane buvo perdavimo bloko numeracija. Pirmoji 1024 pavara yra 01, antroji – 02, trečioji – 03 ir taip toliau (bet, žinoma, šešiabriaune). Bet ką reiškia pakeitimas iš fe į fd? Akys matė sumažėjimą 1, smegenys priminė, kad programuotojai skaičiuoja nuo 0, o ne 1. Bet kodėl tada pirmas blokas yra 1, o ne 0? Vis dar neradau atsakymo į šį klausimą. Bet aš supratau, kaip skaičiuojamas antrasis blokas. Antrasis blokas yra ne kas kita, kaip FF – (atėmus) pirmojo bloko numerį. Taigi antrasis blokas buvo pažymėtas kaip = 02 (FF-02) = 02 FD. Vėlesnis sąvartyno skaitymas patvirtino mano spėjimą.
Tada pradėjo ryškėti toks perdavimo vaizdas:
Perdavimo pradžia
fd 3e 02 – pradžia
01 FE – perdavimo skaitiklis
Perdavimas (34 blokai, perkelti 1024 baitai)
fd 3e 1024 baitai duomenų (padalinta į 30 baitų blokus).
Perdavimo pabaiga
25
Likę duomenys turi būti suderinti iki 1024 baitų.
Kaip atrodo bloko perdavimo galinis rėmas:
fd 25 – signalo perdavimas iki bloko pabaigos. Kitas 2f 52 – likusi failo dalis iki 1024 baitų. 2f 52, sprendžiant iš protokolo, yra 16 bitų CRC kontrolinė suma.
Senų laikų labui sukūriau programą C, kuri iš failo ištraukė 1024 baitus ir apskaičiavo 16 bitų CRC. Programos paleidimas parodė, kad tai nėra 16 bitų CRC. Vėl stuporas – apie tris dienas. Visą tą laiką bandžiau suprasti, kas tai galėtų būti, jei ne kontrolinė suma. Studijuodamas svetaines anglų kalba sužinojau, kad X modemas naudoja savo kontrolinės sumos skaičiavimą - CRC-CCITT (XModem). Neradau šio skaičiavimo C įgyvendinimo variantų, bet radau svetainę, kuri apskaičiavo šią kontrolinę sumą internete. Perkėlusi 1024 baitus savo failo į tinklalapį, svetainė man parodė kontrolinę sumą, kuri visiškai atitiko kontrolinę sumą iš failo.
Sveika! Paskutinė mįslė buvo išspręsta, dabar man reikėjo sukurti savo programinę-aparatinę įrangą. Toliau savo žinias (ir jos liko tik mano galvoje) perdaviau Iljai, kuris yra susipažinęs su galingu įrankių rinkiniu Python.
Programos kūrimas
Ilja Aleshin praneša.
Gavęs atitinkamas instrukcijas, buvau labai „laimingas“.
Kur pradėti? Teisingai, nuo pat pradžių. Nuo iškrovimo iš USB prievado.
Paleiskite USB-pcap
Pasirinkite prievadą, prie kurio prijungtas įrenginys, ir failą, kuriame išsaugosime sąvartyną.
Mes prijungiame skaitytuvą prie įrenginio, kuriame įdiegta vietinė EZConfigScanning programinė įranga, skirta Windows.
Jame randame komandų siuntimo į įrenginį elementą. Bet kaip su komandomis? Kur galiu juos gauti?
Kai programa paleidžiama, įranga automatiškai apklausiama (pamatysime šiek tiek vėliau). O ten buvo mokomieji brūkšniniai kodai iš oficialių įrangos dokumentų. NUMATYTOJI. Tai mūsų komanda.
Reikalingi duomenys gauti. Atidarykite dump.pcap per wireshark.
Blokuoti paleidžiant EZConfigScanning. Vietos, į kurias reikia atkreipti dėmesį, pažymėtos raudonai.
Visa tai pamačiusi pirmą kartą, neteko galvoje. Neaišku, kur toliau kasti.
Šiek tiek minčių šturmo ir-ir-ir... Aha! Sąvartyne - Ar inIr in tai .
Paieškojau „Google“, kas yra URB_INTERRUPT. Sužinojau, kad tai yra duomenų perdavimo būdas. Ir yra 4 tokie metodai: valdymas, pertraukimas, izochroninis, masinis. Apie juos galite paskaityti atskirai.
O galinių taškų adresus USB įrenginio sąsajoje galima gauti naudojant komandą „lsusb –v“ arba naudojant pyusb.
Dabar turime rasti visus įrenginius su šiuo VID. Galite ieškoti konkrečiai pagal VID:PID.
Tai atrodo taip:
Taigi, turime reikiamą informaciją: P_INFO komandas. arba DEFALT, nurodo, kur rašyti komandas endpoint=03 ir kur gauti atsakymą endpoint=86. Lieka tik konvertuoti komandas į hex.
Kadangi įrenginį jau radome, atjunkite jį nuo branduolio...
...ir parašykite į galinį tašką adresu 0x03,
... ir tada perskaitykite atsakymą iš galinio taško su adresu 0x86.
Struktūrizuotas atsakymas:
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Šiuos duomenis matome dump.pcap.
Puiku! Konvertuoti sistemos brūkšninius kodus į šešioliktainį. Viskas, treniruočių funkcionalumas paruoštas.
O kaip su programine įranga? Atrodo, kad viskas taip pat, bet yra niuansas.
Atlikę visišką mirksėjimo procesą, mes maždaug supratome, su kuo turime reikalą. Štai straipsnis apie XMODEM, kuris labai padėjo suprasti, kaip vyksta šis bendravimas, nors ir apskritai: Rekomenduoju perskaityti.
Žvelgiant į sąvartyną, matote, kad kadro dydis yra 1024, o URB duomenų dydis yra 64.
Taigi – 1024 m/64 – bloke gauname 16 eilučių, skaitome programinės įrangos failą po 1 simbolį ir sudarome bloką. 1 eilutės bloko papildymas specialiais simboliais fd3e02 + bloko numeris.
Kiti 14 eilučių papildomi fd25 +, naudojant XMODEM.calc_crc() apskaičiuojame viso bloko kontrolinę sumą (prireikė nemažai laiko suprasti, kad “FF – 1” yra CSUM) ir papildoma paskutinė, 16 eilutė. su fd3e.
Atrodytų, viskas, perskaitykite programinės įrangos failą, paspauskite blokus, atjunkite skaitytuvą nuo branduolio ir nusiųskite jį į įrenginį. Bet tai nėra taip paprasta. Skaitytuvas turi būti perjungtas į programinės įrangos režimą,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Iš kur ši komanda?? Iš sąvartyno.
Bet negalime nusiųsti viso bloko į skaitytuvą dėl 64 limito:
Na, skaitytuvas NEWAPP mirksinčiu režimu nepriima šešioliktadienio. Todėl turėsite išversti kiekvieną eilutę 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]Tada nusiųskite šiuos duomenis į skaitytuvą.
Gauname atsakymą:
[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]Jei patikrinsite straipsnį apie XMODEM, paaiškės: duomenys buvo priimti.
Kai visi blokai bus perkelti, užbaigiame perkėlimą END_TRANSFER = 'xfdx01x04'.
Na, kadangi šie blokai neneša jokios informacijos paprastiems žmonėms, programinę įrangą įdiegsime paslėptu režimu pagal numatytuosius nustatymus. Ir tik tuo atveju surengsime eigos juostą per tqdm.
Tiesą sakant, tai yra smulkmenos. Belieka suvynioti sprendimą į scenarijus, skirtus masiniam replikavimui aiškiai apibrėžtu laiku, kad nesulėtėtų darbo kasose, ir pridėti registravimą.
Visas
Sugaišę daug laiko ir pastangų bei plaukų ant galvos, galėjome sukurti reikalingus sprendimus, taip pat laikėmės termino. Tuo pačiu metu skaitytuvai yra atnaujinti ir perkvalifikuoti centralizuotai, mes aiškiai kontroliuojame visą procesą. Įmonė sutaupė laiko ir pinigų, įgijome neįkainojamos patirties kuriant tokio tipo reversinės inžinerijos įrangą.
Šaltinis: www.habr.com