[🥉 Bronze 4] JPEG 뒤에 붙은 ZIP 꺼내기 — DreamHack Hefty Image 풀이

문제: DreamHack — Hefty Image 분류: Forensics 난이도: 🥉 Bronze 4 FLAG: DH{s1mpl3_st3g4n0gr4phy_w1th_c0nc4t}

문제 설명은 이렇다. "친구가 여행 중에 찍은 사진이라며 파일을 하나 보내왔습니다. 그런데, 평범한 사진 파일치고는 용량이 조금 묵직하네요." 그림 파일 하나를 주는 포렌식 문제인데, 열어 보면 평범한 이미지지만 파일이 화면에 보이는 것보다 "무겁다(hefty)". JPEG가 끝난 뒤에 ZIP이 몰래 이어 붙어 있기 때문이다. 대구대학교가 출제한 문제로, 대학 위게임 소개 캐릭터 계정으로 등록돼 있다.

문제 개요

파일 하나만 있으면 오프라인에서 바로 풀린다.

🔬 정찰 — 그림인데 압축파일이 열린다

file로 보면 분명 JPEG인데, 그 파일을 unzip으로 열어 보면 목록이 나온다.

file challenge.jpg
unzip -l challenge.jpg

file은 JPEG image data, 500×500이라고 하지만, unzip -l challenge.jpg는 "5206 extra bytes at beginning or within zipfile"이라는 경고를 띄우면서도 그 파일 안에서 flag.txt(36바이트)를 목록으로 찾아낸다. 경고 문구 자체가 힌트다 — unzip이 파일 앞쪽 5206바이트를 "쓸모없는 덤"으로 인식하고 건너뛰었다는 뜻이다. 한 파일이 이미지이면서 동시에 유효한 ZIP인 것이다.

먼저 흔한 도구인 binwalk로 임베디드 시그니처를 훑어보려 했다.

binwalk challenge.jpg

이 환경에 설치된 binwalk(2.4.3)가 내부적으로 참조하는 capstone.CS_ARCH_ARM64가 최신 capstone 패키지(6.0.0 알파)에서 사라져 임포트 단계부터 죽는다. 디스어셈블 기능을 쓰지 않아도 모듈을 불러오는 순간 실패하기 때문에 옵션으로 우회할 수도 없다. 어차피 unzip -l이 이미 답을 보여줬으니, 굳이 붙잡지 않고 다음 단계로 넘어갔다.

💣 핵심 — 끝에서 읽는 ZIP, 앞에서 멈추는 뷰어

JPEG는 FF D8로 시작해 FF D9(EOI, End Of Image)로 끝난다. 이미지 뷰어는 FF D9를 만나면 거기서 렌더링을 멈추고, 그 뒤에 무엇이 있든 무시한다. 그래서 뒤에 다른 데이터를 붙여도 그림은 멀쩡히 보인다.

반대로 ZIP은 파일 끝에 있는 중앙 디렉토리(central directory)부터 거꾸로 읽는 구조다. 그래서 ZIP 앞에 아무 데이터(여기서는 JPEG 전체)가 붙어 있어도 unzip은 끝에서부터 정상 구조를 찾아 열어 준다.

이 둘을 합치면, [JPEG ... FF D9][ZIP ... flag.txt] 한 파일이 뷰어에겐 그림, unzip에겐 압축파일로 동시에 동작한다. 실제로 경계를 직접 찾아 확인했다.

d = open("challenge.jpg", "rb").read()
i = d.find(b"\xff\xd9")
print("전체 크기:", len(d))
print("JPEG EOI(FFD9) 끝위치:", i + 2)
print("그 직후 4바이트:", d[i + 2:i + 6])

FF D9가 끝나는 5206번째 바이트 바로 다음이 정확히 PK\x03\x04 — ZIP 로컬 파일 헤더의 매직 시그니처다. 게다가 헥스덤프를 보면 flag.txt라는 파일명 문자열과, 그 뒤로 DH{s1mpl3_st3g4n0gr4phy_w1th_c0nc4t}라는 플래그 본문이 사람이 읽을 수 있는 ASCII로 그대로 찍혀 있다. unzip -lv로 압축 방식을 확인해보면 Stored(0% 압축, 무압축 저장)라고 나오는데, 그래서 압축을 풀 필요도 없이 헥스덤프만으로 내용이 그대로 노출된 것이다 — 압축(Deflate)돼 있었다면 이렇게 평문으로 보이지 않았을 것이다.

🎯 풀이 — unzip -p

목록에 flag.txt가 있으니 그대로 꺼내면 된다. 압축을 풀어 파일을 남기지 않고 내용만 표준출력으로 뽑는다.

unzip -p challenge.jpg flag.txt

flag.txt의 내용이 그대로 플래그다. 문제 이름 Hefty Image(무거운 이미지)와 플래그 문구(s1mpl3 st3g4n0gr4phy w1th c0nc4t, 연결로 만든 간단한 스테가노그래피)가 그대로 기법을 말해 준다.

FLAG: DH{s1mpl3_st3g4n0gr4phy_w1th_c0nc4t}

📝 결론

"보이는 것"과 "파일 전체"는 다르다. 이미지 뷰어가 보여 주는 건 FF D9까지일 뿐, 파일에는 그 뒤가 더 있을 수 있다. 파일 크기가 화면 내용에 비해 크면(hefty), 뒤에 뭔가 이어 붙었는지부터 의심한다. file은 앞부분만 보고 판단하니 그 말만 믿어선 안 된다.

포맷마다 읽는 방향이 다르다. JPEG는 앞에서, ZIP은 뒤에서 읽는다. 이 방향 차이 때문에 두 포맷을 한 파일에 겹쳐 둘 수 있다. 포렌식에서 파일이 수상하면 unzip -l, 파일 끝부분 hex 덤프로 다른 시그니처(PK, FF D8, %PDF 등)가 섞여 있는지부터 훑는 습관이 유용하다 — binwalk 같은 자동화 도구가 돌아가면 가장 편하지만, 이번처럼 도구가 말썽이어도 시그니처 몇 개만 손으로 찾으면 똑같은 결론에 도달할 수 있다.

압축 방식도 정보를 흘린다. ZIP 안에 넣을 때 압축(Deflate) 대신 무압축(Stored)을 쓰면 편집기나 헥스뷰어로 열었을 때 내용이 그대로 노출된다. 진짜로 데이터를 숨기고 싶다면 압축은 물론이고 최소한의 암호화라도 곁들여야 한다는 반면교사이기도 하다.