BitComet is evil

[Lord Alderaan]

This is not about µtorrent. This is about BitComent a controversial 'rival' client.

I got this from what I personally consider a very reliable source [edit]That would be System[/edit] in the torrent community. I verified it myself using wireshark. You can verify it yourself by using the following filter:ip.dst == 222.73.19.193 (assuming the inside-stats.bitcomet.com doesn't change IP). Add a torrent into BitComet and check out the data of packets with POST /xmlstats/ in the info.

I was using 0.93 (freshly downloaded from the bitcomet website itself) and I had all posible options about sending anything to BitComet disabled ('check for updates' and 'Submit task statistical info to help us improve service quality' were turned off and bitcomet was exited and restarted to make sure it was applied).

I've just discovered that bitcomet from 0.89 onwards at least (not tested earlier 0.8 or 0.7 versions) sends data about what you are downloading to bitcomet.com.

Their privacy policy is a lie.

The BitComet Software (the Software) automatically sends only standard, limited information to BitComet, which may be retained in BitComet's server logs. We do not associate this data with personally identifying information about you.

The Software does not send any information about the files you are downloading, unless you enable the function of "Search for mirrors" while downloading in HTTP/FTP protocol.

Here's what's sent:

POST /xmlstats/ HTTP/1.1

Accept: */*

Accept-Encoding: gzip

Connection: close

Content-Length: 281

Content-Type: application/x-www-form-urlencoded

Cookie: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Host: inside-stats.bitcomet.com

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)

Query=%3C%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%20standalone%3D%22

yes%22%20%3F%3E%3CBitCometPost%3E%3CQuery%3E%3Ctask%20hash%3D%22a0743038e91828f

c15db5eec0b2923b1c1518032%22%20size%3D%2239967818%22%20type%3D%22bt%22%3E%3C%2Ftask

%3E%3C%2FQuery%3E%3C%2FBitCometPost%3E

Which translates to:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>

<BitCometPost>

<Query>

<task hash="a0743038e91828fc15db5eec0b2923b1c1518032" size="39967818" type="bt">

</task>

</Query>

</BitCometPost>

The torrent I tested with just happens to be 39MB in size and has an info hash of a0743038e91828fc15db5eec0b2923b1c1518032, which as you can see is sent to BC regardless of what their privacy policy says.

I'd advise everyone to avoid bitcomet use (yet again), because they have proven once more to be the shittiest client out there.

My conclusions where exactly the same. Its sending hash, size and this bt thing to its own server.

Remember that a hash is a unique ID identifying a torrent. Although they'd still have to find the details that go with that torrent this is not impossible, especially with popular public torrents. And of course by connecting to their server they get ur IP connected to that hash.

Draw your own conclusions. Harmless? Lying bastards violating their own privacy policy? Attempt at tracking which torrents are downloaded by whom?

[edit]Updated the post to identify System as my 'reliable source'

[Switeck]

Let me guess...this is probably sent "in the clear" too?

That means anyone doing a "man-in-the-middle" style listening attack on your connection will catch that info passing by too.

[Lord Alderaan]

Its not encrypted no. I fact its a simple html form POST (as opposed to GET) submit with a urlencoded string in the 'query' form field. The string contains the xml info as shown in the 'Which translates to' part.

Not only a man-in-the-middle could see it (man-in-the-middle could decrypt information under certain circumstances). Any hardware/software/person in the route to the server who is looking at/logging the data could read it no problem. However this goes for the normal peer-tracker traffic too so from that perspective this isn't an added risk. Its the fact that BitComet gets this info from ALL its users and could track most of its users (based on their IP) this way. It is worse case scenario yes but why else would BitComet collect this data secretly (well not really secretly, its so easy to detect its a miracle it didn't hear of this earlier, but sneaky yes cos their privacy police states they don't).

This is pretty much exactly what µtorrent has been wrongfully accused of a lot of times in the last year. And BitComet has actually been doing it for a while now and we didn't even know...

[amc1]

Anyone bring this up on the BitComet forums?

[Lord Alderaan]

Go ahead if u want. I heard they moderate heavily on any anti-BitComet topics so it'll be removed and you might get (IP) banned to boot. I want to keep an eye on their site so I'm not gonna bring it up.

[amc1]

Well, I've posted a message here:

http://forums.bitcomet.com/index.php?showtopic=12789405

http://www.tocomet.com/post/35767/

Like I said, it may very well be a bug - there's not a lot you can get from an infohash or file size unless you already have a list of info hashes stored somewhere to compare against.

(Edit: And now they've replied to the post - you might want to take a look)

(Edit #2: It's to do with their torrent "comment" feature, apparently - which unfortunately can't be disabled.)

[Saribro]

there's not a lot you can get from an infohash or file size unless you already have a list of info hashes stored somewhere to compare against.

That's what google is for . The torrent in the OP example:

http://www.fulldls.com/torrent-ebooks-27097.html

[Lord Alderaan]

Like I said. "especially with popular public torrents"

[system]

I did some further testing for all versions from 0.79 - 0.93 (good to know I'm a reliable source )

0.79 Does not send stopped event

0.80 Does not send stopped event

0.81 Does not send stopped event

0.82 Does not send stopped event

0.83 Sends info_hash to inside-stats.bitcomet.com and still doesn't send stopped event

0.84 Sends info_hash to inside-stats.bitcomet.com and still doesn't send stopped event

0.85 gets worse, and still no stopped event

GET /task/bt/a0743038e91828fc15db5eec0b2923b1c1518032/39967818/?v=0.85&l=en_us&filename=Playboy%20October%202007.pdf HTTP/1.1

Accept: */*

Accept-Language: en-gb

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: sidebar.bitcomet.com

Connection: Keep-Alive

Cookie: xxxxxxxxxxxxxxxxxxxxxxxxxx

Notice it also sends the file name. I don't really want playboy, it's just a good file for testing

0.86 sends hash to at least 3 places, filename to 2.

inside.bitcomet.com (similar to sidebar above)

sidebar.bitcomet.com

inside-stats.bitcomet.com

Still no stopped event

0.87 same as above

0.88 same as above, send stopped event after 4 clicks on stop button

0.89 Sends stopped event properly, still has info_hash/size/filename reporting

0.90 drops the sending to inside.bitcomet.com

0.91 drops sending to sidebar.bitcomet.com

0.92 still posting info_hash and size

0.93 still posting info_hash and size

BTW, I don't mind being named as a source for anything I make public. If I'm wrong on something, people need to know who to call on it :-P

[amc1]

I did some further testing for all versions from 0.79 - 0.93

Oh - nice to see you've got some time to spend testing some BT clients, even if you don't have time to spend on others...

Notice it also sends the file name. I don't really want playboy, it's just a good file for testing

Ah - in the query string. It doesn't show in the forum post, but you can see it if you highlight it all and paste it somewhere else.

[system]

Also shows if you extend the width of the browser window.

I've left a few comments around various places asking if anyone can help parg finish up the testing, especially with peer injection becoming public knowledge. If nobody volunteers, I'll clear some time to get it done.

Testing those versions only took about 30 minutes though :-P

[amc1]

I've left a few comments around various places asking if anyone can help parg finish up the testing, especially with peer injection becoming public knowledge. If nobody volunteers, I'll clear some time to get it done.

That would be good. The peer injection route won't work as well in future.

Testing those versions only took about 30 minutes though :-P

[Switeck]

Along the same theme:

v0.97 Max simultaneous half-open TCP connections setting not honored, Statistics pane shows Half-Open: 12 [MAX:10]

http://forums.bitcomet.com/index.php?s=f94870f020efd011a4273ddb00e1240b&showtopic=12790929

Probably be fixed soon.

BC 0.97: Private Passkey Leak!, A very serious bug discovered.

http://forums.bitcomet.com/index.php?s=f94870f020efd011a4273ddb00e1240b&showtopic=12790959

BitComet's new feature "Peer Torrent Sharing" can share private torrents..."and thus is a security leak, if the user accidentially enables this."

I am pretty sure this will be fixed soon.

WTF?!, Stop telling me what I can and can't do.

http://forums.bitcomet.com/index.php?s=f94870f020efd011a4273ddb00e1240b&showtopic=12789834

"In a very old version of our client, one of our partners in development requested that our client not be used to download certain specific torrents, a list of approximately 200-300 were submitted, and our client was coded to reject these torrents.

The torrent in question here, appears to have identical hash data as one on this list, and therefore was rejected.

Since this company is no longer part of our development team, we are removing this code from all future versions of BitComet, starting with the next beta release.

BitComet Team"

...Presumably, it's fixed now.

BUG: BC "LT Seeding" shares HTTP download not intended for sharing

http://forums.bitcomet.com/index.php?s=f94870f020efd011a4273ddb00e1240b&showtopic=12790878

This is FIXED in 0.98B!

Such a vulnerability could've opened up a whole new level of privacy risks. Let's hope it's fixed.

[Falcon4]

I just injected a little of my personal happiness into the BC forums thread. I wonder whose heads are going to roll...

[funchords]

I've been moderating over at that BitComet forum for the past few weeks. I'm a fan of this client -- an almost total convert. I turn on uTorrent to seed and to help catch what I can during a public alpha/beta cycle.

It's not evil (please assume positive intent), but it is buggy. It's also not a pure BitTorrent client anymore, so there are interesting interactions that one wouldn't see with uTorrent or Vuze. Many of the important ones have been identified above (and many of those have been fixed).

Feel free to post on the BitComet forum. We don't filter stuff off as someone alleged (speaking for the English-speaking forum). Just be constructive -- just as you would on this system.

[Switeck]

The point of this thread, at least the starting post, proves that it most certainly monitors what torrents you're running, in contrast to their privacy agreement. Such behavior is acknowledged as intentional and with no way to disable it. No bugs involved.

There are serious issues about who BitComet's business "partners" are, and what THEIR intentions are...since BitComet is certainly willing to secretly (though I'm not sure it was secret?) accommodate them and block torrents as per their request. It was only a bug report and follow-up code audit that uncovered this link, where there may in fact be more.

That makes it evil.

Bugs just seem to make it moreso.

[Firon]

BitComet is evil. Plenty of proof of that. It's also a very badly behaved client.

[Falcon4]

Yeah, well, The UnUsual Suspect (on the BC forums) may just get me to give BitVomet another try. With just his avatar and sig. Much, much <3 there. So badass. How can you argue with so much badass?

Besides, the feature list on the BC site is mucho impressive. And it's written in C++. ^-^

[Dark Shroud]

The problems are being fixed a little slowly at times but they do get fixed. BitComet keeps adding features and every time a new feature is added it seems to break in other areas. What slows down fixes is that RnySmile doesn't speak English, he's Chinese.

Anyway keep reporting issues that you guys find or have a problem with. They do get addressed, just please be decent when doing so.

[Lord Alderaan]

Yup, I do believe they didn't intend misuse when they implemented the feature mentioned in the linked BitComet topic however that doesn't change the fact that it could be abused without the users knowing AND that it violates its own license and policy.

And if they don't care about their own official agreements why would they care about their users and not abuse the feature when a proper opportunity presents itself.

[Switeck]

The hammering nature of earlier BitComet clients (around 0.5 to 0.65) was known to the designer for a long time. It was intentional as a means to get a larger share of attention from a single peer/seed. Barring that, it was an extremely bad design with no real purpose. Attempting multiple connections to the same ip and not giving a reasonable minimum cool-down time for EACH ip attempted...is what I've personally seen and hate.

Now maybe this has been fixed, but there's still HUGE numbers of people using these old versions.

I see similar issues with private trackers recommending uTorrent versions as far back as v1.3 or v1.4!

I really hope the latest BitComet still supports its special encryption method just so nobody sticks with the older versions since "that's all that works for me!"

[Dark Shroud]

BitComet dumped their old encryption in favor of the µTorrent Azureus encryption. It was broken by just about everyone as it only encrypted headers instead of the whole packet. So anyone who says its the only one the works is most likely full of it. They're probably getting a bump in speed from NAT Traversal or web seeds.

[jewelisheaven]

I would like to point out that YES, BitComet is able to somehow register as an incoming connection through a specifically blocked port on my firewall (I recall seeing versions 60-98).. and the only other client which could do that on those swarms was BitLord 1.1. It doesn't appear to be through NAT transversal as XP has no native support for UDP hole punching.

[Ultima]

If it's getting through your firewall, then your firewall must suck :|

[funchords]

I would like to point out that YES, BitComet is able to somehow register as an incoming connection through a specifically blocked port on my firewall (I recall seeing versions 60-98).. and the only other client which could do that on those swarms was BitLord 1.1. It doesn't appear to be through NAT transversal as XP has no native support for UDP hole punching.

It is UDP hole punching. Azureus has had this feature for a while, too.

The first Bitcomet version with it was 0.54. The most recent change was 0.89 which added the "automatic" configuration choice that enables it only if the node appears to be firewalled.