[🥉 Bronze 1] 스트립된 PIE 바이너리의 커스텀 RLE 역산 — DreamHack secret message 풀이

문제: DreamHack — secret message 분류: Reversing 난이도: 🥉 Bronze 1 FLAG: DH{93589e6c1db065fa95075ab5e3790bc1}

문제 개요

문제 설명은 짧다.

드림이는 비밀스런 이미지 파일을 자신이 공부한 알고리즘을 통해 인코딩 하였어요. 인코딩 프로그램을 분석하여 원본 이미지를 알아내주세요. 원본 파일을 구한 경우 imageviewer.py를 통해 이미지를 볼 수 있습니다.

즉 prob는 원본 이미지(secretMessage.raw)를 어떤 알고리즘으로 압축해 secretMessage.enc를 만든 인코더다. 원본 파일 자체는 주어지지 않고, 인코더 바이너리와 결과물만 있다. prob를 리버싱해서 인코딩 규칙을 알아내고, 그걸 거꾸로 돌려 원본 비트맵을 복원해야 한다.

🧩 배경 — imageviewer.py가 기대하는 포맷

imageviewer.py는 딱 3줄이다.

from PIL import Image
with open(sys.argv[1], "rb") as f:
    output = f.read()
    Image.frombytes("1", (500, 50), output).show()

PIL의 frombytes에 모드 "1"을 주면 1비트 흑백 이미지로 해석한다. 픽셀 하나가 1비트라 8개씩 묶여 1바이트가 되는데, PIL의 raw 디코더는 행마다 바이트 경계로 패딩한다. 폭 500픽셀은 500비트 = 62.5바이트라 각 행이 63바이트로 올림되고, 높이 50을 곱하면 원본 파일은 정확히 63 × 50 = 3150바이트여야 한다.

나중에 이 3150이라는 숫자가 발목을 잡는데, 뒤에 삽질 토글에서 그대로 남겨둔다.

🔬 코드 정찰

스트립 여부와 기본 정보

file prob secretMessage.enc imageviewer.py && wc -c secretMessage.enc

prob는 스트립된 PIE 실행 파일이다. 심볼 테이블이 없으니 함수 이름은 전부 오프셋으로 봐야 한다. secretMessage.enc는 1332바이트 — 배경에서 계산한 원본 3150바이트보다 훨씬 작다. 뭔가 압축이 들어갔다는 뜻이다.

.rodata에서 파일 입출력 흐름 잡기

동적 심볼(fopen@plt, fgetc@plt, fputc@plt, remove@plt)이 남아있어서 이 바이너리가 표준 C 스트림 함수로 파일을 순회한다는 건 바로 보인다. 어떤 파일을 여는지는 .rodata를 보면 나온다.

objdump -s -j .rodata prob

"secretMessage.raw"를 "rb"로 열고 "secretMessage.enc"를 "wb"로 연다. 즉 prob는 raw를 읽어서 enc를 쓰는 인코더다. 끝에 remove()로 원본 raw를 지우고 "done!"을 출력하는 흐름까지 문자열만으로 짐작이 간다 — 뒤에서 main() 디스어셈블리로 그대로 확인된다.

▶🐛 삽질 — 3125바이트라고 믿고 시작했다

RLE를 다 역산하고 처음 돌렸을 때 출력이 3150바이트였다. 500 × 50 ÷ 8 = 3125로 계산해뒀던 나는 25바이트가 남는 걸 보고 디코더 로직이 어딘가 틀렸다고 확신했다. 카운트 바이트 처리, 오버플로 리셋 조건, 페어 판정 순서까지 한참을 다시 뒤졌다.

Copy

python3 -c "print(500*50/8)" && python3 decode.py extracted/secretMessage.enc secretMessage.raw

원인은 디코더가 아니라 내 계산이었다. PIL의 raw 모드 "1"은 배경 섹션에서 적어둔 대로 행마다 바이트 정렬 패딩을 한다. 폭 500비트는 62.5바이트라 63바이트로 올림되고, 63 × 50 = 3150이 맞는 값이다. Image.frombytes 문서를 다시 읽고서야 픽셀 수를 8로 나누기만 하면 안 된다는 걸 알았다.

💣 핵심 — encode()의 상태머신

정적분석: main()과 encode() 호출 관계

objdump -d -M intel --start-address=0x911 --stop-address=0x991 prob | sed -rE -f annotate_main.sed

main()은 secretMessage.raw를 "rb"로, secretMessage.enc를 "wb"로 연 다음 0x7fa 오프셋의 함수를 encode(FILE *in, FILE *out) 형태로 호출한다. 그다음 원본 raw를 지우고 "done!"을 찍는다 — 왜 문제에 원본 이미지가 없는지, 이 한 줄이 설명해준다.

encode()의 핵심 분기

0x7fa의 함수를 쭉 따라가면, 매 바이트를 두 개의 상태(prev, cnt)로 다루는 반복문이 나온다. 핵심 분기만 잘라서 보면 이렇다.

objdump -d -M intel --start-address=0x83d --stop-address=0x864 prob | sed -rE -f annotate_core.sed

새로 읽은 바이트 c는 일단 무조건 fputc(c, out)으로 그대로 echo된다. 그 직후 c == prev를 비교하는데, 이 비교가 outer 루프(0x851)와 inner 루프(0x85f) 두 곳에서 반복해서 등장한다. 나머지 로직까지 전부 추적하면 다음과 같은 규칙으로 정리된다.

같은 값이 연속으로 몇 번(L) 나오느냐에 따라 출력 세그먼트가 갈린다.

• L == 1: 값을 딱 한 번만 echo. 카운트 바이트 없음.
• L == 2..257: 처음 두 개는 그대로 echo(v, v)하고, 이후 반복은 세기만 하다가(echo 안 함) 값이 바뀌면 그 반복 횟수 cnt = L - 2를 하나 더 emit. cnt는 0x00 ~ 0xfe 범위.
• cnt가 0xff(255)에 도달하면 그 시점에 강제로 [v, v, 0xff](정확히 257개)를 emit하고 prev를 리셋한다. 런이 그보다 더 길면 다음 세그먼트부터 다시 처음 규칙(첫 2개 echo)이 적용된다 — 카운트 바이트 하나가 8비트라 255가 표현 한계이기 때문에 생기는 분할이다.

디코딩은 이 규칙을 그대로 뒤집으면 된다. v를 하나 읽어 출력하고, 바로 다음 바이트도 v와 같으면 그 페어를 세그먼트로 소비해서 cnt를 마저 읽고 (1+cnt)개를 추가로 출력한다. 다르면 v는 단독이었으니 그 바이트가 곧 다음 세그먼트의 시작이다.

런타임 검증 — 오프셋이 실제로 맞는지, 그리고 라운드트립

정적분석만으로 끝내지 않고 0x7fa가 실제 실행 중에도 맞는 주소인지, 그리고 무엇보다 역산한 디코더가 진짜로 맞는지를 확인하고 싶었다. 방법은 간단하다 — 복원한 raw 파일을 원본 prob 바이너리에 다시 먹여서, 새로 나온 enc가 처음 받은 secretMessage.enc와 바이트 단위로 같은지 보면 된다.

break *0x7fa
run
info registers rdi rsi
continue

PIE라 링크 타임 주소 0x7fa에 그냥 브레이크포인트를 걸면 실패한다(Cannot access memory). starti로 한 번 멈춰 info proc mappings로 실제 로드 베이스(0x555555400000)를 구한 다음, base + 0x7fa에 브레이크포인트를 걸었다.

gdb -q -batch -x cmds.gdb --args ./prob && cmp secretMessage.enc ../extracted/secretMessage.enc && echo ROUND-TRIP-OK

브레이크포인트가 정확히 encode(FILE *in=0x555555602310, FILE *out=0x5555556024f0) 진입 시점에 걸렸고, rdi/rsi가 main()에서 넘긴 두 FILE*라는 것도 확인된다. 그리고 이 프로세스가 다 돌고 나서 만든 secretMessage.enc가 문제에서 받은 원본과 cmp로 완전히 동일했다 — 정적분석으로 재구성한 상태머신이 인코더의 동작과 정확히 일치한다는 뜻이다.

🚀 Full Exploit

디코더는 위에서 정리한 규칙을 그대로 코드로 옮긴 것뿐이다.

def decode(enc: bytes) -> bytes:
    out = bytearray()
    i, n = 0, len(enc)
    while i < n:
        v = enc[i]
        i += 1
        out.append(v)
        if i < n and enc[i] == v:
            i += 1  # 페어의 두번째 v 소비
            cnt = enc[i]
            i += 1
            out.extend([v] * (1 + cnt))
    return bytes(out)

$ python3 decode.py extracted/secretMessage.enc secretMessage.raw
enc=1332B -> raw=3150B (expect 500*50/8=3125B for 1bpp 500x50)

secretMessage.raw가 나오면 imageviewer.py가 기대하는 그대로 Image.frombytes("1", (500, 50), data)에 넣어 PNG로 저장했다.

from PIL import Image
with open("secretMessage.raw", "rb") as f:
    data = f.read()
Image.frombytes("1", (500, 50), data).save("secretMessage.png")

DH{93589e6c1db065fa95075ab5e3790bc1}. 드림핵에 제출해 정답 처리됐다.

📝 결론

스트립돼도 표준 라이브러리 호출은 남는다.

fopen/fgetc/fputc/remove PLT 심볼만으로도 이 바이너리가 파일을 열어 바이트 단위로 순회하며 다른 파일에 쓴다는 큰 그림을 심볼 이름 없이도 그릴 수 있었다. 커스텀 알고리즘이라도 결국 표준 I/O 위에 얹혀 있으면 그 호출 지점이 좋은 이정표가 된다.

압축 알고리즘 역산은 상태(레지스터·스택 변수) 두 개만 추려도 충분할 때가 많다.

이 인코더는 prev와 cnt 딱 두 개의 로컬 변수로 전체 RLE를 굴렸다. 디스어셈블리가 길어 보여도 어떤 스택 슬롯이 반복해서 비교·갱신되는지만 추리면 상태머신은 생각보다 빨리 드러난다.

역산 결과는 원본 도구로 다시 검증할 수 있으면 제일 확실하다.

디코더를 손으로 짜고 "이게 맞다"고 믿는 것과, 그 출력을 원래 인코더에 다시 넣어 바이트 단위로 원본과 일치시키는 것은 신뢰도가 다르다. 이번처럼 인코더 바이너리가 주어지는 문제라면 라운드트립 검증을 꼭 붙이는 편이 안전하다.