Entries in FIX (2)


Fizzer Walkthrough

In September of 2013, GDS released a tool named Fizzer to fuzz the FIX (Financial Information eXchange) protocol.  You can find the original blog post here.

As a follow up to the original release of Fizzer, we wanted to give a brief walkthrough of running the tool.  Furthermore, different FIX receivers handle the fuzzed packets in different ways.  In addition, a couple of code changes can turn this tool into a quick way to test authentication or authorization in FIX systems.  For these reasons, we wanted to dive into some scenarios where you might want to modify the code.

Running Fizzer

Fizzer runs by inserting fuzz strings into FIX requests it parses from a raw packet capture.  The first step is to record a live FIX session between a client and server.  This session must be saved in RAW format to be accepted by Fizzer.  In Wireshark, this can be accomplished by following the TCP stream and selecting “Save As” for the selected conversation.

Once the session has been exported as a raw file, it can be given to Fizzer as a command line argument.  The host IP address, port, Sender Comp ID (sending institution), starting sequence number, and an optional output log file must also be specified.   Running the program without any command line arguments will show information about the usage of these arguments.

Common Modifications and Scenarios

Add Sender Comp ID to Ignored Tags

There is a line in the main loop which specifies which tags should not be fuzzed.  Some organizations may opt to include the SenderCompID (tag 49) in this list.  Adding “49=” to code below will instruct Fizzer to ignore that field.  By default, the BeginString, Message Length, MsgType, MsgSeqNum, and Checksum are ignored.  

else if (part.StartsWith(“8=”) || part.StartsWith(“9=”) || part.StartsWith(“35=”) || part.StartsWith(“34=”) || part.StartsWith(“10=”))


//Don’t fuzz these tags


Respond to Resend Requests

The FIX protocol includes specifications for a resend request initiated by the receiving application.  These are commonly used when an error with sequence numbers is detected or the receiving application was not able to adequately process a message.  Testing Fizzer against different FIX receiving servers showed varying behavior when responding to resend requests.  Some systems will block until a valid message is sent while others will proceed without issue.  The way sequence number and orderID are handled also varies between systems.  It may be necessary to customize or remove the section of code which resends the original message when a resend response is received from the server.  The following shows this section of code.

else if (Regex.IsMatch(fuzzResponse, getSoh() + “35=2” + getSoh()))


    Console.WriteLine(“[INFO] - Got Resend Request: ” + fuzzResponse);

    //try sending the orginal message to reset the system

    fuzzMsg = updateTimeSequenceChecksum(Original, sequence, ordId);

    Console.WriteLine(“[INFO] - Sending Clean Message: ” + fuzzMsg);

    testTime = DateTime.Now;

    sendData(client, stream, fuzzMsg, out fuzzResponse);

    responseTime = DateTime.Now - testTime;

     logMessage(testTime.ToString(“yyyyMMdd-H:mm:ss.fff”), “reset::” + fuzzMsg, fuzzResponse, responseTime.Milliseconds.ToString());


    //account for response sequence number



Modify Defines

Two global variables at the top of the program are used to define the starting order id number and the regex to detect sequence errors.  These will need to be modified for the individual environment.

Add new Fuzz Strings

A function getFuzzList() is used to generate the array of fuzz strings.  New test cases should be added to this section.

Extending Functionality

There are a number of ways to quickly modify the program to test beyond simple fuzzing.  In the past, just a few lines of code have been needed to perform automated authorization testing against all captured requests.  This was accomplished by only fuzzing the SenderCompID and using the function getFuzzList() to generate the list of other organizations.  In addition, fuzzing sequence numbers or sending numbers out of sync have yielded interesting results.  Modifying the sections of code that iterate sequence numbers can be used to test for these conditions in other systems.

Test Environment

One way to try Fizzer out is to leverage the QuickFix example applications located at the URL below.  Hint: try removing the message resend functionality as mentioned above.


Fuzzing FIX

FIX (Financial Information eXchange) is a transaction protocol we come across quite often when assessing trading systems, especially those which span multiple organizations. Having come across these systems a number of times, GDS opted to create a FIX specific assessment tool to enable us to more efficiently assess FIX based solutions.  The main idea was to create a tool which can be extended with new tests in order assess a variety of implementations. After cleaning up the code somewhat, we are now choosing to release this tool to the public. Although it only includes a relatively small number of the checks we perform on such an engagement, it should help provide a starting point for testing a wide variety of FIX receivers. 

When we get an opportunity, we will provide a more detailed walkthrough of using and extending the tool, however to leverage the tool in the meantime, record a FIX conversation between a client and receiver using a packet capture utility such as Wireshark or TCPDump.  Feed this capture file in to the tool, and the messages and a login request will be extracted to serve as a baseline for fuzzing.  The tool will issue a new login request for every message in order to help prevent one session from clouding another.  It also has the ability to keep track of (and automatically update) sequence numbers and respond to resend requests.  The source code can be found on our public Github page at