Closed andreafioraldi closed 2 years ago
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 https://github.com/AFLplusplus/LibAFL/blob/9d669bbc6372b05cf23dd46a6376871b53650ceb/libafl_frida/src/helper.rs#L147
Sounds good. I just have to find time to actually do it!
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 is done, right? cc @s1341
Yes.
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
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