Aprobación de los estados fi nancieros

We previously explained that a field can accept multiple values and that a value can be made of different tokens. To model these tokens, we attach to each field a token-tree. This token-tree models the definition domain of its field, i.e. the set of values it accepts. A token-tree is an ordered, rooted tree that represents the syntactic structure of tokens that are accepted by its field. It follows a n-ary right-branching structure [15] that grows downward and proceeds left to right. Similarly to a Constituency-based parse tree [], a token-tree distinguishes between non-terminal and terminal nodes. A non-terminal node is a node that has one or more children nodes, either non-terminal or terminal ones. A terminal node is a node that has no children and can be seen as a leaf of the tree. Besides, nodes in a token-tree are labeled. Terminal nodes are either labeled with static or

dynamictokens while non-terminal nodes are either labeled as aggregates, alternates or repeats

nodes. We detail these labels in the following and illustrate them by means of examples including sample usages of Netzob.

Definitions of Terminal Nodes accepted by a Token-Tree

A static token (e.g. a magic number in a protocol header) labels non-terminal nodes. It represents a single constant value. To model a field which accepts a single constant value, we attach to it a token-tree that contains a single terminal node labeled with a static token. For example, listing 5.2 illustrates the token-tree of a field f0 that is made of a unique terminal node labeled with a static token which value is “helloworld”.

>>> # defines f0, a field which only accepts "helloworld" >>> f0 = Field("helloword")

Listing 5.2– Example of a static token

A dynamic token (e.g. the username field in the IRC protocol) represents a set of values that share the same type and the same size range. Thus, a dynamic token is described with a type and a size. We support various token types such as ASCII, decimal, IPv4, raw byte or bit array. We use a range to describe the minimum and the maximum size in bits of the values a dynamic token accepts. For example, Listing 5.3 represents two field f0 and f1. The former accepts any sequence of four bytes while f1 accepts any string of ten to twenty ASCII chars.

>>> # f0 is a field that accepts any sequence of 4 bytes >>> f0 = Field(Raw(nbBytes=4))

>>> # f1 is a field that accepts any ASCII string of 10 to 20 chars >>> f1 = Field(ASCII(nbChars=(10,20)))

Listing 5.3– Example of a dynamic token

Besides its size and its type, an additional constraint can be added to the definition of a dynamic token. This constraint can be use to model a relationship between its value and the value or the size of one or more other fields. Our model accepts three types of relationships: 1) intra-symbol

relationship, 2) inter-symbol relationship and 3) environmental relationship.

An intra-symbol relationship describes a relationship between a token and one or more fields that participate in the same symbol. For example, such relationship can be use to model a CRC32 field. To represent this constraint, we use a function taking as parameter some fields of the same symbol. Based on our observation of common protocols, we identified two recurrent functions:

1) size : F∗

→ N a function that returns the size in bits of one or more consecutive fields and 2)

value : F∗→ B a function that returns the value of one or more fields. B represents all the possible

sequence of bits b ∈ Σ∗

0,1 and Σ0,1 = {0, 1}. These functions can be combined with common

mathematical operations to define, for example, that a field contains the CRC32 of another field. Listing 5.4 shows the specification of an intra-symbol relationship in Netzob.

>>> # f1 is a dynamic variable-size field of 0 to 30 chars. >>> f1 = Field(ASCII(nbChars=(0,30)))

>>> # f0 is a dynamic fixed-size field which value is the size of f1 >>> f0 = Field(Size([f1], nbBytes=2))

>>> s = Symbol(fields=[f0, f1])

Listing 5.4– Example of an intra-symbol relationship

An inter-symbol relationship describes a relationship between a token and one or more fields that belong to a previous symbol transmitted during the same session. For example, such relationship exists in the TCP protocol to define the value of an acknowledgment number. We use the same functions than for intra-symbol relationship but specify as parameters fields of other symbols. Listing 5.5 illustrates the specification of an inter-symbol dependency in Netzob.

>>> # f1 is a dynamic variable-size field of 0 to 30 chars. >>> f1 = Field(ASCII(nbChars=(0,30)))

>>> s1 = Symbol(fields=[f1])

>>> # f0 is a dynamic fixed-size field which value is the size of f1 >>> f0 = Field(Size(f1, dataType=Raw(nbBytes=2)))

>>> s0 = Symbol(fields=[f0])

Listing 5.5– Example of an inter-symbol relationship

Finally, the values of a dynamic token can also be constrained by an environmental relationship. Such relationship specifies that the value of a token depends on an environmental property such as the current IP source, the date or the hostname. Similarly to inter and intra symbol relationships, an environmental relationship is represented by a function Env : E → B that takes as parameter the name of an environment property, e ∈ E. For example, Listing 5.6 illustrates a field that takes as value the current hostname of the system.

>>> # f0 is a dynamic variable-size field that contains the message author hostname

>>> f0 = Field(Env("hostname"))

Listing 5.6– Example of an environmental relationship

Definitions of Non-Terminal Nodes accepted by a Token-Tree

Multiple static and dynamic tokens can be combined to form a complex and precise specification of the values that are accepted by a field. A combination is modeled by non-terminal nodes in the token-tree of a field. We propose the use of three different combinations: 1) aggregate, 2) alternate and 3) repeat. We detail them in the following.

An aggregate node concatenates the values that are accepted by its children nodes. It can be use to specify a succession of tokens. For example, Listing 5.7 represents a field which accepts values that are made of an ASCII of 3 to 20 random characters followed by a “.txt” extension.

>>> # Specifies a field made of two aggregated tokens >>> t1 = ASCII(nbChars=(3,20))

>>> t2 = ASCII(".txt")

Listing 5.7– Example of a field which definition domain is an aggregation of two tokens

Tokens can also be combined under an alternative form. This combination is represented by an alternate node. It can be seen as an OR operator between two or more children nodes. For example, listing 5.8 denotes a field accepts either “filename1.txt” or “filename2.txt”.

>>> # Specifies a field made of two alternate tokens >>> t1 = ASCII("filename1.txt")

>>> t2 = ASCII("filename2.txt") >>> f = Field(Alt([t1, t2]))

Listing 5.8– Example of a field which definition domain is an alternate of two tokens

Lastly, a field can also be defined under a repetition form of one or multiple tokens with a

repeatnon-terminal node. It denotes an n-time repetition of a terminal or a non-terminal node. For

instance, we can use this operation to specify a field which token-tree accepts a repetition of n IPv4 addresses where n is the value of another field. Listing 5.10 shows such symbol made of two fields, the former contains the number of IPv4 addresses that are declared in the second field. The repeat operator is used to represent a dynamic number of IPv4 tokens in a single field.

>>> f1 = Field(Decimal(interval=(1,5)))

>>> f2 = Field(Repeat(IPv4(), nbRepeat=value(f1)))

>>> # Creation of a symbol composed of these two fields >>> s = Symbol(fields=[f1, f2])

Listing 5.9– Example of a field which definition domain is a repetition of IPv4 addresses

In this Section, we presented how we specify a symbol, its fields and the grammatical repre- sentation of the values they accept. In the following, we detail the process we use to verify that a message is valid according to the definition of a symbol. We refer to this process as the abstraction. We also explain how we specialize a symbol to generate valid messages according to its definition.