Use Radamsa (or reimplement its algorithm) to generate potentially crashing inputs

[michaelbrownuc]

Radamsa is a test case generator we can use to generate new inputs that may cause a program to crash based off of a set of inputs. We can use this tool on the inputs that comprise the debloating spec to help us create useful mutated inputs in DIFFER.

https://gitlab.com/akihe/radamsa

[pgoodman]

It looks like Radamsa has evolved over time. Many years ago, I harnessed it into a function: https://github.com/lifting-bits/grr/tree/master/third_party/radamsa

[ameily]

Based on the "Debloating Tradeoffs" paper, it looks like we would feed our generated inputs into Radamsa and get a set of related inputs. So, Radamsa would be used to enhance our fuzzing input generation, not replace it outright since we still need some input seeds to generate related inputs from.

One thing we would need to account for is that a related input generated in this way may crash the original binary. Under normal circumstances, we would treat this as a bug of the original binary. However, I'm not sure if we want this behavior for related inputs. I could see a new option that controls how crashes are reported if the input was generated via Radamsa.

[michaelbrownuc]

I think it could be useful, but maybe not necessary at this junction. When we report crashes (of which we expect relatively few of in the original binary), we can leave it to the operator to handle inputs that cause crashes in both the original and mutated binaries.

[ameily]

Radamsa is a little buggy but I don't think it's a deal breaker. The number of samples generated is not always exact. For example, if I pass in --count 4 (generate 4 inputs) sometimes I'll get 4 back and other times I'll get a couple more than 4 back:

$ echo 2008-12-30 04:12:32 | ./radamsa/bin/radamsa -n 4
0-130 04:1:32
2008-12-2��31 -9503202933183296977628506-12��0 32765:12:32
38776-12��0 32765:12:32
38776-12��0 32765:12:32
38776-12��0 32765:12:32
38776-12��0 32765:12:32
38776-12��0 32765:12:32
2008--2147483649-29 2147483651:12:32

The code in radamsa is really hard to follow and primarily written in some Scheme/LISP fork called owl. I'll be able to work around this