Finding out what works - with Fuzzing

Fuzzing is an interesting concept.  From a software testing perspective, it's a means of finding out where code will break by flooding it with a steady stream of commands, good bad or indifferent, to see if you can break it.  The test input is literally garbage, which could be described as fuzzy data, purpose made to be random enough to find the things you didn't think of that might break your code.

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.