Attach mode with PID as an option for in-app persistence

[AdnaneKhan]

Currently the DynamoRIO attach feature w/ WinAFL requires WinAFL to be passed module that will be searched for among all processes. This makes sense when the process will be restarted as the PID will be different, but for a case where the application is not restarted, a single PID would work.

Does it make sense to add the ability to use a PID for DynamoRIO attach mode, and then utilize in-app persistence so the process ID remains the same? The use case for this would be network fuzzing a service application where the function of interest is reached as a result of sending packets.

[ifratric]

I think it might make sense in some scenarios, but with a caveat that the target process is going to need to survive the entire fuzzing session. Meaning, if you find a bug and need to restart the target for that reason, or if there is a memory leak in the target and it dies after x iterations, the entire fuzzing session would also need to be shut down. The current attach implementation IIRC assumes there is some mechanism (external to winafl itself) to restart the target process if such a scenario occurs.

[AdnaneKhan]

The use case I'm thinking of is for fuzzing more mature applications where simply finding a single crash would be valuable.

[ifratric]

Yep, those are "some scenarios" where it might be useful :-) If you want to make that change, feel free to submit a pull request.

[AdnaneKhan]

Sounds good! There are a few other things I ran into that could be changed such as the OpenProcess call failing in the attach case after the named pipe connection is created because even if winafl is run from an elevated command prompt it doesn't seem to enable the privilege needed. Once I get my final use case working (I've had to make a few tweaks to the dynamoRIO side as well) I'll be in a good position to contribute when I have time outside of work.

[ifratric]

Sounds good, thanks!