[Bro] FW: binpac related question

[Ruoming Pang]

Hi Laurentiu,
Is the padding always at the end? If so, you can use:

padding: bytestring &restofdata;

Ruoming

2008/12/1 Cucos, Laurentiu <Laurentiu.Cucos at compuware.com>

>  Hi All,
>
> Tying to use binpac to create a new protocol analyzer I run into a small
> issue relative to byte alignment. I am thinking this must be a known aspect
> however I didn't find much documentation about it.
>
> Padding in binpac works well inside the packet. However, sometime the
> packet ends with a structure that requires padding but the packet doesn't
> carry the extra bytes for the padding. As a result binpac fires an exception
> and the parsing is terminated before extracting the data.
>
> Here is a sample code:
> type ByteArray = record{
>         len : uint32;
>         data: uint8[len];
>         pad : padding align 4;
> };
>
> When the last 6 bytes of a packet that ends with the above record is: 00 00
> 00 02  AA BB    (with: len=00 00 00 02; data ={AA, BB}) binpac throws:
>
> 0.000000 binpac exception: binpac exception: out_of_bound: ByteArray: 8 > 6
>
> Removing the padding entry from the code above results in a correct
> execution, however the padding is needed for the case when ByteArray is
> strictly inside the packet.
>
> The solution I am thinking is way too complex (pass some arguments that
> will help decide if the padding is needed), but I was wondering if there is
> a much more elegant approach.
>
> Another option will be to change the binpac compiler code (pac_record.cc)
> in method: void RecordPaddingField::GenFieldEnd(Output* out_cc, Env* env,
> const DataPtr& field_begin) but I am thinking this case should be covered in
> a different way.
>
> Any suggestions would be greatly appreciated.
>
> Thank you,
> Laurentiu Cucos
>
>
>  The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or disclose
> it to anyone else. If you received it in error please notify us immediately
> and then destroy it.
>
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20081201/2a774378/attachment.html