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

안녕 모두

오늘 Victor Antipov와 Ilya Aleshin은 Python PyUSB를 통해 USB 장치로 작업한 경험과 리버스 엔지니어링에 대해 조금 이야기하겠습니다.

선사 시대

2019년 러시아 연방 정부 법령 제 224호 “식별 수단을 사용하여 담배 제품에 라벨을 붙이는 규칙 승인 및 식별 수단을 사용하여 필수 라벨링 대상 상품의 유통을 모니터링하기 위한 국가 정보 시스템 구현 기능 승인 시” 담배 제품과 관련하여”가 시행되었습니다.
이 문서에서는 1년 2019월 XNUMX일부터 제조업체가 각 담배 팩에 라벨을 부착해야 한다고 설명합니다. 그리고 직접 유통업체는 UDD(Universal Transfer Document)를 실행하여 이러한 제품을 받아야 합니다. 상점에서는 금전 등록기를 통해 라벨이 붙은 제품의 판매를 등록해야 합니다.

또한, 1년 2020월 XNUMX일부터 라벨이 부착되지 않은 담배 제품의 유통이 금지됩니다. 이는 모든 담배갑에 특수 Datamatrix 바코드가 표시되어야 함을 의미합니다. 더욱이 중요한 점은 Datamatrix가 평범하지 않고 반대라는 것이 밝혀졌습니다. 즉, 흰색 바탕에 검정색 코드가 있는 것이 아니라 그 반대의 경우도 마찬가지입니다.

우리는 스캐너를 테스트한 결과 대부분의 스캐너를 새로 고치거나 재교육해야 하는 것으로 나타났습니다. 그렇지 않으면 이 바코드로 정상적으로 작동할 수 없습니다. 우리 회사는 넓은 지역에 걸쳐 많은 매장을 갖고 있기 때문에 이런 상황은 우리에게 심각한 골치 아픈 일을 안겨주었습니다. 수만 개의 금전 등록기가 있지만 시간은 거의 없습니다.

무엇을 해야 했나요? 두 가지 옵션이 있습니다. 첫째, 현장 엔지니어가 수동으로 스캐너를 다시 플래시하고 조정합니다. 둘째: 우리는 원격으로 작업하며 가급적이면 한 번의 반복으로 한 번에 많은 스캐너를 처리합니다.

분명히 첫 번째 옵션은 우리에게 적합하지 않았습니다. 엔지니어를 방문하는 데 돈을 써야 하고 이 경우 프로세스를 제어하고 조정하기가 어려울 것입니다. 그러나 가장 중요한 것은 사람들이 일한다는 것입니다. 즉, 잠재적으로 많은 오류가 발생하고 마감일을 지키지 못할 가능성이 높습니다.

두 번째 옵션은 한 가지가 아니라면 모든 사람에게 좋습니다. 일부 공급업체에는 필요한 모든 운영 체제에 필요한 원격 플래싱 도구가 없었습니다. 그리고 마감일이 다가오자 머리로 생각을 해야 했습니다.

다음으로 우리는 어떻게 Debian 9.x OS용 휴대용 스캐너 도구를 개발했는지 알려드리겠습니다(우리의 모든 금전 등록기는 Debian에 있습니다).

수수께끼 풀기: 스캐너를 플래시하는 방법

빅터 안티포프(Victor Antipov)가 보고합니다.

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

대상 시스템이 Debian이므로 Debian에 usb-redirector 서버를 설치하고 Windows에 usb-redirector 클라이언트를 설치했습니다. usb-redirector 유틸리티를 사용하여 스캐너를 Linux 시스템에서 Windows 시스템으로 전달했습니다.

Windows 공급업체의 유틸리티가 스캐너를 보고 정상적으로 플래시까지 했습니다. 따라서 우리는 첫 번째 결론을 내렸습니다. OS에 의존하는 것은 없으며 플래싱 프로토콜의 문제입니다.

좋아요. Windows 시스템에서 플래싱을 실행하고 Linux 시스템에서 덤프를 제거했습니다.

우리는 덤프를 WireShark에 넣었고... 슬펐습니다(덤프의 세부 사항 중 일부를 생략하겠습니다. 관심이 없습니다).

덤프가 우리에게 보여준 것:

Wireshark로 판단되는 주소 0000~0030은 USB 서비스 정보입니다.

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

MOCFT 문자를 제외하고 하나의 전송 프레임에서 명확한 것은 없습니다. 이 문자는 펌웨어 파일의 문자와 프레임 끝까지 남은 문자로 밝혀졌습니다(펌웨어 파일이 강조 표시됨).

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

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

무엇이 분명해졌나요? 처음 두 바이트는 일종의 상수입니다. 모든 후속 블록은 이를 확인했지만 전송 블록이 끝나기 전에:

이 프레임은 또한 상수가 변경(강조 표시)되었고 이상하게도 파일의 일부가 있었기 때문에 어리둥절했습니다. 파일의 전송된 바이트 크기는 1024바이트가 전송된 것으로 나타났습니다. 나는 다시 남은 바이트가 무엇을 의미하는지 몰랐습니다.

먼저 예전 BBS 별명답게 표준 전송 프로토콜을 검토해보았습니다. 1024바이트를 전송하는 프로토콜이 없습니다. 나는 하드웨어를 공부하기 시작했고 1K Xmodem 프로토콜을 발견했습니다. 1024 전송을 허용했지만 주의할 점이 있습니다. 처음에는 128에 불과했고 오류가 없는 경우에만 프로토콜이 전송된 바이트 수를 늘렸습니다. 즉시 1024바이트를 전송했습니다. 나는 전송 프로토콜, 특히 X 모뎀을 연구하기로 결정했습니다.

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

첫째, 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)=XNUMXFD로 지정되었습니다. 이후 덤프를 읽어보니 내 추측이 확인되었습니다.

그런 다음 전송에 대한 다음 그림이 나타나기 시작했습니다.

전송 시작
fd 3e 02 – 시작
01 FE – 전송 카운터
전송(34블록, 1024바이트 전송)
fd 3e 1024바이트의 데이터(30바이트 블록으로 나눔).
전송 종료
FD 25

나머지 데이터는 1024바이트로 정렬됩니다.

블록 전송 종료 프레임은 어떻게 생겼나요?

fd 25 – 블록 전송을 종료하는 신호입니다. Next 2f 52 – 나머지 파일 크기는 최대 1024바이트입니다. 프로토콜에 따르면 2f 52는 16비트 CRC 체크섬입니다.

옛날에는 파일에서 1024바이트를 가져와 16비트 CRC를 계산하는 프로그램을 C로 만들었습니다. 프로그램을 실행해 보니 16비트 CRC가 아닌 것으로 나타났습니다. 다시 무감각 - 약 1024 일 동안. 그동안 나는 그것이 체크섬이 아니라면 무엇일 수 있는지 이해하려고 노력했습니다. 영어 사이트를 연구하는 동안 X 모뎀이 자체 체크섬 계산인 CRC-CCITT(XModem)를 사용한다는 사실을 발견했습니다. 이 계산에 대한 C 구현을 찾지 못했지만 온라인에서 이 체크섬을 계산하는 사이트를 찾았습니다. XNUMX바이트의 내 파일을 웹 페이지로 전송한 후 사이트는 파일의 체크섬과 완전히 일치하는 체크섬을 보여주었습니다.

만세! 마지막 수수께끼가 풀렸으니 이제 나만의 펌웨어를 만들어야 했습니다. 다음으로, 저는 강력한 툴킷인 Python에 익숙한 Ilya에게 제 지식을 전수했습니다(그것은 제 머리 속에만 남아 있었습니다).

프로그램 만들기

Ilya Aleshin이보고합니다.

적절한 지시를 받고 나는 매우 “행복”했습니다.

어디서부터 시작해야 할까요? 그렇죠, 처음부터요.  USB 포트에서 덤프를 가져옴.

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

장치가 연결된 포트와 덤프를 저장할 파일을 선택하십시오.

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

여기에는 장치에 명령을 보내는 항목이 있습니다. 하지만 팀은 어떻습니까? 어디서 구할 수 있나요?
프로그램이 시작되면 장비가 자동으로 폴링됩니다(이 내용은 나중에 살펴보겠습니다). 그리고 공식 장비 문서에 있는 훈련용 바코드도 있었습니다. 기본. 이것이 우리 팀입니다.

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

EZConfigScanning을 시작할 때 차단합니다. 주의해야 할 곳은 빨간색으로 표시되어 있습니다.

이 모든 것을 처음으로 보니 마음이 놓였습니다. 다음에 어디를 파야할지 명확하지 않습니다.

약간의 브레인스토밍을 하고 또... 아하! 덤프에서 아웃 -가요 in과 in 그것 아웃.

URB_INTERRUPT가 무엇인지 검색해봤습니다. 이것이 데이터 전송 방법이라는 것을 알았습니다. 그리고 제어, 인터럽트, 등시성, 벌크 등 4가지 방법이 있습니다. 이에 대해 별도로 읽을 수 있습니다.

그리고 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에서 볼 수 있습니다.

엄청난! 시스템 바코드를 XNUMX진수로 변환합니다. 이제 훈련 기능이 준비되었습니다.

펌웨어는 어떻습니까? 모든 것이 똑같은 것 같지만 뉘앙스가 있습니다.

플래싱 프로세스를 완전히 덤프한 후 우리가 다루고 있는 내용을 대략적으로 이해했습니다. 다음은 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 플래싱 모드의 스캐너는 XNUMX진수를 허용하지 않습니다. 따라서 각 줄 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