You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let me just start by saying thank you for such a cool idea! I'm excited to use this for some fuzzing research I am performing. However, I've been running into an issue when trying to usefpicker to perform instrumentation while fuzzing with AFL++.
I'm trying to fuzz a function within the CoreAudio MacOS library that handles incoming mach messages.
Here's the command I'm running:
sudo afl-fuzz -i in -o out -- ./fpicker -v --fuzzer-mode afl --communication-mode shm -e attach -p coreaudiod -f harness.js
Here's my harness.js file before compiling it with frida-compile:
// Import the fuzzer base class
import { Fuzzer } from "./harness/fuzzer.js";
//const Fuzzer = require("harness/fuzzer.js");
// The custom fuzzer needs to subclass the Fuzzer class to work properly
class TestFuzzer extends Fuzzer {
constructor() {
// The constructor needs to specify the address of the targeted function and a NativeFunction
// object that can later be called by the fuzzer.
const fuzz_function_addr = Module.enumerateSymbolsSync("CoreAudio").filter(function(o) {return o.name == "HALB_MIGServer_server";})[0].address;
const fuzz_function = new NativeFunction(
fuzz_function_addr,
"int", ["pointer", "pointer"], {
});
super("CoreAudio", fuzz_function_addr, fuzz_function);
}
prepare() {
}
fuzz(payload, length) {
const outputPointer = Memory.alloc(Process.pointerSize);
Memory.writePointer(outputPointer, ptr("0x0"));
this.target_function(payload, outputPointer);
}
}
const f = new TestFuzzer();
//exports.fuzzer = f;
export const fuzzer = f;
However, fpicker stalls during the first test case, every time. Am I using the tool wrong? Any ideas? Thanks so much:
sudo afl-fuzz -i ../subsystem_messages/CoreAudio/HALB_MIGServer_server -o HALB_MIGServer_server-OUT -- ./fpicker -v --fuzzer-mode afl --communication-mode shm -e attach -p coreaudiod -f harness.js
Password:
afl-fuzz++4.06a based on afl by Michal Zalewski and a large online community
[+] afl++ is maintained by Marc "van Hauser" Heuse, Heiko "hexcoder" Eißfeldt, Andrea Fioraldi and Dominik Maier
[+] afl++ is open source, get it at https://github.com/AFLplusplus/AFLplusplus
[+] NOTE: This is v3.x which changes defaults and behaviours - see README.md
[+] No -M/-S set, autoconfiguring for "-S default"
[*] Getting to work...
[+] Using exponential power schedule (FAST)
[+] Enabled testcache with 50 MB
[+] Generating fuzz data with a length of min=1 max=1048576
[*] Checking CPU scaling governor...
[+] You have 4 CPU cores and 4 runnable tasks (utilization: 100%).
[*] Setting up output directories...
[*] Scanning '../subsystem_messages/CoreAudio/HALB_MIGServer_server'...
[+] Loaded a total of 1235 seeds.
[*] Creating hard links for all input files...
[*] Validating target binary...
[*] Spinning up the fork server...
[+] All right - fork server is up.
[*] No auto-generated dictionary tokens to reuse.
[*] Attempting dry run with 'id:000000,time:0,execs:0,orig:fffd8968a91c12de202b3a81c1b0c0f4'...
[-] Oops, the program crashed with one of the test cases provided. There are
several possible explanations:
- The test case causes known crashes under normal working conditions. If
so, please remove it. The fuzzer should be seeded with interesting
inputs - but not ones that cause an outright crash.
- In QEMU persistent mode the selected address(es) for the loop are not
properly cleaning up variables and memory. Try adding
AFL_QEMU_PERSISTENT_GPR=1 or select better addresses in the binary.
- On MacOS X, the semantics of fork() syscalls are non-standard and may
break afl-fuzz performance optimizations when running platform-specific
targets. To fix this, set AFL_NO_FORKSRV=1 in the environment.
- Least likely, there is a horrible bug in the fuzzer. If other options
fail, poke <[email protected]> for troubleshooting tips.
[!] WARNING: Test case 'id:000000,time:0,execs:0,orig:fffd8968a91c12de202b3a81c1b0c0f4' results in a crash, skipping
[*] Attempting dry run with 'id:000001,time:0,execs:0,orig:fff272ad2955f2359fd438f00d9de95d'...
^Czsh: killed sudo afl-fuzz -i ../subsystem_messages/CoreAudio/HALB_MIGServer_server -o --
I dug into the logs a bit more and saw this output. It seems to be waiting for a semaphore to be released that never is:
It seems that your fpicker doesn't find the shared memory created by AFL++ as the log shows fpicker: [JS]: [*] afl_area_ptr: 0x0.
Did you enable the option CFLAGS="-DUSEMMAP=1" when you compile your AFL++?
Hi @ttdennis,
Let me just start by saying thank you for such a cool idea! I'm excited to use this for some fuzzing research I am performing. However, I've been running into an issue when trying to use
fpicker
to perform instrumentation while fuzzing with AFL++.I'm trying to fuzz a function within the
CoreAudio
MacOS library that handles incoming mach messages.Here's the command I'm running:
sudo afl-fuzz -i in -o out -- ./fpicker -v --fuzzer-mode afl --communication-mode shm -e attach -p coreaudiod -f harness.js
Here's my harness.js file before compiling it with
frida-compile
:However,
fpicker
stalls during the first test case, every time. Am I using the tool wrong? Any ideas? Thanks so much:I dug into the logs a bit more and saw this output. It seems to be waiting for a semaphore to be released that never is:
The text was updated successfully, but these errors were encountered: