Global array in context?

Zeek
1

Hi,

I’m trying to develop an application level analyzer.

My protocol has a request/response architectutrte, and the request/response message structure depends on a Function Code.

This Function Code is sent in the request message, but NOT in the response message.

So, when I receive a response I don’t know if it belongs to the request A or the request B.

The only way to know that is checking the transport level ID.

So, I need to maintain any kind of array that relate transport id values and function codes.

My question is how to do that.

I need to read and write that global value in the MyProt-protocol.pac file. But I don’t know how to maintain a global variable in binpac.

I’ve been trying to do it within the $context, but I don’t know how to write a value in a type added to the context.

Any idea?

Thank you!

2

Hi all,

I will repond to myself.

I finally got it to work modifying the connection class and adding the array:

refine connection UmasTCP_Conn += {
%member{
int previous_fcs[256];
%}
};

Adding a RESPONSE type that call to a function to recover the FC data from the array:

type XXX{

(…)
} &let {
(…)
ufc: uint8 = $context.connection.get_Previous_FC(header.Transport_id);
};

And writing two functions in the analyzer.pac file:

refine connection MyProtTCP_Conn += {
(…)

function get_Previous_FC(Transport_id: int): int
%{
return previous_fcs[tid%256];
%}

function SetTID_FC(transport_id:int, ufc:int): bool
%{
previous_fcs[transport_id%256]=ufc;

return true;
%}

The second one is called every time a message event is detected:

function deliver_message(header: BinPAC_TCP_Header, MYPROTheader: BinPAC_MYPROT_header): bool
%{
if ( ::MyProt_message )
{
connection()->SetTID_FC(${header.transport_id}, ${MYPROTheader.myprot_fc});

Works fine.

Thanks anyway!

3

Sorry for not responding previously but I'm glad to hear that you figured out how to get it working!

I do have one design question though (and there is no right answer), are you just taking these function codes and passing them directly into events to be given into script-land? Typically the only case where I collect state in the core like you're doing is when I need that information to continue parsing messages which I believe is probably the case you are in, but you didn't give enough snippets of code to show if that's true.

If you lean toward only collecting state in the analyzer when absolutely necessary and otherwise collecting all state in scripts, it frequently makes pushing things forward more flexible because it's typically much easier and faster to collect and expunge state in scripts that it is in the core.

Congratulations on working out your own problem, I know it can be really painful sometimes. :slight_smile:

  .Seth