새 소식: TriforceAFL과 TLSF를 사용해보려는 분들을 위해 Richard Johnson이 두 가지를 모두 설치해 주는 Dockerfile을 만들었습니다(심지어 Linux 커널도 빌드해 줍니다). https://hub.docker.com/r/moflow/afl-triforce/tags/에서 확인할 수 있습니다.

또한 새 소식: afl-tmin이 이제 forkserver와 함께 작동합니다!

https://github.com/nccgroup/TriforceAFL Jesse Hertz [email protected] Tim Newsham [email protected]

이것은 QEMU를 사용한 전체 시스템 퍼징(full-system fuzzing)을 지원하는 AFL의 패치 버전입니다. 포함된 QEMU는 x86_64용 시스템 에뮬레이터 실행 시 브랜치 추적이 가능하도록 업데이트되었습니다. AFL의 forkserver를 시작하고 퍼즈 설정을 지정하며 테스트 케이스의 시작과 종료를 표시하는 추가 명령어가 포함되어 있습니다.

참고: 모든 AFL 도구가 새로운 변경 사항으로 테스트된 것은 아닙니다. 다음 도구들은 일부 테스트가 수행되었습니다:

afl-fuzz - -QQ 지원하도록 패치됨
afl-showmap - -QQ 및 forkserver(배칭 포함) 지원하도록 패치됨
afl-cmin - -QQ 지원 및 forkserver 사용하도록 패치됨, stdin은 더 이상 지원되지 않음
afl-analyze - -QQ 지원하도록 패치됨
afl-tmin - -QQ 지원하도록 패치됨, 그러나 forkserver는 지원하지 않음!

빌드하려면:

make

커버리지 맵을 얻으려면:

echo hello > /tmp/hello ./afl-showmap -o coverage.txt -QQ --
./afl-qemu-system-trace -kernel ../bzImage
-initrd ../initramfs.cpio.gz -m 1G -nographic
-append "console=ttyS0" -aflFile /tmp/hello cat coverage.txt

퍼징하려면:

figure out what addrs to use below...

egrep ' (panic|log_store)$' ../mykern/kallsyms ffffffff8108e570 t log_store ffffffff8181064b T panic

mkdir inputs echo hello > inputs/hello ./afl-fuzz -i inputs -o outputs -QQ --
afl-qemu-system-trace -kernel bzImage -initrd root.cpio.gz
-m 1G -nographic -append "console=ttyS0"
-aflPanicAddr ffffffff8181064b -aflDmesgAddr ffffffff8108e570
-aflFile @@

(참고: "-Q" 옵션을 사용할 때와 달리, "-QQ" 옵션을 사용할 때는 afl-qemu-system-trace에 전체 명령줄을 지정해야 합니다).

이 수정된 AFL 버전 사용에 대한 자세한 내용은 https://github.com/nccgroup/TriforceLinuxSyscallFuzzer 의 Linux syscall 퍼저를 참조하십시오.

새 AFL 플래그: -QQ - 사용자 모드(-Q) 대신 전체 시스템 에뮬레이션에서 qemu 사용

새 QEMU 플래그: -aflFile - 퍼저 입력이 포함된 파일의 이름 -aflPanicAddr - 패닉 감지를 위한 커널 패닉 주소 -aflDmesgAddr - 로깅 감지 및 로그 메시지 가로채기를 위한 dmesg 로깅 함수의 Linux 커널 주소

새 QEMU 명령어: 0f 24 - aflCall edi=1 startForkserver(esi=enableTicks) Start AFL's fork server. After this point each test will run in a separate forked child. If enableTicks is non-zero, QEMU will re-enable the CPUs timer after forking a child, otherwise it will not be enabled. edi=2 getWork(esi=ptr, edx=sz) Fill ptr[0..sz] with the next input test case. Returns the actual size filled (<= sz). edi=3 startWork(esi=ptr) Tell AFL to start tracing. The argument points to a buffer with two quadwords giving the start and end address of the code to trace. Instructions outside of this range are not traced. edi=4 doneWork(esi=exitCode) Tell AFL that the test case has completed. If a panic is detected, AFL will stop the test case immediately. Otherwise it will run until doneWork is called. The exitCode specified is returned to AFL. (The code can, but currently does not, OR in the value 64 to all exit codes if any dmesg logs were detected during the test case.)

새 QEMU 블록 드라이버: -drive filename=privmem: 이 블록 드라이버는 드라이브 이미지를 copy-on-write 메모리에 유지하므로 변경 사항이 디스크에 영구 저장되지 않습니다. 한 테스트 케이스가 수행한 변경 사항은 다른 테스트 케이스와 격리됩니다.

================== american fuzzy lop

작성 및 유지보수: Michal Zalewski [email protected]

저작권 2013, 2014, 2015, 2016 Google Inc. 모든 권리 보유. Apache License, Version 2.0의 약관 및 조건에 따라 배포됩니다.

새 버전 및 추가 정보는 다음에서 확인하십시오: http://lcamtuf.coredump.cx/afl/

다른 사용자와 의견을 교환하거나 주요 새 기능에 대한 알림을 받으려면 [email protected]로 메일을 보내십시오.

** 이 파일을 읽을 시간이 없다면 QuickStartGuide.txt를 참조하십시오. **

가이드 퍼징의 과제

퍼징(Fuzzing)은 실제 소프트웨어에서 보안 문제를 식별하는 가장 강력하고 검증된 전략 중 하나입니다. 현재까지 보안이 중요한 소프트웨어에서 발견된 원격 코드 실행 및 권한 상승 버그의 대부분은 퍼징 덕분입니다.

불행히도 퍼징은 비교적 얕습니다. 맹목적인 무작위 변이는 테스트 대상 코드의 특정 코드 경로에 도달할 가능성을 매우 낮추며, 일부 취약점은 이 기법의 범위를 완전히 벗어나게 됩니다.

이 문제를 해결하려는 시도는 많았습니다. 초기 접근 방식 중 하나인 코퍼스 증류(corpus distillation)는 Tavis Ormandy가 개척했습니다. 이 방법은 커버리지 신호를 사용하여 방대하고 고품질의 후보 파일 코퍼스에서 흥미로운 시드의 하위 집합을 선택한 다음 전통적인 방식으로 퍼징합니다. 이 접근 방식은 매우 효과적이지만, 그러한 코퍼스가 readily 제공되어야 합니다. 게다가 블록 커버리지 측정은 프로그램 상태에 대한 매우 단순한 이해만 제공하므로 장기적으로 퍼징 노력을 안내하는 데는 덜 유용합니다.

그 외에도 더 정교한 연구는 프로그램 흐름 분석("concolic execution"), 기호 실행(symbolic execution), 정적 분석(static analysis)과 같은 기법에 초점을 맞추었습니다. 이러한 방법들은 실험 환경에서는 매우 유망하지만, 실제 사용에서는 신뢰성과 성능 문제가 따르는 경향이 있으며, 현재로서는 "단순한(dumb)" 퍼징 기법에 대한 실용적인 대안을 제공하지 못합니다.

afl-fuzz 접근 방식

American Fuzzy Lop은 매우 단순하지만 견고한 계측 기반 유전 알고리즘(instrumentation-guided genetic algorithm)과 결합된 무차별 대입(brute-force) 퍼저입니다. 변형된 형태의 엣지 커버리지(edge coverage)를 사용하여 프로그램 제어 흐름의 미묘하고 국지적인 변화를 쉽게 감지합니다.

약간 단순화하면 전체 알고리즘은 다음과 같이 요약할 수 있습니다:

사용자가 제공한 초기 테스트 케이스를 큐에 로드한다.
큐에서 다음 입력 파일을 가져온다.
프로그램의 측정된 동작을 변경하지 않는 가장 작은 크기로 테스트 케이스를 줄이도록 시도한다.
균형 잡히고 잘 연구된 다양한 전통적인 퍼징 전략을 사용하여 파일을 반복적으로 변이시킨다.
생성된 변이 중 하나라도 계측에 의해 기록된 새로운 상태 전이를 초래한 경우, 변이된 출력을 큐의 새 항목으로 추가한다.
2로 이동한다.

발견된 테스트 케이스는 또한 주기적으로 정리되어 더 새롭고 커버리지가 높은 발견으로 대체된 항목을 제거하며, 계측 기반의 여러 다른 노력 최소화 단계를 거칩니다.

퍼징 과정의 부산물로 이 도구는 흥미로운 테스트 케이스로 구성된 작고 자족적인 코퍼스를 생성합니다. 이는 노동 또는 리소스 집약적인 다른 테스트 방식의 시드로 매우 유용합니다. 예를 들어 브라우저, 오피스 애플리케이션, 그래픽 제품군 또는 클로즈드소스 도구의 스트레스 테스트에 사용할 수 있습니다.

이 퍼저는 맹목적 퍼징이나 커버리지 전용 도구보다 훨씬 뛰어난 기본 성능을 제공하도록 철저히 테스트되었습니다.

AFL과 함께 사용하기 위한 프로그램 계측

소스 코드가 제공되는 경우, 타사 코드의 표준 빌드 프로세스에서 gcc 또는 clang을 대체하여 사용할 수 있는 동반 도구로 계측을 주입할 수 있습니다.

이 계측은 성능 영향이 상당히 작습니다. afl-fuzz가 구현한 다른 최적화와 결합하면 대부분의 프로그램을 전통적인 도구로 가능한 것과 같거나 더 빠른 속도로 퍼징할 수 있습니다.

대상 프로그램을 다시 컴파일하는 올바른 방법은 빌드 프로세스의 세부 사항에 따라 다를 수 있지만, 거의 모든 경우에 적용되는 접근 방식은 다음과 같습니다:

$ CC=/path/to/afl/afl-gcc ./configure $ make clean all

C++ 프로그램의 경우 CXX=/path/to/afl/afl-g++도 설정해야 합니다.

clang 래퍼(afl-clang 및 afl-clang++)도 같은 방식으로 사용할 수 있습니다. clang 사용자는 llvm_mode/README.llvm에 설명된 대로 더 높은 성능의 계측 모드를 활용할 수도 있습니다.

라이브러리를 테스트할 때는 stdin 또는 파일에서 데이터를 읽어 테스트 대상 라이브러리에 전달하는 간단한 프로그램을 찾거나 작성해야 합니다. 이 경우 이 실행 파일을 계측된 라이브러리의 정적 버전에 링크하거나, 런타임에 올바른 .so 파일이 로드되도록 해야 합니다(일반적으로 LD_LIBRARY_PATH를 설정). 가장 간단한 옵션은 정적 빌드이며, 일반적으로 다음을 통해 가능합니다:

$ CC=/path/to/afl/afl-gcc ./configure --disable-shared

'make' 호출 시 AFL_HARDEN=1을 설정하면 CC 래퍼가 단순한 메모리 버그를 더 쉽게 감지할 수 있도록 코드 하드닝 옵션을 자동으로 활성화합니다.

참고. ASAN 사용자는 중요한 주의 사항을 위해 notes_for_asan.txt 파일을 검토하는 것이 좋습니다.

바이너리 전용 앱 계측

소스 코드를 사용할 수 없는 경우, 퍼저는 블랙박스 바이너리의 빠른 실시간 계측(on-the-fly instrumentation)에 대한 실험적 지원을 제공합니다. 이는 잘 알려지지 않은 "사용자 공간 에뮬레이션(user space emulation)" 모드로 실행되는 QEMU 버전을 통해 구현됩니다.

QEMU는 AFL과 별개의 프로젝트이지만, 다음을 통해 이 기능을 편리하게 빌드할 수 있습니다:

$ cd qemu_mode $ ./build_qemu_support.sh

추가 지침 및 주의 사항은 qemu_mode/README.qemu를 참조하십시오.

이 모드는 컴파일 타임 계측보다 약 2-5배 느리며, 병렬화에 덜 적합하고, 다른 몇 가지 특이한 점이 있을 수 있습니다.

초기 테스트 케이스 선택

올바르게 작동하려면 퍼저는 대상 애플리케이션이 일반적으로 기대하는 입력 데이터의 좋은 예를 포함하는 하나 이상의 시작 파일이 필요합니다. 두 가지 기본 규칙이 있습니다:

파일을 작게 유지하십시오. 1kB 미만이 이상적이지만 반드시 필요한 것은 아닙니다. 크기가 중요한 이유에 대한 논의는 perf_tips.txt를 참조하십시오.
여러 테스트 케이스는 서로 기능적으로 다른 경우에만 사용하십시오. 이미지 라이브러리를 퍼징하기 위해 50장의 서로 다른 휴가 사진을 사용하는 것은 의미가 없습니다.

이 도구와 함께 제공되는 testcases/ 하위 디렉토리에서 시작 파일의 좋은 예를 많이 찾을 수 있습니다.

참고. 선별을 위해 대량의 데이터 코퍼스를 사용할 수 있다면, afl-cmin 유틸리티를 사용하여 대상 바이너리에서 서로 다른 코드 경로를 실행하는 기능적으로 구별되는 파일의 하위 집합을 식별할 수 있습니다.

바이너리 퍼징

퍼징 프로세스 자체는 afl-fuzz 유틸리티가 수행합니다. 이 프로그램은 초기 테스트 케이스가 포함된 읽기 전용 디렉토리, 결과를 저장할 별도의 장소, 그리고 테스트할 바이너리의 경로가 필요합니다.

stdin에서 직접 입력을 받는 대상 바이너리의 일반적인 구문은 다음과 같습니다:

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]

파일에서 입력을 받는 프로그램의 경우 '@@'를 사용하여 대상 명령줄에서 입력 파일 이름이 들어가야 할 위치를 표시하십시오. 퍼저가 이를 자동으로 대체합니다:

$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@

변이된 데이터를 특정 파일에 기록하려면 -f 옵션을 사용할 수도 있습니다. 이는 프로그램이 특정 파일 확장자 등을 기대하는 경우에 유용합니다.

계측되지 않은 바이너리는 QEMU 모드(명령줄에 -Q 추가) 또는 전통적인 맹목적 퍼저 모드(-n 지정)로 퍼징할 수 있습니다.

실행 프로세스의 기본 시간 제한과 메모리 한도를 재정의하려면 -t 및 -m을 사용할 수 있습니다. 이러한 설정을 조정해야 할 수 있는 드문 대상의 예로는 컴파일러와 비디오 디코더가 있습니다.

퍼징 성능 최적화 팁은 perf_tips.txt에서 다룹니다.

afl-fuzz는 먼저 일련의 결정적(deterministic) 퍼징 단계를 수행하며, 이는 며칠이 걸릴 수 있습니다. zzuf나 honggfuzz처럼 즉시 빠르고 대략적인 결과를 원한다면 명령줄에 -d 옵션을 추가하십시오.

출력 해석

표시된 통계를 해석하고 프로세스 상태를 모니터링하는 방법에 대한 정보는 status_screen.txt 파일을 참조하십시오. 특히 UI 요소가 빨간색으로 강조 표시된 경우 이 파일을 반드시 확인하십시오.

퍼징 프로세스는 Ctrl-C를 누를 때까지 계속됩니다. 최소한 퍼저가 큐 사이클을 한 번 완료하도록 허용해야 하며, 이는 몇 시간에서 일주일가량 걸릴 수 있습니다.

출력 디렉토리 안에는 실시간으로 업데이트되는 세 개의 하위 디렉토리가 생성됩니다:

queue/ - 모든 고유한 실행 경로에 대한 테스트 케이스와 사용자가 제공한 모든 시작 파일. 이는 섹션 2에서 언급한 합성 코퍼스입니다.

       다른 목적으로 이 코퍼스를 사용하기 전에 afl-cmin 도구를 사용하여
       더 작은 크기로 줄일 수 있습니다. 이 도구는 동등한 엣지 커버리지를
       제공하는 더 작은 파일 하위 집합을 찾아냅니다.

crashes/ - 테스트 대상 프로그램이 치명적인 신호(예: SIGSEGV, SIGILL, SIGABRT)를 받게 하는 고유한 테스트 케이스. 항목은 수신된 신호별로 그룹화됩니다.
hangs/ - 테스트 대상 프로그램이 시간 초과되게 하는 고유한 테스트 케이스. 기본(공격적인) 시간 초과 설정이 적용 중일 때는 대기 시간 급증 및 기타 자연스러운 현상으로 인해 약간의 노이즈가 있을 수 있습니다.

크래시와 hang은 관련 실행 경로에 이전에 기록된 오류에서 볼 수 없었던 상태 전이가 포함된 경우 "고유"한 것으로 간주됩니다. 하나의 버그에 여러 방식으로 도달할 수 있다면 프로세스 초기에 카운트가 부풀려질 수 있지만, 곧 빠르게 줄어들 것입니다.

크래시와 hang의 파일 이름은 오류가 발생하지 않은 상위 큐 항목과 연관됩니다. 이는 디버깅에 도움이 됩니다.

afl-fuzz가 발견한 크래시를 재현할 수 없다면 가장 가능성 있는 원인은 도구에서 사용한 것과 동일한 메모리 한도를 설정하지 않았기 때문입니다. 다음과 같이 시도해 보십시오:

$ LIMIT_MB=50 $ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )

LIMIT_MB를 afl-fuzz에 전달한 -m 매개변수와 일치하도록 변경하십시오. OpenBSD에서는 -Sv도 -Sd로 변경하십시오.

중단된 작업을 재개하려면 기존 출력 디렉토리를 사용할 수도 있습니다:

$ ./afl-fuzz -i- -o existing_output_dir [...etc...]

gnuplot이 설치되어 있다면 afl-plot을 사용하여 실행 중인 퍼징 작업에 대한 멋진 그래프를 생성할 수도 있습니다. 어떤 모습인지 예시는 http://lcamtuf.coredump.cx/afl/plot/에서 확인할 수 있습니다.

병렬 퍼징

각 afl-fuzz 인스턴스는 대략 하나의 코어를 차지합니다. 즉, 멀티코어 시스템에서는 하드웨어를 완전히 활용하려면 병렬화가 필요합니다. 여러 코어 또는 여러 네트워크 연결 머신에서 공통 대상을 퍼징하는 방법에 대한 팁은 parallel_fuzzing.txt를 참조하십시오.

퍼저 사전

기본적으로 afl-fuzz 변이 엔진은 컴팩트한 데이터 형식(예: 이미지, 멀티미디어, 압축 데이터, 정규식 구문, 셸 스크립트)에 최적화되어 있습니다. 특히 장황하고 중복이 많은 언어(대표적으로 HTML, SQL, JavaScript)에는 다소 적합하지 않습니다.

구문 인식 도구를 직접 구축하는 번거로움을 피하기 위해 afl-fuzz는 대상 데이터 유형과 연관된 언어 키워드, 매직 헤더 또는 기타 특수 토큰의 선택적 사전으로 퍼징 프로세스를 시드할 수 있는 방법을 제공하며, 이를 통해 기본 문법을 즉석에서 재구성합니다:

http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html

이 기능을 사용하려면 먼저 testcases/README.testcases에서 설명하는 두 가지 형식 중 하나로 사전을 만들어야 합니다. 그런 다음 명령줄의 -x 옵션을 통해 퍼저가 해당 사전을 참조하도록 지정하십시오.

기본 구문에 대해 더 구조화된 설명을 제공할 방법은 없지만, 퍼저는 계측 피드백만으로도 그중 일부를 파악할 가능성이 높습니다. 이는 실제로 효과가 있으며, 예를 들어:

http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html

참고. 명시적인 사전이 제공되지 않더라도 afl-fuzz는 결정적 바이트 플립 과정에서 계측을 매우 면밀히 관찰하여 입력 코퍼스에 존재하는 구문 토큰을 추출하려 시도합니다. 이는 일부 유형의 파서와 문법에서 작동하지만, -x 모드만큼 훌륭하지는 않습니다.

크래시 분류(triage)

커버리지 기반 크래시 그룹화는 일반적으로 수동으로 또는 매우 간단한 GDB나 Valgrind 스크립트로 신속하게 분류할 수 있는 작은 데이터 세트를 생성합니다. 또한 모든 크래시는 큐의 상위 비크래시 테스트 케이스로 추적할 수 있으므로 결함 진단이 더 쉽습니다.

그렇긴 하지만, 일부 퍼징 크래시는 많은 디버깅 및 코드 분석 작업 없이는 악용 가능성을 신속하게 평가하기 어려울 수 있다는 점을 인정하는 것이 중요합니다. 이 작업을 지원하기 위해 afl-fuzz는 -C 플래그로 활성화되는 매우 독특한 "크래시 탐색(crash exploration)" 모드를 지원합니다.

이 모드에서 퍼저는 하나 이상의 크래시 테스트 케이스를 입력으로 받아 피드백 기반 퍼징 전략을 사용하여 프로그램을 크래시 상태로 유지하면서 도달할 수 있는 모든 코드 경로를 매우 빠르게 열거합니다.

크래시를 발생시키지 않는 변이는 거부됩니다. 실행 경로에 영향을 주지 않는 변경 사항도 마찬가지로 거부됩니다.

출력은 매우 신속하게 검토할 수 있는 작은 파일 코퍼스로, 공격자가 오류가 발생한 주소에 대해 어느 정도의 제어권을 가지는지, 초기 경계 밖 읽기(out-of-bounds read)를 지나칠 수 있는지 여부와 그 아래에 무엇이 있는지 확인할 수 있습니다.

아, 한 가지 더: 테스트 케이스 최소화를 위해 afl-tmin을 사용해 보십시오. 이 도구는 매우 간단한 방식으로 사용할 수 있습니다:

$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]

이 도구는 크래시 및 비크래시 테스트 케이스 모두에서 작동합니다. 크래시 모드에서는 계측된 바이너리와 계측되지 않은 바이너리를 모두 수용합니다. 비크래시 모드에서 최소화 도구는 표준 AFL 계측을 사용하여 실행 경로를 변경하지 않고 파일을 더 단순하게 만듭니다.

최소화 도구는 afl-fuzz와 호환되는 방식으로 -m, -t, -f 및 @@ 구문을 지원합니다.

AFL에 최근 추가된 또 다른 도구는 afl-analyze입니다. 이 도구는 입력 파일을 받아 바이트를 순차적으로 플립하고 테스트 대상 프로그램의 동작을 관찰합니다. 그런 다음 중요해 보이는 섹션과 그렇지 않은 섹션을 기준으로 입력을 색상 코드로 표시합니다. 완벽하지는 않지만 복잡한 파일 형식에 대한 빠른 통찰을 제공하는 경우가 많습니다. 작동 방식에 대한 자세한 내용은 technical_details.txt의 끝 부분에서 확인할 수 있습니다.

상식적인 위험

다른 많은 계산 집약적 작업과 마찬가지로 퍼징은 하드웨어와 OS에 부담을 줄 수 있습니다. 특히 다음 사항을 유의하십시오:

CPU가 뜨거워지며 적절한 냉각이 필요합니다. 대부분의 경우 냉각이 불충분하거나 제대로 작동하지 않으면 CPU 속도가 자동으로 조절됩니다. 그렇긴 하지만, 특히 덜 적합한 하드웨어(노트북, 스마트폰 등)에서 퍼징할 때 문제가 발생할 가능성이 완전히 없는 것은 아닙니다.
대상 프로그램이 불규칙하게 수 기가바이트의 메모리를 점유하거나 정크 파일로 디스크 공간을 채울 수 있습니다. AFL은 기본 메모리 한도를 적용하려고 하지만 모든 가능한 사고를 막을 수는 없습니다. 결론적으로 데이터 손실 가능성이 허용 가능한 위험이 아닌 시스템에서는 퍼징을 해서는 안 됩니다.- 퍼징은 파일시스템에 대한 수십억 회의 읽기와 쓰기를 수반합니다. 최신 시스템에서는 이 작업이 대개 대량으로 캐시되어 "물리적" I/O는 상당히 완만하지만, 이 공식을 바꿀 수 있는 요인은 많습니다. 잠재적 문제를 모니터링하는 것은 여러분의 책임입니다. 매우 과중한 I/O가 발생하면 많은 HDD와 SSD의 수명이 단축될 수 있습니다.

Linux에서 디스크 I/O를 모니터링하는 좋은 방법은 'iostat' 명령입니다:

$ iostat -d 3 -x -k [...optional disk ID...]

알려진 제한 사항 및 개선 영역

다음은 AFL에 대한 가장 중요한 주의 사항 몇 가지입니다:

AFL은 시그널(SIGSEGV, SIGABRT 등)로 인해 첫 번째 생성된 프로세스가 종료되는지를 확인하여 결함을 감지합니다. 이러한 시그널에 대한 사용자 정의 핸들러를 설치하는 프로그램은 관련 코드를 주석 처리해야 할 수 있습니다. 마찬가지로, 퍼징 대상이 생성한 자식 프로세스에서 발생한 결함은 이를 포착하는 코드를 직접 추가하지 않는 한 감지를 피할 수 있습니다.
다른 무차별 대입(brute-force) 도구와 마찬가지로, 테스트할 실제 데이터 형식이 암호화, 체크섬, 암호화 서명 또는 압축으로 완전히 래핑되어 있으면 퍼저의 커버리지는 제한적입니다.

이 문제를 우회하려면 관련 검사를 주석 처리할 수 있습니다(참고: experimental/libpng_no_checksum/). 이것이 불가능하다면, experimental/post_library/에 설명된 대로 후처리기(postprocessor)를 작성할 수도 있습니다.
ASAN 및 64비트 바이너리에는 몇 가지 아쉬운 트레이드오프가 있습니다. 이것은 afl-fuzz의 특정 결함 때문이 아닙니다. 팁은 notes_for_asan.txt를 참조하세요.
네트워크 서비스, 백그라운드 데몬, 또는 UI 상호작용이 필요한 대화형 앱의 퍼징은 직접적으로 지원되지 않습니다. 이러한 대상이 보다 전통적인 방식으로 동작하도록 하려면 간단한 코드 변경이 필요할 수 있습니다. Preeny도 비교적 간단한 옵션을 제공할 수 있습니다 - 참조: https://github.com/zardus/preeny

네트워크 기반 서비스 수정에 유용한 팁은 다음에서도 찾을 수 있습니다: https://www.fastly.com/blog/how-to-fuzz-server-american-fuzzy-lop
AFL은 사람이 읽을 수 있는 커버리지 데이터를 출력하지 않습니다. 커버리지를 모니터링하려면 Michael Rash의 afl-cov를 사용하세요: https://github.com/mrash/afl-cov

그 외에도 플랫폼별 팁은 INSTALL을 참조하세요.

특별 감사

다음 사람들의 피드백, 버그 리포트, 또는 패치 없이는 afl-fuzz의 많은 개선이 불가능했을 것입니다:

Jann Horn Hanno Boeck Felix Groebert Jakub Wilk Richard W. M. Jones Alexander Cherepanov Tom Ritter Hovik Manucharyan Sebastian Roschke Eberhard Mattes Padraig Brady Ben Laurie @dronesec Luca Barbato Tobias Ospelt Thomas Jarosch Martin Carpenter Mudge Zatko Joe Zbiciak Ryan Govostes Michael Rash William Robinet Jonathan Gray Filipe Cabecinhas Nico Weber Jodie Cunningham Andrew Griffiths Parker Thompson Jonathan Neuschfer Tyler Nighswander Ben Nagy Samir Aguiar Aidan Thornton Aleksandar Nikolich Sam Hakim Laszlo Szekeres David A. Wheeler Turo Lamminen Andreas Stieger Richard Godbee Louis Dassy teor2345 Alex Moneger Dmitry Vyukov Keegan McAllister Kostya Serebryany Richo Healey Martijn Bogaard rc0r Jonathan Foote Christian Holler Dominique Pelle Jacek Wielemborek Leo Barnes Jeremy Barnes Jeff Trull Guillaume Endignoux ilovezfs Daniel Godas-Lopez Franjo Ivancic

감사합니다!

연락처

질문? 우려 사항? 버그 리포트? 작성자는 대개 [email protected]으로 연락할 수 있습니다.

프로젝트의 메일링 리스트도 있습니다. 가입하려면 [email protected]으로 메일을 보내세요. 또는 먼저 아카이브를 둘러보고 싶다면 다음을 참조하세요:

https://groups.google.com/group/afl-users

https://cla.developers.google.com/clas

번거롭게 해드려 죄송합니다. 물론 기능 요청이나 버그 리포트에는 CLA가 필요 없습니다.

TriforceAFL

인기

figure out what addrs to use below...

================== american fuzzy lop