[🥇 Gold 1] 브라우저 안 wasm 한 덩어리 되돌리기 — DreamHack passcode 풀이

문제: DreamHack — passcode 분류: reversing 난이도: 🥇 Gold 1 FLAG: DH{W3B@sSemb1y_R3ver5in9_^-^}

문제 설명은 한 줄이다. "올바른 passcode를 찾아 DH{} 포맷에 넣어서 인증해주세요!"

받은 압축을 풀면 파일이 둘뿐이다. 서버도 없고 ELF도 없다.

ls -l extracted && file extracted/index.html extracted/main.js && wc -c extracted/main.js

ls -l 과 file 로 확인한 배포본 — index.html 1654바이트와 main.js 9038바이트 둘뿐이고, main.js 는 8051자짜리 한 줄이 들어 있는 JavaScript 소스로 잡힌다

main.js가 9,038바이트인데 그중 8,051자가 한 줄이다. 열어 보면 그 한 줄이 뭔지 바로 나온다.

문제 개요

항목	내용
문제명	passcode
난이도	🥇 Gold 1
분류	reversing
제공 파일	`index.html`, `main.js` (서버 없음, 완전 오프라인)
스택	브라우저 · WebAssembly MVP · jQuery · SweetAlert2 · Bulma
핵심 취약점 / 기법	바이트를 섞지 않는 치환 사슬 — 위치별 전수 역산

풀이 흐름은 이렇다. main.js에 박힌 바이트 배열을 파일로 떼어 내 wasm 모듈로 만들고, wabt로 디컴파일해 검사 함수 f()를 읽는다. 루프가 바이트를 섞지 않는다는 걸 확인한 다음, 선형 메모리에서 상수 테이블 세 개를 그대로 떠내고, 위치마다 256개 후보를 정방향으로 돌려 답을 확정한다. 마지막으로 진짜 wasm과 진짜 브라우저에 먹여 맞는지 본다.

🧩 배경 — 브라우저에서 wasm이 도는 가장 작은 형태

main.js는 세 부분이다. 첫 줄이 바이트 배열, 그다음이 인스턴스화, 나머지가 폼 핸들러.

code = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 17, 3, 96, 0, 0, /* ... 1984개 ... */]);
WebAssembly.instantiate(code).then(result => {
    instance = result.instance;
});

0, 97, 115, 109는 \0asm이다. wasm 매직 넘버를 십진수로 늘어놓은 것뿐이라, 이 배열이 곧 하나의 wasm 모듈 파일이다. 네트워크로 .wasm을 받아 오지 않고 JS 소스 안에 통째로 넣어 뒀다.

검사는 폼 submit에서 일어난다.

$('#passcode-form').on('submit', function(e) {
    e.preventDefault();
    passcode = $('#passcode').val();
    array = new Uint8Array(instance.exports.memory.buffer, 0, passcode.length)
    array.set(passcode.split('').map(x => x.charCodeAt()));
    result = instance.exports.f(array.byteOffset, array.length);
    if (!result) { /* Swal: Correct! */ } else { /* Swal: Wrong! */ }
});

여기서 눈여겨볼 게 두 개다.

입력이 선형 메모리 0번지에 그대로 써진다. wasm 선형 메모리는 그냥 하나의 ArrayBuffer라 JS 쪽에서 아무 오프셋이나 잡아 쓸 수 있고, 이 페이지는 0번지를 골랐다. 그리고 f()에 넘기는 건 그 주소(byteOffset = 0)와 길이다.

그리고 판정이 if (!result)다. f()가 0을 돌려주면 정답이다. C의 memcmp 관례가 그대로 화면까지 올라온다.

먼저 배열을 파일로 떼어 냈다. 손으로 세는 대신 정규식 한 줄로 긁는다.

#!/usr/bin/env python3
"""main.js 1행의 Uint8Array 리터럴을 그대로 꺼내 passcode.wasm 으로 저장한다."""
import re, pathlib
 
src = pathlib.Path("extracted/main.js").read_text()
m = re.search(r"new Uint8Array\(\[(.*?)\]\)", src, re.S)
nums = [int(x) for x in m.group(1).split(",")]
blob = bytes(nums)
pathlib.Path("passcode.wasm").write_bytes(blob)
print(f"bytes={len(blob)} magic={blob[:4].hex()} version={int.from_bytes(blob[4:8],'little')}")

wabt는 시스템에 없어서 npm으로 받았다(npm i wabt). 이 패키지는 JS 바인딩뿐 아니라 node_modules/wabt/bin/ 아래에 wasm-objdump·wasm-decompile·wasm-validate 실행파일까지 같이 깔아 준다.

python3 extract_wasm.py && file passcode.wasm && ./node_modules/wabt/bin/wasm-validate passcode.wasm && echo "wasm-validate: OK"

extract_wasm.py 로 뽑아낸 passcode.wasm 1984바이트 — file 은 WebAssembly binary module version 0x1 로 보고하고, wabt 의 wasm-validate 도 이의 없이 OK 로 답한다

1,984바이트. 검증도 통과한다. 이제부터는 브라우저를 잊고 바이너리 하나만 본다.

🔬 정찰 — 섹션과 export부터

wasm-objdump -h로 섹션 배치를 본다.

./node_modules/wabt/bin/wasm-objdump -h passcode.wasm

wasm-objdump -h 로 본 섹션 배치 — Code 가 0x22b, Data 가 0x228 바이트이고 그 뒤로 .debug_info · .debug_line · .debug_str 커스텀 섹션이 통째로 남아 있다

Code가 0x22b(555바이트), Data가 0x228(552바이트). 코드보다 데이터가 거의 같은 덩치라는 게 첫 힌트다. 상수 테이블이 크다는 뜻이다.

그리고 디버그 섹션이 스트립되지 않았다. .debug_str을 훑으면 빌드 환경이 그대로 나온다.

strings -a -n 8 passcode.wasm | grep -iE "musl|clang|wasmception|memcmp"

/home/yury/Work/wasmception/src/musl/src/string
memcmp.c
.debug_strclang version 8.0.0 (trunk 341960)
/home/yury/Work/wasmception/src/musl/src/string/memcmp.c
/home/yury/Work/wasmception/build/musl

wasmception이라는 초기 standalone wasm 툴체인으로, clang 8.0.0 트렁크로 빌드했고, musl의 memcmp.c가 그대로 링크됐다. 풀이에 꼭 필요한 정보는 아니지만 "이 안에 memcmp가 진짜로 들어 있다"는 걸 미리 알려 준다.

내보내는 심볼은 넷뿐이다.

./node_modules/wabt/bin/wasm-objdump -x -j Export passcode.wasm

wasm-objdump -x -j Export 결과 — 내보내는 것은 memory, __heap_base, __data_end, 그리고 func[1] 인 f 넷뿐이고 import 섹션은 아예 없다

그리고 import 섹션이 아예 없다. 바깥에서 아무것도 안 받는다는 뜻이라, f()의 판정은 순전히 자기 안의 상수만으로 이뤄진다. 서버가 없는 문제이니 당연하지만, "네트워크로 정답을 물어보는 구조가 아니다"를 확인하고 가는 게 낫다.

__data_end가 1568이라는 것도 여기서 얻는다. 상수 영역이 어디서 끝나는지 알려 주는 값이다.

💣 f() 뜯어보기

WAT를 바로 읽어도 되지만, wasm-decompile이 C 비슷한 문법으로 뽑아 주는 게 훨씬 빠르다.

./node_modules/wabt/bin/wasm-decompile passcode.wasm -o passcode.dcmp && sed -n "32,52p" passcode.dcmp

wasm-decompile 이 뽑은 f() 의사코드 — 길이 25 검사, 256회 루프, (c and 255) % 25 인덱싱, 1056 XOR, 회전, 1312 조회가 스무 줄 안에 다 보인다

스무 줄이다. 옮겨 적으면 이렇다.

export function f(a:int, b:int):int {     // a = 버퍼 주소, b = 길이
  var d:int;
  var c:int = 255;
  if (b != 25) goto B_a;                  // 길이가 25가 아니면 즉시 255 반환
  c = 0;
  loop L_b {
    b = a + (c & 255) % 25;               // 건드릴 바이트 주소
    b[0]:byte = (d = b[0]:ubyte ^ (c + 1056)[0]:ubyte);
    var e:int = c & 7;
    var f:int = 0 - c & 7;
    if (c & 1) goto B_d;
    d = (d & 255) >> e | d << f;          // c 가 짝수: 오른쪽으로 e 만큼 회전
    goto B_c;
    label B_d:
    d = d << e | (d & 255) >> f;          // c 가 홀수: 왼쪽으로 e 만큼 회전
    label B_c:
    b[0]:byte = d;
    b[0]:byte = ((d & 255) + 1312)[0]:ubyte;   // sbox 치환
    c = c + 1;
    if (c != 256) continue L_b;
  }
  /* ... buf 뒤집기 12쌍 ... */
  c = memcmp(a, 1024, 25);
  label B_a:
  return c & 255;
}

핵심은 두 번째 줄, b = a + (c & 255) % 25 다. 루프 변수 c가 0부터 255까지 도는데, 매 반복이 건드리는 바이트는 c % 25번째 하나뿐이다.

WAT 원문에서도 같은 자리를 짚어 두자. sed로 주석만 얹었다. 화살표 주석은 내가 붙인 것이고, 나머지는 wasm2wat 출력 그대로다.

s|i32.rem_u$|i32.rem_u                <-- j = (i \& 0xff) % 25  →  건드릴 바이트 위치|
s|i32.const 1056$|i32.const 1056           <-- key 테이블 시작 주소|
s|i32.const 1312$|i32.const 1312           <-- sbox 테이블 시작 주소|
s|i32.xor$|i32.xor                  <-- v = buf[j] ^ key[i]|
s|i32.const 256$|i32.const 256            <-- 루프는 256 회|
s|i32.const 7$|i32.const 7              <-- 회전량은 하위 3비트만|

i32.const 25와 i32.const 255가 둘 다 나오기 때문에 $ 앵커가 없으면 255의 앞부분이 잘못 잡힌다. 이 sed 파일은 annotate_loop.sed로 문제 폴더에 남겨 뒀다.

WAT는 wabt의 JS 바인딩으로 뽑았다. wasm2wat 실행파일도 있지만, 이름 섹션을 붙여 함수명을 $f로 살리려고 스크립트를 따로 썼다.

// wabt(npm) 로 passcode.wasm 을 WAT 텍스트로 풀어 쓴다. wasm2wat 바이너리가 없는 환경용.
const fs = require('fs');
require('wabt')().then(wabt => {
  const buf = fs.readFileSync(process.argv[2] || 'passcode.wasm');
  const mod = wabt.readWasm(new Uint8Array(buf), { readDebugNames: true });
  mod.applyNames();
  fs.writeFileSync('passcode.wat', mod.toText({ foldExprs: false, inlineExport: false }));
  console.log('WAT written: passcode.wat');
});

node wasm2wat.js && sed -n "17,50p" passcode.wat | sed -f annotate_loop.sed

wasm2wat 로 푼 WAT 에 sed 로 주석을 얹은 핵심 루프 — i32.rem_u 가 버퍼 인덱스를 만들고 i32.const 1056 이 key 테이블 주소를, i32.const 7 이 회전량을 만든다

한 반복에서 일어나는 일을 정리하면 세 단계다.

한 바이트에 가해지는 세 연산 — key XOR, 하위 3비트만큼의 8비트 회전, sbox 치환. 옆 바이트를 읽지도 쓰지도 않기 때문에 사슬 전체가 전단사가 된다

회전 방향이 c의 홀짝으로 갈린다. e = c & 7, f = (0 - c) & 7이라 e + f가 항상 8이고, 짝수 반복은 오른쪽으로 e만큼, 홀수 반복은 왼쪽으로 e만큼 도는 정확한 8비트 회전이다. XOR 직후 값이 0~255 범위라 & 255 마스크와 맞물려 상위 비트가 새지 않는다.

여기서 결정적인 게 하나 나온다. 세 연산 전부 바이트 하나 안에서 끝난다. 옆 바이트를 읽지도, 쓰지도 않는다. 그러니 25바이트를 연립방정식으로 묶어 풀 필요가 없다.

256회 루프가 j = i % 25 로 25개 독립 사슬로 갈라지는 구조와, 루프가 끝난 뒤 buf 뒤집기와 memcmp 1024 비교로 이어지는 흐름

i가 0..255를 도니 위치 0~4는 11번, 5도 11번, 나머지는 10번씩 치환을 받는다. 위치마다 회전량도 순서도 다르지만, 어차피 서로 독립이라 상관없다.

루프가 끝난 뒤에는 열두 쌍을 맞바꿔 버퍼를 통째로 뒤집는다(buf[0]↔buf[24], buf[1]↔buf[23], …, buf[11]↔buf[13]). 가운데 buf[12]만 제자리다. 그리고 memcmp(buf, 1024, 25).

반환값은 c & 255다. musl memcmp는 처음 다른 바이트의 차를 돌려주는데, 두 값 모두 0~255라 차가 정확히 0일 때만 & 255가 0이 된다. 우연히 0으로 접히는 경우는 없다.

🧱 데이터 섹션 — 상수 세 덩어리

주소 세 개가 나왔다. 1024(비교 대상), 1056(key), 1312(sbox). __data_end는 1568.

간격을 보면 배치가 읽힌다. 1024부터 25바이트가 target, 1056까지 7바이트는 0 패딩, 1056부터 256바이트가 key, 1312부터 256바이트가 sbox, 그래서 1312 + 256 = 1568. 딱 맞는다.

LEB128을 손으로 세는 대신 wasm을 실제로 인스턴스화해서 선형 메모리를 그대로 떠냈다. 오독의 여지가 없다.

// wasm 을 실제로 인스턴스화해 선형 메모리에서 상수 테이블 3개를 그대로 떠낸다.
// 손으로 LEB128 을 세는 것보다 이쪽이 오독의 여지가 없다.
const fs = require('fs');
const buf = fs.readFileSync('passcode.wasm');
WebAssembly.instantiate(new Uint8Array(buf)).then(({ instance }) => {
  const mem = new Uint8Array(instance.exports.memory.buffer);
  const target = Array.from(mem.slice(1024, 1024 + 25));
  const key    = Array.from(mem.slice(1056, 1056 + 256));
  const sbox   = Array.from(mem.slice(1312, 1312 + 256));
  console.log('target[25] =', JSON.stringify(target));
  console.log('sbox 가 순열인가:', new Set(sbox).size === 256);
  console.log('key  가 순열인가:', new Set(key).size === 256);
  fs.writeFileSync('tables.json', JSON.stringify({ target, key, sbox }));
  fs.writeFileSync('mem_1024.bin', Buffer.from(mem.slice(1024, 1568)));
  console.log('tables.json / mem_1024.bin (544B, __data_end=1568) 기록 완료');
});

떠낸 544바이트를 xxd로 확인하면 경계가 눈으로 보인다.

xxd -l 32 mem_1024.bin && echo "--- key  (오프셋 +32) 첫 32B ---" && xxd -s 32 -l 32 mem_1024.bin && echo "--- sbox (오프셋 +288) 첫 32B ---" && xxd -s 288 -l 32 mem_1024.bin

xxd 로 본 메모리 1024번지 — 앞 25바이트가 비교 대상 target 이고 이어지는 7바이트가 0 패딩, 오프셋 +32 부터 key 가, +288 부터 sbox 가 붙어 있다

6e00 0000 0000 0000 자리가 보인다. target의 마지막 바이트 0x6e 뒤로 0이 일곱 개. 예상한 패딩이다.

node dump_tables.js

node dump_tables.js 출력 — target 25바이트 값이 그대로 찍히고, key 와 sbox 둘 다 중복 없는 256개 순열이라는 판정이 true 로 나온다

key도 sbox도 256개 값이 전부 다르다. 둘 다 순열이라는 뜻이고, 그러면 위치별 치환 사슬 전체가 0..255 위의 전단사다. 역상이 존재하고, 정확히 하나다.

이 지점에서 풀이 방향이 정해진다. 사슬을 대수적으로 뒤집을 필요도 없다. 위치마다 후보 256개를 정방향으로 태워 보고 맞는 걸 고르면 된다. 25 × 256 = 6,400번. 눈 깜짝할 새다.

🐛 빠지기 쉬운 두 곳

▶🕳️ 삽질 — 회전 방향과 뒤집기를 빠뜨리면 조용히 틀린 답이 나온다

이 문제의 고약한 점은 틀려도 티가 안 난다는 것이다.

회전 방향을 홀짝으로 안 가르고 한 방향으로만 고정해도, 마지막 뒤집기를 보정 안 해도, 사슬은 여전히 전단사다. "역상이 유일하다"는 assert도 그대로 통과한다. 그냥 다른 25바이트가 나올 뿐이다.

실제로 어떻게 되는지 각각 빼고 돌려서 확인해 뒀다.

#!/usr/bin/env python3
"""역산에서 빠뜨리기 쉬운 두 가지를 실제로 빠뜨려 보고 결과를 비교한다.
 
(1) 회전 방향을 i 의 홀짝으로 가르지 않고 한 방향으로만 고정
(2) 마지막 buf 뒤집기(swap i <-> 24-i)를 보정하지 않음
둘 다 사슬은 여전히 전단사라 "역상 유일" 검증을 통과한다 — 그래서 조용히 틀린 답이 나온다.
"""
import json, pathlib
 
T = json.loads(pathlib.Path("tables.json").read_text())
target, key, sbox = T["target"], T["key"], T["sbox"]
 
def ror8(v, n): return ((v >> n) | (v << (8 - n))) & 0xFF if n else v
def rol8(v, n): return ((v << n) | (v >> (8 - n))) & 0xFF if n else v
 
def chain(j, v, parity=True):
    for i in range(j, 256, 25):
        v ^= key[i]
        a = i & 7
        if parity:
            v = ror8(v, a) if i % 2 == 0 else rol8(v, a)
        else:
            v = ror8(v, a)          # (1) 항상 오른쪽 회전
        v = sbox[v]
    return v
 
def invert(parity=True, reverse=True):
    out = bytearray(25)
    for j in range(25):
        want = target[24 - j] if reverse else target[j]
        c = [x for x in range(256) if chain(j, x, parity) == want]
        out[j] = c[0] if len(c) == 1 else 0x3F
    return bytes(out)
 
def show(label, b):
    printable = "".join(chr(x) if 0x20 <= x < 0x7F else "." for x in b)
    print(f"{label:<34} {printable}")
 
show("(1) 회전 방향 고정", invert(parity=False, reverse=True))
show("(2) 뒤집기 보정 없음", invert(parity=True, reverse=False))
show("(1)+(2) 둘 다 빠뜨림", invert(parity=False, reverse=False))
show("둘 다 반영한 정답", invert(parity=True, reverse=True))

python3 pitfall.py

pitfall.py 실행 결과 — 회전 방향을 고정하거나 뒤집기를 빼면 출력이 전부 깨진 바이트가 되고, 둘 다 반영했을 때만 읽히는 passcode 가 나온다

셋 다 25바이트를 멀쩡히 뱉는다. 그저 읽을 수 없는 바이트일 뿐이다. 만약 정답이 랜덤 바이트열이었다면 넷 중 어느 게 맞는지 화면만 보고는 못 골랐을 것이다.

그래서 solve.py에는 정방향 재현 assert를 넣었다. 뽑은 답을 다시 f()가 하는 순서대로 태워 target과 글자 하나까지 맞는지 스스로 확인한다.

🎯 역산 — 위치마다 256개만 돌려 본다

역산 코드는 짧다. f()가 위치 j에 가하는 연산을 그대로 함수 하나로 옮기고, 그걸 256번 호출한다.

뒤집기는 마지막에 한 번뿐이니 인덱스 하나로 흡수된다. 위치 j의 변환 결과는 뒤집힌 뒤 24-j번 자리로 가므로, chain(j, x)가 target[24-j]와 같아야 한다.

#!/usr/bin/env python3
"""passcode (DreamHack, Gold 1 / reversing) — wasm export f() 역산
 
f(ptr,len) 이 하는 일 (passcode.wat 에서 읽어낸 그대로):
  len != 25 이면 즉시 255 반환.
  for i in range(256):
      j = (i & 0xff) % 25                 # 바이트 위치. i 가 256 미만이라 i % 25 와 같다
      v = buf[j] ^ key[i]                 # key = 메모리 1056.. 256바이트
      a, b = i & 7, (-i) & 7
      v = ror8(v, a) if i % 2 == 0 else rol8(v, a)
      buf[j] = sbox[v]                    # sbox = 메모리 1312.. 256바이트
  buf 를 뒤집고 memcmp(buf, target@1024, 25).
 
핵심은 j = i % 25 라서 **바이트끼리 절대 섞이지 않는다**는 것. 25개 위치가
각자 독립적인 치환 사슬을 탄다. sbox 도 key 도 순열이라 사슬 전체가 전단사이므로
위치마다 256개 후보를 그냥 다 돌려 보면 역상이 하나로 떨어진다.
뒤집기까지 감안하면 위치 j 의 결과가 target[24-j] 여야 한다.
"""
import json, pathlib
 
T = json.loads(pathlib.Path("tables.json").read_text())
target, key, sbox = T["target"], T["key"], T["sbox"]
 
def ror8(v, n): return ((v >> n) | (v << (8 - n))) & 0xFF if n else v
def rol8(v, n): return ((v << n) | (v >> (8 - n))) & 0xFF if n else v
 
def chain(j, v):
    """위치 j 의 바이트 v 에 f() 가 적용하는 연산을 순서대로 다 태운다."""
    for i in range(j, 256, 25):
        v ^= key[i]
        a = i & 7
        v = ror8(v, a) if i % 2 == 0 else rol8(v, a)
        v = sbox[v]
    return v
 
passcode = bytearray(25)
for j in range(25):
    want = target[24 - j]                       # 뒤집기 보정
    cands = [c for c in range(256) if chain(j, c) == want]
    assert len(cands) == 1, f"j={j} 후보 {len(cands)}개 — 사슬이 전단사가 아니다"
    passcode[j] = cands[0]
 
# 자체 검증: 정방향으로 다시 돌려 target 과 일치하는지 확인한다
fwd = [chain(j, passcode[j]) for j in range(25)][::-1]
assert fwd == target, "정방향 재현 실패"
 
print("passcode =", passcode.decode())
print("FLAG     = DH{%s}" % passcode.decode())

python3 solve.py

python3 solve.py 실행 — 위치별 256후보 전수와 정방향 재현 assert 를 모두 통과하고 25자 passcode 와 DH 형식 플래그를 출력한다

W3B@sSemb1y_R3ver5in9_^-^. 25글자, 리트 표기로 "WebAssembly Reversing". 마지막 ^-^까지 포함해서 길이가 딱 25다.

🚀 검증 — 진짜 wasm과 진짜 브라우저

역산이 맞는지는 배포본 wasm에 직접 물어보는 게 제일 확실하다. main.js의 폼 핸들러와 똑같은 순서로 메모리에 써 넣고 f()를 부른다.

// solve.py 가 뽑은 passcode 를 main.js 와 똑같은 방식으로 진짜 wasm 에 먹인다.
// f() 가 0 을 돌려주면 브라우저에서 Correct! 가 뜨는 것과 같은 조건이다.
const fs = require('fs');
const code = new Uint8Array(fs.readFileSync('passcode.wasm'));
const passcode = process.argv[2] || 'W3B@sSemb1y_R3ver5in9_^-^';
 
WebAssembly.instantiate(code).then(({ instance }) => {
  const array = new Uint8Array(instance.exports.memory.buffer, 0, passcode.length);
  array.set(passcode.split('').map(x => x.charCodeAt()));
  const result = instance.exports.f(array.byteOffset, array.length);
  console.log(`passcode = ${passcode}  (len=${passcode.length})`);
  console.log(`f() -> ${result}   ${result === 0 ? '=> Correct!  FLAG = DH{' + passcode + '}' : '=> Wrong!'}`);
  // 대조군: 한 글자만 바꾸면 어떻게 되는지
  const bad = 'X' + passcode.slice(1);
  const a2 = new Uint8Array(instance.exports.memory.buffer, 0, bad.length);
  a2.set(bad.split('').map(x => x.charCodeAt()));
  console.log(`대조군 "${bad}" -> f() = ${instance.exports.f(a2.byteOffset, a2.length)} (0 이 아니면 Wrong)`);
});

node verify.js

node verify.js 실행 — 배포본 wasm 에 그대로 먹여 f() 가 0 을 반환하고, 첫 글자만 X 로 바꾼 대조군은 202 를 돌려준다

0이다. 대조군으로 첫 글자만 X로 바꿨더니 202가 나온다. 판정이 실제로 입력에 반응한다는 확인이다.

여기까지 왔으면 브라우저로도 봐야 한다. 서버가 없는 문제라 extracted/ 폴더를 그대로 로컬에서 서빙했다.

cd extracted && python3 -m http.server 8412 --bind 127.0.0.1

로컬 http.server 로 띄운 문제 페이지 — 주소창은 127.0.0.1:8412 이고 보라색 배경에 열쇠 아이콘이 붙은 입력칸 하나뿐인 원래 화면이다

입력칸 하나가 전부다. 먼저 틀린 값을 넣어 본다.

틀린 passcode 를 넣고 엔터를 쳤을 때 — SweetAlert2 다이얼로그가 Wrong! You have entered a wrong passcode 문구로 뜬다

그리고 역산한 값.

역산한 passcode 를 넣었을 때 — 같은 페이지가 Correct! You have entered a correct passcode 로 바뀐다

마지막으로 DevTools 콘솔에서 인스턴스를 직접 만져 봤다. 페이지 스크립트가 instance와 passcode를 전역으로 두기 때문에 콘솔에서 그대로 잡힌다.

Object.keys(instance.exports).join()
passcode
buf=new Uint8Array(instance.exports.memory.buffer,0,25),buf.set(Array.from(passcode).map(c=>c.charCodeAt())),instance.exports.f(0,25)

Chrome DevTools 콘솔에서 직접 확인 — instance.exports 는 memory 와 __heap_base, __data_end, f 넷이고 f(0,25) 호출이 0 을 반환한다

내보내기 목록이 wasm-objdump로 본 것과 같고, f(0, 25)가 콘솔에서도 0을 준다. 정적 분석과 런타임이 같은 얘기를 하고 있다.

플래그는 passcode를 형식에 넣은 그대로다.

DH{W3B@sSemb1y_R3ver5in9_^-^}

한 방 재현

문제 폴더에 reproduce.sh를 남겨 뒀다. 추출부터 검증까지 한 번에 돈다. 필요한 건 python3과 node뿐이고, wabt는 분석용이라 재현에는 쓰지 않는다.

#!/usr/bin/env bash
# passcode (DreamHack Gold 1 / reversing) — 한 방 재현.
#   extracted/main.js 에서 wasm 추출 → 상수 테이블 덤프 → 역산 → 진짜 wasm 으로 검증까지.
# 필요한 것: python3, node (wabt 는 분석용이라 여기선 안 쓴다)
set -eu
cd "$(dirname "$(readlink -f "$0")")"
 
EXPECT=$(python3 -c "import json;print(json.load(open('문제.json'))['flag'])" 2>/dev/null || echo '')
 
command -v node >/dev/null || { echo "❌ node 가 필요합니다"; exit 1; }
 
python3 extract_wasm.py                 # extracted/main.js → passcode.wasm
node    dump_tables.js                  # 선형 메모리 → tables.json / mem_1024.bin
OUT=$(timeout 120 python3 solve.py 2>&1) || true
echo "$OUT"
 
FLAG=$(printf '%s' "$OUT" | grep -aoE 'DH\{[^}]+\}' | head -1)
PASS=$(printf '%s' "$FLAG" | sed -E 's/^DH\{(.*)\}$/\1/')
 
echo
echo "--- 진짜 wasm 으로 재검증 (f() 가 0 이어야 정답) ---"
node verify.js "$PASS"
 
if [ -n "$FLAG" ] && node verify.js "$PASS" | grep -q 'f() -> 0'; then
  if [ -z "$EXPECT" ] || [ "$FLAG" = "$EXPECT" ]; then
    echo; echo "✅ PASS  $FLAG"; exit 0
  fi
fi
echo; echo "❌ FAIL (얻은 값: '${FLAG:-없음}' / 기대: '${EXPECT:-대조본 없음}')"; exit 1

로컬 환경은 Ubuntu 25.10(커널 6.17.0-41) · Node v22.12.0 · Python 3.13.7 · wabt는 npm i wabt로 받은 것(패키지 버전은 package-lock.json에 고정)을 썼다. 폴더를 통째로 다른 경로에 복사해 산출물을 지우고 한 번 더 돌려 PASS가 나오는 것까지 확인했다.

📝 결론

섞지 않는 암호는 암호가 아니다

이 문제의 전부는 (c & 255) % 25 한 줄이다. 루프를 256번 돌리고, XOR과 회전과 S-box를 겹쳐 놓고, 마지막에 뒤집기까지 얹었지만, 바이트 사이에 확산(diffusion)이 없다. 그래서 25바이트 탐색 공간이 25개의 256짜리 탐색으로 무너진다.

블록 암호가 왜 매 라운드 자리를 섞는지를 반대편에서 보여 주는 셈이다. 치환만 쌓아 봐야 위치별 전단사가 하나 더 길어질 뿐이다.

정적 분석은 도구를 바꿔 가며 두 번 본다

wasm-decompile의 C 비슷한 출력이 없었다면 WAT 76줄을 스택 머신 그대로 따라가야 했다. 반대로 wasm-decompile만 봤다면 i32.rem_u가 어느 값에 걸리는지 헷갈렸을 것이다. 같은 코드를 두 표현으로 보는 게 빠르다.

그리고 상수는 파싱하지 말고 실행해서 꺼내는 게 낫다. WebAssembly.instantiate 한 줄이면 데이터 섹션이 알아서 메모리에 깔린다. LEB128을 손으로 세다 한 바이트 틀리면 답 전체가 어긋난다.

틀려도 결과가 나오는 역산은 스스로 검증하게 만든다

회전 방향이나 뒤집기를 빠뜨려도 25바이트가 멀쩡히 나온다. 정답이 사람이 읽는 문자열이라 눈으로 걸러졌을 뿐이다. solve.py가 뽑은 답을 정방향으로 다시 태워 target과 대조하고, 마지막에는 배포본 wasm에 직접 먹여 0을 받는 것까지 해 두면 이런 종류의 착각이 남지 않는다.

클라이언트에 검증 로직을 두면 그게 곧 정답 사본이다

방어 관점에서는 뻔한 결론이 하나 남는다. 이 페이지는 정답을 서버에 안 물어본다. 판정에 필요한 모든 것이 다운로드된 1,984바이트 안에 있다. wasm으로 감싸면 JS보다 읽기 번거로울 뿐이지, 도구가 갖춰지면 난독화 축에도 못 든다. import가 하나도 없는 모듈은 "여기 안에 답이 다 있다"는 표시나 마찬가지다.

실제로 인증이 필요한 값이라면 입력을 서버로 보내 거기서만 비교해야 하고, 클라이언트 검사는 어디까지나 오타 걸러 주는 편의 기능으로 두는 게 맞다.