Changes between Initial Version and Version 1 of zzuf/tutorial1


Ignore:
Timestamp:
05/18/2008 12:11:29 PM (17 years ago)
Author:
Sam Hocevar
Comment:

splitting tutorial into tutorial1, tutorial2 etc.

Legend:

Unmodified
Added
Removed
Modified
  • zzuf/tutorial1

    v1 v1  
     1{{{
     2#!html
     3<div style="text-align: center">
     4}}}
     5Prev: [wiki:zzuf zzuf home] | Next: [wiki:tutorial2 zzuf as a batch testing tool]
     6{{{
     7#!html
     8</div>
     9}}}
     10
     11= 1. Basic `zzuf` usage =
     12
     13`zzuf`’s behaviour is configured through the command line. A comprehensive list of flags and their meaning is given in the `zzuf` manual page. Just run '''`man zzuf`''' on your system to see it.
     14
     15== 1.1. Launching `zzuf` ==
     16
     17Let’s start with a simple command that reads data from a file. We choose `hd`, the hexadecimal dump command, so that we get a chance to observe what exactly happens to the data.
     18
     19This is how to tell `hd` to read 32 bytes from `/dev/zero`:
     20
     21{{{
     22% hd -vn 32 /dev/zero
     2300000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     2400000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     2500000020
     26%
     27}}}
     28
     29Now let’s fuzz `hd`’s input using `zzuf`. It’s completely straightforward: just prepend `zzuf` to the commandline.
     30
     31{{{
     32% zzuf hd -vn 32 /dev/zero
     3300000000  00 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     3400000010  00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |................|
     3500000020
     36%
     37}}}
     38
     39We see that two `00` values have been changed to `02`s. `zzuf` '''intercepted''' `hd`'s opening of `/dev/zero` and automatically '''corrupted''' the bits it read at random. Let’s do it again:
     40
     41{{{
     42% zzuf hd -vn 32 /dev/zero
     4300000000  00 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     4400000010  00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |................|
     4500000020
     46%
     47}}}
     48
     49We get exactly the same output. This is a very important property of `zzuf`: its behaviour is '''reproducible'''.
     50
     51== 1.2. Invoking different programs ==
     52
     53Let’s fuzz the `cat` utility instead of `hd`, but read the final output with `hd` nonetheless:
     54
     55{{{
     56% zzuf cat /dev/zero | hd -vn 32
     5700000000  00 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     5800000010  00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |................|
     5900000020
     60%
     61}}}
     62
     63Now instead of calling `hd`, let’s try `od`, the octal dumper:
     64{{{
     65% zzuf od -vN 32 /dev/zero
     660000000 000000 000002 000000 000000 000000 000000 000000 000000
     670000020 000000 000000 001000 000000 000000 000000 000000 000000
     680000040
     69%
     70}}}
     71
     72If you understand octal dumps as fluently as hexadecimal dumps, you noticed that the data has been fuzzed exactly like with `hd`.
     73
     74This is another very important property of `zzuf`: '''data is fuzzed the same way regardless of the fuzzed application'''.
     75
     76== 1.3. The fuzzing ratio ==
     77
     78The '''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.
     79
     80Let’s try fuzzing more bits, for instance 5% of the bits, using '''`-r` 0.05''':
     81
     82{{{
     83% zzuf -r 0.05 hd -vn 32 /dev/zero
     8400000000  00 01 00 00 00 00 44 00  04 80 00 40 21 00 0a 20  |......D....@!.. |
     8500000010  40 20 00 04 00 00 02 00  00 00 00 00 00 00 00 00  |@ ..............|
     8600000020
     87%
     88}}}
     89
     90We see that 15 bits have been changed. 5% of 256 bits is 12.8, so here again the behaviour is as expected.
     91
     92Now let’s fuzz fewer bits, for instance 0.1%, using '''`-r` 0.001''':
     93
     94{{{
     95% zzuf -r 0.001 hd -vn 32 /dev/zero
     9600000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     9700000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     9800000020
     99%
     100}}}
     101
     102No 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.
     103
     104Very high fuzzing ratios can be specified, for instance 50%, using '''`-r` 0.5''':
     105
     106{{{
     107% zzuf -r 0.5 hd -vn 32 /dev/zero 
     10800000000  c0 a0 20 b0 ad 40 07 c2  8a 14 30 1b 83 21 1a 69  |.. ..@....0..!.i|
     10900000010  11 28 05 07 30 00 70 01  43 08 62 c8 6d 45 e4 1a  |.(..0.p.C.b.mE..|
     11000000020
     111%
     112}}}
     113
     114== 1.4. The random seed ==
     115
     116`zzuf`’s behaviour is reproducible, but we might not be satisfied with the output. Or we may simply want to fuzz in several different ways, but still using the same fuzzing ratio. This is done by changing the '''random seed''' with the '''`-s` flag'''. The random seed is the initial value of `zzuf`’s random number generator. The default seed is 0, so let’s try with other values:
     117
     118{{{
     119% zzuf -s 2 hd -vn 32 /dev/zero
     12000000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     12100000010  00 00 00 00 80 00 00 00  00 00 00 00 00 00 00 00  |................|
     12200000020
     123% zzuf -s 79432 hd -vn 32 /dev/zero 
     12400000000  00 00 00 00 00 00 00 20  00 00 00 00 00 00 00 00  |....... ........|
     12500000010  00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |................|
     12600000020
     127%
     128}}}
     129
     130As can be seen, each seed value initiates a different behaviour of the random number generator.
     131
     132== 1.5. Creating fuzzed files ==
     133
     134It is possible to fuzz files directly, without calling applications at all.
     135
     136To do so, simply call `zzuf` with no application argument. It will fuzz its standard input by default:
     137
     138{{{
     139% cat /dev/zero | zzuf | hd -vn32         
     14000000000  00 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     14100000010  00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |................|
     14200000020
     143%
     144}}}
     145
     146`zzuf` can be used to create files. Again, the behaviour is entirely reproducible:
     147
     148{{{
     149% dd if=/dev/zero bs=1 count=32 | zzuf > output.file
     15032+0 records in
     15132+0 records out
     15232 bytes (32 B) copied, 9.1129e-05 s, 351 kB/s
     153% hd -v output.file
     15400000000  00 00 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
     15500000010  00 00 00 00 00 02 00 00  00 00 00 00 00 00 00 00  |................|
     15600000020
     157%
     158}}}
     159
     160This may be used if a given application is not supported by `zzuf`, but it is especially useful to generate files that reproduce `zzuf`’s behaviour without requiring `zzuf` at all.
     161
     162{{{
     163#!html
     164<div style="text-align: center">
     165}}}
     166Prev: [wiki:zzuf zzuf home] | Next: [wiki:tutorial2 zzuf as a batch testing tool]
     167{{{
     168#!html
     169</div>
     170}}}