Всем привет.
Біз, Виктор Антипов пен Илья Алешин, бүгін Python PyUSB арқылы USB құрылғыларымен жұмыс істеу тәжірибеміз туралы және кері инженерия туралы аздап сөйлесетін боламыз.
тарихын
2019 жылы Ресей Федерациясы Үкіметінің № 224 «Сәйкестендіру құралдарымен темекі өнімдерін таңбалау қағидаларын және сәйкестендіру құралдарымен міндетті таңбалауға жататын тауарлардың айналымын бақылаудың мемлекеттік ақпараттық жүйесін енгізу ерекшеліктерін бекіту туралы» қаулысы. темекі өнімдеріне қатысты» заңы күшіне енді.
Құжатта 1 жылдың 2019 шілдесінен бастап өндірушілер темекінің әрбір қорабын таңбалауға міндетті екені түсіндіріледі. Ал тікелей дистрибьюторлар бұл өнімдерді әмбебап тасымалдау құжатын (UDD) ресімдеу арқылы алуы керек. Дүкендер өз кезегінде таңбаланған өнімдерді сатуды касса арқылы тіркеуі қажет.
Сондай-ақ, 1 жылдың 2020 шілдесінен бастап таңбаланбаған темекі өнімдерінің айналымына тыйым салынады. Бұл барлық темекі қораптары арнайы Datamatrix штрих-кодымен белгіленуі керек дегенді білдіреді. Оның үстіне - маңызды сәт - Datamatrix қарапайым емес, керісінше болатыны белгілі болды. Яғни, ақ түсті қара код емес, керісінше.
Біз сканерлерімізді сынап көрдік және олардың көпшілігін жаңарту/қайта даярлау қажет екені белгілі болды, әйтпесе олар бұл штрих-кодпен қалыпты жұмыс істей алмайды. Оқиғалардың бұл айналымы бізге қатты бас ауруына кепілдік берді, өйткені біздің компанияда кең аумақта шашыраңқы орналасқан көптеген дүкендер бар. Бірнеше ондаған мың кассалық аппараттар – және өте аз уақыт.
Не істеу керек еді? Екі нұсқа бар. Біріншіден: сайттағы инженерлер сканерлерді қолмен қайта жарқылдайды және реттейді. Екіншіден: біз қашықтан жұмыс істейміз және жақсырақ, бір итерацияда бірден көптеген сканерлерді жабамыз.
Бірінші нұсқа, анық, бізге сәйкес келмеді: инженерлерге бару үшін ақша жұмсауға тура келеді және бұл жағдайда процесті бақылау және үйлестіру қиын болады. Бірақ ең бастысы, адамдар жұмыс істейтін еді, яғни біз көптеген қателер алуымыз мүмкін және, ең алдымен, белгіленген мерзімге сәйкес келмейтін болар едік.
Екінші нұсқа бір нәрсе үшін болмаса, барлығына жақсы. Кейбір жеткізушілерде барлық қажетті операциялық жүйелер үшін қажет қашықтан жыпылықтау құралдары болмады. Ал мерзімдер біткен соң, өз басым ойлануға тура келді.
Әрі қарай, біз Debian 9.x ОЖ үшін қол сканерлеріне арналған құралдарды қалай жасағанымызды айтамыз (барлық кассаларымыз Debian жүйесінде).
Жұмбақты шешіңіз: сканерді қалай жыпылықтау керек
Виктор Антипов хабарлайды.
Жеткізуші ұсынған ресми утилита Windows жүйесінде және тек IE-де жұмыс істейді. Утилита сканерді жыпылықтап, конфигурациялай алады.
Мақсатты жүйеміз Debian болғандықтан, біз Debian жүйесінде usb-қайта бағыттағыш серверін және Windows жүйесінде USB-қайта бағыттаушы клиентті орнаттық. USB-қайта бағыттағыш утилиталарын пайдалана отырып, біз сканерді Linux құрылғысынан Windows құрылғысына жібердік.
Windows жеткізушісінің утилитасы сканерді көріп, тіпті оны қалыпты түрде жыпылықтады. Осылайша, біз бірінші қорытынды жасадық: ештеңе ОЖ-ға байланысты емес, бұл жыпылықтайтын протокол мәселесі.
ЖАРАЙДЫ МА. Біз Windows құрылғысында жыпылықтауды іске қостық және Linux құрылғысындағы қоқысты алып тастадық.
Біз қоқысты WireShark ішіне толтырдық және... мұңайып қалдық (қоқыс туралы кейбір мәліметтерді өткізіп жіберемін, олар ешқандай қызығушылық тудырмайды).
Қоқыс бізге не көрсетті:
Wireshark бағалауы бойынша 0000-0030 мекенжайлары USB қызметінің ақпараты болып табылады.
Бізді 0040-0070 бөлімі қызықтырды.
Бір жіберу жақтауынан MOCFT таңбаларынан басқа ештеңе анық болмады. Бұл таңбалар микробағдарлама файлындағы таңбалар, сондай-ақ кадрдың соңына дейін қалған таңбалар болып шықты (микробағдарлама файлы бөлектелген):
fd 3e 02 01 fe символдары нені білдіретінін мен де Илья сияқты білмедім.
Мен келесі кадрды қарадым (қызмет туралы ақпарат осы жерден жойылған, микробағдарлама файлы бөлектелген):
Не түсінікті болды? Алғашқы екі байт тұрақты мән болып табылады. Барлық кейінгі блоктар мұны растады, бірақ беру блогының аяқталуына дейін:
Бұл жақтау да таң қалдырды, өйткені тұрақты өзгерген (ерекшеленген) және бір таңқаларлығы, файлдың бір бөлігі болды. Файлдың тасымалданатын байттарының өлшемі 1024 байт тасымалданғанын көрсетті. Мен қалған байттардың нені білдіретінін тағы да білмедім.
Ең алдымен, ескі BBS лақап аты ретінде мен стандартты жіберу протоколдарын қарастырдым. Ешбір протокол 1024 байтты жібермеді. Мен аппараттық құралдарды зерттей бастадым және 1K Xmodem протоколын кездестірдім. Ол 1024-ті тасымалдауға мүмкіндік берді, бірақ ескертумен: алдымен тек 128 және қателер болмаса ғана, хаттама тасымалданатын байттардың санын көбейтті. Менде бірден 1024 байтты тасымалдау болды. Мен тарату протоколдарын, атап айтқанда X-модемді зерттеуді шештім.
Модемнің екі нұсқасы болды.
Біріншіден, CRC8 қолдауы бар XMODEM пакет пішімі (түпнұсқа XMODEM):
Екіншіден, CRC16 қолдауы бар XMODEM пакет пішімі (XmodemCRC):
SOH, пакет нөмірі және CRC және пакет ұзындығын қоспағанда, ұқсас көрінеді.
Мен екінші жіберу блогының басына қарадым (және микробағдарлама файлын қайтадан көрдім, бірақ қазірдің өзінде 1024 байт шегініспен):
Мен таныс fd 3e 02 тақырыбын көрдім, бірақ келесі екі байт өзгерген: ол 01 fe болды және 02 fd болды. Содан кейін мен екінші блоктың қазір 02 нөмірленгенін байқадым және осылай түсіндім: менің алдымда трансмиссия блогының нөмірленуі тұрған. Бірінші 1024 беріліс - 01, екіншісі - 02, үшінші - 03 және т.б. (бірақ, әрине, алтыбұрышта). Бірақ fe-ден fd-ге ауысу нені білдіреді? Көздер 1-ге төмендегенін көрді, ми бағдарламашылар 0 емес, 1-ден санайтынын еске салды. Бірақ неге бірінші блок 1 емес, 0? Мен бұл сұрақтың жауабын әлі таппадым. Бірақ мен екінші блоктың қалай есептелетінін түсіндім. Екінші блок FF – (минус) бірінші блоктың нөмірінен басқа ештеңе емес. Осылайша, екінші блок = 02 (FF-02) = 02 FD ретінде белгіленді. Қоқыс туралы кейінгі оқу менің болжамымды растады.
Содан кейін трансмиссияның келесі суреті пайда бола бастады:
Трансляцияның басталуы
fd 3e 02 – Бастау
01 FE – беріліс есептегіші
Тасымалдау (34 блок, 1024 байт тасымалданды)
fd 3e 1024 байт деректер (30 байт блоктарға бөлінген).
Трансляцияның аяқталуы
fd 25
1024 байтқа теңестірілетін қалған деректер.
Блок берудің соңғы жақтауы қалай көрінеді:
fd 25 – блок беруді аяқтау үшін сигнал. Келесі 2f 52 – өлшемі 1024 байтқа дейінгі файлдың қалған бөлігі. 2f 52, хаттамаға сәйкес, 16-биттік CRC бақылау сомасы.
Ескі уақыт үшін мен C тілінде файлдан 1024 байт шығарып, 16 биттік CRC есептейтін бағдарлама жасадым. Бағдарламаны іске қосу бұл 16-биттік CRC емес екенін көрсетті. Қайтадан ступор - шамамен үш күн. Осы уақыт бойы мен бақылау сомасы болмаса, бұл не болуы мүмкін екенін түсінуге тырыстым. Ағылшын тіліндегі сайттарды зерттей отырып, мен X-модем өзінің бақылау сомасын есептейтінін білдім - CRC-CCITT (XModem). Мен бұл есептеудің ешқандай C нұсқасын таппадым, бірақ мен бұл бақылау сомасын онлайн есептеген сайтты таптым. Менің файлымның 1024 байтты веб-бетке тасымалдағаннан кейін сайт маған файлдағы бақылау сомасына толығымен сәйкес келетін бақылау сомасын көрсетті.
Ура! Соңғы жұмбақ шешілді, енді өзімнің микробағдарлама жасауым керек болды. Содан кейін мен өз білімімді (және ол менің басымда ғана қалды) күшті Python құралдар жинағымен таныс Ильяға бердім.
Бағдарлама құру
Бұл туралы Илья Алешин хабарлады.
Тиісті нұсқауларды алып, мен өте «қуанышты».
Неден бастау керек? Дұрыс, басынан бастап. USB портынан демп алудан.
USB-pcap іске қосыңыз
Құрылғы қосылған портты және біз дампты сақтайтын файлды таңдаңыз.
Сканерді Windows жүйесіне арналған EZConfigScanning бағдарламалық құралы орнатылған құрылғыға қосамыз.
Онда біз құрылғыға командаларды жіберуге арналған элементті табамыз. Бірақ командалар ше? Мен оларды қайдан аламын?
Бағдарлама іске қосылғанда, жабдық автоматты түрде сұралады (мұны сәл кейінірек көреміз). Ал ресми жабдық құжаттарынан оқу штрих-кодтары болды. ДЕФАЛТ. Бұл біздің команда.
Қажетті деректер алынды. Wireshark арқылы dump.pcap файлын ашыңыз.
EZConfigScanning іске қосу кезінде блоктау. Сізге назар аудару керек орындар қызыл түспен белгіленген.
Осының бәрін бірінші рет көріп, жүрегім елжіреп кетті. Әрі қарай қайда қазу керек екені белгісіз.
Кішкене миға шабуыл және-және-және... Аха! Қоқыста сыртында - болып табылады inмен in ол сыртында.
Мен URB_INTERRUPT деген не екенін гуглдан іздедім. Мен бұл деректерді беру әдісі екенін білдім. Және мұндай 4 әдіс бар: бақылау, үзу, изохронды, көлемді. Олар туралы бөлек оқуға болады.
Ал USB құрылғысының интерфейсіндегі соңғы нүкте мекенжайларын «lsusb –v» пәрмені арқылы немесе pyusb көмегімен алуға болады.
Енді осы VID бар барлық құрылғыларды табу керек. Арнайы VID:PID арқылы іздеуге болады.
Мынадай көрінеді:
Сонымен, бізде қажетті ақпарат бар: P_INFO командалары. немесе DEFALT, пәрмендерді жазуға болатын мекенжайлар endpoint=03 және жауаптың соңғы нүктесі=86 қайдан алынады. Пәрмендерді он алтылыққа түрлендіру ғана қалады.
Құрылғыны тауып қойғандықтан, оны ядродан ажыратайық...
...және 0x03 мекенжайымен соңғы нүктеге жазыңыз,
... содан кейін 0x86 мекенжайы бар соңғы нүктеден жауапты оқыңыз.
Құрылымдық жауап:
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Біз бұл деректерді dump.pcap файлында көреміз.
Тамаша! Жүйелік штрих-кодтарды он алтылыққа түрлендіру. Міне, жаттығу функциясы дайын.
Микробағдарлама туралы не деуге болады? Бәрі бірдей сияқты, бірақ бір нюанс бар.
Жыпылықтау процесін толығымен алып тастап, біз немен айналысып жатқанымызды түсіндік. Міне XMODEM туралы мақала, ол жалпы мағынада болса да, бұл байланыстың қалай болатынын түсінуге өте пайдалы болды: Мен оны оқуға кеңес беремін.
Демпке қарап, кадр өлшемі 1024, ал URB-деректер өлшемі 64 екенін көруге болады.
Сондықтан – 1024/64 – біз блокта 16 жол аламыз, микробағдарлама файлын бір уақытта 1 таңбадан оқып, блокты қалыптастырамыз. fd1e3 + блок нөмірі арнайы таңбалары бар блоктағы 02 жолды толықтыру.
Келесі 14 жол fd25 + қосымшасымен толықтырылған, XMODEM.calc_crc() көмегімен біз бүкіл блоктың бақылау сомасын есептейміз («FF – 1» CSUM екенін түсіну үшін көп уақыт кетті) және соңғы, 16-шы жол толықтырылды fd3e көмегімен.
Бәлкім, микробағдарлама файлын оқып, блоктарды басып, сканерді ядродан ажыратып, құрылғыға жіберіңіз. Бірақ бұл қарапайым емес. Сканерді микробағдарлама режиміне ауыстыру қажет,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
Бұл қай команда??? Қоқыстан.
Бірақ 64 шегіне байланысты сканерге толық блокты жібере алмаймыз:
NEWAPP жыпылықтау режиміндегі сканер он алтылықты қабылдамайды. Сондықтан әрбір жолды 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]Содан кейін бұл деректерді сканерге жіберіңіз.
Жауапты аламыз:
[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 туралы мақаланы тексерсеңіз, ол анық болады: деректер қабылданды.
Барлық блоктар тасымалданғаннан кейін біз тасымалдауды аяқтаймыз END_TRANSFER = 'xfdx01x04'.
Бұл блоктар қарапайым адамдар үшін ешқандай ақпаратты тасымалдамайтындықтан, біз микробағдарламаны әдепкі бойынша жасырын режимде орнатамыз. Сондай-ақ, біз tqdm арқылы прогресс жолағын ұйымдастырамыз.
Шындығында, бұл ұсақ-түйек нәрсе. Тек қана шешімді нақты белгіленген уақытта жаппай репликациялау үшін сценарийлерге орап, кассалардағы жұмыс процесін бәсеңдетпеу және тіркеуді қосу ғана қалады.
Нәтиже
Басымызға көп уақыт пен күш жұмсап, біз өзімізге қажетті шешімдерді әзірлей алдық, сонымен қатар белгіленген мерзімге жеттік. Сонымен қатар, сканерлер орталықтандырылған және қайта оқытылған, біз бүкіл процесті нақты басқарамыз. Компания уақыт пен ақшаны үнемдеді және біз осы типтегі кері инженерлік жабдықтарда баға жетпес тәжірибе алдық.
Ақпарат көзі: www.habr.com