[🥉 Bronze 3] stripped Rust 바이너리에서 스택 key 를 뽑아 XOR 역산 — DreamHack Rusty Gyul 풀이

문제: DreamHack — Rusty Gyul 분류: Reversing 난이도: 🥉 Bronze 3 FLAG: B1N4RY{Z2FtZ3l1bG11a2dvc2lwZGE=}

바이너리 하나가 덜렁 주어진다. 실행하면 굵은 = 배너와 함께 Gyullllllllll!!!!! 를 외치고 플래그를 입력받은 뒤, 틀리면 [-] Wrong flag. Try again. 을 뱉는다. 서버도 없고 힌트도 없다. 이 안에 정답을 판별하는 로직이 통째로 들어 있으니, 그 판별을 거꾸로 돌리면 플래그가 손에 잡힌다는 뜻이다.

Rust 로 짜여 심볼이 전부 stripped 된 바이너리라 처음엔 함수 이름 하나 안 보이지만, 검사 로직 자체는 허무할 만큼 단순하다. 이 글은 "그 단순한 한 줄"을 어셈블리에서 찾아 들어가 확인하고 되돌리는 과정이다.

문제 개요

Rusty Gyul 은 드림핵의 "귤(gyul)" 테마 리버싱 시리즈 중 하나다. Packing Tangerines, Gyul Bomb 처럼 이름만 귀엽고 안은 평범한 crackme 인데, 이번엔 그 crackme 를 Rust 로 컴파일해 심볼과 디버그 정보를 걷어낸 게 전부다. Rust 라고 겁먹을 필요는 없다 — 컴파일러가 만들어내는 껍데기(런타임 부트스트랩, UTF-8 처리)만 걷어내면 검사 알고리즘은 C 로 짠 것과 다르지 않다.

🔬 정찰

먼저 파일 정체와 안에 박힌 문자열부터 본다.

이 글의 명령은 모두 extracted/ 에서 실행한다.

file rusty_gyul; strings -n 6 rusty_gyul | grep -iE 'Input the flag|Correct! The|Wrong flag|Gyul|Enjoy'

• ELF 64-bit ... pie executable ... stripped — PIE 라 주소는 로드 시마다 바뀌고, 심볼 테이블은 없다.
• 문자열에 Input the flag:, [-] Wrong flag. Try again., [+] Correct! The flag is yours. 가 보인다. 판정 분기가 이 세 문자열 근처에 있을 것이다.
• src/main.rs 같은 Rust 흔적도 남아 있어 소스 언어가 Rust 임을 확인할 수 있다.

메시지만 봐선 어떤 값과 비교하는지 알 수 없다. 판별 코드로 직접 들어가야 한다.

; main (0x165e0) — 진짜 로직이 없다
mov  rdx, rsi                  ; argv
movsxd rsi, edi                ; argc
lea  rdi, [0x16099]            ; <-- 진짜 main 클로저 주소를 넘긴다
xor  ecx, ecx
jmp  0x16457                   ; std::rt::lang_start(...)

💣 진짜 검사 루틴 찾기

main 래퍼가 lang_start 에 넘기는 함수 포인터 0x16099 가 실제 프로그램 본체다. 이 함수를 따라가면 배너 출력 → 한 줄 입력 → 판정까지 전부 들어 있다. 입력을 읽은 직후 두 개의 비슷한 루프가 도는데, 둘 다 같은 서브루틴(0x1653b)을 호출한다. 그 서브루틴을 열어보면 정체가 보인다.

; fcn 0x1653b — char::is_whitespace
lea  ecx, [rdi - 9]
cmp  ecx, 0x18
...                            ; 0x09..0x0d(탭/개행류), 0x20(공백),
cmp  edi, 0x1680               ; 그리고 유니코드 공백(0x1680, 0x2000.., 0x3000 …)
cmp  edi, 0x3000

0x09~0x0d, 0x20, 0x1680, 0x3000 … 딱 봐도 공백 판정이다. 즉 두 루프는 입력 앞쪽과 뒤쪽에서 공백을 걷어내는 str::trim() 이다. 사용자가 엔터를 치며 남긴 개행(\n)을 떼어내는 전형적인 패턴이다. 정리하면 흐름은 이렇다.

1. 한 줄 입력을 받는다.
2. input.trim() — 앞뒤 공백/개행 제거.
3. trim 한 길이가 정확히 32 인지 본다.
4. 32바이트를 한 바이트씩 검사한다.

핵심은 4번이다. 0x16099 함수의 판정 구간(0x16302~)을 objdump 로 잘라, 어떤 명령이 무슨 일을 하는지 주석을 달아 보면 판정의 정체가 그대로 드러난다.

objdump -d --no-show-raw-insn --start-address=0x16302 --stop-address=0x16342 rusty_gyul \
  | sed -E -f notes.sed

읽어보면 이렇다.

• movaps -0x101b1(%rip),%xmm0 / movaps -0x101ed(%rip),%xmm0 — .rodata 두 곳(0x6160, 0x6130)에서 16바이트씩 읽어 스택(rsp+0x30, rsp+0x40)에 이어붙인다. 이게 32바이트 key 다.
• cmp $0x20,%rbp — trim 된 입력 길이가 0x20(=32)이 아니면 바로 오답으로 점프.
• 그리고 루프:

loop:
  cmp  $0x20,%rax                 ; i == 32 이면 -> 정답 출력
  je   correct
  mov  0x30(%rsp,%rax,1),%cl      ; cl = key[i]
  xor  (%rdx,%rax,1),%cl          ; cl ^= input[i]
  inc  %rax
  cmp  $0x55,%cl                  ; (key[i] ^ input[i]) == 0x55 ?
  je   loop                       ; 맞으면 다음 글자, 틀리면 오답

즉 검사식은 단 하나다 — 모든 i(0..31)에 대해 key[i] ^ input[i] == 0x55. XOR 은 자기 역원이니, 이걸 뒤집으면 곧바로 정답이 된다: input[i] = key[i] ^ 0x55.

key 를 이루는 두 블록은 순서가 뒤바뀌어 실린다는 점만 주의하면 된다. 스택에서 낮은 주소(rsp+0x30)에 먼저 실리는 건 0x6160 쪽 16바이트(= key 앞부분), 그다음 rsp+0x40 에 0x6130 쪽 16바이트(= key 뒷부분)다.

🧪 런타임으로 한 번 더 확인

정적 분석만 믿고 넘어가지 않고, gdb 로 실제 실행 중에 그 오프셋과 값이 맞는지 확인한다. PIE 라 로드 주소가 매번 바뀌므로 set disable-randomization on 으로 고정한 뒤, 검사 진입점 (0x16322)과 per-char 비교(0x1633d)에 브레이크포인트를 걸고 정답 플래그를 입력으로 넣어봤다.

gdb -q -batch -x check.gdb --args ./rusty_gyul < input.txt

• rbp = 32 — trim 된 길이가 32로, 길이 검사를 통과한다.
• 스택(rsp+0x30)에서 덤프한 32바이트가 17 64 1b 61 07 0c 2e 0f … — objdump 로 정적으로 짚은 .rodata 값과 정확히 일치한다. key 가 실행 시점에 스택 어디에 실리는지까지 눈으로 확인된 셈이다.
• key[i] ^ input[i] 가 i=0,1,2 … 모두 0x55 — 검사식이 실제로 그렇게 동작한다.

정적으로 읽어낸 구조가 런타임에서도 그대로였다. 이제 되돌리기만 하면 된다.

🎯 풀이 — key 를 뽑아 0x55 로 되XOR

바이너리에서 .rodata 의 두 블록을 그대로 읽어, 스택에 실리는 순서(0x6160 → 0x6130)대로 이어붙인 32바이트 key 를 만들고 각 바이트를 0x55 로 XOR 한다. .rodata 는 파일 오프셋과 가상주소가 같은 구간(둘 다 0x6100 시작)이라 파일에서 바로 잘라 쓰면 된다.

# solve.py
BIN = "rusty_gyul"
XOR = 0x55
 
data = open(BIN, "rb").read()
 
# 스택에 실리는 순서: 0x6160(앞 16B) + 0x6130(뒤 16B)
key = data[0x6160:0x6160 + 16] + data[0x6130:0x6130 + 16]
 
flag = bytes(b ^ XOR for b in key)
print(f"[*] key   = {key.hex()}")
print(f"[*] flag  = {flag.decode()}")
 
import base64
inner = flag[flag.index(b"{") + 1: flag.index(b"}")]
print(f"[*] inner = {base64.b64decode(inner).decode()}   # (base64 decode)")

플래그가 그대로 떨어진다.

B1N4RY{Z2FtZ3l1bG11a2dvc2lwZGE=}

재미있는 건 플래그 안쪽 Z2FtZ3l1bG11a2dvc2lwZGE= 를 base64 로 한 번 더 풀면 gamgyulmukgosipda — "감귤 먹고 싶다" 가 나온다는 점이다. 문제 제목이 왜 Rusty Gyul 인지 알 것 같은 소소한 장난이다.

✅ 검증

복원한 값이 진짜 정답인지, 로컬 바이너리에 그대로 먹여 확인한다. 파이프(echo | ./bin)는 환경에 따라 오동작할 수 있어 subprocess 로 넣는다.

# verify.py
import subprocess
 
flag = "B1N4RY{Z2FtZ3l1bG11a2dvc2lwZGE=}"
r = subprocess.run(["./rusty_gyul"], input=flag + "\n",
                   capture_output=True, text=True)
print("Input :", flag)
print("Output:")
print(r.stdout.strip())

[+] Correct! The flag is yours. 그대로 뜬다. 드림핵에 제출해도 정답 처리된다.

🛡️ 정리 & 방어 관점

이 문제가 주는 교훈은 두 가지다.

리버서 입장 — Rust 바이너리라고 접근이 달라지지 않는다. 심볼이 없어도 (1) 출력 문자열 근처의 분기, (2) main 이 lang_start 에 넘기는 함수 포인터, 이 두 이정표만 잡으면 사용자 로직으로 바로 내려갈 수 있다. libc 후킹(ltrace)이 비어 있으면 "비교가 인라인됐구나" 하고 정적 분석으로 전환하면 된다. 그리고 정적으로 짚은 오프셋·상수는 gdb 런타임으로 한 번 더 확인하는 습관이, "내가 잘못 읽은 것"과 "진짜 그런 것"을 가른다.

방어(문제 출제) 입장 — 정답을 상수로 그대로 들고 있으면(설령 XOR 한 겹을 씌워도) 바이너리를 가진 사람에겐 아무 비밀도 아니다. 여기선 key 32바이트가 .rodata 에 그대로 있고 XOR 상수도 0x55 한 바이트라, 검사 루프 한 눈에 전부 복원된다. 실제로 값을 숨기려면 클라이언트 측 상수 비교가 아니라 서버 검증(입력을 서버로 보내 판정)이나, 최소한 입력에서 파생한 키로만 풀리는 구조여야 한다. crackme 는 원래 "숨긴 척"일 뿐, 바이너리 안의 비교는 언제나 뒤집힌다.