Closed vanhauser-thc closed 3 years ago
Can you try again with:
cd docker/fuzzolic-runner
make build
?
We have a few submodules that need to be fetched. The Makefile is doing that when running the build
target.
P.s. now that the repos are public, we could just do it in the Dockerfile...
@ercoppa oops you are right, that fixes building for me. Another question the patch for af++'s afl-showmap, is that important? and does afl-showmap from vanilla afl work without a patch? I want to add fuzzolic to fuzzbench and compare to symcc and eclipser.
@ercoppa I choose to just use the afl-showmap etc. binaries that are in fuzzolic/utils.
I run the two following commands:
afl-fuzz -i /out/seeds -o /out/corpus -m none -t 1000+ -S afl-worker -- /out/fuzzer 2147483647
/out/fuzzolic/fuzzolic/fuzzolic.py -f -p -r -a /out/corpus/afl-worker -i /out/corpus/afl-worker/queue -o /out/corpus/fuzzolic_output -- /out/uninstrumented/fuzzer[
fuzzolic does not seem to like the setup though as I get:
Configuration file for /out/uninstrumented/fuzzer is missing. Using default configuration.
Waited 0.9 seconds for a new input from AFL
Running directory: /out/corpus/fuzzolic_output/fuzzolic-00000
Using Fuzzy-SAT solver
ERROR: tracer has returned code -6
Run took 0.2 secs
Running directory: /out/corpus/fuzzolic_output/fuzzolic-00001
Using Fuzzy-SAT solver
ERROR: tracer has returned code -6
Run took 0.3 secs
what is going wrong here?
-d tracer showed that LD_LIBRARY_PATH was wrong.
OK, now I am running into an issue I cannot solve:
/out/fuzzolic/fuzzolic/fuzzolic.py -d trace -f -p -r -a /out/corpus/afl-worker -i /out/corpus/afl-worker/queue -o /out/corpus/fuzzolic_output -- /out/uninstrumented/fuzzer
WARNING: in debug mode, only a single path is explored.
Configuration file for /out/uninstrumented/fuzzer is missing. Using default configuration.
Running directory: /out/corpus/fuzzolic_output/fuzzolic-00000
Using Fuzzy-SAT solver
Loading testcase: /out/corpus/fuzzolic_output/.cur_input
Loaded 3 bytes from testcase: /out/corpus/fuzzolic_output/.cur_input
[testcase-lib] Loading testcase "/out/corpus/fuzzolic_output/.cur_input"
[SOLVER] Creating shared memory #1 (key=913189430)...
[SOLVER] Creating shared memory #2 (key=2447953390)...
[SOLVER] Attached to shared memories...
[SOLVER] Invalid bitmap /out/corpus/fuzzolic_output/branch_bitmap. Resetting it.
[SOLVER] Bitmap /out/corpus/fuzzolic_output/context_bitmap does not exist. Initializing it (65536).
qemu-x86_64: /out/fuzzolic/tracer/tcg/symbolic/symbolic.c:437: void load_configuration(void): Assertion `s_config.inputfile && "Neet to specify testcase path."' failed.
[SOLVER] Waiting for the tracer...
ERROR: tracer has returned code -6
Another question the patch for af++'s afl-showmap, is that important? and does afl-showmap from vanilla afl work without a patch?
Vanilla afl-showmap should work but fuzzolic may then discard a crashing input whenever the crashing input is not increasing the coverage/hit counts. Our patch makes afl-showmap to add ".crash" to the name of the bitmap (generated by afl-showmap) for an input if there was a crash during the program execution.
I want to add fuzzolic to fuzzbench and compare to symcc and eclipser.
That would be great. It could be interesting to try it with Z3 and with Fuzzy-SAT (--fuzzy
). Also, I suggest enabling optimistic solving (--optimistic-solving
), address reasoning (--address-reasoning
), and the libc models (--symbolic-models
). Also you should set a timeout on solving time (--timeout 90000
).
fuzzolic does not seem to like the setup though as I get:
1) Ignore the warning about the configuration file.
2) I see in your command /out/uninstrumented/fuzzer[
: is the [
at the end correct?
3) I see that on the instrumented binary you are passing an argument (2147483647
). Should you pass the same to fuzzolic?
4) Can you share the binary and the inputs?
I want to add fuzzolic to fuzzbench and compare to symcc and eclipser.
That would be great. It could be interesting to try it with Z3 and with Fuzzy-SAT (
--fuzzy
). Also, I suggest enabling optimistic solving (--optimistic-solving
), address reasoning (--address-reasoning
), and the libc models (--symbolic-models
). Also you should set a timeout on solving time (--timeout 90000
).
ok, no problem, will add the options and put two variants on fuzzbench to have both solvers covered.
fuzzolic does not seem to like the setup though as I get:
2. I see in your command `/out/uninstrumented/fuzzer[`: is the `[` at the end correct?
that was just a copy-paste error. I guess the fuzzer would not start if the filename is wrong.
3. I see that on the instrumented binary you are passing an argument (`2147483647`). Should you pass the same to fuzzolic?
the argument is optional. I added it to be the same, still same error
4. Can you share the binary and the inputs?
sure attached. it is re2. re2.zip
Note that I give an instrumented binary to afl-fuzz and an uninstrumented binary to fuzzolic. to me this should work without issues right?
ok, no problem, will add the options and put two variants on fuzzbench to have both solvers covered.
Great, thanks.
sure attached. it is re2.
Thank you, I will try to debug it in the next hours.
Note that I give an instrumented binary to afl-fuzz and an uninstrumented binary to fuzzolic. to me this should work without issues right?
Yes, it should be fine.
hmm from the code it looks like SYMBOLIC_INJECT_INPUT_MODE is set with FROM_FILE, however the input is coming with stdin so it would need to be READ_FD_0
I set config['SYMBOLIC_INJECT_INPUT_MODE'] = "READ_FD_0"
in fuzzolic/fuzzolic/executor.py and this works now.
but qemu seems to crash:
----------------
IN:
0x40013ae42b: 48 63 d7 movslq %edi, %rdx
0x40013ae42e: b8 ea 00 00 00 movl $0xea, %eax
0x40013ae433: 48 63 f9 movslq %ecx, %rdi
0x40013ae436: 0f 05 syscall
OP:
ld_i32 tmp11,env,$0xfffffffffffffff8
movi_i32 tmp12,$0x0
brcond_i32 tmp11,tmp12,lt,$L0
---- 00000040013ae42b 0000000000000000
mov_i64 tmp0,rdi
ext32s_i64 tmp0,tmp0
mov_i64 rdx,tmp0
---- 00000040013ae42e 0000000000000000
movi_i64 tmp0,$0xea
ext32u_i64 rax,tmp0
---- 00000040013ae433 0000000000000000
mov_i64 tmp0,rcx
ext32s_i64 tmp0,tmp0
mov_i64 rdi,tmp0
---- 00000040013ae436 0000000000000000
movi_i64 tmp3,$0x40013ae436
st_i64 tmp3,env,$0x80
movi_i32 tmp11,$0x2
call syscall,$0x0,$0,env,tmp11
call rechecking_single_step,$0x0,$0,env
exit_tb $0x0
set_label $L0
exit_tb $0x55f3de97c483
qemu: uncaught target signal 6 (Aborted) - core dumped
ERROR: tracer has returned code -6
When running the uninstrumented program, it seems that is expecting a command line argument (path to the input). If this is the case then:
../fuzzolic/utils/AFLplusplus/afl-fuzz -i seeds -o out -m none -t 1000+ -S afl-worker -- ./fuzzer
and then:
../fuzzolic/fuzzolic/fuzzolic.py -i out/afl-worker/queue/ -f -p -r -i seeds/ -o out/fuzzolic -- uninstrumented/fuzzer @@
hmm from the code it looks like SYMBOLIC_INJECT_INPUT_MODE is set with FROM_FILE, however the input is coming with stdin so it would need to be READ_FD_0
Are you sure this is the case for the uninstrumented binary?
$ echo "AAAA" | ./uninstrumented/fuzzer
StandaloneFuzzTargetMain: running 0 inputs
while:
$ ./uninstrumented/fuzzer seeds/test.dat
StandaloneFuzzTargetMain: running 1 inputs
Running: seeds/test.dat
Done: seeds/test.dat: (5 bytes)
hmm from the code it looks like SYMBOLIC_INJECT_INPUT_MODE is set with FROM_FILE, however the input is coming with stdin so it would need to be READ_FD_0
Let me check if reading from stdin is broken (we mostly used programs reading from file; our debug tests read from stdin but we define a configuration file for them). However, check my previous comment.
you are right. that wrapper for uninstrumented was not mine, and I hadnt thought that it would be inefficiently implemented ... sorry.
works now:
Running directory: /out/corpus/fuzzolic_output/fuzzolic-00007
Using Fuzzy-SAT solver
[-] Discarding test_case_10_0.dat
[-] Discarding test_case_5_0.dat
[-] Discarding test_case_4_0.dat
[-] Discarding test_case_3_0.dat
[-] Discarding test_case_6_0.dat
[-] Discarding test_case_2_0.dat
Run took 0.8 secs
Good, I will still check if reading input from stdin works (without writing a conf file) since it could be an issue with other drivers.
when I fix the dockerfile for this issue I run into another one:
and this is not surprising as the directory solver/fuzzy-sat/fuzzolic-z3 is empty.