Other parser in Analyzer (LFF, STT, MAC)


There are other parser used by Analyzer. Most of the way they work are shared with the protocol parsers (interaction with Query and so on). Following there is a brief description of these components.

 

Definition of the dumpfile format (LFF: Log File Format)

There are several program for network analysis and capture, each one with its proprietary dumpfile. LFF files are used to describe the format of each dumpfile in ordr to allow to import files created with different programs. Even if LFF is a generic description format that can be used to import and export files, Analyzer does not allow exporting files with different formats; only importing is permitted.

Each dumpfile format that has to be interpreted needs its own LFF file that is interpreted by a specified parser in order to create an object (.LFO) file. This object is executed by Query in order to make the read file "compatible" with the Query native format (that is .ACP). This parser is case insensitive.

This parser can be launched either by Analyzer or manually:

fdreader INPUT.LFF OUTPUTFILE.LFO

The LFF file structure is based on the characteristics which are common to each possible format of a capture file:

On the base given by these characteristics here it is the LFF structure which defines the format of the capture file:

The definition of the fields in the LFF files follows these rules: a field definition is composed by a name and a type. The name is composed by a letter (or the char '_') followed by less then 50 alphanumerical characters.

The characters can be defined as:

The BYTE and the WORD are interpreted as sign-less integer and their highest values are: 255 and 65535. The DWORD are interpreted as integer with sign on 4 bytes. Their range is (-2147483648 , 2147483647).

The name of the expressions  have to be defined in the structure which precedes the expression.

Here it is, as example, the LLF file which defines the ACP format:

1:  HEADER
2:	DWORD Magic
3:	WORD MajorVer
4:	WORD MinorVer
5:	DWORD thiszone
6:	DWORD snaplen
7:	DWORD sigfigs
8:	DWORD caplinktype
9:  ENDHH
10:	MUSTINVERT : (Magic!=0xa1b2c3d4)
11:	LINKTYPE : caplinktype

12: PHEADER
13:	DWORD Secs
14:	DWORD USecs
15:	DWORD PckLen
16:	DWORD TLen
17: ENDPH
18:	PLEN:PckLen
19:	LEN:TLen
20:	TYPE:128
21	CHECK:1
22:	FIRSTPROTOCOL:"MAC"
23:
24: PTRAILER
25: ENDPT

26: TRAILER
27: ENDHT

In the rows (1->10) there is the header file definition. An header file starts with the keyword 'HEADER'. Then there is a series of fields definitions. The fields definition ends with key word 'ENDHH' (look at the row 10, END Header Head).

Then there is the key word 'MUSTINVERT'; if this expression returns a value different from 0 when it is tested then all the integer are read in the opposite direction. For instance the hexadecimal integer 0xa1b2c3d4 becomes 0xd4c3b2a1. In the next row there is the key word 'LINKTYPE followed by the char ':' and by a valid expression. The expression caplinktype indicates the network type from which the packets were captured; the expression returns a value defined link type identifier in the ACP format.

Rows (12->25) define a possible packet type. We can find more then one definition like this in the same file. So the LFF file defines all the elements which belongs a format. For instance in the LOG file there are five elements types.

A packet header starts with the key word 'PHEADER'. Then there is a series of fields definitions. The fields definition ends with the keyword 'ENDPH' (END Packet Head). Then there are some compulsory clauses and some optional clauses. It is very important to respect a particular order in clauses declaration. The obligatory clauses are composed by a key word and by the char ':'; here it is the list of the valid key words (the order in the list is also the order of the declaration):

The first four clauses are followed by a valid expression while the last clause is followed by a string. The clause PLEN (Packet LENgth) indicate the packet length which is present on the disk. LEN (LENgth) indicates the real length of the packet. TYPE returns an integer which indicates the type of the packet. The most important clauses are CHECK and FIRSTPROTOCOL. This last clause allows to establish from which protocol the packet analysis will start. CHECK is used to determine which is the type of the element.

The optional clauses as the obligatory clauses are composed by a key word, by the char ':' and by a valid expression; here it is the list of the optional clauses:

Also these clauses have to be declared in the order specified by the list, but you can introduce in the file the clauses that you want.

SECS allows to set the second number of the timestamp; USECS allows to set the microsecond number of the timestamp. If these clauses are not set the timestamp value is equal to the last set value. WRITTEN allows to set the number of the packets written since the last statistics report. DISCARDED allows to set the number of lost packets since the last notification.

A packet trailer starts with the keyword 'PTRAILER'. Then there is a series of fields definitions. The fields definition ends with the keyword 'ENDPH'.

In the rows 27 - 28 there is the definition of the final string of the file. A final string starts with the keyword 'TRAILER'. Then there is a series of fields definition; this series ends with 'ENDHT'.

You can have more information about LFF format looking at:


Statistics files (STT: STaTistics files)

The statistics files are used by the analysis engine to evaluate statistics on capture files. They usually have the extension STT (STaTistics). They describe the statistics which have to be evaluated.

These files, which are text files, need empty row in order to separate the different sections. STT is case sensitive except for the part involving protocols fields / protocol names.

Here is an exmple of an STT file.

UseSemigraphicCharacters=no
ReportFrameCount=yes
ReportFrameRate=yes
ReportFramePercentage=yes
ReportByteCount=yes
ReportByteRate=yes
ReportBytePercentage=yes
ReportFrameSize=yes
ReportTotals=yes
ReportAverages=yes
ReportMaximums=yes
ReportMinimums=yes
ReportExtremeFramesizes=yes
ReportJustFinal=no

LengthOfInterval= 0 0 5
ExcludedFrames=GetVMVar ("FrameSize")=CantTell
DefaultLengthParameter=GetVMVar ("FrameSize")

GroupName=Broadcast_MAC
OutCap=
Predicate=MAC.DS1==0xFFFF && MAC.DS2==0xFFFF && MAC.DS3==0xFFFF
LengthParameter=GetVMVar ("FrameSize")
(...)

The first section contains a list of keywords which are set with 'yes' or 'no' in order to decide which parameters values have to be reported in the results table. The key words order is fixed and all the key words have to be written. The lines and the blank spaces are ignored; the comment lines start with the char ';' (see the beginning of a STT file). The lines can be at most 120 characters long.

The next section contains:

The next section defines a group, that is basically a filter applied to the input files. User can define several filters (for example "UDP", "TCP") in order to calculate the statistics separately on each subset of the packets. Results will be printed in such a way that these groups can be compared to each others. This sample contains only a group definition but an STT file can contain more then one group.

The expressions are created using the protocols definition saved in the PDF file. The expressions returns a non valid value (a CANTTELL value) if its evaluation is not possible, it returns a zero value (FALSE) if the evaluated packet does not satisfy the expression. A value different from 0 means "TRUE": the packet satisfies the expression. A frame group contains all the packets whose evaluation returned a 'TRUE' value.

The frame size can be calculated using different criteria; for instance the 'LengthParameter' can be set in order to consider only the IP section using the expression 'GetDataLen(IP)'.

The evaluation of percentages requires a total counter which consider the all the frames; if a group is not able to calculate a frame length then a default value is set (DefaultLengthParameter).

For further information look at:


Macro files

These files allows launching by one only command the execution of an analysis engine functions series. The functions series has to be written in the MAC file, then this file has to be compiled (through the dreader parser) in order to create the relative object file (the MO file); then this file is interpreted and executed by the Analysis engine. The MAC file is a normal text file, it does not need end row characters and its parser is not case sensitive. This parser is the same that compiles DFF and IFF files. The packets information contained in their fields are not available from the MAC file because this file is only relative to the Analysis engine management. Besides are not valid the functions calls: GetVmVar, 'CHECK', 'CONV', 'CONV16', 'CONV24', 'CONV32'.

Though the function 'COMMAND' it is possible sending commands to the Analysis engine as if they came from the keyboard; the function syntax is the following one:

COMMAND '(' STRING ')'

'STRING' is common characters string in inverted commas ("command name"); it should represent the name of a valid command. If the string is not recognized as a valid command the function 'COMMAND' returns a value different from 0 (else 0 if it is valid). The macro execution starts from the function 'MACROMAIN', whose prototype is:

DWORD MacroMain ();

This function must be present. It returns a value different from 0 if there are errors during the execution. It can call the other functions of the macro file.

About the file format look at the grammar.