[🥉 브론즈 3] XOR 한 줄로 잠근 랜섬웨어, 키를 거꾸로 뽑아내다 — DreamHack darimchal_001 풀이

문제: DreamHack — darimchal_001 분류: Crypto 난이도: 🥉 Bronze 3 FLAG: pa55uc0

친구 다리미가 드림이의 컴퓨터에 XOR 랜섬웨어를 심었다. 복호화 키를 입력해서 잠금을 풀어야 한다는, 콘셉트가 귀여운 문제다.

핵심은 단 한 줄이다. 입력한 키를 고정 문자열 KEY와 바이트별로 XOR한 뒤, 미리 박혀 있는 JOKER와 같은지만 본다. XOR은 같은 값으로 두 번 걸면 원래대로 돌아오는 자기역원(self-inverse) 연산이라, JOKER를 KEY로 한 번 더 XOR하면 통과 비밀번호가 그대로 튀어나온다.

문제 개요

풀이 흐름은 짧다. 소스에서 검증 한 줄을 읽고 → JOKER ⊕ KEY를 계산해 비밀번호 pa55uc0_를 얻고 → 실제 바이너리 디스어셈블로 그 XOR이 진짜인지 확인한 뒤 → 플래그 형식만 맞춰 제출한다.

🧩 배경 — XOR은 왜 자물쇠이자 열쇠인가

XOR(^)은 대칭이다. 어떤 바이트 p를 키 k로 가리면 c = p ^ k가 되고, 같은 키로 한 번 더 XOR하면 c ^ k = p ^ k ^ k = p로 원래 값이 복원된다. k ^ k = 0이고 p ^ 0 = p이기 때문이다.

이 문제는 그 성질을 그대로 자물쇠로 쓴다. 정답 비밀번호 p를 KEY로 XOR한 결과 JOKER = p ^ KEY를 바이너리에 박아 두고, 사용자가 넣은 입력 x에 대해 x ^ KEY == JOKER인지 검사한다.

그런데 x ^ KEY == JOKER가 성립하려면 x == JOKER ^ KEY여야 한다. 공격자 입장에서는 브루트포스도, 방정식 풀이도 필요 없다. JOKER와 KEY가 둘 다 바이너리 안에 있으니 그냥 둘을 XOR하면 통과 키가 나온다. 가리는 데 쓴 연산이 그대로 여는 열쇠가 된다.

🔬 정찰 — Mach-O 바이너리와 박혀 있는 상수

먼저 파일 종류와, 바이너리에 KEY·JOKER가 실제로 들어 있는지 본다.

file chall1 && strings -a chall1 | grep -nE "023661dd4|CRT;|\.success"

macOS용 Mach-O 64-bit x86_64 실행 파일이다. 리눅스에서 바로 실행되진 않지만, 소스가 같이 주어졌고 상수도 그대로 박혀 있어 분석에는 지장이 없다. strings에 023661dd4(= KEY)가 그대로 보이고, JOKER의 인쇄 가능한 꼬리인 CRT;(0x43 0x52 0x54 0x3b)도 잡힌다. 성공 시 만드는 ./%s.success 태그 파일 이름도 보인다.

🔎 코드 분석 — 검증은 딱 한 줄

동봉된 chall1.c에서 상수와 검증 로직만 추리면 이렇다.

#define JOKER "\x40\x53\x06\x03\x43\x52\x54\x3b"   // 잠긴 값 (8바이트)
#define KEY   "023661dd4"                          // XOR 키 (9바이트)
 
int __is_valid_pwd(char *pwd) {
    // pwd 를 KEY 로 XOR 한 결과가 JOKER 와 같으면 통과
    if (!strncmp(JOKER, __obfuscation(pwd, KEY), sizeof(JOKER)))
        return TRUE;
    return FALSE;
}
 
char *__obfuscation(char *pwd, char *key) {
    for (int i = 0; i < strlen(pwd); i++) {
        if (key[i] == '\0') break;      // 키 길이(9)까지만
        pwd[i] = pwd[i] ^ key[i];       // 바이트별 XOR
    }
    return pwd;
}

__obfuscation은 입력을 KEY로 바이트별 XOR한다. __is_valid_pwd는 그 결과를 JOKER와 strncmp로 비교한다. 통과 조건은 모든 i에 대해 pwd[i] ^ KEY[i] == JOKER[i], 즉 pwd[i] == JOKER[i] ^ KEY[i]다.

비교 길이 sizeof(JOKER)는 문자열 리터럴의 널 종단까지 포함해 9다. JOKER는 8바이트뿐이라 9번째 자리는 널(0x00)이다. 그래서 입력이 정확히 8글자면 그 문자열의 널 종단이 9번째 자리에서 JOKER의 널과 맞아떨어져, 앞 8바이트만 일치시키면 검증을 통과한다.

소스만 믿지 말고, 실제 바이너리에서도 이 XOR이 도는지 radare2로 __obfuscation 루프 본체를 뜯어 본다.

r2 -q -c "pd 13 @ 0x100003d2f" chall1

두 번의 movsx … byte [rax + rcx]로 pwd[i]와 key[i]를 각각 읽어 온 다음, xor edx, esi 한 줄로 XOR하고 mov byte [rax + rcx], dl로 제자리에 덮어쓴다. 그 뒤 add eax, 1로 인덱스를 올려 루프를 돈다. 소스의 pwd[i] ^= key[i]가 바이너리에서도 그대로다.

🎯 풀이 — JOKER ⊕ KEY 한 번

pwd[i] = JOKER[i] ^ KEY[i]를 그대로 코드로 옮기면 끝이다.

# solve.py — JOKER ⊕ KEY 역산
JOKER = bytes.fromhex("40 53 06 03 43 52 54 3b".replace(" ", ""))  # 8 bytes
KEY   = b"023661dd4"                                               # 9 bytes
 
pwd = bytes(j ^ k for j, k in zip(JOKER, KEY))
print("복호화 키(pwd):", pwd.decode())      # -> pa55uc0_
 
# 검증: 다시 XOR 해서 JOKER 와 일치하는지
check = bytes(p ^ k for p, k in zip(pwd, KEY))
print("re-XOR      :", check.hex(" "), "==JOKER?", check == JOKER)

JOKER ⊕ KEY = pa55uc0_. 다시 KEY로 XOR한 값이 원래 JOKER와 정확히 일치(==JOKER? True)하니, 이 문자열이 바이너리를 여는 비밀번호가 맞다. 8글자라 strncmp 9바이트 비교도 널 종단으로 자연히 통과한다.

🐛 삽질 — 통과 키는 찾았는데 플래그가 자꾸 오답

여기서 한참 헤맸다. 통과 비밀번호 pa55uc0_는 확실한데, 드림핵에 제출할 플래그 형식이 예상과 달랐다.

댓글이 알려준 대로 DH{}를 떼고 끝 언더바도 뺀 **pa55uc0**를 제출하니 정답 처리됐다(워게임 auth API HTTP 201, 문제 상태 is_completed: true).

바이너리를 여는 비밀번호(pa55uc0_)와 채점용 플래그(pa55uc0)가 미묘하게 다른, 형식 함정이 있는 문제였다.

📝 결론

XOR은 가린 방법이 곧 여는 방법이다.

정답을 KEY로 XOR해 숨겨 놨다면, 그 KEY와 숨긴 값이 같은 바이너리 안에 있는 한 XOR 한 번으로 그대로 복원된다. 대칭키를 평문 옆에 함께 두는 순간 난독화는 장식일 뿐이다.

소스가 있어도 실제 바이너리를 한 번은 확인한다.

이번엔 소스와 바이너리가 일치했지만, 제공 소스가 단순화판이거나 상수가 다를 수 있다. strings로 KEY·JOKER가 실제로 박혀 있는지, radare2로 그 XOR 루프가 정말 도는지 눈으로 확인하고 나서야 계산을 믿을 수 있었다.

마지막 관문은 암호가 아니라 형식이었다.

키를 다 풀고도 DH{} 래퍼와 언더바 때문에 두 번 오답을 받았다. 검증을 통과하는 키와 채점용 플래그가 항상 같지는 않다는 것 — 막히면 문제 설명·댓글의 형식 힌트부터 다시 보는 게 빠르다.