문서 없는 장비 프로토콜 읽기

장비와 통신하는 프로그램을 만들어야 했는데 프로토콜 문서가 없었다. 기존에 동작하는 프로그램은 있고 소스는 없어서 통신을 들여다보는 것부터 시작했다.

Table of contents

오가는 것을 잡았다

기존 프로그램을 돌리면서 패킷을 캡처했다.

tcpdump -i eth0 -w capture.pcap host 장비주소

tcpdump 로 잡으면 무엇이 오가는지 그대로 남는다. 한 번 잡아 보니 16진수만 잔뜩 나와서 어디가 무엇인지 구분이 안 됐고 ASCII 로 읽히는 구간도 없었다.

그래서 몇 가지 동작을 시켜 보면서 각각 따로 캡처했다.

연결만 하기
상태 조회
값 변경
연결 끊기

동작마다 따로 캡처한 것이 중요했다. 섞여 있으면 어느 것이 어느 동작인지 모른다.

반복되는 부분을 찾았다

pcap 파일을 열어 바이트를 봤다.

02 00 10 A1 03 ...
02 00 10 A2 03 ...
02 00 14 B1 03 ...

앞뒤가 반복되고 02 로 시작해서 03 으로 끝난다. 02 와 03 은 대개 시작과 끝 표시이고 그 사이가 내용이다.

세 번째 바이트가 길이로 보여서 실제 길이와 맞춰 보니 맞았고 그렇게 프레임 구조가 잡혔다.

[시작] [예약] [길이] [명령] [데이터...] [끝]

여러 번 반복해서 잡으면 매번 같은 자리가 프레임의 고정 부분이었다.

값을 바꿔 보며 확인했다

추측한 프레임 구조가 맞는지 확인하려고 바이트를 하나씩 바꿔 보며 반응을 봤다. 길이 바이트를 틀리게 보내면 거부되고 명령 바이트를 바꾸면 다른 응답이 오며 데이터를 늘리면 길이 값도 늘어야 했다.

추측하고 실험하고 확인하는 것을 반복했다. 여러 자리를 한꺼번에 바꾸면 어느 것 때문인지 안 갈리므로 하나씩 바꾸는 것이 느려 보여도 결과적으로 빨랐다.

두 바이트가 한 숫자로 묶이는 자리에서는 Big-Endian 인지 Little-Endian 인지도 같이 확인했다. 값을 1에서 256으로 올려 보면 앞 바이트가 움직이는지 뒤가 움직이는지로 갈린다.

이것이 시간이 걸렸다. 다만 문서가 있어도 실제와 다를 수 있으니 어차피 해야 하는 일이기도 하다.

규칙이 안 보이던 바이트

한동안 못 풀던 것이 있었다. 03 앞에 값이 하나 더 있는데 규칙이 안 보였다.

체크섬이었다. 여러 프레임의 그 값과 나머지 바이트를 놓고 단순 합과 XOR 과 CRC-8 을 비롯해 몇 가지를 계산해 봤다.

XOR 이었고 시작과 끝을 뺀 나머지를 전부 XOR 한 값이었다. XOR 을 못 찾았으면 우리가 보내는 프레임이 전부 거부됐을 것이다.

한 바이트짜리라 CRC-8 이든 무엇이든 256번에 한 번은 우연히 맞는다. 그래서 계산 결과가 몇 개 맞았다고 확정하지 않고 값을 바꿔 가며 여러 번 맞는지를 봤다.

XOR 이나 단순 합은 바이트 순서가 바뀌어도 같은 값이 나온다는 것도 확인에 썼다. 순서를 뒤집었을 때 값이 달라지면 CRC-16 계열이라는 뜻이고 안 달라지면 겹치기만 하는 방식이다.

검증 — 문서와 관측 범위

알아낸 프레임 구조를 문서로 적었다.

[프로토콜 구조] — 캡처 분석으로 추론, 2016-06

프레임: 02 | 예약(00) | 길이 | 명령 | 데이터 | 체크섬 | 03
체크섬: 길이~데이터를 XOR

명령
  10  상태 조회
  14  값 설정
  ...

[확인 안 된 것]
  예약 바이트의 용도 (항상 00이었음)
  명령 20 이상의 응답 형식 (관측 못 함)

확인 안 된 것을 적은 것이 중요했다. 내가 관측한 범위 밖은 모르고 그것을 안 적으면 다음 사람이 이 문서를 완전한 명세로 오해한다.

이 문서는 tcpdump 로 잡은 동작의 범위에서만 유효하다. 그 장비가 다른 명령도 받을 수 있고 오류 상황에서 다른 응답을 줄 수도 있는데 관측 못 했으니 모른다.

그래서 문서 첫 줄에 적었다.

이 문서는 캡처 분석으로 추론한 것이며 공식 명세가 아니다. 관측한 동작(연결·조회·설정·해제) 범위에서만 확인됐다.

추론을 명세처럼 쓰지 않는다. 추측을 명세처럼 적어 두면 그것을 근거로 만든 것이 나중에 깨진다.

정리

• 문서가 없으면 오가는 통신을 tcpdump 로 잡는 것부터 시작한다
• 섞어서 잡으면 구분이 안 되므로 동작마다 따로 잡는다
• 여러 번 반복하면 매번 같은 자리가 고정 부분이다
• 반복되는 앞뒤가 시작과 끝 표시이고 길이가 대개 그다음에 보인다
• 구조를 추측하면 값을 하나씩 바꿔 보며 확인한다
• 여러 자리를 한꺼번에 바꾸면 원인이 안 갈린다
• 규칙이 안 보이는 바이트는 체크섬을 의심하고 몇 가지를 대입한다
• 한 바이트짜리는 우연히 맞을 수 있어 여러 번 확인한다
• 순서를 바꿔 보면 겹치기만 하는 방식인지 CRC 계열인지 갈린다
• 문서에 확인된 것과 확인 안 된 것을 갈라 적는다
• 관측 범위를 명시하고 추론을 명세처럼 쓰지 않는다