งานสำหรับนักพัฒนา หรือวิธีที่เราแฟลชสแกนเนอร์มือถือโดยไม่มีผู้จำหน่าย

สวัสดีทุกคน

วันนี้พวกเรา Viktor Antipov และ Ilya Aleshin จะพูดถึงประสบการณ์ในการทำงานกับอุปกรณ์ USB ผ่าน Python PyUSB และวิศวกรรมย้อนกลับเล็กน้อย

ประวัติศาสตร์

ในปี 2019 พระราชกฤษฎีกาของรัฐบาลสหพันธรัฐรัสเซียหมายเลข 224“ ในการอนุมัติกฎสำหรับการติดฉลากผลิตภัณฑ์ยาสูบด้วยวิธีการระบุและคุณสมบัติของการดำเนินการตามระบบข้อมูลของรัฐสำหรับการตรวจสอบการไหลเวียนของสินค้าภายใต้การติดฉลากบังคับด้วยวิธีการระบุตัวตน เกี่ยวกับผลิตภัณฑ์ยาสูบ” มีผลบังคับใช้
เอกสารอธิบายว่าตั้งแต่วันที่ 1 กรกฎาคม 2019 ผู้ผลิตจะต้องติดฉลากยาสูบแต่ละซอง และผู้จัดจำหน่ายโดยตรงจะต้องได้รับผลิตภัณฑ์เหล่านี้พร้อมกับการดำเนินการตามเอกสารการโอนสากล (UDD) ในทางกลับกัน ร้านค้าจำเป็นต้องลงทะเบียนการขายผลิตภัณฑ์ที่มีฉลากผ่านเครื่องบันทึกเงินสด

นอกจากนี้ ตั้งแต่วันที่ 1 กรกฎาคม 2020 เป็นต้นไป ห้ามจำหน่ายผลิตภัณฑ์ยาสูบที่ไม่มีฉลาก ซึ่งหมายความว่าซองบุหรี่ทั้งหมดจะต้องมีบาร์โค้ด Datamatrix พิเศษ ยิ่งไปกว่านั้น - จุดสำคัญ - ปรากฎว่า Datamatrix จะไม่ธรรมดา แต่กลับกัน นั่นคือไม่ใช่รหัสสีดำบนพื้นสีขาว แต่ในทางกลับกัน

เราทดสอบเครื่องสแกนของเรา และปรากฏว่าส่วนใหญ่จำเป็นต้องได้รับการเปลี่ยน/ฝึกใหม่ ไม่เช่นนั้นเครื่องจะไม่สามารถทำงานตามปกติด้วยบาร์โค้ดนี้ได้ เหตุการณ์พลิกผันนี้ทำให้เราปวดหัวอย่างรุนแรง เนื่องจากบริษัทของเรามีร้านค้าจำนวนมากที่กระจัดกระจายไปทั่วพื้นที่อันกว้างใหญ่ เครื่องบันทึกเงินสดหลายหมื่นเครื่อง – และมีเวลาน้อยมาก

จะต้องทำอะไร? มีสองตัวเลือก ประการแรก: วิศวกรนอกสถานที่จะทำการแฟลชใหม่และปรับเครื่องสแกนด้วยตนเอง ประการที่สอง: เราทำงานจากระยะไกล และควรครอบคลุมเครื่องสแกนหลายเครื่องพร้อมกันในการทำซ้ำครั้งเดียว

เห็นได้ชัดว่าตัวเลือกแรกไม่เหมาะกับเรา: เราจะต้องเสียเงินไปกับวิศวกรที่ไปเยี่ยม และในกรณีนี้การควบคุมและประสานงานกระบวนการจะเป็นเรื่องยาก แต่สิ่งที่สำคัญที่สุดคือผู้คนจะทำงานได้ กล่าวคือ เราอาจได้รับข้อผิดพลาดมากมายและมีแนวโน้มว่าจะไม่ทันกำหนดเวลา

ตัวเลือกที่สองนั้นดีสำหรับทุกคน หากไม่ใช่เพื่อสิ่งหนึ่งสิ่งใด ผู้จำหน่ายบางรายไม่มีเครื่องมือการแฟลชระยะไกลที่เราต้องการสำหรับระบบปฏิบัติการที่จำเป็นทั้งหมด และเนื่องจากเส้นตายกำลังจะหมดลง ฉันจึงต้องคิดในใจของตัวเอง

ต่อไป เราจะบอกคุณว่าเราพัฒนาเครื่องมือสำหรับเครื่องสแกนมือถือสำหรับระบบปฏิบัติการ Debian 9.x ได้อย่างไร (เครื่องบันทึกเงินสดทั้งหมดของเราอยู่บน Debian)

ไขปริศนา: วิธีแฟลชสแกนเนอร์

วิกเตอร์ อันติปอฟ รายงาน

ยูทิลิตี้อย่างเป็นทางการที่จัดทำโดยผู้จำหน่ายทำงานภายใต้ Windows และเฉพาะกับ IE เท่านั้น ยูทิลิตี้นี้สามารถแฟลชและกำหนดค่าสแกนเนอร์ได้

เนื่องจากระบบเป้าหมายของเราคือ Debian เราจึงติดตั้งเซิร์ฟเวอร์ usb-redirector บน Debian และไคลเอนต์ usb-redirector บน Windows ด้วยการใช้ยูทิลิตี usb-redirector เราส่งต่อสแกนเนอร์จากเครื่อง Linux ไปยังเครื่อง Windows

ยูทิลิตี้จากผู้ขาย Windows เห็นสแกนเนอร์และยังทำการแฟลชตามปกติ ดังนั้นเราจึงได้ข้อสรุปแรก: ไม่มีอะไรขึ้นอยู่กับระบบปฏิบัติการ มันเป็นเรื่องของโปรโตคอลการกะพริบ

ตกลง. เรารันการแฟลชบนเครื่อง Windows และลบดัมพ์บนเครื่อง Linux

เรายัดไฟล์ดัมพ์ลงใน WireShark และ... รู้สึกเศร้า (ฉันจะละรายละเอียดบางส่วนของไฟล์ดัมพ์ เนื่องจากไม่สนใจเลย)

สิ่งที่กองขยะแสดงให้เราเห็น:

ที่อยู่ 0000-0030 ตัดสินโดย Wireshark เป็นข้อมูลบริการ USB

เราสนใจชิ้นส่วน 0040-0070

ไม่มีสิ่งใดที่ชัดเจนจากเฟรมการส่งสัญญาณเดียว ยกเว้นอักขระ MOCFT อักขระเหล่านี้กลายเป็นอักขระจากไฟล์เฟิร์มแวร์รวมถึงอักขระที่เหลือจนกระทั่งสิ้นสุดเฟรม (ไฟล์เฟิร์มแวร์ถูกเน้น):

สัญลักษณ์ fd 3e 02 01 fe หมายถึงอะไร โดยส่วนตัวแล้วฉันก็เหมือนกับ Ilya ที่ไม่มีความคิด

ฉันดูที่เฟรมต่อไปนี้ (ข้อมูลบริการถูกลบที่นี่ ไฟล์เฟิร์มแวร์ถูกเน้นไว้):

อะไรที่ชัดเจน? สองไบต์แรกนั้นเป็นค่าคงที่ บล็อกที่ตามมาทั้งหมดยืนยันสิ่งนี้ แต่ก่อนที่จะสิ้นสุดบล็อกการส่งสัญญาณ:

เฟรมนี้ก็น่างงเช่นกันเนื่องจากค่าคงที่มีการเปลี่ยนแปลง (ไฮไลต์) และที่น่าแปลกก็คือมีส่วนหนึ่งของไฟล์ ขนาดของไบต์ที่ถ่ายโอนของไฟล์แสดงว่ามีการถ่ายโอน 1024 ไบต์ ฉันไม่รู้อีกครั้งว่าไบต์ที่เหลือหมายถึงอะไร

ก่อนอื่นเลย ในฐานะชื่อเล่น BBS เก่า ฉันได้ตรวจสอบโปรโตคอลการส่งข้อมูลมาตรฐาน ไม่มีการส่งโปรโตคอล 1024 ไบต์ ฉันเริ่มศึกษาฮาร์ดแวร์และพบกับโปรโตคอล 1K Xmodem อนุญาตให้ส่งสัญญาณ 1024 แต่มีข้อแม้: ในตอนแรกเพียง 128 และหากไม่มีข้อผิดพลาดเท่านั้น โปรโตคอลจะเพิ่มจำนวนไบต์ที่ส่ง ฉันได้รับการถ่ายโอน 1024 ไบต์ทันที ฉันตัดสินใจศึกษาโปรโตคอลการส่งข้อมูล และโดยเฉพาะ X-modem

โมเด็มมีสองรูปแบบ

ขั้นแรก รูปแบบแพ็คเกจ 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 ไบต์)
สิ้นสุดการส่งสัญญาณ
เอฟดี 25

ข้อมูลที่เหลือจะถูกจัดแนวเป็น 1024 ไบต์

เฟรมสิ้นสุดการส่งบล็อกมีลักษณะอย่างไร:

fd 25 – สัญญาณเพื่อยุติการส่งสัญญาณบล็อก ถัดไป 2f 52 - ส่วนที่เหลือของไฟล์มีขนาดสูงสุด 1024 ไบต์ 2f 52 ซึ่งตัดสินโดยโปรโตคอล คือการตรวจสอบ CRC แบบ 16 บิต

เพื่อประโยชน์ในสมัยก่อน ฉันสร้างโปรแกรมในภาษา C โดยดึงข้อมูลขนาด 1024 ไบต์จากไฟล์และคำนวณ CRC แบบ 16 บิต การเปิดตัวโปรแกรมแสดงให้เห็นว่านี่ไม่ใช่ CRC 16 บิต อาการมึนงงอีกครั้ง - ประมาณสามวัน ตลอดเวลานี้ ฉันพยายามทำความเข้าใจว่ามันจะเป็นอะไร ถ้าไม่ใช่เช็คซัม ขณะศึกษาไซต์ภาษาอังกฤษ ฉันค้นพบว่า X-modem ใช้การคำนวณผลรวมของตัวเอง - CRC-CCITT (XModem) ฉันไม่พบการใช้งาน C ใด ๆ ในการคำนวณนี้ แต่ฉันพบไซต์ที่คำนวณผลรวมตรวจสอบนี้ทางออนไลน์ หลังจากโอนไฟล์ของฉัน 1024 ไบต์ไปยังหน้าเว็บแล้ว ไซต์ก็แสดงเช็คซัมที่ตรงกับเช็คซัมจากไฟล์โดยสมบูรณ์

ไชโย! ปริศนาสุดท้ายได้รับการแก้ไขแล้ว ตอนนี้ฉันต้องสร้างเฟิร์มแวร์ของตัวเอง ต่อไป ฉันถ่ายทอดความรู้ของฉัน (และยังคงอยู่ในหัวของฉันเท่านั้น) ให้กับ Ilya ซึ่งคุ้นเคยกับชุดเครื่องมือ Python อันทรงพลัง

การสร้างโปรแกรม

อิลยา อเลชิน รายงาน

เมื่อได้รับคำแนะนำที่เหมาะสมแล้ว ฉันก็ "มีความสุขมาก"

จะเริ่มต้นที่ไหน? ถูกต้องตั้งแต่ต้น  จากการรับดัมพ์จากพอร์ต USB

เปิดตัว USB-pcap https://desowin.org/usbpcap/tour.html

เลือกพอร์ตที่อุปกรณ์เชื่อมต่ออยู่และไฟล์ที่เราจะบันทึกดัมพ์

เราเชื่อมต่อเครื่องสแกนเข้ากับเครื่องที่ติดตั้งซอฟต์แวร์ EZConfigScanning สำหรับ Windows ไว้

ในนั้นเราจะพบรายการสำหรับส่งคำสั่งไปยังอุปกรณ์ แต่แล้วทีมล่ะ? ฉันจะหาพวกมันได้ที่ไหน?
เมื่อโปรแกรมเริ่มทำงาน อุปกรณ์จะถูกโพลโดยอัตโนมัติ (เราจะเห็นสิ่งนี้ในภายหลัง) และมีการฝึกอบรมบาร์โค้ดจากเอกสารอุปกรณ์ราชการ ค่าเริ่มต้น นี่คือทีมของเรา

ได้รับข้อมูลที่จำเป็นแล้ว เปิด dump.pcap ผ่าน wireshark

บล็อกเมื่อเริ่ม EZConfigScanning สถานที่ที่คุณต้องใส่ใจจะถูกทำเครื่องหมายด้วยสีแดง

เมื่อเห็นทั้งหมดนี้เป็นครั้งแรกฉันก็ใจหาย ยังไม่ชัดเจนว่าจะขุดที่ไหนต่อไป

ระดมความคิดนิดหน่อย แล้วก็... อ๋อ! ในกองขยะ ออก - เป็น inและ in มัน ออก.

ฉันค้นหาว่า URB_INTERRUPT คืออะไร ฉันพบว่านี่เป็นวิธีการถ่ายโอนข้อมูล และมี 4 วิธีดังกล่าว: การควบคุม, การขัดจังหวะ, แบบไอโซโครนัส, จำนวนมาก คุณสามารถอ่านเกี่ยวกับพวกเขาแยกกันได้

และที่อยู่ปลายทางในอินเทอร์เฟซอุปกรณ์ USB สามารถรับได้ผ่านคำสั่ง "lsusb –v" หรือใช้ pyusb

ตอนนี้เราต้องค้นหาอุปกรณ์ทั้งหมดที่มี VID นี้ คุณสามารถค้นหาโดยเฉพาะด้วย VID:PID

ดูเหมือนว่านี้:

ดังนั้นเราจึงมีข้อมูลที่จำเป็น: คำสั่ง P_INFO หรือ DEFALT ระบุตำแหน่งที่จะเขียนคำสั่ง endpoint=03 และตำแหน่งที่จะได้รับการตอบสนอง endpoint=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

ที่จริงแล้วมันเป็นเรื่องของสิ่งเล็กน้อย สิ่งที่เหลืออยู่คือการรวมโซลูชันไว้ในสคริปต์เพื่อการจำลองแบบจำนวนมากในเวลาที่กำหนดไว้อย่างชัดเจน เพื่อไม่ให้กระบวนการทำงานที่จุดชำระเงินช้าลง และเพิ่มการบันทึก

ทั้งหมด

หลังจากที่ใช้เวลา ความพยายาม และการดูแลเส้นผมไปมาก เราก็สามารถพัฒนาโซลูชันที่เราต้องการได้ และยังบรรลุตามกำหนดเวลาอีกด้วย ในขณะเดียวกัน เครื่องสแกนก็ได้รับการปรับโฉมใหม่และฝึกอบรมจากส่วนกลาง ซึ่งทำให้เราควบคุมกระบวนการทั้งหมดได้อย่างชัดเจน บริษัทประหยัดเวลาและเงิน และเราได้รับประสบการณ์อันล้ำค่าในด้านวิศวกรรมย้อนกลับประเภทนี้

ที่มา: will.com