How to debug target hanging inside the qemu-nyx instance started by rust_fuzzer?

[isefuzz]

Hi there,

We are trying to use nyx-net fuzzing some complex interactive systems, and we have successfully started the target system inside qemu-nyx manually. Unfortunately, the target came into hanging inside qemu-nyx instance when we started it with rust_fuzzer. According to the hook message printed by the code from your DEBUG_MODE and added by us, we found that our target is blocked somewhere and never come into socket() and bind(). As a result, it cannot reach the init_nyx() function and cannot start the fuzzing process.

We have tried several ways to debug. Specifically, we tried to use gdbserver to enable remote debugging, but it turns out that the qemu-nyx will kill the process started by gdbserver in the fork() hooked by ld_preload_fuzz.so. We have also tried connecting the rust_fuzzer-started qemu-nyx with ssh, but it seems the standard output of qemu-nyx has been captured by the chardev used for controlling fuzzing. Is there any possible way to debug our situation?

Some configs of concern

We have modified many configurations of qemu-nyx, here some critical ones:

• We have raised the version of the kernel to 6.13 and started the qemu-nyx vm from a debian image.
• Our target system runs in a multi-threaded mode. Many pthread_* functions are called when the target is running.

[isefuzz]

We have resolved this issue. It turns out that our target system implements a while loop to continuously invoke rand() to ensure a random seed is non-zero, while ld_preload_fuzz.c hooks and overrides rand() to make it always return 0. We fixed the issue by simply commenting out the hooking or rand() and random.

Though the issue has been somewhat resolved, we are curious about why rand() and random() are reimplemented to return 0. Is this a design out of high-speed fuzzing?