Refactor libafl_frida

[andreafioraldi]

IMO we should generalize a bit the code for frida.
For sure, it's time to move the Executor from the example to the lib https://github.com/AFLplusplus/LibAFL/blob/main/fuzzers/frida_libpng/src/fuzzer.rs#L61
Then, I think we should split the FridaInstrumentationHelper. Instead of having flags like cmplog_enabled atc. we should offer the option to stack different helpers into one (like we do for Feedback for instance), so then the user can for instance use CmpLog mixing FridaEdgeCoverageHelper with FridaCmpLogHelper and even write its own helper

[andreafioraldi]

In additions, there are some buggy patterns like https://github.com/AFLplusplus/LibAFL/blob/main/libafl_frida/src/helper.rs#L147
Here the unpoison works well for BytesInput, but fails target_bytes return an owned vector, the slice address will be on stack and different from the one used in the harness. Still, I don't have a solution in mind right now, but better to note this problem here.

edit (toka):
permalink

LibAFL/libafl_frida/src/helper.rs

Line 147 in 9d669bb

let target_bytes = input.target_bytes();

[s1341]

Sounds good. I just have to find time to actually do it!

[andreafioraldi]

We have to add too some code to run binaries not just shared objects. Should be easy, just hook libc start main, compile the fuzzer as a shared object and inject into the target with LD_PRELOAD.

[domenukk]

This is done, right? cc @s1341

[s1341]

Yes.

[tokatoka]

We have to add too some code to run binaries not just shared objects. Should be easy, just hook libc start main, compile the fuzzer as a shared object and inject into the target with LD_PRELOAD.

This part is not done yet.
but well, I'll open another issue then