Helo semua.
Kami, Viktor Antipov dan Ilya Aleshin, hari ini akan bercakap tentang pengalaman kami bekerja dengan peranti USB melalui Python PyUSB dan sedikit tentang kejuruteraan terbalik.
prasejarah
Pada tahun 2019, Dekri Kerajaan Persekutuan Rusia No. 224 "Mengenai kelulusan Peraturan untuk pelabelan produk tembakau dengan cara pengenalan dan ciri pelaksanaan sistem maklumat negeri untuk memantau peredaran barang tertakluk kepada pelabelan mandatori dengan cara pengenalan. berhubung dengan produk tembakauβ berkuat kuasa.
Dokumen itu menjelaskan bahawa mulai 1 Julai 2019, pengeluar dikehendaki melabel setiap pek tembakau. Dan pengedar langsung mesti menerima produk ini dengan pelaksanaan dokumen pemindahan universal (UDD). Kedai-kedai pula perlu mendaftarkan penjualan produk berlabel melalui daftar tunai.
Juga, mulai 1 Julai 2020, pengedaran produk tembakau tidak berlabel adalah dilarang. Ini bermakna semua pek rokok mesti ditanda dengan kod bar Datamatrix khas. Lebih-lebih lagi - satu perkara penting - ternyata Datamatrix tidak akan menjadi biasa, tetapi songsang. Iaitu, bukan kod hitam pada putih, tetapi sebaliknya.
Kami telah menguji pengimbas kami, dan ternyata kebanyakan daripadanya perlu disemak semula/dilatih semula, jika tidak, pengimbas tersebut tidak dapat berfungsi secara normal dengan kod bar ini. Peristiwa ini menjamin kami sakit kepala yang teruk, kerana syarikat kami mempunyai banyak kedai yang tersebar di wilayah yang luas. Beberapa puluhan ribu daftar tunai - dan masa yang sangat singkat.
Apa yang perlu dilakukan? Terdapat dua pilihan. Pertama: jurutera di tapak secara manual reflash dan melaraskan pengimbas. Kedua: kami bekerja dari jauh dan, sebaik-baiknya, meliputi banyak pengimbas sekaligus dalam satu lelaran.
Pilihan pertama, jelas, tidak sesuai untuk kami: kami perlu membelanjakan wang untuk melawat jurutera, dan dalam kes ini sukar untuk mengawal dan menyelaraskan proses. Tetapi perkara yang paling penting ialah orang akan bekerja, iaitu, kita berpotensi mendapat banyak ralat dan, kemungkinan besar, tidak memenuhi tarikh akhir.
Pilihan kedua adalah baik untuk semua orang, jika bukan untuk satu perkara. Sesetengah vendor tidak mempunyai alat berkelip jauh yang kami perlukan untuk semua sistem pengendalian yang diperlukan. Dan memandangkan tarikh akhir semakin hampir, saya terpaksa berfikir dengan kepala saya sendiri.
Seterusnya, kami akan memberitahu anda cara kami membangunkan alatan untuk pengimbas pegang tangan untuk Debian 9.x OS (semua daftar tunai kami menggunakan Debian).
Selesaikan teka-teki: bagaimana untuk memancarkan pengimbas
Victor Antipov melaporkan.
Utiliti rasmi yang disediakan oleh vendor berfungsi di bawah Windows, dan hanya dengan IE. Utiliti boleh berkelip dan mengkonfigurasi pengimbas.
Memandangkan sistem sasaran kami ialah Debian, kami memasang pelayan usb-redirector pada Debian dan klien usb-redirector pada Windows. Menggunakan utiliti usb-redirector, kami memajukan pengimbas daripada mesin Linux ke mesin Windows.
Utiliti daripada vendor Windows melihat pengimbas dan juga memancarkannya secara normal. Oleh itu, kami membuat kesimpulan pertama: tiada apa yang bergantung pada OS, ia adalah soal protokol berkelip.
OKEY. Kami menjalankan flashing pada mesin Windows, dan mengeluarkan dump pada mesin Linux.
Kami menyumbat tempat pembuangan itu ke dalam WireShark dan... berasa sedih (saya akan meninggalkan beberapa butiran tempat pembuangan itu, mereka tidak berminat).
Perkara yang ditunjukkan oleh tempat pembuangan sampah kepada kami:
Alamat 0000-0030, berdasarkan Wireshark, adalah maklumat perkhidmatan USB.
Kami berminat dengan bahagian 0040-0070.
Tiada apa-apa yang jelas daripada satu bingkai penghantaran kecuali untuk aksara MOCFT. Watak-watak ini ternyata menjadi aksara daripada fail perisian tegar, serta aksara yang tinggal sehingga akhir bingkai (fail perisian tegar diserlahkan):
Apa yang dimaksudkan dengan simbol fd 3e 02 01 fe, saya secara peribadi, seperti Ilya, tidak tahu.
Saya melihat bingkai berikut (maklumat perkhidmatan telah dialih keluar di sini, fail perisian tegar telah diserlahkan):
Apa yang menjadi jelas? Bahawa dua bait pertama adalah sejenis pemalar. Semua blok berikutnya mengesahkan ini, tetapi sebelum akhir blok penghantaran:
Bingkai ini juga mengejutkan, kerana pemalar telah berubah (diserlahkan) dan, anehnya, terdapat sebahagian daripada fail. Saiz bait fail yang dipindahkan menunjukkan bahawa 1024 bait telah dipindahkan. Saya sekali lagi tidak tahu apa maksud bait yang tinggal.
Pertama sekali, sebagai nama panggilan BBS lama, saya menyemak protokol penghantaran standard. Tiada protokol yang dihantar 1024 bait. Saya mula mengkaji perkakasan dan menemui protokol 1K Xmodem. Ia membenarkan penghantaran 1024, tetapi dengan kaveat: pada mulanya hanya 128, dan hanya jika tiada ralat, protokol meningkatkan bilangan bait yang dihantar. Saya segera mempunyai pemindahan 1024 bait. Saya memutuskan untuk mengkaji protokol penghantaran, dan khususnya modem X.
Terdapat dua variasi modem.
Pertama, format pakej XMODEM dengan sokongan CRC8 (XMODEM asal):
Kedua, format paket XMODEM dengan sokongan CRC16 (XmodemCRC):
Ia kelihatan serupa, kecuali untuk SOH, nombor pakej dan CRC serta panjang pakej.
Saya melihat pada permulaan blok penghantaran kedua (dan sekali lagi melihat fail perisian tegar, tetapi sudah diinden oleh 1024 bait):
Saya melihat pengepala biasa fd 3e 02, tetapi dua bait seterusnya telah pun berubah: ia adalah 01 fe, dan menjadi 02 fd. Kemudian saya perhatikan bahawa blok kedua kini bernombor 02 dan dengan itu faham: di hadapan saya adalah penomboran blok penghantaran. Gear 1024 pertama ialah 01, yang kedua ialah 02, yang ketiga ialah 03 dan seterusnya (tetapi dalam hex, sudah tentu). Tetapi apakah maksud perubahan daripada fe kepada fd? Mata melihat penurunan sebanyak 1, otak mengingatkan bahawa pengaturcara mengira dari 0, bukan 1. Tetapi mengapa blok pertama 1, dan bukan 0? Saya masih tidak menemui jawapan kepada soalan ini. Tetapi saya faham bagaimana blok kedua dikira. Blok kedua tidak lebih daripada FF β (tolak) nombor blok pertama. Oleh itu, blok kedua telah ditetapkan sebagai = 02 (FF-02) = 02 FD. Pembacaan tempat pembuangan seterusnya mengesahkan tekaan saya.
Kemudian gambar penghantaran berikut mula muncul:
Permulaan penghantaran
fd 3e 02 β Mula
01 FE β kaunter penghantaran
Pemindahan (34 blok, 1024 bait dipindahkan)
fd 3e 1024 bait data (dibahagikan kepada 30 bait blok).
Tamat penghantaran
fd 25
Baki data untuk diselaraskan kepada 1024 bait.
Apakah rupa rangka hujung penghantaran blok:
fd 25 β isyarat untuk menamatkan penghantaran blok. Seterusnya 2f 52 β selebihnya fail sehingga saiz 1024 bait. 2f 52, berdasarkan protokol, ialah 16-bit CRC checksum.
Untuk kepentingan zaman dahulu, saya membuat program dalam C yang menarik 1024 bait daripada fail dan mengira CRC 16-bit. Melancarkan program menunjukkan bahawa ini bukan CRC 16-bit. Stupor lagi - selama kira-kira tiga hari. Selama ini saya cuba memahami apa yang boleh jadi, jika bukan checksum. Semasa mengkaji tapak berbahasa Inggeris, saya mendapati bahawa X-modem menggunakan pengiraan checksum sendiri - CRC-CCITT (XModem). Saya tidak menjumpai sebarang pelaksanaan C pengiraan ini, tetapi saya menemui tapak yang mengira checksum ini dalam talian. Setelah memindahkan 1024 bait fail saya ke halaman web, tapak tersebut menunjukkan kepada saya jumlah semak yang sepadan sepenuhnya dengan jumlah semak daripada fail.
Hooray! Teka-teki terakhir telah diselesaikan, kini saya perlu membuat firmware saya sendiri. Seterusnya, saya menyampaikan pengetahuan saya (dan ia hanya tinggal di kepala saya) kepada Ilya, yang biasa dengan Python toolkit yang berkuasa.
Mencipta program
Ilya Aleshin melaporkan.
Setelah menerima arahan yang sesuai, saya sangat "gembira".
Di mana untuk bermula? Betul, dari awal lagi. ο Daripada membuang sampah dari port USB.
Lancarkan USB-pcap
Pilih port yang peranti disambungkan dan fail tempat kami akan menyimpan pembuangan.
Kami menyambungkan pengimbas ke mesin di mana perisian EZConfigScanning asli untuk Windows dipasang.
Di dalamnya kita dapati item untuk menghantar arahan ke peranti. Tetapi bagaimana dengan pasukan? Di mana saya boleh mendapatkannya?
Apabila program bermula, peralatan ditinjau secara automatik (kita akan melihat ini sedikit kemudian). Dan terdapat kod bar latihan daripada dokumen peralatan rasmi. DEFALT. Ini pasukan kami.
Data yang diperlukan telah diterima. Buka dump.pcap melalui wireshark.
Sekat apabila memulakan EZConfigScanning. Tempat yang perlu anda perhatikan ditandakan dengan warna merah.
Melihat semua ini buat kali pertama, saya hilang semangat. Tidak jelas di mana hendak digali seterusnya.
Sedikit sumbangsaran dan-dan-dan... Aha! Di tempat pembuangan keluar - Adakah inDan in ΡΡΠΎ keluar.
Saya google apa itu URB_INTERRUPT. Saya mendapati bahawa ini adalah kaedah pemindahan data. Dan terdapat 4 kaedah sedemikian: kawalan, sampukan, isokronus, pukal. Anda boleh membaca tentang mereka secara berasingan.
Dan alamat titik akhir dalam antara muka peranti USB boleh diperolehi sama ada melalui arahan "lsusb βv" atau menggunakan pyusb.
Sekarang kita perlu mencari semua peranti dengan VID ini. Anda boleh mencari secara khusus melalui VID:PID.
Ia kelihatan seperti ini:
Jadi, kami mempunyai maklumat yang diperlukan: arahan P_INFO. atau DEFALT, alamat tempat menulis perintah endpoint=03 dan tempat untuk mendapatkan titik akhir respons=86. Apa yang tinggal ialah menukar arahan kepada hex.
Memandangkan kita telah menemui peranti itu, mari kita putuskan sambungannya daripada kernel...
...dan tulis ke titik akhir dengan alamat 0x03,
... dan kemudian baca respons dari titik akhir dengan alamat 0x86.
Jawapan berstruktur:
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: 0x6986Kami melihat data ini dalam dump.pcap.
Hebat! Tukar kod bar sistem kepada hex. Itu sahaja, fungsi latihan sudah sedia.
Bagaimana dengan firmware? Semuanya kelihatan sama, tetapi ada nuansa.
Setelah membuang sepenuhnya proses berkelip, kami secara kasar memahami perkara yang kami hadapi. Berikut ialah artikel tentang XMODEM, yang sangat membantu dalam memahami cara komunikasi ini berlaku, walaupun secara umum: Saya mengesyorkan membacanya.
Melihat tempat pembuangan, anda dapat melihat bahawa saiz bingkai ialah 1024, dan saiz data URB ialah 64.
Oleh itu β 1024/64 β kami mendapat 16 baris dalam satu blok, membaca fail perisian tegar 1 aksara pada satu masa dan membentuk satu blok. Melengkapkan 1 baris dalam blok dengan aksara khas fd3e02 + nombor blok.
14 baris seterusnya ditambah dengan fd25 +, menggunakan XMODEM.calc_crc() kami mengira jumlah semak keseluruhan blok (ia mengambil banyak masa untuk memahami bahawa "FF - 1" ialah CSUM) dan baris ke-16 yang terakhir ditambah dengan fd3e.
Nampaknya itu sahaja, baca fail perisian tegar, tekan blok, cabut pengimbas dari kernel dan hantar ke peranti. Tetapi ia tidak semudah itu. Pengimbas perlu ditukar kepada mod perisian tegar,
ΠΎΡΠΏΡΠ°Π²ΠΈΠ² Π΅ΠΌΡ NEWAPP = β\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0dβ.
Pasukan mana ni?? Dari tempat pembuangan sampah.
Tetapi kami tidak boleh menghantar keseluruhan blok ke pengimbas kerana had 64:
Nah, pengimbas dalam mod berkelip NEWAPP tidak menerima hex. Oleh itu, anda perlu menterjemah setiap 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]Dan kemudian hantar data ini ke pengimbas.
Kami mendapat jawapannya:
[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]Jika anda menyemak artikel tentang XMODEM, ia akan menjadi jelas: data telah diterima.
Selepas semua blok telah dipindahkan, kami melengkapkan pemindahan END_TRANSFER = 'xfdx01x04'.
Oleh kerana blok ini tidak membawa sebarang maklumat untuk orang biasa, kami akan memasang perisian tegar dalam mod tersembunyi secara lalai. Dan untuk berjaga-jaga, kami akan mengatur bar kemajuan melalui tqdm.
Sebenarnya, ia adalah perkara kecil. Yang tinggal hanyalah membungkus penyelesaian dalam skrip untuk replikasi besar-besaran pada masa yang jelas, supaya tidak melambatkan proses bekerja di pembayaran, dan menambah pengelogan.
Jumlah
Setelah menghabiskan banyak masa dan usaha dan rambut di kepala kami, kami dapat membangunkan penyelesaian yang kami perlukan, dan juga memenuhi tarikh akhir. Pada masa yang sama, pengimbas kini disinar semula dan dilatih semula secara berpusat, kami mengawal keseluruhan proses dengan jelas. Syarikat itu menjimatkan masa dan wang, dan kami memperoleh pengalaman yang tidak ternilai dalam peralatan kejuruteraan terbalik jenis ini.
Sumber: www.habr.com