[🥈 Silver 4] 검은 가림막을 ret 한 줄로 걷어내다 — DreamHack patch 풀이

문제: DreamHack — patch 분류: Reversing 난이도: 🥈 Silver 4 FLAG: DH{UPATCHED}

문제 이름 그대로 "패치"가 답이다. 실행하면 창에 flag를 그려 주는데, 가운데가 검은 막대로 덮여 있다. 입력도 검증도 없다. flag를 그리는 방식을 뜯어보고, 그 그림에서 가림막만 걷어내면 된다.

문제 개요

문제 설명도 친절하다 — "flag를 그리는 루틴을 분석하고 가려진 flag를 보이게 해 주세요"에, 참고 링크로 GDI+ 문서와 x64dbg의 Patch File 기능을 걸어 뒀다. 그리기 루틴을 읽고, 바이너리를 패치하라는 뜻이다.

🧩 배경 — GDI+ 라인 드로잉

이 프로그램은 텍스트 출력 API(TextOut·DrawText)를 쓰지 않는다. 대신 GDI+의 선 그리기로 글자 하나하나를 직접 그린다. import를 보면 쓰는 함수가 몇 개 안 된다.

GdiplusStartup / GdipCreateFromHDC   ; GDI+ 시작, HDC로 Graphics 생성
GdipCreatePen1(ARGB color, REAL width, Unit, Pen**)  ; 색·두께를 가진 펜
GdipDrawLineI(Graphics, Pen, x1, y1, x2, y2)         ; 두 점을 잇는 선
GdipSetSmoothingMode / GdipDeletePen / GdipDeleteGraphics

GdipCreatePen1의 첫 인자가 펜 색(ARGB, 예: 0xff000000 = 불투명 검정)이고, GdipDrawLineI가 그 펜으로 선을 긋는다. 즉 화면의 모든 것이 선분의 모음이다. flag 글자도, 그걸 가리는 막대도 전부 선으로 그려진다. 그래서 "무슨 색 선을, 어떤 순서로 긋는가"가 이 문제의 전부다.

🔬 정찰 — 누가 무엇을 그리나

strings로는 flag가 안 나온다(글자가 문자열이 아니라 선분 좌표로 박혀 있으니 당연하다). import만 GDI+로 가득하다.

GdipDrawLineI 호출처를 따라가면 함수가 잔뜩 나온다. 글자 한 자당 함수 하나꼴로, 각 함수가 GdipCreatePen1(색은 인자로 받음) → GdipDrawLineI를 여러 번 반복해 글자 모양을 만든다. 이 글자 함수들을 한데 모아 호출하는 곳이 그리기 오케스트레이터(fcn.140002c40)다.

오케스트레이터는 두 단계로 나뉜다. 먼저 fcn.140002b80을 x좌표 30, 35, 40 … 90으로 25번 부르고, 그 다음 글자 함수 12개를 색 0xff000000(검정)으로 부른다.

여기서 눈에 걸리는 게 두 가지다. ① 앞쪽 fcn.140002b80도 호출할 때 스택으로 색 0xff000000(검정)을 넘긴다. ② 글자 함수들도 색이 0xff000000(검정)이다. 둘 다 검정인데, 하나는 먼저 그려진다.

💣 핵심 — 검정 가림막 위에 검정 글자

fcn.140002b80이 무엇을 그리는지 보면 답이 나온다. 펜 두께가 10.0(상수 0x41200000)으로 글자용 펜(두께 4)보다 훨씬 굵고, 호출될 때마다 x를 5씩 옮겨 가며 선을 긋는다. 굵은 선 25개를 촘촘히 겹치면 — 속이 꽉 찬 검은 사각형, 즉 가림막이 된다.

그리는 순서가 함정이다.

1. 먼저 가림막(검정 사각형)을 flag 가운데 위치에 그린다.
2. 그 다음 flag 글자들을 검정으로 그 위에 그린다.

GDI+는 부른 순서대로 위에 덧칠하므로, 가운데 글자들은 가림막 위에 그려진다. 그런데 글자도 검정, 가림막도 검정이라 검정 위 검정 = 구분 불가다. 반면 DH{와 }는 가림막 바깥(흰 배경) 위치라 검정 글자가 멀쩡히 보인다. flag가 "암호화"된 게 아니라, 말 그대로 같은 색으로 덧칠해 가려 둔 것이다.

해결책은 가림막을 없애는 것 하나로 충분하다. 가림막을 그리는 함수 fcn.140002b80이 아무것도 안 하게 만들면, 가운데 검정 글자들이 흰 배경 위에 그대로 남는다.

🎯 패치 — 가림막 함수를 ret 시키기

fcn.140002b80은 가림막만 그린다. 그러니 이 함수의 첫 명령을 ret(0xC3)로 바꾸면, 호출돼도 즉시 돌아가 아무것도 안 그린다. 함수 진입 직후라 스택에 push한 것도 없어 그냥 ret 한 바이트면 깔끔하다.

함수 시작은 가상주소 0x140002b80이고, .text 섹션이 가상주소 0x140001000 → 파일 오프셋 0x400에 매핑되니 파일 오프셋은 0x140002b80 - 0x140001000 + 0x400 = 0x1f80이다. 그 자리의 0x48(프롤로그 첫 바이트)을 0xC3으로 덮는다. x64dbg라면 그 주소에서 Assemble → ret 후 Patch File을 하면 되고, 여기선 같은 일을 파일에 직접 했다.

# patch.py
COVER_VA   = 0x140002b80
TEXT_VA    = 0x140001000   # .text 가상주소
TEXT_PADDR = 0x400         # .text 파일오프셋
off = COVER_VA - TEXT_VA + TEXT_PADDR   # 0x1f80
 
data = bytearray(open("Patch.exe", "rb").read())
assert data[off] == 0x48
data[off] = 0xC3          # 가림막 함수를 즉시 ret
open("Patch_patched.exe", "wb").write(data)

패치한 실행 파일을 (여기서는 wine로) 실행하면 가림막이 사라지고 가운데 글자가 흰 배경 위에 드러난다.

세그먼트 폰트라 글자가 각져 보이지만 그대로 읽힌다 — D H { U P A T C H E D }.

DH{UPATCHED}

가림막의 색만 흰색으로 바꾸거나(호출처 25곳의 0xff000000 → 0xffffffff), 글자 색을 검정이 아닌 색으로 바꿔도 같은 결과가 나오지만, 가림막 함수 하나를 ret 시키는 1바이트 패치가 가장 간단하다.

📝 결론

보이지 않는다고 없는 게 아니다. 이 문제의 flag는 암호화되거나 어딘가 숨겨진 게 아니라, 화면에 멀쩡히 그려진 뒤 같은 색으로 한 번 더 덧칠해 시각적으로만 가려져 있었다. 데이터는 처음부터 거기 있었고, 그것을 가린 것도 코드 몇 줄이다. 그리는 순서(z-order)와 색만 바꾸면 그대로 드러난다.

정리하면,

1. "가림 = 보호"가 아니다. UI에서 무언가를 검은 사각형·블러·visibility:hidden으로 덮어도, 그 아래 원본 데이터는 그대로 존재한다. 민감 정보는 렌더링 단계가 아니라 데이터 단계에서 빼야 한다(서버에서 마스킹해 내려보내기 등).
2. 바이너리 패치의 기본기. 분기 하나, 함수 하나를 ret/nop으로 바꾸는 것만으로 프로그램의 행동을 통째로 바꿀 수 있다. 라이선스 체크·안티디버깅 우회 같은 실전 분석도 같은 원리이고, x64dbg의 Patch File이 정확히 이 작업을 GUI로 해 준다.
3. 그림도 코드다. 출력이 텍스트가 아니라 그래픽이면 strings로는 안 잡힌다. 무엇을 그리는 API인지(GDI/GDI+/Direct2D…)부터 식별하고, 그 호출 순서와 인자(색·좌표)를 따라가면 "그림으로 숨긴 값"도 결국 읽어낼 수 있다.