[Bro] Patch for BitTorrent analyzer

Martin Szydlowski msz at seclab.tuwien.ac.at
Tue Jun 23 11:29:03 PDT 2009

Hi Bernhard,

Bernhard Ager wrote:
> Oh, interesting to see that. Especially as I have also written a few
> extensions for the BitTorrent analyzer, among them the above mentioned
> Azureus Messaging Protocol (AZMP) and the LibTorrent Extension
> Protocol. 

I was not aware of that - I stopped following the SVN when 1.4 was
released. Also, by that time, I had pretty much finished the extensions.
It's been only a couple of fixes since then and my 1.4 patch still works
fine on the most recent SVN trunk. I should have released it back then
but somehow I kept forgetting, and only when I met Robin in Oakland last
month I remembered.

> My flavour of the enhanced parser analyzes the extension
> negotiation protocol (I remember that being a bit hairy) before
> deciding if AZMP or plain BitTorrent is used.

I had planned to implement the negotiation protocol as well, but since I
never encountered it in my traces I postponed that project :)

> Main differences between the analyzers as far as I can tell from a
> short peek into your code (forgive me if I mistook a thing or two):
> - AZMP is parsed generically, e.g., I don't handle AZ_PEER_EXCHANGE in
>   a special way. When handling those messages explicitely, then this
>   should be unified with LTEP anyway.
> - Well, LTEP and arbitraty message parsing integrated.
> - We use different methods for determining the transparent switch to
>   the AZMP protocol. I can happily claim mine works correct for all
>   examined connections---that includes a few TB of traffic :-)
> - I deliberately decided against changing the event signatures by
>   adding an explicit PDU len field, though this is definitely the
>   cleaner solution, and in case of padding it is the only way to
>   communicate the correct PDU length. I have never seen a
>   non-encrypted BT connection using padding in the wild, though.
> - Your analyzer handles a few non-standard message types that mine
>   does only cover by the bittorrent_peer_unknown event (with no loss
>   of information though).

I have tailored the analyzer to my needs, and all the changes are a
result of that, especially the PDU-len field and explicit recognition of
certain extended message types (makes post-processing much easier for
me). As you are the main developer for this analyzer and I but a mere
tinkerer, I suggest you take whatever is useful from my patch and
integrate it with your work. There is one actual bugfix in this patch
for BitTorrentTracker.cc, that clears up an endiannes SNAFU when
converting the peer list sent by the tracker to Bro host/port tuples.
However, this is only interesting when using the extended
bt-tracker-plist.bro policy that will also print the complete peer list
to the log file (again something I need that others probably won't find

> I've been testing my analyzer now on several TB of (live) BitTorrent
> traffic and it appears to run stable. For SSH subversion users all of
> this is available from
> svn+ssh://svn.icir.org/bro/branches/bager/bittorrent-enhancements but
> there appears to be no public access to this branch currently. Martin:
> If you are interested in the patch but don't have access, drop me a
> mail, then I'll send it to you.

For now, I am content with what I have and need to focus on other
things, but I would like to continue work on the BT analyzer when I have
more time (couple of weeks from now). I'll let you know when that
happens and if you are still working on BT/Bro then, I'd be delighted to

greetz Martin

Martin Szydlowski
Vienna University of Technology
(temporary @ UC Santa Barbara)
Secure Systems Lab
e-mail: msz at iseclab.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20090623/c428c7af/attachment.bin 

More information about the Bro mailing list