개발자의 작업 또는 공급업체 없이 휴대용 스캐너를 플래시하는 방법

안녕 모두

오늘 저희, 빅터 안티포프와 일리야 알레신은 Python PyUSB를 통해 USB 장치를 다루는 경험과 리버스 엔지니어링에 대해 이야기해보겠습니다.

선사 시대

2019년에 러시아 연방 정부 결의안 제224호 "담배 제품에 식별 수단을 표시하기 위한 규칙 승인 및 담배 제품과 관련된 식별 수단 표시 의무화 대상 상품의 유통을 모니터링하기 위한 국가 정보 시스템 구현 세부 사항"이 발효되었습니다.
이 문서는 1년 2019월 XNUMX일부터 제조업체가 모든 담배 갑에 라벨을 부착해야 한다고 설명합니다. 또한 직접 유통업체는 UPD(Universal Transfer Document) 등록을 통해 제품을 수령해야 합니다. 또한, 매장에서는 라벨이 부착된 제품의 판매를 금전 등록기를 통해 등록해야 합니다.

또한 1년 2020월 XNUMX일부터 표시가 없는 담배 제품의 유통이 금지됩니다. 즉, 모든 담뱃갑에는 특수 데이터매트릭스 바코드가 표시되어야 합니다. 더욱 중요한 점은 데이터매트릭스가 일반적인 데이터매트릭스가 아니라 그 반대라는 것입니다. 즉, 흰색 바탕에 검은색 코드가 아니라 그 반대입니다.

스캐너를 테스트해 본 결과, 대부분 스캐너를 재플래시하거나 재교육해야 하는 것으로 나타났습니다. 그렇지 않으면 이 바코드를 인식하고 정상적으로 작동할 수 없습니다. 이러한 상황은 저희 회사에 큰 골칫거리가 될 수밖에 없었습니다. 저희 회사는 넓은 지역에 매장이 산재해 있고, 수만 개의 금전 등록기가 있는데도 불구하고 시간이 매우 부족하기 때문입니다.

무엇을 해야 했을까요? 두 가지 옵션이 있습니다. 첫째, 현장 엔지니어가 스캐너를 수동으로 재플래시하고 미세 조정하는 것입니다. 둘째, 원격으로 작업하고, 가급적이면 한 번에 여러 스캐너를 검사하는 것입니다.

첫 번째 옵션은 당연히 우리에게 적합하지 않았습니다. 엔지니어 방문에 비용을 지출해야 했고, 그럴 경우 프로세스를 제어하고 조정하는 것이 어려웠습니다. 하지만 가장 중요한 것은 사람들이 계속 작업해야 한다는 점입니다. 즉, 오류가 많이 발생할 가능성이 높고, 마감일을 맞추지 못할 가능성이 높습니다.

두 번째 옵션은 모두에게 좋을 것 같지만, 한 가지 단점이 있습니다. 일부 업체는 필요한 모든 OS에 필요한 원격 플래싱 도구를 제공하지 않았습니다. 게다가 마감일이 촉박했기 때문에 직접 생각해 내야 했습니다.

다음으로, 데비안 9.x OS에서 손 스캐너 도구를 어떻게 개발했는지 알려드리겠습니다(저희의 모든 금전 등록기는 데비안 기반입니다).

수수께끼를 풀어보세요: 스캐너를 플래시하는 방법

빅터 안티포프가 이야기를 들려줍니다.

공급업체에서 제공하는 공식 유틸리티는 Windows 및 IE에서만 작동합니다. 이 유틸리티를 사용하면 스캐너를 플래시하고 구성할 수 있습니다.

대상 시스템이 데비안이므로 데비안에는 USB-Redirector 서버를, 윈도우에는 USB-Redirector 클라이언트를 설치했습니다. USB-Redirector 유틸리티를 사용하여 Linux 컴퓨터에서 Windows 컴퓨터로 스캐너를 전달했습니다.

공급업체의 Windows용 유틸리티가 스캐너를 인식하고 정상적으로 플래싱까지 완료했습니다. 따라서 첫 번째 결론은 OS와는 무관하며, 플래싱 프로토콜에 문제가 있다는 것입니다.

좋아요. Windows 컴퓨터에서 리플래싱을 시작했고, Linux 컴퓨터에서는 덤프를 실행했습니다.

우리는 덤프를 WireShark에 밀어 넣었고... 슬펐습니다(덤프에 대한 세부 사항 중 일부는 건너뛰겠습니다. 중요하지 않습니다).

매립지가 우리에게 보여준 것:

Wireshark에 따르면 주소 0000-0030은 USB 서비스 정보입니다.

우리는 0040-0070 부분에 관심이 있었습니다.

단일 전송 프레임에서는 MOCFT 기호를 제외하고는 아무것도 명확하게 나타나지 않았습니다. 이 기호들은 펌웨어 파일에서 가져온 기호였으며, 프레임 끝까지 남은 기호들도 마찬가지였습니다(펌웨어 파일은 강조 표시되어 있습니다).

개인적으로 저는 일리아처럼 fd 3e 02 01 fe라는 기호가 무엇을 의미하는지 전혀 몰랐습니다.

다음 프레임을 살펴보았습니다(여기서는 서비스 정보가 제거되었고, 펌웨어 파일이 강조 표시되었습니다).

무엇이 분명해졌을까요? 처음 두 바이트는 일종의 상수라는 것입니다. 이후 모든 블록에서 이를 확인했지만, 전송 블록이 끝나기 전에 다음과 같은 결과가 나왔습니다.

이 프레임도 헷갈렸는데, 상수가 바뀌었고(강조 표시됨) 이상하게도 파일의 일부가 남아 있었기 때문입니다. 전송된 파일 바이트 크기는 1024바이트로 표시되었습니다. 나머지 바이트가 무엇을 의미하는지는 저도 알 수 없었습니다.

우선, 저는 오래된 BBS-nik으로서 표준 전송 프로토콜을 검토했습니다. 어떤 프로토콜도 1024바이트를 전송하지 못했습니다. 하드웨어를 공부하기 시작하면서 1K X-modem 프로토콜을 발견했습니다. 이 프로토콜은 1024바이트를 전송할 수 있었지만, 미묘한 차이가 있었습니다. 처음에는 128바이트만 전송했고, 오류가 없을 때만 전송 바이트 수가 증가했습니다. 저는 즉시 1024바이트를 전송했습니다. 그래서 전송 프로토콜, 특히 X-modem을 연구하기로 했습니다.

모뎀에는 두 가지 변형이 있었습니다.

먼저, CRC8을 지원하는 XMODEM 패킷 포맷(원래 XMODEM):

둘째, CRC16을 지원하는 XMODEM 패킷 포맷(XmodemCRC):

SOH, 패키지 번호, CRC, 패키지 길이를 제외하면 비슷해 보입니다.

두 번째 전송 블록의 시작 부분을 살펴보았습니다(그리고 다시 펌웨어 파일을 보았지만 들여쓰기가 1024바이트였습니다).

익숙한 헤더 fd 3e 02를 보았지만 다음 두 바이트는 이미 바뀌어 있었습니다.01 fe였고 02 fd가 되었습니다.그런 다음 두 번째 블록이 이제 02로 번호가 매겨진 것을 보고 이해했습니다.내 앞에 전송 블록의 번호가 있었습니다.첫 번째 1024 전송은 01, 두 번째는 02, 세 번째는 03입니다(물론 1진수).하지만 fe에서 fd로의 변경은 무엇을 의미할까요?내 눈은 0 감소한 것을 보았고, 내 뇌는 프로그래머가 1이 아니라 1부터 센다는 것을 상기시켰습니다.그렇다면 왜 첫 번째 블록은 0이 아니라 02일까요?저는 이 질문에 대한 답을 찾지 못했습니다.하지만 두 번째 블록은 어떻게 세는지 이해했습니다.두 번째 블록은 FF - (마이너스) 첫 번째 블록의 번호에 불과합니다.따라서 두 번째 블록은 = 02 (FF-02) = XNUMX FD로 지정되었습니다.그 후에 덤프를 읽어보니 내 추측이 맞았습니다.

그러자 다음과 같은 전송 그림이 나타나기 시작했습니다.

전송 시작
fd3e02-시작
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가 아니었습니다. 다시 한번, 약 1024일 동안 멍하니 있었습니다. 그동안 저는 그것이 체크섬이 아니라면 무엇일지 이해하려고 애썼습니다. 영어 사이트들을 살펴보니 X-모뎀이 자체 체크섬 계산 방식인 CRC-CCITT(XModem)를 사용한다는 것을 알게 되었습니다. 이 계산을 C로 구현한 사이트는 없었지만, 온라인에서 이 체크섬을 계산하는 사이트를 찾았습니다. XNUMX바이트 파일을 웹 페이지로 전송했더니, 해당 사이트에서 파일의 체크섬과 완전히 일치하는 체크섬을 보여주었습니다.

만세! 마지막 수수께끼가 해결되었으니, 이제 직접 펌웨어를 만들어야 합니다. 그런 다음 제 지식을 (오직 머릿속에만 남아 있던) 강력한 툴킷인 Python에 정통한 Ilya에게 전수했습니다.

프로그램 만들기

일리아 알레신이 이야기를 들려줍니다.

관련 지시를 받고 나는 매우 "기뻤다".

어디서부터 시작해야 할까요? 네, 처음부터요.  USB 포트에서 덤프를 가져오는 것부터요.

USB-pcap 실행 https://desowin.org/usbpcap/tour.html

장치가 연결된 포트와 덤프를 저장할 파일을 선택합니다.

스캐너를 Windows용 기본 EZConfigScanning 소프트웨어가 설치된 컴퓨터에 연결합니다.

여기서 우리는 장치에 명령을 보내는 요점을 찾을 수 있습니다. 하지만 이 명령들은 어떻게 처리해야 할까요? 어디서 얻을 수 있을까요?
프로그램이 시작되면 장비가 자동으로 폴링됩니다(이 부분은 잠시 후에 설명하겠습니다). 그리고 공식 장비 문서의 교육용 바코드도 있습니다. 기본 설정입니다. 저희 팀입니다.

필요한 데이터를 수신했습니다. Wireshark를 통해 dump.pcap을 엽니다.

EZConfigScanning을 시작할 때 차단합니다. 주의가 필요한 부분은 빨간색으로 표시됩니다.

이 모든 것을 처음 본 나는 낙담했다. 다음에는 어디를 파야 할지 알 수 없었다.

약간의 브레인스토밍과... 아하! 쓰레기장에서 아웃 -가요 in과 in 그것 아웃.

URB_INTERRUPT가 뭔지 구글에서 검색해 봤는데, 데이터 전송 방식이라는 걸 알 수 있었습니다. 이 방식에는 제어 방식, 인터럽트 방식, 등시성 방식, 대량 방식 등 네 가지가 있습니다. 각 방식에 대한 설명은 별도로 확인하실 수 있습니다.

USB 장치 인터페이스의 엔드포인트 주소는 "lsusb –v" 명령이나 pyusb를 통해 얻을 수 있습니다.

이제 해당 VID를 가진 모든 장치를 찾아야 합니다. VID:PID로 구체적으로 검색할 수 있습니다.

다음과 같이 보입니다.

이제 필요한 정보, 즉 P_INFO 또는 DEFALT 명령, 명령을 작성할 주소(엔드포인트=03)와 응답을 받을 주소(엔드포인트=86)를 얻었습니다. 이제 명령을 XNUMX진수로 변환하는 작업만 남았습니다.

이미 장치를 찾았으므로 커널에서 연결을 끊겠습니다.

…그리고 우리는 주소 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에서 이 데이터를 볼 수 있습니다.

훌륭합니다! 시스템 바코드를 16진수로 변환합니다. 이제 교육 기능이 준비되었습니다.

펌웨어는 어떤가요? 똑같아 보이지만, 미묘한 차이가 있습니다.

리플래시 과정을 완전히 살펴보고 나니, 무슨 일이 벌어지고 있는지 대략적으로 이해하게 되었습니다. XMODEM에 대한 글을 참고했는데, 이 통신이 어떻게 이루어지는지, 비록 일반적인 내용이지만, 이해하는 데 큰 도움이 되었습니다. http://microsin.net/adminstuff/others/xmodem-protocol-overview.html 나는 독서를 권합니다.

덤프를 살펴보면 프레임 크기가 1024이고, URB 데이터 크기가 64인 것을 알 수 있습니다.

따라서 – 1024/64 – 블록에 16줄을 넣고, 펌웨어 파일을 한 번에 한 문자씩 읽어 블록을 구성합니다. 블록의 한 줄을 특수 문자 fd1e1 + 블록 번호로 추가합니다.
다음 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 재플래시 모드의 스캐너는 16진수를 인식하지 못합니다. 따라서 각 줄을 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을 통해 진행률 표시줄을 구성하겠습니다.

사실, 이제 큰 문제는 아닙니다. 남은 것은 명확하게 정의된 시간에 대량 복제를 위한 스크립트로 솔루션을 래핑하여 계산대 작업 속도를 늦추지 않고 로깅을 추가하는 것입니다.

합계

많은 시간과 노력, 그리고 땀 흘린 노력 끝에, 저희는 필요한 솔루션을 개발하고 마감일도 준수할 수 있었습니다. 동시에, 스캐너는 중앙에서 재플래시 및 재교육되므로 전체 프로세스를 명확하게 제어할 수 있습니다. 덕분에 회사는 시간과 비용을 절약할 수 있었고, 저희는 이러한 유형의 장비 역설계에 대한 귀중한 경험을 쌓았습니다.

출처 : habr.com