Баарына салам.
Биз, Виктор Антипов жана Илья Алешин, бүгүн Python PyUSB аркылуу USB түзүлүштөрү менен иштөө тажрыйбабыз жана тескери инженерия жөнүндө бир аз сүйлөшөбүз.
prehistory
2019-жылы Россия Федерациясынын Өкмөтүнүн № 224 “Тамеки буюмдарын идентификациялоо каражаттары менен маркировкалоо эрежелерин жана идентификациялык каражаттар менен милдеттүү маркировкаланууга тийиш болгон товарларды жүгүртүүгө мониторинг жүргүзүүнүн мамлекеттик маалыматтык системасын ишке ашыруунун өзгөчөлүктөрүн бекитүү жөнүндө” токтому тамеки буюмдарына карата» мыйзамы күчүнө кирди.
Документте 1-жылдын 2019-июлунан тартып өндүрүүчүлөр тамекинин ар бир кутусуна маркировкалоого милдеттүү экени түшүндүрүлөт. Ал эми тике дистрибьюторлор бул продукцияны универсалдуу өткөрүп берүү документин (UDD) аткаруу менен алышы керек. Дүкөндөр өз кезегинде маркировкаланган продукцияны касса аркылуу сатууну каттоого алышы керек.
Ошондой эле, 1-жылдын 2020-июлунан тартып маркировкаланбаган тамеки буюмдарын жүгүртүүгө тыюу салынат. Бул бардык тамеки кутулары атайын Datamatrix штрих-коду менен белгилениши керек дегенди билдирет. Андан тышкары - маанилүү жагдай - бул Datamatrix катардагы эмес, тескерисинче болот экен. Башкача айтканда, ак түстөгү кара код эмес, тескерисинче.
Биз сканерлерибизди сынап көрдүк жана алардын көбүн жаңыртуу/кайра даярдоо керек экени белгилүү болду, антпесе алар бул штрих-код менен кадимкидей иштей алышпайт. Окуялардын мындай бурулушу бизге катуу баш ооруну кепилдейт, анткени биздин компаниянын көптөгөн дүкөндөрү бар. Бир нече он миңдеген кассалык аппараттар – жана өтө аз убакыт.
Эмне кылуу керек эле? Эки вариант бар. Биринчиден: сайттын инженерлери сканерлерди кол менен жаңыртышат жана тууралашат. Экинчиси: биз алыстан иштейбиз жана жакшыраак, бир итерацияда бир эле учурда көптөгөн сканерлерди камтыйбыз.
Биринчи вариант, албетте, биз үчүн ылайыктуу эмес: инженерлерге барууга акча коротууга туура келет жана бул учурда процессти контролдоо жана координациялоо кыйын болмок. Бирок эң негизгиси, адамдар иштешмек, башкача айтканда, биз көп ката кетиришибиз мүмкүн жана, кыязы, белгиленген мөөнөткө жетпей калмакпыз.
Экинчи параметр бир нерсе үчүн эмес, баары үчүн жакшы. Кээ бир сатуучулар бардык талап кылынган операциялык тутумдар үчүн керектүү алыстан жаркылдоочу куралдарга ээ эмес болчу. Ал эми мөөнөттөр бүтүп бараткандыктан, мен өз башым менен ойлонууга туура келди.
Андан кийин, биз Debian 9.x OS үчүн кол сканерлери үчүн куралдарды кантип иштеп чыкканыбызды айтып беребиз (биздин бардык кассаларыбыз 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-пкапты ишке киргизиңиз
Түзмөк туташтырылган портту жана биз таштанды сактай турган файлды тандаңыз.
Биз сканерди Windows үчүн жергиликтүү EZConfigScanning программасы орнотулган машинага туташтырабыз.
Анда биз аппаратка буйруктарды жөнөтүү пунктун табабыз. Бирок командалар жөнүндө эмне айтууга болот? Аларды кайдан алсам болот?
Программа башталганда, жабдуулар автоматтык түрдө суралат (биз муну бир аз кийинчерээк көрөбүз). Ал эми официалдуу жабдуулардын документтеринен окуу штрих-коддору бар болчу. DEFALT. Бул биздин команда.
Керектүү маалыматтар алынды. 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 аркылуу прогресс тилкесин уюштурабыз.
Чынында, анда бул кичинекей нерсе. Болгону, кассаларда иштөө процессин жайлатпоо үчүн, так аныкталган убакытта чечимди скрипттерге жапырт репликациялоо үчүн ороп, журналдарды кошуу гана калды.
жыйынтык
Көптөгөн убакытты, күч-аракетти жана башыбызга чачты коротуп, биз керектүү чечимдерди иштеп чыга алдык, ошондой эле белгиленген мөөнөткө жеттик. Ошол эле учурда, сканерлер азыр кайра жандырылды жана борборлоштурулуп кайра даярдалды, биз бүт процессти так көзөмөлдөйбүз. Компания убакытты жана акчаны үнөмдөп, биз бул типтеги тескери инженердик жабдууларда баа жеткис тажрыйбага ээ болдук.
Source: www.habr.com