| 1 | = Zzuf tutorial = |
| 2 | |
| 3 | '''WARNING''': this tutorial requires `zzuf` version 0.11 or later. |
| 4 | |
| 5 | == Basics == |
| 6 | |
| 7 | Let’s start with a simple command that reads data from a file. We choose `hd`, the hexadecimal dump command, and tell it to read 32 bytes from `/dev/zero`: |
| 8 | |
| 9 | {{{ |
| 10 | % hd -vn 32 /dev/zero |
| 11 | 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
| 12 | 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
| 13 | 00000020 |
| 14 | % |
| 15 | }}} |
| 16 | |
| 17 | Now let’s fuzz `hd`’s input using `zzuf`. It’s completely straightforward: just prepend `zzuf` to the commandline. |
| 18 | |
| 19 | {{{ |
| 20 | % zzuf hd -vn 32 /dev/zero |
| 21 | 00000000 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
| 22 | 00000010 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 |................| |
| 23 | 00000020 |
| 24 | % |
| 25 | }}} |
| 26 | |
| 27 | We see that two `00` values have been changed to `02`s. `zzuf` '''intercepted''' `hd`'s opening of `/dev/zero` and automatically '''corrupted''' the bytes it read at random. Let’s do it again: |
| 28 | |
| 29 | {{{ |
| 30 | % zzuf hd -vn 32 /dev/zero |
| 31 | 00000000 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
| 32 | 00000010 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 |................| |
| 33 | 00000020 |
| 34 | % |
| 35 | }}} |
| 36 | |
| 37 | We get exactly the same output. This is a very important property of `zzuf`: its behaviour is '''reproducible'''. |
| 38 | |
| 39 | == Altering the fuzzing ratio == |
| 40 | |
| 41 | The '''fuzzing ratio''' is the proportion of bits that `zzuf` changes. It is specified with the '''`-r` flag'''. The default fuzzing ratio is 0.004, meaning "fuzz 0.4% of the bits". 32 bytes is 256 bits, and 0.4% of 256 bits is approximately 1. `zzuf` should have fuzzed 1 bit, but since it fuzzes bits at random, 2 bits is not surprising. |
| 42 | |
| 43 | Let’s try fuzzing more bits, for instance 5% of the bits, using '''`-r` 0.05''': |
| 44 | |
| 45 | {{{ |
| 46 | % zzuf -r 0.05 hd -vn 32 /dev/zero |
| 47 | 00000000 00 01 00 00 00 00 44 00 04 80 00 40 21 00 0a 20 |......D....@!.. | |
| 48 | 00000010 40 20 00 04 00 00 02 00 00 00 00 00 00 00 00 00 |@ ..............| |
| 49 | 00000020 |
| 50 | % |
| 51 | }}} |
| 52 | |
| 53 | We see that 15 bits have been changed. 5% of 256 bits is 12.8, so here again the behaviour is as expected. |
| 54 | |
| 55 | Now let’s fuzz fewer bits, for instance 0.1%, using '''`-r` 0.001''': |
| 56 | |
| 57 | {{{ |
| 58 | % zzuf -r 0.001 hd -vn 32 /dev/zero |
| 59 | 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
| 60 | 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| |
| 61 | 00000020 |
| 62 | % |
| 63 | }}} |
| 64 | |
| 65 | No bits have been changed, because 0.1% of 256 is 0.256, so there were few chances that the bits would be changed at all. |
| 66 | |
| 67 | Very high fuzzing ratios can be specified, for instance 50%, using '''`-r` 0.5''': |
| 68 | |
| 69 | {{{ |
| 70 | % zzuf -r 0.5 hd -vn 32 /dev/zero |
| 71 | 00000000 c0 a0 20 b0 ad 40 07 c2 8a 14 30 1b 83 21 1a 69 |.. ..@....0..!.i| |
| 72 | 00000010 11 28 05 07 30 00 70 01 43 08 62 c8 6d 45 e4 1a |.(..0.p.C.b.mE..| |
| 73 | 00000020 |
| 74 | % |
| 75 | }}} |