Created basics of AFL-SWAM interface #7
Conversation
fuzzer/README.md
Outdated
| Therefore, instead of using the C++-compiler provided by AFLplusplus (afl-clang-fast++), we use the "standard" g++ compiler and instead mimic the instrumentation behaviour in the interface. | ||
|
|
||
| AFL communicates with the target binary with a shared memory by default. Since Scala does not seem suitable for such low-level operations, we have instead created a low-level wrapper for SWAM, interface.cpp. Whilst the code coverage plugin for SWAM writes it's results to a fixed file, our interface wrapper reads from this file and then feeds the content into the shared memory used by AFL. | ||
|
|
There was a problem hiding this comment.
Good work! Could you add a little more of context? How does this work as a general picture? Maybe a summary about kelinci. WHat about this URL https://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html in the C code?
There was a problem hiding this comment.
I've added another commit, which actually makes it work in the way I had in mind. The interface is now however feeding dummy coverage data to AFL. As a next step I will try to integrate this with SWAM and then try to feed the code coverage from Tarek's work into AFL.
If those steps are validated, I will start being more concise in the README. Hope that's ok!
…Function & executeFunction. Created first basic Server file.
…xed anymore; Fixed measure time; Parsing received socket message to byte array.
…wat and cli.run_server.
…es; use runClient();
…t mill compilation step in Dockerfile.
|
Hey @Jacarte, the program seems to work overall now. There are still some irregularities concerning the Socket connection, which I can look into. But I've updated the README and you should be able to run it quite easily on your machine. I can merge this to master on my repo and forward this to the others via email if you want to! |
|
|
||
| // TODO: Read port from env-variable SWAM_SOCKET_PORT | ||
| object Server { | ||
| val maxQueue = 50000 |
There was a problem hiding this comment.
This looks really interesting. Just a thing: I'd like to keep Swam pure and functional. Can you try to implement the server using fs2-io? See https://fs2.io/io.html
If you are not used to this kind of programming I can do it for you, but I'd really love to have this before merging upstream.
There was a problem hiding this comment.
Yeah, I get that. I'll have a go at it..!
fuzzer/Dockerfile
Outdated
| @@ -0,0 +1,22 @@ | |||
| FROM aflplusplus/aflplusplus | |||
There was a problem hiding this comment.
Is docker really required to make coverage work?
There was a problem hiding this comment.
It's not meant to be required for coverage to work.
I think it's useful to have for fuzzing though, given the nature of fuzzing:
-
I'd prefer to have the fuzzer somehow containerized, given that I am testing all of this on my local machine and the AFLplusplus docs state "you shouldn't be fuzzing on systems where the prospect of data loss is not an acceptable risk". It might not make a difference though, I'm not sure.
-
Since fuzzing is meant to be run for a longer period of time "in production", i.e. probably on a server, I don't want to spend time on portability issues, especially since I am not developing on Linux.
As stated in the README files however, I've at least written a run_test.sh script to test the SWAM server without Docker.
And lastly, the entire docker-compose configuration is set up to work very easily, which I think it currently does. It will work without Docker though, if you install AFLplusplus manually and source the .env file first.
Nonetheless, you may want to check whether you're fine with the Dockerfile I put into the root of this repository.
fix: sensible default values
See fuzzer/README.md for details