Do we really need a specialized unicorn mode? IIRC it changes basically nothing but set one or two env variables, specifically AFL_SKIP_BIN_CHECK (right?)

Ah this PR adds a bunch of other things, I see...
Other option: can we merge some flags for binary-only instrumentation into one? Does qemu_mode or unicorn mode (or frida mode?) really make a difference for the forkserver? Ideally it should not

This question is really out of my knowledge. Hope someone could answer this.

I can take a look but allow me a few days since still on travelling

Ideally, we do not need any special handling for unicornafl as said previously. It will act like any forkserver targets, like those compiled by afl-cc.

AFL++ internally has many checks to avoid users from composing unsupported features. For example, when using afl-forkserver, only qemu-mode would use cmplog, where other mode would fail the check (afl-cc use another code so not checked at that location). As a result, it may not be "special handling", it's just some misuse checks that require explicit unicorn mode set.

AFL++ internally has many checks to avoid users from composing unsupported features. For example, when using afl-forkserver, only qemu-mode would use cmplog, where other mode would fail the check (afl-cc use another code so not checked at that location). As a result, it may not be "special handling", it's just some misuse checks that require explicit unicorn mode set.

I mean, AFL++ can remove unicorn mode, i.e. “-U”, totally.

For example, I would prefer a "forkserver->force_cmplog" flag that both qemu and unicorn mode set, rather than a bunch of obscure feature flags sprinkled around the codebase. It gets very spaghetti otherwise

unicorn mode likely still needs SKIP_BINCHECK in comparison to afl-cc binaries

I mean -U likely still needs SKIP_BINCHECK

No, current uncornafl v3 pass that seamlessly thanks to libafl fsrv implementation

There may be some confusions here. I totally agree that force_cmplog flag is better, but without inferring unicorn mode by -U cmdline option, how can we set that flag accordingly? At least for now, we do not have a mechanism of guessing target instrumentation by user-provided binaries.

The idea is that uncornafl spins up fsrv like a normal afl-cc or libafl_cc instrumented binary so that it is very transparent to afl++. Unicornafl only needs to notify afl++ a crash is found by aborting intentioanlly.

There may be some confusions here. I totally agree that force_cmplog flag is better, but without inferring unicorn mode by -U cmdline option, how can we set that flag accordingly? At least for now, we do not have a mechanism of guessing target instrumentation by user-provided binaries.

The point is that “unicorn mode” is not necessary. Unicornafl can mock as a pretty normal fsrv targets.

OK, that makes sense.

I mean -U likely still needs SKIP_BINCHECK

No, current uncornafl v3 pass that seamlessly thanks to libafl fsrv implementation

It suddenly occurred to me that, if we provide python binding of new unicornafl, then the bin check should be skipped, otherwise the python executable will be checked? 🤔

I mean -U likely still needs SKIP_BINCHECK

No, current uncornafl v3 pass that seamlessly thanks to libafl fsrv implementation

It suddenly occurred to me that, if we provide python binding of new unicornafl, then the bin check should be skipped, otherwise the python executable will be checked? 🤔

I looked into the code and we can reuse QEMU mode to skip bin checks.

@wtdcode please ping me (repeatedly if necessary :-) ) when this is ready to be merged

@wtdcode please ping me (repeatedly if necessary :-) ) when this is ready to be merged

This PR may no longer be needed (cc @Evian-Zhang)

For harness building with new unicornafl in Rust/C/C++, nothing special is needed: https://github.com/AFLplusplus/unicornafl/blob/ea475ce52594ad256e602823f8b2f3d25a295904/.github/workflows/ci.yaml#L74

For harness building witn new unicornafl in Python, I would suggest aliasing unicorn mode to qemu mode to skip bin check. Not really tested yet, but I checked the code and it should work, or with a few lines.

I agree. @vanhauser-thc Feel free to close this PR if you also think this is unnecessary :)

I cannot comment if this PR is needed or not - you are the experts :-)
At least it needs a PR to update the unicornafl checkout

I cannot comment if this PR is needed or not - you are the experts :-) At least it needs a PR to update the unicornafl checkout

Will let you know once I have tested the python cases.

I would close this PR. I think the new unicornafl checkout shall be updated after AFLplusplus/unicornafl#43 is merged.