Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Using Titan as a fuzzing engine part 1( Generalities )
Using Titan as a fuzzing engine part 1 [message #1758053] Thu, 23 March 2017 07:51
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member

According to Wikipedia, fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program.
In this post , we will use fuzzing to refer to network or protocol fuzzing, which is about sending forged packets to the tested application in
the hope that these packets wil trigger a software error.

Introduction of fuzzing capabilities to Titan was an organic evolution that went through several steps.
The first step was using controllable codecs , that is, codecs that are controlled by additional instructions decorating the TTCN-3 code
that tell the codec how the structures (abstract syntax) should be converted to bits on the wire (transfer syntax) and vice versa.
Based on these instructions, Titan will generate the encoding-decoding functions; all the user has to do is to declare them in order to be able refer them from the TTCN-3 code.
Typically codecs and the related instruction sets are not standardized, the only exception being XML.
Controllable codecs have been discussed in a number of previous posts and in Titan are available for: XML,JSON, TEXT(ascii) and RAW(binary).

See the simple example below:


module Frame {
//autogenerated codecs:
    external function enc_CX_frame( in CX_Frame cx_message ) return octetstring
        with { extension "prototype(convert) encode(RAW)" }

    external function dec_CX_frame( in octetstring stream ) return CX_Frame
        with { extension "prototype(convert) decode(RAW)" }

    type octetstring  OCT2 length(2) with { variant "FIELDLENGTH(2), BITORDER(msb)" };

    type record CX_Frame
    {
        OCT2            data_length,
        octetstring     data_stream
    } with 
	{ 
	variant "FIELDORDER(msb)" ;
	variant (data_length) "BITORDERINFIELD(msb)" ;
	variant (data_length) "LENGTHTO(data_stream)" ;	
	}

}  with { encode "RAW" }


template CX_Frame t_CX_Frame:=
    {
        data_length:=0,
        data_stream:='AAAABBCCDDEEFF1122'O
    } 

var octetstring v_os:= enc_CX_frame(valueof(t_CX_frame))

//Encoded:
//'09AAAABBCCDDEEFF1122'O



The "variant" instructions will tell Titan how the structure has to be encoded, respectively how the binary stream has to be decoded.

Correspondingly, we have the following messaging architecture:
 
+---------------------+         +---------------------+        +---------------------+
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|  Messaging logic    |         |  Codec(External     |        |                     |
|  (TTCN-3 & Titan)   +--------->  or auto-generated  +-------->     SUT             |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
+---------------------+         +---------------------+        +---------------------+



With this setup it's rather difficult to produce messages that are in violation of the encoding rules;
verifications take place on several levels: the structure (template or variable or constant) is verified
against the type on TTCN-3 level (compile or run-time) and again by the codec during encoding/decoding (run-time).

To permit illegal messages, the codec had to be modified. This was done by introducing a new feature (not covered by the TTCN-3 language standard) named
"negative testing"; this was also detailed in a previous post, and is also available for XML, JSON, TEXT(ascii) and RAW(binary), but for encoding direction only.
I hope the reasons for this are obvious.

In the example below:


template CX_Frame t_CX_Frame:=
    {
        data_length:=0,
        data_stream:='AAABBCCDDEEFF1122'O
    } with 
	{ 
	erroneous (data_length)  "after(raw) := 'FF'O ";
	erroneous (data_length)  "value(raw) := 'AABBCC'O ";
    erroneous (data_length)  "before(raw) := 'FF'O ";
 	}
	
//Encoded:
//'FFAABBCCFFAAABBCCDDEEFF112'O


the "erroneous" instructions will tell the codec to forget about the encoding rules and
replace the targeted field with a constant or literal value, or add a value in front or after it.

Theoretically this fulfills the condition of sending illegal values, but in practice suffers from a number of disadvantages:
for each errored message a new template has to be written; input can be taken only from constants and literals.
As a consequence this feature is rather static and awkward to use.

The next evolutionary step, added only a couple of weeks ago to the github repo ( and to be made available in the next, post 6.1.0 release of Titan) , was aiming to make negative testing more dynamic and easy to use.

First of all, it does not require a full template; it refers to an existing template of whose erroneous instructions intends to overwrite:


@update(t_CX_Frame) with 
	{ 
	erroneous (data_length) "after(raw) := 'AA'O ";
	erroneous (data_length) "value(raw) := f_someFunction()";
   	erroneous (data_length) "before(raw) := 'BB'O ";
 	}


As it can be seen , instead of constants/literals, it can take its' input form variables and functions.

It can be used to omit mandatory parameters:


@update(t_CX_Frame) with 
	{ 
	erroneous (data_length) "value := omit";
	}


An empty instruction will reset the "erroneous" instructions:

@update(t_CX_Frame)   


The function or external function used can have a number of "out" or "inout" parameters, so the whole fuzzing logic can be implemented in such form, for example:


function f_twoOutParams(in integer p_i, out octetstring p_os1, out octetstring p_os2) return integer
	{
	p_os1:=int2oct(p_i,2);
	p_os2:='AABB'O
	return 1
	}
:
:
var octetstring v_os1, v_os2;
:
:

f_twoOutParams(1,v_os1,v_os2);  

@update(t_connect)
with {
	erroneous (msg.connect_msg.nameLength)   "value(raw) := v_os1";
	erroneous (msg.connect_msg.name)         "value(raw) := v_os2";
	}



The @update instruction does not work on variables derived from templates:

var CX_Frame v_CX_frame :=valueof(t_F_connect)
@update(t_F_connect) with { ..... } has no effect on the subsequent encoding of v_CX_frame
enc_CX_frame(v_CX_frame) will not take into account the "erroneous" instructions  



This form of negative testing is available for XML,JSON, TEXT(ascii) and RAW(binary), encoding direction only.

About 80% of Titan protocol modules have been implemented with controllable codecs, hence can be subjected to fuzzing.
A small part is implemented with handwritten codecs for different reasons (codec limitations, speed etc.);
for these, the encoding direction has to be implemented with a controllable codec.


For protocol modules based on controllable codecs, the following messaging architecture
can be drawn:


+---------------------+         +---------------------+        +---------------------+
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|  Messaging logic    |         |                     |        |                     |
|  (TTCN-3 & Titan)   +--------->       Codec         +-------->     SUT             |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
|                     |         |                     |        |                     |
+---------------------+         +----------+----------+        +---------------------+
                                           ^
                                           |
                                           |
+---------------------+                    |
|                     |                    |
|                     |                    |
|                     |                    |
|                     |                    |
|   Fuzzing logic     +--------------------+
|   (TTCN-3 or        |
|   external)         |
|                     |
|                     |
+---------------------+


In case of protocol modules with handwritten external codecs, the encoding will be done with a controllable codec , while the decoding
with the legacy codec; we will need two protocol modules in parallel:

+---------------------+         +---------------------+        +---------------------+
|                     |         |                     |        |                     |
|                     |         |        Decode       |        |                     |
|                     |         |   +-------------+   |        |                     |
|  Messaging logic    |         |   |             ^   |        |                     |
|  (TTCN-3 & Titan)   +----------<--+   Codec     +----<------->     SUT             |
|                     |         |   |             ^   |        |                     |
|                     |         |   +------+------+   |        |                     |
|                     |         |          ^ Encode   |        |                     |
|                     |         |          |          |        |                     |
+---------------------+         +---------------------+        +---------------------+
                                           |
                                           |
                                           |
+---------------------+                    |
|                     |                    |
|                     |                    |
|                     |                    |
|                     |                    |
|   Fuzzing logic     +--------------------+
|   (TTCN-3 or        |
|   external)         |
|                     |
|                     |
+---------------------+




Practical examples will follow.


Note: Both forms of negative testing are available only in the function test run-time mode (RT2) of Titan, which means that compilation has to be done with the -R compiler switch.



Best regards

Elemer


Previous Topic:Help Needed on Sample Test Project using TITAN
Next Topic:oneM2MTester presented at M-to-M Embedded Systems Show
Goto Forum:
  


Current Time: Fri Mar 29 05:52:50 GMT 2024

Powered by FUDForum. Page generated in 0.03945 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top