[Bro] FW: binpac related question

Cucos, Laurentiu Laurentiu.Cucos at compuware.com
Tue Dec 2 10:09:13 PST 2008


Hi Ruoming,
 
Thanks for the answer. First, I would like to say how impressed I am
with binpac capabilities and the approach used. Once I had a test
environment setup and went over the samples and documentation, I was
able to develop a fairly extensive decoder for a relatively complex
protocol (IIOP) in just a day or so (took longer to go over the protocol
specs).
 
 
Regarding the issue in question, the padding is not always at the end.
Depending on some protocol data (i.e. version), the ByteArray record can
be either in mid packet or at the end. 
The things are complicated by the fact that this record is part of other
records (that ultimately depend on version) - and I would not like to
duplicate records with every version. 
 
 
As of now I found a solution by changing:  pac_record.cc:
 
 void RecordPaddingField::GenFieldEnd(Output* out_cc, Env* env, const
DataPtr& field_begin)
.............
case PAD_TO_NEXT_WORD:
.....
// new code: disable the padding if exceeds the packet size (not sure
about all implications)
   out_cc->println("%s = (%s == 0 || (%s + %s > %s)) ? 0 : %d - %s;",
     padding_var,
     padding_var,
     padding_var,
     field_begin.ptr_expr(),
     env->RValue(end_of_data),
     wordsize_,
     padding_var);
 
// original code:
   // out_cc->println("%s = (%s == 0) ? 0 : %d - %s;",
   // padding_var,
   // padding_var,
   // wordsize_,
   // padding_var);
 
Any feedback will be highly appreciated.
 
Thank you,
Laurentiu
 

________________________________

From: ruoming at gmail.com [mailto:ruoming at gmail.com] On Behalf Of Ruoming
Pang
Sent: Monday, December 01, 2008 9:03 PM
To: Cucos, Laurentiu
Cc: Bro at bro-ids.org
Subject: Re: [Bro] FW: binpac related question


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/20081202/f9bf9e42/attachment.html 


More information about the Bro mailing list