New config: read from /dev/urandom

Given that Piper doesn't support Intruder payload generators, I used a payload processor instead. That works well! The result is a low-cost Web fuzzer, mostly aimed to embedded/IoT devices

intruderPayloadProcessors:
- prefix: [sh, -c, dd if=/dev/urandom of=/dev/stdout bs=1 count=`shuf -i1-100 -n1` status=none]
  inputMethod: stdin
  name: /dev/urandom

Linking the inspiring Twitter thread for reference: https://twitter.com/Agarri_FR/status/1326221026422906880

Thanks, I added it to the deafult config and finally added support for payload generators. I like your workaround (and TIL null payloads exist) and this new payload generator solution will allow for external generators that need state (and thus no reexec for every payload), such as https://github.com/asciimoo/exrex by @asciimoo (see example config) or John the Ripper's stdout password listing output for rules mangling.

I released v0.7 that contains these.

Many thanks, for:

integrating my /dev/random processor
adding support for Intruder generator
discussing exrex (that could be useful ;-)

As an improvement, I wonder if the payload's baseValue (for processors and generators) could be exposed (probably via stdin). It would be useful when some details (length, charset, ...) about the non-fuzzed value are needed, for example when mutating with radamsa.

I wonder if the payload's baseValue (for processors and generators) could be exposed (probably via stdin). It would be useful when some details (length, charset, ...) about the non-fuzzed value are needed

I was thinking about this when I integrated it this way:

burp-piper/src/main/kotlin/burp/BurpExtender.kt

Line 173 in 80b8589

val p = modelItem.cmd.execute(ByteArray(0)).first

So that empty byte array could definitely be replaced by baseValue, I'll run some local test and see what comes out... If I could fit this into cmd.execute that would be great, since that would mean stdin/command line argument could be switchable using the regular GUI options already used for all other tools.

I'm not sure what you mean for processors, since I already make it available to them, see below:

burp-piper/src/main/kotlin/burp/BurpExtender.kt

Line 138 in 80b8589

    
           else getStdoutWithErrorHandling(modelItem.cmd.execute(currentPayload), modelItem)

Did it not work for you? If so, let's talk about it, since that should be a bug which I intend to fix. :)

Generators: exposing the baseValue would allow to run (f.e.) radamsa on it. That would nice, even if it isn't a common use-case (at least for me). No opinions regarding how to integrate that in the GUI and such.

Processors: it works fine, it was just me being dumb (tested by chaining a stock Convert to upper-case and a Piper-provided rev)