AFLplusplus / AFLplusplus/LibAFL

Improvement on Intel-PT-based fuzzing capabilities

Offen
#3,724 7 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
Vorherrschende Sprache
Rust
Sterne
2.6k
Forks
481
Ø Merge
2 T. 30 Min.
Gemergte PRs (30 T.)
16

Beschreibung

I noticed that LibAFL has been integrating the Intel-PT-based fuzzing capabilities using the [ptcov](https://crates.io/crates/ptcov) crate. I have also implemented a full-featured Intel-PT decoder [iptr](https://github.com/Evian-Zhang/iptr) using pure Rust with more idiomatic APIs in both low-level and bitmap-level APIs.

Evaluated on the famous [`libxdc_experiments`](https://github.com/nyx-fuzz/libxdc_experiments) benchmark, it turns out that iptr has comparable performance with libxdc, the fastest Intel PT decoder written in C, with each target completed in 5-10 seconds. However, ptcov cannot run most of the targets (possible due to the approach that I build up `PtImage` since libxdc dumps memory in page level instead of image level, leading to some instructions split into two pages), while some targets cannot complete in even 18 hours... I guess the reason for the low performance is that ptcov does not use TNT cache to accelerate the bitmap update.

I also managed to integrate iptr into LibAFL, creating a fuzzer with the same functionality with [`intel_pt_command_executor`](https://github.com/AFLplusplus/LibAFL/tree/main/fuzzers/binary_only/intel_pt_command_executor). Due to the fact that the target program is very small, the performance improvement is not as large as what we see in `libxdc_experiments`. Anyway, it can still discover the vulnerabilities as ptcov does, proving the full functionalities.

I wonder whether the LibAFL team is willing to accept iptr as an alternative Intel PT decoder. I can think of four feasible approaches:

1. iptr as an alternative with independent sub-crate like [`libafl_intelpt`](https://github.com/AFLplusplus/LibAFL/tree/main/crates/libafl_intelpt)
2. iptr and ptcov being two configurable backend features in [`libafl_intelpt`](https://github.com/AFLplusplus/LibAFL/tree/main/crates/libafl_intelpt)

However, I found that the logics and APIs are highly coupled with ptcov in both [`libafl_intelpt`](https://github.com/AFLplusplus/LibAFL/tree/main/crates/libafl_intelpt) and the [Intel PT executor hook](https://github.com/AFLplusplus/LibAFL/blob/main/crates/libafl/src/executors/hooks/intel_pt.rs), with some ptcov-related structs exposed in public APIs.

If we want to use features to select these two backends, some refactor works still need to be done.
3. Rewrite ptcov using iptr
4. Directly use iptr to replace ptcov.

I'm willing to assist in any of the above approaches. Which approach do you prefer? :)

cc @Marcondiro @domenukk

Beitragsleitfaden

Beitragsleitfaden öffnen

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.