이것은 AFL++가 완벽하게 처리할 수 있는 간단한 로컬 타겟이며, 예시로 빠르게 제시한 것입니다. Litefuzz는 네트워크 및 GUI 퍼징 측면에서 훨씬 더 많은 기능을 제공하도록 설계되었으므로, 실제로 사용해보면 알게 될 것입니다.

## 이유

네, 또 다른 퍼저입니다. 그리고 현재의 트렌드와 관례에 잘 맞지 않는 퍼저입니다. 특정 요구사항을 충족하기 위해 트레이드오프가 이루어졌습니다. 이러한 요구사항은 기본적으로 여러 플랫폼에서 작동하고, 로컬 및 네트워크 타겟을 모두 퍼징하며, 사용하기 매우 쉬운 퍼저입니다. 누군가를 설득하려는 것이 아니라, 맥락을 제공하려는 것입니다. 일부 타겟은 AFL과 같은 퍼저를 빌드 체인에 통합하는 데 많은 노력이 필요합니다. 이 퍼저는 계측(instrumentation)을 필요로 하지 않으므로 문제가 되지 않으며, 계측을 통해 얻는 정확한 커버리지는 희생하되 사용 편의성과 이식성을 얻었습니다. AFL은 기본적으로 네트워크 퍼징을 지원하지 않으며, 이를 지원하는 프로젝트들이 있지만 사용하기가 간단하지 않고 일반적으로 더 많은 코드 수정과 하네스가 필요합니다 ([Libfuzzer](https://llvm.org/docs/LibFuzzer.html)와 비슷한 이야기입니다).

병렬 퍼징을 하지 않으며, [영구 모드](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html)가 제공하는 엄청난 속도 향상도 지원하지 않으므로, 그러한 기능을 가진 퍼저들에 비해 확장할 수 없습니다. 다시 말하지만, 이것은 최첨단 퍼저가 아닙니다. 그러나 소스 코드, 빌드 설정 또는 특정 OS 기능이 필요하지 않습니다. 일부 네트워크 클라이언트 GUI 및 대화형 앱도 퍼징할 수 있습니다. 여러 측면에서 '있는 그대로' 동작하며, 변이기 및 최소화와 같은 많은 기능은 처음부터 직접 작성되었습니다.

그냥 작동하도록 설계되었으며, 필요한 몇 가지 종속성에 대한 설정 및 설치를 자동화하는 데 노력을 기울였습니다. 이 퍼저는 목적을 위해 작성되었으며, 다양한 타겟 시나리오와 환경에서 가치를 제공하고, 무엇보다도 모든 퍼저가 궁극적으로 평가되어야 할 기준인 버그를 찾는 능력에서 가치를 제공합니다. 그리고 **실제로** [버그](https://github.com/sec-tools/beta/blob/main/README.md#trophies)를 찾습니다. 타겟 소스 코드가 있다고 가정하지 않으므로, 폐쇄 소스 소프트웨어를 상당히 잘 커버할 수 있습니다. 약간의 수정만으로 자동화의 일부로 실행될 수 있지만, 취약점 연구자들이 사용하기에 재미있도록 설계되었습니다. 그러나 완전한 제품보다는 R&D 프로젝트로 생각하는 것이 더 도움이 됩니다. 또한, 기본적으로 약간 망가져 있거나 최신 운영 체제에서 실행하기 위해 추가 작업이 필요한 복잡한 설정은 없습니다.

Ubuntu Linux, Mac 및 Windows에서 작동하는 것으로 테스트되었으며, 퍼징 준비 환경을 설정하기 위해 거의 모든 작업을 자동으로 수행하는 완전한 기능의 스크립트가 함께 제공됩니다.

**설정 스크립트가 완료되면, 다양한 타겟을 퍼징하는 데 몇 분밖에 걸리지 않습니다.**

## 작동 방식

**Litefuzz는 로컬, 클라이언트, 서버의 세 가지 모드를 지원합니다.**

로컬 모드는 로컬 바이너리를 대상으로 하며, Linux/Mac에서는 하위 프로세스로 실행되어 GDB 및 LLDB 트라이지(triage) 지원을 각각 크래시 시에 제공하고, Windows에서는 [WinAppDbg](https://github.com/MarioVilas/winappdbg)를 통해 제공됩니다. 크래시는 로컬 크래시 디렉터리에 기록되며, 읽기/쓰기 AV 또는 SIGABRT/SIGSEGV와 같은 결함 유형과 파일 해시별로 정렬됩니다. 모든 고유 크래시는 퍼징 중에 트라이지되며, 이 데이터와 타겟 출력(가능한 경우)도 캡처되어 동일한 디렉터리에 아티팩트로 배치됩니다. 또한 `--replay` 옵션과 크래시 파일을 제공하여 크래시를 재현할 수도 있습니다. `local` 클라이언트 모드에서는 입력 디렉터리에 서버 인사말, 응답 또는 클라이언트가 서버에 연결할 때 기대하는 데이터가 포함되어야 합니다.

현재로서는 복잡한 세션 지원 없이 네트워크 퍼징을 위한 하나의 '샷'만 구현되어 있습니다. 클라이언트는 명령줄을 통해 실행되며, 파일 퍼징과 동일한 방식으로 디버깅됩니다. 이 시나리오를 지원하기 위해 리스너가 설정됩니다. 느리고 거의 수동 노동에 가깝지만 작동합니다. 크래시가 감지되면 gdb에서 재현되어 트라이지 세부 정보를 얻습니다. `remote` 클라이언트 모드에서는 로컬 디버깅/크래시 트라이지가 없다는 점을 제외하고 동일하게 작동합니다. *로컬* 서버 모드는 로컬 클라이언트 모드와 유사하며, `remote` 서버 모드는 지정된 타겟에 연결하고 사용자가 입력으로 지정한 변이된 샘플 클라이언트 데이터를 보내지만, '여전히 연결할 수 있는가, 그렇지 않으면 마지막 데이터에서 크래시가 발생했을 가능성이 높다'는 간단한 트라이지만 제공합니다.

처음부터 작성된 몇 가지 변이 함수가 있으며, 대부분 `-i` 플래그로 지정된 입력의 무작위 선택으로 무작위 변이를 수행합니다. 파일 퍼징의 경우 로컬 모드를 선택하고 타겟 명령줄에 앱이 파싱할 파일 이름을 나타내는 FUZZ를 전달합니다(예: `tcpdump -r FUZZ`). 또한 변이할 '좋은 파일'의 입력 디렉터리를 제공합니다. 네트워크 클라이언트 퍼징의 경우 로컬 퍼징과 유사하지만, `-a`를 통해 연결 세부 정보도 제공합니다. 서버를 퍼징하려면 서버 모드를 선택하고 클라이언트와 마찬가지로 `protocol://address:port`를 제공합니다.

타겟이 데이터를 소비하고 종료하는 속도(대부분의 CLI 애플리케이션의 경우)만큼 빠르게 퍼징하거나, 로컬 실행 또는 네트워크 연결 시간이 초과되기 전에 사용자가 결정한 시간 동안 퍼징하므로 훨씬 느릴 수 있습니다. 여기에는 화려한 exec 또는 커널 트릭이 없습니다. 물론 입력을 파싱하고 빠르게 종료하는 하네스를 작성하여 타겟의 특정 부분을 커버하는 것도 도움이 됩니다. 그러나 그 정도로 타겟에 근접할 수 있다면, [영구 모드](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html)나 다른 퍼저가 제공하는 유사한 기능을 사용하는 것이 더 나을 것입니다.

간단히 말해서...

### 기능
- linux, windows, mac에서 실행되며 py2/py3 지원
- 파일/stdin에서 읽는 CLI/GUI 바이너리 퍼징
- 네트워크 클라이언트 및 서버 퍼징 (오픈 소스 또는 독점, 로컬 또는 원격 디버깅 가능)
- 크래시의 diff, 최소화, 재현, 정렬 및 자동 트라이지
- TLS 지원, golang 바이너리 퍼징 및 Mac용 일부 추가 기능 등 기타
- 다양한 내장 변이기 + pyradamsa (Linux)로 입력 변이

### 하지 않는 것
- 네이티브 계측
- 동시 작업으로 확장
- 복잡한 세션 퍼징
- 원격 클라이언트 및 서버 모니터링 (연결과 같은 기본 검사만)

## 지원

주로 **Ubuntu Linux 20.04** (22.04 및 21.04는 가볍게 테스트), **Windows 10** 및 **Mac OS 11** (12는 가볍게 테스트)에서 테스트되었습니다. 퍼저와 설정 스크립트는 이러한 운영 체제의 약간 더 오래되었거나 최신 버전에서도 작동할 수 있지만, 대부분의 연구, 테스트 및 개발은 이러한 환경에서 수행되었습니다. Python3가 지원되며, [WinAppDbg](https://github.com/MarioVilas/winappdbg)를 통해 Windows에서 퍼징하는 데 필요하므로 Python2와도 호환되도록 코드를 작성하려고 노력했습니다.

플랫폼 테스트는 주로 Intel 기반 하드웨어에서 수행되었지만, Apple M1 플랫폼에서도 대부분 작동하는 것으로 보입니다 (주목할 만한 예외는 Linux에서 GDB용 exploitable 플러그인이 지원되지 않을 가능성이 있으며, Pyradamsa도 마찬가지입니다). 또한 setup/에 설정 스크립트가 있어 대부분의 작업과 종속성 설치를 자동화합니다. 일반적으로 각 플랫폼에서 네이티브 바이너리(C/C++로 컴파일된 경우가 많음)를 퍼징할 수 있지만, Golang 바이너리의 크래시도 포착할 수 있습니다 (실험적).

### 파이썬 버전

Python3는 Linux 및 Mac에서 지원되며, Python2는 Windows에서 필요합니다.

왜 Linux와 Mac에서는 Py3인가? Pyautogui, Pyradamsa (Linux 전용), Mac에서 더 나은 소켓 지원.

왜 Windows에서는 Py2인가? Winappdbg는 Py2가 필요합니다.

### 리눅스

디버깅에는 GDB를, 크래시 트라이지에는 [exploitable](https://github.com/jfoote/exploitable)을 사용합니다. 오픈 소스인 경우 [샌타이저(sanitizers)](https://fuzzing-project.org/tutorial2.html) 등으로 타겟을 빌드하고 계측할 수 있으며, 그렇지 않으면 실행 시 로드할 수 있는 [메모리 디버거](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption)가 있습니다.

이 설치 과정과 파이썬 종속성 및 기타 유용한 항목은 [setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/linux.sh)로 자동화되었습니다. 권장 OS는 Ubuntu 20.04이며, 대부분의 테스트가 이 환경에서 이루어졌습니다.

### 맥

OS X에서는 gdb 대신 lldb를 디버깅에 사용합니다. XCode 명령줄 도구에 포함되어 있기 때문입니다. 관리자이거나 개발자 그룹에 속해 있으면 lldb를 사용할 수 있어야 하지만, 이 동작은 환경과 버전에 따라 다를 수 있으며, 다른 방법이 없으면 sudo 권한으로 실행해야 할 수도 있습니다.

수동으로 해야 할 한 가지는 SIP를 끄는 것입니다 (복구 모드에서 cmd+R을 통해 또는 vmware fusion 해킹 사용). 그렇지 않으면 Tim Apple의 OS에서 퍼징할 때 자동 트라이지가 실패합니다.

거의 모든 설정이 [setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/mac.sh) 스크립트로 자동화되어 있으므로, 빠른 시작을 위해 실행하기만 하면 됩니다.

### 윈도우

Windows에서는 디버깅에 [WinAppDbg](https://github.com/MarioVilas/winappdbg)를 사용하며, stdin 퍼징이 지원되지 않는다는 약간의 주의사항이 있습니다.

다른 운영 체제의 자동 설정과 마찬가지로, chocolatey가 Windows에서 패키지 설치를 자동화하는 데 도움을 줍니다. litefuzz 루트 디렉터리에서 [setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/windows.bat)를 관리자 권한으로 실행하여 설치를 자동화하십시오. 디버깅 도구 및 기타 종속성을 설치하여 원활하게 실행되도록 합니다.

### 타겟

다음은 테스트되었고 일반적으로 지원되는 타겟 유형 목록입니다.

* 파일 형식이나 stdin을 파싱하는 로컬 CLI/GUI 앱
  - 디버그 지원
* 서버 응답을 파싱하는 로컬 CLI/GUI 네트워크 클라이언트
  - CLI에 대한 디버그 지원
  - GUI에 대한 제한된 디버그 지원
* 클라이언트 요청을 파싱하는 로컬 CLI 네트워크 서버
  - 디버그 지원 (주의: 독립 실행형 실행 파일로 실행 가능해야 함, 그렇지 않으면 *원격*으로 처리 가능)
* 클라이언트 요청을 파싱하는 로컬 GUI 네트워크 서버
  - 이론적으로 지원, 테스트되지 않음
* 서버 응답을 파싱하는 원격 CLI/GUI 네트워크 클라이언트
  - 디버그 지원 없음
* 클라이언트 요청을 파싱하는 원격 CLI/GUI 네트워크 서버
  - 디버그 지원 없음
  - Mac에서 `attach` 또는 `reportcrash` 기능을 사용하는 경우 예외

다시 말하지만, 퍼저는 Linux, Mac 및 Windows에서 로컬 앱, 클라이언트 및 서버를 실행하고 지원할 수 있으며, 물론 타겟 플랫폼과 무관하게 원격 대상을 퍼징할 수 있습니다.

### 트라이지

* 파일 형식이나 stdin을 파싱하는 로컬 CLI/GUI 앱
  - 앱 실행, 신호 포착, 크래셔와 함께 디버거 내에서 다시 실행하여 재현
* 서버 응답을 파싱하는 로컬 CLI/GUI 네트워크 클라이언트
  - 앱 실행, 신호 포착, 크래셔와 함께 디버거 내에서 다시 실행하여 재현
* 클라이언트 요청을 파싱하는 로컬 GUI/CLI 네트워크 서버
  - 디버거에서 앱 실행, 신호 포착, 크래셔와 함께 디버거 내에서 다시 실행하여 재현
* 서버 응답을 파싱하는 원격 CLI/GUI 네트워크 클라이언트
  - 가시성 없음, 원격 측에서 크래시 수집
  - 트라이지를 지원하기 위해 수동으로 스크립트 작성 가능
* 클라이언트 요청을 파싱하는 원격 CLI/GUI 네트워크 서버
  - 가시성 없음, 원격 측에서 크래시 수집
  - 트라이지를 지원하기 위해 수동으로 스크립트 작성 가능
  - Mac의 예외는 `attach` 및 `reportcrash` 옵션으로, 일부 트라이지 기능을 활성화하는 데 사용 가능

## 시작하기

대부분의 플랫폼별 설정은 [setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup) 디렉터리의 스크립트로 자동화되어 있습니다.

litefuzz 루트에서 해당 스크립트를 실행하기만 하면 많은 시간을 절약하고 자동화된 배포에 필요한 일부를 활성화하는 데 도움이 됩니다. 깨끗한 OS 및 퍼징 환경을 설정하기 위해 VM을 사용하는 것이 유용하며, 무엇보다 스냅샷 기능이 유용합니다.

자세한 내용은 [INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md)를 참조하십시오.

**설치 후, 빠른 실행을 위해 초기 섹션의 latex2rtf 예제 퍼징을 참조하거나 이 README에 자세히 설명된 모든 명령줄 옵션 및 추가 예제를 살펴보십시오.**

### 도커

로컬에 종속성을 설치하지 않고 `Dockerfile`을 사용하여 Docker로 litefuzz를 실행할 수 있습니다. 이는 빠른 테스트나 시스템에 종속성 설치를 피하려는 경우 특히 유용합니다.

Dockerfile은 다음 두 가지 방식으로 작동합니다.
- **리포지토리 내에서** - 로컬 파일 사용 (더 빠르며, 로컬 변경 사항 포함)
- **독립 실행형** - 모든 디렉터리에서 빌드 가능 (GitHub에서 클론)```bash
# Build the Docker image (from any directory with Dockerfile)
docker build -t litefuzz:latest .

# Run litefuzz
docker run --rm litefuzz:latest python3 litefuzz.py --help

이것은 다음을 수행합니다:
- latex2rtf를 1000회 반복으로 퍼징합니다
- 힙 디버깅 사용 (`-z` 플래그)
- 크래시를 호스트의 `./crashes` 디렉토리에 저장합니다
- 저장소의 `/litefuzz/input/tex`에 있는 내장 입력 파일 사용

호스트에서 자신의 입력 파일을 사용하려면:```bash
# Create input directory with your test files
mkdir -p input/tex crashes
# Add your test files to input/tex/
cp your-test.tex input/tex/

# Run fuzzing with your input files
docker run --rm \
  -v $(pwd)/input:/litefuzz/input \
  -v $(pwd)/crashes:/tmp/crashes \
  litefuzz:latest \
  python3 litefuzz.py -l -c "latex2rtf FUZZ" -i /litefuzz/input/tex -o /tmp/crashes -n 1000 -z

메인 디렉토리에서 `test_litefuzz.py`에 대한 pytest를 실행하고, 테스트 실행이 완료되면 PASS/FAIL 결과를 제공합니다.

#### 충돌 앱 테스트
다양한 플랫폼에서 충돌 및 분류 기능을 테스트하기 위한 버그가 있는 앱의 몇 가지 예제는 `test` 폴더에서 찾을 수 있습니다.

- (a) 널 포인터 역참조
- (b) 0으로 나누기
- (c) 힙 오버플로우
- (d-gui) GUI의 포맷 문자열 버그
- (e) 클라이언트의 버퍼 오버플로우
- (f) 서버의 버퍼 오버플로우

이들은 설정 중에 자동으로 빌드되며, 명령줄, 디버거에서 실행하거나 퍼징 대상으로 테스트하는 데 사용할 수 있습니다.

**Windows 명령줄에서 실행하는 경우, `이벤트 뷰어 -> Windows 로그 -> 응용 프로그램`에서 충돌을 확인하세요.**

## 옵션
다양한 대상 시나리오를 활용할 수 있는 많은 옵션과 기능이 있습니다. 다음은 이를 사용하는 방법을 이해하는 데 도움이 되는 간단한 설명과 몇 가지 예제입니다.

### 충돌 디렉토리
`-o`를 사용하면 기본값(로컬 경로의 crashes/)이 아닌 다른 충돌 디렉토리를 지정할 수 있습니다. 이를 사용하여 동시에 여러 앱에 대한 여러 퍼징 실행의 충돌 폴더를 관리할 수 있습니다.

### 절연 모드
`-u`는 대상 애플리케이션을 일반 퍼징 프로세스(예: 실행, 반복적인 패킷 전송 및 충돌 확인)로부터 격리합니다. 대신, 이 모드는 대화형 클라이언트 애플리케이션(예: Postman)을 위해 만들어졌으며, 애플리케이션 내에서 스크립트를 작성하여 클라이언트 퍼징을 위한 연결을 반복할 수 있습니다. 대상은 디버거 내에서 실행되고, 퍼저는 일시 중지되어 사용자가 몇 개의 버튼을 클릭하거나 대상의 구성을 자동 실행으로 설정할 시간을 갖습니다. 사용자가 재개하면 이제 대화형 네트워크 클라이언트를 퍼징하고 있습니다.

`litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z`

절연 모드 + 새로고침은 대화형 클라이언트에 사용할 수 있습니다. 예를 들어, 디버거에서 FileZilla를 실행하되, 각 새 반복마다 서버에 다시 연결하도록 F5를 계속 누릅니다. 또한 로컬 CLI/GUI 서버 퍼징은 디버거 내에서 한 번만 시작 및 실행되어 프로세스를 약간 더 효율적으로 만듭니다.

`--key`를 사용하면 대화형 대상을 퍼징하는 동안 키를 보낼 수 있습니다. 예를 들어, F5로 '연결 새로고침'을 보내 FileZilla의 FTP 서버 응답 구문 분석을 퍼징할 수 있습니다.

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc`

참고: 절연 모드는 Linux에서만 테스트되었으며 Windows에서는 지원되지 않습니다.

### 타임아웃
`-x secs`를 사용하여 타임아웃을 지정할 수 있습니다. 실제로는 CLI 대상의 경우 '반복 사이의 대략적인 시간'에 가깝고, GUI의 경우 실제 타임아웃입니다.

### 뮤테이터
`--mutator N`은 퍼징에 사용할 뮤테이터를 지정합니다. 옵션이 제공되지 않으면, 각 퍼징 반복마다 사용 가능한 뮤테이터 목록에서 무작위로 선택됩니다.

이 뮤테이터들은 (물론 Radamsa를 제외하고) 처음부터 작성되었습니다. 수백만 번의 반복 동안 광범위하게 테스트되었고 상당히 잘 견뎌냈지만, 때때로 미묘한 버그가 있을 수 있습니다. 그러나 일반적으로 이는 기능에 영향을 미치지 않습니다.```
FLIP_MUTATOR = 1
HIGHLOW_MUTATOR = 2
INSERT_MUTATOR = 3
REMOVE_MUTATOR = 4
CARVE_MUTATOR = 5
OVERWRITE_MUTATOR = 6
RADAMSA_MUTATOR = 7

### pause
Ctrl+c를 눌러 퍼징 프로세스를 일시 중지합니다. 재개하려면 `y` 또는 `n`을 선택하여 중지합니다. 이 기능은 플랫폼 간에 잘 작동하지만, GUI 앱을 퍼징할 때는 덜 안정적일 수 있습니다.

### reusing crashes for variant finding

`-e`는 재사용 모드를 활성화합니다. 즉, 퍼징 실행 중에 충돌이 발견되면 해당 충돌이 두 번째 퍼징 라운드의 입력으로 사용되어 더 많은 버그를 찾아내는 데 도움이 됩니다. `-z`와 결합하면 `-ez` 버그를 잡을 수 있습니다! Da-duph.

다음 예제는 100000번의 반복으로 antiword를 퍼징한 후, 동일한 반복 횟수와 옵션으로 또 다른 실행을 시작하여 충돌을 입력으로 재사용하여 더 많은 버그를 찾아내는 것입니다.

`litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez`

(또는 충돌을 수동으로 입력 디렉터리에 복사하여 재사용 실행의 반복 횟수를 직접 제어할 수 있습니다.)

`litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z`

참고: 이 모드는 로컬 앱에서만 지원됩니다.

### memory debugging helpers
`-z`는 Linux에서 Electric Fence(또는 대체로 glib malloc 디버깅)를 활성화하고, Mac에서는 Guard Malloc, Windows에서는 PageHeap을 활성화합니다. 또한 `-zz`를 사용하면 애플리케이션에 대해 PageHeap을 활성화한 후 비활성화할 수 있습니다. 퍼저를 시작하지 않고 켜기/끄기만 하려면 `-i` 플래그를 생략하면 됩니다. Windows 설정 중에는 [gsudo](https://github.com/gerardog/gsudo)가 설치되며, 명령줄에서 상승된 명령을 실행하는 데 사용할 수 있습니다(예: 대상에 대해 PageHeap 켜기).

`sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z`

`sudo litefuzz -l -c "notepad FUZZ" -zz`

Linux에서는 특정 도우미를 선택할 수 있습니다. 예를 들어, 기본값으로 glib malloc을 사용하는 대신 선택할 수 있습니다.

`litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc`

기본 Electric Fence malloc 디버거는 훌륭하지만 모든 대상에서 작동하지는 않습니다. EF로 대상을 테스트하고 충돌이 발생하면 대신 glibc 도우미를 선택할 수 있습니다.

### checking live target output
Linux 또는 Mac에서 로컬 앱을 퍼징하는 경우 `cat /tmp/litefuzz/RUN_ID/fuzz.out`을 사용하여 대상의 최신 stdout을 확인할 수 있습니다. `RUN_ID`는 퍼징이 시작될 때 STATS 정보 영역에 표시됩니다. 충돌이 발생하면 stdout도 충돌 디렉터리에 `.out` 파일로 캡처됩니다. 전역 stdout/stderr는 모든 퍼징 대상에 대해 `/tmp/litefuzz/out`으로도 전송되며, 디버깅 목적에 사용됩니다. 단, insulated 또는 로컬 서버 모드의 경우 디버거 출력은 `/tmp/litefuzz/RUN_ID/out`으로 전송됩니다.

Winappdbg는 대상의 stdout 캡처를 기본적으로 지원하지 않으므로(AFAIK) 이 아티팩트는 Windows에서 사용할 수 없습니다.

### client and server modes
서버가 바이너리를 실행하여(일부 플래그 및 구성 포함 또는 미포함) 로컬에서 실행될 수 있다면, `-c`로 명령줄을 전달하고 시작, 퍼징, 종료가 각 반복마다 새롭게 실행됩니다. 여기서 아이디어는 속도를 희생하여 대상의 메모리가 '특정 상태'에 있을 때만 트리거되는 성가신 버그를 피하는 능력을 얻는 것입니다. 이는 위양성(false positive)으로 이어질 수 있습니다. 로컬 네트워크 클라이언트 퍼징도 마찬가지입니다. 또한 TLS 연결을 지원하며, 인증서를 즉석에서 생성합니다(사용자가 필요한 서버를 퍼징할 때 클라이언트 인증서를 제공하거나 인증서 자체를 퍼징하는 것도 다른 아이디어입니다).

Litefuzz는 원격 클라이언트와 서버를 퍼징할 때 디버깅 지원을 제공하지 않으므로, 원격 측 설정은 사용자에게 달려 있습니다. 서버의 경우 단순히 서버가 응답을 중단했는지 확인하고 이전 페이로드를 크래셔(crasher)로 기록합니다. 이는 TCP 연결에서는 잘 작동하지만 UDP 서비스에서는 이러한 이점이 없으므로 원격 서버 모니터링은 ReportCrash 기능(Mac에서 사용 가능), 대상 디버거에서 실행(로컬 서버 모드 또는 수동으로) 또는 특정 대상에 맞게 작성된 맞춤 지원 스크립트를 통해 이루어집니다. 또한 일부 서버는 충돌 후 자동으로 다시 시작되거나 복구될 수 있지만, 로그나 파일 시스템의 다른 아티팩트에서 그 증거를 찾을 수 있으며, 이는 특정 대상에 대해 작성된 지원 스크립트로 파싱할 수 있습니다.

### local network examples

`litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z`

(Wireshark를 열고 응답을 캡처한 후, 
d, 오른쪽 클릭 Simple Network Management Protocol -> Export Packet Bytes -> resp.bin)

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z`

`litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z`

**quick notes**
- UDP 소켓은 Mac + Py2에서 약간 이상하게 동작할 수 있으므로 Mac + Py3만 테스트 및 지원됩니다.
- Windows에서 로컬 네트워크 클라이언트 퍼징은 버그가 있을 수 있으며 현재 실험적 기능으로 간주되어야 합니다.

### remote network examples

원격 클라이언트와 서버를 퍼징하는 것은 조금 더 까다롭습니다. 로컬 디버깅이 없고 네트워크를 통한 두 당사자 간의 상호 작용 중단을 감지하여 충돌을 포착해야 합니다. 또한 반대쪽에서 무슨 일이 일어나고 있는지 알 수 없으므로, 클라이언트나 서버가 응답을 중단하면 퍼징이 종료되며, 사용자가 원격 측에서 이 프로세스를 관리하는 스크립트를 설정하지 않은 경우 클라이언트나 서버가 정상(충돌하지 않은) 상태로 복원된 후 수동으로 다시 시작해야 합니다.

UDP는 이를 더욱 복잡하게 만듭니다. UDP 포트에서 수신 중인 서비스가 있는지 확인하기 위해 테스트 패킷을 보내더라도 응답이 보장되지는 않습니다. 따라서 원격으로 네트워크 클라이언트와 서버를 퍼징하는 것은 가능하지만 가시성에 대한 트레이드오프가 있습니다.

#### client

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100`

클라이언트 모드는 여기서 더 까다롭습니다. 클라이언트가 실제로 충돌하여 재연결되지 않는 것인지, 아니면 send/recv 동작이 맞지 않는 것인지 판단하기 어렵기 때문입니다. 각 클라이언트는 연결을 원하는 대로 처리할 수 있습니다. 또한 이는 단지 예시일 뿐이며, 원격 클라이언트 퍼징은 본질적으로 까다롭고 다소 실험적으로 간주되어야 합니다.

#### server

로컬 또는 원격으로 서버를 퍼징할 때의 장단점은 두 옵션을 모두 사용할 수 있을 때 대상을 어떻게 접근할지 결정하는 데 도움이 될 수 있습니다.

기본적으로 디버거에서 서버를 퍼징하는 것은 느리지만 자동 분류를 통해 충돌 로그를 얻을 수 있습니다. 반면에 원격 모드(로컬호스트를 가리키는 경우라도)로 서버를 퍼징하는 것은 평균적으로 훨씬 빠르지만 높은 가시성과 디버거 기반 분류 기능을 잃게 됩니다. 그러나 각 충돌 후 서버가 종료되기 전에 수동으로 다시 시작할 시간을 제공합니다(TCP 서버만 해당, UDP 기반 서버는 지원되지 않습니다).

**Shoutcast**

`./sc_serv ...`

`litefuzz -s -a localhost:8000 -i input/shouts -n 10000`

**SSHesame**

`sshesame`

`litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05`

**FTP**

`litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000`

**DNS**

`coredns -dns.port 10000`

`litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

or

`litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

##### TLS

`litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000````
...
@ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining)

[!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

각 패킷은 배열로 소비되며, 무작위 인덱스가 변형되어 대상에 재전송되어 퍼징됩니다.

`litefuzz -lk -c "ssh -T test@localhost -p 2222" -a tcp://localhost:2222 -i input/ssh -o crashes/ssh -p -n 250000 -z glibc`

그리고 최신 반복에 대한 대상의 출력을 확인할 수 있습니다.```
cat /tmp/litefuzz/out
kex_input_kexinit: discard proposal: string is too large
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: string is too large

... and others like

ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: unknown or unsupported key type

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Host key verification failed.

Bad packet length 1869636974.
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect

퍼저는 각 줄을 자체 FTP 응답으로 분할하여 클라이언트의 세션 처리 방식을 퍼징합니다. 하지만 클라이언트가 "예의 바르게" 행동하거나 세션이 제대로 완료되지 않는 방식으로 동작하지 않을 수도 있으므로, Wireshark를 실행하면서 세션 테스트 케이스를 약간의 시행착오와 미세 조정을 통해 대상 간 상호작용의 차이를 이해하는 것이 도움이 될 수 있습니다.

`litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z`

이는 FileZilla와 같은 GUI 네트워크 대상을 격리하기 위해 *-u*와 결합할 수도 있습니다.

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc`

### 프로세스에 연결하기
대상이 연결 시 새 프로세스를 생성하는 경우, 서버에 연결이 설정된 후 연결할 프로세스의 이름(또는 pid)을 지정할 수 있습니다. 이는 예를 들어 launchd가 포트에서 수신 대기 중이고 클라이언트가 연결된 후에만 처리 프로세스를 시작하는 경우에 유용합니다. 이 기능은 로컬 퍼징과 원격 퍼징의 경계를 다소 모호하게 만듭니다. 기술적으로 퍼저는 원격 모드이지만 대상 주소를 localhost로 지정하고 프로세스에 연결하도록 요청하기 때문입니다.

`./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000`

참고: 현재 이 기능은 Mac(LLDB)과 네트워크 퍼징에서만 지원되지만, 구현된다면 Linux(GDB)에서도 잘 작동할 것입니다.

### 충돌 아티팩트
퍼징 도중 충돌이 발생하면 디버거에서 재생되어 디버그 아티팩트와 버킷 정보가 생성됩니다. 정보는 플랫폼에 따라 다르지만, 일반적으로 백트레이스, 레지스터 정보, `!exploitable` 유형 정보(사용 가능한 경우) 및 기타 기본 정보가 포함된 텍스트 파일이 생성됩니다.

**메모리 덤프**는 `--memdump`를 전달하여 Windows에서 활성화하거나 `--nomemdump`로 비활성화할 수 있습니다. 이는 `-z`와 `-zz`를 통해 malloc 디버거를 제어하는 방식과 유사합니다. 활성화된 경우 덤프는 콘솔 디버거(cdbg)에도 로드되며, `!analyze -v` 충돌 분석 출력이 추가 메모리 덤프 충돌 분석 로그에 캡처됩니다. Winappdbg에는 이미 초기 충돌 분석에서 얻을 수 있는 !exploitable 유형 분석이 있으므로, 여기서는 !analyze만 수행합니다.

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump`

또는 응용 프로그램에 대해 메모리 덤프를 비활성화하려면

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump`

자동 충돌 분류 외에도 바이너리/문자열 diff(적절한 경우)와 대상 stdout(플랫폼/대상에 따라 다름)도 생성되며, 물론 재현 파일도 함께 생성됩니다.

로컬 퍼징의 경우 아티팩트에는 일반적으로 diff, stdout(linux/mac 전용), 재현 파일, 충돌 로그 및 정보 파일이 포함됩니다.```
$ ls crashes/latex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

원격 퍼징의 경우 선택한 옵션에 따라 아티팩트가 다를 수 있지만, 종종 다음이 포함됩니다: diff, 재현 파일 및/또는 재현 파일 디렉터리(입력이 여러 패킷이 있는 세션인 경우), 이전 퍼징 반복 재현(원격 퍼징의 특성상 실제 크래셔일 때 버그를 잃지 않도록 방지), 크래시 로그 또는 간략한 정보 파일.```
ls crashes/serverd
REMOTE_SERVER_testbox.1_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_PREV_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diff
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diffs
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.txt
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.zz

ls crashes/serverd/REMOTE_SERVER_localhost_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_1.zz	REMOTE_SERVER_localhost_NNNN_2.zz
REMOTE_SERVER_testbox.1_NNNN_3.zz	REMOTE_SERVER_localhost_NNNN_4.zz

축소된 버전을 확인해 보세요.```
GET /admin.cgi?mode=debug&option=a
Authorization:s YWRtaW46Y2hhbmdlbWU
Referer:admin.cgi

**최소화 예제**

`litefuzz -l -c "latex2rtf FUZZ" -m test.tex -z`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a "tcp://localhost:8000" -m repro.http`

**supermin 예제**```
litefuzz -l -c "latex2rtf FUZZ" -mm crashes/latex2rtf/test.tex -z
...
[+] starting minimization

@ 582/582 (1 new crashes, 1145 -> 582 bytes, ~0:00:00 remaining)  

[+] reduced crash @ pc=55555556c141 -> pc=55555557c57d to 582 bytes

[+] supermin activated, continuing...

@ 299/299 (1 new crashes, 582 -> 300 bytes, ~0:00:00 remaining)

[+] reduced crash @ pc=55555557c57d to 300 bytes
...
[+] reduced crash @ pc=555555562170 to 17 bytes

@ 17/17 (2 new crashes, 17 -> 17 bytes, ~0:00:00 remaining)

[+] achieved maximum minimization @ 17 bytes (test.min.tex)

[RESULTS]
completed (17) iterations with 2 new crashes found

#### Ubuntu에서 파일 핸들러 열거```
$ cat /usr/share/applications/defaults.list
[Default Applications]
application/csv=libreoffice-calc.desktop
application/excel=libreoffice-calc.desktop
application/msexcel=libreoffice-calc.desktop
application/msword=libreoffice-writer.desktop
application/ogg=rhythmbox.desktop
application/oxps=org.gnome.Evince.desktop
application/postscript=org.gnome.Evince.desktop
....

**fuzz gpg 복호화 (stdin 입력, 힙 오류 검사 포함)** (Mac)

`litefuzz -l -c "gpg --decrypt" -i test-gpg -o crashes-gpg -z`

**fuzz Books 앱** (Mac GUI)

`litefuzz -l -c "/System/Applications/Books.app/Contents/MacOS/Books FUZZ" -i test-epub -t "/Users/test/Library/Containers/com.apple.iBooksX/Data" -x 8 -n 100000 -z`

참고: `-z`는 미묘한 힙 손상 버그를 탐지하기 위해 [Guard Malloc](https://www.manpagez.com/man/3/libgmalloc/) 힙 오류 검사를 활성화합니다.

**mac 참고 사항**

일부 GUI 대상은 각 반복의 타임아웃 후에 종료되지 못하고 응답하지 않게 될 수 있습니다. 이를 완화하려면 다른 터미널에서 다음과 같은 스크립트를 실행하여 주기적으로 배치 종료함으로써 수동 작업과 모니터링을 줄일 수 있습니다. 그렇지 않으면 퍼징 프로세스에 영향을 줄 수 있습니다.```
#!/bin/bash
ps -Af | grep -ie "$1" | awk '{print $2}' | xargs kill -9

*/Users/test* (로컬 GUI 앱에 임시 파일이 전달되는 경로의 첫 부분에 대한 예시로, 실행 중 FUZZ가 경로가 됩니다)는 프로세스를 종료하기 위해 고유한 문자열이 필요하고, 프로세스 이름만 사용하면 퍼징 프로세스 자체에도 프로세스 이름이 포함되어 있어 퍼징 프로세스까지 종료되기 때문에 선택되었습니다.

**Windows에서 파일 핸들러 열거**

[AssocQueryString](https://github.com/sec-tools/WindowsFileHandlerEnumeration/) 스크립트를 *assoc* 명령어와 함께 사용하면 파일 확장자를 기본 애플리케이션에 매핑할 수 있습니다.```
C:\> .\AssocQueryString.ps1
...
.hlp :: C:\Windows\winhlp32.exe
.hta :: C:\Windows\SysWOW64\mshta.exe
.htm :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.html :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.icc :: C:\Windows\system32\colorcpl.exe
.icm :: C:\Windows\system32\colorcpl.exe
.imesx :: C:\Windows\system32\IME\SHARED\imesearch.exe
.img :: C:\Windows\Explorer.exe
.inf :: C:\Windows\system32\NOTEPAD.EXE
.ini :: C:\Windows\system32\NOTEPAD.EXE
.iso :: C:\Windows\Explorer.exe

#### 로컬 클라이언트

**로컬호스트(Linux)에서 SNMP 클라이언트 퍼징**

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

#### 원격 클라이언트

**원격 FTP 클라이언트(Linux) 퍼징**

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -n 100`

참고: 대상에 따라 클라이언트 퍼징을 위해 권한 있는 포트(1-1024)에서 수신 대기가 필요할 수 있습니다. 이 경우 Linux에서는 Python 인터프리터에 `setcap cap_net_bind_service=+ep`를 설정하거나 퍼저 실행 시 sudo를 사용할 수 있고, Mac에서는 sudo를 사용하면 되며, Windows에서는 퍼저를 관리자로 실행하면 Permission Denied 오류를 피할 수 있습니다.

### 서버

#### 빠른 보기```
litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -i input/shoutcast -o crashes/shoutcast -n 1000 -z
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id:     4001
cmdline:    ./sc_serv shoutcast.conf
address:    tcp://localhost:8000
crash dir:  crashes/shoutcast
input dir:  input/shoutcast
inputs:     3
iterations: 1000
mutator:    random(mutators)

@ 1000/1000 (1 crashes, 7 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (1000) iterations with (1) unique crashes and 7 dups
>> check crashes/shoutcast for more details

# trophies

Litefuzz는 다음과 같은 다양한 소프트웨어 패키지에서 크래시를 발견했습니다.

* antiword
* AppleScript (OS X)
* ArangoDB VelocyPack
* Avast authenticode-parser
* Avast RetDec
* BBC Audio Waveform
* ColorSync (OS X)
* Dynamsoft BarcodeReader
* eot2ttf
* evernote2md
* faad2
* Facebook의 Origami Studio
* FontForge
* ForestDB
* Gifsicle
* GPUJPEG
* GPAC Multimedia Framework
* Google Draco
* Google Quipper
* GoPro GPR
* GtkRadiant
* IIPImage Server
* John The Ripper
* Kyoto Cabinet
* latex2rtf
* libMeshb
* libembroidery
* libsndfile
* Lion Vector Graphics (lvg)
* L-SMASH
* mp3-decoder
* MindNode
* minimp4
* MiniWeb Server
* MLpack
* Nvidia Data Center GPU Manager
* Numbers (OS X)
* OpenJPEG
* OpenOrienteering Mapper
* OSM Express
* Pages (OS X)
* PBRT-Parser
* Pixar USD
* Remote Apple Events (OS X)
* Samsung rlottie
* Samsung ThorVG
* Shoutcast Server
* Silo
* syslog (OS X)
* Tencent NCNN
* TinyXML2
* UEFITool
* Ulfius Web Framework
* zlib

# FAQ

## 이 프로젝트는 어떻게 시작되었나요?
퍼징은 재미있습니다! 그리고 퍼저가 항상 최신 또는 인기 있는 접근 방식을 따라야만 버그를 찾을 수 있다는 것은 아니라는 반항적인 관점을 가진 프로젝트를 하는 것도 좋습니다. 베어메탈에 가깝든, 모든 경로에서 코드 커버리지를 얻든, 또는 단순히 빠르고 유연하게 최적화하든, 근본적으로 "가정을 무효화"하는 방식으로 일을 수행하든, 어떻게 나타나든 즐기세요.

## 이 프로젝트는 적극적으로 유지 관리되나요?
프로젝트에 대한 적극적인 지원이나 유지 관리를 기대하지 마십시오. 새 기능을 추가하거나 버그를 수정하려면 자유롭게 포크하세요. 사소한 부분은 PR을 보낼 수도 있지만 응답이나 문제 해결에 대한 기대는 하지 마십시오. 이 리포지토리에서의 개발이 활발할 의도는 없습니다.

## 퍼저가 잘 작동하는지 어떻게 알 수 있으며, 다른 퍼저와 비교 측정했나요?
Litefuzz의 목적은 여러 플랫폼에서 버그를 찾는 것입니다. 그리고 실제로 그렇게 합니다. 따라서 솔직히 말해서 fuzzerX나 fuzzerY와 비교 측정하는 것은 우선순위에서 밀렸습니다. 특정 절충점이 처음부터 결정되고 인정되었으며, 자세한 내용은 [#intro](https://github.com/sec-tools/litefuzz/blob/HEAD/README.md#intro)를 참조하세요.

## 오늘 다시 작성한다면 무엇을 바꾸겠습니까?
현재 상태로도 꽤 잘 작동하며 수많은 다양한 대상과 시나리오에서 테스트되었습니다. 그렇긴 하지만, 대상과 플랫폼 간 전환 시 코드의 운영 측면에서 추가 검사가 많이 필요하지 않도록 보다 모듈 기반의 플러그인 시스템을 표준화하는 것이 도움이 될 것입니다. 물론 공식적인 테스트와 지원 OS에서 테스트할 수 있는 배포 시스템이 있으면 핵심 기능을 변경할 때 작업하기 쉬운 환경이 조성될 것입니다. 작지만 야심찬 프로젝트에서 꽤 빠르게 조금 더 큰 규모로 성장했습니다.

## litefuzz는 얼마나 안정적인가요?
명령줄, GUI, 네트워크 퍼징(주로 Linux 및 Mac), 최소화 등은 상당히 철저하게 테스트되었으며 전반적으로 꽤 안정적일 것입니다. 절연된 네트워크 GUI 퍼징, Mac용 ReportCrash 지원 등과 같은 일부 이국적인 기능은 실험적인 것으로 간주해야 합니다.

## litefuzz에서 지원되지 않는 시나리오가 있나요?
네, 몇 가지 있습니다. 하지만 대부분은 드문 시나리오로 버그가 있거나, "제대로" 구현하기 위해 더 많은 시간과 연구가 필요하거나, 플랫폼 관련 이유로 제대로 작동하지 않습니다. 그 중 많은 경우 해당 옵션으로 실행하려고 하면 명시적으로 "지원되지 않음" 메시지와 함께 종료되며, 다양한 기능을 설명할 때 위 섹션에서 몇 가지 주의 사항이 언급되었습니다. 더 세부적인 사항 중 일부는 *절연* 앱의 재현 모드가 지원되지 않으며, 절연 기능을 사용하는 Mac 앱에 대한 테스트가 제한적이라는 점, Pyautogui는 Linux와 Windows에서 잘 작동하는 것 같지만 Mac에서는 신뢰할 수 없어 기능적으로 지원되지 않는 것으로 간주한다는 점, Windows에서의 클라이언트 퍼징은 다른 플랫폼의 다른 모드보다 약간 덜 안정적일 수 있다는 점 등이 있습니다.

여기저기 몇 가지 엣지 케이스가 있을 수 있지만, 가장 일반적인 로컬 및 네트워크 퍼징 시나리오는 테스트되었고 작동 중입니다. 아, 이것이 크로스 플랫폼 도구를 작성하는 즐거움입니다: 보람되지만 항상 모든 것을 완벽하게 작동하게 만드는 것은 어렵습니다. 전반적으로 Linux/Mac에서의 퍼징이 더 안정적이고 더 많은 기능을 지원하는 것으로 보이며, 특히 Windows 플랫폼보다 네트워크 퍼징 테스트가 훨씬 많이 이루어졌지만 Win32에서 최소한의 기본 기능과 몇 가지 추가 기능을 사용할 수 있도록 노력했습니다.

이 퍼저를 포크하여 개선하거나 현재 지원되지 않는 기능을 지원하거나, 사소하지만 유용한 것에 대한 PR을 자유롭게 보내십시오.

## 이 프로젝트 또는 그 코드에 대해 어떤 보장이 제공되나요?
전혀 없습니다. 하지만 퍼징하면서 버그를 찾는 것은 꽤 재미있습니다.

## 작성자 / 참고 자료
- [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/HEAD/jbrown3264%5BNOSPAM%5Dgmail)
- [macOS 퍼징용 슬라이드 데크](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)