[🥈 Silver 4] 10²²년짜리 잠을 0.3초로 줄이기 — DreamHack Long Sleep 풀이 (2번 보류 끝에 해결)

문제: DreamHack — Long Sleep 분류: Reversing 난이도: 🥈 Silver 4 FLAG: DH{406b2742ffb2a6cac02abb8f303fa12067f8061339979855108ce4a2e38ef558}

이 문제도 세 번째 시도 만에 풀렸다. 지난 두 세션은 파일 패치, 소프트웨어 브레이크포인트, ptrace 레지스터 조작을 순서대로 시도하다가 전부 막혀서 "타이밍 기반 안티템퍼일 것"이라는 추측만 남기고 보류했다. 오늘 다시 붙어 바이너리를 처음부터 제대로 읽어보니, 애초에 "안티템퍼가 하나"라는 전제 자체가 틀려 있었다 — 이 프로그램은 서로 완전히 무관한 두 개의 방어를 겹쳐 갖고 있었다.

문제 개요

실행하면 이렇게 흘러간다.

$ ./prob
Wait! I'm generating flag!!
(... 한참 멈춤 ...)
Here's your flag: DH{...}

file/checksec로 보호기법부터 확인했다. PIE, Full RELRO, 카나리, NX, SHSTK/IBT(CET)까지 켜진 최신 빌드 조합이다. strings로 뽑아보면 앞으로 마주칠 모든 문구가 이미 다 나와 있다 — "생성 중" 안내, flag 접두어, 그리고 안티템퍼 실패 메시지.

▶🕳️ 삽질 — 지난 두 세션, '하나의 방어'라고 착각하고 계속 막혔다

그동안의 시도를 순서대로 다시 정리하면 이렇다.

시도 1 — 파일을 직접 패치. syscall 명령(0f 05) 두 바이트를 nop(90 90)으로 바꿔 실행 파일 자체를 수정한 뒤 실행했다. sleep 자체를 아예 없애버리면 되지 않을까 하는 단순한 발상이었다. 결과는 곧바로 *** assertin failed *** integrity_check(): file has been corrupted. — sleep이 시작되기도 전에, 거의 즉시 실패했다.

시도 2 — gdb 소프트웨어 브레이크포인트로 syscall 건너뛰기. break *<syscall주소> 를 걸고 명령어를 건너뛰는 방식을 시도했다. 이것도 똑같이 즉시 corrupted가 떴다.

시도 3 — ptrace로 레지스터만 조작(메모리 패치 없이). syscall 진입 지점에서 $rax/$orig_rax를 39(getpid)로 바꿔치기해서 nanosleep 대신 즉시 끝나는 syscall을 대신 실행시키려 했다. 이번엔 corrupted가 뜨지 않았지만, 관찰이 이상하게 불안정했다 — catch가 계속 반복되기만 하고 다음 단계로 넘어가는 느낌이 없었다.

세 번의 시도를 겪고 나서 "corrupted가 뜨는 조건과 뜨지 않는 조건" 사이의 차이를 timing으로 해석했다 — "실제 경과 시간을 재는 검증일 것"이라는 추측이었다. 결과적으로 이 추측은 틀렸다. 이번에 main을 처음부터 다시 읽고 나서야 진짜 구조가 보였다.

디스어셈블리를 따라가 보면, ELF의 .init_array(생성자 목록)에 함수가 두 개 등록되어 있다.

첫 번째(0x1220)는 흔한 register_tm_clones 트램폴린이고, 두 번째(0x1229)가 진짜 코드다. 이 함수는 main()이 시작되기도 전에 — glibc가 프로그램 시작 시 자동으로 실행하는 생성자로서 — 자기 자신의 코드 영역 0x1367부터 0x1000바이트(4096바이트, main 함수와 flag 생성 로직, sleep 함수까지 전부 포함하는 범위)를 SHA256으로 해시한 뒤, 바이너리에 하드코딩된 32바이트 값과 memcmp로 비교한다. 다르면 그 자리에서 corrupted 메시지를 출력하고 exit(-1).

즉 이 검사는 타이밍과 아무 관계가 없다. 파일을 패치하면 그 변조가 코드 영역에 그대로 남아 해시가 달라지고, gdb 소프트웨어 브레이크포인트도 대상 주소에 0xCC 바이트를 실제로 써넣기 때문에 똑같이 해시가 어긋난다 — 둘 다 sleep이 한 번도 실행되기 전, 프로그램이 시작되자마자 실패하는 게 당연했다. 반대로 시도 3(레지스터만 바꾸고 메모리는 안 건드림)이 corrupted를 유발하지 않았던 것도 이 가설과 정확히 들어맞는다 — 그건 관찰이 잘못된 게 아니라 애초에 옳은 방향이었다. 다만 레지스터 조작 방식 자체에 다른 버그가 있었을 뿐이다(뒤에서 다시 나온다).

💣 핵심 1 — 자체 코드 해시와 실행 속도는 서로 다른 층이다

정리하면 이 바이너리는 두 개의 독립적인 방어를 갖고 있다.

1. 정적 방어 (생성자, main 이전): 자기 코드 4096바이트의 SHA256을 계산해 하드코딩된 값과 비교. 코드 바이트가 조금이라도 바뀌면 실패. 시간과는 무관.
2. 동적 방해 (SHA256 압축 함수 안): syscall(SYS_nanosleep, ...) 을 PLT나 libc 심볼을 거치지 않고 직접 호출. 매 64바이트 블록을 처리할 때마다 한 번씩, 전역 카운터를 N → 2*(N+1)로 불려가며 tv_sec에 그 값을 채워 넣는다.

syscall 명령을 직접 쓴다는 점이 중요하다. 일반적인 sleep()/nanosleep() 호출이었다면 LD_PRELOAD로 libc 심볼을 가로채는 흔한 우회가 통했겠지만, 이 코드는 PLT 자체를 거치지 않으므로 후킹할 심볼이 없다 — 실제로 지난번에 LD_PRELOAD로 ptrace()를 무력화하는 시도가 이 syscall엔 아무 영향을 주지 못했던 이유이기도 하다(그건 다른 함수 얘기였지만, 같은 맥락의 함정이다).

이 sleep 함수는 어디서 호출될까 궁금해서 호출자를 계속 따라 올라갔더니, 놀랍게도 main이 계산하는 "flag"의 정체가 드러났다. main은 sha256_init → sha256_update(ctx, "I will evolve into SUPER FLAG!!!!", 33) → sha256_final을 순서대로 호출해서 나온 32바이트 다이제스트를 64자 hex로 출력할 뿐이다. flag는 그냥 고정 문자열의 SHA256이다. 그리고 sleep 호출은 이 SHA256의 압축 함수(64바이트 블록 하나를 처리하는 부분) 안에 끼워 넣어져 있다 — 계산 로직 자체와는 아무 상관이 없고, 그저 "블록 하나 처리할 때마다 대기시키는" 훼방꾼으로 삽입된 것이다.

그리고 생성자(0x1229)도 자기 자신을 검증하기 위해 4096바이트(64블록)를 같은 SHA256 압축 함수로 해시한다 — 즉 생성자 자신도 이 sleep 폭탄을 밟는다. 두 검사(자체 해시 + flag 계산)를 합치면 sleep이 총 96번 걸린다는 걸 나중에 실측으로 확인했다.

🎯 자체 완결 solve

방향은 명확해졌다. 코드 바이트는 한 글자도 건드리지 말고, syscall이 읽어갈 timespec 인자값만 조작한다. gdb의 catch syscall은 커널 PTRACE_SYSCALL 메커니즘을 쓰기 때문에 소프트웨어 브레이크포인트(0xCC)와 달리 .text에 어떤 바이트도 쓰지 않는다 — 자체 코드 해시 검증을 건드릴 이유가 없다.

def on_stop(event):
    orig_rax = int(gdb.parse_and_eval("$orig_rax"))
    if orig_rax != 35:      # SYS_nanosleep
        return
    rdi = int(gdb.parse_and_eval("$rdi"))   # timespec* 인자
    gdb.execute(f"set variable *(long*){rdi} = 0")
    gdb.execute(f"set variable *(long*)({rdi}+8) = 1000")
 
gdb.events.stop.connect(on_stop)
gdb.execute("catch syscall nanosleep")
gdb.execute("run < /dev/null")

처음 이 스크립트를 돌렸을 때, $rax로 syscall 번호를 확인하는 조건(if rax == 35)을 썼는데 계속 아무 것도 패치되지 않고 프로그램이 멈춰버렸다.

rax=-38. -38은 -ENOSYS다. 여기서 지난번에 정확히 걸려 넘어졌던 그 함정을 다시 만났다 — ptrace의 syscall-enter 정지 시점에는 $rax가 아직 진짜 syscall 번호를 담고 있지 않다. 커널은 이 시점의 rax를 -ENOSYS 플레이스홀더로 채워두고, 진짜 syscall 번호는 별도의 $orig_rax 레지스터에 넣어둔다(이건 x86-64 ptrace의 잘 알려진 동작이다 — syscall-enter/exit이 같은 정지 이벤트로 겹쳐 보이기 때문에, "이게 지금 들어가는 중인지 나가는 중인지"를 커널이 이런 방식으로 구분해준다). $orig_rax로 바꾸자마자 정상 동작했다.

패치된 호출은 정확히 96번이었다. 이게 얼마나 큰 숫자인지 감을 잡으려고, 우회 없이 이 수열을 실제로 다 기다렸다면 걸렸을 시간을 계산해봤다.

우회 없이 다 기다렸다면 약 10²²년 — 우주 나이(약 1.4×10¹⁰년)보다 10¹²배 이상 긴 시간이다. 실제 우회 실행은 0.32초만에 끝났다. "몇 회차까지는 버틸 만하지 않을까"라는 지난번 마지막 메모는, 정확히 확인해보니 애초에 성립할 수 없는 질문이었다.

Wait! I'm generating flag!!
Here's your flag: DH{406b2742ffb2a6cac02abb8f303fa12067f8061339979855108ce4a2e38ef558}

이 flag를 드림핵에 제출해 "정답! 해결 처리됨"으로 확정됐다.

📝 결론

이 문제가 준 교훈은 두 가지 층위로 나뉜다.

• "안티템퍼처럼 보이는 실패"가 전부 같은 원인이라고 가정하지 말아야 한다. 파일 패치와 소프트웨어 브레이크포인트가 똑같이 corrupted를 유발했을 때, 그 공통점이 "메모리를 건드렸다"는 사실이었을 뿐 "타이밍이 흐트러졌다"는 뜻은 전혀 아니었다. 두 실패의 공통 원인을 정확히 짚지 못하면(이번엔 "코드 바이트 변경"이 진짜 공통점이었다), 엉뚱한 가설(타이밍) 쪽으로 두 세션을 허비하게 된다.
• syscall 명령을 직접 쓰는 코드는 심볼 기반 후킹(LD_PRELOAD)이 통하지 않는다. libc 함수 이름을 가로채는 방어 우회는 애초에 "그 이름의 함수가 호출된다"는 전제 위에 서 있다. 0f 05(syscall) 명령이 코드에 인라인으로 박혀 있으면 그 전제 자체가 깨진다 — 대신 ptrace/gdb catch syscall처럼 커널이 syscall 진입/탈출을 인식하는 지점에서 개입해야 한다.
• 정적 방어(코드 무결성)와 동적 방해(실행 속도)는 서로 다른 표면이고, 우회 수단도 달라야 한다. 코드 무결성은 "메모리를 안 바꾸면" 통과하고, 실행 속도는 "syscall의 인자값을 바꾸면" 우회된다. 이 둘을 분리해서 보지 못하면, 코드를 건드리는 우회(파일 패치, 소프트 브레이크포인트)로 실행 속도 문제까지 해결하려다가 정작 더 예민한 무결성 검사에 먼저 걸린다.
• ptrace 기반 도구를 직접 다룰 때는 syscall-enter의 $rax가 -ENOSYS 플레이스홀더라는 사실을 반드시 기억해야 한다. 진짜 syscall 번호는 $orig_rax에 있다. 이 구분을 놓치면 "catch는 되는데 아무 로직도 안 걸린다"는, 원인을 짐작하기 어려운 조용한 실패로 이어진다 — 지난번에 "관찰이 불안정하다"고 적었던 바로 그 증상이었다.

방어자 관점에서 보면, 코드 자체 해시 검증(생성자에서 실행되는 self-integrity check)은 정적 패치에 대해 상당히 효과적인 방어였다. 반면 "syscall을 압축 함수 안에 끼워 실행을 늦춘다"는 아이디어는, syscall 인자를 조작하는 동적 개입 앞에서는 사실상 무력했다 — 코드를 건드리지 않고도 그 코드가 만들어내는 "효과"만 무력화할 수 있는 지점이 존재한다면, 방어는 그 지점까지 고려해서 설계돼야 한다는 걸 이 문제가 잘 보여준다.