Առաջադրանք ծրագրավորողի համար, կամ թե ինչպես ենք ձեռքի սկաներները առանց վաճառողի լուսարձակում

Բարեւ բոլորին

Մենք՝ Վիկտոր Անտիպովը և Իլյա Ալեշինը, այսօր կխոսենք Python PyUSB-ի միջոցով USB սարքերի հետ աշխատելու մեր փորձի և մի փոքր հակադարձ ճարտարագիտության մասին:

նախապատմությանը

2019 թվականին Ռուսաստանի Դաշնության Կառավարության N 224 որոշումը «Նույնականացման միջոցներով ծխախոտի արտադրանքի մակնշման կանոնները հաստատելու մասին և նույնականացման միջոցներով պարտադիր պիտակավորման ենթակա ապրանքների շրջանառության մոնիտորինգի պետական ​​տեղեկատվական համակարգի ներդրման առանձնահատկությունները հաստատելու մասին». ծխախոտի արտադրանքի հետ կապված» ուժի մեջ է մտել։
Փաստաթղթում բացատրվում է, որ 1 թվականի հուլիսի 2019-ից արտադրողները պարտավոր են պիտակավորել ծխախոտի յուրաքանչյուր տուփ։ Իսկ ուղղակի դիստրիբյուտորները պետք է ստանան այդ ապրանքները համընդհանուր փոխանցման փաստաթղթի (UDD) կատարմամբ: Խանութներն իրենց հերթին պետք է ՀԴՄ-ի միջոցով գրանցեն մակնշված ապրանքների վաճառքը։

Նաև 1 թվականի հուլիսի 2020-ից արգելվում է առանց մակնշման ծխախոտի արտադրանքի շրջանառությունը։ Սա նշանակում է, որ ծխախոտի բոլոր տուփերը պետք է նշվեն հատուկ Datamatrix շտրիխ կոդով: Ավելին, մի կարևոր կետ, պարզվեց, որ Datamatrix-ը սովորական չէ, այլ հակադարձ: Այսինքն՝ ոչ թե սև կոդ սպիտակի վրա, այլ հակառակը։

Մենք փորձարկեցինք մեր սկաներները, և պարզվեց, որ դրանցից շատերը կարիք ունեն վերապատրաստման/վերապատրաստման, այլապես նրանք պարզապես չեն կարողանում նորմալ աշխատել այս շտրիխ կոդով։ Իրադարձությունների այս շրջադարձը մեզ ապահովեց ուժեղ գլխացավանք, քանի որ մեր ընկերությունն ունի բազմաթիվ խանութներ, որոնք ցրված են հսկայական տարածքում: Մի քանի տասնյակ հազար դրամարկղեր, և շատ քիչ ժամանակ:

Ի՞նչ էր պետք անել։ Երկու տարբերակ կա. Առաջին. տեղում ինժեներները ձեռքով թարմացնում և կարգավորում են սկաներները: Երկրորդ. մենք աշխատում ենք հեռակա կարգով և, նախընտրելի է, ծածկում ենք բազմաթիվ սկաներներ միանգամից մեկ կրկնությամբ:

Առաջին տարբերակը, ակնհայտորեն, մեզ հարմար չէր՝ մենք պետք է գումար ծախսեինք ինժեներների այցելության վրա, և այս դեպքում դժվար կլիներ վերահսկել և համակարգել գործընթացը։ Բայց ամենակարևորն այն է, որ մարդիկ աշխատեին, այսինքն՝ մենք պոտենցիալ բազմաթիվ սխալներ կստանայինք և, ամենայն հավանականությամբ, ժամկետը չէինք պահպանելու։

Երկրորդ տարբերակը լավ է բոլորի համար, եթե ոչ մի բանի համար. Որոշ վաճառողներ չունեին բոլոր անհրաժեշտ օպերացիոն համակարգերի համար անհրաժեշտ հեռակառավարվող թարթման գործիքները: Եվ քանի որ ժամկետները սպառվում էին, ես պետք է մտածեի իմ գլխով։

Հաջորդիվ, մենք ձեզ կպատմենք, թե ինչպես ենք մշակել գործիքներ Debian 9.x ՕՀ-ի համար ձեռքի սկաներների համար (մեր բոլոր դրամարկղերը գտնվում են Debian-ում):

Լուծեք հանելուկը. ինչպես բռնկել սկաները

հայտնում է Վիկտոր Անտիպովը։

Վաճառողի կողմից տրամադրված պաշտոնական կոմունալ ծրագիրը աշխատում է Windows-ի ներքո և միայն IE-ով: Կոմունալ ծրագիրը կարող է թարթել և կարգավորել սկաները:

Քանի որ մեր թիրախային համակարգը Debian-ն է, մենք տեղադրեցինք USB-վերահղման սերվերը Debian-ում և usb-redirector-հաճախորդ Windows-ում: Օգտագործելով usb-redirector կոմունալ ծառայություններ, մենք սկաները փոխանցեցինք Linux սարքից Windows ապարատ:

Windows-ի վաճառողի կոմունալ ծրագիրը տեսավ սկաները և նույնիսկ այն նորմալ թարթեց: Այսպիսով, մենք արեցինք առաջին եզրակացությունը. ոչինչ կախված չէ ՕՀ-ից, դա թարթող արձանագրության խնդիր է:

ԼԱՎ. Մենք գործարկեցինք թարթումը Windows մեքենայի վրա և հեռացրինք Linux սարքի աղբարկղը:

Մենք աղբավայրը լցրեցինք WireShark-ի մեջ և... տխրեցինք (ես բաց կթողնեմ աղբավայրի որոշ մանրամասներ, դրանք որևէ հետաքրքրություն չեն ներկայացնում):

Ինչ ցույց տվեց մեզ աղբավայրը.

0000-0030 հասցեները, դատելով Wireshark-ից, USB ծառայության տեղեկատվություն են:

Մեզ հետաքրքրեց 0040-0070 մաս.

Ոչինչ պարզ չէր փոխանցման մեկ շրջանակից, բացի MOCFT նիշերից: Պարզվեց, որ այս նիշերը նիշեր են որոնվածի ֆայլից, ինչպես նաև մնացած նիշերը մինչև կադրի ավարտը (որոնվածի ֆայլը ընդգծված է).

Թե ինչ էին նշանակում fd 3e 02 01 fe սիմվոլները, ես անձամբ, ինչպես Իլյա, գաղափար չունեի։

Ես նայեցի հետևյալ շրջանակին (ծառայության տեղեկատվությունը հանվել է այստեղ, որոնվածի ֆայլը ընդգծված է).

Ի՞նչ պարզ դարձավ. Որ առաջին երկու բայթերը ինչ-որ հաստատուն են: Բոլոր հետագա բլոկները հաստատեցին դա, բայց մինչև փոխանցման բլոկի ավարտը.

Այս շրջանակը նույնպես ապշեցուցիչ էր, քանի որ հաստատունը փոխվել էր (ընդգծվել էր) և, տարօրինակ կերպով, ֆայլի մի մասն էլ կար: Ֆայլի փոխանցված բայթերի չափը ցույց է տվել, որ փոխանցվել է 1024 բայթ։ Ես նորից չգիտեի, թե ինչ են նշանակում մնացած բայթերը:

Նախ, որպես հին BBS մականուն, ես վերանայեցի փոխանցման ստանդարտ արձանագրությունները: Ոչ մի արձանագրություն չի փոխանցվել 1024 բայթ: Ես սկսեցի ուսումնասիրել սարքավորումները և հանդիպեցի 1K Xmodem արձանագրությանը: Այն թույլ էր տալիս փոխանցել 1024, բայց նախազգուշացումով. սկզբում ընդամենը 128, և միայն եթե սխալներ չլինեին, արձանագրությունն ավելացրեց փոխանցվող բայթերի քանակը: Ես անմիջապես ունեի 1024 բայթ փոխանցում: Ես որոշեցի ուսումնասիրել փոխանցման արձանագրությունները, և մասնավորապես X-մոդեմը:

Մոդեմի երկու տարբերակ կար.

Նախ, XMODEM փաթեթի ձևաչափը CRC8 աջակցությամբ (բնօրինակ XMODEM).

Երկրորդ, XMODEM փաթեթի ձևաչափը CRC16 աջակցությամբ (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-ը https://desowin.org/usbpcap/tour.html

Ընտրեք այն նավահանգիստը, որին միացված է սարքը և այն ֆայլը, որտեղ մենք կպահենք աղբավայրը:

Մենք սկաները միացնում ենք մեքենային, որտեղ տեղադրված է Windows-ի համար նախատեսված EZConfigScanning ծրագիրը:

Դրանում մենք գտնում ենք սարքին հրամաններ ուղարկելու նյութը։ Բայց ինչ վերաբերում է թիմերին: Որտեղ կարող եմ դրանք ձեռք բերել:
Երբ ծրագիրը սկսվում է, սարքավորումները ավտոմատ կերպով հարցման են ենթարկվում (մենք դա կտեսնենք մի փոքր ուշ): Իսկ պաշտոնական սարքավորումների փաստաթղթերից կային ուսումնական շտրիխ կոդեր։ ՄԵԿՆԱԲԵՐՈՒՄ. Սա մեր թիմն է։

Ստացվել են անհրաժեշտ տվյալները։ Բացեք dump.pcap-ը wireshark-ի միջոցով:

Արգելափակել 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-ի մասին, որը շատ օգտակար էր հասկանալու համար, թե ինչպես է այս հաղորդակցությունը տեղի ունենում, թեև ընդհանուր առումներով. http://microsin.net/adminstuff/others/xmodem-protocol-overview.html Խորհուրդ եմ տալիս կարդալ այն։

Նայելով աղբավայրին, դուք կարող եք տեսնել, որ շրջանակի չափը 1024 է, իսկ URB տվյալների չափը 64 է:

Ուստի – 1024 թ/64 – մենք ստանում ենք 16 տող բլոկում, կարդում ենք որոնվածի ֆայլը 1 նիշով և ձևավորում բլոկ: Բլոկի մեջ 1 տող լրացվում է հատուկ նիշերով fd3e02 + բլոկի համարով:
Հաջորդ 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