[🥈 Silver 4] 화면에 아무것도 안 뜨는 바이너리에서 flag 뽑아내기 — DreamHack fake 풀이

문제: DreamHack — fake 분류: Reversing 난이도: 🥈 Silver 4 FLAG: DH{SMC_R3vers1ng_chall}

파일 하나짜리 평범한 리버싱 문제처럼 보였다. file로 확인하면 그냥 stripped PIE ELF. 그런데 실행해봐도, 입력을 줘도, 아무 일도 일어나지 않는다. 프롬프트도, 에러 메시지도, 성공/실패 메시지도 전혀 없다. 문제 제목이 "fake"인데, 풀고 나니 이 프로그램이 "겉으로 보여주는 것"이 통째로 가짜였다는 뜻이었다 — 애초에 뭔가를 보여줄 생각 자체가 없는 프로그램이었다.

문제 설명 맨 아래에는 "언인텐 수정완료 [2024.12.21]"이라는 문구도 붙어 있었다. 출제자가 의도하지 않은 지름길(unintended solution)이 한 번 발견돼서 막혔다는 뜻인데, 어떤 지름길이었는지는 알 길이 없었지만 적어도 "이 문제는 정공법으로 풀리도록 다시 손봐졌다"는 신호로는 받아들일 만했다. 실행조차 관찰 불가능한 바이너리에서 어떤 지름길이 있었을지 상상하기 어려웠는데, 끝까지 풀고 나서 돌이켜보면 아마 힙 메타데이터를 이용한 우회이지 않았을까 싶다 — 확인할 방법은 없지만, 최소한 지금 이 바이너리에서는 그런 수가 통하지 않는다는 것만은 분명했다.

문제 개요

바이너리 하나만 주어진다. 문제 설명은 짧다: format:DH{...}, "simple reversing challenge". 일단 실행해봤다.

보호기법은 전부 켜져 있지만 이 문제와는 무관해 보인다. Full RELRO, 스택 카나리, NX, PIE, 심지어 최신 CPU 기능인 Shadow Stack(SHSTK)·Indirect Branch Tracking(IBT)까지 — 사용자 입력을 아예 받지 않는 프로그램에 이 정도로 완전한 보호기법 세트를 붙여둔 건 다소 과해 보였다. 나중에 알게 됐지만, 이건 아마 "이 바이너리를 공격 대상으로 착각하게 만드는" 또 하나의 미끼였을 것이다 — 보호기법이 촘촘한 걸 보면 반사적으로 "메모리 손상 취약점을 찾아야 하나"라는 생각이 먼저 드는데, 이 문제는 애초에 pwn이 아니라 순수 리버싱이었다.

진짜 눈에 띄는 건 임포트 목록이다. malloc, free, __cxa_finalize, __stack_chk_fail — 이게 전부다. read도, write도, puts도, printf도 없다. 표준 C 프로그램이라면 사용자와 뭔가 주고받기 위해 최소한 하나는 있어야 할 함수들이 통째로 빠져 있다. strings로 훑어봐도 프롬프트나 성공/실패 메시지 문자열이 하나도 안 보인다.

🔬 정찰 — strace가 확인해준 사실: 이 프로그램은 정말 아무것도 안 한다

혹시 못 보고 지나친 syscall이 있을까 싶어 strace로 직접 감시했다. stdin에 아무 값이나 흘려보내면서 실행했다.

brk()로 힙을 늘리고, ASLR/스택 카나리용 getrandom()을 한 번 호출하고, 그대로 exit_group(0)으로 끝난다. stdin에 넣은 값은 단 한 바이트도 읽히지 않는다. 이 프로그램은 사용자 입력과 무관하게 항상 똑같이 동작하고, 그 결과를 어디에도 출력하지 않는다. 그렇다면 "정답을 맞히는" 문제가 아니라 — 이 프로그램이 메모리 안에서 조용히 계산해내는 값이 무엇인지를 정적으로 재구성해야 하는 문제라는 뜻이다.

objdump -d -M intel로 main()부터 따라가봤다.

구조는 단순하다. init()을 호출해 뭔가를 malloc한 포인터를 받고(NULL이면 조기 종료), f1357(ptr) → f1521(ptr) → f1357(ptr) 순서로 세 번 호출한 뒤, free(ptr->data)와 free(ptr)를 호출하고 끝난다. 출력 함수 호출은 이 흐름 어디에도 없다.

마지막 두 free 호출의 순서도 눈여겨볼 만하다. 안쪽 버퍼(ptr->data)를 먼저 해제하고, 그 다음에 바깥 구조체(ptr)를 해제한다 — 자식을 먼저 정리하고 부모를 나중에 정리하는, 중첩 포인터를 다루는 정석적인 해제 순서다. 순서가 반대였다면(구조체를 먼저 해제한 뒤 그 구조체를 통해 ptr->data에 접근하려 했다면) use-after-free가 됐을 텐데, 이 바이너리는 그 함정을 정확히 피해가고 있다. 취약점을 심어두는 문제가 아니라 정말 "계산 결과를 조용히 만들고 치우는" 것 자체가 목적인 프로그램이라는 정황이 여기서도 확인됐다.

💣 핵심 — 시드 버퍼 하나가 세 번 변환되고 그대로 사라진다

init()(주소 0x140b)부터 다시 봤다. 이 함수가 하는 일은 malloc된 24바이트 버퍼에 23바이트짜리 시드 데이터를 채워 넣는 것이다.

movabs rax, 0x595468565f5b5b4a와 movabs rdx, 0x6841044552064450 두 개(8바이트씩 16바이트), 그리고 mov DWORD/WORD/BYTE로 4+2+1=7바이트를 더 채워서 정확히 23바이트(0x17)를 만든다. 이 값들이 스택에서 malloc된 힙 버퍼로 그대로 복사된다 — **이게 이 프로그램이 다루는 유일한 "데이터"**다.

이제 f1521(진짜 변환 함수) 차례다. 열어보면 세 개의 하위 함수를 순서대로 호출할 뿐이다.

• reverse: 버퍼 전체를 앞뒤로 뒤집는다.
• swap_pairs: (0,1), (2,3), (4,5) ... 인접한 두 바이트씩 서로 맞바꾼다.
• xor_key: 모든 바이트를 0x37로 XOR한다.

세 함수 다 인자는 { char *data; size_t len; } 구조체 포인터 하나뿐이고, 전부 그 자리에서 버퍼를 직접 고쳐 쓴다(in-place). 이 세 단계를 거친 버퍼가 바로 free()로 넘어가는 마지막 상태다 — 콘솔에 한 글자도 안 찍히지만, 메모리 안에서는 분명히 무언가가 완성돼 있다.

여기서 한 가지 짚어둘 부분은 xor_key의 키 값 0x37이다. 이번엔 이 값이 즉시값(mov esi, 0x37)으로 코드에 그대로 박혀 있어서 바로 읽을 수 있었지만, 만약 키가 난독화돼 있었다면 접근이 달라졌을 것이다. XOR은 자기 자신의 역연산이라((x ^ k) ^ k = x) 키를 몰라도 결과가 사람이 읽을 수 있는 ASCII 범위(0x20~0x7e)에 들어오는 키를 전수조사(256가지뿐이니 사실상 즉시 끝난다)해서 후보를 좁히는 방법도 충분히 통했을 것이다 — XOR 단일 바이트 키는 애초에 브루트포스에 가장 취약한 축에 속하는 변환이라, 굳이 키 자체를 정적으로 찾아내지 못했더라도 큰 장애물은 아니었을 거라는 뜻이다.

🎯 자체 완결 solve

시드 버퍼 23바이트를 그대로 옮기고, reverse → swap_pairs → xor_key(0x37)를 파이썬으로 재현했다.

import struct
 
chunk1 = struct.pack("<Q", 0x595468565F5B5B4A)
chunk2 = struct.pack("<Q", 0x6841044552064450)
chunk3 = struct.pack("<I", 0x4C747A65)
chunk4 = struct.pack("<H", 0x7364)
chunk5 = struct.pack("<B", 0x7F)
buf = bytearray(chunk1 + chunk2 + chunk3 + chunk4 + chunk5)
n = len(buf)
 
# reverse
i = 0
while i < (n >> 1):
    j = n - i - 1
    buf[i], buf[j] = buf[j], buf[i]
    i += 1
 
# swap adjacent byte pairs
i = 0
while i + 1 < n:
    buf[i], buf[i + 1] = buf[i + 1], buf[i]
    i += 2
 
# xor with key 0x37
for i in range(n):
    buf[i] ^= 0x37
 
print("[+] FLAG:", buf.decode())

DH{SMC_R3vers1ng_chall}이 나왔다. DH{로 시작해서 }로 끝나는 것 자체가 시드 값과 변환 순서를 제대로 읽었다는 강한 증거였지만, 프로그램을 한 번도 실행하지 않고 어셈블리만 읽어서 낸 결론이라 한 번은 직접 확인해보고 싶었다. 이 바이너리는 (앞서 확인했듯) 콘솔에는 아무것도 안 찍지만, free()로 넘어가기 직전 그 메모리는 실제로 존재한다 — gdb로 free()에 브레이크포인트를 걸고 첫 번째 호출의 인자(rdi, 즉 해제될 버퍼 주소)를 문자열로 찍어봤다.

free() call #1, arg (rdi) = DH{SMC_R3vers1ng_chall} — 파이썬으로 계산한 값과 한 글자도 다르지 않다. 이 바이너리는 스스로 그 값을 절대 보여주지 않지만, 살아있는 프로세스의 힙을 gdb로 들여다보면 확실하게 존재를 확인할 수 있다. 이 flag를 드림핵에 제출해 정답으로 확정됐다.

DH{SMC_R3vers1ng_chall}에서 SMC가 정확히 뭘 줄인 말인지는 출제자만 알겠지만, 문맥상 "Self-Modifying Code"의 약자로 읽는 게 가장 자연스럽다. 이 바이너리가 정말로 자기 자신의 코드를 고쳐 쓰는(전통적인 의미의 SMC) 건 아니지만, 자신이 만든 데이터를 스스로 세 번 연속 변형하고, 그 결과를 한 번도 외부에 노출하지 않은 채 조용히 해제한다는 동작 자체가 "겉으로 드러나지 않는 자기 변형"이라는 주제와 잘 어울린다. 리버서 입장에서 이런 프로그램을 상대할 때는, 프로그램이 스스로를 드러내주길 기다리는 대신 그 변형 과정 자체를 코드 밖에서 그대로 재현해버리는 쪽이 유일한 실전적인 접근이었다.

📝 결론

이 문제가 특이했던 지점은 "실행해서 확인한다"는, 리버싱에서 가장 기본적인 검증 수단 자체가 애초에 통하지 않도록 설계돼 있었다는 점이다.

• 임포트 목록을 가장 먼저 확인하는 습관이 시간을 크게 아껴줬다. read/write 계열이 하나도 없다는 걸 처음에 알았다면, "입력을 넣고 출력을 기다리는" 식의 접근을 아예 시도조차 하지 않고 바로 정적분석으로 들어갈 수 있었다. 나는 먼저 몇 번 실행해보고 나서야 임포트를 확인했는데, 순서를 바꿨다면 더 빨랐을 것이다. 리버싱 문제를 받으면 반사적으로 ./chall부터 실행해보는 습관이 있는데, 이 문제는 그 습관이 통하지 않는 사례였고, 앞으로는 checksec/file 다음 순서로 임포트 목록부터 확인하는 걸 기본 루틴에 넣어두는 게 나을 것 같다.
• 그럴듯해 보이는 계산이 항상 검증 로직인 건 아니다. f1357처럼 "체크섬을 계산하는 것처럼 생긴" 코드가 실제로는 결과를 어디에도 쓰지 않는 디코이일 수 있다. 그 계산 결과가 프로그램의 나머지 동작에 실제로 영향을 주는지(변수에 저장돼 이후 분기나 쓰기 연산에 쓰이는지)를 끝까지 추적해보기 전에는 "이게 핵심이다"라고 단정하지 않는 게 안전했다.
• 출력이 없어도 gdb는 살아있는 메모리를 보여준다. 이 바이너리처럼 콘솔 출력이 전혀 없는 프로그램이라도, 힙에 할당된 데이터는 실제로 존재하고 free() 같은 함수 호출 시점에 인자로 그 주소가 넘어간다. 표준 출력을 가로챌 수 없다고 해서 런타임 검증이 불가능한 건 아니다 — 어떤 함수가 그 데이터를 인자로 받는지만 찾으면 거기에 브레이크포인트를 걸면 된다.

방어자 관점에서 보면, 이 문제는 "관찰 가능한 출력이 없다"는 것과 "안전하다"는 것이 전혀 다른 이야기라는 걸 보여준다. 실전에서도 로그를 전혀 남기지 않거나 응답을 돌려주지 않는 프로세스가 "블랙박스라서 안전하다"고 오해받는 경우가 있는데, 디버거나 메모리 포렌식 도구 앞에서는 그 어떤 프로그램도 완전한 블랙박스가 될 수 없다. 민감한 데이터를 다루는 프로세스라면 콘솔 출력 여부와 무관하게, 그 데이터가 메모리에 얼마나 오래 평문으로 남아있는지, 힙 할당자에 전달되는 순간까지도 노출 경로가 될 수 있다는 걸 함께 고려해야 한다.

이 문제를 처음 봤을 때는 "출력이 없으면 풀 방법도 없는 것 아닌가"라는 생각이 잠깐 스쳤다. 하지만 리버싱이라는 작업 자체가 원래 "프로그램이 스스로 말해주는 것"에 의존하는 게 아니라 "프로그램이 어떻게 만들어졌는지를 코드로부터 직접 읽어내는" 작업이라는 걸 생각하면, 출력의 유무는 사실 부차적인 문제였다. 실행 결과를 눈으로 확인하는 건 정적분석이 맞았는지 검증하는 여러 수단 중 하나일 뿐이지, 그게 유일한 진입점은 아니다 — 이번엔 그 검증 수단이 표준 출력 대신 gdb였을 뿐이다.