커버리지 기반 퍼징
실제 타겟을 피드백 하에서 실행하고, 의도된 오라클과 재현 가능한 생명주기를 갖추게 하세요. 실행 중인 퍼즈 바이너리나 증가하는 코퍼스가 유용한 타겟 도달 범위를 보장하지는 않습니다: "corpus count 값은 커버리지가 얼마나 좋은지 확인하기 위한 나쁜 지표입니다" (AFL++ 심층 퍼징 §3.g).
실제 레인 선택
타겟 진입점, 빌드 그래프, 활성화된 기능, 런타임/아키텍처, 디코더 및 속성을 읽으세요. 계측을 받는 타겟 모듈과 퍼즈 빌드 하에서 변경되는 사항을 식별하세요; 드라이버만 계측된 경로나 래퍼에서만 활성화된 기능은 의도된 구현을 놓칠 수 있습니다. cargo-fuzz의 기능 옵션은 전달될 때까지 "fuzz_targets 크레이트를 제어"하며, libFuzzer는 계측(-fsanitize=fuzzer-no-link)과 자체 main() 연결을 분리합니다 (Rust Fuzz Book 가이드, Cargo 기능, LLVM libFuzzer, 퍼저 사용법).
기존에 맞는 프로듀서와 빌드 소유자를 사용하세요. 해당하는 실행 참조만 선택하세요:
| 타겟 | 참조 문서 |
|---|---|
| 네이티브 소스/바이너리, AFL++ 또는 libFuzzer | 네이티브 러너 |
| Go 또는 Rust | Go와 Rust |
| Python/네이티브 확장 또는 JVM | Python과 JVM |
| FuzzTest를 사용하는 C++ 속성 도메인 | C++ FuzzTest |
| Node.js (CJS, ESM, Jest를 통한 TypeScript) | Node.js with Jazzer.js |
브라우저 애플리케이션 코드에는 프로세스 내 커버리지 기반 경로가 없습니다: Jazzer.js는 "기타 런타임 또는 브라우저 지원"을 범위 밖으로 둡니다 (Jazzer.js 아키텍처, 제약 사항). 브라우저 UI 탐색은 UI 이벤트 시퀀스를 담당하는 스킬로 라우팅하세요.
설정을 변경하기 전에 선택한 릴리스의 전제 조건과 설치된 도움말을 확인하세요. 참조 문서는 날짜가 기록된 소스 스냅샷을 기록한 것이지, 모든 버전/플랫폼이 동일한 플래그를 지원한다는 약속이 아닙니다. 사용자의 기존 권한 내에서 호출하세요; 이 스킬은 자체적으로 설치, 타겟 편집 또는 외부 지출을 승인하지 않습니다.
유한한 정보 제공 파일럿 실행
작업자를 추가하기 전에 탐색 모드, 관련 타겟 계측, 상태 리셋 및 작동하는 오라클을 설정하세요. Go 시드 재생, Jazzer 회귀 모드, Jazzer.js Jest 회귀 모드 및 FuzzTest 단위 모드는 탐색 모드와 다릅니다: 일반 go test는 "유닛 테스트와 매우 유사하게" 시드를 실행하고, "Jazzer는 퍼징 모드가 명시적으로 활성화되지 않으면 회귀 모드로 작동"하며, Jazzer.js는 Jest에서 기본값이 "regression"이고, FuzzTest 단위 모드는 "새니타이저 및 커버리지 계측 없이" 실행됩니다 (Go 퍼징, 퍼즈 테스트 실행, Jazzer README, 회귀 모드, Jazzer.js 퍼징 설정, 모드, FuzzTest Bazel 빠른 시작, 퍼즈 테스트 생성 및 실행).
디코더 수용, 의도된 작동, 성공적인 효과 및 속성 평가를 엔진 커버리지와 별도로 관찰하세요; 압축 형식의 바이트 변이는 "생성된 입력의 거의 전부가 uncompress에 대해 유효하지 않게" 만들 수 있습니다 (Google 구조 인식 퍼징 가이드, 예제: 압축). 거부된 형식, 숨겨진 상태 또는 충족되지 않은 종속성을 도달, 리셋 및 피드백을 사용하여 진단하세요. 입증된 차단자에 대해 사전/비교 피드백 또는 구조적 변이를 선택하세요; 각각은 탐색의 다른 부분을 변경합니다 (AFL++ CmpLog, Google 구조 인식 퍼징 가이드).
입력당, 퍼즈 시간, 벽시계 시간, 작업자/CPU 및 메모리 제어를 구분하고, 승인된 범위에 설정/재생 비용을 포함시키세요. AFL++ -V는 "(퍼즈 시간 전용!)"이고 -E는 "대략적인 총 실행 횟수"입니다; 둘 다 집계 프로세스 CPU가 아닙니다 (AFL++ selected-ref CLI 소스, 사용법 텍스트). Go -timeout은 퍼징 단계를 제한하지 않습니다 (Go와 Rust). 분리된 소유 출력과 소유 프로세스의 제한된 정리를 사용하세요; libFuzzer는 정확한 아티팩트 경로에 대해 "여러 병렬 프로세스에 동일한 경로를 사용하지 마십시오"라고 말합니다 (LLVM libFuzzer, 옵션). 할당 결정은 bugfinding-campaign을 참조하세요.
증거 해석 및 보존
정확한 입력/타입 인수, 빌드/설정/계측, 초기 상태 또는 시퀀스, 명령/제한, 원시 엔진 출력, 타겟/속성 카운터 및 방출된 재생 자료를 보존하세요. 호출 간 상태 및 생명주기 차이는 단일 파일 재현을 무효화할 수 있습니다: Go는 "퍼즈 타겟의 상태는 각 호출이 끝난 후에도 지속되어서는 안 된다"고 요구하며, Jazzer의 기본 PER_TEST는 "퍼즈 테스트 실행 간에 의도치 않게 상태를 보존할 가능성이 더 높습니다" (Go 퍼징, 제안, Jazzer 생명주기 구현).
실제로 실행된 것, 관찰된 속성, 리소스 사용, 후보 및 누락을 반환하세요. 탐색과 회귀, 커버리지와 의미적 도달, 후보 실패와 제품 귀속을 구분하세요. 호환 가능한 보존/교환에는 corpus-evolution, 증인 보존 축소에는 failure-reduction, 귀속에는 evidence-based-triage를 사용하세요. 과거 시드 선택 결과는 타겟/스케줄러에 따라 다릅니다; Rebert 등은 한 가설이 "최적 스케줄링 하에서는 거짓"임을 발견했지만 라운드-로빈 하에서 다시 테스트했습니다. 이를 보편적인 처리량 또는 수율 약속으로 바꾸지 마세요 (Rebert et al., pp.864,871,873).
구체적인 오해의 소지가 있는 실행 및 수정 사항은 일반적인 실수를 읽으세요. 이 스킬에서 타겟별 새로운 프레임워크가 도출되지는 않습니다.