low stability

[vanhauser-thc]

I noticed that the stability is very low, also when ASLR is deactivated.

do you know what the reason is for that?

btw. I used lots of your code for here: https://github.com/AFLplusplus/AFLplusplus/tree/dev/examples/afl_frida

[meme]

Would have to check to be sure, but I imagine it is related to/the result of issue: https://github.com/meme/hotwax/issues/2

[vanhauser-thc]

I doubt it.

If I remove the persistent signature (hence fork mode is used) I have 100% stability and the identified paths are correct. Enabling persistent mode by uncommentiing the signature again pushes down the stability and it finds an impossible number of paths.

My guess is that some frida functions have to be called at the start/end of the the while loop.

now writing this the issue seems obvious: as "follow me" is active in the while loop, isnt all afl code also followed? that could be an explanation. I will move the follow/unfollow within the loop and report back

[vanhauser-thc]

no thats sadly not it ... putting the follow/unfollow in the loop just decreases the speed a lot but does not increase the stability.

[meme]

I explicitly tell Stalker to exclude the range of the parent executable, so it will NOT trace Frida's code nor the code inside of target_persistent. Did you retain that code?

[vanhauser-thc]

I am talking about your code, not what I adapted (otherwise this issue would be pointless as this is about your code, not mine :)

when starting with afl-fuzz -i in -o out ./target_persistent it is already announced: [!] WARNING: Instrumentation output varies across runs. and it finds an impossible number of paths: total paths : 15

But I found one issue in the code, one that bit me more than in your code base: code_start and code_end are unused when deciding to instrumenting blocks.

when this is fixed it still has the same stability issue though ...

[vanhauser-thc]

I think the remaining instability after the PR is that the code range you get is the whole binary not just the parts you add from target.o. and it then includes all the afl and gum stuff in target*.c.

because what I did is adding generic fuzzing support, so people specify a target library and function, that library is loaded with dlopen and from that point I can get the exact memory range and unless there are instabilities in the target I naturally have 100% stability.

so for your case you would just need to get the start and end address of the box() function and use that for code_start/code_end.

[meme]

Ah, I think I'll replace box() to be dynamically loaded in my example as well. I think that is also generally better suited for people's use-case. Thanks for your help on this.

[vanhauser-thc]

no problem :) Currently I take the address of the module from /proc/self/maps which is not portable, and I guess your solution will take gum which will be much better