google/aflamerican fuzzy lop - 보안 지향 퍼저
원래 Michal Zalewski([email protected])가 개발했습니다.
이 파일을 읽을 시간이 없다면 QuickStartGuide.txt를 참조하세요.
퍼징(Fuzzing)은 실제 소프트웨어에서 보안 문제를 식별하는 가장 강력하고 검증된 전략 중 하나입니다. 현재까지 보안에 중요한 소프트웨어에서 발견된 원격 코드 실행 및 권한 상승 버그의 대부분은 퍼징 덕분입니다.
불행히도 퍼징은 비교적 얕습니다. 맹목적인 무작위 변이는 테스트 대상 코드의 특정 코드 경로에 도달할 가능성을 매우 낮게 만들어, 일부 취약점은 이 기법의 범위 밖에 남게 됩니다.
이 문제를 해결하려는 수많은 시도가 있었습니다. 초기 접근법 중 하나는 Tavis Ormandy가 개척한 코퍼스 정제(corpus distillation)입니다. 이 방법은 커버리지 신호를 사용하여 방대하고 품질 좋은 후보 파일 코퍼스에서 흥미로운 시드(seed)의 하위 집합을 선택한 다음, 전통적인 수단으로 퍼징합니다. 이 접근법은 매우 잘 작동하지만 그러한 코퍼스가 쉽게 준비되어 있어야 합니다. 게다가 블록 커버리지 측정은 프로그램 상태에 대한 매우 단순한 이해만을 제공하므로, 장기적으로 퍼징 노력을 안내하는 데는 덜 유용합니다.
다른 더 정교한 연구는 프로그램 흐름 분석("concolic execution"), 기호 실행, 또는 정적 분석과 같은 기법에 집중해 왔습니다. 이러한 모든 방법은 실험 환경에서는 매우 유망하지만, 실제 사용에서는 신뢰성과 성능 문제를 겪는 경향이 있으며, 현재로서는 "단순한" 퍼징 기법에 대한 실행 가능한 대안을 제공하지 못합니다.
American Fuzzy Lop은 매우 단순하지만 견고한 계측 기반 유전 알고리즘과 결합된 무차별 대입 퍼저입니다. 프로그램 제어 흐름의 미묘하고 국소적인 변화를 쉽게 포착하기 위해 변형된 형태의 엣지 커버리지를 사용합니다.
약간 단순화하면, 전체 알고리즘은 다음과 같이 요약할 수 있습니다.
사용자가 제공한 초기 테스트 케이스를 큐에 로드합니다.
큐에서 다음 입력 파일을 가져옵니다.
프로그램의 측정된 동작을 변경하지 않는 가장 작은 크기로 테스트 케이스를 줄이려고 시도합니다.
균형 잡히고 잘 연구된 다양한 전통적인 퍼징 전략을 사용하여 파일을 반복적으로 변형합니다.
생성된 변형 중 하나라도 계측에 기록된 새로운 상태 전이를 초래한 경우, 변형된 출력을 큐에 새 항목으로 추가합니다.
2단계로 이동합니다.
발견된 테스트 케이스는 또한 새롭고 더 높은 커버리지를 가진 발견으로 대체된 것을 제거하기 위해 주기적으로 선별되며, 계측 기반의 여러 작업량 최소화 단계를 거칩니다.
퍼징 과정의 부산물로, 이 도구는 흥미로운 테스트 케이스로 구성된 작고 자족적인 코퍼스를 생성합니다. 이는 다른 노동 집약적이거나 리소스 집약적인 테스트 방식을 시딩(seeding)하는 데 매우 유용합니다. 예를 들어 브라우저, 오피스 애플리케이션, 그래픽 제품군 또는 클로즈드 소스 도구를 스트레스 테스트하는 경우가 있습니다.
이 퍼저는 맹목적인 퍼징이나 커버리지 전용 도구보다 훨씬 뛰어난 즉시 사용 가능한 성능을 제공하도록 철저히 테스트되었습니다.
소스 코드를 사용할 수 있는 경우, 타사 코드의 표준 빌드 프로세스에서 gcc 또는 clang을 대체하는 드롭인(drop-in) 도구로 작동하는 동반 도구를 통해 계측을 주입할 수 있습니다.
계측은 성능에 상당히 적당한 영향을 미칩니다. afl-fuzz가 구현한 다른 최적화와 함께, 대부분의 프로그램은 전통적인 도구보다 빠르거나 심지어 더 빠르게 퍼징할 수 있습니다.
대상 프로그램을 올바르게 다시 컴파일하는 방법은 빌드 프로세스의 세부 사항에 따라 다를 수 있지만, 거의 보편적으로 적용되는 방법은 다음과 같습니다.```shell $ 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에 설명된 대로 더 높은 성능의
계측(instrumentation) 모드를 활용할 수도 있습니다.
라이브러리를 테스트할 때는 stdin 또는 파일에서 데이터를 읽어
테스트 대상 라이브러리에 전달하는 간단한 프로그램을 찾거나 작성해야 합니다.
이러한 경우, 이 실행 파일을 계측된 라이브러리의 정적 버전에 링크하거나
런타임에 올바른 .so 파일이 로드되도록 (보통 `LD_LIBRARY_PATH`를 설정하여)
해야 합니다. 가장 간단한 방법은 정적 빌드이며,
일반적으로 다음과 같이 가능합니다:```shell
$ CC=/path/to/afl/afl-gcc ./configure --disable-shared
'make'를 호출할 때 AFL_HARDEN=1을 설정하면 CC 래퍼가
간단한 메모리 버그를 더 쉽게 탐지할 수 있도록 코드 하드닝
옵션을 자동으로 활성화합니다. AFL에 포함된 헬퍼 라이브러리인
Libdislocator(libdislocator/README.dislocator 참조)도 힙 손상 문제를 발견하는 데 도움이 될 수 있습니다.
참고: ASAN 사용자는 중요한 주의사항이 있으므로 notes_for_asan.txt 파일을 검토할 것을 권장합니다.
소스 코드를 사용할 수 없는 경우, 퍼저는 블랙박스 바이너리의 빠른 온더플라이 계측을 위한 실험적 지원을 제공합니다. 이는 잘 알려지지 않은 "사용자 공간 에뮬레이션" 모드로 실행되는 QEMU 버전을 통해 구현됩니다.
QEMU는 AFL과 별개의 프로젝트이지만, 다음을 실행하여 해당 기능을 편리하게 빌드할 수 있습니다:```shell $ cd qemu_mode $ ./build_qemu_support.sh
For additional instructions and caveats, see qemu_mode/README.qemu.
The mode is approximately 2-5x slower than compile-time instrumentation, is
less conducive to parallelization, and may have some other quirks.
## 5) Choosing initial test cases
To operate correctly, the fuzzer requires one or more starting file that
contains a good example of the input data normally expected by the targeted
application. There are two basic rules:
- Keep the files small. Under 1 kB is ideal, although not strictly necessary.
For a discussion of why size matters, see [perf_tips.txt](https://github.com/google/afl/blob/HEAD/docs/perf_tips.txt).
- Use multiple test cases only if they are functionally different from
each other. There is no point in using fifty different vacation photos
to fuzz an image library.
You can find many good examples of starting files in the testcases/ subdirectory
that comes with this tool.
PS. If a large corpus of data is available for screening, you may want to use
the afl-cmin utility to identify a subset of functionally distinct files that
exercise different code paths in the target binary.
## 6) Fuzzing binaries
The fuzzing process itself is carried out by the afl-fuzz utility. This program
requires a read-only directory with initial test cases, a separate place to
store its findings, plus a path to the binary to test.
For target binaries that accept input directly from stdin, the usual syntax is:```shell
$ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program [...params...]
For programs that take input from a file, use '@@' to mark the location in the target's command line where the input file name should be placed. The fuzzer will substitute this for you:
파일에서 입력을 받는 프로그램의 경우, '@@'를 사용하여 대상의 명령줄에서 입력 파일 이름이 배치되어야 할 위치를 표시하십시오. 퍼저가 이를 대신 대체해 줄 것입니다:```shell $ ./afl-fuzz -i testcase_dir -o findings_dir /path/to/program @@
또한 -f 옵션을 사용하여 변형된 데이터를 특정
파일에 쓸 수 있습니다. 이는 프로그램이 특정 파일 확장자 등을 기대하는 경우에 유용합니다.
계측되지 않은 바이너리는 QEMU 모드(명령줄에 -Q 추가)에서 퍼징하거나
전통적인 블라인드 퍼저 모드(-n 지정)로 퍼징할 수 있습니다.
-t 및 -m을 사용하여 실행 프로세스의 기본 시간 제한과 메모리 한도를
재정의할 수 있습니다. 이러한 설정을 조정해야 하는 드문 대상의 예로는
컴파일러와 비디오 디코더가 있습니다.
퍼징 성능 최적화를 위한 팁은 [perf_tips.txt](https://github.com/google/afl/blob/HEAD/docs/perf_tips.txt)에서 논의됩니다.
afl-fuzz는 일련의 결정적(deterministic) 퍼징 단계를 수행하는 것으로 시작한다는 점을 유의하십시오.
이 단계는 며칠이 걸릴 수 있지만 깔끔한 테스트 케이스를 생성하는 경향이 있습니다.
zzuf 및 기타 전통적인 퍼저와 마찬가지로 즉시 빠르고 조잡한 결과를 원한다면
명령줄에 -d 옵션을 추가하십시오.
## 7) 출력 해석
표시된 통계를 해석하고 프로세스 상태를 모니터링하는 방법에 대한 정보는
[status_screen.txt](https://github.com/google/afl/blob/HEAD/docs/status_screen.txt) 파일을 참조하십시오.
특히 UI 요소가 빨간색으로 강조 표시된 경우 이 파일을
반드시 확인하십시오.
퍼징 프로세스는 Ctrl-C를 누를 때까지 계속됩니다. 최소한 퍼저가
하나의 큐 사이클을 완료하도록 허용해야 하며, 이는
몇 시간에서 일주일 정도 걸릴 수 있습니다.
출력 디렉터리 내에 세 개의 하위 디렉터리가 생성되며 실시간으로
업데이트됩니다:
- queue/ - 모든 고유 실행 경로에 대한 테스트 케이스와 사용자가 제공한
모든 시작 파일. 이것은 섹션 2에서 언급된 합성 코퍼스입니다.
이 코퍼스를 다른 목적으로 사용하기 전에 afl-cmin 도구를 사용하여
더 작은 크기로 줄일 수 있습니다. 이 도구는
동일한 엣지 커버리지를 제공하는 더 작은 파일 하위 집합을 찾습니다.
- crashes/ - 테스트 중인 프로그램이 치명적인 신호(예: SIGSEGV, SIGILL, SIGABRT)를
수신하도록 하는 고유 테스트 케이스. 항목은
수신된 신호별로 그룹화됩니다.
- hangs/ - 테스트 중인 프로그램이 시간 초과되도록 하는 고유 테스트 케이스입니다.
어떤 것이 hang으로 분류되기 전의 기본 시간 제한은
1초와 -t 매개변수 값 중 더 큰 값입니다.
이 값은 AFL_HANG_TMOUT을 설정하여 미세 조정할 수 있지만, 이는
거의 필요하지 않습니다.
크래시와 hang은 관련 실행 경로에 이전에 기록된 결함에서 볼 수 없었던
상태 전환이 포함된 경우 "고유"한 것으로 간주됩니다. 단일 버그에
여러 방식으로 도달할 수 있다면 프로세스 초기에 카운트가 다소 부풀려질 수 있지만,
곧 빠르게 줄어들어야 합니다.
크래시 및 hang의 파일 이름은 상위(결함이 없는) 큐 항목과 연관됩니다.
이는 디버깅에 도움이 됩니다.
afl-fuzz가 발견한 크래시를 재현할 수 없는 경우, 가장 가능성 높은 원인은
도구에서 사용한 것과 동일한 메모리 한도를 설정하지 않았기 때문입니다. 다음을 시도해 보십시오:```shell
$ LIMIT_MB=50
$ ( ulimit -Sv $[LIMIT_MB << 10]; /path/to/tested_binary ... )
Change LIMIT_MB를 afl-fuzz에 전달된 -m 매개변수와 일치하도록 변경하세요. OpenBSD에서는 -Sv도 -Sd로 변경하세요.
기존 출력 디렉터리를 사용하여 중단된 작업을 재개할 수도 있습니다. 다음과 같이 시도하세요:```shell $ ./afl-fuzz -i- -o existing_output_dir [...etc...]
gnuplot이 설치되어 있다면, afl-plot을 이용해 실행 중인 퍼징 작업에 대한 보기 좋은 그래프를 생성할 수도 있습니다. 이것이 어떤 모습인지에 대한 예시는 [http://lcamtuf.coredump.cx/afl/plot/](http://lcamtuf.coredump.cx/afl/plot/)에서 확인할 수 있습니다.
## 8) 병렬 퍼징
각각의 afl-fuzz 인스턴스는 대략 코어 하나를 차지합니다. 즉, 멀티코어 시스템에서는 하드웨어를 완전히 활용하려면 병렬화가 필요합니다. 여러 코어 또는 여러 네트워크 연결 머신에서 공통 타깃을 퍼징하는 방법에 대한 팁은 [parallel_fuzzing.txt](https://github.com/google/afl/blob/HEAD/docs/parallel_fuzzing.txt)를 참조하세요.
병렬 퍼징 모드는 또한 AFL을 다른 퍼저, 심볼릭 또는 콘콜릭 실행 엔진 등과 연동하는 간단한 방법을 제공합니다. 역시 팁은 [parallel_fuzzing.txt](https://github.com/google/afl/blob/HEAD/docs/parallel_fuzzing.txt)의 마지막 섹션을 참조하세요.
## 9) 퍼저 사전
기본적으로 afl-fuzz의 변이 엔진은 컴팩트한 데이터 형식(예: 이미지, 멀티미디어, 압축 데이터, 정규 표현식 문법, 셸 스크립트)에 최적화되어 있습니다. HTML, SQL 또는 JavaScript와 같이 특히 장황하고 중복이 많은 언어에는 다소 적합하지 않습니다.
구문 인식 도구를 직접 만드는 번거로움을 피하기 위해, afl-fuzz는 타깃 데이터 형식과 연관된 언어 키워드, 매직 헤더 또는 기타 특수 토큰의 선택적 사전을 퍼징 프로세스에 시드하여 기본 문법을 그 자리에서 재구성하는 방법을 제공합니다:
[http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html](http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html)
이 기능을 사용하려면 먼저 dictionaries/README.dictionaries에서 설명하는 두 가지 형식 중 하나로 사전을 만든 다음, 명령줄에서 -x 옵션을 사용해 퍼저에 지정하면 됩니다.
(해당 하위 디렉터리에는 몇 가지 일반적인 사전도 이미 제공되어 있습니다.)
기본 구문에 대해 더 구조화된 설명을 제공할 방법은 없지만, 퍼저는 계측 피드백만으로도 그중 일부를 파악할 가능성이 높습니다. 이는 실제로 효과가 있으며, 예를 들면 다음과 같습니다:
[http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html](http://lcamtuf.blogspot.com/2015/04/finding-bugs-in-sqlite-easy-way.html)
추신: 명시적인 사전이 주어지지 않더라도 afl-fuzz는 결정적 바이트 플립 과정에서 계측을 매우 면밀히 관찰하여 입력 코퍼스에서 기존 구문 토큰을 추출하려고 시도합니다. 이는 일부 유형의 파서와 문법에서는 작동하지만 -x 모드만큼 좋지는 않습니다.
사전을 구하기 정말 어렵다면, AFL을 잠시 실행한 다음 AFL과 함께 제공되는 보조 유틸리티인 토큰 캡처 라이브러리를 사용하는 방법도 있습니다. 자세한 내용은 libtokencap/README.tokencap를 참조하세요.
## 10) 크래시 분류
커버리지 기반 크래시 그룹화는 일반적으로 소량의 데이터 세트를 생성하며, 이를 수동으로 또는 매우 간단한 GDB나 Valgrind 스크립트로 신속하게 분류할 수 있습니다. 또한 모든 크래시는 큐에 있는 상위 비크래시 테스트 케이스로 추적할 수 있어 결함 진단이 더 쉬워집니다.
그렇기는 하지만, 일부 퍼징 크래시는 많은 디버깅과 코드 분석 작업 없이는 악용 가능성을 빠르게 평가하기 어려울 수 있다는 점을 인정하는 것이 중요합니다. 이 작업을 돕기 위해 afl-fuzz는 -C 플래그로 활성화되는 매우 독특한 "크래시 탐사" 모드를 지원합니다.
이 모드에서 퍼저는 하나 이상의 크래시 테스트 케이스를 입력으로 받아들이고, 피드백 기반 퍼징 전략을 사용하여 프로그램을 크래시 상태로 유지하면서 도달할 수 있는 모든 코드 경로를 매우 빠르게 열거합니다.
크래시를 유발하지 않는 변이는 거부됩니다. 실행 경로에 영향을 주지 않는 변경도 마찬가지로 거부됩니다.
출력은 소규모 파일 코퍼스로, 공격자가 오류 주소를 어느 정도 제어할 수 있는지, 또는 초기 경계 밖 읽기를 넘어설 수 있는지, 그리고 그 아래에 무엇이 있는지 확인하기 위해 매우 빠르게 검토할 수 있습니다.
아, 한 가지 더: 테스트 케이스 최소화에는 afl-tmin을 사용해 보세요. 이 도구는 매우 간단한 방식으로 사용할 수 있습니다:```shell
$ ./afl-tmin -i test_case -o minimized_result -- /path/to/program [...]
이 도구는 크래시 테스트 케이스와 비크래시 테스트 케이스 모두에서 작동합니다. 크래시 모드에서는 계측된 바이너리와 계측되지 않은 바이너리를 모두 문제없이 받아들입니다. 비크래시 모드에서는 최소화 도구가 표준 AFL 계측을 사용하여 실행 경로를 변경하지 않으면서 파일을 더 단순하게 만듭니다.
이 최소화 도구는 afl-fuzz와 호환되는 방식으로 -m, -t, -f 및 @@ 구문을 받아들입니다.
AFL에 최근 추가된 또 다른 도구는 afl-analyze입니다. 이 도구는 입력 파일을 받아 바이트를 순차적으로 뒤집으면서 테스트 대상 프로그램의 동작을 관찰합니다. 그런 다음 입력에서 중요해 보이는 섹션과 그렇지 않은 섹션을 기준으로 색상을 지정합니다. 완벽하게 안전한 방법은 아니지만, 복잡한 파일 형식에 대한 빠른 통찰을 제공하는 경우가 많습니다. 작동 방식에 대한 자세한 내용은 technical_details.txt 문서의 끝부분 근처에서 확인할 수 있습니다.
퍼징은 크래시를 일으키지 않는 설계 및 구현 오류를 발견하는 데에도 훌륭하고 충분히 활용되지 못한 기법입니다. 예를 들어 다음과 같은 상황에서 대상 프로그램이 abort()를 호출하도록 수정함으로써 꽤 많은 흥미로운 버그가 발견되었습니다.
두 개의 bignum 라이브러리가 퍼저가 생성한 동일한 입력을 받았을 때 서로 다른 출력을 생성하는 경우,
이미지 라이브러리가 동일한 입력 이미지를 연속으로 여러 번 디코딩하라는 요청을 받았을 때 서로 다른 출력을 생성하는 경우,
직렬화/역직렬화 라이브러리가 퍼저가 제공한 데이터를 반복적으로 직렬화하고 역직렬화할 때 안정적인 출력을 생성하지 못하는 경우,
압축 라이브러리가 특정 blob을 압축한 다음 압축 해제하라는 요청을 받았을 때 입력 파일과 일관되지 않은 출력을 생성하는 경우.
이러한 또는 유사한 무결성 검사를 구현하는 데는 보통 아주 짧은 시간이 걸립니다. 특정 패키지의 관리자라면 이 코드를 #ifdef FUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION(libfuzzer와도 공유되는 플래그) 또는 #ifdef __AFL_COMPILER(이것은 AFL 전용) 조건부로 만들 수 있습니다.
다른 많은 계산 집약적 작업과 마찬가지로 퍼징은 하드웨어와 운영체제에 부담을 줄 수 있다는 점을 명심하세요. 특히 다음과 같습니다.
CPU는 뜨거워지며 적절한 냉각이 필요합니다. 대부분의 경우 냉각이 불충분하거나 제대로 작동하지 않으면 CPU 속도가 자동으로 제한됩니다. 그렇긴 하지만, 특히 덜 적합한 하드웨어(노트북, 스마트폰 등)에서 퍼징할 때 무언가가 타버릴 가능성이 전혀 없는 것은 아닙니다.
대상 프로그램이 예기치 않게 수 기가바이트의 메모리를 소비하거나 디스크 공간을 정크 파일로 가득 채울 수 있습니다. AFL은 기본적인 메모리 제한을 적용하려고 시도하지만, 가능한 모든 사고를 막을 수는 없습니다. 결론적으로 데이터 손실 가능성이 수용 가능한 위험이 아닌 시스템에서는 퍼징을 수행해서는 안 됩니다.
퍼징은 파일 시스템에 대한 수십억 회의 읽기와 쓰기를 수반합니다. 최신 시스템에서는 일반적으로 이러한 작업이 많이 캐시되어 "물리적" I/O가 상당히 적지만, 이 균형을 바꿀 수 있는 많은 요소가 있습니다. 잠재적인 문제를 모니터링하는 것은 사용자의 책임입니다. 매우 과중한 I/O가 발생하면 많은 HDD와 SSD의 수명이 단축될 수 있습니다.
Linux에서 디스크 I/O를 모니터링하는 좋은 방법은 'iostat' 명령입니다.```shell $ iostat -d 3 -x -k [...optional disk ID...]
## 13) 알려진 제한 사항 및 개선 영역
AFL에 대한 가장 중요한 주의 사항 몇 가지는 다음과 같습니다:
- AFL은 첫 번째로 생성된 프로세스가 시그널(SIGSEGV, SIGABRT 등)로 인해 죽는지 확인하여 결함을 감지합니다. 이러한 시그널에 대한 사용자 정의 핸들러를 설치하는 프로그램은 관련 코드를 주석 처리해야 할 수 있습니다. 마찬가지로 퍼징 대상이 생성한 하위 프로세스의 결함은 수동으로 잡는 코드를 추가하지 않는 한 감지되지 않을 수 있습니다.
- 다른 무차별 대입 도구와 마찬가지로, 실제 테스트할 데이터 형식이 암호화, 체크섬, 암호화 서명 또는 압축으로 완전히 래핑된 경우 퍼저는 제한된 커버리지를 제공합니다.
이 문제를 해결하려면 관련 검사를 주석 처리할 수 있습니다(experimental/libpng_no_checksum/ 참조). 이것이 불가능하면 experimental/post_library/에 설명된 대로 후처리기를 작성할 수도 있습니다.
- ASAN 및 64비트 바이너리와 관련하여 몇 가지 불가피한 트레이드오프가 있습니다. 이는 afl-fuzz의 특정 결함 때문이 아닙니다. 팁은 [notes_for_asan.txt](https://github.com/google/afl/blob/HEAD/docs/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
- 때때로, 감정을 가진 기계가 창조자에 맞서 일어납니다. 이런 일이 발생하면 http://lcamtuf.coredump.cx/prep/를 참조하십시오.
그 외에는 플랫폼별 팁은 INSTALL을 참조하십시오.
## 14) 특별 감사
다음 사람들의 피드백, 버그 보고서 또는 패치가 없었다면 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
Austin Seipp Daniel Komaromy
Daniel Binderman Jonathan Metzman
Vegard Nossum Jan Kneschke
Kurt Roeckx Marcel Bohme
Van-Thuan Pham Abhik Roychoudhury
Joshua J. Drake Toby Hutton
Rene Freingruber Sergey Davidoff
Sami Liedes Craig Young
Andrzej Jackowski Daniel Hodson
감사합니다!
질문이 있으신가요? 우려 사항이 있으신가요? 버그 리포트는 GitHub를 이용해 주세요.
프로젝트 메일링 리스트도 있습니다. 가입하려면 다음 주소로 메일을 보내세요: [email protected]. 또는 먼저 아카이브를 둘러보고 싶다면 다음을 확인해 보세요: https://groups.google.com/group/afl-users.