[🥇 Gold 4] RC4인 줄 알았던 암호와, 파일 하나에 숨어 있던 세 조각 — DreamHack Enc-JPG 풀이

문제: DreamHack — Enc-JPG 분류: Reversing + Forensics 난이도: 🥇 Gold 4 FLAG: DH{How_ENc_ECrypt_yo}

문제 개요

문제 설명이 짧지만 정보가 꽤 들어 있다.

드림이가 JPG파일 만드는 중에 변조가 되었어요!! JPG파일이 단단히 이상하네요…?? 문제 파일이 하나 잘못생성 되었습니다. ㅠ-ㅠ 마지막 사진 플래그 글자수는 4개입니다. DH{JPG_TXT_PNG}

마지막 줄을 나는 처음에 "플래그 형식은 이렇게 생겼다"는 예시로 읽었다. 다 풀고 나서야 조각이 JPG·TXT·PNG 세 곳에서 나온다는 구성 안내였다는 걸 알았다. 그리고 "잘못생성"과 "마지막 사진 4글자"는 마지막 단계에서 정확히 들어맞는다. 미리 알고 봤으면 훨씬 빨랐을 텐데, 순서대로 적어 본다.

1. 정찰

받은 게 뭔지부터 본다.

cd extracted
ls -la && file Enc flag.jpg

flag.jpg가 data로 잡힌다. 확장자만 jpg 고 내용은 JPEG 이 아니라는 뜻이다. 앞 4바이트가 ff d8 ff e0이 아니라는 얘기이고, 그러니 Enc가 이 파일을 뭉갠 장본인일 것이다.

윈도우 바이너리라 리눅스에서 실행할 수는 없다. 정적 분석으로 간다. 문자열부터.

strings -n 5 Enc | grep -iE "funfun|flag|r\\+b|Project2"

funfun이 눈에 띈다. 길이 6짜리 영단어 반복이라 키일 가능성이 높다. flag.jpg와 r+b가 같이 있는 것도 자연스럽다 — 파일을 읽기·쓰기 겸용 바이너리 모드로 연다는 건 제자리에서 고쳐 쓴다(in-place)는 뜻이다.

섹션 배치도 봐 둔다.

objdump -h Enc | sed -n "4,12p"

.text가 4KB 남짓이라 함수가 몇 개 없다. 이 정도면 전부 읽어도 된다.

문자열이 .rdata 어디에 있는지 확인해 두면 참조 지점을 찾기 쉽다.

objdump -s -j .rdata Enc | grep -iE "funfun|flag"

주소가 나왔다. funfun은 0x140003280, flag.jpg는 0x140003290이다. 이제 이걸 가리키는 lea 를 찾으면 된다. 두 군데가 나왔다 — 0x140001043과 0x140001277. 즉 파일을 여는 함수가 둘이다. 하나는 sub_140001000, 다른 하나는 그걸 호출하는 main(0x140001240)이다.

정리하면 이 프로그램은 flag.jpg를 두 번 훑는다.

2. 1단계 — RC4를 닮았지만 아닌 것

sub_140001000부터 읽는다. 앞부분은 평범하다. funfun\0 7바이트를 스택([rbp+0x28])에 복사하고, fopen_s(&f, "flag.jpg", "r+b")로 열고, fread(buf, 1, 0x400, f)로 1024바이트를 읽는다. 그 다음 키 길이를 구하는 루프(or rdx,-1 → inc rdx → cmp byte[rax+rdx],0)가 돌아 rdx = 6이 된다.

여기서부터가 본론이다.

주석은 tools/annot_ksa.sed 로 얹었다. ; 뒤가 내가 붙인 것이고 나머지는 objdump 원문이다.

s|\(and    rax,rdx\)|\1              ; ★ i % 6 이 아니라 i \& 6|
s|\(mov    al,BYTE PTR \[rbp+rax\*1+0x28\]\)|\1  ; K[i] = key[i \& 6]|
s|\(mov    BYTE PTR \[rbp+rcx\*1+0x30\],r8b\)|\1 ; S[i] = i|

objdump -d Enc -M intel --start-address=0x1400010d5 --stop-address=0x1400010f9 \
  | sed -n "8,20p" | sed -f ../tools/annot_ksa.sed

RC4 의 키 스케줄이 맞다. S[i] = i로 채우고 K[i]에 키를 반복해 넣는다. 그런데 명령이 and rax,rdx 다. 표준 RC4 는 K[i] = key[i % keylen]인데 이건 key[i & 6]이다.

i & 6이 낼 수 있는 값은 {0, 2, 4, 6} 넷뿐이다. 즉 실제로 쓰이는 키 바이트는

넷이고, funfun의 두 번째·네 번째·여섯 번째 글자(u, f, n)는 한 번도 안 쓰인다. 컴파일러가 최적화한 게 아니라 소스가 원래 &였을 것이다. 어느 쪽이든 그대로 베껴야 한다.

KSA 본체(0x1400010f9)는 표준 그대로다. j = (j + K[i] + S[i]) & 0xff 하고 S[i]와 S[j]를 맞바꾼다. and edi,0x800000ff 뒤에 붙은 부호 보정 3줄은 컴파일러가 부호 있는 정수로 나머지를 흉내 낸 것이라 결과적으로는 & 0xff와 같다.

키스트림을 뽑는 PRGA 에서 두 번째 차이가 나온다.

주석은 tools/annot_prga.sed 로 얹었다. ; 뒤가 내가 붙인 것이고 나머지는 objdump 원문이다.

s|\(movzx  ecx,BYTE PTR \[rbp+rax\*1+0x30\]\)|\1 ; S[t]|
s|\(mov    al,BYTE PTR \[rbp+rcx\*1+0x30\]\)|\1  ; ★ S[S[t]] — 한 번 더 인덱싱|
s|\(xor    BYTE PTR \[rbp+r8\*1+0x130\],al\)|\1 ; buf[n] ^= keystream|

objdump -d Enc -M intel --start-address=0x14000118d --stop-address=0x1400011b2 \
  | sed -n "8,16p" | sed -f ../tools/annot_prga.sed

t = (S[i] + S[j]) & 0xff까지는 같다. 표준이라면 S[t]가 키스트림 바이트다. 그런데 여기는 movzx ecx, [rbp+rax+0x30]으로 S[t]를 꺼낸 뒤, 그 값을 다시 인덱스로 써서 mov al, [rbp+rcx+0x30] 을 한 번 더 한다. 즉 S[S[t]] 다.

이것만으로도 표준 RC4 구현을 갖다 쓰면 안 된다는 게 확실해진다. 여기까지 읽고 나는 "키 funfun, & 확장, 이중 인덱싱" 세 가지를 반영해 복호기를 짰다. 그리고 틀렸다.

🔧 삽질 — 헤더만 살아나고 나머지가 전부 깨졌다

청크마다 S 박스를 새로 만든다는 걸 놓치고 스트림을 파일 전체에 계속 이어서 돌린 버전이다.

Copy

# ✗ 잘못된 버전 — S 박스를 파일 전체에 한 번만 만든다
S, j = ksa(KEY), 0
out = bytearray(data)
for n in range(len(out)):
    out[n] ^= prga_next(S)          # 청크 경계를 무시하고 계속 이어 간다
open("wrong_stream.jpg", "wb").write(out)

앞 4바이트가 ff d8 ff e0으로 정확히 나오고 file도 JPEG 으로 잡는데, 정작 그림은 위쪽 몇 줄만 멀쩡하고 아래가 전부 노이즈였다. 아래는 그렇게 나온 wrong_stream.jpg 를 이미지 뷰어로 연 화면이다.

"헤더는 맞는데 뒤가 틀리다"는 건 앞 1024바이트만 키스트림이 맞았다는 뜻이다. 1024는 아까 fread에 넘긴 0x400이다. 우연일 리가 없다.

그래서 함수 끝을 다시 봤다.

주석은 tools/annot_loop.sed 로 얹었다. ; 뒤가 내가 붙인 것이고 나머지는 objdump 원문이다.

Copy

s|\(je     0x14000108e\)|\1  ; ★ 복귀점이 ftell 직전 = S박스 초기화가 루프 안|
s|\(call   QWORD PTR \[rip+0x1f82\)|\1 ; feof|

Copy

objdump -d Enc -M intel --start-address=0x1400011f4 --stop-address=0x140001210 \
  | sed -n "8,14p" | sed -f ../tools/annot_loop.sed

feof가 0이면 je 0x14000108e로 점프한다. 0x14000108e는 ftell 직전, 즉 S 박스 초기화보다 앞이다. 다시 말해 이 함수는 파일 전체를 1024바이트씩 돌면서 매 청크마다 S 박스를 처음부터 다시 만든다. 키스트림이 이어지지 않는다.

한 가지 더 있다. KSA 가 쓰는 j(레지스터 edi)는 루프 밖 0x140001059에서 딱 한 번만 0이 된다. PRGA 직전(0x14000113d)에서 다시 0으로 초기화되니, KSA 는 앞 청크 PRGA 가 끝났을 때의 j 값을 이어받아 시작한다. 그래서 청크마다 S 박스는 새로 만들어지되 매번 다른 배열이 나온다.

이 두 줄이 빠져서 두 시간을 날렸다. 디스어셈블리에서 루프의 복귀 지점을 확인하지 않고 "함수 하나 = 스트림 하나"라고 넘겨짚은 게 원인이다.

파일을 어떻게 훑는가

암호 자체와 별개로, 이 함수가 파일을 다루는 골격도 봐 둘 필요가 있다. 임포트 주소를 호출 인자와 맞춰 보면 이렇게 정리된다.

한 바퀴는 ftell 로 현재 위치 기억 → fread → 변환 → 기억한 위치로 fseek → fwrite → 읽기 끝난 위치로 다시 fseek 이다. 제자리 갱신이라 r+b 로 연 이유가 여기서 드러난다. 원본을 남기지 않으니 flag.jpg 는 이미 두 번 덮어써진 상태로 배포된 것이다.

정리하면 1단계는 이렇다.

3. 2단계 — 인덱스 홀짝 XOR

main은 1단계 함수를 부른 뒤 파일을 다시 연다. 이번엔 훨씬 단순하다.

주석은 tools/annot_st2.sed 로 얹었다. ; 뒤가 내가 붙인 것이고 나머지는 objdump 원문이다.

s|\(test   dl,0x1\)|\1                ; 인덱스 홀짝 판정|
s|\(xor    cl,0x85\)|\1               ; 짝수|
s|\(xor    cl,0x44\)|\1               ; 홀수|

objdump -d Enc -M intel --start-address=0x1400012cb --stop-address=0x1400012ef \
  | sed -n "8,18p" | sed -f ../tools/annot_st2.sed

test dl,0x1로 인덱스의 최하위 비트를 보고 짝수면 ^0x85, 홀수면 ^0x44 한다. 역시 0x400씩 읽어 처리하고 되쓴다. 청크 크기가 짝수라 청크가 나뉘어도 전역 홀짝이 어긋나지 않는다. 그래서 파일 전체를 한 번에 처리하는 것과 결과가 같다.

cmp rdx,rdi; jbe 라 읽은 바이트 수보다 하나 더 XOR 하는 오프바이원이 있는데, fwrite는 읽은 만큼만 쓰기 때문에 출력에는 영향이 없다. 스택 한 바이트를 건드리고 말 뿐이다.

두 단계 모두 XOR 이라 복호는 같은 연산이고, XOR 은 교환법칙이 성립하니 순서도 상관없다.

4. 복호기

읽은 그대로 옮긴다. 별도 라이브러리가 필요 없다.

KEY = b"funfun\x00"          # 바이너리가 스택에 복사하는 7바이트 그대로
CHUNK = 0x400                # fread/fwrite 단위. 1·2단계 모두 이 크기로 돈다
 
 
def rc4_variant(data, j_carry=0, key=KEY):
    """한 청크. 반환 (결과, 다음 청크 KSA 로 넘길 j)."""
    klen = len(key) - 1                              # strlen("funfun") = 6
    K = bytes(key[i & klen] for i in range(256))     # ① i % klen 이 아니라 i & klen
 
    S = list(range(256))
    j = j_carry                                      # ② KSA 전에 j 를 0 으로 안 돌린다
    for i in range(256):
        j = (j + K[i] + S[i]) & 0xFF
        S[i], S[j] = S[j], S[i]
 
    out = bytearray(data)
    i = j = 0                                        # PRGA 직전에만 j = 0
    for n in range(len(data)):
        i = (i + 1) & 0xFF
        j = (j + S[i]) & 0xFF
        S[i], S[j] = S[j], S[i]
        t = (S[i] + S[j]) & 0xFF
        out[n] ^= S[S[t]]                            # ③ S[t] 가 아니라 S[S[t]]
    return bytes(out), j
 
 
def stage2(data):
    """인덱스 홀짝 XOR. 자기역함수."""
    return bytes(b ^ (0x44 if n & 1 else 0x85) for n, b in enumerate(data))
 
 
def stage1(data):
    """청크마다 S 박스를 새로 만들되 KSA 의 j 만 이어받는다. 자기역함수."""
    out, j = [], 0
    for o in range(0, len(data), CHUNK):
        blk, j = rc4_variant(data[o:o + CHUNK], j)
        out.append(blk)
    return b"".join(out)
 
 
def decrypt(enc):
    return stage1(stage2(enc))       # 암호화가 1→2 였으니 복호는 2→1

돌려 보면 이렇게 나온다.

ff d8 ff e0으로 시작하고 file이 303x64 JPEG 으로 잡는다. 그림도 멀쩡하다.

메모장 메뉴바다. 그런데 플래그가 없다. 303×64면 메뉴바 딱 한 줄 높이라 아래가 아예 없다.

복호가 맞는지 어떻게 확신했나

"헤더가 맞으면 복호가 맞다"는 건 앞에서 이미 한 번 틀렸다. 그래서 이번엔 세 가지로 교차 확인했다.

1. JPEG 구조가 끝까지 파싱된다. SOI 부터 EOI 까지 마커 길이가 전부 맞고, 중간에 정의되지 않은 마커가 나오지 않는다. 키스트림이 어긋나면 압축 데이터가 깨져 디코더가 중간에 멈춘다.
2. 그림이 의미를 가진다. 노이즈가 아니라 읽을 수 있는 한글 메뉴 문자열이 나온다. 이건 우연으로 나올 수 없다.
3. 뒤쪽 PNG 의 zlib 스트림이 해제된다. 파일 끝부분(오프셋 4845 이후)은 완전히 다른 청크에 속하는데, 거기 있는 압축 데이터가 정상 해제되고 크기까지 179 × (1 + 439×4) 로 딱 맞는다. 앞쪽만 맞고 뒤가 틀린 상황이었다면 여기서 반드시 걸린다.

세 번째가 특히 중요하다. 삽질 때는 1번과 2번이 부분적으로 통과해서 속았는데, 파일 끝에서 독립적으로 검증되는 지표를 하나 잡아 두면 그런 착각을 걸러낼 수 있다.

5. 파일 하나에 넷이 들어 있었다

file이 JPEG 이라고 해서 파일 전체가 JPEG 인 건 아니다. 7,415바이트 중 이 그림이 몇 바이트를 쓰는지 확인해 봐야 한다. 마커를 훑는 스크립트를 짰다.

d = Path("decrypted.jpg").read_bytes()
NAMES = {0xD8: "SOI", 0xD9: "EOI", 0xDA: "SOS", 0xC0: "SOF0",
         0xC4: "DHT", 0xDB: "DQT", 0xE0: "APP0"}
 
i = 0
while i < len(d) - 1:
    if d[i] == 0xFF and d[i + 1] in NAMES:
        m = d[i + 1]
        ln = int.from_bytes(d[i + 2:i + 4], "big")
        print(f"  @{i:<6} FF{m:02X} {NAMES[m]:<5} len={ln}")
    i += 1

EOI(FFD9)가 두 개다. 그리고 4845 에 PNG 시그니처가 있다. 파일은 이렇게 생겼다.

두 번째 덩어리가 설명에 나온 "잘못생성된 파일"이다. JPEG 은 SOI·양자화표(DQT)·프레임 헤더(SOF0)· 허프만표(DHT)·스캔 시작(SOS)이 있어야 디코딩되는데, 그게 통째로 없고 압축된 픽셀 데이터만 남아 있다.

6. 헤더 없는 JPEG 을 되살리기

없는 헤더는 만들어 붙이면 된다. 마침 같은 인코더가 만든 JPEG ①이 바로 앞에 있다. 양자화표와 허프만표가 같을 가능성이 높으니 ①의 헤더를 그대로 이식해 본다.

JPEG ①에서 SOS 세그먼트가 끝나는 지점(609 + 2 + 12 = 623)까지가 헤더다.

d    = Path("decrypted.jpg").read_bytes()
hdr  = d[0:623]        # JPEG① 의 SOI ~ SOS 세그먼트 끝
scan = d[3273:4808]    # JPEG② 의 스캔 데이터 + EOI
Path("part2_graft.jpg").write_bytes(hdr + scan)

크기(SOF0 의 가로·세로)는 ①의 303×64 그대로다. 당연히 틀렸을 텐데, JPEG 은 크기가 어긋나도 디코더가 있는 데까지는 그려 준다.

나왔다. 화면이 어긋난 건 가로 크기가 실제와 달라서 줄이 밀린 것뿐이고, 글자는 읽힌다.

제대로 된 가로 크기를 찾으려고 후보를 훑어 한 장에 모아 봤다.

어느 폭으로 맞춰도 DH{How 뒤는 회색이다. 스캔 데이터가 딱 거기까지라는 뜻이니, 이 그림이 가진 글자는 그게 전부다. 확대해서 정확히 읽는다.

DH{HOW가 아니라 DH{How 다. 작게 볼 때는 전부 대문자로 보였는데 확대하니 ow가 소문자다. 플래그는 대소문자를 틀리면 그냥 오답이니 이런 건 꼭 확대해서 확인해야 한다.

7. 사이에 낀 37바이트

JPEG ②의 EOI 와 PNG 시그니처 사이 37바이트가 남아 있다. 그냥 덤프해 본다.

Find\0the\0String\0"_ENc_ECrypt"\0\0\0...

널로 끊긴 평문이다. _ENc_ECrypt — 두 번째 조각이고, 문제 설명의 DH{JPG_TXT_PNG} 에서 TXT 자리다. 여기서 그 줄이 형식 예시가 아니라 조각 출처 안내였다는 걸 알았다.

8. 안 열리는 PNG

남은 건 PNG 다. file은 439×179 RGBA 라고 잘 읽는데 정작 이미지 라이브러리가 못 연다. 청크를 순회하며 CRC 를 검사해 본다.

off = 8
while off + 8 <= len(d):
    ln, typ = struct.unpack(">I4s", d[off:off + 8])
    data = d[off + 8:off + 8 + ln]
    crc  = d[off + 8 + ln:off + 12 + ln]
    ok = struct.pack(">I", zlib.crc32(typ + data) & 0xFFFFFFFF) == crc
    print(f"  @{off:<6} {typ.decode():<5} len={ln:<12} CRC {'OK' if ok else '*** 불일치'}")
    off += 12 + ln

IHDR·sRGB·gAMA까지는 CRC 가 맞는다. pHYs부터 어긋나고, 그 다음 IDAT의 길이 필드가 1,601,793,917로 읽힌다. 파일이 2,570바이트인데 16억이라니 말이 안 된다.

여기서 두 갈래가 있다. "PNG 를 고쳐서 그림을 본다"와 "왜 저 숫자가 나왔는지 본다"다. 둘 다 해 봤는데 정답은 후자였다.

8-1. 고쳐서 보기

배치 자체는 멀쩡하다. IEND가 2562 에 제대로 있으니 IDAT 데이터는 [91:2554]일 수밖에 없다. 길이와 CRC 만 다시 계산하면 살아난다.

idat = d[91:2554]                 # IDAT 타입(87)+4 ~ IEND 길이필드(2558)-4
raw  = zlib.decompress(idat)      # 314,503 bytes
assert len(raw) == 179 * (1 + 439 * 4)     # 높이 × (필터바이트 1 + 가로 × RGBA)

zlib 해제 크기가 179 × (1 + 439×4) = 314,503과 정확히 맞는다. IHDR 이 말한 크기가 진짜라는 뜻이고, 데이터도 온전하다는 뜻이다. 청크를 다시 조립하면 열린다.

그런데 백지다. 메뉴바 아래 픽셀을 전부 세어 보면 #ffffff 한 색뿐이다. 그릴 글자가 애초에 없었다. 설명의 "문제 파일이 하나 잘못생성 되었습니다"가 이걸 말한 거였다.

8-2. 왜 16억이 나왔는지 보기

그럼 그 이상한 길이 필드는 뭘까. 바이트를 그대로 보면 5f 79 6f 7d 다. ASCII 로 읽으면 _yo} 다. 혹시 몰라 파일 전체에서 ASCII 런을 훑었다.

for m in re.finditer(rb"[\x20-\x7e]{6,}", d):
    print(f"  @{m.start():<6} {m.group().decode()!r}")

@4928 '_yo}IDATx^'. 플래그 조각이 IDAT 청크의 길이 필드 자리에 그대로 덮여 있었다. 그림에 글자를 그리는 대신 파일 구조를 덮어쓴 것이고, 그래서 PNG 가 안 열리고 내용도 백지였다. "잘못생성"과 "마지막 사진 플래그 글자수는 4개"가 여기서 동시에 맞아떨어진다 — _yo} 는 정확히 4글자다.

PNG 를 고쳐서 그림만 봤다면 백지를 보고 막혔을 것이다. 깨진 구조 필드 자체가 데이터일 수 있다는 게 이 문제의 진짜 교훈이라고 생각한다.

9. 조각 맞추기

p1 = "DH{How"       # JPEG② 에 그려진 텍스트 (JPEG① 헤더를 이식해 렌더)
p2 = "_ENc_ECrypt"  # JPEG② EOI 와 PNG 사이 평문 37바이트
p3 = "_yo}"         # PNG 의 IDAT 길이 필드 자리에 덮여 있던 4글자
 
print("FLAG =", p1 + p2 + p3)

DH{How_ENc_ECrypt_yo}

설명이 준 DH{JPG_TXT_PNG} 구조와 정확히 대응한다.

10. 방어 관점에서

문제를 떠나 실무로 옮겨 놓고 보면 몇 가지가 남는다.

하드코딩 키는 키가 아니다. funfun은 .rdata 에 평문으로 있었고 strings 한 번에 나왔다. 실행파일 안에 있는 값은 사용자에게 있는 값이다. 여기에 더해 이 구현은 키 6바이트 중 3바이트를 실제로는 쓰지도 않았다 — i & 6 때문에 유효 키 공간이 사실상 3바이트로 줄었다.

직접 만든 RC4 변형은 RC4 보다 약하다. %를 &로 바꾸고 인덱싱을 한 번 더 하는 식의 수정은 안전성을 높이지 않는다. 오히려 이 경우엔 청크마다 상태를 초기화하는 바람에 같은 키스트림 패턴이 1024바이트마다 반복되는 구조가 됐다. 알려진 평문(JPEG 헤더 ff d8 ff e0)이 있으면 키를 몰라도 공격할 여지가 생긴다.

XOR 만으로는 무결성이 없다. 복호 결과가 맞는지 틀린지 프로그램은 알 수 없다. 실제로 나는 잘못된 복호본으로도 "정상 JPEG"을 얻었다(헤더 1024바이트가 맞았으니까). 암호화한 데이터에는 MAC 이나 AEAD 를 붙여야 이런 상황에서 즉시 걸러진다.

포렌식 쪽으로는, 확장자와 file 출력은 파일의 앞부분만 본다는 걸 기억해 둘 만하다. 이번처럼 한 파일에 네 덩어리가 이어붙어 있어도 file은 "JPEG"이라고만 한다. EOI 이후를 확인하는 습관, 그리고 구조 필드의 값이 비상식적이면 그게 오염이 아니라 데이터일 수 있다는 시각이 이 문제의 마지막 관문이었다.

정리

• Enc.exe는 flag.jpg를 두 번 덮어쓴다. 1단계는 RC4 변형, 2단계는 인덱스 홀짝 XOR
• RC4 변형의 함정 셋: key[i & 6], 키스트림 S[S[t]], 0x400 청크마다 S 박스 재생성
• 셋째를 놓치면 앞 1024바이트만 복호돼 "헤더는 맞는데 그림이 깨진" 상태가 된다
• 복호본은 JPEG + 헤더 없는 JPEG + 평문 37B + PNG 가 이어붙은 한 파일
• 플래그 세 조각 중 마지막은 PNG 의 IDAT 길이 필드 자리에 있어 그림으로는 안 보인다