frida_libpng example does not compile on Mac

[br-lewis]

While trying to run frida_libpng on my M1 Mac running MacOs 13.5, I ran into two problems which are dependent on each other so I'm adding them as one issue but let me know if you want me to split them.

1. frida_libpng does not compile
2. if I update the dependencies so that it does compile, it doesn't do any fuzzing

Not compiling

Describe the bug
frida_libpng does not compile due to an error in a dependency. Updating a few dependencies was able to get it building.

• LibAFL/fuzzers/frida_libpng/Cargo.toml

  Line 30 in eae6f04

  frida-gum = { version = "0.8.1", features = [ "auto-download", "event-sink", "invocation-listener"] }

  , change to version 0.12.0

• LibAFL/libafl_frida/Cargo.toml

  Line 29 in eae6f04

  frida-gum-sys = { version = "0.4.1", features = [ "auto-download", "event-sink", "invocation-listener"] }

  , change to version 0.7.1

• LibAFL/libafl_frida/Cargo.toml

  Line 30 in eae6f04

  frida-gum = { version = "0.8.1", features = [ "auto-download", "event-sink", "invocation-listener"] }

  , change the version to 0.12.0 and add module-names to features

To Reproduce

1. Go to fuzzers/frida_libpng
2. Run cargo build --release or cargo make run

Expected behavior
The example fuzzer would compile

Screen output/Screenshots

 thread 'main' panicked at '"_GFloatIEEE754_struct_(unnamed_at_/Users/<redacted>/LibAFL/fuzzers/frida_libpng/target/release/build/frida-gum-sys-007ee71aac7d6748/out/frida-gum_h_3251_3)" is not a valid Ident', /Users/<redacted>/.cargo/registry/src/index.crates.io-6f17d22bba15001f/proc-macro2-1.0.66/src/fallback.rs:774:9

Not fuzzing

Describe the bug

With the fuzzer compiled, running it results in it doing no fuzzing. It periodically outputs a status update which shows that the target isn't being executed (see below). I wasn't able to get this working with VS Code's debugger but by adding lots of print statements, I've tracked the issue down to this line within libafl which goes to this line in frida-gum. That call to gum_sys::gum_stalker_follow_me seems to hang, at least beyond the default 5 minute timeout. I'm not sure how to chase down the cause further from that point.

To Reproduce
Steps to reproduce the behavior:

1. Go to fuzzers/frida_libpng
2. Run cargo make run

Expected behavior
I would expect the fuzzer to execute the the fuzz target function.

Screen output/Screenshots

[Broker      #0]  (GLOBAL) run time: 0h-0m-30s, clients: 0, corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
                  (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker      #0]  (GLOBAL) run time: 0h-1m-0s, clients: 1, corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
                  (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
[Broker      #0]  (GLOBAL) run time: 0h-1m-30s, clients: 1, corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000
                  (CLIENT) corpus: 0, objectives: 0, executions: 0, exec/sec: 0.000

[domenukk]

@s1341 in case you find the time... :)

[Mrmaxmeier]

This is likely the same as #1383. (On Windows it also gets stuck instead of fuzzing, though updating frida-gum is not required.)

[s1341]

Can you check if this is still the case after the frida update?

[br-lewis]

Pulled the latest changes (keeping my dependency changes) and ran into a compilation error due on this line

error[E0425]: cannot find value `helper` in this scope
   --> /Users/<redacted>/LibAFL/libafl_frida/src/helper.rs:328:38
    |
328 | ...                   &helper.capstone,
    |                        ^^^^^^ not found in this scope

frida_libpng uses libafl_frida with the cmplog feature enabled. Switching that line to &capstone got it compiling and now cargo make run gives

[cargo-make] INFO - Running Task: run
/var/folders/<redacted>.sh: line 3: 77771 Killed: 9               ./${FUZZER_NAME} -F LLVMFuzzerTestOneInput -H ./libpng-harness.so -l ./libpng-harness.so
[cargo-make] ERROR - Error while executing command, exit code: 137
[cargo-make] WARN - Build Failed.

[br-lewis]

I'm not sure what's changed in the meantime but it's now getting slightly further with recent changes. I have a small example with a single file in the corpus and on startup it won't find that interesting, doesn't accept it as an input, and fails due to having an empty corpus. It looks like this may be due to the target module not being instrumented.
I added a log between these lines

                let mut first = true;
                log::debug!("RANGES: {:#?}", ranges);
                for instruction in basic_block {

Which gave me

[2023-08-11T11:46:06Z DEBUG libafl_frida::helper] RANGES: RefCell {
        value: {
            4723998720..4724015104: (
                0,
                ".../fuzz-target/harness.so",
            ),
        },
    }

Logging all the addresses in the for loop afterwards had them in the range of around 4377.... The numbers vary between runs of course but the addresses that are examined are never within the range of the target module on the ARM Mac. I tried this on an x86 Mac and it shows addresses in several different areas including ones within the range of the target module that are then instrumented.

[domenukk]

Can you see if #1408 helps at all?

[domenukk]

Fixed the reported build issues on my mac, cannot test it right now

[br-lewis]

The build issues are indeed fixed for me in that branch