Herkese Merhaba.
Biz, Viktor Antipov ve Ilya Aleshin, bugün Python PyUSB aracılığıyla USB cihazlarıyla çalışma deneyimlerimizden ve biraz da tersine mühendislikten bahsedeceğiz.
tarih öncesi
2019 yılında, 224 Sayılı Rusya Federasyonu Hükümeti Kararnamesi “Tütün ürünlerinin tanımlama araçlarıyla etiketlenmesine ilişkin Kuralların onaylanması ve tanımlama araçlarıyla zorunlu etiketlemeye tabi malların dolaşımını izlemek için bir devlet bilgi sisteminin uygulanmasının özellikleri hakkında Tütün ürünlerine ilişkin düzenleme" yürürlüğe girdi.
Belgede, 1 Temmuz 2019'dan itibaren üreticilerin her tütün paketini etiketlemesi gerektiği belirtiliyor. Ve doğrudan distribütörlerin bu ürünleri evrensel bir transfer belgesi (UDD) düzenleyerek alması gerekir. Mağazaların ise etiketli ürünlerin satışını kasa aracılığıyla kaydetmesi gerekiyor.
Ayrıca 1 Temmuz 2020 tarihinden itibaren etiketsiz tütün ürünlerinin dolaşımı da yasaklanmıştır. Bu, tüm sigara paketlerinin özel bir Datamatrix barkoduyla işaretlenmesi gerektiği anlamına gelir. Üstelik - önemli bir nokta - Datamatrix'in sıradan değil ters olacağı ortaya çıktı. Yani beyaz üzerine siyah kod değil, tam tersi.
Tarayıcılarımızı test ettik ve çoğunun yeniden flaşlanması/yeniden eğitilmesi gerektiği ortaya çıktı, aksi takdirde bu barkodla normal şekilde çalışamayacaklar. Olayların bu şekilde değişmesi bize ciddi bir baş ağrısı yaşattı çünkü şirketimizin geniş bir bölgeye dağılmış çok sayıda mağazası var. Onbinlerce yazar kasa ve çok az zaman.
Ne yapılması gerekiyordu? İki seçenek var. Birincisi: sahadaki mühendisler tarayıcıları manuel olarak yeniden çalıştırıyor ve ayarlıyor. İkincisi: uzaktan çalışıyoruz ve tercihen tek bir yinelemede birçok tarayıcıyı aynı anda inceliyoruz.
Açıkçası ilk seçenek bizim için uygun değildi: Ziyaret eden mühendislere para harcamak zorunda kalacaktık ve bu durumda süreci kontrol etmek ve koordine etmek zor olacaktı. Ancak en önemli şey insanların çalışabilmesi, yani potansiyel olarak çok fazla hata almamız ve büyük olasılıkla son teslim tarihine yetişemememizdir.
İkinci seçenek tek bir şey için olmasa da herkes için iyidir. Bazı satıcılar, gerekli tüm işletim sistemleri için ihtiyaç duyduğumuz uzaktan yükleme araçlarına sahip değildi. Ve son teslim tarihleri dolduğu için kendi kafamla düşünmek zorunda kaldım.
Daha sonra size Debian 9.x işletim sistemi için el tipi tarayıcılara yönelik araçları nasıl geliştirdiğimizi anlatacağız (tüm yazarkasalarımız Debian'dadır).
Bilmeceyi çözün: tarayıcı nasıl flaşlanır
Victor Antipov bildiriyor.
Satıcı tarafından sağlanan resmi yardımcı program Windows altında ve yalnızca IE ile çalışır. Yardımcı program tarayıcıyı flaşlayabilir ve yapılandırabilir.
Hedef sistemimiz Debian olduğundan Debian'a usb-redirector sunucusu, Windows'a ise usb-redirector istemcisi kurduk. USB yeniden yönlendirme yardımcı programlarını kullanarak tarayıcıyı bir Linux makinesinden bir Windows makinesine ilettik.
Bir Windows satıcısının yardımcı programı tarayıcıyı gördü ve hatta normal şekilde flashladı. Böylece ilk sonuca vardık: hiçbir şey işletim sistemine bağlı değildir, bu bir yanıp sönen protokol meselesidir.
TAMAM. Flashlamayı Windows makinesinde çalıştırdık ve Linux makinesindeki dökümü kaldırdık.
Çöpü WireShark'a doldurduk ve... üzüldük (çöplüğün bazı ayrıntılarını atlayacağım, hiç ilgimizi çekmiyor).
Çöplük bize ne gösterdi:
Wireshark'a göre 0000-0030 adresleri USB servis bilgileridir.
0040-0070 kısmıyla ilgilendik.
MOCFT karakterleri dışında bir iletim çerçevesinden hiçbir şey net değildi. Bu karakterlerin, ürün yazılımı dosyasındaki karakterlerin yanı sıra çerçevenin sonuna kadar kalan karakterler olduğu ortaya çıktı (ürün yazılımı dosyası vurgulanmıştır):
Fd 3e 02 01 fe sembollerinin ne anlama geldiğine dair kişisel olarak Ilya gibi hiçbir fikrim yoktu.
Aşağıdaki çerçeveye baktım (burada servis bilgileri kaldırılmış, ürün yazılımı dosyası vurgulanmıştır):
Ne netleşti? İlk iki bayt bir çeşit sabittir. Sonraki tüm bloklar bunu doğruladı, ancak iletim bloğunun bitiminden önce:
Bu çerçeve aynı zamanda şaşırtıcıydı, çünkü sabit değişmişti (vurgulanmıştı) ve garip bir şekilde dosyanın bir kısmı vardı. Dosyanın aktarılan bayt boyutu 1024 baytın aktarıldığını gösterdi. Kalan baytların ne anlama geldiğini yine bilmiyordum.
Öncelikle eski bir BBS takma adı olarak standart iletim protokollerini inceledim. Hiçbir protokol 1024 bayt iletilmedi. Donanımı incelemeye başladım ve 1K Xmodem protokolüyle karşılaştım. 1024'ün iletilmesine izin verdi, ancak bir uyarıyla: ilk başta yalnızca 128 ve yalnızca hiçbir hata olmadığında, protokol iletilen bayt sayısını artırdı. Hemen 1024 baytlık bir aktarım yaptım. İletim protokollerini ve özellikle X modemi incelemeye karar verdim.
Modemin iki çeşidi vardı.
İlk olarak, CRC8 destekli XMODEM paket formatı (orijinal XMODEM):
İkincisi, CRC16 destekli (XmodemCRC) XMODEM paket formatı:
SOH, paket numarası, CRC ve paket uzunluğu dışında benzer görünüyor.
İkinci iletim bloğunun başlangıcına baktım (ve ürün yazılımı dosyasını tekrar gördüm, ancak zaten 1024 bayt girintili):
Tanıdık fd 3e 02 başlığını gördüm, ancak sonraki iki bayt çoktan değişmişti: 01 fe idi ve 02 fd oldu. Sonra ikinci bloğun artık 02 olarak numaralandırıldığını fark ettim ve şunu anladım: önümde iletim bloğunun numaralandırması vardı. İlk 1024 vitesi 01'dir, ikincisi 02'dir, üçüncüsü 03'tür ve bu böyle devam eder (ama tabii ki onaltılı olarak). Peki fe'den fd'ye geçiş ne anlama geliyor? Gözler 1'lik bir azalma gördü, beyin programcılara 0'den değil 1'dan saymayı hatırlattı. Peki o zaman neden ilk blok 1 değil de 0? Bu sorunun cevabını hala bulamadım. Ama ikinci bloğun nasıl sayıldığını anladım. İkinci blok, ilk bloğun numarası olan FF'den (eksi) başka bir şey değildir. Böylece ikinci blok = 02 (FF-02) = 02 FD olarak belirlendi. Dökümün daha sonra okunması tahminimi doğruladı.
Daha sonra transfere ilişkin şu tablo ortaya çıkmaya başladı:
İletimin başlangıcı
fd 3e 02 – Başlat
01 FE – iletim sayacı
Aktarım (34 blok, 1024 bayt aktarıldı)
fd 3e 1024 bayt veri (30 baytlık bloklara bölünmüş).
İletimin sonu
fd 25
Kalan veriler 1024 bayta hizalanacak.
Blok iletim uç çerçevesi neye benziyor:
fd 25 – uç blok iletimine sinyal. Sonraki 2f 52 – dosyanın geri kalanının boyutu 1024 bayta kadardır. Protokole göre 2f 52, 16 bitlik bir CRC sağlama toplamıdır.
Eski günlerin hatırına, C dilinde bir dosyadan 1024 bayt alan ve 16 bitlik bir CRC hesaplayan bir program yaptım. Programın başlatılması bunun 16 bitlik bir CRC olmadığını gösterdi. Yine sersemlik - yaklaşık üç gün boyunca. Bunca zaman, bir sağlama toplamı olmasa da ne olabileceğini anlamaya çalışıyordum. İngilizce siteleri incelerken, X-modem'in kendi sağlama toplamı hesaplamasını (CRC-CCITT (XModem)) kullandığını keşfettim. Bu hesaplamanın herhangi bir C uygulamasını bulamadım, ancak bu sağlama toplamını çevrimiçi olarak hesaplayan bir site buldum. Dosyamın 1024 baytını web sayfasına aktaran site, bana dosyadaki sağlama toplamıyla tamamen eşleşen bir sağlama toplamı gösterdi.
Yaşasın! Son bilmece çözüldü, artık kendi aygıt yazılımımı oluşturmam gerekiyordu. Daha sonra bilgilerimi Python'un güçlü araç setine aşina olan Ilya'ya aktardım (ve sadece kafamda kaldı).
Bir program oluşturmak
Ilya Aleshin bildirdi.
Uygun talimatları aldıktan sonra çok “mutlu oldum”.
Nereden başlamalı? Bu doğru, başından beri. USB bağlantı noktasından döküm almaktan.
USB-pcap'i başlat
Cihazın bağlı olduğu bağlantı noktasını ve dökümü kaydedeceğimiz dosyayı seçin.
Tarayıcıyı Windows için yerel EZConfigScanning yazılımının kurulu olduğu bir makineye bağlıyoruz.
İçinde cihaza komut göndermek için kullanılan öğeyi buluyoruz. Peki ya takımlar? Onları nereden alabilirim?
Program başladığında ekipman otomatik olarak yoklanır (bunu biraz sonra göreceğiz). Ve resmi ekipman belgelerinden eğitim barkodları vardı. DEFALT. Bu bizim takımımız.
Gerekli veriler alındı. dump.pcap'i Wireshark ile açın.
EZConfigScanning'i başlatırken engelleyin. Dikkat etmeniz gereken yerler kırmızı ile işaretlenmiştir.
Bütün bunları ilk kez gördüğümde kalbimi kaybettim. Bundan sonra nereye kazılacağı belli değil.
Biraz beyin fırtınası ve-ve-ve... Aha! Çöplükte dışarı - olduğunu inVe in bu dışarı.
URB_INTERRUPT'un ne olduğunu Google'da araştırdım. Bunun bir veri aktarım yöntemi olduğunu öğrendim. Ve bu tür 4 yöntem vardır: kontrol, kesinti, eş zamanlı, toplu. Bunları ayrı ayrı okuyabilirsiniz.
USB aygıt arayüzündeki uç nokta adresleri ise “lsusb –v” komutuyla veya pyusb kullanılarak elde edilebilir.
Şimdi bu VID'ye sahip tüm cihazları bulmamız gerekiyor. Özellikle VID:PID'ye göre arama yapabilirsiniz.
Şuna benziyor:
Böylece gerekli bilgiye sahibiz: P_INFO komutları. veya DEFALT, komutların nereye yazılacağı uç noktası=03 ve yanıt uç noktası=86'nın nereden alınacağını adresler. Geriye kalan tek şey komutları hex'e dönüştürmek.
Cihazı zaten bulduğumuza göre, çekirdekle olan bağlantısını keselim...
...ve 0x03 adresiyle uç noktaya yazın,
... ve ardından 0x86 adresli uç noktadan gelen yanıtı okuyun.
Yapılandırılmış cevap:
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: 0x6986Bu veriyi dump.pcap dosyasında görüyoruz.
Harika! Sistem barkodlarını hex'e dönüştürün. İşte bu, eğitim işlevi hazır.
Ürün yazılımı ne olacak? Her şey aynı gibi görünüyor ama bir nüans var.
Yanıp sönme sürecini tamamen bitirdikten sonra, neyle karşı karşıya olduğumuzu kabaca anladık. XMODEM ile ilgili genel anlamda da olsa bu iletişimin nasıl gerçekleştiğini anlamamıza oldukça yardımcı olan bir yazı: Okumayı tavsiye ederim.
Döküme baktığınızda çerçeve boyutunun 1024, URB veri boyutunun ise 64 olduğunu görebilirsiniz.
Bu nedenle – 1024/64 – bir blokta 16 satır alıyoruz, ürün yazılımı dosyasını her seferinde 1 karakter okuyarak bir blok oluşturuyoruz. Bir bloktaki 1 satırın fd3e02 + blok numarası özel karakterleri ile tamamlanması.
Sonraki 14 satır fd25 + ile tamamlanır, XMODEM.calc_crc() kullanarak tüm bloğun sağlama toplamını hesaplarız (“FF – 1”in CSUM olduğunu anlamak çok zaman aldı) ve son 16. satır tamamlanır fd3e ile.
Öyle görünüyor ki, ürün yazılımı dosyasını okuyun, bloklara basın, tarayıcıyı çekirdekten ayırın ve cihaza gönderin. Ama bu o kadar basit değil. Tarayıcının ürün yazılımı moduna geçirilmesi gerekiyor,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Bu takım nereden? Çöplükten.
Ancak 64 sınırı nedeniyle tarayıcıya bir bloğun tamamını gönderemiyoruz:
NEWAPP yanıp sönme modundaki tarayıcı hex'i kabul etmiyor. Bu nedenle, her satırı bytes_array olarak çevirmeniz gerekecek
[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]Daha sonra bu verileri tarayıcıya gönderin.
Cevabını alıyoruz:
[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]XMODEM ile ilgili makaleyi kontrol ederseniz netleşecektir: veriler kabul edildi.
Tüm bloklar aktarıldıktan sonra aktarımı END_TRANSFER = 'xfdx01x04' tamamlıyoruz.
Peki, bu bloklar sıradan insanlar için herhangi bir bilgi taşımadığından, bellenimi varsayılan olarak gizli modda kuracağız. Her ihtimale karşı tqdm aracılığıyla bir ilerleme çubuğu düzenleyeceğiz.
Aslında o zaman mesele küçük şeyler. Geriye kalan tek şey, ödemelerde çalışma sürecini yavaşlatmamak ve günlük kaydı eklemek için çözümü açıkça tanımlanmış bir zamanda toplu çoğaltma için komut dosyalarına sarmak.
sonuç
Çok fazla zaman, çaba ve saç harcayarak ihtiyaç duyduğumuz çözümleri geliştirmeyi başardık ve aynı zamanda son teslim tarihini de yakaladık. Aynı zamanda tarayıcılar artık merkezi olarak yeniden eğitiliyor ve yeniden eğitiliyor; tüm süreci net bir şekilde kontrol ediyoruz. Şirket zamandan ve paradan tasarruf etti ve biz de bu tür tersine mühendislik ekipmanlarında paha biçilmez deneyim kazandık.
Kaynak: habr.com