USBFuzz icon indicating copy to clipboard operation
USBFuzz copied to clipboard

Command to reproduce the bug problem

Open datadancer opened this issue 4 years ago • 1 comments

Given that you have found a USB bug, you may need to reproduce the bug. Assume that we have found a bug and the crashing input is saved in bugs/bug1.

 run the following command to start the guest vm:

./usbfuzz-afl/qemu_mode/qemu-build/x86_64-softmmu/qemu-system-x86_64 -M q35 -device qemu-xhci,id=xhci -object memory-backend-shm,id=shm -device ivshmem-plain,id=ivshmem,memdev=shm -m 4G -enable-kvm -kernel OSes/linux-target/linux-test-build/arch/x86_64/boot/bzImage -hda images/linux/stretch.img -append 'root=/dev/sda console=ttyS0' -usbDescFile bugs/bug1 -serial stdio The usbDescFile should be bugs/bug1, not seeds/usb_sk4Wm9j.

datadancer avatar Feb 05 '21 00:02 datadancer

I found some crash input in workdir/crashes. One of them is named "id:000000,sig:81,src:000025,op:flip2,pos:11". But when I try to reproduce the bug, use the command like "xxxxx -usbDescFile workdir/crashes/id:000000,sig:81,src:000025,op:flip2,pos:11 stdio -serial stdio", it says "qemu-system-x86_64: -usbDescFile workdir/crashes/id:000000,sig:81,src:000025,op:flip2,pos:11: drive with bus=0, unit=0 (index=0) exists" and does not work. But when I use "-usbDescFile bugs/bug1", it can work. Is that because the crash input is incomplete or something else?

wanrenmi avatar Mar 15 '23 03:03 wanrenmi