დავალება დეველოპერისთვის, ან როგორ გავანათეთ ხელის სკანერები გამყიდველის გარეშე

გაუმარჯოს ყველას.

ჩვენ, ვიქტორ ანტიპოვი და ილია ალეშინი, დღეს ვისაუბრებთ Python PyUSB-ის მეშვეობით USB მოწყობილობებთან მუშაობის გამოცდილებაზე და ცოტას საპირისპირო ინჟინერიაზე.

წინაისტორია

2019 წელს რუსეთის ფედერაციის მთავრობის ბრძანებულება No224 „თამბაქოს ნაწარმის ეტიკეტირების წესების დამტკიცების შესახებ იდენტიფიკაციის საშუალებებით და საიდენტიფიკაციო საშუალებებით სავალდებულო ეტიკეტირებას დაქვემდებარებული საქონლის მიმოქცევის მონიტორინგის სახელმწიფო საინფორმაციო სისტემის დანერგვის მახასიათებლების შესახებ. თამბაქოს ნაწარმთან დაკავშირებით“ ძალაში შევიდა.
დოკუმენტში განმარტებულია, რომ 1 წლის 2019 ივლისიდან მწარმოებლებს მოეთხოვებათ თამბაქოს თითოეულ შეკვრაზე ეტიკეტირება. ხოლო უშუალო დისტრიბუტორებმა უნდა მიიღონ ეს პროდუქტები უნივერსალური გადაცემის დოკუმენტის (UDD) შესრულებით. მაღაზიებს, თავის მხრივ, სჭირდებათ ეტიკეტირებული პროდუქციის რეალიზაციის რეგისტრაცია სალარო აპარატის საშუალებით.

ასევე, 1 წლის 2020 ივლისიდან აკრძალულია თამბაქოს არაეტიკეტირებული ნაწარმის ბრუნვა. ეს ნიშნავს, რომ სიგარეტის ყველა კოლოფი უნდა იყოს მონიშნული სპეციალური Datamatrix შტრიხკოდით. უფრო მეტიც - მნიშვნელოვანი მომენტი - აღმოჩნდა, რომ Datamatrix არ იქნება ჩვეულებრივი, არამედ ინვერსიული. ანუ არა შავი კოდი თეთრზე, არამედ პირიქით.

ჩვენ გამოვცადეთ ჩვენი სკანერები და აღმოჩნდა, რომ მათ უმეტესობას გადამზადება/გადამზადება სჭირდება, წინააღმდეგ შემთხვევაში ისინი უბრალოდ ვერ ახერხებენ ნორმალურად მუშაობას ამ შტრიხკოდით. მოვლენების ამგვარმა განვითარებამ ძლიერი თავის ტკივილი მოგვცა, რადგან ჩვენს კომპანიას აქვს უამრავი მაღაზია, რომლებიც მიმოფანტულია უზარმაზარ ტერიტორიაზე. რამდენიმე ათეული ათასი სალარო აპარატი - და ძალიან ცოტა დრო.

რა იყო გასაკეთებელი? ორი ვარიანტია. პირველი: ადგილზე ინჟინრები ხელით ანახლებს და არეგულირებენ სკანერებს. მეორე: ჩვენ ვმუშაობთ დისტანციურად და, სასურველია, ვფარავთ ბევრ სკანერს ერთდროულად ერთ გამეორებაში.

პირველი ვარიანტი, ცხადია, არ შეგვეფერებოდა: ინჟინრების სტუმრად ფულის დახარჯვა მოგვიწევდა და ამ შემთხვევაში პროცესის კონტროლი და კოორდინაცია გაგვიჭირდება. მაგრამ ყველაზე მნიშვნელოვანი ის არის, რომ ხალხი იმუშავებდა, ანუ ჩვენ პოტენციურად მივიღებდით უამრავ შეცდომას და, დიდი ალბათობით, ვერ შევასრულებდით ვადას.

მეორე ვარიანტი ყველასთვის კარგია, თუ არა ერთი რამისთვის. ზოგიერთ მომწოდებელს არ გააჩნდა დისტანციური მოციმციმე ხელსაწყოები, რომლებიც გვჭირდებოდა ყველა საჭირო ოპერაციული სისტემისთვის. და რადგან ვადები იწურებოდა, ჩემი თავით მომიწია ფიქრი.

შემდეგი, ჩვენ გეტყვით, თუ როგორ შევიმუშავეთ ხელსაწყოები ხელის სკანერებისთვის Debian 9.x OS-ისთვის (ჩვენი ყველა სალარო აპარატი Debian-ზეა).

ამოხსენით თავსატეხი: როგორ გავანათოთ სკანერი

იუწყება ვიქტორ ანტიპოვი.

გამყიდველის მიერ მოწოდებული ოფიციალური პროგრამა მუშაობს Windows-ის ქვეშ და მხოლოდ IE-ით. პროგრამას შეუძლია ციმციმი და სკანერის კონფიგურაცია.

ვინაიდან ჩვენი სამიზნე სისტემა არის Debian, ჩვენ დავაყენეთ USB-გადამისამართების სერვერი Debian-ზე და usb-redirector კლიენტი Windows-ზე. usb-redirector-ის კომუნალური საშუალებების გამოყენებით, ჩვენ გადავიტანეთ სკანერი Linux-ის აპარატიდან Windows-ის აპარატში.

Windows-ის გამყიდველის პროგრამამ დაინახა სკანერი და ნორმალურადაც კი გაანათა. ამრიგად, ჩვენ გავაკეთეთ პირველი დასკვნა: არაფერია დამოკიდებული OS-ზე, ეს არის ციმციმის პროტოკოლის საკითხი.

ᲙᲐᲠᲒᲘ. ჩვენ გავუშვით ციმციმა Windows-ის აპარატზე და ამოიღეთ ნაგავსაყრელი Linux-ის აპარატზე.

ჩვენ ჩავყარეთ ნაგავსაყრელი WireShark-ში და... დავიწყინეთ (ნაგავსაყრელის ზოგიერთ დეტალს გამოვტოვებ, ისინი არანაირ ინტერესს არ წარმოადგენენ).

რა გვაჩვენა ნაგავსაყრელმა:

მისამართები 0000-0030, ვიმსჯელებთ Wireshark-ის მიხედვით, არის USB სერვისის ინფორმაცია.

დავინტერესდით 0040-0070 ნაწილით.

არაფერი იყო ნათელი ერთი გადაცემის ჩარჩოდან, გარდა MOCFT სიმბოლოებისა. ეს სიმბოლოები აღმოჩნდა სიმბოლოები firmware ფაილიდან, ისევე როგორც დარჩენილი სიმბოლოები ჩარჩოს ბოლომდე (მონიშნულია firmware ფაილი):

რას ნიშნავდა სიმბოლოები fd 3e 02 01 fe, მე პირადად, ისევე როგორც ილია, წარმოდგენა არ მქონდა.

მე გადავხედე შემდეგ ჩარჩოს (მომსახურების ინფორმაცია წაშლილია აქ, ხაზგასმულია firmware ფაილი):

რა გახდა ნათელი? რომ პირველი ორი ბაიტი არის ერთგვარი მუდმივი. ყველა მომდევნო ბლოკმა დაადასტურა ეს, მაგრამ გადაცემის ბლოკის დასრულებამდე:

ეს ჩარჩო ასევე გამაოგნებელი იყო, რადგან მუდმივი შეიცვალა (ხაზგასმულია) და, უცნაურად საკმარისი იყო, იყო ფაილის ნაწილი. ფაილის გადატანილი ბაიტის ზომამ აჩვენა, რომ გადატანილი იყო 1024 ბაიტი. ისევ არ ვიცოდი რას ნიშნავდა დარჩენილი ბაიტები.

უპირველეს ყოვლისა, როგორც ძველი BBS მეტსახელი, გადავხედე გადაცემის სტანდარტულ პროტოკოლებს. არცერთი პროტოკოლი არ არის გადაცემული 1024 ბაიტი. დავიწყე ტექნიკის შესწავლა და წავაწყდი 1K Xmodem პროტოკოლს. ეს საშუალებას აძლევდა 1024-ის გადაცემას, მაგრამ სიფრთხილით: თავდაპირველად მხოლოდ 128 და მხოლოდ იმ შემთხვევაში, თუ შეცდომები არ იყო, პროტოკოლმა გაზარდა გადაცემული ბაიტების რაოდენობა. მაშინვე მქონდა 1024 ბაიტის გადაცემა. გადავწყვიტე შემესწავლა გადაცემის პროტოკოლები და კონკრეტულად X-მოდემი.

მოდემის ორი ვარიაცია იყო.

პირველი, XMODEM პაკეტის ფორმატი CRC8 მხარდაჭერით (ორიგინალური XMODEM):

მეორეც, XMODEM პაკეტის ფორმატი CRC16 მხარდაჭერით (XmodemCRC):

ეს გამოიყურება მსგავსი, გარდა SOH, პაკეტის ნომერი და CRC და პაკეტის სიგრძე.

მე გადავხედე მეორე გადაცემის ბლოკის დასაწყისში (და ისევ ვნახე firmware ფაილი, მაგრამ უკვე ჩაღრმავებული 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 პროგრამული უზრუნველყოფა.

მასში ვპოულობთ მოწყობილობას ბრძანებების გაგზავნის ნივთს. მაგრამ რაც შეეხება გუნდებს? სად შემიძლია მათი მიღება?
როდესაც პროგრამა იწყება, აღჭურვილობა ავტომატურად იკითხება (ამას ცოტა მოგვიანებით ვნახავთ). და იყო სასწავლო შტრიხკოდები ოფიციალური აღჭურვილობის დოკუმენტებიდან. DEFALT. ეს ჩვენი გუნდია.

მიღებულია საჭირო მონაცემები. გახსენით 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-ში.

დიდი! გადაიყვანეთ სისტემის შტრიხკოდები ექვსკუთხედად. ეს არის ის, სასწავლო ფუნქციონირება მზად არის.

რაც შეეხება firmware-ს? როგორც ჩანს, ყველაფერი იგივეა, მაგრამ არის ნიუანსი.

ციმციმის პროცესის სრული ნაგავსაყრელის შემდეგ, ჩვენ უხეშად მივხვდით, რასთან გვქონდა საქმე. აქ არის სტატია XMODEM-ის შესახებ, რომელიც ძალიან დამეხმარა იმის გაგებაში, თუ როგორ ხდება ეს კომუნიკაცია, თუმცა ზოგადი თვალსაზრისით: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html გირჩევთ წაიკითხოთ.

ნაგავსაყრელის დათვალიერებისას ხედავთ, რომ ჩარჩოს ზომაა 1024, ხოლო URB-მონაცემების ზომა არის 64.

ამიტომ – 1024 წ/64 – ვიღებთ 16 ხაზს ბლოკში, ვკითხულობთ firmware ფაილს 1 სიმბოლოს ერთდროულად და ვქმნით ბლოკს. ბლოკში 1 ხაზის შევსება სპეციალური სიმბოლოებით fd3e02 + ბლოკის ნომერი.
შემდეგი 14 სტრიქონი დამატებულია fd25 +-ით, XMODEM.calc_crc()-ის გამოყენებით ვიანგარიშებთ მთელი ბლოკის საკონტროლო ჯამს (დიდი დრო დასჭირდა იმის გაგებას, რომ „FF – 1“ არის CSUM) და დამატებულია ბოლო, მე-16 ხაზი. fd3e-ით.

როგორც ჩანს, ეს ასეა, წაიკითხეთ firmware ფაილი, დააჭირეთ ბლოკებს, გამორთეთ სკანერი ბირთვიდან და გაგზავნეთ მოწყობილობაში. მაგრამ ეს არც ისე მარტივია. სკანერი უნდა გადავიდეს firmware რეჟიმში,
отправив ему 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'.

კარგად, რადგან ეს ბლოკები არ შეიცავს ინფორმაციას ჩვეულებრივი ადამიანებისთვის, ჩვენ დავაყენებთ firmware-ს დამალულ რეჟიმში ნაგულისხმევად. და ყოველ შემთხვევაში, ჩვენ მოვაწყობთ პროგრესის ზოლს tqdm-ის საშუალებით.

სინამდვილეში, მაშინ ეს წვრილმანებზეა. რჩება მხოლოდ ხსნარის გადატანა სკრიპტებში მასობრივი რეპლიკაციისთვის მკაფიოდ განსაზღვრულ დროში, რათა არ შეანელოს სალაროებში მუშაობის პროცესი და დაამატოთ ლოგინი.

სულ

დიდი დრო და ძალისხმევა და თავზე თმების დახარჯვის შემდეგ ჩვენ შევძელით საჭირო გადაწყვეტილებების შემუშავება და ასევე დავასრულეთ ვადა. ამავდროულად, სკანერები ახლა განახლებულია და გადამზადებულია ცენტრალურად, ჩვენ აშკარად ვაკონტროლებთ მთელ პროცესს. კომპანიამ დაზოგა დრო და ფული და ჩვენ შევიძინეთ ფასდაუდებელი გამოცდილება ამ ტიპის უკუ საინჟინრო აღჭურვილობაში.

წყარო: www.habr.com