31. Binary Diffing: 패치에서 취약점 찾는 빠른 루틴

바이너리 diff는 패치 노트를 대신하는 지도가 아니라, 두 빌드의 차이를 설명하는 가설 생성기다. 소유한 소프트웨어나 공개 패치 분석, 승인된 취약점 연구에만 사용한다. “바뀐 함수가 곧 취약점”이라는 단정은 컴파일러 최적화와 빌드 환경 차이를 무시한다.

비교 전에 맞춰야 할 것

구버전과 신버전의 아키텍처, 컴파일러, 최적화, 심볼·디버그 정보, 링크된 라이브러리를 기록한다. 가능하면 동일한 재현 빌드와 함수 심볼을 준비하고, 해시와 빌드 ID를 보존한다. Diaphora나 Ghidra Version Tracking으로 함수를 매칭할 때 이름뿐 아니라 CFG, 호출자·피호출자, 문자열과 상수 참조를 함께 확인한다.

sha256sum old.bin new.bin
readelf -n old.bin new.bin
objdump -dM intel old.bin > old.asm
objdump -dM intel new.bin > new.asm

변경을 의미로 좁히기

변경 함수에서 입력 길이 계산, 정수 변환, 경계 비교, 권한 검사, 복호화 전후의 버퍼 수명부터 본다. 새로 추가된 len <= cap 검사는 방어일 수 있지만, 부호 있는 비교·정수 오버플로·호출자 계약과 함께 읽어야 한다. 에러 경로가 합쳐졌다는 사실도 보안 개선의 증거가 아니다. 데이터 흐름이 외부 입력에서 위험한 sink까지 끊겼는지를 추적한다.

패치 전후에 동일한 작은 fixture를 실행하고, 변경 함수의 정상·경계·실패 입력을 비교한다. diff 결과가 가리킨 위치를 소스 패치나 커밋과 대조하면 오탐을 줄일 수 있다. 취약점 연구 결과는 재현 가능한 로컬 테스트와 영향 설명으로 남기며, 패치 우회 페이로드를 운영 대상에 보내지 않는다.

속도는 변경량이 아니라 판단의 질에서 나온다. diff는 어디를 먼저 읽을지 알려주고, 취약점 여부는 경계 조건과 실제 데이터 흐름이 결정한다.