Missing documentation how to reproduce faults about eclipser

[jchoi2022]

• As stated in https://github.com/SoftSec-KAIST/Eclipser#usage, fuzzing results will be saved in <sync dir>/*/queue/ and <sync dir>/*/crashes/. You can retrieve the test cases in crashes/ and run them on the target program to reproduce the crashes.

• I'm not sure what you mean by parse the bytes to tell user which are the inputs that made the program crash. Are you interested in which part (i.e. specific offset) of the input is actually related to the found bugs? Such analysis is out of fuzzing's scope. Please take a look at dynamic taint analysis tools and papers for such functionality.

[francescoschembri]

Yes, I read that part but it's not 100% clear how can i run the crashses or the testcases with my program.
I implemented the example in the paper with an abort and I find it and it is stored in crashes. How can I read which is the input? How do I open the fuzzing results stored in queue and crashes?

[francescoschembri]

To be clearer.

I implemented the example in a C program called fault.c and compiled it in fault.bin. I launch Eclipser on it and it finds the crash (implemented with abort()).

If i run ./fault.bin box/output/crashes/id\:000000 the only thing i get is Aborted (core dumped). So I understand that there is a problem but I don't get any useful information like: which is the input that made my program crash? Which is the path followed with that input that lead to an abort?

[neuromancer]

Hi @francescoschembri. AFAIK, Eclipser is tool that could give you a crash, but it cannot show you the program path or minimize the input to know we exactly which bytes are important. If you want to understand how and why you program crashed, you should use a debugger such as gdb. You can take a look to a tutorial for debugging a crash here.

[jchoi2022]

• Each file in crashes/ directory is a test case by itself, so running it like ./fault.bin box/output/crashes/id\:000000 as you did is correct. In other words, the content of box/output/crashes/id\:000000 is the exact input that makes the program crashes.
• If you want to obtain more detailed information about the crash (e.g. 'the path of crashing execution' or 'which offset of the input led to the execution of that path'), such analysis is not the role of a fuzzer, as neuromancer has pointed out. One can implement such functionality with program instrumentation or dynamic taint analysis tools, so please take a look at such tools. Of course, a debugger is a good option, too.

[francescoschembri]

Ok so it's a decision to focus just on the fuzzing and not also on the other stuffs. Thanks for the clarification.