Protocol 문서가 없을 때 장비 통신 분석하는 방법: Packet Capture·Hex 분석·Command 추론

Protocol 문서가 없을 때 장비 통신 분석하는 방법: Packet Capture·Hex 분석·Command 추론#

1장 문서가 없다고 바로 Protocol을 추측하면 안 된다#

장비 연동 업무를 하다 보면 가장 난감한 상황 중 하나가 있습니다.

장비는 정상적으로 동작하고 있는데 Protocol 문서가 없습니다.

기존 프로그램과 장비는 서로 데이터를 주고받고 있지만 개발자가 받은 것은 다음뿐일 수 있습니다.

장비 본체

기존 Controller

통신 Cable

실행 중인 프로그램

몇 줄의 Log

그리고 Packet을 확인하면 다음과 같은 HEX가 보입니다.

AA 55 01 10 04 00 64 00 C8 7A

처음 보면 아무 의미가 없어 보입니다.

하지만 실제 Protocol도 결국 일정한 규칙을 가지고 있습니다.

예를 들어 위 데이터가 다음처럼 구성되어 있을 수 있습니다.

AA 55 | 01 | 10 | 04 | 00 64 00 C8 | 7A

그리고 분석 결과:

AA 55
Header

01
Device Address

10
Command

04
Data Length

00 64 00 C8
Payload

7A
Checksum

라는 사실을 찾아낼 수 있습니다.

문서 없는 Protocol 분석의 핵심은 HEX를 보고 직감으로 의미를 붙이는 것이 아니라, 반복되는 실제 동작과 Packet의 변화를 비교해 가설을 세우고 검증하는 것입니다.

전체 과정은 다음처럼 볼 수 있습니다.

장비 식별
↓
통신 경로 확인
↓
정상 Traffic 확보
↓
Packet 분리
↓
반복 Pattern 비교
↓
Field 후보 추론
↓
Request·Response 관계 분석
↓
Checksum·CRC 추론
↓
Simulator 검증
↓
Protocol 명세 작성

2장 분석하기 전에 먼저 확보해야 할 정보가 있다#

문서가 없다고 해서 Packet Capture부터 시작하는 것은 좋은 방법이 아닙니다.

먼저 장비 자체 정보를 확보합니다.

장비 식별 정보#

가능하면 다음을 기록합니다.

Manufacturer

Product Name

Model

Hardware Revision

Firmware Version

Serial Number

같은 모델이라도 Firmware가 다르면 Packet 구조나 Command가 달라질 수 있습니다.

통신 Interface#

다음도 확인합니다.

RS-232

RS-422

RS-485

Ethernet

CAN

USB

Wireless

Protocol을 분석하려면 먼저 데이터가 어떤 경로를 통해 전달되는지 알아야 합니다.

기존 연결 구조#

예를 들어:

Sensor
↓
RS-485
↓
Controller
↓
Ethernet
↓
Server

인지:

Device
↓
RS-232
↓
PC Application

인지 확인합니다.

분석 지점을 잘못 선택하면 실제로 원하는 Protocol이 아니라 Gateway가 변환한 데이터를 분석하게 될 수도 있습니다.

3장 가장 가치 있는 데이터는 정상적으로 동작하는 Traffic이다#

Protocol 문서가 없다면 현재 정상적으로 동작하는 시스템 자체가 가장 중요한 참고 자료가 됩니다.

예를 들어 기존 프로그램에서 다음 작업이 정상적으로 수행된다고 하겠습니다.

장비 상태 조회

Sensor 값 읽기

Printer 상태 확인

Relay ON

Relay OFF

각 동작을 수행하면서 송수신 데이터를 기록합니다.

예:

상태 조회
TX  AA 55 01 10 00 7B
RX  AA 55 01 90 01 00 2C

Relay ON
TX  AA 55 01 20 01 01 91
RX  AA 55 01 A0 01 00 4C

Relay OFF
TX  AA 55 01 20 01 00 90
RX  AA 55 01 A0 01 00 4C

이런 데이터가 여러 개 쌓이면 비교를 통해 구조를 추론할 수 있습니다.

특히 중요한 것은 한 번의 Capture가 아닙니다.

동일 동작을 여러 번 반복합니다.

Status Read × 20

Sensor Read × 20

ON × 20

OFF × 20

그래야:

항상 같은 Byte

실행할 때마다 변하는 Byte

상태에 따라 변하는 Byte

를 구분할 수 있습니다.

4장 Packet Capture는 통신 방식에 따라 방법이 다르다#

Packet Capture라는 말을 흔히 Wireshark와 연결하지만 모든 장비 통신을 Wireshark로 볼 수 있는 것은 아닙니다.

Ethernet#

TCP·UDP 기반 통신은 다음 방식으로 Capture할 수 있습니다.

Wireshark

tcpdump

Switch Port Mirroring

Network TAP

구조:

Device
       ┌── Analyzer
       │
Switch ├── Server
       │
       └── Other Devices

Managed Switch의 Mirror Port를 이용하면 기존 통신에 개입하지 않고 Traffic을 관찰하기 좋습니다.

RS-232#

RS-232는 Point-to-Point 방식이므로 Serial Analyzer나 중간 Capture 구조를 사용할 수 있습니다.

Device
↓
Serial Analyzer
↓
Controller

또는 기존 Application 자체의 TX·RX Log를 활용할 수도 있습니다.

RS-485#

RS-485는 Multi-drop Bus가 될 수 있으므로 분석 시 특히 조심해야 합니다.

Controller
│
├─ Device 01
├─ Device 02
├─ Device 03
└─ Analyzer

잘못된 장비를 연결하면 Bus의 전기적 특성에 영향을 줄 수 있습니다.

가능하면 수동 수신 위주의 Analyzer를 사용하고 기존 Bus 동작에 영향을 최소화해야 합니다.

5장 HEX를 보면 먼저 고정 영역과 변화 영역을 나눈다#

다음 Packet을 여러 번 Capture했다고 하겠습니다.

AA 55 01 10 02 00 64 31
AA 55 01 10 02 00 65 32
AA 55 01 10 02 00 66 33
AA 55 01 10 02 00 67 34

먼저 열을 맞춥니다.

AA 55 01 10 02 00 64 31
AA 55 01 10 02 00 65 32
AA 55 01 10 02 00 66 33
AA 55 01 10 02 00 67 34
─────────────────────
고정        변화 변화

앞부분:

AA 55

가 계속 같다면 Header 후보가 될 수 있습니다.

01

이 장비마다 달라진다면 Address일 가능성을 생각할 수 있습니다.

10

이 동작 종류에 따라 달라진다면 Command 후보입니다.

02

뒤의 Payload가 항상 2 Byte라면 Length 후보가 될 수 있습니다.

마지막 Byte가 앞의 데이터 변화와 함께 계속 바뀐다면:

Checksum

CRC

LRC

Sequence

등을 의심할 수 있습니다.

중요한 점은 이것들이 아직 후보라는 것입니다.

한두 개 Packet만 보고 확정해서는 안 됩니다.

6장 한 번에 하나의 조건만 바꿔야 Command를 찾을 수 있다#

문서 없는 Protocol 분석에서 매우 중요한 방법이 있습니다.

한 번에 하나의 변수만 변경합니다.

예를 들어 Sensor 설정값을 분석한다고 하겠습니다.

다음 조건으로 Capture합니다.

Test 1
Value = 10

Test 2
Value = 11

Test 3
Value = 12

Packet:

AA 55 01 30 02 00 0A 92
AA 55 01 30 02 00 0B 93
AA 55 01 30 02 00 0C 94

여기에서:

00 0A

00 0B

00 0C

가 각각:

10

11

12

와 연결될 가능성이 높아집니다.

반대로 한 번에 여러 조건을 바꾸면:

Address 변경
+
설정값 변경
+
동작 Mode 변경

어떤 Byte가 무엇 때문에 변했는지 알기 어렵습니다.

분석 실험은 과학 실험과 비슷합니다.

하나 변경
↓
Capture
↓
차이 확인

을 반복합니다.

7장 Command는 동작과 Packet을 시간으로 연결해서 찾는다#

Command를 추론하려면 Packet만 보는 것으로 부족합니다.

장비에서 실제로 어떤 일이 발생했는지 함께 기록합니다.

예:

14:20:10.000
Button 클릭

14:20:10.015
TX
AA 55 01 21 00 81

14:20:10.031
RX
AA 55 01 A1 01 00 34

14:20:10.120
Motor Start

이런 기록이 있다면:

0x21

이 Motor 동작 요청과 관련된 Command일 가능성이 높아집니다.

더 확실하게 하려면 같은 동작을 여러 번 반복합니다.

OPEN

OPEN

OPEN

OPEN

그리고 다른 동작도 비교합니다.

CLOSE

CLOSE

CLOSE

예:

OPEN
AA 55 01 21 00 81

CLOSE
AA 55 01 22 00 82

처럼 특정 Byte만 바뀐다면:

21
OPEN 후보

22
CLOSE 후보

라고 추론할 수 있습니다.

하지만 처음부터:

0x21 = OPEN

이라고 확정하지 말고 반복 검증해야 합니다.

8장 Request와 Response를 묶으면 Protocol 구조가 빨리 보인다#

다음과 같은 Traffic이 있다고 하겠습니다.

TX
AA 55 01 10 00 71

RX
AA 55 01 90 02 00 64 D2

이 패턴이 반복된다면:

Request Command
10

Response Command
90

사이에 관계가 있을 수 있습니다.

다른 Command를 비교합니다.

TX Command
11

RX Command
91

TX Command
12

RX Command
92

그렇다면:

Response Command
=
Request Command + 0x80

이라는 가설을 세울 수 있습니다.

이처럼 Protocol 분석은 개별 Packet보다 Packet 사이 관계가 중요합니다.

Response 시간도 기록한다#

예:

Request
14:20:10.000

Response
14:20:10.035

이면 약 35ms입니다.

여러 번 측정합니다.

32ms
34ms
36ms
31ms
220ms

대부분 30~40ms인데 가끔 220ms가 나온다면 장비 내부 처리나 다른 조건이 있을 수 있습니다.

이 정보는 나중에 Timeout 설정의 근거가 됩니다.

9장 ASCII인지 Binary인지 먼저 판단한다#

Capture 데이터에서 다음 값이 보인다고 하겠습니다.

47 45 54 2C 53 54 41 54 55 53 0D 0A

ASCII로 변환하면:

GET,STATUS\r\n

입니다.

이런 경우 Text 기반 Protocol일 가능성이 높습니다.

반대로:

AA 55 01 82 04 C7 21 00 FF 3A

처럼 보인다면 Binary Protocol일 가능성이 높습니다.

ASCII Protocol 분석#

찾아야 할 요소:

Command 이름

Separator

Field 순서

숫자 표기

CR

LF

Encoding

예:

GET,STATUS,01\r\n

Binary Protocol 분석#

찾아야 할 요소:

Header

Address

Command

Length

Data Type

Byte Order

Flags

Checksum

CRC

Binary 데이터 안에도 ASCII 문자열이 일부 포함될 수 있으므로 두 방식이 완전히 배타적인 것은 아닙니다.

10장 Length Field는 여러 Packet을 비교해 찾는다#

가변 길이 Packet을 Capture했다고 하겠습니다.

AA 55 01 10 02 11 22 XX

AA 55 01 10 04 11 22 33 44 XX

AA 55 01 10 06 11 22 33 44 55 66 XX

다섯 번째 Byte가:

02

04

06

으로 변하고 뒤의 Data 길이와 정확히 일치한다면:

Length

일 가능성이 매우 높습니다.

하지만 Length가 항상 Byte 수를 의미하는 것은 아닙니다.

다음도 가능합니다.

전체 Frame Length

Payload Length

Word Count

Character Count

Register Count

따라서 실제 Frame 크기를 여러 개 비교해야 합니다.

Length가 없을 수도 있다#

Frame 경계를 다른 방식으로 찾는 Protocol도 있습니다.

예:

STX
...
ETX

또는:

CR LF

또는 고정 길이:

항상 32 Byte

일 수도 있습니다.

11장 Sequence Number와 Counter는 반복 Packet에서 드러난다#

다음처럼 동일 명령을 반복했는데 한 Byte만 계속 증가한다고 하겠습니다.

AA 55 01 10 01 ...
AA 55 01 10 02 ...
AA 55 01 10 03 ...
AA 55 01 10 04 ...

다음 후보를 생각할 수 있습니다.

Sequence Number

Packet Counter

Transaction ID 일부

이 값을 찾으면 Request와 Response를 연결하는 데 도움이 됩니다.

예:

Request
Sequence 23

Response
Sequence 23

이라면 같은 Transaction임을 확인할 수 있습니다.

다만 Counter가:

FF
↓
00

처럼 순환할 수도 있으므로 충분히 오래 Capture하는 것이 좋습니다.

12장 상태값은 Bit 단위로 바뀔 수 있다#

Packet:

Status
05

가 있다고 하겠습니다.

상태를 바꿨더니:

05
↓
07

로 변했습니다.

Binary로 보면:

05
0000 0101

07
0000 0111

차이는:

Bit 1

입니다.

이때 특정 Sensor나 상태를 ON/OFF하면서 값을 비교하면 각 Bit의 역할을 추론할 수 있습니다.

예:

상태	값
기본	0x00
Sensor A ON	0x01
Sensor B ON	0x02
Sensor A+B ON	0x03

이 결과가 반복된다면:

Bit 0
Sensor A

Bit 1
Sensor B

라는 강한 근거가 됩니다.

XOR 비교도 유용합니다.

05 XOR 07
=
02

즉 두 상태의 차이가 0x02라는 것을 바로 확인할 수 있습니다.

13장 Checksum과 CRC는 마지막에 분석하는 편이 좋다#

문서가 없는 Packet에서 마지막 1~2 Byte가 계속 변하면 Checksum이나 CRC를 의심하게 됩니다.

하지만 처음부터 모든 CRC Algorithm을 무작정 대입하는 것은 효율적이지 않습니다.

먼저 다음을 확인합니다.

검증값 크기

Packet 끝에 위치하는가?

Data 변경 시 같이 변하는가?

Sequence 변경 시 변하는가?

Header도 계산에 포함되는가?

그다음 간단한 방식부터 확인합니다.

SUM

XOR

LRC

Two's Complement

일치하지 않으면 CRC 계열을 검토합니다.

CRC의 경우 다음 Parameter가 필요할 수 있습니다.

Polynomial

Initial Value

RefIn

RefOut

XorOut

Output Byte Order

또한 어느 영역을 계산하는지도 중요합니다.

예:

AA 55 01 10 02 00 64 XX XX

CRC 대상이:

01 10 02 00 64

일 수도 있고:

AA 55 01 10 02 00 64

일 수도 있습니다.

검증값을 바꿔가며 실장비에 무작정 보내지 않는다#

Checksum·CRC를 잘못 추론한 상태에서 임의 Frame을 실장비에 반복 전송하는 것은 피합니다.

가능하면 Capture 데이터와 Offline 계산을 통해 먼저 가설을 검증합니다.

14장 TCP Packet과 Application Message를 혼동하지 않는다#

Ethernet 장비 분석에서 매우 흔한 실수입니다.

Wireshark에서 TCP Packet이 다음처럼 보였다고 하겠습니다.

TCP Packet 1
AA 55 01

TCP Packet 2
10 04 00 64

TCP Packet 3
00 C8 7A

이것이 Protocol Frame 세 개라는 뜻은 아닙니다.

실제 Application Message는:

AA 55 01 10 04 00 64 00 C8 7A

하나일 수 있습니다.

반대로 하나의 TCP Segment 안에 Application Frame 두 개가 들어갈 수도 있습니다.

Frame A | Frame B

TCP는 Byte Stream이기 때문입니다.

따라서 다음을 분리해야 합니다.

Ethernet Frame

IP Packet

TCP Segment

Application Protocol Frame

분석 대상이 장비 Protocol이라면 최종적으로 TCP Payload를 다시 Application Frame 규칙에 따라 조립해야 합니다.

15장 추론한 Command를 그대로 재전송하면 위험할 수 있다#

Capture에서 다음 Packet이 Motor를 움직이기 직전에 발생했다고 하겠습니다.

AA 55 01 21 00 81

0x21이 Motor Start Command일 가능성이 있다고 추론할 수 있습니다.

하지만 이 Packet을 그대로 실장비에 Replay하는 것은 위험할 수 있습니다.

왜냐하면 다음과 같은 숨은 조건이 존재할 수 있기 때문입니다.

현재 Mode

Safety Sensor

Session 상태

Sequence Number

Authentication

Interlock

Timestamp

일회용 Token

또한 Capture Packet 자체가:

Motor Start

가 아니라:

Motor 상태 확인

일 수도 있습니다.

시간적으로 가까웠다는 사실만으로 인과관계를 확정해서는 안 됩니다.

먼저 Simulator에서 검증한다#

분석 결과로 다음과 같은 가상 장비를 만들 수 있습니다.

Request
↓
Parser
↓
Command 해석
↓
가상 상태 변경
↓
Response

Simulator에서:

Packet Parsing

Checksum

Command Mapping

Sequence

Timeout

을 먼저 검증합니다.

16장 분석 결과는 가설표와 Field Map으로 관리한다#

문서가 없는 Protocol에서는 특히 확정 사실과 추정을 분리해야 합니다.

예:

Offset	크기	추정 역할	근거	상태
0	2	Header	모든 Packet AA55	확정
2	1	Address	장비별로 값 변경	강한 추정
3	1	Command	동작별 값 변경	강한 추정
4	1	Length	Payload 길이와 일치	확정
5~N	N	Data	동작별 변경	분석 중
Last	1	Checksum	Data 변경과 함께 변경	추정

이 방식은 매우 중요합니다.

분석자가:

Byte 3은 Command다.

라고 메모해두면 나중에는 사실처럼 받아들여질 수 있습니다.

대신:

Offset 3
Command 후보

근거
OPEN과 CLOSE에서 값이 달라짐

신뢰도
높음

추가 검증
STATUS 명령과 비교 필요

처럼 기록합니다.

Protocol 분석 문서에 남길 내용#

최종적으로 다음을 작성하는 것이 좋습니다.

Transport

Serial·Network 설정

Frame Format

Field Map

Data Type

Byte Order

Command Table

Response Table

Error Code

Checksum·CRC

Timing

Sequence

Timeout

Retry

미확인 Field

Firmware Version

이 문서가 다음 단계인 Driver 개발의 기준이 됩니다.

17장 분석을 더 빠르게 만드는 실전 방법#

반복 Capture를 자동화한다#

동일 Command를 50번 Capture하면 손으로 비교하기 어렵습니다.

Script를 이용해 각 Offset의 값 분포를 계산하면 도움이 됩니다.

예:

Offset 0
AA 100%

Offset 1
55 100%

Offset 2
01 100%

Offset 3
10 100%

Offset 4
00~FF 변화

이런 결과를 보면 고정 Field와 변화 Field를 빠르게 구분할 수 있습니다.

같은 종류 Packet끼리 묶는다#

Length나 Header가 같은 Packet을 Grouping하면 분석이 쉬워집니다.

Type A

Type B

Type C

그리고 각 Group 내부에서 변화를 비교합니다.

물리 상태 로그와 시간을 맞춘다#

가능하면 다음 데이터를 같은 시간 기준으로 기록합니다.

Packet Capture

Application Log

Sensor 상태

장비 화면

운영자 동작

예:

10:30:01.100
Button OPEN 클릭

10:30:01.107
TX Packet

10:30:01.135
RX ACK

10:30:01.180
Motor Start

10:30:02.320
Open Sensor ON

이렇게 하면 Protocol의 의미를 훨씬 정확하게 추론할 수 있습니다.

18장 자기 점검#

Protocol 문서가 없을 때 가장 먼저 해야 할 일은 무엇인가#

기존 정상 시스템의 구조와 장비 Model·Firmware·통신 Interface를 확인하고 안전하게 Traffic을 관찰할 수 있는 환경을 만드는 것입니다.

같은 Packet을 한 번만 Capture해도 분석할 수 있는가#

일부 정보는 볼 수 있지만 신뢰성이 낮습니다. 동일 동작과 서로 다른 상태를 반복 Capture해야 고정 Field와 변화 Field를 구분할 수 있습니다.

특정 Byte가 동작 직전에 바뀌었다면 바로 Command라고 확정해도 되는가#

아닙니다. Sequence·Timestamp·Status 등이 우연히 함께 바뀌었을 가능성이 있으므로 반복 실험과 다른 동작 비교가 필요합니다.

마지막 두 Byte가 계속 변하면 CRC인가#

가능성은 있지만 바로 확정할 수 없습니다. Checksum·Counter·Timestamp 일부 등 다른 Field일 수도 있으므로 계산과 반복 비교가 필요합니다.

TCP Capture 한 개가 장비 Protocol Packet 하나인가#

아닙니다. TCP Segment 경계와 Application Message 경계는 다를 수 있으므로 Protocol의 Length·Header·Delimiter 등을 이용해 다시 Frame을 구성해야 합니다.

19장 이 글을 마치며#

Protocol 문서가 없는 장비를 분석하는 전체 흐름을 정리하면 다음과 같습니다.

장비 Model·Firmware 확인
↓
통신 Interface 확인
↓
기존 정상 통신 구조 확인
↓
안전한 Capture 환경 구성
↓
정상 Traffic 반복 수집
↓
HEX 정렬
↓
고정·변화 Field 분리
↓
동작별 Packet 비교
↓
Request·Response 연결
↓
Length·Sequence 추론
↓
Data Type·Bit Field 분석
↓
Checksum·CRC 검증
↓
Timing 분석
↓
Simulator 검증
↓
Field Map 작성
↓
Protocol 명세 작성

특히 다음 원칙을 기억하면 됩니다.

문서가 없다고 Packet의 의미를 감으로 정하지 말고 동일 동작을 반복해서 Capture하고 변화가 하나씩 발생하도록 실험해야 합니다.

Header·Address·Command·Length·Sequence·Payload·Checksum 후보를 분리한 뒤 각 가설마다 근거와 신뢰도를 기록해야 합니다.

실제 장비의 물리 상태와 Packet 발생 시간을 함께 기록해야 단순한 상관관계를 실제 Command나 Status로 잘못 판단하는 일을 줄일 수 있습니다.

TCP Segment와 Application Packet은 다르며 Serial과 TCP 모두 수신한 Byte Stream에서 Protocol 규칙에 따라 Frame을 다시 구성해야 합니다.

추론한 Packet을 실장비에 Replay하기 전에 Simulator에서 Parser·Checksum·Command Mapping·Timeout을 검증해야 합니다.

분석 결과는 개인의 기억이나 주석으로 남기지 말고 Field Map·Command Table·Error Code·Timing·미확인 Field가 포함된 Protocol 명세로 문서화해야 합니다.

결국 Protocol Reverse Engineering은 HEX 값을 찍어보며 정답을 맞히는 작업이 아닙니다.

관찰
↓
비교
↓
가설
↓
검증
↓
반복
↓
문서화

라는 과정입니다.

처음 보는 장비에서:

AA 55 01 10 04 00 64 00 C8 7A

라는 한 줄을 발견했을 때도 바로 답을 내리지 않습니다.

먼저 질문합니다.

어떤 Byte가 항상 같은가?

어떤 Byte가 장비마다 달라지는가?

어떤 Byte가 동작에 따라 달라지는가?

길이를 나타내는 값이 있는가?

Request와 Response는 어떻게 연결되는가?

상태 변화와 동시에 변하는 Bit는 무엇인가?

마지막 값은 무엇을 검증하는가?

이 가설은 몇 번 반복해도 성립하는가?

이 질문을 체계적으로 반복할 수 있다면 제조사 문서가 부족한 PLC, Sensor, 계측기, Reader, Printer, Controller, Gateway 등도 훨씬 안전하고 재현 가능한 방법으로 분석할 수 있습니다.