[🥉 Bronze 1] 검증식을 브라우저 대신 내가 계산하기 — DreamHack funjs 풀이

문자열을 배열 하나에 몰아넣고, IIFE로 배열 순서를 한 번 섞은 다음, 인덱스 계산으로 원래 문자열을 되찾아 쓰는 전형적인 javascript-obfuscator 스타일 문자열 테이블이다. _0x374fd6(0x183) 같은 호출이 실제로는 getElementById 같은 흔한 메서드 이름이라는 뜻.

중요한 건 이 기법이 가릴 수 있는 대상이다. 문자열 테이블은 "charCodeAt", "length", "getElementById" 처럼 소스에 원래 문자열 리터럴로 박혀 있던 것만 감출 수 있다. 반면 검증에 쓰이는 숫자 배열과 연산자는 애초에 문자열이 아니라 산술 리터럴이라 이 테이블을 거치지 않는다. 브라우저가 실행 시점에 실제 값을 알아야 계산이 되기 때문에, 구조적으로 평문 리터럴로 남을 수밖에 없다. 즉 겉모습만 어려워 보일 뿐, 정답을 만드는 재료는 처음부터 다 공개돼 있다.

🔬 정찰

화면 — 움직이는 박스와 debugger;

로컬로 파일을 띄우면 입력창과 버튼뿐인 페이지가 뜬다.

#formbox(입력창 + 버튼을 담은 div)를 1초마다 화면 랜덤 위치로 옮긴다. 게다가 매 틱마다 debugger;. DevTools를 열어놓고 분석하던 사람을 1초마다 멈춰 세우려는 얄미운 훼방이다. 하지만 DevTools를 안 열면 debugger;는 그냥 아무 일도 안 하는 문장이고, 검증 로직은 버튼 클릭 시 동기적으로 한 번에 끝나기 때문에 박스가 어디로 움직이든 결과에는 전혀 영향이 없다. 위협적으로 보이지만 실질적으로는 장식이다.

main() — 진짜 검증 로직

문자열 테이블을 걷어내고 나면 main()의 뼈대는 이거다.

text2img는 결과를 DOM 텍스트가 아니라 <canvas>에 그려 <img>로 박아 넣는 함수다. Ctrl+F로 정답 문자열을 검색해도 안 걸리게 하려는 의도로 보이지만, 검증 자체가 클라이언트에서 돌아가는 이상 캔버스로 결과를 그리든 말든 로직을 읽는 데는 아무 지장이 없다.

핵심 비교는 딱 한 줄이다.

_0x4949, _0x42931은 36개짜리 16진수 상수 배열, operator는 +, -, *, ^ 네 개가 i % 4로 순환한다. 전부 소스에 그대로 적혀 있다. 즉 정답 문자 코드 자체가 이미 계산 가능한 형태로 공개돼 있다 — 브루트포스도, 방정식을 뒤집을 필요도 없다. 저 식을 그대로 실행만 하면 된다.

💣 핵심 — 난독화된 건 이름표뿐, 값은 처음부터 평문

정리하면 이 문제의 구조는 이렇다.

javascript-obfuscator 류 도구는 식별자·문자열 리터럴은 얼마든지 가릴 수 있어도, 실행 시점에 실제 계산이 이뤄져야 하는 산술 데이터까지 감출 수는 없다(감추면 브라우저도 계산을 못 한다). 그래서 "난독화됐다"는 인상과 별개로, 검증 공식 + 상수 = 정답인 문제는 코드를 한 번 읽는 것만으로 다 뚫린다. 서버 왕복도, 반복 시도도 필요 없다.

🎯 익스플로잇 — 검증식을 파이썬으로 그대로 옮기기

_0x4949, _0x42931 두 배열을 정규식으로 뽑아 charCodeAt 비교식 그대로 재현한다.

내 계산이 challenge의 실제 검증 로직과 정확히 일치하는지는 추측으로 남겨두지 않았다. 다운로드한 index.html의 <script>를 원본 그대로 Node에 로드하고, document.getElementById("flag")만 이 값으로 채운 mock DOM을 붙여서 main()을 직접 실행시켜봤다 — 틀린 값을 넣으면 캔버스에 NOP !가, 이 값을 넣으면 캔버스에 플래그 문자열 그대로가 그려졌다. 브라우저에서도 동일하게 재현된다.

DreamHack 라이브 페이지에 같은 값을 제출하면 확인된다.

📝 결론

클라이언트에서 도는 검증은, 그 검증 코드 전체가 이미 공격자 손에 있다는 뜻이다.

이름을 아무리 가려도 실행에 필요한 실제 값(상수·연산)은 소스에 그대로 남는다. 이번 문제처럼 "정답 문자 코드 = 상수 배열 + 연산자"라는 식 자체가 공개돼 있으면, 공격자는 브루트포스는커녕 그 식을 복사해서 실행만 하면 된다. debugger; 도배나 박스를 움직이는 연출은 분석을 귀찮게 할 뿐 실제 방어력은 없다.

진짜 비밀은 서버에 남겨야 한다. 클라이언트는 사용자가 완전히 통제하는 환경이라, 여기서 도는 어떤 검사도 결국 우회 가능한 참고자료일 뿐이다. 입력값 검증이나 UX용 즉시 피드백 정도는 클라이언트에서 해도 되지만, 정답·라이선스 키·권한 판정처럼 진짜 중요한 판단은 반드시 서버 왕복으로 확인해야 한다.