[Network] 파일에서 플래그를 찾아라.

CTF-D에 NetWork카테고리에 있는 "파일에서 플래그를 찾아라"를 풀어보도록 하겠습니다.
문제를 한번 보겠습니다.

확장자가 없는 myheart....이 주어졌고 txt파일이 주어졌는데, txt파일을 열어보니 풀이 답안지여서 저 방식과는 다르게
제 방식대로 풀어 보겠습니다.

이런 파일이 하나 주어지는데 리눅스로 가져가 파일 유형을 보겠습니다.

$ file [파일명]

xz파일로 되어있으니 unxz 명령어를 통해서 압축을 풀어 줍시다.

$ unxz [파일명]

압축을 풀었으면, 다시 파일의 유형을 살펴봅시다.

pcapng파일이네용!! 저도 pcapng에 대해서는 잘 알지 못하기 때문에 간단하게만 구글링을 한 대로 설명 하겠습니다.

pcapng파일이란?
PCAP Next Generation의 약자로 기존 pcap파일을 발전 시킨 파일 형식입니다. 기존 pcap과 비교하여 패킷 캡처를 한 인페이스 정보, 주석, 이름 확인 정보 등 많은 메타데이터가 추가 되었습니다.

파일 시그니처는 pcap과 달리 D4 C3 B2 A1이 아니라, 0A 0D 0D 0A입니다.

pcapng파일을 와이어 샤크로 분석하기 위해서는 pcap파일로 변환을 시켜주어야 하는데 변환을 시켜주기 위해서는 editcap을 이용해야 합니다. editcap은 캡처 파일의 형식을 변환시켜 주는 친구입니다.
명령어는 다음과 같습니다.

$ editcap -F libpcap -T ether [파일명].pcapng [파일명].pcap

명령에 대해서 해석을 하겠습니다.
-F : 파일 형식을 지정합니다.
libpcap : 패킷 캡처 라이브러리입니다.
(TcpDump/WinDump등 기타 네트워킹 도구에서 사용되는 기본 캡처 파일 형식으로 wireshark/Tshark에서 지원)
-T : 캡슐화 시킵니다.
(캡슐화를 시키는 이유는 files from that network type can't be saved in that format 에러가 발생하지 않기 위해서)

나머지는 뭐 pcapng파일을 pcap으로 변환한다. 라고 생각하시면 되겠습니다.
본론으로 돌아가 변환된 pcap파일을 실행 해봅시다.

TCP 프로토콜만 보이니까 [Analyze] - [Follow] - [TCP Stream] 을 보겠습니다.

TCP Stream 0를 보면 다음과 같은 화면이 나옵니다. 빨간색으로 된 것을 보면
host a.asis.io에 GET /LoiRLUoq과 파란색에 Content-Range : bytes 1080486 - 1345387/2347916이 보입니다.
쉽게 LoiRLUoq파일을 보냈는데, 바이트가 분할되어서 보내졌다 라고 이해하시면됩니다.
그래서 진짜 파일을 보냈는지 확인하기 위해서 networkminer를 사용하겠습니다.

보시는것과 같이 [0], [1], [2], ----- [22]까지 존재하는데요 총 23개의 파일로 쪼개진것을 확인할 수 있었습니다.
그럼 쪼개진 부분을 순서대로 합쳐서 카빙을 진행하면 파일이 복구가 됩니다.

카빙이란?
기본적으로 파일에 주어진 메타데이터 보다는 파일 자체의 바이너리 데이터인 header, signature등을 이용해서 디스크의 비할당 영역에서 파일을 복구하는 방식입니다. 자세한것은 여기를 참고하시길 바랍니다.

https://lemonpoo22.tistory.com/77

카빙을 하는 방법은 쉽습니다. ( 저도 삽질 11번 정도해서 푼거지만...ㅎㅎㅎ)
1개의 카빙 방법만 알려드리고 나머지는 직접 하시길 바랍니다.
bytes 순서대로 적습니다.

이런식으로 순서를 적다보면 결국엔 마지막에 나오는것이 푸터 시그니처일겁니다.
근데 왜 0bytes부터 시작 안하는지 궁금해 하실텐데 그 부분은 곧 설명을 해드리겠습니다.

이제 tcp.stream 10번에 가봅시다.

이렇게 나올텐데, 빨간색으로 표시한 사각형을 제외한 밑에 공백과 HDR부분 보이시나요?
이 부분부터 카빙을 진행해야 합니다.
그럼 HDR이 16진수로 들어가야 카빙이 되기 때문에 hex dump로 보겠습니다.

형광색으로 된 것부터 보겠습니다.
왼편에 0d 0a 0d 0a는 Content-Range와 HDR 사이에 공백 한줄을 의미합니다.
오른편에 Content.....부터 2347916....까지는 카빙을 하시면 안됩니다. 쉽게 말해 모든 tcp stream에서는 range뒤에 0d 0a 0d 0a가 존재합니다. 그 뒷 부분부터 카빙을 진행해야 합니다. 48 44 52 00부터 카빙을 하시면 다음 그림처럼 됩니다.

이런식으로 말이죠!!! 하지만 중요한점이 있습니다.

이 부분을 보면 [10]이 [17]이 가지고 있는 바이트 수를 넘습니다.
[10]에서는 총 13 ~ 179835까지 전송을 했고, [17]에는 27943 ~ 132132까지 전송을 했습니다.
그럼 중복된 부분이 27943 ~ 132132까지 같은 데이터로 씌워질겁니다. 그래서 중복은 제외를 시켜야 합니다.

그래서 마지막에 d8 b1 a0 fe 7c가 tcp stream 10의 마지막 16진수 데이터입니다.
그럼 [17]을 제외하고 [13]에서 d8 b1 a0 fe 7c를 검색을 진행하고 다음 부분에 나오는것부터 카빙을 하시고, 또 13에서 나오는 마지막값을 가지고 검색을 진행하고 또 다음 부분부터 카빙하고 무한반복 하다보면 마지막에 png파일의 푸터 시그니처가 등장할것입니다. 그래서 파일을 저장할 때 확장자를 png로 해주신다음 저장을 하면 됩니다.

제대로 카빙을 했다면 offset값이 23D370이 됩니다. 카빙한 데이터를 실행시켜봅시다.

답이 나오질 않았습니다. 왜냐면 파일에는 헤더 시그니처와 푸터 시그니처가 존재하기 때문입니다.
아까 제가 왜 0byte부터 시작 안하냐고 했던게 기억이 나실텐데, 바로 헤더 시그니처가 빠졌기 때문입니다.
png구조를 설명하지는 않겠지만, 89 50 4E 47 0D 0A 1A 0A 같이 헤더 시그니처가 존재합니다.

헤더 시그니처를 추가해줌에도 불구하고 답이 나오질 않습니다. 그래서 잘 살펴보니 HDR이 보입니다. HDR은 PNG파일에서 존재하지 않은 청크입니다. 그래서 IHDR로 바꿔주어야 합니다.

그래서 총 추가해야 될 문자는 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49로 13개의 문자입니다.
뒤에 00 00 00 0D 49는 왜 붙는지 궁금해 하실텐데 png구조를 살펴보시면 알수있습니다. ㅎㅎ

이렇게 13개의 문자를 넣어주고 저장을 하면 플래그를 찾을 수 있습니다.

오늘도 수고 많으셨습니다. 푸는데 12시간 넘게 걸렸네요 ㅠㅠ

-reperence-
디지털 포렌식 with CTF