실제 사이트에 들어가면 문제는 아래와 같이 주어지고 learned를 누르면 문제 파일이 다운받아진다.

나는 처음에 문제를 풀 때 문제 사이트는 들어가보지 못했지만 파일과 대화내용을 주목하여 이미지를 구하라는 힌트가 주어진 상태여서 대화내용을 먼저 찾아야 겠다는 생각을 가지고 시작할 수 있었다.
일단 와이어샤크에서 해당 파일을 열어보았다 TCP패킷이 많이 보이므로 TCP 스트림으로 Follow를 해보았다. 나는 좀 아래쪽에 있는 TCP패킷으로 Follow를 실행해서 아래와 같은 화면이 나왔었다.

해당 화면에서는 ASCII로 이루어진 정보를 찾을 수 없으므로 이 전에 있는 TCP 패킷이 가지고 있는 정보를 찾아보았다.
우측 아래쪽 코너를 보면 Stream이라고 쓰여진 곳이 있다. 현재 위치한 stream은 두번째 stream이므로 이전 stream으로 가보면 아래와 같은 대화를 찾을 수 있다.

이를 통해 Stream 1에서 대화내용을 알 수 있다. 그럼 상대 이미지를 지금 보내고 있다는 메시지를 보낸 클라이언트가 바로 다음에 이미지를 보냈는지 확인해 봐야겠다. Stream 2에서 해독되지 않은 정보 모두 이미지를 보내겠다는 클라이언트가 보낸 것이므로 Stream 2가 이미지 정보인 것을 추측할 수 있다.
Stream 2의 정보를 16비트로 변경시키면 해당 이미지의 데이터를 얻을 수 있다.
인터넷에서 16진수 데이터를 이미지 데이터로 변경해주는 페이지를 찾아서 아래 데이터

를 복사 붙여넣기 해서 입력해주었더니 아래와 같은 이미지를 얻을 수 있었다.
Stream 2가 이미지 파일 데이터라는 것을 파일 시그니처를 통해 정확히 알 수 있다. Stream 2를 보면 ascii 코드 상으로는 JFIF으로 시작하고 1진수 데이터는 ffd8ffe0으로 시작하는것을 확인 할 수 있는데 이는 JPEG파일의 헤더 시그니처이다. 즉 해당 문자로 시작하는 데이터는 모두 JPEG파일임을 알 수 있다.
http://forensic-proof.com/archives/300
해당 페이지에서 다른 파일의 헤더들을 확인할 수 있다.
CTF문제에서 자주 나타나는 몇 가지 파일 시그니처만 확인해보면
PNG : 89 50 4E 47 0D 0A 1A 0A
PDF : 25 50 44 46 2D 31 2E
ZIP : 50 4B 03 04
또한 나는 패킷들을 대충 확인하고 TCP패킷이 더 많아 보여서 TCP stream 을 follow했는데 statistics->protocol hierarchy에서 패킷이 차지하는 비율을 확인할 수 있다. 이 문제의 경우 아래와 같이 UDP패킷보다 TCP패킷의 구성비율이 더 많으므로 TCP패킷에 대부분의 정보가 있는 것을 알 수 있다.
