State Machine with boofuzz

[TwoBottomBuns]

Is it possible to manage nodes with a state machine? Suppose I want to fuzz a stateful network protocol (such as TLS), and would need to keep track of certain pieces for different parts of the protocol. I would need to keep track of things like the handshake hash, the negotiated ciphersuite, keys, etc. in order to send valid packets and handshake messages while fuzzing.

Based on examples and documentation, it seems like the default values defined when constructing blocks and primitives are intended to be used for all cases in which that block is not currently being fuzzed. But when building a block for a Finished message (in which the client sends an encrypted payload), it would be impossible to construct a valid payload without having the contents from the ClientHello and ServerHello.

Is there an efficient way to manage a state machine with boofuzz that can track all of these necessary parameters and then dynamically populate blocks with the values? I was looking at the s_update() function to do this, but I saw in another issue how it intentionally doesn't work with the s_string primitive. I also saw mention that s_update may be removed for the future.

[SR4ven]

Apologies for the long delay.

Stateful fuzzing is not fully implemented in boofuzz but there are some helpers you could use.
The most useful ones will be the callback functions pre_send, post_send and the ones for nodes. Pre- and post_send callbacks can be set as Session arguments.
The callbacks are called in the following order:
pre_send - req - node_callback ... req - node_callback - post-test-case-callback

Inside of those callbacks you have access to all of the blocks and primitives of the node and their values, which you can also overwrite to construct a valid packet. Check #368 but I'm not sure about how manipulating values affects dynamic primitives like s_size and s_checksum.
Accessing the latest received data is possible with session.last_recv.

In case you only want to fuzz the payload there is a second option. You could write a dedicated connection class that handles all the stateful stuff. The SSLSocketConnection class basically does this, but it uses external libraries for it.
If that's the way to go, make sure that you install boofuzz from the current master branch, as the latest version on pypi doesn't include those classes.

Either way, it would be interesting to see the outcome if you find a solution.
Feel free to open a PR or post an example here. I'm sure that this would help others too.

[jtpereyda]

Thanks for the question @TwoBottomBuns ! @SR4ven hit the nail on the head. Right now the way to handle a state machine would be to use the various callback methods and modify your own state machine / object as necessary. If anybody has any ideas for how boofuzz could make this easier, feel free to share. The main challenge is that every protocol's state machine will be unique.

s_size and s_checksum render pretty late and should accept any modified values.

[dorpvom]

Hi,
I just ran into the same question. I'll post my solution, which is likely not ideal yet. Maybe @SR4ven or @jtpereyda have input to optimize this:

def define_third_handshake_packet():
    s_initialize('ThirdPacket')

    with s_block('header'):
        s_bytes(b'foo', name='bar')

    with s_block('body'):
        s_dword(0, name='secure channel id', fuzzable=False)  # will be overwritten
        s_dword(4, name='secure token id', fuzzable=False)  # will be overwritten
        s_dword(2, name='secure sequence number', fuzzable=False)  # will be overwritten
        s_dword(2, name='secure request id', fuzzable=False)  # will be overwritten

[...]

def set_channel_parameters(target, fuzz_data_logger, session, node, *args, **kwargs):  # pylint: disable=protected-access
    '''
    1. Unpacking values at [8:12], [12:16] and so on in the received packet.
    1a. Using length fields to account for variable length header content
    1b. Handling struct.error for empty response
    2. Directly setting _value of next node. Replacing node breaks the fuzzing process
    '''
    try:
        recv = session.last_recv  # last received packet

        # Lots of magic numbers, all are protocol specific
        channel_id, policy_len = struct.unpack('ii', recv[8:16])
        sequence_offset = 24 + policy_len
        seq_num, req_id = struct.unpack('ii', recv[sequence_offset:sequence_offset + 8])

        request_header_length = 24
        token_offset = sequence_offset + 8 + request_header_length + 4
        sec_channel_id, token_id = struct.unpack('ii', recv[token_offset:token_offset + 8])
    except struct.error:
        fuzz_data_logger.log_error('Could not unpack channel parameters for this test case')
    else:
        node.stack[1].stack[0]._value = sec_channel_id
        node.stack[1].stack[1]._value = token_id
        node.stack[1].stack[2]._value = seq_num + 1
        node.stack[1].stack[3]._value = req_id + 1

[...]

def main():
    [...]
    session.connect(s_get('FirstPacket'))
    session.connect(s_get('FirstPacket'), s_get('ThirdPacket'), callback=set_channel_parameters)

    session.fuzz()

[SR4ven]

Thanks for sharing your solution @dorpvom!

[solimand]

Hi there, I would reopen this issue if it is possible and reasonable.

I am trying to use a callback to read a value from a node and pass it to the next node (as @dorpvom suggested)

The message that I want to modify:

def my_msg():
        s_initialize(Close)
        with s_block(block0):
            ...
        with s_block(c-body):
            s_dword(1, name='secure channel id', fuzzable=False) #value I want overwrite

So I want to overwrite the primitive Close.c-body.secure channel id

The callback signature is def my_callback(target, fuzz_data_logger, session, node, *_, **__)

The session graph is

session.connect(s_get(mymsg0))
session.connect(s_get(mymsg0), s_get(mymsg1))
session.connect(s_get(mymsg1), s_get(Close), callback=my_callback)

The reading of the response is ok, I get a correct 'myVal' from response to prev msg.
But these writes fail (in the sense that the next node is not set accordingly):
node.names['Close.c-body.secure channel id'] = myVal
OR
node.stack[1].stack[0]._value = myVal # (stack[1].stack[0] is the correct index)

Notice that the following prints (inside the callback) gave me the right value of the field I want to overwrite:

print("sec ch from node names " + str(node.names['Close.c-body.secure channel id']))
print("sec ch from session " + str(session.nodes[3].names['Close.c-body.secure channel id']))

The only write that works is:
node.stack[1].stack[0]._default_value = myVal

How I solved my problem:
-I printed all variables of the field I want to overwrite and I found that the default_value is the only one used in the next node transmission (actually there is no '_value' field in the 's_dword' primitive, it is created only if I use the writing method 'node.stack[1].stack[0]._value = myVal')
print("all values of -sec ch id- primitive " + str(pprint(vars(node.stack[1].stack[0]))))

My question is:
-I successfully reach my goal of overwriting values of the 'next' node BUT
-is this a weird solution?
-could it lead to a bad situation during the fuzzing?
-is there another way for overwriting primitive values for the next node?

[cq674350529]

I used to do the same thing in an ooolder version of boofuzz like node.names['Close.c-body.secure channel id']._value = myVal. And after setting the value, it's necessary to call node.render() to make it work.

Maybe you can have a try. I'm not sure if it changes in the latest version.

[solimand]

Thanks for the answer @cq674350529. I tried the render() method, but from the docs, it seems to be a method of Fuzzable, and the type of the node is boofuzz.blocks.request.Request.
I tried:
node.names['Close.c-body.secure channel id']._value = myVal
OR
node.names['Close.c-body.secure channel id'] = myVal
AND
node.render()
but it does not work. The value of the next node is not set accordingly.

Also the type of node.names['Close.c-body.secure channel id'] in my case is an int (I used the s_dword primitive for that field), so render() method is not applicable.

The only thing to try after modifying the next node with node.names['Close.c-body.secure channel id']._default_value = myVal OR node.stack[1].stack[0]._default_value = myVal (both work) is if the field has an unwanted value during the next fuzzing cases. But for this, I need more time because the tests last a lot.

Thanks again, all your suggestions are welcome.

[cq674350529]

@solimand I had a look at the boofuzz code of latest version. Some apis have been changed. I though the method you provide (changing the _default_value) can achieve your goal (I did a simple test).

The only thing to try after modifying the next node with node.names['Close.c-body.secure channel id']._default_value = myVal OR node.stack[1].stack[0]._default_value = myVal (both work) is if the field has an unwanted value during the next fuzzing cases. But for this, I need more time because the tests last a lot.

I may not understand what's your point.

[solimand]

@cq674350529 the only doubt is: could the overwriting of the _default_value (instead of the _value) lead to unwanted situations? In my case, I want always the overwriting of these fields, so my solution is ok, but for other protocols, someone could want the original default value set in the message definition, during the fuzzing of the other fields. So I don't know if mine could be a general solution for challenge/response protocols.

Anyway, the solution provided by @dorpvom is not more valid, so I commented on this post with my experience in this regard.

[SR4ven]

Sorry for the delayed answer @solimand.

Overwriting the _default_value should work fine in most cases where the node/primitive which is being overwritten is not fuzzed (e.g s_static or arg fuzzable=false). In that case it will always use the _default_value when being rendered.
BTW node.render() won't work from boofuzz v0.3.0 on because we use generators to get the fuzzed data.

If one tries to overwrite a fuzzable primitive, overwriting _default_value will most likely not work for test cases where this primitive is currently being mutated. The exact behavior needs to be tested.

[solimand]

thank you for the replay @SR4ven, and no need to apologize at all, it was not a critical situation :)

In my case, I want always the overwriting of fields for which I modified the _default_value, so this is not a problem. Maybe a specific field for this purpose could be implemented, in order to have the possibility of overwriting both the _default_value and the _current_value (the value of that field for the current run).

[SR4ven]

One option would be to make _default_value public and document the ability to use it to modify a primitives value while it's not fuzzed.
I guess that wasn't the original idea behind it, but many have asked about this. What do you think @jtpereyda?

About a "_current_vaule", that was called _value prior to v0.3.0. We removed it in favor of generators for primitives. I also don't really see the point of it, either you have a (dynamic) default value or you fuzz the primitive in which case you don't need to modify it's value. Am I missing a point here?

[solimand]

I didn't use the old version, but yes, I agree with you, making _default_value public and documented could be enough for the purpose.