Closed singleghost2 closed 3 years ago
Hi and sorry for a somewhat late reply, I just returned from my vacation. I see you closed the issue in the meantime but I still wanted to offer some thoughts, in case it helps:
Note that -patch_return_addresses has a significant performance impact so it's quite possible that something that takes <1s naively takes >10s with -patch_return_addresses. You can test if that's the case for you by trying to run without that flag, though you might encounter issues later in the fuzzing session if your target relies on C++ / Objective C exceptions.
We are currently working on a solution that will remove the need for -patch_return_addresses and allow fuzzing of such targets at near native speeds, but it's not ready just yet.
Thansk for you reply! I absolutely need patch_return_addresses
now because if not, I will receive libc++abi: terminating with uncaught exception of type CAXException
error. I use perisistent mode afterwards and see a performance improve to 0.8/s, hope that your work can bring the efficiency of tinyinst to a higher level. Thanks!
And I found that the increase in the number of threads is not proportional to the increase in fuzz speed. As the number of threads increases, the increase in fuzz speed becomes more and more slow. Too many threads may even lead to a decrease in fuzz speed. Any ideas about this?
For multiple threads - this is likely because of work done by the OS kernel - depending on how much time is spent in the target process vs. how much time is spent in the kernel, you will see a greater or lesser benefit with the number of threads. Unfortunately, -patch_return_addresses
also introduces a lot of kernel overhead (requiring context switching often etc.) so it also negatively affects this (but on the positive side, once we remove it, you should also see improvement in parallel fuzzing).
One thing you could experiment with is, instead of having one fuzzer process with large -nthreads
, you could have several fuzzer processes which synchronize over Jackalope server (see Jackalope -start_server
flag). Whether you'll get any benefit from this depends on how the operating system kernel is implemented (how locking mechanisms work etc.), but it's worth experimenting with.
Hello! I use jackalope to fuzz my target binary. Executing my binary on the command line alone can execute and exit normally in less than 1 second, but when using jackalope, it will timeout, even if the
-t
option is set to a very long time, such as 10 seconds, it will also timeout. The log is as followings, is there any ideas about what is happening? I tried to add-trace_debug_events
and-trace_basic_blocks
, the output shows that same basic block set is executed over and over again and seems to never stop. I suspect that the issue may lie in the instrumentation module of TinyInst.