wireshark를 사용하지 않고 어떻게 수동으로 패킷을 올바르게 읽고 해석 할 수 있습니까?
이제 이더넷 헤더에서 목적지 MAC 주소가 5 번째 바이트에 있어야한다는 것을 알고 있습니다 (비트 / 바이트 변환 후). 그래서이 데이터에서 나는 그것이 4a 이후가 될 것이라고 생각했습니다. 그러나 실제로는 00:17:f2:d0:4c:82입니다.
IP 소스 대상도 마찬가지입니다. 예를 들어 소스는 13-16 바이트 여야합니다. 판독 값은 0800 이후 여야한다고 생각합니다.하지만 실제로는 0a 32 e7 85에 있지만 이유를 알 수 없습니다. 이 데이터를 올바르게 해석하는 방법이 혼란 스럽거나 일반적인 헤더 구조를 잘못 이해하고있을 수 있습니다.
https://ntquan87.wordpress.com/2015/08/17/reading-packet-hex-dumps-manually-no-wireshark/
답변
내 생각에는 현재보고있는 것이 레벨 2 이더넷 프레임이므로 서문이 없습니다. 또한 이더넷 체크섬이 누락 된 것 같습니다. 이 경우 모든 것이 정렬 된 것처럼 보입니다 (이더넷 프레임 내부의 패킷 유형, IPv4 버전, IPv4 패킷 길이, 패킷 유형, 즉 IP 패킷 내부의 TCP 등). 그런 다음 그림과 같이 패킷을 읽습니다.
TCP 페이로드는
474554202f20485454502f312e300d0a 557365722d4167656e743a2057676574 2f312e31312e340d0a4163636570743a 202a2f2a0d0a486f73743a207777772e 696574662e6f72670d0a436f6e6e6563 74696f6e3a204b6565702d416c697665 0d0a0d0a 이며 다음으로 디코딩됩니다.
GET / HTTP/1.0 User-Agent: Wget/1.11.4 Accept: */* Host: www.ietf.org Connection: Keep-Alive 이는 목적지 포트가 80이라는 사실과 일관됩니다.
코멘트
- 실수로 소스와 목적지의 레이블을 바꿨 기 때문입니다 .. . 죄송합니다. 사진을 업데이트했습니다. IPv4 헤더에 IPv4 패킷의 길이가 152 바이트라고 표시되어 있으므로 체크섬이 없습니다. 즉, 데이터 끝에서 정확히 끝납니다. 마지막 바이트가 모두 디코딩 된 버전별로 페이로드의 일부입니다 ('는 HTTP GET 요청 임).
- 나는 ' 이 번호를 가져 오는 위치를 ' 알 수 있습니다. 이더넷 페이로드 (IPv4 패킷)는 15 번째 바이트부터 시작합니다. 참조 : ko .wikipedia.org / wiki / Ethernet_frame . I Pv4 패킷의 길이는 3 번째 및 4 번째 바이트입니다. 참조 : en.wikipedia.org/wiki/IPv4#Packet_structure . 따라서 길이는 0x0098 (16 진수), 즉 152 바이트입니다. 이것은 전체 IPv4 패킷의 길이입니다 (그림에서 파란색 테두리가있는 상자).
- ' 번호를 가져 오는 위치를 이해했습니다. 게시 한 다이어그램을 잘못된 방식으로 읽고 있습니다! 이더넷 대상 주소의 길이가 32 비트가 아닙니다! ' 48 비트 = 6 바이트 … 다이어그램에서 " 대상 MAC 주소 " 필드는 두 번째 줄의 끝에서 끝나지 않지만 세 번째 줄에서도 계속됩니다 (" | " 구분 기호). 소스 주소도 마찬가지입니다 (세 번째 줄의 빈 공간에서 시작하여 네 번째 줄에서 끝남). 덜 혼란스러운 다이어그램을 사용하는 것이 좋습니다 …
- 답변에서 소스 및 대상 MAC 주소가 바뀌는 이유를 ' 잘 모르겠습니다. 누가 대답을했는지에 대한 좋은 질문처럼 들립니다. IP 패킷과 관련하여 ' IP 헤더 체크섬을 제거하려는 이유를 알 수 없습니다. 다이어그램에서 " 소스 주소 " 필드 앞의 IP 패킷에는 정확히 12 바이트가 있습니다. 이것은 내 그림과 정확히 일치합니다.
- 애플리케이션 레이어 프로토콜은 HTTP 입니다. 플래그는 바이너리로 000011000으로 설정됩니다. 플래그 목록 을 살펴보면 ' 5 번째 및 6 번째 플래그 (세트에 해당하는 비트)는 ACK 및 PSH입니다.