A possible workflow for testing (networked) applications in S2E
could look like this:
1. Install the client and the server inside the same VM. S2E does not have access to the outside network so both the client and the server should run inside the same S2E instance. This makes it easier to ensure execution consistency.
2. Generate some workload to drive execution. S2E cannot guess on its own how to run your application.
3. Once single-path execution works properly (e.g., you get some basic coverage of your client), you can start with symbolic execution
4. Insert a few bytes of symbolic data at some boundary (e.g., read() system call). You don't necessarily need to worry about non-data syscalls like select(), unless you want to do fault injection.
5. See what new coverage you get, if there is path explosion, etc. You can use "s2e forkprofile" and "s2e coverage" for that.
6. When you get useful test cases from S2E, add them to your workload in 2, then repeat.
7. You should obtain the best results by combining fuzzing and symbolic execution in loop. Fuzz your app, take the test cases, feed them into S2E, which will then use them as a skeleton to find more test cases. Then use S2E's test cases as fuzzer input, and repeat.
You received this message because you are a member of the S2E Developer Forum.
To post to this group, send email to s2e...@googlegroups.com
To unsubscribe from this group, send email to s2e-dev+u...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/s2e-dev
You received this message because you are subscribed to the Google Groups "S2E Developer Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to s2e-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/s2e-dev/1c9fbf59-798a-4c6c-a3c0-681f65dde72bn%40googlegroups.com.