Open Deoxyss opened 5 years ago
This project uses QEMU 2.3.0, and requires the project specific AFL patches to work properly.
Yes, this will only work with the provided version of QEMU.
If you're still interested, please move any discussion to https://github.com/timnewsham/TriforceAFL where we can try and provide support.
I'm trying to fuzz the emulation of QNX on QEMU-support using TriforceAFL
So, for fuzzing, I use:
./afl-fuzz -t 500+ -i inputs -o out234 -QQ -- \ ./afl-qemu-system-trace \ -m 256M \ -L qemu_mode/qemu/pc-bios \ -drive format=raw,file=ifs.img \ -drive file=fs.img,format=raw \ -kernel bzImage -aflPanicAddr ffffffff8108ea0c \ -aflDmesgAddr ffffffff810f32e0 \ -aflFile @@
Here,
- fs.img and ifs.img are the filesystem and image-filesystem disk files used to boot QNX on QEMU
- I modified afl-qemu-system-trace from QEMU emulator version 2.3.0 to QEMU emulator version 2.11.1 (older version was not able to boot qnx)
- bzImage is procnto-smp-instr (as kernel is the process with PID of 1)
- Panic and Dmesg are used accordingly
Also, to test the emulation of QNX, I'm using:
./afl-qemu-system-trace \ -m 256M \ -L qemu_mode/qemu/pc-bios \ -drive format=raw,file=ifs.img \ -drive file=fs.img,format=raw \
This boots QNX on QEMU
But, when I run the above afl-fuzz command, it gives the following error:
[-] Hmm, looks like the target binary terminated before we could complete a handshake with the injected code. There are two probable explanations: - The current memory limit (2.00 GB) is too restrictive, causing an OOM fault in the dynamic linker. This can be fixed with the -m option. A simple way to confirm the diagnosis may be: ( ulimit -Sv $[2047 << 10]; /path/to/fuzzed_app ) Tip: you can use http://jwilk.net/software/recidivm to quickly estimate the required amount of virtual memory for the binary. - Less likely, there is a horrible bug in the fuzzer. If other options fail, poke <lcamtuf@coredump.cx> for troubleshooting tips. [-] PROGRAM ABORT : Fork server handshake failed Location : init_forkserver(), afl-fuzz.c:2123
I'm still not able to figure out why it fails. I tried changing the memory limit, but it wasn't effective.
afl-qemu-system-trace is the target binary here (Please correct me if I'm wrong).
Also, when used in user mode (-Q) instead of full-system emulation (-QQ), this executed for QNX and fuzzing process started! i.e., in user mode (-Q), where afl-qemu-system-trace is qemu-system-x86_64 binary of QEMU emulator version 2.11.1
I read that qemu-system-x86_64 is used for full system emulation ( while qemu-x86_64 is for user mode emulation ) . Hence, afl-qemu-system-trace is for full-system emulation!
But here we are running full system emulation with -Q option (user mode) of afl !!!!
What does this mean exactly?
Please tell me how the ifs.img fs.img bzImage you mentioned is generated, I am a beginner in qnx and I can never google the answer to the generation of image files
I'm trying to fuzz the emulation of QNX on QEMU-support using TriforceAFL
So, for fuzzing, I use:
Here,
Also, to test the emulation of QNX, I'm using:
This boots QNX on QEMU
But, when I run the above afl-fuzz command, it gives the following error:
I'm still not able to figure out why it fails. I tried changing the memory limit, but it wasn't effective.
afl-qemu-system-trace is the target binary here (Please correct me if I'm wrong).
Also, when used in user mode (-Q) instead of full-system emulation (-QQ), this executed for QNX and fuzzing process started! i.e., in user mode (-Q), where afl-qemu-system-trace is qemu-system-x86_64 binary of QEMU emulator version 2.11.1
I read that qemu-system-x86_64 is used for full system emulation ( while qemu-x86_64 is for user mode emulation ) . Hence, afl-qemu-system-trace is for full-system emulation!
But here we are running full system emulation with -Q option (user mode) of afl !!!!
What does this mean exactly?