[Bro] FW: binpac related question

Ruoming Pang rpang at cs.princeton.edu
Mon Dec 1 18:02:45 PST 2008

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

padding: bytestring &restofdata;


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 

More information about the Bro mailing list