08. CTF에서 checksec로 바이너리 방어기법 빠르게 파악하기

checksec은 익스플로잇을 선택하는 버튼이 아니라 바이너리의 초기 가설을 세우는 요약이다. CTF나 자기 소유 테스트 바이너리에서만 사용하고, 보호 기능이 켜졌다는 사실을 곧바로 “안전하다” 또는 “우회 가능하다”로 번역하지 않는다.

checksec --file=./chall
readelf -W -l ./chall
readelf -s ./chall

NX는 쓰기 가능한 스택을 실행하지 못하게 해 코드 재사용 공격의 필요성을 높인다. Canary는 반환 주소 앞의 값이 바뀌었는지 검사하지만, 모든 메모리 손상을 막지는 않는다. PIE는 실행 파일의 주소도 ASLR의 영향을 받게 한다. RELRO는 GOT 같은 재배치 영역의 쓰기 가능 시점과 범위를 제한한다. 이 설명은 방어 기능의 효과이지, 특정 공격 경로의 보장이 아니다.

출력에서 다음 질문으로

Canary found를 보면 누출 가능성뿐 아니라, 오버플로우가 실제로 canary를 건드리는지부터 확인한다. PIE가 있으면 주소 누출의 필요성을 검토하되, 라이브러리와 스택의 랜덤화도 따로 본다. Partial RELRO와 Full RELRO의 차이는 GOT overwrite 가능성에 관한 것이며, 다른 데이터 포인터나 함수 테이블까지 보호한다는 뜻은 아니다. No RELRO도 곧 취약점은 아니다.

보호 기능의 유무는 file, ELF 헤더, 컴파일 플래그, 런타임 동작을 교차 확인한다. 컨테이너·커널·libc 버전이 달라지면 주소와 동작이 달라질 수 있으므로, 로컬 재현 환경을 기록한다. 방어 평가라면 같은 코드에 보호 플래그를 적용한 빌드를 만들고 충돌·탐지·성능 변화를 측정하는 편이 더 유익하다.

첫 30초의 목적은 공격을 서두르는 것이 아니다. 어떤 가정이 이미 틀렸는지 빨리 제거하고, 추가 분석이 필요한 경계와 보호 공백을 명확히 하는 것이다.