[Bro] Syntax Question - Nested Switch Case

[Jon Siwek]

On Sun, Oct 28, 2018 at 10:41 PM TQ <nothinrandom at gmail.com> wrote:

> type HeaderCmd(cmd: uint16) = case cmd of {
>   DEVICE_CMD2_1  -> info1: Record_A;
>   DEVICE_CMD2_2  -> info2: Record_B;
> };
>
> type Record_A = record {
> title: uint16;
> author: uint32;
> text: uint64;
> ending: uint8;
> }
>
> type Record_B = record {
> title: uint16;
> author: uint32;
> text: uint64;
> ending: uint8;
> }
>
> Based on the ending for each Record, I'd switch to another set. Would I set it up like Device_Response from above if Record_A and Record_B share some data before the switch occurs?

It's up to you, but if Record_{A,B} share a common format, you might
change HeaderCmd to be a record that contains the common fields plus
an extra switch.  Something like:

type HeaderCmd(cmd: uint16) = record {
  title: uint16;
  author: uint32;
  text: uint64;
  ending: uint8;
  endcmd: case ending of {
    ...
  };
};

> All of the above is under protocol.pac. How would one access information from analyzer.pac?

You can see most analyzers in the Bro source tree for examples, but a
typical pattern is refining the type to add some post-processing
function.  e.g.:

refine connection My_Conn += {
  function proc_header_cmd(rec: HeaderCmd): bool
    %{
    // Add your code here
    return true;
    %}
};

refine typeattr HeaderCmd += &let {
  proc: bool = $context.connection.proc_header_cmd(this);
};

There's nothing special about the filenames -analyzer.pac vs.
-protocol.pac, you can access the same type definitions wherever as
long as the %include setup is correct, but the convention that Bro
tends to use is to put protocol parsing logic in -protocol.pac and
additional protocol analysis/validation logic in -analyzer.pac.

- Jon