Halo kabeh.
Kita, Viktor Antipov lan Ilya Aleshin, dina iki bakal ngomong babagan pengalaman kita nggarap piranti USB liwat Python PyUSB lan sethithik babagan reverse engineering.
prasejarah
Ing 2019, Keputusan Pamrentah Federasi Rusia No. 224 "Ing disetujoni Aturan kanggo menehi label produk tembakau kanthi sarana identifikasi lan fitur saka implementasine sistem informasi negara kanggo ngawasi sirkulasi barang sing tundhuk label wajib kanthi sarana identifikasi. ing hubungane karo produk tembakau” dileksanakake.
Dokumen kasebut nerangake manawa wiwit tanggal 1 Juli 2019, pabrikan kudu menehi label saben bungkus rokok. Lan distributor langsung kudu nampa produk kasebut kanthi eksekusi dokumen transfer universal (UDD). Toko, ing siji, kudu ndhaftar Advertisement produk label liwat kasir.
Uga, wiwit 1 Juli 2020, sirkulasi produk tembakau sing ora dilabeli dilarang. Iki tegese kabeh bungkus rokok kudu ditandhani nganggo barcode Datamatrix khusus. Menapa malih - titik penting - ternyata Datamatrix ora bakal biasa, nanging kuwalik. Sing, ora kode ireng ing putih, nanging kosok balene.
We dites scanner kita, lan dadi metu sing paling saka wong-wong mau kudu reflashed / retrained, digunakake padha mung ora bisa kanggo bisa normal karo barcode iki. Acara iki njamin kita lara banget, amarga perusahaan kita duwe akeh toko sing kasebar ing wilayah sing akeh. Sawetara puluhan ewu kasir - lan wektu sethithik banget.
Apa sing kudu ditindakake? Ana rong pilihan. Pisanan: insinyur ing situs kanthi manual reflash lan nyetel scanner. Kapindho: kita kerja adoh lan, luwih becik, nutupi akeh scanner bebarengan ing siji iterasi.
Pilihan pisanan, temenan, ora cocok kanggo kita: kita kudu nglampahi dhuwit kanggo ngunjungi engineers, lan ing kasus iki bakal angel kanggo ngontrol lan koordinasi proses. Nanging sing paling penting yaiku wong-wong bakal kerja, yaiku, kita duweni potensi akeh kesalahan lan, sing paling mungkin, ora bakal ketemu deadline.
Pilihan kapindho apik kanggo kabeh wong, yen ora kanggo siji bab. Sawetara vendor ora duwe alat sumunar remot sing dibutuhake kanggo kabeh sistem operasi sing dibutuhake. Lan amarga tenggat wektu wis entek, aku kudu mikir kanthi sirahku dhewe.
Sabanjure, kita bakal pitutur marang kowe carane nggawe alat kanggo scanner genggaman kanggo Debian 9.x OS (kabeh kasir kita ana ing Debian).
Ngatasi teka-teki: carane kerlip scanner
Victor Antipov laporan.
Utilitas resmi sing diwenehake vendor bisa digunakake ing Windows, lan mung nganggo IE. Utilitas bisa kerlip lan ngatur pemindai.
Amarga sistem target kita yaiku Debian, kita nginstal server usb-redirector ing Debian lan klien usb-redirector ing Windows. Nggunakake utilitas usb-redirector, kita nerusake scanner saka mesin Linux menyang mesin Windows.
Utilitas saka vendor Windows ndeleng pemindai lan malah flashed biasane. Mangkono, kita nggawe kesimpulan pisanan: ora ana sing gumantung ing OS, iku masalah protokol sumunar.
OK. We mlayu sumunar ing mesin Windows, lan mbusak mbucal ing mesin Linux.
We diiseni mbucal menyang WireShark lan ... dadi sedih (Aku bakal ngilangi sawetara rincian mbucal, padha ora kapentingan sembarang).
Apa dump nuduhake kita:
Alamat 0000-0030, miturut Wireshark, minangka informasi layanan USB.
Kita padha kasengsem ing bagean 0040-0070.
Ora ana sing jelas saka siji pigura transmisi kajaba karakter MOCFT. Karakter kasebut dadi karakter saka file firmware, uga karakter sing isih ana nganti pungkasan pigura (file firmware disorot):
Apa tegese simbol fd 3e 02 01 fe, aku dhewe, kaya Ilya, ora ngerti.
Aku ndeleng pigura ing ngisor iki (informasi layanan wis dibusak ing kene, file firmware wis disorot):
Apa dadi cetha? Sing loro bita pisanan sawetara jenis pancet. Kabeh pamblokiran sakteruse dikonfirmasi iki, nanging sadurunge mburi pamblokiran transmisi:
Pigura iki uga stupefying, wiwit pancet wis diganti (disorot) lan, cukup aneh, ana bagéan saka file. Ukuran file sing ditransfer nuduhake yen 1024 bait ditransfer. Aku maneh ora ngerti apa tegese bait sing isih ana.
Kaping pisanan, minangka julukan BBS lawas, aku nliti protokol transmisi standar. Ora ana protokol sing dikirimake 1024 bait. Aku miwiti sinau hardware lan ketemu protokol 1K Xmodem. Diijini ngirim 1024, nanging kanthi caveat: ing wiwitan mung 128, lan mung yen ora ana kesalahan, protokol nambah jumlah bita sing dikirim. Aku langsung duwe transfer 1024 bait. Aku mutusaké kanggo sinau protokol transmisi, lan khusus X-modem.
Ana rong variasi saka modem.
Pisanan, format paket XMODEM kanthi dhukungan CRC8 (XMODEM asli):
Kapindho, format paket XMODEM kanthi dhukungan CRC16 (XmodemCRC):
Iku katon padha, kajaba SOH, nomer paket lan CRC lan dawa paket.
Aku katon ing wiwitan pamblokiran transmisi kapindho (lan maneh weruh file perangkat kukuh, nanging wis indented dening 1024 bait):
Aku weruh header menowo fd 3e 02, nanging loro bita sabanjuré wis diganti: iku 01 fe, lan dadi 02 fd. Banjur aku ngelingi yen blok kapindho saiki ana nomer 02 lan kanthi mangkono ngerti: ing ngarepku ana nomer blok transmisi. Gear 1024 pisanan yaiku 01, sing kapindho yaiku 02, sing katelu yaiku 03 lan liya-liyane (nanging ing hex, mesthi). Nanging apa tegese owah-owahan saka fe dadi fd? Mripat weruh nyuda 1, otak ngelingake yen programer ngetung saka 0, ora 1. Nanging kenapa blok pertama 1, lan dudu 0? Aku isih durung nemokake jawaban kanggo pitakonan iki. Nanging aku ngerti carane pemblokiran kapindho diitung. Blok kapindho ora luwih saka FF - (minus) nomer blok pisanan. Mangkono, blok kapindho ditetepake minangka = 02 (FF-02) = 02 FD. Waca mbucal sakteruse dikonfirmasi guess sandi.
Banjur gambar transmisi kasebut wiwit muncul:
Miwiti transmisi
fd 3e 02 – Mulai
01 FE - counter transmisi
Transfer (34 blok, 1024 bita ditransfer)
fd 3e 1024 bita data (dipérang dadi 30 blok bait).
Pungkasan transmisi
fd 25
Data sing isih ana kanggo didadekake siji kanggo 1024 bita.
Apa tampilan pigura mburi transmisi blok:
fd 25 - sinyal kanggo mungkasi transmisi pemblokiran. Sabanjure 2f 52 - file liyane nganti ukuran 1024 bita. 2f 52, miturut protokol, minangka checksum CRC 16-bit.
Kanggo jaman biyen, aku nggawe program ing C sing narik 1024 bait saka file lan ngitung CRC 16-bit. Bukak program kasebut nuduhake manawa iki dudu CRC 16-bit. Stupor maneh - kira-kira telung dina. Kabeh wektu iki aku nyoba kanggo ngerti apa iku bisa, yen ora checksum. Nalika sinau situs basa Inggris, aku nemokake yen X-modem nggunakake pitungan checksum dhewe - CRC-CCITT (XModem). Aku ora nemokake implementasine C saka pitungan iki, nanging aku nemokake situs sing ngitung checksum iki online. Sawise nransfer 1024 bait fileku menyang kaca web, situs kasebut nuduhake checksum sing cocog karo checksum saka file kasebut.
Hore! Teka-teki pungkasan wis ditanggulangi, saiki aku kudu nggawe perangkat kukuh dhewe. Sabanjure, aku menehi kawruh (lan mung ana ing sirahku) marang Ilya, sing kenal karo toolkit Python sing kuat.
Nggawe program
Ilya Aleshin laporan.
Sawise nampa instruksi sing cocog, aku "seneng banget".
Where kanggo miwiti? Bener, wiwit wiwitan. Saka njupuk dump saka port USB.
Bukak USB-pcap
Pilih port sing disambungake piranti lan file sing bakal disimpen.
Kita nyambungake scanner menyang mesin ing ngendi piranti lunak EZConfigScanning asli kanggo Windows diinstal.
Ing kono kita nemokake item kanggo ngirim printah menyang piranti. Nanging kepiye tim? Ing endi aku bisa njaluk?
Nalika program diwiwiti, peralatan kasebut polling kanthi otomatis (kita bakal weruh iki mengko). Lan ana barcode latihan saka dokumen peralatan resmi. DEFALT. Iki tim kita.
Data sing dibutuhake wis ditampa. Buka dump.pcap liwat wireshark.
Blok nalika miwiti EZConfigScanning. Panggonan sing kudu digatekake diwenehi tandha abang.
Weruh kabeh iki kanggo pisanan, aku kelangan ati. Iku ora cetha ngendi kanggo dig sabanjuré.
A brainstorming sethitik lan-lan-lan... Aha! Ing mbucal metu - iki inlan in iku metu.
Aku googling apa URB_INTERRUPT. Aku ngerteni manawa iki minangka cara transfer data. Lan ana 4 cara kasebut: kontrol, interupsi, isochronous, akeh. Sampeyan bisa maca babagan kasebut kanthi kapisah.
Lan alamat endpoint ing antarmuka piranti USB bisa dipikolehi liwat printah "lsusb -v" utawa nggunakake pyusb.
Saiki kita kudu golek kabeh piranti karo VID iki. Sampeyan bisa nggoleki khusus kanthi VID:PID.
Katon kaya mangkene:
Dadi, kita duwe informasi sing dibutuhake: perintah P_INFO. utawa DEFALT, alamat ngendi kanggo nulis printah endpoint=03 lan ngendi kanggo njaluk respon endpoint=86. Kabeh sing isih ana yaiku ngowahi perintah kasebut dadi hex.
Amarga kita wis nemokake piranti kasebut, ayo pedhot saka kernel ...
...lan nulis menyang titik pungkasan kanthi alamat 0x03,
... banjur waca respon saka titik pungkasan kanthi alamat 0x86.
Wangsulan terstruktur:
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: 0x6986We ndeleng data iki ing dump.pcap.
apik tenan! Ngonversi barcode sistem dadi hex. Sing, fungsi latihan wis siyap.
Apa babagan firmware? Kabeh katon padha, nanging ana nuansa.
Sawise mbuwang lengkap proses sumunar, kita kira-kira ngerti apa sing kita tindakake. Iki minangka artikel babagan XMODEM, sing mbantu banget kanggo mangerteni carane komunikasi iki kedadeyan, sanajan ing istilah umum: Aku nyaranake maca.
Deleng ing mbucal, sampeyan bisa ndeleng sing ukuran pigura 1024, lan ukuran URB-data 64.
Mulane - 1024/64 - kita entuk 16 garis ing blok, maca file firmware 1 karakter sekaligus lan mbentuk blok. Nglengkapi 1 baris ing blok kanthi karakter khusus fd3e02 + nomer blok.
Sabanjure 14 baris ditambah karo fd25 +, nggunakake XMODEM.calc_crc () kita ngetung checksum saka kabeh pemblokiran (iku njupuk akèh wektu kanggo ngerti sing "FF - 1" punika CSUM) lan pungkasan, 16 baris ditambah. karo fd3e.
Mesthi wae, maca file perangkat kukuh, kenek blok, pedhot pemindai saka kernel lan kirim menyang piranti. Nanging iku ora sing prasaja. Pemindai kudu dialihake menyang mode firmware,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Iki tim endi?? Saka mbucal.
Nanging kita ora bisa ngirim blok kabeh menyang scanner amarga watesan 64:
Inggih, scanner ing mode sumunar NEWAPP ora nampa hex. Mulane, sampeyan kudu nerjemahake saben baris 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]Banjur ngirim data iki menyang scanner.
Kita entuk jawaban:
[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]Yen sampeyan mriksa artikel babagan XMODEM, bakal dadi cetha: data wis ditampa.
Sawise kabeh pamblokiran wis ditransfer, kita ngrampungake transfer END_TRANSFER = 'xfdx01x04'.
Ya, amarga blok kasebut ora nggawa informasi kanggo wong biasa, kita bakal nginstal perangkat kukuh ing mode sing didhelikake kanthi standar. Lan yen ngono, kita bakal ngatur garis kemajuan liwat tqdm.
Bener, banjur iku prakara cilik. Kabeh sing isih ana yaiku mbungkus solusi ing skrip kanggo replikasi massa ing wektu sing ditemtokake kanthi jelas, supaya ora alon-alon proses kerja ing checkout, lan nambah logging.
Asile
Sawise ngentekake akeh wektu lan gaweyan lan rambut ing endhas, kita bisa ngembangake solusi sing dibutuhake, lan uga ketemu deadline. Ing wektu sing padha, scanner saiki reflashed lan retrained tengah, kita cetha ngontrol kabeh proses. Perusahaan ngirit wektu lan dhuwit, lan kita entuk pengalaman sing ora ana regane ing peralatan rekayasa terbalik saka jinis iki.
Source: www.habr.com