Halo semuanya.Kami, Victor Antipov dan Ilya Aleshin, hari ini akan berbicara tentang pengalaman kami dengan perangkat USB melalui Python PyUSB dan sedikit tentang reverse engineering.
Latar Belakang
Pada tahun 2019, Keputusan Pemerintah Federasi Rusia No. 224 “Atas persetujuan aturan pelabelan produk tembakau dengan cara identifikasi dan spesifikasi memperkenalkan sistem informasi negara untuk memantau sirkulasi barang yang dikenakan pelabelan wajib dengan cara identifikasi dalam kaitannya dengan produk tembakau” mulai berlaku.Dokumen tersebut menjelaskan bahwa mulai 1 Juli 2019, produsen diwajibkan untuk memberi label pada setiap bungkus tembakau. Dan distributor langsung harus menerima produk-produk ini dengan desain dokumen transfer universal (UPD). Toko, pada gilirannya, perlu mendaftarkan penjualan produk berlabel melalui mesin kasir.Juga, mulai 1 Juli 2020, produk tembakau yang tidak ditandai dilarang. Ini berarti bahwa semua bungkus rokok harus diberi label dengan barcode Datamatrix khusus. Dan - poin penting - ternyata Datamatrix tidak akan menjadi biasa, tetapi terbalik. Artinya, bukan kode hitam di atas putih, tetapi sebaliknya.Kami menguji pemindai kami, dan ternyata sebagian besar perlu direfleksikan / dilatih ulang, jika tidak mereka tidak dapat bekerja secara normal dengan barcode ini. Pergantian peristiwa ini membuat kami sakit kepala parah, karena perusahaan kami memiliki banyak toko yang tersebar di wilayah yang luas. Beberapa puluh ribu meja kas - dan waktu yang sangat sedikit.Apa yang harus dilakukan? Ada dua opsi. Pertama: para insinyur di fasilitas secara manual merefleksikan dan menyesuaikan pemindai. Kedua: kami bekerja dari jarak jauh dan, lebih disukai, kami mencakup banyak pemindai sekaligus dalam satu iterasi.Opsi pertama, jelas, tidak cocok untuk kita: kita harus mengeluarkan uang untuk kunjungan lapangan para insinyur, dan sulit untuk mengendalikan dan mengoordinasikan proses dalam kasus ini. Tetapi yang paling penting adalah bahwa orang akan bekerja, yaitu, berpotensi kita akan mendapatkan banyak kesalahan dan, kemungkinan besar, tidak akan sesuai dengan tenggat waktu.Opsi kedua baik untuk semua orang, jika bukan untuk satu tetapi. Beberapa vendor tidak memiliki alat flashing jarak jauh yang kami butuhkan untuk semua sistem operasi yang diperlukan. Dan karena tenggat waktu hampir habis, saya harus berpikir dengan kepala sendiri.Selanjutnya, kami akan menjelaskan bagaimana kami mengembangkan alat untuk pemindai genggam untuk OS Debian 9.x (kami memiliki semua box office Debian).:
Kata Victor Antipov.Utilitas resmi yang disediakan oleh vendor bekerja di bawah Windows, dan hanya dengan IE. Utilitas dapat menginstal dan mengkonfigurasi pemindai.Karena sistem targetnya adalah Debian, kami memasang server usb-redirector di server Debian dan klien usb-redirector di Windows. Menggunakan utilitas usb-redirector, pemindai diteruskan dari mesin Linux ke mesin Windows.Utilitas dari vendor Windows melihat pemindai dan bahkan mem-flashnya secara normal. Jadi, kesimpulan pertama dibuat: tidak ada yang tergantung pada OS, masalahnya ada di protokol flashing.BAIK. Sebuah flashing diluncurkan pada mesin Windows, dan dump dihapus pada mesin Linux.Mereka memasukkan dump ke WireShark dan ... sedih (saya akan menghilangkan bagian dari detail dump, mereka tidak tertarik).Apa yang ditunjukkan dump kepada kami:
Alamat 0000-0030, dinilai oleh Wireshark, adalah informasi layanan USB.Kami tertarik pada bagian 0040-0070.Tidak ada yang jelas dari satu bingkai transmisi, kecuali untuk karakter MOCFT. Simbol-simbol ini ternyata menjadi simbol dari file firmware, serta simbol-simbol lainnya hingga akhir frame (file firmware disorot):
Apa yang dimaksud dengan simbol fd 3e 02 01 fe, saya pribadi, seperti Ilya, tidak tahu.Saya melihat bingkai berikutnya (informasi layanan dihapus di sini, file firmware disorot):
Apa yang menjadi jelas? Bahwa dua byte pertama adalah semacam konstanta. Semua blok berikutnya mengkonfirmasi ini, tetapi sebelum akhir blok transmisi:
Bingkai ini juga masuk ke dalam keadaan pingsan, karena konstanta berubah (disorot) dan, anehnya, ada bagian dari file. Ukuran byte yang ditransmisikan dari file menunjukkan bahwa 1024 byte ditransfer. Apa artinya byte yang tersisa - saya tidak tahu lagi.Pertama-tama, seperti nama panggilan BBS lama, saya merevisi protokol transfer standar. 1024 byte, tidak ada protokol yang diteruskan. Dia mulai mempelajari materiil dan menemukan protokol 1K Xmodem. Itu memungkinkan untuk mengirimkan 1024, tetapi dengan nuansa: pada awalnya hanya 128, dan hanya tanpa adanya kesalahan protokol meningkatkan jumlah byte yang dikirim. Saya segera memiliki transmisi 1024 byte. Saya memutuskan untuk mempelajari protokol transmisi, dan khususnya X-modem.Ada dua variasi modem.Pertama, format paket XMODEM dengan dukungan CRC8 (XMODEM asli):
Kedua, format paket XMODEM dengan dukungan CRC16 (XmodemCRC):
Kelihatannya mirip, dengan pengecualian SOH, nomor paket dan CRC dan panjang paket.Saya melihat awal blok transmisi kedua (dan sekali lagi melihat file firmware, tetapi dengan indentasi 1024 bytes):
Saya melihat tajuk akrab fd 3e 02, tetapi dua byte berikutnya sudah berubah: itu 01 fe, dan itu menjadi 02 fd. Kemudian saya perhatikan bahwa blok kedua sekarang bernomor 02 dan dengan demikian dipahami: di depan saya adalah penomoran blok transmisi. Transmisi 1024 pertama adalah 01, 02 kedua, 03 ketiga dan seterusnya (tetapi dalam hex, tentu saja). Tapi apa artinya perubahan dari fe ke fd? Mata melihat penurunan 1, otak mengingatkan bahwa programmer menghitung dari 0, bukan dari 1. Tapi mengapa blok pertama 1, bukan 0? Saya tidak menemukan jawaban untuk pertanyaan ini. Tapi saya mengerti bagaimana blok kedua dipertimbangkan. Blok kedua tidak lebih dari FF - (minus) jumlah blok pertama. Dengan demikian, blok kedua ditetapkan sebagai = 02 (FF-02) = 02 FD. Pembacaan berikutnya dari dump mengkonfirmasi firasat saya.Kemudian gambar program berikut mulai muncul:Awal programfd 3e 02 - Mulai01 FE - penghitung transmisiTransmisi (34 blok, 1024 byte ditransmisikan)fd 3e 1024 byte data (dibagi menjadi blok 30 byte).Akhir transmisifd 25Sisa data untuk disejajarkan dengan 1024 byte.Seperti apakah bingkai ujung transfer blok:
fd 25 - sinyal ke akhir transfer blok. Berikutnya 2f 52 - sisa-sisa file hingga 1024 byte. 2f 52, dilihat dari protokol, adalah checksum CRC 16-bit.Berdasarkan memori lama, saya membuat program dalam C yang menarik 1024 byte dari file dan membaca CRC 16-bit. Peluncuran program menunjukkan bahwa ini bukan CRC 16-bit. Sekali lagi pingsan - selama sekitar tiga hari. Selama ini saya mencoba memahami apa jadinya jika bukan checksum. Mempelajari situs berbahasa Inggris, saya menemukan bahwa X-modem menggunakan perhitungan checksum sendiri - CRC-CCITT (XModem). Saya tidak menemukan implementasi dalam C untuk perhitungan ini, tetapi saya menemukan situs yang membaca checksum ini secara online. Setelah ditransfer ke halaman web 1024 byte dari file saya, situs menunjukkan kepada saya sebuah checksum yang sepenuhnya bertepatan dengan checksum dari file tersebut.Hore! Teka-teki terakhir terpecahkan, sekarang Anda harus membuat firmware sendiri. Kemudian saya mentransfer pengetahuan saya (dan mereka hanya tinggal di kepala saya) ke Ilya, yang akrab dengan alat yang kuat - Python.Pembuatan program
Diceritakan oleh Ilya Aleshin.Setelah menerima instruksi yang sesuai, saya sangat “senang”.Di mana untuk memulai? Benar, dari awal. Dari dumping dari port USB.Jalankan USB-pcap https://desowin.org/usbpcap/tour.htmlPilih port tempat perangkat terhubung dan file tempat kami akan menyimpan dump.
Kami menghubungkan pemindai ke mesin tempat perangkat lunak EZConfigScanning asli untuk Windows diinstal.
Di dalamnya kita menemukan titik mengirim perintah ke perangkat. Tapi bagaimana dengan tim? Di mana mendapatkannya?Ketika program dimulai, peralatan diinterogasi secara otomatis (kita akan melihatnya nanti). Dan ada barcode pelatihan dari dokumen peralatan resmi. DEFALT. Ini tim kami.
Data yang diperlukan diterima. Buka dump.pcap melalui wireshark.Blokir saat startup EZConfigScanning. Poin merah adalah tempat yang harus diperhatikan.
Melihat semua ini untuk pertama kalinya, saya kehilangan hati. Tempat menggali lebih jauh tidak jelas.Sedikit brainstorming dan-dan-dan ... Aha! Di sebuah dump, keluar adalah di , dan di adalah keluar .Cari Google apa itu URB_INTERRUPT. Mengetahui bahwa ini adalah metode transfer data. Dan ada 4 metode seperti: kontrol, interupsi, isochronous, bulk. Anda dapat membacanya secara terpisah.Dan alamat titik akhir di antarmuka perangkat USB dapat diperoleh baik melalui perintah “lsusb –v”, atau dengan menggunakan pyusb.Sekarang Anda perlu menemukan semua perangkat dengan VID ini. Anda dapat mencari secara spesifik dengan VID: PID.
Ini terlihat seperti ini:
Jadi, kami memiliki informasi yang diperlukan: perintah P_INFO. atau DEFALT, alamat tempat menulis perintah titik akhir = 03 dan di mana mendapatkan jawaban titik akhir = 86. Tetap hanya menerjemahkan perintah dalam hex.
Karena kita sudah menemukan perangkat, lepaskan dari kernel ...
... dan tulis ke titik akhir dengan alamat 0x03,
... dan kemudian baca respons dari titik akhir dengan alamat 0x86.
Jawaban 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: 0x6986
Kami melihat data ini di dump.pcap.
Baik! Kami menerjemahkan barcode sistem ke hex. Semuanya, fungsionalitas pelatihan siap.Apa yang harus dilakukan dengan firmware? Tampaknya semuanya sama, tetapi ada nuansa.Setelah menghapus seluruh proses flashing, kami secara kasar memahami apa yang sedang kami hadapi. Berikut adalah artikel tentang XMODEM yang benar-benar membantu untuk memahami bagaimana komunikasi ini terjadi, meskipun secara umum: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html Saya sarankan membacanya.Melihat di dump, Anda dapat melihat bahwa ukuran frame adalah 1024, dan ukuran data-URB adalah 64.
Oleh karena itu, 1024/64, kami mendapatkan 16 baris dalam satu blok, membaca file firmware dengan 1 karakter dan membentuk sebuah blok. Melengkapi 1 baris dalam satu blok dengan karakter khusus fd3e02 + nomor blok.14 baris berikutnya dilengkapi dengan fd25 +, menggunakan XMODEM.calc_crc () kami menghitung checksum dari seluruh blok (butuh banyak waktu untuk memahami bahwa "FF - 1" adalah CSUM) dan baris 16 terakhir ditambah dengan fd3e.Tampaknya semuanya, baca file firmware, tekan blok, lepaskan pemindai dari kernel dan kirim ke perangkat. Tapi tidak sesederhana itu. Pemindai harus dimasukkan ke mode firmware denganmengirimkannya NEWAPP = '\\ xfd \\ x0a \\ x16 \\ x4e \\ x2c \\ x4e \\ x45 \\ x57 \\ x41 \\ x50 \\ x50 \\ x0d'.Dari mana datangnya perintah ini ?? Dari tempat sampah.
Tetapi kami tidak dapat mengirim seluruh blok ke pemindai karena pembatasan 64:
Ya, pemindai dalam mode flashing NEWAPP juga tidak menerima hex. Oleh karena itu perlu menerjemahkan 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 sudah mengirimkan data ini ke pemindai.Kami mendapatkan jawabannya:[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 memeriksa artikel tentang XMODEM, menjadi jelas: data telah diterima.
Setelah semua blok ditransfer, kami menyelesaikan transfer END_TRANSFER = '\ xfd \ x01 \ x04'.Ya, karena blok ini tidak membawa informasi apa pun untuk orang awam, kami akan membuat firmware dalam mode tersembunyi secara default. Dan untuk berjaga-jaga, melalui tqdm kami akan mengatur progress bar.
Sebenarnya, sisanya kecil. Tetap hanya untuk membungkus solusi dalam skrip untuk replikasi massal pada waktu yang jelas, agar tidak memperlambat proses bekerja di box office, dan menambahkan logging.Total
Setelah menghabiskan banyak waktu, energi, dan rambut di kepala , kami dapat mengembangkan solusi yang kami butuhkan, terlebih lagi, kami memenuhi tenggat waktu. Pada saat yang sama, pemindai dicetak ulang dan dilatih kembali sekarang secara terpusat, kami jelas mengendalikan seluruh proses. Perusahaan menghemat waktu dan uang, dan kami mendapatkan pengalaman yang tak ternilai dalam rekayasa terbalik dari peralatan jenis ini.