[CTF] ctf-d 우리의 제일 귀여운…

1. 문제

stego.pcap 파일을 다운로드 받을 수 있다.
해당 파일로부터 key 값을 알아내는 것이 문제이다.

2. pcap

pcap 파일은 packet capture 파일이다.
즉 네트워크 패킷이 송수신 된 내역을 담고 있다.
이제 stego.pcap 파일을 wireshark로 보자.

HTTP 패킷 부분에 message.png 라는 파일이 전송된 것이 보인다.
해당 파일을 추출해 보자.

3. message.png

추출한 뒤 열면 아래와 같은 스테고사우르스 사진이 보인다.

보다시피 사진 자체로는 아무런 단서도 찾을 수 없다.
그렇다면 헥스 에디터로 파일을 열어보자.

header와 footer에도 이상한 점을 발견할 수 없었다. 그렇다면 도대체 어디에서 단서를 찾아야 할까?

4. 풀이

네트워크를 통해 파일을 전송할 때에는 해당 네트워크에서 전송할 수 있는 최대 크기가 정해져 있다.
따라서 파일 크기가 최대 전송 크기보다 크게 되면 파일을 나누어서 전송하게 된다.
마찬가지로 stego.pcap에서도 message.png를 전송할 때 나누어서 전송하는 것을 확인할 수 있다.
그런데 이 때 이 나누어서 보내는 패킷들에서 변화가 생기는 부분이 있었다.
바로 아래의 urgent pointer 이다.

변화하는 urgent pointer들을 관찰했더니 ascii 범위인 것 같아 ascii로 변환해 보려고 한다.
하지만 파일을 나누어서 전송한 패킷이 너무 많아 일일이 확인해야 하나? 라는 생각이 들었지만 그럴 필요가 없었다.
tshark라는 프로그램을 리눅스 환경에 설치한 후 urgent pointer 부분을 가져오는 방법이 존재했다.
tcp 헤더에서 urgent pointer를 읽어오고, 0인 urgent pointer는 제외했다.

이제 나온 이 숫자들을 ascii에 맞게 변환하면
CTF{And_You_Thought_"생략"}
라는 key 값을 얻을 수 있다.

5. 마무리

마무리하기 전, 짚고 넘어갈 것이 있다.
단순히 패킷마다 값이 바뀌기에 무엇인지 모르고 그냥 넘어갔지만
urgent pointer가 무엇인지 알고 가야 할 듯 싶다.
urgent pointer는 TCP 헤더의 구성 요소로 긴급 데이터를 표시하기 위해 사용한다.
긴급 데이터의 경우 순서에 상관 없이 먼저 전송된다.
이 긴급 데이터의 마지막 바이트 위치가 바로 urgent pointer가 된다.

100 포인트 문제라서 message.png 파일을 찾아냈을 때 금방 해결할 수 있을 것이라 생각했지만
message.png 파일에서는 어떤 단서도 찾을 수 없었고 오히려 stego.pcap 파일에 단서가 있는 문제였다.
변화하는 것이 무엇인지 체크하는 것도 중요할 것 같고, tcp 헤더에 대한 이해도 필요해 보인다.