Gnutella Forums - Newbie refresher course - bearshare spy-packets scandal

I am a bit of a newbie to gnutella. I am posting this for the benefit of other newbies, who may have missed the opriginal dialogue. (hope the formatting comes out ok from this cut-and-paste)

I was curious to receive some text files in my gnutella transfers detailing contentious issues surrounding the BearShare client and it's rude but now famous developer, Vinnie.

So I looked up the mentioned sites on the web and tried to make some sense out of it.

Here is the result:

Summary of http://www.gnutellaforums.com/showth...p?threadid=358

----- Summary of first article -----------
This article is in fact a reposting of an entire thread
because Vinnie deleted the thread previously
------------------------------------------

"Spy Packets not Onflow message being passed around"
Posted by Stacker (Guest) on May-08-01 at 06:16 AM

[snip intro]

Bearshare sends out secret packets and passes them around the Gnutella Network disguised as search replies. Bearshare filters them so you don't see them! You need a special program to see them! They can't be easly tracked back to their source!

[snip conjecture]

I found these messages on a public forum called the "gdf" where developers hang out:

From: Nate Date: Sat Apr 21, 2001 6:00am
Subject: Strange Query Hit packets
While working on some routines, I found a strange scrambled packet, it's
always 175
bytes and very well formatted for Gnutella. Any idea what this is? The
IP address is never correct in the packet. Here's a sample I captured:
----------------- Query Hit Data
01 B4 16 16 B4 F2 48 38 00 00 00 01 00 00 00 AF .4..4rH8......./
00 00 00 A1 B3 D0 A9 E0 99 A0 B1 FF FE D9 EF 93 ...!3P)`. 1.~Yo.
EE C5 91 D5 80 85 AA B0 F2 97 E3 F6 CD BD D2 A1 nE.U..*0r.cvM=R!
A0 F9 C2 A9 94 8F D0 EE D6 C0 BA EE BE CA B9 DF yB)..PnV@:n>J9_
A2 A9 8B B9 88 AE E9 95 C4 D9 AB 99 F1 E4 B6 B7 ").9..i.DY+.qd67
F8 D0 97 9C 86 C9 D9 F8 8B 87 AA B9 DF C9 A1 B5 xP...IYx..*9_I!5
D3 E4 C8 95 CD BF 98 CB E7 E5 8E 91 E0 C7 B3 C4 SdH.M?.Kge..`G3D
AF 87 CE 82 94 C6 BF FF EF 92 A6 D9 A3 E4 B8 90 /.N..F?.o.&Y#d8.
AF EF B7 A8 E3 E6 E4 D7 96 DC 85 F9 8E FE 88 93 /o7(cfdW.\.y.~..
CA 83 A5 BC C9 BD 9E DF FC C2 A6 CE C0 00 00 53 J.%U-.r.sq6gTm.
----------------- Bytes = 175

[snip more example packets]

normal packet for reference:
----------------- Query Hit Data
04 CA 18 41 A2 C8 68 00 03 00 00 9A 00 00 00 60 .J.A"Hh........`
E9 18 00 4B 6F 72 6E 20 2D 20 49 73 73 75 65 73 i..Korn - Issues
20 2D 20 31 37 20 2D 20 48 69 64 64 65 6E 20 54 - 17 - Hidden T
72 61 63 6B 2E 6D 70 33 00 00 44 01 00 00 C7 C2 rack.mp3..D...GB
95 00 72 61 67 65 20 61 67 61 69 6E 73 74 20 74 ..rage against t
68 65 20 6D 61 63 68 69 6E 65 20 2D 20 30 31 20 he machine - 01
2D 20 62 6F 6D 62 74 72 61 63 6B 2E 6D 70 33 00 - bombtrack.mp3.
00 9D 02 00 00 00 D0 58 00 44 61 76 65 20 4D 61 ......PX.Dave Ma
74 74 68 65 77 73 20 42 61 6E 64 20 2D 20 42 65 tthews Band - Be
66 6F 72 65 20 54 68 65 73 65 20 43 72 6F 77 64 fore These Crowd
65 64 20 53 74 72 65 65 74 73 20 2D 20 31 30 20 ed Streets - 10
2D 20 54 72 61 63 6B 20 31 30 2E 6D 70 33 00 00 - Track 10.mp3..
89 00 00 00 AB C5 47 00 4B 6F 72 6E 20 2D 20 46 ....+EG.Korn - F
6F 6C 6C 6F 77 20 54 68 65 20 4C 65 61 64 65 72 ollow The Leader
20 2D 20 32 36 20 2D 20 20 28 48 69 64 64 65 6E - 26 - (Hidden
20 54 72 61 63 6B 29 20 43 68 65 65 63 68 20 26 Track) Cheech &
20 43 68 6F 6E 2E 6D 70 33 00 00 42 45 41 52 01 Chon.mp3..BEAR.
00 18 00 01 02 00 00 00 00 00 AF 8C 30 D4 1E 46 ........../.0T.F
CE 59 FF 83 94 41 60 5F 8A 00 XX XX XX XX XX XX NY...A`_..
----------------- Bytes = 298

<A NAME="1">
From: Vinnie</A> Date: Sat Apr 21, 2001 2:43pm
Subject: Re: Strange Query Hit packets

[snip quoting of above post]

Queries, or Query Hits message which have only high ascii characters
(values with the high bit set) where strings are expected are
proprietary messages sent between BearShare servents.

Queries should be handled as usual (routed or dropped if
duplicate/expired) however there is no need to scan the local index
of files for a match if the high bit is set in every character.

Query Hits messages which have only high ascii characters should be
handled as usual (routed or dropped if expired or there is no route).

If you have passive monitoring implemented, do not scan these high
ascii file names as they do not correspond to file data.

[snip mainbly inadequately specified sources of no information concerning packets]

[snip reply]

"Bull$hit"
Posted by Vinnie on May-08-01 at 08:20 AM
Its not spy packets.
<A NAME="2"></A>
BearShare sends encrypted messages that contain the version number, and high precision representations of the shared file count and bytes.
These messages are sent as both queries, and query replies.
The main purpose of the message is to support the "upgrade notice" when a newer version of BearShare is detected on the network.
The message is protected to prevent unauthorized users from claiming to be a higher version number.
Duh!!! This is old news!

[snip some replies]

"RE: Bull$hit"
Posted by Sephiroth on May-09-01 at 02:47 PM
This is needed to get users to update the program.
Gnutella is not like napster or any other crappy centralized or semi-decentralized program. The latest programs HAVE to be used or else the network will continue to be slow and ****ty for all. That is why its needed and because gnutella is not centralized you cant really have a central place to check for updates and get to everyone.
Waste of bandwith... a less than a fraction of a second to transmit.. Oh yeah thats a real waste..
It doesnt FORCE you it gives you the chance to say yes update or no dont...
The most important thing is
>The message is protected to prevent
>unauthorized users from claiming to
>be a higher version number.
If that wasnt in there i could take a nasty virus.exe set it to Bearshare 9.9.9 and watch as everyone upgrades to it and gets there computer infected with the nasty surprize of my
choosing..
The current upgrade method prevents that for ever happening and what you two are complaining about is that you want to take that feature away and open a paradoras box that will have the potential to literally cripple gnutella network out of existance..
So ****ed i think that would be a little worse than the trojan rant you went on about. But trojans open a security hole on your computer and leaves them there and the upgrade notice doesnt since you believe one is there i hope you go out and find this trojan and see how you can use it to gain access to other users machine. Since you said that it is a trojan you must already know alot on it so you'd be the best one to track it down. Ill be waiting for your results and good luck testing that out.

[snip some less relevent posts]

"RE: Hack a pack"
Posted by Grant (Guest) on May-13-01 at 04:39 PM
So is there a security hole? Is that what you are saying?
If someone wants to send a packet saying they have a upgraded version my client will accept it and then download and install the new version. Or make it look valid so I install it?
Sounds like a big security hole to me! Has this encryption been tested by the big encryption programmers? If not, you are doomed!
I cant wait to see the first formatted hard drive and law suit cause this was done incorrectly. "RE: wHack a clown"

Posted by Sephiroth on May-13-01 at 05:12 PM
Because of the way it is now what i said in my last post cant ever happen. And even if it did then you have to be directed to a web page which contains the file. Plus theres others way to prevent it from happening that are in place. So your all full of it.

[snip some less relevent posts]

"Snap into a Slim Jim"
Posted by Vinnie on May-13-01 at 11:35 PM
>So is there a security hole?
>Is that what you are
>saying?
>If someone wants to send a
>packet saying they have a
>upgraded version my client will
>accept it and then download
>and install the new version.
No - BearShare does not automatically download and install anything.
Even if it did (which it might, eventually) it would use download.bearshare.com, ask the user before the installation proceeds, and be digitally signed by Free Peers, Inc. using the code signing tools developed by Microsoft.
Compromising the private key from Verisign would require either #1 breaking the encryption strength, or #2 hacking the machine which stores the certificate and stealing a copy.
For #1 the chances of this happening are just as likely as someone cracking the private key for Microsoft's code signing certificate. If I were devoting CPU resources to breaking a cipher, I would certainly go after a more valuable certificate than the one held by Free Peers, Inc. especially since both Internet Explorer and Windows Update can automatically trust certificates from Microsoft.
For #2 someone would have to break into the facilities since this machine is neither connected to a local area network nor is it connected to the Internet.
If I were dead set on gaining access to the certificate, I would certainly go for method #2 since that one has a higher chance of success.
Whoever tries, better make sure that I'm not there or else they will get a major can of whoop-asss opened up on them

[snip some less relevent posts]

"Eh?"
Posted by Vinnie on May-15-01 at 07:58 AM
>Here's why I don't understand the
>rationale you give ("So people
>don't impersonate higher versions.")
>How exactly are Bearshare users
>going to do that?
A malicious hacker could send a message out that claims a higher version - this would wreak havoc on the network, no one would trust the upgrade dialog again.
>Vinnie has said elsewhere that he
>plans on putting additional info
>in these packets soon, such
>as Processor, RAM, etc.
>I don't know if he
>was joking (I think sometimes
>that he replies on these
>forums after a couple days
>of no sleep), but why
>would he do this?
Certain high end machines will become eligible to run extended peer to peer services. Criteria for running these extended services include:
- someone who leaves their machine on for a long time
- dedicated IP address (that doesn't change with DHCP)
- ability to accept incoming connections
- sufficient RAM
- sufficient idle CPU time
Part of these features requires "tuning" the network. This tuning process assigns random number probabilities to each eligible machine to determine if they are elected to run extended services - this provides control over density and distribution within the network of machines running extended services. In order for me to tune it, I need to have a rough idea of the distribution of computer resources through the network and this requires gathering statistics.
>I CAN think of a couple
>reasons for this type of
>packet that don't NECESSARILY involve
>RIAA or MPAA, but I
>don't understand why he wouldn't
>just SAY so. For
>example, something to prevent other
>apps from masquerading as BS
>(for what reason, I can't
>imagine.)
It is impossible to prevent other applications from masquerading as BearShare. It simply cannot be done.
However, it is possible to prevent other applications from claiming to be a higher version number of BearShare than is currently shipping, thus the encryption.

"Thanks for the explanation"
Posted by Einstein (Guest) on May-15-01 at 10:58 AM
>A malicious hacker could send a
>message out that claims a
>higher version - this would
>wreak havoc on the network,
>no one would trust the
>upgrade dialog again.
Ah! I think the lightbulb just went on! So, the way this works then, bearshare apps send out messages that tell other peers what version they are running. If my app sees a message from a higher version, it pops up the upgrade dialog. Got it. So, you do this to cut your bandwidth costs at your download servers (seeing how the alternative would be for them to check in there when they are fired up)? So, if this is how these are used, you are effectively spreading your bandwidth costs out to the rest of the network. That sort of makes sense. Now you need to figure out a way to propagate the downloads through the network
>Part of these features requires "tuning"
>the network. This tuning process
>assigns random number probabilities to
>each eligible machine to determine
>if they are elected to
>run extended services - this
>provides control over density and
>distribution within the network of
>machines running extended services. In
>order for me to tune
>it, I need to have
>a rough idea of the
>distribution of computer resources through
>the network and this requires
>gathering statistics.
Have you been working at all with other peer developers on this? I would think that messages of this sort would be generally useful for network distribution. You could implement the use of those messages in a superior way, and maintain your competitive advantage, and the network would enhance the value of your software by complying with the messages. That might also ease the fears of some of the more ... er ... cautious on these forums.

[snip some less relevent posts]

"Loki"
Posted by Vinnie on May-16-01 at 05:04 PM
>A malicious hacker could send a
>message out that claims a
>higher version - this would
>wreak havoc on the network,
>no one would trust the
>upgrade dialog again.

>So, how can a message claming
>a higher version client wreak
>havoc on the network, if
>all downloads are made from
>download.bearshare.com anyway?

No one will upgrade in a timely fashion.

<A NAME="3"></A>One of the biggest fixes I made to BearShare was in the "push" handling. Part of this fix actually rejected connections from older BearShare servents on or after a specific date (a "time bomb"). This timing scheme was necessary to make sure there was a sufficient number of fixed versions out on the network before the connection reject logic took effect.

Without the time delay, early adopters of the new version would have a difficult if not impossible time getting hosts.

Having a false ugprade dialog would not only be annoying, it would interfere with the upgrade process itself, causing delays in propagation of bug fixes and enhancements.

Thats called havoc.

--------- End of first article -------------

None of the other posts in the thread respond to the actual question at hand:

Why should Vinnie be <A HREF=#2">passing encrypted packets in the guise of Query and Query Hit messages?</A>

Why should <A HREF="#1">non-BearShare users pass these on in good faith?</A>

Why should BearShare users take Vinnies word that they are not of concern? Why doesn't he just document a protocol extension?

This really doesn't hold water. How is he saving bandwidth by this, if at the same time he is getting all his BearShare clients to get their hosts from his BearShare hostcache? Duh? Why doesn't he send out a one-byte packet during this check-in, which means 'check your version against that held at http://blah.bearshare.blah'? Remember, he said the version info was the '<A HREF="#2">main purpose</A>'!

Face it, the only real way that this 'version number' scheme can be of significant benefit is if he closes his web site and ships out version upgrades via the gnutella network.

Right, as if. Is he expecting gnutella to make the www redundant?!

And this (fictional) method of BearShare propagation would be a big security risk.

Sure, he's using the version number info propagation already, but I just don't believe that this can be the 'main purpose' of these packets.

Unless .. ah now this makes sense .. he's worried that sysadmins will firewall his clients from connecting to www.bearshare.com, so he lets the clients use different hostcaches for that case. Note that he does not reciprocate this and allow other clients to use his hostcache, but he is happy for his clients to use other hostcaches. Anyway, so with these packets, the version upgrade info can't be firewalled off.

And face it, the only way he could use up 170-odd bytes on <A HREF="#2">'high-precision representations of the shared file count and bytes' is if he's doing some profiling of file types, file sizes etc, which he should declare as 'collecting aggregate data' because otherwise local data-protection (privacy protection) laws are being broken.

Other useful data he could collect (got your notebook out Vinnie) would include numbers of competing clients that are being met, uptime, processing power, line speed, amount shared by not just one client, but by many - he could be taking a survey of every machine he meets .. or even sending out remote control instructions or code updates .. da da da.

And face it, he hasn't decided what he's gonna use these packets for yet.

Do you like the <A HREF="#3">built-in-redundancy factor?</A> Imagine if other software companies built in <A HREF="#3>deliberate rejection of connections from older versions of software to force users to upgrade</A>?!

<A HREF="http://www.gnutellaforums.com/showthread.php?s=&threadid=1426">More on this topic</A>
(Gee that guy Vinnie comes up as a shining beacon again! If I acted like that in my place of work, I'd get the sack. Think about it.)

<A HREF="http://www.gnutellaforums.com/showthread.php?s=&threadid=1459&highlight=cookie"> Someone claimed that 20 minutes with a port sniffer proved that the encrypted packets were entirely a safe proposition</A> - what do you think? Well, the site that did the survey is down right now (29 Mar 2002) but to me it's pretty obvious that you can't prove what the encrypted packets could be hiding .. because their encrypted and you don't have the source code to generate or process them. Like trying to prove a cup could never hold poison.

by the way, aren't these two postings a laugh!:

------------- Third article ----------------

Vinnie
Guest
Registered: Not Yet
Location:
Posts: N/A

bodhi, I deleted your post because it was abusive.
Why don't you stop using Windows until Microsoft releases the source code?
Why don't you stop using LimeWire until they release the source code?
Why don't you stop using Gnotella until they release the source code?
Report this post to a moderator | IP: Logged
05-25-2001 07:09 AM

--------- End of third article -------------

------------ Fourth article ----------------

Vinnie
Guest
Registered: Not Yet
Location:
Posts: N/A

One more thing
You are a narrow minded, simple fool.
If you paid any kind of attention, you would realize that I have responded to all of the user feedback.
Bundled components can be UNCHECKED in the latest install!!
DUH!!! What's wrong with you dude!
Someone needs to smack you upside the head.

--------- End of fourth article ------------