ACTION REQUIRED (읽은 후 즉시 실행)
NOW:../field-journal/precedent-reverse.md를 읽어 이 스킬의 작업이 승인된 정규 작업인지 확인NOW: 현재 작업이 이 스킬의 적용 범위에 해당하는지 확인NEXT:../tool-index.md를 읽어 도구 사용 가능성과 실제 경로 확인NEXT: 도구가 없으면 bootstrap을 호출하고, 경로를 추측하지 마세요ACT: "워크플로" 첫 단계로 진입해 실행하고, 확인 상태에서 멈추지 마세요
취약점 지점에서 작동하는 Exploit까지 (Pwn Chain)
적용 범위
다음 시나리오에 해당할 때 이 스킬을 사용하세요:
- 바이너리 + 알려진 취약점 확보 — 정적 분석/감사/fuzz로 오버플로/UAF/double free를 찾았고, 트리거부터 쉘 획득까지 필요함
- CTF 문제 로컬에서는 통과했지만, 원격에서는 실패 — 원격 환경 차이로 스크립트가 깨져서 안정화가 필요함
- 실제 대상 바이너리 익스플로잇 — SRC/Red Team 상황에서 메모리 손상 취약점을 이미 확인했고, RCE 구성이 필요함
- Linux 커널 드라이버 ioctl 버그 — 사용자 공간에서 트리거하며, 목표는 root 권한 상승
전제 조건: 이미 "어디서 터지는지"를 알고 있어야 합니다. 이 스킬은 취약점 발견(fuzzing/감사)을 담당하지 않으며, "취약점 지점에서 Exploit을 작성"하는 것만 담당합니다.
다른 스킬과의 분업
| 시나리오 | 사용할 스킬 |
|---|---|
| 사용자 정의 VM / 안티디버그 / 복잡한 난독화 식별 | reverse-engineering/ |
| 처음부터 바이너리를 열어 정적 분석 | ida-reverse/ 또는 radare2/ |
| 취약점 지점을 알고, Exploit을 작성해 원격까지 연결 | 이 스킬 |
| pwn으로 획득한 쉘을 전체 공격 체인에 통합 | attack-chain/ (하위) |
reverse-engineering/ 스킬은 "프로그램이 무엇을 하는지 이해"(패턴 인식, 프로토콜 복원, CTF 문제의 이상한 매커니즘 해석)에 집중하고, 이 스킬은 "이미 이해한 취약점을 실행 가능한 공격으로 전환"하는 데 집중합니다. 두 스킬은 자주 함께 사용되지만 역할이 명확히 나뉩니다.
핵심 워크플로
Step 1: 취약점 유형 + 보호 기계 확인
├─ checksec ./vuln (NX / Canary / PIE / RELRO / Fortify)
├─ file ./vuln + readelf -d ./vuln
├─ 취약점 분류: 스택 오버플로 / 포맷 스트링 / 힙 (UAF/DF/OF) / 정수 / 경쟁 조건 / 커널
└─ → 어떤 references/ 경로를 따를지 결정
Step 2: 익스플로잇 전략 선택
├─ NX 꺼짐 + ASLR 없음 → 직접 쉘코드
├─ NX 켜짐 + libc 제공 → ret2libc / one_gadget
├─ NX 켜짐 + libc 미제공 → leak 후 libc-database 역추적
├─ 힙 → glibc 버전에 따른 기술 (tcache/fastbin/unsorted/large)
└─ 커널 → commit_creds / modprobe_path / core_pattern
Step 3: libc + 가젯 준비
├─ libc-database：./find puts 0x6f0
├─ ROPgadget --binary ./libc.so.6 --only "pop|ret"
├─ one_gadget ./libc.so.6
└─ base 계산：leak_addr - libc.sym['puts']
Step 4: pwntools 템플릿 작성 (로컬 process)
├─ context.binary = ELF('./vuln')
├─ p = process('./vuln') / p = gdb.debug('./vuln','b *main+xx')
├─ payload = cyclic(N) + p64(ret) + ...
└─ p.interactive()
Step 5: 로컬 통과
├─ 반복 attach + 레지스터 확인 + 오프셋 조정
├─ pwndbg/GEF의 vmmap / heap / bins / telescope 사용
└─ 통과 후 remote() 전환
Step 6: 원격 안정화
├─ libc 오프셋: leak을 통해 libc-database 역추적, 추측 금지
├─ 스택 정렬: 16바이트 미정렬 → movaps 크래시 → ret 가젯 하나 추가
├─ 원격 네트워크 지연 → recvuntil로 문자열 정확히 고정, 막연한 sleep 금지
├─ 원격 버퍼: sendline은 sendlineafter보다 불안정
├─ 힙 스프레이 성공률: spray 양 늘리고, 병합 방지용 padding chunk 유지
└─ 여러 번 실행: while True로 성공률 95% 이상 검증
대표 시나리오
시나리오 1: 원격 64비트 바이너리 (NX+PIE+canary, libc 제공)
이미 확보: ./vuln (64-bit ELF, NX, PIE, canary) + ./libc.so.6 + nc host port
취약점: read(buf, 0x200) 이지만 buf는 0x40바이트 → 스택 오버플로
보호 기법: canary 차단, PIE로 .text 주소 랜덤화
전략:
1. 먼저 canary 누설 (스택/포맷 문자열/부분 읽기)
2. 그 다음 libc 함수 주소 누설 (puts@got)
3. libc.address = leaked - libc.sym['puts'] 로 libc base 계산
4. one_gadget ./libc.so.6 실행하여 제약 조건을 만족하는 magic gadget 선택
5. payload = padding + canary + saved_rbp + (pop_rdi + bin_sh + system) 또는 직접 one_gadget
6. ret 가젯 하나 추가하여 스택 정렬 (중요!)
전체 템플릿은 references/stack-pwn.md 참조.
시나리오 2: Linux 커널 드라이버 ioctl 경계 초과 쓰기 → root 획득
이미 확보: vmlinux + bzImage + initramfs.cpio.gz + 사용자 정의 vuln.ko
취약점: ioctl(0x1337, ptr) 내 copy_from_user 길이 제어 가능 → 커널 힙 오버플로 (kmalloc-64 slab)
보호 기법: SMEP, SMAP, KASLR, KPTI
전략:
1. init 스크립트를 수정해 root 쉘 획득 (CTF) 또는 먼저 KASLR base 누설 후 진행 (실제 환경)
2. /proc/kallsyms (권한 제한 가능) 또는 초기화되지 않은 힙 스프레이로 커널 베이스 주소 누설
3. kmalloc-64 slab에서 tty_struct / msg_msg / pipe_buffer 스프레이
4. vtable 포인터를 사용자 공간으로 덮어쓰기 → 불가능 (SMEP), stack pivot + 커널 ROP로 변경
5. ROP 체인: prepare_kernel_cred(0) → commit_creds → swapgs+iretq → 사용자 공간 execve("/bin/sh")
6. 더 간단한 방법: modprobe_path를 "/tmp/x"로 덮어쓰고, /tmp/x 작성 후 modprobe 트리거
전체 템플릿은 references/kernel-pwn.md 참조.
온디맨드 부트스트랩 (On-Demand Bootstrap)
도구 의존성
| 도구 | 용도 | 설치 방법 |
|---|---|---|
| pwntools | 익스플로잇 작성 프레임워크 | pip install pwntools |
| GEF | gdb 강화 (커널 + 사용자 공간 추천) | git clone https://github.com/bata24/gef (fork 유지 관리 활발) |
| pwndbg | gdb 강화 (힙 디버깅 최고) | git clone https://github.com/pwndbg/pwndbg && ./setup.sh |
| ROPgadget | 가젯 검색 | pip install ropgadget |
| Ropper | 가젯 검색 (대안, 다양한 아키텍처 지원) | pip install ropper |
| one_gadget | libc magic gadget 검색 | gem install one_gadget (ruby 필요) |
| libc-database | libc 지문 역추적 | git clone https://github.com/niklasb/libc-database && ./get |
| qemu-system-x86_64 | 커널 문제 디버깅 | apt install qemu-system-x86 |
| binwalk / cpio | initramfs 압축 해제 | apt install binwalk cpio |
| patchelf | libc 버전 전환 | apt install patchelf |
부트스트랩 검사 스크립트
# 원클릭 검사 + 핵심 도구 설치
for t in pwntools ropgadget ropper; do
pip show $t >/dev/null 2>&1 || pip install $t
done
command -v one_gadget >/dev/null || gem install one_gadget
[ -d ~/tools/libc-database ] || git clone https://github.com/niklasb/libc-database ~/tools/libc-database
[ -d ~/tools/libc-database/db ] || (cd ~/tools/libc-database && ./get ubuntu debian)
[ -d ~/tools/pwndbg ] || (git clone https://github.com/pwndbg/pwndbg ~/tools/pwndbg && cd ~/tools/pwndbg && ./setup.sh)
동일 도구 자동 설치 2회 실패 후
재시도를 중단하고 구조화된 수동 설치 단계(pip 소스 / gem 소스 / git 국내 미러 / apt 소스)를 출력하여 사용자가 확인하도록 합니다.
라우팅 컨텍스트
상위 진입점: skills/SKILL.md (총괄), routing.md
트리거 조건: 바이너리 + 이미 식별된 취약점 지점이 있고, Exploit 작성 필요
상위 스킬 (먼저 사용한 후 이 스킬로 복귀):
- 바이너리가 무엇을 하는지 아직 모를 때 →
reverse-engineering/ - 정적 상세 분석 필요 →
ida-reverse/ - 빠른 정찰로 아키텍처/보호 기법 확인 →
radare2/
하위 스킬 (쉘 획득 후):
- 전체 공격 체인에 통합 (측면 이동, 권한 상승, 지속성) →
attack-chain/
서브모듈 네비게이션:
- 스택 기반 익스플로잇 (ret2libc / ret2csu / one_gadget / 스택 정렬) →
references/stack-pwn.md - 힙 기반 익스플로잇 (tcache / fastbin / unsorted / large bin / FILE struct) →
references/heap-pwn.md - 커널 pwn (kROP / SMEP-SMAP 우회 / KASLR leak / modprobe_path) →
references/kernel-pwn.md
주의사항
- 로컬에서 통과했다고 끝내지 마세요 — 로컬 libc / ASLR / 네트워크 환경이 모두 원격과 다르므로, 반드시 remote 모드에서 20회 이상 연속 실행하여 안정성을 검증해야 합니다.
- libc 버전을 반드시 확인하세요 — leak + libc-database 역추적을 사용하고, Ubuntu 22.04 기본 libc라고 가정하지 마세요.
- 스택 정렬은 64비트의 흔한 함정 —
movaps xmm0, [rsp]가 rsp가 16바이트 정렬되지 않았을 때 세그멘테이션 오류를 발생시킵니다. 빈ret가젯 하나를 추가하여 해결합니다. - 힙 익스플로잇은 glibc 버전에 매우 민감 — tcache는 2.27에서 도입, safe-linking은 2.32에서 도입, 2.34에서 hooks 제거, 각 버전마다 익스플로잇 경로가 다릅니다.
- 커널 pwn은 먼저 cpu 플래그를 확인해야 함 — qemu 부팅 인자에 +smep +smap +pku가 있는지 여부가 ROP 체인 작성 방법을 직접 결정합니다.
- KASLR leak은 한 번이면 충분 — 하나의 커널 주소를 얻으면 모든 주소를 오프셋으로 계산할 수 있으므로 반복해서 누설하지 마세요.
작업 완료 자체 점검 (완료했다고 말하기 전에 MUST 통과)
- 워크플로의 각 단계를 실행했습니까 (단순히 읽기만 한 것이 아니라)?
-
tool-index를 기반으로 실제 도구 경로를 사용했습니까? - 재현 가능한 증거(명령어/스크립트/스크린샷/보고서)를 생성했습니까?
- RULES가 요구하는 Checklist 항목을 완료하고 기록했습니까?