문서 기반 퍼징 가이드 추출 및 Multi-LLM Fuzzing 파이프라인 구축 (`prompt_fuzz`)

C/C++ 라이브러리의 헤더 파일과 문서(README)로부터 API 제약 조건, 메모리 소유권, 보일러플레이트 가이드를 자동 추출하여 유효 Fuzz Driver 생성률과 브랜치 커버리지를 극대화한 연구 및 개발

📌 배경 및 문제 정의 (Problem Statement)

기존 PromptFuzz 등 LLM 기반 Fuzz Driver(Harness) 자동 생성 기법은 타겟 라이브러리의 코드나 문서를 참조하지 않고 단점적인 API 시그니처 정보만 프롬프트로 제공했습니다.

이로 인해 LLM이 C/C++ 라이브러리 특유의 메모리 관리 규약(Free 책임, 소유권 이전) 및 에러 핸들링 보일러플레이트를 파악하지 못해 생성된 Harness의 대다수가 컴파일 또는 실행 시 크래시되는 한계가 존재했습니다.

🔍 사전 실험 및 원인 분석 (cJSON & libpng 실험)

cJSON 80개 Harness 생성 실험: 80개 중 단 24개만 성공(성공률 30%), 실패한 56개 중 LeakSanitizer(메모리 미해제) 25개, AddressSanitizer(Free 후 재사용/Use-After-Free) 22개로 메모리 관리 지식 부족이 주원인임을 입증.
libpng Harness 생성 실험: png_jmpbuf()를 이용한 에러 처리 보일러플레이트 미비로 정상종료(Halt)되지 않고 에러 크래시 발생.
핵심 인사이트: Harness 생성 실패의 주 원인은 API 메모리 소유권(Ownership) 및 라이브러리 고유의 Lifecycle/보일러플레이트 정보 부족에 있음.

💡 주요 구현 및 해결 방안 (Key Solution & Implementation)

1. 문서 및 헤더 파일 자동 수집 & 컨텍스트 통합 엔진 (`src/request/openai.rs`)

타겟 라이브러리의 시스템/라이브러리 헤더 파일(include_sys_headers, include_lib_headers)과 빌드 디렉토리 내 문서 파일(README.md, README.txt, README)을 자동 로드.
--- Header File --- 및 --- Documentation File --- 구조로 분류하여 LLM 컨텍스트로 결합.

2. Structured Outputs (JSON Schema) 기반 정밀 퍼징 가이드 추출

OpenAI의 ResponseFormatJsonSchema 규격을 적용하여 strict 모드의 스키마(fuzzing_harness_gen) 정의 및 강제 고정.
API 메모리 소유권 및 제약 조건 구조화:
arg_ownership_info: 인자 전달 시 소유권 유지/이전 여부 (Caller keeps ownership, Caller loses ownership, None)
ret_ownership_info: 반환값 해제 책임 정보 (Caller owns, Library owns, None)
func_info: API 호출 전 선행 조건 및 필수 사용법
라이브러리 보일러플레이트 가이드 추출:
library_boilerplate: 라이브러리 전용 에러 핸들링 및 필수 초기화/정리 구문 가이드 추출.

3. Multi-LLM 표준 규격 및 비동기 파이프라인 연동 (`src/request/`)

async-openai v0.28 연동 및 환경 변수(OPENAI_MODEL_NAME, OPENAI_PROXY_BASE, OPENAI_CONTEXT_LIMIT) 지원으로 vLLM, Ollama, OpenAI 호환 엔드포인트 연동.
Tokio Runtime 및 futures::future::join_all 기반 비동기 병렬 처리 및 TokenUsage 실시간 모니터링 로거 구현.

📂 퍼징 가이드 추출 및 생성 흐름도 (Data Flow)

flowchart TD
    A[C/C++ Header Files] --> C[Context Aggregator & Structuring]
    B[README / Documentation Files] --> C
    C --> D[OpenAI Structured Outputs<br>ResponseFormatJsonSchema]
    D --> E[Extracted Fuzzing Guide JSON]
    E --> F[API Ownership Info<br>arg/ret ownership]
    E --> G[Usage Constraints &<br>Call Dependencies]
    E --> H[Library Boilerplate &<br>Error Handling Guide]
    F & G & H --> I[System / User Prompt Injection]
    I --> J[High-Quality Fuzz Driver Generation]

📊 정량적 성과 및 실험 결과 (Experimental Results)

GPT-4o-mini 모델 환경에서 6개 주요 C/C++ 라이브러리를 대상으로 11~15시간 동안 퍼징 실험을 진행하여 기존 PromptFuzz와 비교 검증했습니다.

1. 유효 하니스(Valid Harness) 생성 수 비교

문서 기반 퍼징 가이드 주입을 통해 메모리 유실 및 ASan 크래시가 대폭 줄어들어 유효 하니스 생성 수가 최대 4.5배 증가했습니다.

라이브러리	PromptFuzz 유효 하니스	본 프로젝트 유효 하니스	증가율
cJSON	~44개	~80개	↑ 81.8% (1.8배)
c-ares	~6개	~27개	↑ 350.0% (4.5배)
libmagic	~41개	~81개	↑ 97.6% (2.0배)
lcms	~6개	~19개	↑ 216.7% (3.2배)
zlib	~19개	~27개	↑ 42.1% (1.4배)

2. 브랜치 커버리지 (Branch Coverage) 비교 결과

유효 하니스 생성이 증가함에 따라 모든 라이브러리에서 기존 PromptFuzz 대비 브랜치 커버리지가 상승했습니다.

라이브러리	퍼징 시간	기존 PromptFuzz 커버리지	본 프로젝트 커버리지	커버리지 상승 폭 (p)
cJSON	13시간	78.37%	87.38%	↑ 9.01%p
libmagic	13시간	37.62%	45.40%	↑ 7.78%p
c-ares	15시간	39.87%	45.03%	↑ 5.16%p
zlib	11시간	59.88%	62.01%	↑ 2.13%p
re2	15시간	41.96%	43.16%	↑ 1.20%p
lcms	15시간	23.01%	23.38%	↑ 0.37%p

🎯 연구 인사이트 (Key Takeaways)

API 문서와 헤더 파일의 메모리 관리 및 보일러플레이트 정보가 명확히 명시된 라이브러리일수록 (cJSON, libmagic, c-ares) 유효 하니스 비율과 브랜치 커버리지가 비례하여 대폭 상승(최대 9.01%p)함.
높은 품질의 유효 하니스가 초기에 대량 생성됨으로써 더 짧은 시간에 높은 커버리지 목표치에 도달함을 검증함.

문서 기반 퍼징 가이드 추출 및 Multi-LLM Fuzzing 파이프라인 구축 (prompt_fuzz)