Поздрав свима.
Ми, Виктор Антипов и Иља Аљешин, данас ћемо говорити о нашем искуству рада са УСБ уређајима преко Питхон ПиУСБ-а и мало о обрнутом инжењерингу.
praistorija
У 2019. години, Уредба Владе Руске Федерације бр. 224 „О усвајању Правила за означавање дуванских производа средствима идентификације и карактеристикама имплементације државног информационог система за праћење промета робе која подлеже обавезном означавању средствима за идентификацију у односу на дуванске производе” ступио на снагу.
У документу се објашњава да су од 1. јула 2019. произвођачи дужни да обележе свако паковање дувана. А директни дистрибутери морају да приме ове производе уз извршење универзалног преносног документа (УДД). Продавнице, пак, треба да региструју продају означених производа преко касе.
Такође, од 1. јула 2020. године забрањен је промет неозначених дуванских производа. То значи да све кутије цигарета морају бити означене посебним Датаматрик бар кодом. Штавише - важна ствар - испоставило се да Датаматрик неће бити обичан, већ инверзан. Односно, не црни код на белом, већ обрнуто.
Тестирали смо наше скенере и испоставило се да већину њих треба допунити/обучити, иначе једноставно неће моћи нормално да раде са овим бар кодом. Овакав развој догађаја гарантовао нам је јаку главобољу, јер наша компанија има много продавница које су раштркане на огромној територији. Неколико десетина хиљада каса – а врло мало времена.
Шта је требало учинити? Постоје две опције. Прво: инжењери на лицу места ручно обнављају и подешавају скенере. Друго: радимо на даљину и, по могућности, покријемо више скенера одједном у једној итерацији.
Прва опција нам, очигледно, није одговарала: морали бисмо да трошимо новац на посете инжењерима, ау овом случају би било тешко контролисати и координирати процес. Али најважније је да би људи радили, односно да бисмо потенцијално добили много грешака и, највероватније, не испоштовали рок.
Друга опција је добра за све, ако не и за једну ствар. Неки добављачи нису имали алате за даљинско флешовање које су нам биле потребне за све потребне оперативне системе. А пошто су рокови истицали, морао сам да размишљам својом главом.
Затим ћемо вам рећи како смо развили алате за ручне скенере за Дебиан 9.к ОС (све наше касе су на Дебиан-у).
Решите загонетку: како да флешујете скенер
Извештава Виктор Антипов.
Званични услужни програм који је обезбедио добављач ради под Виндовс-ом и само са ИЕ. Услужни програм може да флешује и конфигурише скенер.
Пошто је наш циљни систем Дебиан, инсталирали смо сервер за усб преусмеравање на Дебиан и клијент за усб преусмеравање на Виндовс. Користећи усб-редирецтор услужне програме, проследили смо скенер са Линук машине на Виндовс машину.
Услужни програм Виндовс добављача је видео скенер и чак га је нормално бљеснуо. Дакле, донели смо први закључак: ништа не зависи од ОС-а, ствар је у протоколу флешовања.
ОК. Покренули смо флешовање на Виндовс машини и уклонили думп на Линук машини.
Убацили смо думп у ВиреСхарк и... се растужили (изоставићу неке детаље о сметлишту, нису од интереса).
Шта нам је депонија показала:
Адресе 0000-0030, судећи по Виресхарку, су информације о УСБ сервису.
Интересовао нас је део 0040-0070.
Ништа није било јасно из једног оквира преноса осим МОЦФТ карактера. Испоставило се да су ови знакови знакови из датотеке фирмвера, као и преостали знакови до краја оквира (датотека фирмвера је истакнута):
Шта значе симболи фд 3е 02 01 фе, ја лично, као и Иља, нисам имао појма.
Погледао сам следећи оквир (информације о сервису су овде уклоњене, фајл фирмвера је истакнут):
Шта је постало јасно? Да су прва два бајта нека врста константе. Сви наредни блокови су то потврдили, али пре краја блока преноса:
Овај оквир је такође био запањујући, пошто се константа променила (истакнула) и, што је чудно, постојао је део датотеке. Величина пренетих бајтова датотеке показала је да је пренето 1024 бајта. Опет нисам знао шта значе преостали бајтови.
Пре свега, као стари ББС надимак, прегледао сам стандардне протоколе за пренос. Ниједан протокол није пренео 1024 бајта. Почео сам да проучавам хардвер и наишао на 1К Ксмодем протокол. Дозвољавао је пренос 1024, али уз упозорење: у почетку само 128, и само ако није било грешака, протокол је повећавао број пренетих бајтова. Одмах сам имао трансфер од 1024 бајта. Одлучио сам да проучавам протоколе за пренос, а посебно Кс-модем.
Постојале су две варијанте модема.
Прво, формат пакета КСМОДЕМ са подршком за ЦРЦ8 (оригинални КСМОДЕМ):
Друго, формат КСМОДЕМ пакета са подршком ЦРЦ16 (КсмодемЦРЦ):
Изгледа слично, осим СОХ-а, броја пакета и ЦРЦ-а и дужине пакета.
Погледао сам почетак другог блока преноса (и поново видео датотеку фирмвера, али већ увучену са 1024 бајта):
Видео сам познато заглавље фд 3е 02, али следећа два бајта су се већ променила: било је 01 фе и постало је 02 фд. Тада сам приметио да је други блок сада означен бројем 02 и тако схватио: испред мене је била нумерација блока преноса. Прва 1024 брзина је 01, друга је 02, трећа је 03 и тако даље (али хексадецимално, наравно). Али шта значи промена из фе у фд? Очи су виделе смањење за 1, мозак је подсетио да програмери броје од 0, а не од 1. Али зашто је онда први блок 1, а не 0? Још увек нисам нашао одговор на ово питање. Али разумео сам како се броји други блок. Други блок није ништа више од ФФ – (минус) број првог блока. Дакле, други блок је означен као = 02 (ФФ-02) = 02 ФД. Накнадно читање депоније потврдило је моју претпоставку.
Тада је почела да се појављује следећа слика преноса:
Почетак преноса
фд 3е 02 – Старт
01 ФЕ – бројач преноса
Пренос (34 блока, пренето 1024 бајта)
фд 3е 1024 бајтова података (подељених на блокове од 30 бајтова).
Крај преноса
фд 25
Преостале податке треба ускладити са 1024 бајта.
Како изгледа крајњи оквир преноса блока:
фд 25 – пренос сигнала до краја блока. Следећи 2ф 52 – остатак датотеке величине до 1024 бајта. 2ф 52, судећи по протоколу, је 16-битни ЦРЦ контролни збир.
Због старих времена, направио сам програм у Ц који је извукао 1024 бајта из датотеке и израчунао 16-битни ЦРЦ. Покретање програма показало је да ово није 16-битни ЦРЦ. Опет ступор - око три дана. Све ово време покушавао сам да схватим шта би то могло бити, ако не контролни збир. Док сам проучавао сајтове на енглеском, открио сам да Кс-модем користи сопствени прорачун контролне суме - ЦРЦ-ЦЦИТТ (КСМодем). Нисам пронашао ниједну Ц имплементацију овог прорачуна, али сам нашао сајт који је израчунао овај контролни збир на мрежи. Преневши 1024 бајта моје датотеке на веб страницу, сајт ми је показао контролни збир који се у потпуности поклапао са контролним збиром из датотеке.
Ура! Последња загонетка је решена, сада сам морао да направим сопствени фирмвер. Затим сам своје знање (и остало је само у мојој глави) пренео Иљи, који је упознат са моћним алатом Питхон.
Креирање програма
Иља Аљешин извештава.
Пошто сам добио одговарајућа упутства, био сам веома „срећан“.
Где да почнем? Тако је, од почетка. Од преузимања података са УСБ порта.
Покрените УСБ-пцап
Изаберите порт на који је уређај повезан и датотеку у коју ћемо сачувати думп.
Повезујемо скенер са машином на којој је инсталиран изворни софтвер ЕЗЦонфигСцаннинг за Виндовс.
У њему налазимо ставку за слање команди уређају. Али шта је са тимовима? Где могу да их набавим?
Када се програм покрене, опрема се аутоматски прозива (видећемо то мало касније). А ту су били и бар кодови за обуку из званичних докумената опреме. ДЕФАЛТ. Ово је наш тим.
Потребни подаци су примљени. Отворите думп.пцап преко виресхарк-а.
Блокирајте при покретању ЕЗЦонфигСцаннинг. Места на која треба да обратите пажњу су означена црвеном бојом.
Видевши све ово први пут, изгубио сам дух. Није јасно где даље копати.
Мало размишљања и-и-и... Аха! На сметлишту напоље - Је inИ in ово напоље.
Гуглао сам шта је УРБ_ИНТЕРРУПТ. Сазнао сам да је ово метод преноса података. И постоје 4 такве методе: контрола, прекид, изохроно, масовно. О њима можете прочитати одвојено.
А адресе крајњих тачака у интерфејсу УСБ уређаја могу се добити или преко команде „лсусб –в“ или помоћу пиусб.
Сада морамо да пронађемо све уређаје са овим ВИД-ом. Можете претраживати посебно према ВИД:ПИД.
То изгледа овако:
Дакле, имамо потребне информације: команде П_ИНФО. или ДЕФАЛТ, адресе где треба написати команде ендпоинт=03 и где добити одговор ендпоинт=86. Остаје само да конвертујете команде у хексадецимални.
Пошто смо већ пронашли уређај, хајде да га искључимо из кернела...
...и писати на крајњу тачку са адресом 0к03,
... а затим прочитајте одговор са крајње тачке са адресом 0к86.
Структурирани одговор:
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Ове податке видимо у думп.пцап.
Велики! Претворите системске бар кодове у хексадецимални. То је то, функционалност обуке је спремна.
Шта је са фирмвером? Чини се да је све исто, али постоји нијанса.
Након што смо потпуно избрисали процес флешовања, отприлике смо схватили са чиме имамо посла. Ево чланка о КСМОДЕМ-у, који је био од велике помоћи у разумевању како се ова комуникација одвија, иако уопштено: Препоручујем читање.
Гледајући думп, можете видети да је величина оквира 1024, а величина УРБ података 64.
Дакле – 1024/64 – добијамо 16 редова у блоку, читамо датотеку фирмвера 1 знак по један и формирамо блок. Допуњавање 1 реда у блоку специјалним знаковима фд3е02 + број блока.
Следећих 14 редова је допуњено са фд25 +, користећи КСМОДЕМ.цалц_црц() израчунавамо контролни збир целог блока (требало је доста времена да схватимо да је „ФФ – 1“ ЦСУМ) и последњи, 16. ред је допуњен са фд3е.
Чини се да је то то, прочитајте датотеку фирмвера, ударите блокове, искључите скенер из кернела и пошаљите га на уређај. Али то није тако једноставно. Скенер треба да се пребаци у режим фирмвера,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Одакле је ова екипа?? Са депоније.
Али не можемо да пошаљемо цео блок скенеру због ограничења од 64:
Па, скенер у НЕВАПП режиму треперења не прихвата хек. Због тога ћете морати да преведете сваки ред битес_арраи
[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]А затим пошаљите ове податке скенеру.
Добијамо одговор:
[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]Ако погледате чланак о КСМОДЕМ-у, биће јасно: подаци су прихваћени.
Након што су сви блокови пребачени, завршавамо пренос ЕНД_ТРАНСФЕР = 'кфдк01к04'.
Па, пошто ови блокови не носе никакве информације за обичне људе, ми ћемо подразумевано инсталирати фирмвер у скривеном режиму. И за сваки случај, ми ћемо организовати траку напретка кроз ткдм.
У ствари, онда је то ствар малих ствари. Остаје само да се решење увије у скрипте за масовну репликацију у јасно дефинисано време, како се не би успоравао процес рада на касама, и да се дода логовање.
Укупан
Пошто смо потрошили много времена и труда и косе на глави, успели смо да развијемо решења која су нам била потребна, а такође смо испоштовали рок. У исто време, скенери су сада централно обновљени и поново обучени, ми јасно контролишемо цео процес. Компанија је уштедела време и новац, а стекли смо непроцењиво искуство у опреми за реверзни инжењеринг овог типа.
Извор: ввв.хабр.цом