아쉽게도 첫번째 콘테스트에 정답을 제출해 주신 분들은 없었다. 일단, 풀이과정을
설명해 보도록 하겠다. 문제였던 다음의 HEX 코드 값을 패킷 파일로 변경하면
문제의 반은 해결한 것이다. 일단, 다음 패킷내용을 challenge.txt 로 저장해 보자.
00 05 b5 02 02 02 01 01 01 01 01 01 08 00 45 00
00 79 12 34 00 00 ff 06 a3 45 01 01 01 01 c0 a8
03 02 04 d2 16 2e 00 00 00 00 00 00 00 00 50 00
20 00 65 53 00 00 55 47 46 6a 61 32 56 30 53 57
35 7a 61 57 52 6c 4c 6d 4e 76 62 53 41 78 63 33
51 67 55 47 46 6a 61 32 56 30 49 45 4e 6f 59 57
78 73 5a 57 35 6e 5a 53 42 54 62 32 78 32 5a 57
51 73 49 45 4e 76 62 6d 64 79 59 58 52 31 62 47
46 30 61 57 39 75 0a
일전에 text2pcap 을 통해 변환하는 방법에 대해서 설명하였지만, OD 의 특정 포맷에
맞춰서 해야 하다 보니 약간 귀챦은 부분이 있다. 하지만, 생각을 좀더 달리하면 한
라인으로 해당 HEX 값을 나열하는 방법도 있다. 이럴때 쉽게 사용해 볼 수 있는 방법이
tr 을 통해 \n 을 제거해 주고, sed 를 이용해 제일 처음에 00000 를 넣어 주어서 text2pcap
이 인지할 수 있는 포맷형태로 만든다.
$ cat challenge.txt | tr '\n' ' ' | sed 's/^/00000 /' | text2pcap - result.pcap
Input from: Standard input
Output to: result.pcap
Wrote packet of 175 bytes at 0
Read 1 potential packet, wrote 1 packet
위 명령을 통해 result.pcap 으로 쉽게 패킷 파일이 만들어졌다. 위 팁은 가끔 HEX 형태의
아스키 형태만 가지고 분석을 해야 하는 경우 유용하게 사용할 수 있을 것이다.
result.pcap 을 tcpdump 를 통해 읽어 보자. 출발지 IP 1.1.1.1 에서 목적지 IP
192.168.3.2 로 TCP/5678 번에 데이터를 전송하였다.
# tcpdump -XX -r result.pcap
reading from file result.pcap, link-type EN10MB (Ethernet)
10:22:41.000000 IP 1.1.1.1.1234 > 192.168.3.2.5678: . 0:81(81) win 8192
0x0000: 0005 b502 0202 0101 0101 0101 0800 4500 ..............E.
0x0010: 0079 1234 0000 ff06 a345 0101 0101 c0a8 .y.4.....E......
0x0020: 0302 04d2 162e 0000 0000 0000 0000 5000 ..............P.
0x0030: 2000 6553 0000 5547 466a 6132 5630 5357 ..eS..UGFja2V0SW
0x0040: 357a 6157 526c 4c6d 4e76 6253 4178 6333 5zaWRlLmNvbSAxc3
0x0050: 5167 5547 466a 6132 5630 4945 4e6f 5957 QgUGFja2V0IENoYW
0x0060: 7873 5a57 356e 5a53 4254 6232 7832 5a57 xsZW5nZSBTb2x2ZW
0x0070: 5173 4945 4e76 626d 6479 5958 5231 6247 QsIENvbmdyYXR1bG
0x0080: 4630 6157 3975 0a F0aW9u.
tshark 를 통해서도 한번 형태를 자세히 들여다 보자
# tshark -V -r result.pcap
Frame 1 (135 bytes on wire, 135 bytes captured)
Arrival Time: Feb 8, 2010 10:22:41.000000000
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 135 bytes
Capture Length: 135 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:data]
Ethernet II, Src: Private_01:01:01 (01:01:01:01:01:01), Dst: Broadcom_02:02:02 (00:05:b5:02:02:02)
Destination: Broadcom_02:02:02 (00:05:b5:02:02:02)
Address: Broadcom_02:02:02 (00:05:b5:02:02:02)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Private_01:01:01 (01:01:01:01:01:01)
Address: Private_01:01:01 (01:01:01:01:01:01)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 1.1.1.1 (1.1.1.1), Dst: 192.168.3.2 (192.168.3.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 121
Identification: 0x1234 (4660)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: TCP (0x06)
Header checksum: 0xa345 [incorrect, should be 0xe39e]
[Good: False]
[Bad : True]
Source: 1.1.1.1 (1.1.1.1)
Destination: 192.168.3.2 (192.168.3.2)
Transmission Control Protocol, Src Port: search-agent (1234), Dst Port: rrac (5678), Seq: 1, Len: 81
Source port: search-agent (1234)
Destination port: rrac (5678)
Sequence number: 1 (relative sequence number)
[Next sequence number: 82 (relative sequence number)]
Header length: 20 bytes
Flags: 0x00 ()
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...0 .... = Acknowledgment: Not set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 8192
Checksum: 0x6553 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Data (81 bytes)
0000 55 47 46 6a 61 32 56 30 53 57 35 7a 61 57 52 6c UGFja2V0SW5zaWRl
0010 4c 6d 4e 76 62 53 41 78 63 33 51 67 55 47 46 6a LmNvbSAxc3QgUGFj
0020 61 32 56 30 49 45 4e 6f 59 57 78 73 5a 57 35 6e a2V0IENoYWxsZW5n
0030 5a 53 42 54 62 32 78 32 5a 57 51 73 49 45 4e 76 ZSBTb2x2ZWQsIENv
0040 62 6d 64 79 59 58 52 31 62 47 46 30 61 57 39 75 bmdyYXR1bGF0aW9u
0050 0a .
Data: 5547466A613256305357357A6157526C4C6D4E7662534178...
추가적인 정보를 더 볼 수 있는데, 들여다 보니 출발지와 목적지의 맥주소가 어딘가 이상하다.
Private_01:01:01 (01:01:01:01:01:01), Dst: Broadcom_02:02:02 (00:05:b5:02:02:02)
조작된 것임을 쉽게 추정해 볼 수 있다. 목적지의 맥주소는 제조회사가 Broadcom
으로 보이는데 출발지와 목적지를 맥을 봤을때, 목적지의 Broadcom 부분도 의도적으로
고쳐진 것으로 보인다. (실제 필자가 고치기도 하였지만 ㅋㅋ )
또 IP 헤더의 체크썸을 보면 값이 잘못 되어 있다.
Header checksum: 0xa345 [incorrect, should be 0xe39e]
원래는 0xe39e 의 값을 갖고 있어야 하지만 0xa345 로, 조작될 가능성이 높은 부분임을
알 수 있다. 자, 그리고 데이터를 보면 81 바이트로 암호같은 문자열이 연속으로 놓여있다.
많이 접해 보신분들은 쉽게 눈치를 챌 수 있겠지만, BASE64 로 인코딩된 데이터이다.
BASE64 는 이메일에서 인코딩 방법으로 많이 쓰인다. 자, 그럼 BASE64 데이터임을
추정하였으니 아래와 같이 해독해 보자.
$ perl -MMIME::Base64 -e 'print decode_base64("UGFja2V0SW5zaWRlLmNvbSAxc3QgUGFja2V0IENoYWxsZW5nZSBTb2x2ZWQsIENvbmdyYXR1bGF0aW9u")'
PacketInside.com 1st Packet Challenge Solved, Congratulation
펄의 MIME:Base64 모듈을 이용해 위 데이터를 디코딩하면 위와 같은 결과를 얻을 수 있다.
바로, 이번 문제의 정답이다.
이번 문제는 앞서 배운 text2pcap 의 사용방법과 효과적으로 쓸수 있는 방법을 통해
패킷파일로 만들어보고 그 안에서 문제의 정답과정을 찾고 패킷의 잘못된 부분을
추정해 볼 수 있다.
