[Bro] weird behavior in binpac-generated analyzer

[Martin Szydlowski]

Hi all,

I am extending the BitTorrent analyzer (kudos to Nadi Sarrar) that has
finally made it into the 1.4.prerelease to handle messages beyond the
standard protocol. In particular, I am including the Azureus Messaging
protocol and there's where the trouble begins. When "switching" from
standard to azureus protocol, the analyzer consistently swallows the
first 4 bytes in the upflow direction. The downflow is unaffected and
the analysis works fine there and it does not matter if the first
message after the switch was upflow or downflow, it is always the first
upflow message that is affected.

The effect of the swallow is that the analyzer misses the 4-byte length
field and takes the first four bytes of the following string instead.
That produces a huge number that causes an out_of_bound exception and
stops the anaylsis for the upflow.

I did some debugging with gdb and found that FlowBuffer::NewMessage
in aux/binpac/lib/binpac_buffer.cc increases the orig_data_begin_
pointer by 4 when it is actually pointing at the correct spot. Either
the increment is wrong, or the data pointer is 4 bytes to far already, I
cannot tell.

I have only made changes to ,pac (and .bro) files, therefore all the
code is binpac-generated. As long as the network dumps do not contain
azureus traffic, my code does not get invoked, and the analysis runs
fine, therefore the fault must lie in my changes. However, since the
code for upflow and downflow is obviously identical and only upflow is
affected by this error, maybe my code triggers some obscure bug in
binpac or bro. Oh and BTW, I also tried disabling the connection
compressor, since in the past that caused trouble with localhost
connections (but that bug should be fixed by now).

I am attaching a diff of my changes (against SVN revision 6054).
The dumps I have been testing against can be found at
http://hades.seclab.tuwien.ac.at/msz/azu.dump and
http://hades.seclab.tuwien.ac.at/msz/azu2.dump (both ~30MB).
When using this dumps, you must use the -C flag since the tcp checksums
are invalid (as always when capturing traffic on the originating host).
(My invocation of bro is: $ bro -C -r xxx.dump bittorrent bt-tracker weird)

I hope someone can look at this and tell me what is going wrong.

greetz Martin


-------------- next part --------------
A non-text attachment was scrubbed...
Name: r6054v4.diff.zip
Type: application/x-zip-compressed
Size: 3270 bytes
Desc: not available
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080819/e7ee5e7b/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20080819/e7ee5e7b/attachment-0001.bin