Peach see’s stored procedures as callable methods with parameters and possible return types.  This allows creating anything from super simple to very complex state machines around your set of stored procedures.  Additionally there is the typical rich set of data modeling tools available for specifying the parameter data.

The example provided in this article is taken from the SQL Stored Procedure Fuzzing Tutorial and uses MySQL v5.1 as the test database. ?????? ????? ????

Example 1 – Simple Stored Procedure

Our first example is very simple, we will have a single stored procedure called “testproc” that accepts a single parameter “parameter1” that is typed as a “varchar(255).”

The MySQL database schema looks like this:

?????? ????? ????

create table if not exists testtable (
   msg varchar(255)
);

delimiter //
CREATE PROCEDURE testproc(IN parameter1 VARCHAR(255))
BEGIN
   insert into testtable (msg) values (parameter1);
END;
//

Next we need to create out Peach PIT file, this will contain a data model for our parameter, a state machine that calls our method, and finally a publisher configured to talk with MySQL.

<?xml version="1.0" encoding="utf-8"?>
<Peach xmlns="http://phed.org/2008/Peach"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://phed.org/2008/Peach /peach/peach.xsd">

       <Include ns="default" src="file:defaults.xml"/>
       <Include ns="pt" src="file:PeachTypes.xml"/>

       <DataModel name="TheDataModel">
               <String value="Peachy"/>
       </DataModel>

       <StateModel name="TheState" initialState="Initial">

               <State name="Initial">
                       <Action type="call" method="call testproc(?)">
                               <Param name="p1" type="in">
                                       <DataModel ref="TheDataModel"/>
                               </Param>
                       </Action>
               </State>
       </StateModel>

       <Test name="TheTest">
               <StateModel ref="TheState"/>

               <Publisher class="sql.Odbc">
                       <Param name="dsn" value="TestMySql/root/password"/>
               </Publisher>
       </Test>

       <Run name="DefaultRun">
               <Test ref="TheTest"/>
       </Run>
</Peach>

  ?????? ????? ???? ?????? ????? ????

And that’s it!  Now, obviously there is little point to fuzzing our example method.  The real targets for our fuzzing are the built in methods that ship with most SQL servers, or 3rd party “native” stored procedures (those written in languages like C, or C++).

Well, I hope this was a good introduction to fuzzing SQL stored procedures with Peach!  If you have any questions please post them on the Peach mailing list.

???? ??????? ????? ??????????? ???? ?????? ???

??????? ???????????

?????????? ??????? amr

To change the defaults for the Number element so they are unsigned and big endian you would use the following XML: ?????? ???????

???? ??????? ???? ?????

<Defaults>
  <Number signed=”false” endian=”big” />
</Defaults> ???? ?a????????? ????? 

Sadly most fuzzers do not support fuzzing shared libraries directly, so typically one was stuck dusting off something like SPIKE, or some other framework and writing some custom code to drive everything.  Things can get even more complicated if the exposed methods you are fuzzing take complex types comprised of structures with pointers to other structures, etc.

download this is it movie

Enter Peach.  Peach has always been capable of loading shared libraries and making function calls, however not until version 2.3 has Peach supported complex structure types and pointers.

Lets take a look at a few samples to get an idea of how easy this is with Peach.

Use Case #1 – Non-complex data types ?????????????? ? ??????????

Out first example will emulate the follow code:

mydll.Initialize();
mydll.DoCoolThings( char* s );

?????? ????? ??????

?????? ????? ???????? ???????

First we will need to create a quick data model for our “s” parameter:

<DataModel name=”s”>
  <String value=”Hello World!” />
</DataModel>

Next is the state model that will have the method calls:

<StateModel name=”TheStateModel” initialState=”State1”>
  <State name=”State1”>
    <Action type=”call” method=”Initialize” />
    <Action type=”call” method=”DoCoolThings”>
      <Param name=”s” type=”in”>
        <DataModel ref=”s” />
      </Param>
    </Action>
  </State>
</StateModel>

• ????? ????????? ?????????

And finally we will need to configure a publisher:

??? ??????? ?????????? ???????? ?????

<Publisher class=”dll.Dll”>
  <Param name=”library” value=”mydll.dll” />
</Publisher>

c??? ???? ?????? ????? ?????

And that’s it!

Use Case #2 – Complex data types

Now, lets change to the definition of DoCoolThings to this:

struct otherstruct
{
  int a;
  int b;
};

struct mystruct
{
  struct otherstruct * val;
};

mydll.DoCoolThings( struct mystruct *s);

First we will need data models:

<DataModel name=”otherstruct”>
  <Number name=”a” size=”32” value=”0” />
  <Number name=”b” size=”32” value=”0” />
</DataModel>

<DataModel name=”mystruct” pointer=”true”>
  <Block ref=”otherstruct” pointer=”true” />
</DataModel>

Next we need the sate model:

<StateModel name=”TheStateModel” initialState=”State1”>
  <State name=”State1”>
    <Action type=”call” method=”Initialize” />
    <Action type=”call” method=”DoCoolThings”>
      <Param name=”s” type=”in”>
        <DataModel ref=”mystruct” />
      </Param>
    </Action>
  </State>
</StateModel>

And finally we will need to configure a publisher:

Zoe Saldana Neytiri

<Publisher class=”dll.Dll”>
  <Param name=”library” value=”mydll.dll” />
</Publisher>

And there you go. Easy! I hope this was a good introduction to fuzzing shared libraries with Peach.

CanSecWest 2009 is coming up in March and we are offering a two day Peach Dojo!  For more information and pricing check out the CanSecWest website.

Time Bomb

Ghosts of Mars divx download Owning Mahowny movie

Course Details

• Unittests to improve stability and reliability
• Improved COM support including properties
• Improved state machine
• Fuzz network clients easily by listening for connections, not just creating them
• Remote publishers allow sending data through a Peach Agent to a remote host
• Improved Linux and OS X support via debugger.UnixGdb monitor (uses beta pygdb module)
• Deterministic fuzzing will perform test count calculation in separate thread to speed fuzzing
• Improved documentation.  See the Peach 2 Tutorial which is quickly becoming the Peach 2 Guide :)

The Covenant full

Mr. Brooks

• Strange Wilderness rip

Can be had here.

P2 dvdrip The Digby Biggest Dog in the World hd

Hope Floats release

Nights in Rodanthe movie download

• Doctor Zhivago download

Big Bully movie

download open season divx Beauty and the Beast movie

Hot Fuzz film

PS- If your up at CanSecWest be sure to check out my talk on Peach Friday morning.

Head here to download.

???? ?????? ??????

• this is it dvd

pandora The course will cover creating fuzzers for the following situations:

• State-aware network protocol parsers
• N-tier applications
• Arbitrary APIs
• File parsers
• COM and Active/X components
• Detect non-classic faults in software
• Extend the Peach Fuzzing Platform by creating custom Transformers, Generators, Publishers, and Monitors.
• Apply these concepts and tools to their unique environment
• Utilize parallel fuzzing to increase fuzzing efficiency

Course information and registration.

The following article will walk you through an example file fuzzer.

Fuzzing file formats passed to applications on the command line have the following flow for each test iteration:

1. Create some mutated data
2. Write the data to disk
3. Launch the application
4. Close the application

To detect faults we will use Microsoft’s Application Verifier application which is able to automatically attached a debugger and set variouse memory debugging options on all processes with a specific executable name.  This is perfect for us since we will be restarting the application for each test we perform.  Peach includes a monitor called “debugger.WindowsAppVerifier” that we will use to control this tool.

Okay, so next up we need to be able to perform steps 2-4.  We will use a publisher called “file.FileWriterLauncherGui”.  This publisher will act as both a stream and call based publisher allowing us to write out a file and then launch an application.  It will wait about 5 seconds and than send a WM_CLOSE message to the application, and finally if the application does not shut down will terminate it.  If we are lucky, the WM_CLOSE message will let the application shutdown normally allowing for additional code coverage.

On with the XML!

Data Model

Nothing very interesting here.  We will have two data models, one will specify the filename for the program (this will make more sense later).  Note that one side affect of requiring the FileName data model will be some fuzzing of the filename.  There are a few mutators (the data tree set) that will not notice the “isStatic” and perform some mutations anyways.

<!-- Define our file format DDL -->
<DataModel name="FileData">
	<String value="Hello World!" />
</DataModel>

<!-- A template to hold the filename -->
<DataModel name="FileName">
	<String isStatic="true" value="fuzzedfile.txt" />
</DataModel>

State Model

Now things get more interesting.  This is were we will define steps 2-4.  There are three actions in the following state model.  The first two will create, write, and close the file after writing out data model out to it.  The third action will launch our application passing as a parameter the FileName data model (fuzzedfile.txt).

<StateModel name="State" initialState="Initial">
    <State name="Initial">
        <!-- Write out contents of file -->
        <Action name="WriteFile" type="output">
            <DataModel ref="FileData" />
        </Action>

        <!-- Close file -->
        <Action type="close" />

        <!-- Launch the file consumer -->
        <Action type="call" method="c:\windows\system32\notepad.exe">
            <Param type="in" name="filename">
                <DataModel ref="FileName"/>
            </Param>
        </Action>
    </State>
</StateModel>

Agent Configuration

Next up we need to configure out agent and monitor to use the debugger.WindowsAppVerifier monitor.  Notice that the parameter to the monitor specified just the executable name, not the full path.

<!-- Setup a local agent that will monitor for faults -->
<Agent name="LocalAgent" location="http://127.0.0.1:9000">
    <!-- For file fuzzing were the application will be launched and closed
        a number of times we will use Microsofts Application Verifier to
        monitor the process for faults.  -->
    <Monitor class="debugger.WindowsAppVerifier">
        <Param name="Application" value="notepad.exe" />
    </Monitor>
</Agent>

Test and Run Configuration

Almost done now, this is the final section were we configure the test and run.  These two sections will tie all these things together and associate our publisher.  I have bolded the two parameters for the publisher we are using.  The filename must match the one in our FileName data model or things will not work right.  Additionally the windowName parameter should be a unique (but partial) application window title.

<Test name="TheTest">
    <Agent ref="LocalAgent" />

    <StateModel ref="State"/>

    <!-- Configure our publisher with correct filename to write too -->
    <Publisher class="file.FileWriterLauncherGui">
        <Param name="fileName" value="fuzzedfile.txt" />
        <Param name="windowName" value="Notepad" />
    </Publisher>
</Test>

<Run name="DefaultRun">
    <Test ref="TheTest" />
    <Logger class="logger.Filesystem">
        <Param name="path" value="c:\peach\logtest" />
    </Logger>
</Run>

Running the Fuzzer

Okay, to run this bad boy we will need to launch two command windows.  In one kick off a Peach Agent by running “peach.py -a”.  In the second window we will run our fuzzer by saying “peach.py FileFuzzerGui.xml”.  If all works well you will see notepad popup with “Hello World!” for a few seconds than go away only to be replaced with another notepad window.  If you continue watching you will see “Hello World!” start to get mutated.

The Complete File Listing

Here is the complete file listing for this fuzzer example.  I hope it made sense!

<?xml version="1.0" encoding="utf-8"?>
<Peach xmlns="http://phed.org/2008/Peach" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://phed.org/2008/Peach ../peach.xsd" version="1.0"
	author="Michael Eddington">

	<!-- Import defaults for Peach instance -->
	<Include ns="default" src="file:defaults.xml" />
	<Include ns="pt" src="file:PeachTypes.xml" />

	<!-- Define our file format DDL -->
	<DataModel name="FileData">
		<String value="Hello World!" />
	</DataModel>

	<!-- A template to hold the filename -->
	<DataModel name="FileName">
		<String isStatic="true" value="fuzzedfile.txt" />
	</DataModel>

	<!-- Define a simple state machine that will write the file and
		then launch a program using the FileWriterLauncher publisher -->
	<StateModel name="State" initialState="Initial">
		<State name="Initial">
			<!-- Write out contents of file -->
			<Action name="WriteFile" type="output">
				<DataModel ref="FileData" />
			</Action>

			<!-- Close file -->
			<Action type="close" />

			<!-- Launch the file consumer -->
			<Action type="call" method="c:\windows\system32\notepad.exe">
				<Param type="in" name="filename">
					<DataModel ref="FileName"/>
				</Param>
			</Action>
		</State>
	</StateModel>

	<!-- Setup a local agent that will monitor for faults -->
	<Agent name="LocalAgent" location="http://127.0.0.1:9000">
		<!-- For file fuzzing were the application will be launched and closed
			a number of times we will use Microsofts Application Verifier to
			monitor the process for faults.  -->
		<Monitor class="debugger.WindowsAppVerifier">
			<Param name="Application" value="notepad.exe" />
		</Monitor>
	</Agent>

	<Test name="TheTest">
		<Agent ref="LocalAgent" />

		<StateModel ref="State"/>

		<!-- Configure our publisher with correct filename to write too -->
		<Publisher class="file.FileWriterLauncherGui">
			<Param name="fileName" value="fuzzedfile.txt" />
			<Param name="windowName" value="Notepad" />
		</Publisher>
	</Test>

	<Run name="DefaultRun">
		<Test ref="TheTest" />
		<Logger class="logger.Filesystem">
			<Param name="path" value="c:\peach\logtest" />
		</Logger>
	</Run>

</Peach>
<!-- end -->

Peach 2.1 BETA3 includes the following fixups out of the box:

• checksums.Crc32Fixup — This fixup computes the standard CRC32 as defined by ISO 3309 and is used by PNG, zip, etc.
• checksums.EthernetChecksumFixup — Computes the ethernet checksum.
• checksums.IcmpChecksumFixup — Computes the ICMP packet checksum.

Using Fixups

Our example will be a PNG chunk data model which looks like this:

<DataModel name=”Chunk”>
    <Number name=”Length” size=”32″ endian=”network” signed=”false”>
        <Relation type=”size” of=”Core.Data”/>
    </Number>
    <String name=”Type” length=”4″/>
    <Blob name=”Data” value=”"/>
    <Number name=”CRC” size=”32″ signed=”false” endian=”network” isStatic=”true” value=”9999″ />
</DataModel>

From the PNG spec we know the CRC should be of Type and Data.  We will need to do two modifications to this data model.  First we will need to wrap Type and Data in a Block element.  Second we will add our fixup.

<DataModel name=”Chunk”>
    <Number name=”Length” size=”32″ endian=”network” signed=”false”>
        <Relation type=”size” of=”Core.Data”/>
    </Number>
    <Block name=”Core”>
        <String name=”Type” length=”4″/>
        <Blob name=”Data” value=”"/>
    </Block>
    <Number name=”CRC” size=”32″ signed=”false” endian=”network” isStatic=”true” value=”9999″>
        <Fixup class=”checksums.Crc32Fixup”>
            <Param name=”ref” value=”Core”/>
        </Fixup>
    </Number>
</DataModel>

The bolded portions are the changes we made.  The one of most interest is the <Fixup> element that is a child of the CRC number.  All fixups take a single parameter of ref that specifies the name of the element that we will operate on.  In this case that is Core the wrapper of Length and Data.

Creating Custom Fixups

Creating custom fixups are easy and require implementing a single class and two methods.  The following is the code for the Crc32Fixup that we used in the above example:

class Crc32Fixup(Fixup):
	'''
	Standard CRC32 as defined by ISO 3309.  Used by PNG, zip, etc.
	'''

	def __init__(self, ref):
		Fixup.__init__(self)
		self.ref = ref

	def fixup(self):
		stuff = self._findDataElementByName(self.ref).getValue()
		if stuff == None:
			raise Exception("Error: Crc32Fixup was unable to locate [%s]" % self.ref)

		return zlib.crc32(stuff)

To implement your own Fixup simply copy this code and change the class name (Crc33Fixup), the Exception string and finally implement your own fixup code instead of “return zlib.crc32″.  To include your custom module see the documentation about <PythonPath> and <Import> in the Peach 2 Tutorial.

Thanks to David for reporting this bug.

Patch and List Post