<div dir="ltr">Hi Martin,<br><br>I can help you look at the issue. The first thing to do is to extract the exact connection that causes the problem and use tcpdump to extract a dump that only contains the connection. I assume that there's no cross-connection state that could affect the analysis.<br>
<br>Ruoming<br><br><div class="gmail_quote">2008/8/19 Martin Szydlowski <span dir="ltr"><<a href="mailto:msz@seclab.tuwien.ac.at">msz@seclab.tuwien.ac.at</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<br>
I am extending the BitTorrent analyzer (kudos to Nadi Sarrar) that has<br>
finally made it into the 1.4.prerelease to handle messages beyond the<br>
standard protocol. In particular, I am including the Azureus Messaging<br>
protocol and there's where the trouble begins. When "switching" from<br>
standard to azureus protocol, the analyzer consistently swallows the<br>
first 4 bytes in the upflow direction. The downflow is unaffected and<br>
the analysis works fine there and it does not matter if the first<br>
message after the switch was upflow or downflow, it is always the first<br>
upflow message that is affected.<br>
<br>
The effect of the swallow is that the analyzer misses the 4-byte length<br>
field and takes the first four bytes of the following string instead.<br>
That produces a huge number that causes an out_of_bound exception and<br>
stops the anaylsis for the upflow.<br>
<br>
I did some debugging with gdb and found that FlowBuffer::NewMessage<br>
in aux/binpac/lib/binpac_buffer.cc increases the orig_data_begin_<br>
pointer by 4 when it is actually pointing at the correct spot. Either<br>
the increment is wrong, or the data pointer is 4 bytes to far already, I<br>
cannot tell.<br>
<br>
I have only made changes to ,pac (and .bro) files, therefore all the<br>
code is binpac-generated. As long as the network dumps do not contain<br>
azureus traffic, my code does not get invoked, and the analysis runs<br>
fine, therefore the fault must lie in my changes. However, since the<br>
code for upflow and downflow is obviously identical and only upflow is<br>
affected by this error, maybe my code triggers some obscure bug in<br>
binpac or bro. Oh and BTW, I also tried disabling the connection<br>
compressor, since in the past that caused trouble with localhost<br>
connections (but that bug should be fixed by now).<br>
<br>
I am attaching a diff of my changes (against SVN revision 6054).<br>
The dumps I have been testing against can be found at<br>
<a href="http://hades.seclab.tuwien.ac.at/msz/azu.dump" target="_blank">http://hades.seclab.tuwien.ac.at/msz/azu.dump</a> and<br>
<a href="http://hades.seclab.tuwien.ac.at/msz/azu2.dump" target="_blank">http://hades.seclab.tuwien.ac.at/msz/azu2.dump</a> (both ~30MB).<br>
When using this dumps, you must use the -C flag since the tcp checksums<br>
are invalid (as always when capturing traffic on the originating host).<br>
(My invocation of bro is: $ bro -C -r xxx.dump bittorrent bt-tracker weird)<br>
<br>
I hope someone can look at this and tell me what is going wrong.<br>
<br>
greetz Martin<br>
<br>
<br>
<br>_______________________________________________<br>
Bro mailing list<br>
<a href="mailto:bro@bro-ids.org">bro@bro-ids.org</a><br>
<a href="http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro" target="_blank">http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro</a><br></blockquote></div><br></div>