search

aerosec / jetset

GNU General Public License v2.0
49 stars 6 forks source link

I am trying to Reproducing evaluation results #1

Closed KA2010 closed 2 years ago

KA2010 commented 2 years ago

that what I got

Screen Shot 2021-10-13 at 2 03 45 PM

and when I run concrete file, I got

Screen Shot 2021-10-13 at 2 49 32 PM
enjhnsn2 commented 2 years ago

1) Jetset uses xterm to display the firmware's output during symbolic execution. That error makes it seem like you don't have xterm installed. If it is and I forgot to add some config info to the makefile, let me know and I will fix it. 2) The output of run_drone_concrete looks correct. Jetset, by default, prints all length-1 MMIO writes to terminal. This ensures that we can view the serial text output of the firmware, but it also prints out junk when the firmware writes non-text to MMIO. The Drone target hit! message lets you know that the execution succeeded, and that address b174 was the target, which, in this case, is the start of the Drone's main communication loop.

KA2010 commented 2 years ago

Thank you for replay, yes adding config info to the makefile, like how to download xterm with Jetset, will be helpful. but my question now that I do not know what to do with output, What is the next step. Is there any guide can help with that. thanks

enjhnsn2 commented 2 years ago

One thing that you can do with the generated emulator is fuzz it: the fuzzer we used is located here https://github.com/aerosec/jetset_fuzzer .

KA2010 commented 2 years ago

yes I already look at it, but how I can use it. Is there is any guide that can help

enjhnsn2 commented 2 years ago

The fuzzing repo README is pretty detailed, but we don't have anything like a quick start guide. The fuzzer just relies on AFL, so if you're familiar with AFL, it shouldn't be too hard to get started.

maxwell-bland commented 2 years ago

Adding to this, there is an example for how to perform syscall fuzzing at: https://github.com/aerosec/jetset_fuzzer/blob/320b00f3982eb279568157c6213ee00b448f7707/example/cpu-exec.c#L162

At a high level, the steps to fuzzing are:

  1. Add code to checkpoint the qemu emulator and read the fuzzer inputs into the cpu state
  2. Initialize/build the docker image for the fuzzer (this isolating the fuzzer qemu instance from the OS itself, a necessary step because of how qemu is implemented)
  3. Run the https://github.com/aerosec/jetset_fuzzer/blob/master/scripts/afl-fuzz-one.sh script to test a single instance of the fuzzer
  4. (Optionally) https://github.com/aerosec/jetset_fuzzer/blob/master/scripts/afl-fuzz-many.sh to spin up several instances.

As Evan suggested, reading through the fuzzer's readme (and hopefully the code!) to make sure you understand how the system is working is strongly suggested. After reading the README, if there is still confusion, reading through https://github.com/aerosec/jetset_fuzzer/blob/master/accel/tcg/afl-qemu-cpu-inl.c can help significantly, or shoot me an email at mb28@illinois.edu