[🥉 Bronze 4] 심볼 없는 STM32F4 펌웨어에서 진짜 키 찾기 — DreamHack Please Discover my Discovery key 풀이

문제: DreamHack — Please Discover my Discovery key 분류: Misc (펌웨어 리버싱) 난이도: 🥉 Bronze 4 원본: ACSC CTF 출제작 (plzdiscoverdiscovery) FLAG: acsc{welcometostm32!!!}

주어지는 건 stm32f4-discovery.bin 딱 하나, 그것도 769바이트다. 서버도 없다. 문제 설명은 한 줄, "Get key from stripped cortex M board" — 심볼이 다 벗겨진(stripped) Cortex-M 보드에서 키를 뽑아내라는 뜻이다.

가장 먼저 손이 가는 건 strings 인데, 여기서부터 함정이 시작된다. doyouwantrealkey("do you want real key"), ppQAwdKeyskeys@=, poppoppoppoppop, 0x001001 같은 그럴듯한 "키 후보"들이 대놓고 박혀 있다. 이걸 하나씩 넣어보다 시간을 다 버리게 된다. 진짜 키는 이 문자열들 안에 없다. 보드가 부팅해서 UART 로 실제로 계산해 내보내는 값에 있다. 그래서 이 문제는 "strings 로 끝"이 아니라, Thumb 코드를 읽어 무슨 계산을 하는지 따라가야 하는 리버싱 문제다.

이 글의 명령은 모두 문제 폴더 최상위(extracted/ 의 부모) 에서 실행한다.

file extracted/stm32f4-discovery.bin; strings -n 4 extracted/stm32f4-discovery.bin

문제 개요

파일만 주어지는 오프라인 문제라 VM 이 필요 없다. file 은 그냥 data 라고만 말해준다 — ELF 도 아니고 헤더도 없는 순수 펌웨어 바이너리(raw binary) 다. 이럴 땐 아키텍처와 로드 주소를 사람이 직접 알려줘야 디스어셈블이 된다.

풀이 흐름은 이렇다. strings 로 미끼와 진짜 재료(base64 두 개)를 구분하고 → 벡터 테이블에서 로드 주소·진입점을 읽어 Thumb 으로 디스어셈블하고 → main 이 두 base64 문자열을 XOR 해서 UART 로 내보낸다는 걸 확인하고 → 에뮬레이터로 그 출력을 실측한 뒤 → XOR 을 되돌려 숨은 메시지를 복원한다.

🧩 배경 — raw 펌웨어를 주소공간에 얹기

일반적인 리버싱은 ELF 를 주면 objdump 가 알아서 심볼·섹션·진입점을 읽어준다. 하지만 이 파일은 섹션 헤더가 없는 raw 이미지다. Cortex-M 은 전원이 들어오면 주소 0 에서 두 개의 32비트 워드를 읽는다.

• [0x00] 초기 스택 포인터(MSP)
• [0x04] 리셋 핸들러 주소 (최하위 비트 1 = Thumb 모드)

파일 맨 앞 8바이트가 정확히 이 벡터 테이블이다.

00000000: 0000 0220  5102 0008   ...
          └ SP=0x20020000  └ Reset=0x08000251

SP = 0x20020000 은 STM32F4 의 SRAM(0x20000000) 영역 끝이고, 리셋 벡터 0x08000251 은 flash 영역(0x08000000)을 가리킨다. 즉 이 바이너리는 0x08000000 에 얹히는 flash 이미지이고, 코드는 Thumb 이며 진입점은 0x08000250(짝수 정렬, LSB 는 Thumb 표시라 떼고 봄)이다. 이 두 숫자만 있으면 나머지는 전부 디스어셈블로 풀린다.

objdump 는 이 머신을 못 물어서(can't use supplied machine arm) capstone 으로 직접 Thumb 디스어셈블했다. 769바이트 안에는 함수가 몇 개 없다.

• 0x08 UART 한 글자 출력 (상태 레지스터의 TXE 비트를 폴링 후 데이터 레지스터에 write)
• 0x4c USART1·GPIO·RCC 초기화
• 0xc8 busy-loop 딜레이
• 0xf6 반복키 XOR (핵심)
• 0x17e / 0x19c getKey — 각각 3, 4 만 반환 (미끼)
• 0x1b8 main

🔍 정찰 — 미끼와 진짜 재료 구분하기

strings 결과에서 base64 로 보이는 두 개가 눈에 띈다.

c3RtMzJmNC1kaXNjb3Zlcnk=   → base64 디코드 → "stm32f4-discovery"
d2VsY29tZXRvc3RtMzIhISE=   → base64 디코드 → "welcometostm32!!!"

나머지 doyouwantrealkey, ppQAwdKeyskeys@=, poppoppoppoppop, 0x001001 은 평문 그대로 flash 에 박혀 있다. 사람 눈엔 오히려 이 평문들이 "키"처럼 보이지만, 코드가 실제로 이걸 쓰는지 아닌지는 디스어셈블로 확인해야 한다.

capstone 으로 각 함수의 PC-상대 리터럴 로드를 전부 해석해 봤다. 어떤 문자열을 누가 참조하는지가 여기서 갈린다.

• 0x1be (main) → d2VsY29t…(welcome base64)
• 0x1d2 (main) → c3RtMzJm…(discovery base64)
• 0x184 (getKey A) → poppoppoppoppop
• 0x1a2 (getKey B) → ppQAwdKeyskeys@=
• 0x1d6 (main) → doyouwantrealkey
• 0x1da (main) → 0x001001

getKey 두 함수는 문자열 포인터를 지역변수에 담아두고는 정작 정수 3·4 만 반환한다. main 에서도 doyouwantrealkey 와 0x001001 은 로드만 되고 이후 한 번도 읽히지 않는다. 즉 네 개 다 죽은 코드(dead code) 미끼다. 실제 계산에 들어가는 재료는 base64 두 개뿐이다.

🎯 핵심 — main 이 하는 계산

main(0x080001b8)의 흐름은 짧다.

1. flash 의 d2VsY29tZXRvc3RtMzIhISE=(= welcome base64)를 스택 버퍼 buf 로 복사한다.
2. xor_inplace(buf, "c3RtMzJmNC1kaXNjb3Zlcnk=") 를 호출한다 — buf 를 discovery base64 로 XOR 한다.
3. USART1 을 초기화하고, buf 를 UART 로 반복 송신한다.

2번의 xor_inplace(0x080000f6)가 이 문제의 전부다. 디스어셈블을 보면 전형적인 반복키 XOR 이다.

#!/usr/bin/env python3
# capstone thumb disassembly of the repeating-key XOR routine @ 0x080000f6
import capstone
BASE = 0x08000000
data = open("extracted/stm32f4-discovery.bin", "rb").read()
md = capstone.Cs(capstone.CS_ARCH_ARM, capstone.CS_MODE_THUMB)
 
notes = {
    0x08000106: "while str1[i]        -> i = strlen(str1)",
    0x0800011e: "while str2[j]        -> j = strlen(str2)  (key length)",
    0x08000142: "sdiv/mul/sub         -> k % strlen(key)",
    0x08000154: "r2 = key[k % keylen]",
    0x0800015c: "r2 ^= str1[k]",
    0x08000160: "str1[k] = r2         <-- repeating-key XOR, in place",
}
for insn in md.disasm(data[0x130:0x172], BASE + 0x130):
    n = notes.get(insn.address, "")
    tail = f"      ; {n}" if n else ""
    print(f"0x{insn.address:08x}:  {insn.mnemonic:6s} {insn.op_str}{tail}")

python3 xor_disasm.py

의사코드로 옮기면 이렇다.

// str1 = buf(welcome base64),  str2 = key(discovery base64)
for (k = 0; k < strlen(str1); k++) {
    str1[k] = str1[k] ^ str2[k % strlen(str2)];   // 0x160: strb r2, [r3]
}

sdiv/mul/subs 세 명령이 k % strlen(key) 를 만들고(0x142~0x14c), key[k % keylen](0x154)를 str1[k](0x13c)와 XOR(0x15c)해서 제자리에 다시 쓴다(0x160). 두 문자열 길이가 24로 같으니 결국 두 base64 문자열의 단순 바이트 XOR 이다.

즉 보드가 UART 로 내보내는 값은

CT = base64("welcometostm32!!!") ⊕ base64("stm32f4-discovery")

이고, 이 CT 를 다시 base64("stm32f4-discovery") 로 XOR 하면 base64("welcometostm32!!!") 가 튀어나온다. "my Discovery key" 는 미끼 평문들이 아니라, 보드 자신의 정체성인 stm32f4-discovery 를 XOR 키로 쓴다는 뜻이었다.

🧪 증거 — 에뮬레이터로 UART 출력 실측

정적 분석만으로 "이 바이트가 나온다"고 주장하기보다, 실제로 코드를 돌려 UART 로 무엇이 나가는지 확인하는 편이 확실하다. 실물 보드가 없으니 Unicorn 엔진으로 이 Thumb 펌웨어를 그대로 실행했다. flash·SRAM 을 매핑하고, USART1 의 상태 레지스터(0x40011000) 읽기는 항상 TXE 준비됨으로 응답하게, 데이터 레지스터(0x40011004) write 는 후킹해서 나가는 바이트를 모았다.

def usart_read(uc, offset, size, user):
    if offset == 0x00:      # USART_SR: TXE|TC 항상 준비됨
        return 0xC0
    return 0
 
def usart_write(uc, offset, size, value, user):
    if offset == 0x04:      # USART_DR: 송신 바이트
        captured.append(value & 0xFF)
 
uc.mmio_map(0x40011000, 0x1000, usart_read, None, usart_write, None)
uc.reg_write(UC_ARM_REG_SP, 0x20020000)
uc.emu_start(0x08000250 | 1, 0, count=0)   # 리셋 핸들러부터

보드가 실제로 클럭아웃하는 바이트는 07 01 04 07 14 48 73 19 14 1b …. 사람이 읽을 수 없는 값이다. 여기서 "출력이 곧 flag" 라고 착각하면 막힌다 — 이건 암호문(CT)이고, 정적 분석에서 예측한 XOR 결과와 바이트 단위로 정확히 일치한다. 정적·동적 두 갈래가 같은 답을 가리키니 이제 되돌리면 된다.

🔓 복호 — 자체 완결 solve

CT 를 base64("stm32f4-discovery") 로 XOR 해 원문 base64 를 복원하고, 그걸 다시 base64 디코드하면 숨은 메시지가 나온다.

import base64
 
# USART1_DR 로 나온 바이트 (Unicorn 으로 캡처)
CT = bytes.fromhex("0701040714487319141b631d026b1c1e2f4913042a3d2e00")
 
key_b64 = b"c3RtMzJmNC1kaXNjb3Zlcnk="            # base64("stm32f4-discovery")
 
recovered_b64 = bytes(CT[i] ^ key_b64[i % len(key_b64)] for i in range(len(key_b64)))
secret = base64.b64decode(recovered_b64).decode()
 
print("recovered base64 :", recovered_b64.decode())
print("b64 decode       :", secret)
print("flag             : acsc{%s}" % secret)

복원된 base64 d2VsY29tZXRvc3RtMzIhISE= → 디코드 → welcometostm32!!!. 이걸 소문자 형식에 넣어 acsc{welcometostm32!!!} 를 제출하니 정답(HTTP 201, 해결 처리)이다.

🛡️ 방어 관점에서 배울 점

장난처럼 보이는 문제지만 실제 임베디드 보안에 그대로 닿아 있다.

• 펌웨어에 하드코딩한 "키"는 키가 아니다. 여기서 XOR 키 stm32f4-discovery 는 그냥 flash 에 base64 로 박혀 있었다. 물리 접근이나 flash 덤프 한 번이면 끝난다. 진짜 비밀은 secure element·OTP·PUF 처럼 읽어낼 수 없는 곳에 둬야 한다.
• XOR 은 암호화가 아니다. 반복키 XOR 은 키만 알면 즉시 되돌아가고, 여기선 키까지 같은 바이너리 안에 있었다. 난독화(미끼 문자열, 죽은 코드)를 아무리 얹어도 "쉽게 되돌아가는 변환"이라는 본질은 안 바뀐다.
• strip 은 방어가 아니라 속도 방지턱이다. 심볼을 다 지워도 벡터 테이블·주변장치 주소·문자열은 남고, 디스어셈블러와 에뮬레이터로 로직은 그대로 복원된다. 기밀성이 필요하면 코드 난독화가 아니라 실행 환경(secure boot, 읽기 보호 RDP)으로 지켜야 한다.
• 분석 측면에서는, 미끼에 흔들리지 말고 "코드가 실제로 무엇을 읽고 쓰는가"만 따라가면 된다. getKey 가 반환값을 안 쓰고 문자열을 로드만 하는 걸 디스어셈블로 확인하는 순간, 네 개의 미끼는 한꺼번에 걸러졌다.

마무리

strings 한 방으로 끝날 것 같던 769바이트가, 실은 "출력이 곧 답이 아니다"라는 한 겹을 숨겨둔 문제였다. Cortex-M 벡터 테이블에서 로드 주소를 읽고 → Thumb 을 디스어셈블해 미끼를 걸러내고 → 반복키 XOR 을 찾아 → Unicorn 으로 실측하고 → 되돌린다. 마지막에 대문자·소문자 하나로 헤맨 건 덤이지만, 그 덕에 "제출 형식은 문제 설명에서 먼저 확인하자"는 기본을 한 번 더 되새겼다.

FLAG: acsc{welcometostm32!!!}