Re: Fwd: Kazaa file corruption

[Markus Kern <markus-kern () gmx net>]

Blue Boar <BlueBoar () thievco com> wrote:

> I had been under the impression that Kazaa DID use checksums, just that it
> had some sort of bug, or was trusting the peers, or something.  I thought
> that was what the temp filename was.  (I wouldn't mind someone pointing me
> to any good info about the protocol.)

The best source for information about the FastTrack protocol are the
old giFT sources (http://www.giftproject.org, they now use their own
protocol, get old sources from cvs).

Since this is pretty old (September 2001) Kazaa may use a different
method for checksumming now but I'll describe how it worked back then.

First it does a MD5 hash of the first 307200 bytes (300K) of the file.
This is the same thing napster did IIRC.

Second it takes 307200 byte chunks from the file and passes them to a
algorithm that produces a 4 byte hash using a hardcoded table.
The first chunk is taken from file offset 0x100000 (1M) and then the
offset is shifted left by 1 bit for the next chunk, etc.

The MD5 hash and the 4 byte hash are concatenated to form a 20 byte
file id which is used to distinguish files on the network (and group
search results, for example).

Naturally this method is not cryptographically secure and my guess
is that it was choosen for performance reasons.

For downloading a file a third hash with a length of 2 bytes is used.
Again using a constant table it is calculated from the 20 byte file
id and appended to the http url which is used to download the file.

As for the possibility of corrupting the Kazaa binary itself I have no
experimental data on this.
But since performance is not an issue here and it's a special case
where they execute the binary automatically I hope they have included
a final MD5 check of the entire file against a hash downloaded from
their central web page.

Hope this helps,
Markus Kern