[🥉 Bronze 2] .img라 쓰고 gzip이라 읽는다 — DreamHack smart_device 풀이

문제: DreamHack — smart_device 분류: Misc 난이도: 🥉 Bronze 2 FLAG: acsc{binwalkisgod!}

문제 설명은 짧다. "Get API Key from smart device :D". 제공 파일도 smart_firmware.img 하나뿐이다. IoT 펌웨어 분석의 정석은 파일을 열어보기 전에 정말로 그 확장자가 맞는지부터 의심하는 것이다.

문제 개요

🧩 배경 — 임베디드 펌웨어는 대개 그냥 압축된 루트 파일시스템

IoT 기기용 펌웨어 이미지는 겉보기엔 알 수 없는 바이너리 덩어리 같지만, 속을 열어보면 의외로 평범하다. 대부분 리눅스 루트 파일시스템(/bin, /etc, /usr ...)을 그대로 tar나 cpio 같은 아카이브로 묶고, 용량을 아끼려고 gzip이나 LZMA로 한 번 더 압축한 것뿐이다. 그래서 펌웨어 분석의 첫 단계는 거의 항상 "이 파일이 실제로 어떤 포맷으로 압축·아카이브돼 있는가"를 파일 앞부분의 매직바이트(magic bytes) 로 확인하는 것이다. 확장자(.img, .bin 등)는 제작사가 마음대로 붙인 이름표일 뿐, 진짜 포맷은 파일 헤더가 말해준다.

binwalk 같은 도구가 바로 이 매직바이트 스캔과 자동 추출을 대신해주는 표준 도구다 — 사실 이 문제의 flag 자체가 그 도구 이름을 딴 농담이다.

🔬 정찰 — 확장자를 믿지 않기

file smart_firmware.img.gz
xxd smart_firmware.img.gz | head -3

file 명령이 바로 정체를 알려준다. .img 확장자와 무관하게 gzip compressed data다. 헥스덤프 맨 앞의 1f 8b 08이 gzip의 표준 매직바이트다.

이럴 때 가장 먼저 손이 가는 도구는 binwalk다 — 파일 안에 서명이 남아있는 모든 알려진 포맷(gzip, tar, ZIP, 파일시스템 등)을 스캔하고 필요하면 자동으로 잘라 추출까지 해준다.

binwalk smart_firmware.img.gz

▶🐛 삽질 — binwalk가 실제로 안 돌아간다(환경 패키지 충돌)

야심차게 binwalk를 돌렸더니 명령어가 시작하자마자 파이썬 트레이스백을 뱉으며 죽어버렸다.

원인은 binwalk(2.4.3, apt로 설치된 버전)가 내부적으로 디스어셈블 기능을 위해 capstone.CS_ARCH_ARM64를 참조하는데, 이 환경에 pip로 깔린 capstone이 6.0.0 알파 버전이라 그 상수 자체가 없어져 있었다. binwalk는 --extract처럼 디스어셈블과 무관한 옵션을 줘도 모듈 임포트 시점에 이 클래스를 로드하려다 죽기 때문에, 어떤 방식으로 실행해도 우회할 수 없었다.

시스템 파이썬을 직접 건드리면 다른 세션에 영향을 줄 수 있으니, 격리된 venv에 구버전 capstone을 깔아서 제대로 고쳐보기로 했다.

Copy

python3 -m venv /tmp/binwalkvenv
/tmp/binwalkvenv/bin/pip install 'capstone<5' 'setuptools<81' binwalk
/tmp/binwalkvenv/bin/binwalk smart_firmware.img.gz

capstone은 정확히 고쳤는데(capstone 4.0.2 OK), 이번엔 PyPI에 올라온 binwalk 패키지 자체가 문제였다 — binwalk.core 서브모듈이 아예 빠진 불완전한 배포판이라, capstone 문제와 무관하게 임포트 단계에서 또 죽는다. apt로 설치되는 binwalk(소스 빌드 방식)와 pip install binwalk(PyPI 배포판)가 서로 다른, 호환되지 않는 패키지라는 걸 이 삽질을 통해 알게 됐다. 결국 두 겹의 문제(capstone 버전 충돌 + PyPI 배포판 불완전)를 다 해결하려면 정식 GitHub 소스에서 빌드해야 하는데, 이 문제 하나 풀자고 거기까지 갈 이유는 없었다 — binwalk가 원래 자동으로 해주는 일(매직바이트 스캔 → 압축 해제 → 아카이브 추출)을 그냥 손으로 재현하기로 했다. 어차피 이 파일은 gzip 하나뿐이라 gunzip + tar만으로 충분했다.

💣 핵심 — 수동으로 같은 걸 한다: gunzip → tar → 설정 파일

gunzip -k smart_firmware.img.gz -c > /tmp/fw.tar
file /tmp/fw.tar
tar -tvf /tmp/fw.tar

압축을 풀고 나니 예상대로 GNU tar 아카이브였고, 그 안에는 /bin, /etc, /etc/init.d, /var/log 같은 낯익은 리눅스 루트 파일시스템 구조가 그대로 들어있다. /etc/device.conf라는 이름이 특히 눈에 띈다 — 설정 파일에는 흔히 인증 정보가 하드코딩돼 있다.

tar -xf /tmp/fw.tar -C tar_extracted
cat tar_extracted/etc/device.conf

[SECURITY] 섹션의 AUTH_KEY에 flag가 그대로 평문으로 박혀 있다. # Do not edit manually.라는 주석이 붙어 있는 걸 보면, 이 파일은 빌드 시스템이 자동 생성한 뒤 이미지에 그대로 구워 넣은 것으로 보인다 — 즉 누구든 이 펌웨어 파일 하나만 다운로드하면(구매한 기기를 분해하지 않고도) API 키를 얻을 수 있다는 뜻이다.

flag만 뽑고 끝내기 전에, 이 rootfs에 다른 흥미로운 게 더 있는지 전체 구조를 한 번 훑어봤다.

find tar_extracted -type f | sort
cat tar_extracted/etc/init.d/rcS
cat tar_extracted/etc/passwd

전체 구성은 5개 파일뿐인 미니멀한 더미 rootfs다. /etc/init.d/rcS는 부팅 시 /bin/check_status를 실행해 "Device Status: OK"를 찍는 게 전부고, /etc/passwd에는 root와 admin 두 계정만 있다(둘 다 패스워드 해시 필드가 x라 별도 /etc/shadow 없이는 로그인 정보가 없다 — 이 문제에서는 미끼에 가깝다). 진짜 민감 정보는 처음 찾은 device.conf 하나뿐이었다는 걸 rootfs 전체를 훑어보고 나서야 확신할 수 있었다.

📝 결론

확장자가 아니라 매직바이트를 믿어라. .img, .bin, .dat 처럼 제조사가 임의로 붙인 확장자는 실제 포맷에 대해 아무것도 보장하지 않는다. file 한 번, 혹은 헥스덤프로 처음 몇 바이트만 봐도 진짜 정체가 드러나는 경우가 놀랄 만큼 많다.

표준 도구가 죽으면 그 도구가 "무엇을 하는지"를 이해하고 손으로 재현하면 된다. binwalk가 이 환경에서 우연히 망가져 있었지만, 그게 하는 일(시그니처 스캔 → 압축 해제 → 아카이브 추출)을 알고 있으면 file+gunzip+tar 세 명령으로 똑같은 결과를 얻을 수 있다. 도구 하나에 의존하기보다 그 도구가 대체하고 있는 기본 개념을 알아두는 게 이럴 때 빛을 발한다.

펌웨어에 인증 키를 평문으로 굽지 마라. 이 문제가 보여주는 실제 취약점 패턴은 IoT 업계에서 흔하다 — 기기 고유 키나 API 시크릿을 빌드 시점에 설정 파일에 하드코딩해 전체 제품 라인에 동일하게 배포하면, 공개된 펌웨어 업데이트 파일 하나만 손에 넣어도 모든 기기의 키가 한꺼번에 노출된다. 키는 기기별로 안전한 프로비저닝 절차를 통해 별도로 주입해야지, 이미지 자체에 구워 넣으면 안 된다.