I like to use fuzzing for a secondary purpose: to find out what works, not what is unexpectedly broken. I remember hearing about an undocumented command with a product I was working with. It took integers as arguments and had a different UI element for each different integer value passed. It occurred to me to flood it, using a loop, with a series of numbers well beyond the published range to see what else might be hiding in the product code. I was rewarded with several hits, some of them very useful. You might not ever want to build your application around undocumented features, but sometimes they are stable and useful and it can be fun to show off a bit by being able to leverage them.
My recent example for using PLINK to send commands over TCP to a Smart TV presented a potential surface for attack with this method. I wanted to find out if, with any of the published 4 bit codes, any serially entered 4 bit number would combine to make a code that could return some additional useful information from the TV. Unfortunately, my testing struck out, but the simple CMD batch file I came up with is very useful for documenting the results.
@echo off echo Fuzzing Interface... set cmdlist=TVNM MNRD SWVN IPPV WIDE setlocal ENABLEDELAYEDEXPANSION for %%a in (%cmdlist%) do ( for /L %%n in (1,1,9999) do ( set "cmd=%%a%%n " echo !cmd! >cmd.txt echo !cmd! plink 169.254.253.20 -P 10002 -raw < cmd.txt >results.txt timeout 1 set /P r=< results.txt if [!r!] EQU [OK] echo !cmd! !r!>> OKcommands.txt if [!r!] NEQ [ERR] echo !cmd! !r!>> goodcommands.txt if [!r!] EQU  echo no response )) echo Done. @echo on
First this generates a command fine, called cmd.tx by combining a command sequence with an integer. So our first command would be TVNM1, and our next would be TVNM2 on up to TVNM9999, the maximum range for the input.
Next, the code uses this command file as input to PLINK, and sends the response from PLINK to results.txt.
Then, it reads the result file into a variable, r, which can be evaluated to see if the command that was used is sent to the file of things that simply return OK or to the file that returns something other than ERR.
It's not perfect, there are some gaps in the code I decided not to take the time to close because we had moved past the point in the project where it would provide useful information. For one, the command text should always only be 8 characters and a carriage return. This code doesn't trim the resulting command down as the integers grow. I also could do a better job discriminating the useful output into different files, but a glance at the goodcommands.txt told me what I wanted to know.
There are lots of ways to use this approach and it can be employed in almost any system or language. A windows cmd batch file is probably one of the more simplistic, if not powerful, ways to use this method.