106. Packet Bytes 구조

Soc Wireshark 패킷 분석 packet wireshark 네트워크 패킷 분석 보안관제

네트워크 · 패킷 분석

목록 보기

106/300

📚 네트워크 · 패킷 분석 › 03. Wireshark 패킷 분석 — 106편
이전 글: 105. Packet Details 구조 · 다음 글: 107. Capture Filter와 Display Filter

1. 개념

Packet Bytes는 선택한 패킷의 원본 바이트를 16진수와 문자로 보여 주는 영역입니다. List·Details가 해석 결과라면 Bytes는 해석 이전의 증거입니다(104. Wireshark 화면 구조와 필드 읽는 법). 이 글은 Bytes 영역을 직접 읽는 방법을 다룹니다.

한 줄은 세 부분으로 나뉩니다.

부분	예	의미
오프셋	`0010`	이 줄 첫 바이트의 위치(16진수). 한 줄 = 16바이트
16진수	`00 3c 1a 2b 40 00 40 06 ...`	바이트 값 16개 (8개씩 두 묶음)
문자	`.<.+@.@..]......`	같은 바이트를 ASCII로 표시. 출력 불가 문자는 `.`

2. 동작 원리

Details에서 필드를 클릭하면 Bytes에서 해당 범위가 강조되고, 반대도 마찬가지입니다. 이 연동은 해석기가 필드마다 시작 위치와 길이를 기록해 두기 때문에 가능합니다(105. Packet Details 구조의 PDML pos, size).

Details 필드 클릭 (ip.ttl)
        ↓  해석기가 기록한 pos=22, size=1
Bytes 영역 0x16 위치 1바이트 강조
        ↓
값 0x40 = 10진수 64 → Details의 "Time to Live: 64"와 일치하는지 검증

하나의 패킷에 바이트 탭이 여러 개 생기기도 합니다. Wireshark가 여러 패킷을 합치거나 변환한 결과를 별도 탭으로 보여 주는 것입니다.

탭 이름 예	생기는 경우	주의점
Frame (N bytes)	항상	실제 캡처된 원본
Reassembled TCP (N bytes)	여러 세그먼트에 걸친 데이터를 합친 경우	여러 프레임의 바이트를 이어 붙인 결과
Reassembled IPv4	IP 단편을 재조립한 경우	조각 일부가 없으면 생성되지 않음
De-chunked / Uncompressed entity body	HTTP chunked·gzip 해제	Wireshark가 변환한 값
Decrypted TLS	키 로그 파일을 설정한 경우	원본은 여전히 암호문

증거로 인용할 때는 Frame 탭의 원본인지, 재조립·변환된 탭인지를 구분해 적습니다.

3. 주요 특징

Ethernet II + IPv4(옵션 없음) + TCP 패킷에서 자주 보는 필드의 바이트 위치입니다. IP 옵션이나 VLAN 태그가 있으면 뒤쪽 위치가 밀립니다.

오프셋(16진)	길이	필드	읽는 법
0x00	6	`eth.dst`	목적지 MAC
0x06	6	`eth.src`	출발지 MAC
0x0c	2	`eth.type`	`08 00` = IPv4
0x0e	1	`ip.version` + `ip.hdr_len`	`45` = 버전 4, 헤더 5×4 = 20바이트
0x16	1	`ip.ttl`	TTL
0x17	1	`ip.proto`	`06` = TCP, `11` = UDP, `01` = ICMP
0x1a / 0x1e	4 / 4	`ip.src` / `ip.dst`	`c0 a8 0a 14` = 192.168.10.20
0x22 / 0x24	2 / 2	`tcp.srcport` / `tcp.dstport`	`00 50` = 80
0x2f	1	`tcp.flags` (하위 8비트)	`02` = SYN, `12` = SYN/ACK

오른쪽 클릭 메뉴로 표시·복사 방식을 바꿀 수 있습니다.

기능	용도
Show bytes as bits	비트 필드(Flag 등)를 직접 확인
Copy → as Hex Dump / as Hex + ASCII	보고서에 원본 첨부
Copy → as Escaped String / as Raw Binary	다른 도구로 재현·검증
File → Export Packet Bytes	선택한 필드(예: 페이로드)만 바이너리 파일로 저장

4. 예시

TCP SYN 한 개(74바이트)의 Bytes 영역 형식 예시(값은 환경마다 다름, 체크섬은 임의 값)입니다.

0000  00 50 56 dd ee ff 00 0c 29 aa bb cc 08 00 45 00   .PV.....).....E.
0010  00 3c 1a 2b 40 00 40 06 8e 5d c0 a8 0a 14 c0 a8   .<.+@.@..]......
0020  0a 1e cc 78 00 50 b6 17 2c 64 00 00 00 00 a0 02   ...x.P..,d......
0030  fa f0 95 3c 00 00 02 04 05 b4 04 02 08 0a 00 0f   ...<............
0040  42 40 00 00 00 00 01 03 03 07                     B@........

위치	바이트	해석
0x10–0x11	`00 3c`	IP 전체 길이 60 = IP 20 + TCP 40
0x14	`40`	DF 비트 설정
0x16 / 0x17	`40` / `06`	TTL 64 / TCP
0x22–0x25	`cc 78 00 50`	52344 → 80
0x2e–0x2f	`a0 02`	TCP 헤더 10×4 = 40바이트, Flag SYN
0x36–	`02 04 05 b4`	TCP 옵션 MSS = 1460

실습 예시 — CLI에서 같은 덤프와 페이로드 바이트를 확인합니다(Rocky/Ubuntu 공통).

# 16진수 덤프 (Bytes 영역과 같은 형식, 재조립 탭도 함께 출력될 수 있음)
tshark -r /tmp/lab.pcapng -x -c 1

# 페이로드 바이트를 필드로 추출 (콜론 없는 16진 문자열)
tshark -r /tmp/lab.pcapng -Y 'tcp.len > 0' -T fields \
  -e frame.number -e frame.len -e frame.cap_len -e tcp.len -e tcp.payload

# 해석기가 모르는 데이터
tshark -r /tmp/lab.pcapng -Y 'data' -T fields -e frame.number -e data.len -e data.data

바이트 단위 조건은 디스플레이 필터의 슬라이스 문법으로 겁니다(필터 문법 전반은 108. Display Filter).

tcp.payload[0:4] == 47:45:54:20      # 페이로드가 "GET "으로 시작
eth.src[0:3] == 00:0c:29             # 출발지 MAC 앞 3바이트
frame[47] == 12                      # 오프셋 47(0x2f) 1바이트가 0x12 (옵션 없는 IPv4·Ethernet 기준)

📷 [실습 화면 삽입 위치] Details에서 Time to Live를 클릭했을 때 Bytes 영역 0x16 위치 1바이트가 강조된 화면

📷 [실습 화면 삽입 위치] HTTP 응답 패킷에서 Bytes 영역 하단에 Frame / Reassembled TCP / Uncompressed 탭이 함께 표시된 화면

5. 보안 관점

해석기가 보여 주지 않는 곳을 확인할 수 있는 유일한 영역입니다. eth.trailer, IP 옵션, TCP 헤더의 예약 비트, 비표준 포트 페이로드에 데이터를 숨기는 기법은 Details에서 눈에 띄지 않다가 Bytes에서 드러날 수 있습니다.
ASCII 열에 MZ(PE 파일 시작), %PDF, PK(ZIP) 같은 파일 시그니처가 보이면 어떤 파일이 전송되었는지 추정할 단서가 됩니다. 단, 추정이므로 파일 추출·해시 확인으로 검증합니다(148편 148. pcap 증거 보존과 해시 검증).
암호화 트래픽의 Bytes는 무작위에 가까운 값만 보입니다. 이 경우 페이로드 내용보다 크기·시간·방향 같은 메타데이터로 분석합니다.
Export Packet Bytes로 꺼낸 페이로드가 악성일 수 있으므로 격리된 환경에서만 다루고 실행하지 않습니다.

6. SOC 관점

상황	Bytes에서 확인할 것	관제 질문
IDS Alert의 content 매칭	Alert가 지목한 문자열·16진 패턴의 실제 위치	룰이 매칭한 위치가 헤더인가 페이로드인가?
Malformed 표시	`frame.cap_len`과 실제 끝 위치	캡처가 잘린 것인가, 형식이 잘못된 것인가?
비표준 포트 통신	페이로드 앞부분의 프로토콜 시그니처	포트가 말하는 서비스와 내용이 일치하는가?
파일 전송 의심	매직 바이트, 재조립 탭	어떤 형식의 파일이 어느 방향으로 갔는가?

IDS 룰의 content·offset이 패킷의 어느 바이트를 보는지는 06. 방화벽 · IDS 기초 영역에서 다룹니다.

오탐 주의: ASCII 열의 우연한 문자열(예: 압축·암호화 데이터 속 MZ 두 글자)은 의미 없는 경우가 많습니다. 시그니처는 위치(파일 시작 부분인지)와 앞뒤 구조까지 함께 보고 판단합니다.

7. 핵심 정리

Bytes 영역은 오프셋·16진수·ASCII 세 부분으로 구성되며, 해석 이전의 원본 증거입니다.
Details 필드 클릭 시 강조되는 범위로 필드의 바이트 위치(pos, size)를 검증합니다.
Reassembled·Uncompressed·Decrypted 탭은 Wireshark가 만든 결과이므로 Frame 원본과 구분해 인용합니다.
주요 필드 오프셋(0x16 TTL, 0x17 Protocol, 0x2f TCP Flag 등)은 옵션·VLAN이 없을 때의 기준입니다.
tshark -x, -e tcp.payload, -e data.data와 슬라이스 필터로 바이트 단위 분석을 CLI에서 재현합니다.

changseop lee

코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다