Skip to content
This repository has been archived by the owner on Aug 23, 2024. It is now read-only.

Issue with populate script and custom corpus generation #7

Open
turbolizer opened this issue Aug 28, 2020 · 20 comments
Open

Issue with populate script and custom corpus generation #7

turbolizer opened this issue Aug 28, 2020 · 20 comments

Comments

@turbolizer
Copy link

turbolizer commented Aug 28, 2020

Hi @thdusdl1219 thank you for open sourcing this fuzzer. I just was reading your published paper and wanted to run it on my local machine. I would have two questions:

  1. I was compiling my target engine with the provided afl-clang-fast version from /fuzz/afl. When running the populate script and attach with tmux attach -t corpus I see that I receive a long list of
Checking corpus: ./corpus/output-x/00xxxx-corpus.js
Checking corpus: ./corpus/output-x/00xxxx-corpus.js
Checking corpus: ./corpus/output-x/00xxxx-corpus.js
Checking corpus: ./corpus/output-x/00xxxx-corpus.js
Checking corpus: ./corpus/output-x/00xxxx-corpus.js

+++ Testing aborted by user +++

We're done here. Have a nice day

When taking a look at the output directory I don't see that a .cur_input file was created for each directory. As far I understood this is done by the afl-fuzz program. When connecting to the redis database I only see the following keys:

1) "fuzzers:fuzzer-ubuntu-d5787..."
2) "fuzzers:fuzzer-ubuntu-d5787..."
3) "fuzzers:fuzzer-ubuntu-d5787..."
4) "fuzzers"
5) "fuzzers:fuzzer-ubuntu-d5787..."
6) "fuzzers:fuzzer-ubuntu-d5787..."
7) "fuzzers:fuzzer-ubuntu-d5787..."
8) "fuzzers:fuzzer-ubuntu-d5787..."
9) "fuzzers:fuzzer-ubuntu-d5787..."
10) "fuzzers:fuzzer-ubuntu-d5787..."
11) "fuzzers:fuzzer-ubuntu-d5787..."
12) "fuzzers:fuzzer-ubuntu-d5787..."
13) "fuzzers:fuzzer-ubuntu-d5787..."

I don't see the mentioned keys like "crashBitmap", "crashQueue", "pathBitmap", newPathsQueue". What might cause that those keys are not generated? I already was reading the following issue but the comments also didn't help:
#2

@zr950624 was your issue solved?

  1. Same question as Instructions to use new corpus #6

Please let me know if you have any ideas for either or question. I would like to get the fuzzer running and create a pull request for potential required changes.

@turbolizer
Copy link
Author

I just retried it and now I have the same issue as #2. The program reports
Error: [-] file doesn't exist: output-11/.cur_input.js

@turbolizer turbolizer changed the title Testing aborted by user in populate script and custom corpus generation Issue with populate script and custom corpus generation Aug 28, 2020
@zr950624
Copy link

I just retried it and now I have the same issue as #2. The program reports
Error: [-] file doesn't exist: output-11/.cur_input.js

This problem was firstly addressed by add -C to perform crash mode while initializing the corpus(instrument by original AFL).
Further, I used the provided AFL to instrument the binary and it works well, so I think this problem might be caused by the afl-fuzz cannot catch the new bit while fuzzing. You may need to check your instrument or debug the save_if_insteresting function.

@turbolizer
Copy link
Author

turbolizer commented Aug 29, 2020

Thanks @zr950624 for your quick response! I try to add the -C flag if that helps in the population phase.

@thdusdl1219
Copy link
Member

I suggest compiling JS engines with the provided scripts in engine dir as we selectively instrument the binary (See engine/compiler/proxy.py). I pushed scripts for #6 so please check it.

@turbolizer
Copy link
Author

turbolizer commented Sep 1, 2020

Hi @thdusdl1219 thank you for your response! I was able to follow your steps and my populate.sh script seems to almost correctly initialized the corpus now. After executing the script I see the newPathsQueue and pathBitmap keys. However, I don't see the crashQueue and crashBitmap yet.

  1. When taking a closer look into the provided afl-fuzz.c file I see that …redis_ctrl.js insertCrash… will only be called when fault == FAULT_CRASH which would mean that a crash was detected? I guess it is ok then that crashQueue and crashBitmap is not visible then after executing the populate.sh script?

(I didn't use the -C flag since you mentioned in #2 that you also didn't use it.)

  1. When running the fuzzer I receive the following outputs. Do those look correct:
    tmux output:
[*] Get a next testcase
[*] Command: node ./fuzz/afl/../TS/redis_ctrl.js getNextTestcase output-11/.cur_input.js
[*] Generating testcases...
[*] Command: timeout 30 node ./fuzz/afl/../TS/esfuzz.js output-11/.cur_input.js output-11/fuzz_inputs 100 1467279467 > /dev/null
[*] Scanning 'output-11/fuzz_inputs'...
[*] Command: node ./fuzz/afl/../TS/redis_ctrl.js reportStatus fuzzer-$(hostname)-$(cat /etc/machine-id|cut -c 1-16)-3781934 output-11/fuzzer_stats
[*] Time - Generation: 101.00 ea/s, Execution: 13.47 ea/s

[*] Get a next testcase
[*] Command: node ./fuzz/afl/../TS/redis_ctrl.js getNextTestcase output-11/.cur_input.js
[*] Generating testcases...
[*] Command: timeout 30 node ./fuzz/afl/../TS/esfuzz.js output-11/.cur_input.js output-11/fuzz_inputs 100 1749688920 > /dev/null
[*] Scanning 'output-11/fuzz_inputs'...
[*] Time - Generation: 202.00 ea/s, Execution: 13.47 ea/s

Statistics output:

start_time        : 1598953267
last_update       : 1598953933
fuzzer_pid        : 3781934
cycles_done       : 0
execs_done        : 3667
execs_per_sec     : 6.37
paths_total       : 0
paths_favored     : 0
paths_found       : 0
paths_imported    : 0
max_depth         : 0
cur_path          : 36
pending_favs      : 0
pending_total     : 0
variable_paths    : 0
stability         : 100.00%
bitmap_cvg        : 27.41%
unique_crashes    : 0
unique_hangs      : 0
last_path         : 0
last_crash        : 0
last_hang         : 0
execs_since_crash : 3667
exec_timeout      : 1000
afl_banner        : d8
afl_version       : 2.52b
target_mode       : default
command_line      : ./fuzz/afl/afl-fuzz -m none -o output-11 ./engines/v8-latest/v8/out/Debug/d8 /home/turbolizer/die_fuzzer/DIE/corpus/lib.js /home/turbolizer/die_fuzzer/DIE/corpus/jsc.js /home/turbolizer/die_fuzzer/DIE/corpus/v8.js /home/turbolizer/die_fuzzer/DIE/corpus/ffx.js /home/turbolizer/die_fuzzer/DIE/corpus/chakra.js @@

@thdusdl1219
Copy link
Member

Yes. It looks working.

@turbolizer
Copy link
Author

Thank you for your response and work @thdusdl1219. I just was confused since the the newPathsQueue and pathBitmap keys haven't been in the database after initialization. The issue can be closed now.

@adrian-rt
Copy link

Hi all,

got a similar issue, I'm missing "newPathsQueue". all the other keys seem to be there. I've also added -C to afl-fuzz as was suggested here.

these are my redis keys:

127.0.0.1:6379> keys crash*

  1. "crashQueue"
  2. "crashBitmap"
    127.0.0.1:6379> keys path
  3. "pathBitmap"
    127.0.0.1:6379> keys Path
  4. "oldPathsQueue"
    127.0.0.1:6379>

Any tips? cc: @thdusdl1219

thank you.

@adrian-rt
Copy link

I suspect it might have to do something with my instrumentation, I realized I didn't used the proxy.py file.

So, I change the build-jsc.sh to contain the following vars:

export CC="/Downloads/DIE/engines/compiler/clang"
export CXX="
/Downloads/DIE/engines/compiler/clang++"

where clang and clang++ are the symlinks that point to the proxy.py file. Now I get "No instrumentation detected"...
It was better previously when I pointed the CC & CXX var directly to afl-clang-fast from the afl dir.......

@thdusdl1219
Copy link
Member

build-jsc.sh is for compiling naive binary, not for instrumentation. I used build-jsc-cov.sh for instrumentation in the past.. Could you retry with this script?

@adrian-rt
Copy link

yes, it works again using this script.

I get this output in tmux but I still don't have the newPathsQueue in redis:

[] Checking corpus: ./corpus/output-9/001480-corpus.js
[
] Checking corpus: ./corpus/output-9/001481-corpus.js
[] Checking corpus: ./corpus/output-9/001482-corpus.js
[
] Checking corpus: ./corpus/output-9/001483-corpus.js
[] Checking corpus: ./corpus/output-9/001484-corpus.js
[
] Checking corpus: ./corpus/output-9/001485-corpus.js
[] Checking corpus: ./corpus/output-9/001486-corpus.js
[
] Checking corpus: ./corpus/output-9/001487-corpus.js
[] Checking corpus: ./corpus/output-9/001488-corpus.js
[
] Checking corpus: ./corpus/output-9/001489-corpus.js
[] Checking corpus: ./corpus/output-9/001490-corpus.js
[
] Checking corpus: ./corpus/output-9/001491-corpus.js

@adrian-rt
Copy link

it seems that after calling "/redis_ctrl.js reportStatus fuzzer-$(hostname)-$(cat /etc/machine-id|cut -c 1-16)-14780 /home/adrian/Downloads/DIE/output-1/fuzzer_stats" the system command doesn't return for some reason and I get this error message : "+++ Testing aborted by user +++" . Placed breakpoints everywhere, I placed breakpoints on signal handlers, because I though maybe there's a signal raised that causes my program to get stopped, nothing happens.....the bps don't get hit, after that system call the program dies.

[] Command: node /home/adrian/Downloads/DIE/fuzz/afl/../TS/redis_ctrl.js reportStatus fuzzer-$(hostname)-$(cat /etc/machine-id|cut -c 1-16)-14780 /home/adrian/Downloads/DIE/output-1/fuzzer_stats
[1] + Done "/usr/bin/gdb" --interpreter=mi --tty=${DbgTerm} 0<"/tmp/Microsoft-MIEngine-In-6e7v9kz8.dhy" 1>"/tmp/Microsoft-MIEngine-Out-dtdm68f6.tif"
adrian@adrian-Precision-7750:~$ [
] Scanning './corpus/output-1'...
[] Checking corpus: ./corpus/output-1/000000-corpus.js
[
] Spinning up the fork server...
[+] All right - fork server is up.
[] Command: node /home/adrian/Downloads/DIE/fuzz/afl/../TS/redis_ctrl.js reportStatus fuzzer-$(hostname)-$(cat /etc/machine-id|cut -c 1-16)-14780 /home/adrian/Downloads/DIE/output-1/fuzzer_stats
[
] Checking corpus: ./corpus/output-1/000001-corpus.js

+++ Testing aborted by user +++

@thdusdl1219
Copy link
Member

+++ Testing aborted by user +++ is the correct message if every population is finished. Could you provide more details of the execution? Did you run populate.sh instead of run.sh? It should not be finished if you ran run.sh correctly..

@Peter6-beep
Copy link

I suggest compiling JS engines with the provided scripts in engine dir as we selectively instrument the binary (See engine/compiler/proxy.py). I pushed scripts for #6 so please check it.

Hi @thdusdl1219 thank you for open sourcing this fuzzer! I'm running "populate.sh", but how can I get [target binary path]? Looking forward to your reppy. Thank you.

@m0ck1ng
Copy link

m0ck1ng commented Jan 10, 2021

Hi all,

got a similar issue, I'm missing "newPathsQueue". all the other keys seem to be there. I've also added -C to afl-fuzz as was suggested here.

these are my redis keys:

127.0.0.1:6379> keys crash*

  1. "crashQueue"
  2. "crashBitmap"
    127.0.0.1:6379> keys path
  3. "pathBitmap"
    127.0.0.1:6379> keys Path
  4. "oldPathsQueue"
    127.0.0.1:6379>

Any tips? cc: @thdusdl1219

thank you.

hi, I also met a similar problem with "newPathsQueue" and "pathBitmap" in redis missing.
I'm sure I have instrumented Chakracore with afl-clang-fast and get stuck in populate.sh.
Have you solved the problem? And what do you mean saying "add -C to afl-fuzz" ? Is that a command flag or something?
I will appreciate a lot if you could reply me.

@1789120321
Copy link

Hi, @thdusdl1219 When running the tool, I encountered two problems.
How to get the binary file when running the file : populate.sh ?
How to instrument JavaScript engine?
I will appreciate a lot if you could reply me. Thank you.

@ducphanduyagentp
Copy link

Hi @turbolizer, I wonder how you compiled the target and fix things because seems like I am facing the same issue. Thank you!

@m0ck1ng
Copy link

m0ck1ng commented Apr 19, 2021

Hi @turbolizer, I wonder how you compiled the target and fix things because seems like I am facing the same issue. Thank you!

I make it. And here is a brief intro of my solution.
solution.md

Hope it may help you.

@ducphanduyagentp
Copy link

@StitchWuhula Thank you for your summary, that helps a lot. I am still trying but by any chance you've had it working with the latest v8? AFAIK latest v8 is using clang 13 so I've encountered a lot of issue when building.

@m0ck1ng
Copy link

m0ck1ng commented Apr 19, 2021 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants