ວຽກງານສໍາລັບນັກພັດທະນາ, ຫຼືວິທີທີ່ພວກເຮົາ flashed ເຄື່ອງສະແກນມືໂດຍບໍ່ມີຜູ້ຂາຍ

ສະບາຍດີທຸກໆທ່ານ.

ພວກເຮົາ, Viktor Antipov ແລະ Ilya Aleshin, ມື້ນີ້ຈະເວົ້າກ່ຽວກັບປະສົບການຂອງພວກເຮົາທີ່ເຮັດວຽກກັບອຸປະກອນ USB ຜ່ານ Python PyUSB ແລະເລັກນ້ອຍກ່ຽວກັບວິສະວະກໍາຍ້ອນກັບ.

ປະວັດສາດ

ໃນປີ 2019, ດຳລັດຂອງລັດຖະບານຂອງສະຫະພັນລັດເຊຍ ສະບັບເລກທີ 224 “ວ່າດ້ວຍການອະນຸມັດກົດລະບຽບການຕິດສະຫຼາກຜະລິດຕະພັນຢາສູບດ້ວຍວິທີການລະບຸຕົວຕົນ ແລະ ຄຸນສົມບັດຂອງການປະຕິບັດລະບົບຂໍ້ມູນຂ່າວສານຂອງລັດໃນການຕິດຕາມການໄຫຼວຽນຂອງສິນຄ້າທີ່ຕ້ອງຕິດສະຫຼາກດ້ວຍວິທີການກໍານົດຕົວຕົນ. ກ່ຽວ​ກັບ​ການ​ຜະ​ລິດ​ຕະ​ພັນ​ຢາ​ສູບ” ໄດ້​ມີ​ຜົນ​ບັງ​ຄັບ​ໃຊ້.
ເອກະສານດັ່ງກ່າວອະທິບາຍວ່າ ນັບແຕ່ວັນທີ 1 ກໍລະກົດ 2019 ເປັນຕົ້ນໄປ, ຜູ້ຜະລິດຈະຕ້ອງຕິດປ້າຍໃສ່ຢາສູບແຕ່ລະຊອງ. ແລະຜູ້ຈັດຈໍາຫນ່າຍໂດຍກົງຕ້ອງໄດ້ຮັບຜະລິດຕະພັນເຫຼົ່ານີ້ດ້ວຍການປະຕິບັດເອກະສານການໂອນເງິນທົ່ວໄປ (UDD). ຮ້ານຄ້າ, ໃນທາງກັບກັນ, ຈໍາເປັນຕ້ອງລົງທະບຽນການຂາຍຜະລິດຕະພັນທີ່ມີປ້າຍຊື່ຜ່ານບັນຊີເງິນສົດ.

ນອກຈາກນີ້, ນັບແຕ່ວັນທີ 1 ກໍລະກົດ 2020 ເປັນຕົ້ນໄປ, ຫ້າມຈຳໜ່າຍຜະລິດຕະພັນຢາສູບທີ່ບໍ່ມີປ້າຍຊື່. ນີ້ຫມາຍຄວາມວ່າຖົງຢາສູບທັງຫມົດຕ້ອງໄດ້ຮັບການຫມາຍດ້ວຍບາໂຄດ Datamatrix ພິເສດ. ຍິ່ງໄປກວ່ານັ້ນ - ຈຸດສໍາຄັນ - ມັນໄດ້ຫັນອອກວ່າ Datamatrix ຈະບໍ່ທໍາມະດາ, ແຕ່ກົງກັນຂ້າມ. ນັ້ນແມ່ນ, ບໍ່ແມ່ນລະຫັດສີດໍາໃນສີຂາວ, ແຕ່ໃນທາງກັບກັນ.

ພວກ​ເຮົາ​ໄດ້​ທົດ​ສອບ​ເຄື່ອງ​ສະ​ແກນ​ຂອງ​ພວກ​ເຮົາ​, ແລະ​ມັນ​ໄດ້​ຫັນ​ອອກ​ວ່າ​ພວກ​ເຂົາ​ສ່ວນ​ໃຫຍ່​ຈໍາ​ເປັນ​ຕ້ອງ​ໄດ້​ຮັບ​ການ reflashed / retrained​, ຖ້າ​ບໍ່​ດັ່ງ​ນັ້ນ​ພວກ​ເຂົາ​ເຈົ້າ​ພຽງ​ແຕ່​ບໍ່​ສາ​ມາດ​ເຮັດ​ວຽກ​ໄດ້​ປົກ​ກະ​ຕິ​ກັບ barcode ນີ້​. ເຫດການດັ່ງກ່າວໄດ້ຮັບປະກັນໃຫ້ພວກເຮົາເຈັບຫົວຢ່າງຮ້າຍແຮງ, ເພາະວ່າບໍລິສັດຂອງພວກເຮົາມີຮ້ານຄ້າຈໍານວນຫລາຍທີ່ກະແຈກກະຈາຍຢູ່ໃນອານາເຂດທີ່ກວ້າງຂວາງ. ຫຼາຍສິບພັນບັນຊີເງິນສົດ - ແລະໃຊ້ເວລາຫນ້ອຍຫຼາຍ.

ສິ່ງທີ່ຕ້ອງເຮັດ? ມີສອງທາງເລືອກ. ທໍາອິດ: ວິສະວະກອນຢູ່ໃນສະຖານທີ່ reflash ດ້ວຍຕົນເອງແລະປັບຕົວສະແກນ. ອັນທີສອງ: ພວກເຮົາເຮັດວຽກຫ່າງໄກສອກຫຼີກແລະ, ດີກວ່າ, ກວມເອົາເຄື່ອງສະແກນຫຼາຍໆຄັ້ງໃນເວລາດຽວ.

ທາງເລືອກທໍາອິດ, ແນ່ນອນ, ບໍ່ເຫມາະສົມສໍາລັບພວກເຮົາ: ພວກເຮົາຈະຕ້ອງໃຊ້ເງິນໃນການຢ້ຽມຢາມວິສະວະກອນ, ແລະໃນກໍລະນີນີ້ມັນຈະເປັນການຍາກທີ່ຈະຄວບຄຸມແລະປະສານງານຂະບວນການ. ແຕ່ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນວ່າປະຊາຊົນຈະເຮັດວຽກ, ນັ້ນແມ່ນ, ພວກເຮົາອາດຈະໄດ້ຮັບຄວາມຜິດພາດຫຼາຍແລະ, ສ່ວນຫຼາຍອາດຈະບໍ່ກົງກັບກໍານົດເວລາ.

ທາງເລືອກທີສອງແມ່ນດີສໍາລັບທຸກຄົນ, ຖ້າບໍ່ແມ່ນສໍາລັບສິ່ງຫນຶ່ງ. ຜູ້ຂາຍບາງຄົນບໍ່ມີເຄື່ອງມື flashing ຫ່າງໄກສອກຫຼີກທີ່ພວກເຮົາຕ້ອງການສໍາລັບທຸກລະບົບປະຕິບັດການທີ່ຕ້ອງການ. ແລະ​ນັບ​ຕັ້ງ​ແຕ່​ກໍາ​ນົດ​ເວ​ລາ​ຫມົດ​, ຂ້າ​ພະ​ເຈົ້າ​ໄດ້​ຄິດ​ດ້ວຍ​ຫົວ​ຂອງ​ຕົນ​ເອງ​.

ຕໍ່ໄປ, ພວກເຮົາຈະບອກທ່ານວ່າພວກເຮົາພັດທະນາເຄື່ອງມືສໍາລັບເຄື່ອງສະແກນມືສໍາລັບ Debian 9.x OS (ການລົງທະບຽນເງິນສົດຂອງພວກເຮົາທັງຫມົດແມ່ນຢູ່ໃນ Debian).

ແກ້​ໄຂ riddle​: ວິ​ທີ​ການ flash ເຄື່ອງ​ສະ​ແກນ​

Victor Antipov ລາຍງານ.

ປະໂຫຍດຢ່າງເປັນທາງການທີ່ສະຫນອງໃຫ້ໂດຍຜູ້ຂາຍເຮັດວຽກພາຍໃຕ້ Windows, ແລະພຽງແຕ່ກັບ IE. ຜົນປະໂຫຍດສາມາດກະພິບແລະກໍາຫນົດຄ່າເຄື່ອງສະແກນ.

ເນື່ອງຈາກລະບົບເປົ້າຫມາຍຂອງພວກເຮົາແມ່ນ Debian, ພວກເຮົາໄດ້ຕິດຕັ້ງເຄື່ອງແມ່ຂ່າຍຂອງ usb-redirector ໃນ Debian ແລະລູກຄ້າ usb-redirector ໃນ Windows. ການໃຊ້ usb-redirector utilities, ພວກເຮົາໄດ້ສົ່ງເຄື່ອງສະແກນຈາກເຄື່ອງ Linux ໄປຫາເຄື່ອງ Windows.

ຜົນປະໂຫຍດຈາກຜູ້ຂາຍ Windows ໄດ້ເຫັນເຄື່ອງສະແກນແລະແມ້ກະທັ້ງ flashed ມັນເປັນປົກກະຕິ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ສະຫຼຸບທໍາອິດ: ບໍ່ມີຫຍັງຂຶ້ນກັບ OS, ມັນເປັນເລື່ອງຂອງໂປໂຕຄອນກະພິບ.

ຕົກ​ລົງ. ພວກເຮົາດໍາເນີນການ flashing ໃນເຄື່ອງ Windows, ແລະເອົາ dump ໃນເຄື່ອງ Linux.

ພວກເຮົາເອົາຂີ້ເຫຍື້ອໃສ່ WireShark ແລະ ... ຮູ້ສຶກເສຍໃຈ (ຂ້ອຍຈະຍົກເວັ້ນບາງລາຍລະອຽດຂອງການຖິ້ມຂີ້ເຫຍື້ອ, ພວກມັນບໍ່ມີຄວາມສົນໃຈ).

ສິ່ງທີ່ dump ສະແດງໃຫ້ເຫັນພວກເຮົາ:

ທີ່ຢູ່ 0000-0030, ຕັດສິນໂດຍ Wireshark, ແມ່ນຂໍ້ມູນການບໍລິການ USB.

ພວກເຮົາມີຄວາມສົນໃຈໃນສ່ວນ 0040-0070.

ບໍ່ມີຫຍັງຈະແຈ້ງຈາກກອບການສົ່ງຕໍ່ອັນດຽວຍົກເວັ້ນຕົວອັກສອນ MOCFT. ຕົວອັກສອນເຫຼົ່ານີ້ກາຍເປັນຕົວອັກສອນຈາກໄຟລ໌ເຟີມແວ, ເຊັ່ນດຽວກັນກັບຕົວອັກສອນທີ່ຍັງເຫຼືອຈົນກ່ວາໃນຕອນທ້າຍຂອງກອບ (ໄຟລ໌ເຟີມແວຖືກເນັ້ນໃສ່):

ສັນຍາລັກ fd 3e 02 01 fe ຫມາຍຄວາມວ່າແນວໃດ, ຂ້າພະເຈົ້າສ່ວນບຸກຄົນ, ເຊັ່ນ Ilya, ບໍ່ມີຄວາມຄິດ.

ຂ້າພະເຈົ້າໄດ້ເບິ່ງຢູ່ໃນກອບຕໍ່ໄປນີ້ (ຂໍ້ມູນການບໍລິການໄດ້ຖືກລຶບອອກຢູ່ທີ່ນີ້, ໄຟລ໌ເຟີມແວໄດ້ຖືກເນັ້ນໃສ່):

ແມ່ນຫຍັງຈະແຈ້ງ? ວ່າສອງ bytes ທໍາອິດແມ່ນບາງປະເພດຂອງຄົງທີ່. ຕັນຕໍ່ໄປທັງຫມົດຢືນຢັນນີ້, ແຕ່ກ່ອນທີ່ຈະສິ້ນສຸດຂອງຕັນການສົ່ງຕໍ່:

ກອບນີ້ຍັງ stupefying, ນັບຕັ້ງແຕ່ຄົງທີ່ມີການປ່ຽນແປງ (ເນັ້ນໃສ່) ແລະ, oddly ພຽງພໍ, ມີສ່ວນຫນຶ່ງຂອງໄຟລ໌. ຂະຫນາດຂອງ bytes ໂອນຂອງໄຟລ໌ສະແດງໃຫ້ເຫັນວ່າ 1024 bytes ໄດ້ຖືກໂອນ. ອີກເທື່ອ ໜຶ່ງ ຂ້ອຍບໍ່ຮູ້ວ່າ bytes ທີ່ເຫຼືອ ໝາຍ ຄວາມວ່າແນວໃດ.

ກ່ອນອື່ນ ໝົດ, ເປັນຊື່ຫຼິ້ນ BBS ເກົ່າ, ຂ້າພະເຈົ້າໄດ້ທົບທວນຄືນໂປໂຕຄອນການສົ່ງມາດຕະຖານ. ບໍ່ມີໂປຣໂຕຄໍສົ່ງ 1024 bytes. ຂ້ອຍເລີ່ມສຶກສາຮາດແວແລະມາໃນທົ່ວ 1K Xmodem protocol. ມັນອະນຸຍາດໃຫ້ສົ່ງ 1024, ແຕ່ມີຂໍ້ຄວນລະວັງ: ທໍາອິດພຽງແຕ່ 128, ແລະພຽງແຕ່ຖ້າບໍ່ມີຂໍ້ຜິດພາດ, ໂປໂຕຄອນໄດ້ເພີ່ມຈໍານວນ bytes ທີ່ສົ່ງຕໍ່. ຂ້າພະເຈົ້າທັນທີມີການໂອນ 1024 bytes. ຂ້າພະເຈົ້າໄດ້ຕັດສິນໃຈສຶກສາໂປໂຕຄອນການສົ່ງຕໍ່, ແລະໂດຍສະເພາະ X-modem.

ມີສອງຕົວແປຂອງໂມເດັມ.

ຫນ້າທໍາອິດ, ຮູບແບບຊຸດ XMODEM ທີ່ມີການສະຫນັບສະຫນູນ CRC8 (XMODEM ຕົ້ນສະບັບ):

ອັນທີສອງ, ຮູບແບບແພັກເກັດ XMODEM ທີ່ມີການສະຫນັບສະຫນູນ CRC16 (XmodemCRC):

ມັນເບິ່ງຄືວ່າຄ້າຍຄືກັນ, ຍົກເວັ້ນ SOH, ຈໍານວນຊຸດແລະ CRC ແລະຄວາມຍາວຂອງຊຸດ.

ຂ້າພະເຈົ້າໄດ້ເບິ່ງໃນຕອນຕົ້ນຂອງລະບົບສາຍສົ່ງທີສອງ (ແລະອີກເທື່ອຫນຶ່ງໄດ້ເຫັນໄຟລ໌ firmware, ແຕ່ indented ແລ້ວໂດຍ 1024 bytes):

ຂ້ອຍເຫັນ header fd 3e 02 ທີ່ຄຸ້ນເຄີຍ, ແຕ່ສອງ bytes ຕໍ່ໄປໄດ້ປ່ຽນແປງແລ້ວ: ມັນແມ່ນ 01 fe, ແລະກາຍເປັນ 02 fd. ຫຼັງຈາກນັ້ນ, ຂ້າພະເຈົ້າໄດ້ສັງເກດເຫັນວ່າຕັນທີສອງແມ່ນຫມາຍເລກ 02 ແລະດັ່ງນັ້ນຈຶ່ງເຂົ້າໃຈ: ຢູ່ທາງຫນ້າຂອງຂ້ອຍແມ່ນຕົວເລກຂອງຕັນສາຍສົ່ງ. ເຄື່ອງມື 1024 ທໍາອິດແມ່ນ 01, ທີສອງແມ່ນ 02, ທີສາມແມ່ນ 03 ແລະອື່ນໆ (ແຕ່ໃນ hex, ແນ່ນອນ). ແຕ່ການປ່ຽນແປງຈາກ fe ເປັນ fd ຫມາຍຄວາມວ່າແນວໃດ? ຕາເຫັນການຫຼຸດລົງ 1, ສະຫມອງເຕືອນວ່ານັກຂຽນໂປລແກລມນັບຈາກ 0, ບໍ່ແມ່ນ 1. ແຕ່ເປັນຫຍັງຕັນທໍາອິດຈຶ່ງເປັນ 1, ແລະບໍ່ແມ່ນ 0? ຂ້ອຍຍັງບໍ່ພົບຄໍາຕອບຂອງຄໍາຖາມນີ້. ແຕ່ຂ້ອຍເຂົ້າໃຈວິທີການນັບຕັນທີສອງ. ຕັນທີສອງແມ່ນບໍ່ມີຫຍັງຫຼາຍກ່ວາ FF – (ລົບ) ຈໍານວນຂອງຕັນທໍາອິດ. ດັ່ງນັ້ນ, ຕັນທີສອງຖືກກໍານົດເປັນ = 02 (FF-02) = 02 FD. ການອ່ານຕໍ່ໄປຂອງການຖິ້ມຂີ້ເຫຍື້ອໄດ້ຢືນຢັນການຄາດເດົາຂອງຂ້ອຍ.

ຫຼັງຈາກນັ້ນ, ຮູບພາບດັ່ງຕໍ່ໄປນີ້ຂອງການສົ່ງຕໍ່ໄດ້ເລີ່ມຕົ້ນອອກມາ:

ການເລີ່ມຕົ້ນຂອງລະບົບສາຍສົ່ງ
fd 3e 02 – ເລີ່ມ
01 FE – ເຄົາເຕີສາຍສົ່ງ
ໂອນຍ້າຍ (34 ຕັນ, 1024 bytes ໂອນ)
fd 3e 1024 bytes ຂອງຂໍ້ມູນ (ແບ່ງອອກເປັນ 30 byte block).
ສິ້ນສຸດລະບົບສາຍສົ່ງ
fd 25

ຂໍ້​ມູນ​ທີ່​ຍັງ​ເຫຼືອ​ທີ່​ຈະ​ສອດ​ຄ່ອງ​ກັບ 1024 bytes​.

ກອບການສົ່ງຕໍ່ຕັນມີລັກສະນະແນວໃດ:

fd 25 – ສັນຍານທີ່ຈະສິ້ນສຸດການສົ່ງຕໍ່ຕັນ. ຕໍ່ໄປ 2f 52 - ສ່ວນທີ່ເຫຼືອຂອງໄຟລ໌ສູງເຖິງ 1024 bytes ໃນຂະຫນາດ. 2f 52, ຕັດສິນໂດຍໂປຣໂຕຄໍ, ເປັນ checksum CRC 16-bit.

ສໍາລັບຜົນປະໂຫຍດຂອງເວລາເກົ່າ, ຂ້າພະເຈົ້າໄດ້ສ້າງໂຄງການໃນ C ທີ່ດຶງ 1024 bytes ຈາກໄຟລ໌ແລະຄິດໄລ່ CRC 16-bit. ການເປີດຕົວໂຄງການສະແດງໃຫ້ເຫັນວ່ານີ້ບໍ່ແມ່ນ CRC 16-bit. Stupor ອີກເທື່ອຫນຶ່ງ - ສໍາລັບປະມານສາມມື້. ຕະຫຼອດເວລານີ້ຂ້ອຍພະຍາຍາມເຂົ້າໃຈສິ່ງທີ່ມັນອາດຈະເປັນ, ຖ້າບໍ່ແມ່ນ checksum. ໃນຂະນະທີ່ກໍາລັງສຶກສາເວັບໄຊທ໌ທີ່ເປັນພາສາອັງກິດ, ຂ້າພະເຈົ້າໄດ້ຄົ້ນພົບວ່າ X-modem ໃຊ້ການຄິດໄລ່ checksum ຂອງຕົນເອງ - CRC-CCITT (XModem). ຂ້ອຍບໍ່ພົບການປະຕິບັດ C ຂອງການຄິດໄລ່ນີ້, ແຕ່ຂ້ອຍພົບເວັບໄຊທ໌ທີ່ຄິດໄລ່ checksum ນີ້ອອນໄລນ໌. ໂດຍໄດ້ໂອນ 1024 bytes ຂອງໄຟລ໌ຂອງຂ້ອຍໄປຫາຫນ້າເວັບ, ເວັບໄຊທ໌ໄດ້ສະແດງໃຫ້ຂ້ອຍເຫັນ checksum ທີ່ກົງກັບ checksum ຈາກໄຟລ໌.

ໂຫ້ຍ! riddle ສຸດທ້າຍໄດ້ຖືກແກ້ໄຂ, ຕອນນີ້ຂ້ອຍຈໍາເປັນຕ້ອງສ້າງເຟີມແວຂອງຂ້ອຍເອງ. ຕໍ່ໄປ, ຂ້າພະເຈົ້າໄດ້ຖ່າຍທອດຄວາມຮູ້ຂອງຂ້ອຍ (ແລະມັນຢູ່ໃນຫົວຂອງຂ້ອຍເທົ່ານັ້ນ) ກັບ Ilya, ຜູ້ທີ່ຄຸ້ນເຄີຍກັບຊຸດເຄື່ອງມືທີ່ມີປະສິດທິພາບ Python.

ການສ້າງໂຄງການ

Ilya Aleshin ມີ​ລາຍ​ງານ.

ໂດຍໄດ້ຮັບຄໍາແນະນໍາທີ່ເຫມາະສົມ, ຂ້ອຍ "ດີໃຈຫຼາຍ."

ບ່ອນທີ່ຈະເລີ່ມຕົ້ນ? ນັ້ນແມ່ນ, ຕັ້ງແຕ່ເລີ່ມຕົ້ນ.  ຈາກການເອົາຂີ້ເຫຍື້ອອອກຈາກພອດ USB.

ເປີດໃຊ້ USB-pcap https://desowin.org/usbpcap/tour.html

ເລືອກພອດທີ່ອຸປະກອນເຊື່ອມຕໍ່ແລະໄຟລ໌ທີ່ພວກເຮົາຈະຊ່ວຍປະຢັດ dump ໄດ້.

ພວກເຮົາເຊື່ອມຕໍ່ເຄື່ອງສະແກນກັບເຄື່ອງທີ່ຕິດຕັ້ງຊອບແວ EZConfigScanning ພື້ນເມືອງສໍາລັບ Windows.

ໃນມັນພວກເຮົາຊອກຫາລາຍການສໍາລັບການສົ່ງຄໍາສັ່ງກັບອຸປະກອນ. ແຕ່ສິ່ງທີ່ກ່ຽວກັບທີມ? ຂ້ອຍສາມາດເອົາພວກມັນໄດ້ຢູ່ໃສ?
ໃນເວລາທີ່ໂຄງການເລີ່ມຕົ້ນ, ອຸປະກອນໄດ້ຖືກ polled ອັດຕະໂນມັດ (ພວກເຮົາຈະເຫັນນີ້ເລັກນ້ອຍຕໍ່ມາ). ແລະໄດ້ມີການຝຶກອົບຮົມ barcode ຈາກເອກະສານອຸປະກອນທາງການ. ຄ່າເລີ່ມຕົ້ນ. ນີ້ແມ່ນທີມງານຂອງພວກເຮົາ.

ຂໍ້ມູນທີ່ຈໍາເປັນໄດ້ຮັບແລ້ວ. ເປີດ dump.pcap ຜ່ານ wireshark.

ບລັອກເມື່ອເລີ່ມ EZConfigScanning. ສະຖານທີ່ທີ່ທ່ານຈໍາເປັນຕ້ອງເອົາໃຈໃສ່ແມ່ນຫມາຍເປັນສີແດງ.

ເຫັນທັງໝົດນີ້ເປັນເທື່ອທຳອິດ, ຂ້ອຍເສຍໃຈ. ມັນບໍ່ຈະແຈ້ງວ່າບ່ອນໃດທີ່ຈະຂຸດຕໍ່ໄປ.

ລະດົມສະໝອງໜ້ອຍໜຶ່ງ ແລະ ແລະ ແລະ... ອ້າວ! ໃນບ່ອນຖິ້ມຂີ້ເຫຍື້ອ ອອກ - ນີ້ inແລະ in ມັນ ອອກ.

ຂ້າພະເຈົ້າໄດ້ googled ວ່າ URB_INTERRUPT ແມ່ນຫຍັງ. ຂ້ອຍພົບວ່ານີ້ແມ່ນວິທີການໂອນຂໍ້ມູນ. ແລະມີ 4 ວິທີການດັ່ງກ່າວ: ການຄວບຄຸມ, ຂັດຂວາງ, isochronous, bulk. ທ່ານສາມາດອ່ານກ່ຽວກັບພວກເຂົາແຍກຕ່າງຫາກ.

ແລະທີ່ຢູ່ປາຍທາງໃນການໂຕ້ຕອບອຸປະກອນ USB ສາມາດໄດ້ຮັບໂດຍຜ່ານຄໍາສັ່ງ "lsusb –v" ຫຼືການນໍາໃຊ້ pyusb.

ໃນປັດຈຸບັນພວກເຮົາຈໍາເປັນຕ້ອງຊອກຫາອຸປະກອນທັງຫມົດທີ່ມີ VID ນີ້. ທ່ານສາມາດຄົ້ນຫາໂດຍສະເພາະໂດຍ VID:PID.

ມັນເບິ່ງຄືວ່ານີ້:

ດັ່ງນັ້ນ, ພວກເຮົາມີຂໍ້ມູນທີ່ຈໍາເປັນ: ຄໍາສັ່ງ P_INFO. ຫຼື DEFALT, ທີ່ຢູ່ບ່ອນທີ່ຈະຂຽນຄໍາສັ່ງ endpoint=03 ແລະບ່ອນທີ່ຈະໄດ້ຮັບຄໍາຕອບ endpoint=86. ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອປ່ຽນຄໍາສັ່ງເປັນ hex.

ເນື່ອງຈາກພວກເຮົາໄດ້ພົບເຫັນອຸປະກອນແລ້ວ, ໃຫ້ພວກເຮົາຕັດການເຊື່ອມຕໍ່ຈາກ kernel ...

...ແລະຂຽນໃສ່ຈຸດສິ້ນສຸດດ້ວຍທີ່ຢູ່ 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.

ຍິ່ງໃຫຍ່! ປ່ຽນບາໂຄດລະບົບເປັນ hex. ນັ້ນແມ່ນ, ຫນ້າທີ່ການຝຶກອົບຮົມແມ່ນກຽມພ້ອມ.

ແມ່ນຫຍັງກ່ຽວກັບເຟີມແວ? ທຸກສິ່ງທຸກຢ່າງເບິ່ງຄືວ່າຄືກັນ, ແຕ່ມີ nuance ເປັນ.

ໂດຍໄດ້ເອົາການຖິ້ມຂີ້ເຫຍື້ອທີ່ສົມບູນຂອງຂະບວນການກະພິບ, ພວກເຮົາເຂົ້າໃຈປະມານສິ່ງທີ່ພວກເຮົາຈັດການກັບ. ນີ້ແມ່ນບົດຄວາມກ່ຽວກັບ XMODEM, ເຊິ່ງເປັນປະໂຫຍດຫຼາຍໃນການເຂົ້າໃຈວິທີການສື່ສານນີ້ເກີດຂຶ້ນ, ເຖິງແມ່ນວ່າໃນຄໍາສັບທົ່ວໄປ: http://microsin.net/adminstuff/others/xmodem-protocol-overview.html ຂ້ອຍຂໍແນະນໍາໃຫ້ອ່ານມັນ.

ຊອກຫາຢູ່ໃນບ່ອນຖິ້ມຂີ້ເຫຍື້ອ, ທ່ານສາມາດເຫັນໄດ້ວ່າຂະຫນາດຂອງກອບແມ່ນ 1024, ແລະຂະຫນາດຂໍ້ມູນ URB ແມ່ນ 64.

ເພາະສະນັ້ນ - 1024/64 – ພວກ​ເຮົາ​ໄດ້​ຮັບ 16 ເສັ້ນ​ໃນ​ຕັນ​, ອ່ານ​ໄຟລ​໌ firmware 1 ຕົວ​ອັກ​ສອນ​ໃນ​ເວ​ລາ​ແລະ​ປະ​ກອບ​ເປັນ block ໄດ້​. ການຕື່ມ 1 ແຖວໃນບລັອກທີ່ມີຕົວອັກສອນພິເສດ fd3e02 + ຕົວເລກບລັອກ.
ຕໍ່ໄປ 14 ແຖວຖືກເສີມດ້ວຍ fd25 +, ໂດຍໃຊ້ XMODEM.calc_crc() ພວກເຮົາຄິດໄລ່ checksum ຂອງທ່ອນໄມ້ທັງຫມົດ (ມັນໃຊ້ເວລາຫຼາຍທີ່ຈະເຂົ້າໃຈວ່າ "FF – 1" ແມ່ນ CSUM) ແລະສຸດທ້າຍ, ແຖວທີ 16 ແມ່ນເສີມ. ກັບ fd3e.

ມັນເບິ່ງຄືວ່ານັ້ນແມ່ນ, ອ່ານໄຟລ໌ເຟີມແວ, ຕີຕັນ, ຕັດການເຊື່ອມຕໍ່ເຄື່ອງສະແກນຈາກແກ່ນແລະສົ່ງມັນໄປຫາອຸປະກອນ. ແຕ່ມັນບໍ່ງ່າຍດາຍ. ເຄື່ອງສະແກນຈໍາເປັນຕ້ອງໄດ້ປ່ຽນເປັນໂຫມດເຟີມແວ,
отправив ему NEWAPP = ‘\xfd\x0a\x16\x4e\x2c\x4e\x45\x57\x41\x50\x50\x0d’.
ທີມນີ້ມາຈາກໃສ?? ຈາກບ່ອນຖິ້ມຂີ້ເຫຍື້ອ.

ແຕ່ພວກເຮົາບໍ່ສາມາດສົ່ງບລັອກທັງໝົດໄປຫາເຄື່ອງສະແກນໄດ້ເນື່ອງຈາກຂີດຈຳກັດ 64:

ດີ, ເຄື່ອງສະແກນໃນໂຫມດກະພິບ NEWAPP ບໍ່ຍອມຮັບ hex. ດັ່ງນັ້ນ, ທ່ານຈະຕ້ອງແປແຕ່ລະແຖວ 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.

ແທ້ຈິງແລ້ວ, ມັນເປັນເລື່ອງເລັກນ້ອຍ. ທັງຫມົດທີ່ຍັງເຫຼືອແມ່ນເພື່ອຫໍ່ການແກ້ໄຂໃນສະຄິບສໍາລັບການຈໍາລອງມະຫາຊົນໃນເວລາທີ່ກໍານົດໄວ້ຢ່າງຊັດເຈນ, ເພື່ອບໍ່ໃຫ້ຂະບວນການເຮັດວຽກຢູ່ບ່ອນເກັບເງິນຊ້າລົງ, ແລະເພີ່ມການເຂົ້າສູ່ລະບົບ.

ຜົນໄດ້ຮັບ

ໂດຍໃຊ້ເວລາຫຼາຍແລະຄວາມພະຍາຍາມແລະຜົມຢູ່ເທິງຫົວຂອງພວກເຮົາ, ພວກເຮົາສາມາດພັດທະນາວິທີແກ້ໄຂທີ່ພວກເຮົາຕ້ອງການ, ແລະຍັງບັນລຸໄດ້ກໍານົດເວລາ. ໃນເວລາດຽວກັນ, ເຄື່ອງສະແກນໄດ້ຖືກ reflashed ແລະ retrained ສູນກາງ, ພວກເຮົາຄວບຄຸມຂະບວນການທັງຫມົດຢ່າງຊັດເຈນ. ບໍລິສັດໄດ້ປະຫຍັດເວລາແລະເງິນ, ແລະພວກເຮົາໄດ້ຮັບປະສົບການອັນລ້ໍາຄ່າໃນອຸປະກອນວິສະວະກໍາຍ້ອນກັບຂອງປະເພດນີ້.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com