View Single Post
Old 26-08-03, 01:05 PM   #1
TankGirl
Madame Comrade
 
TankGirl's Avatar
 
Join Date: May 2000
Location: Area 25
Posts: 5,587
Arrow Partial hashing subjects FastTrack to fake file flooding

From Zeropaid:
Quote:

Found this on the k-lite forum. It explains the floud of damaged mp3s. Pure horror. We can't trust the verifieds anymore.

Author: Hasnain
Date: 08-26-03 16:13

Foreword:

I am listing this topic here, because more and more people are beginning to download fake or corrupted files from the FastTrack network, despite using a verified hash. Some people have asked me how this is possible, the main reason being that Kazaa does not use each and every byte of a file to determine its hash.

Vulnerability:

I had noticed this vulnerability when saw the source code of sig2dat. Essentially, Kazaa calculates the hash of a file in the following way:

1. It reads the filesize and if the filesize is less than 300Kb, it hashes the whole file. If the filesize is greater than 300Kb it reads the first 300Kb from the file. The hash method is md5 one way hash.
2. After hashing the first 300Kb, it now calculates the offset of the next block as the offset of the previous block t shifted by two i.e.
New Offset = Old Offset << 1 (Shifting a number left by one means multiplying it by two).

------------------------------
Block 1, Size = 300Kb
Start Offset = 1
------------------------------
Block 2, Size = 300Kb <--This block will be
Start Offset = 300K <-- skipped
------------------------------
Block 3, Size = 300Kb
Start Offset = 600K
------------------------------
. <- Other skipped block(s) here
.
.
------------------------------
Block N, Size = 300Kb
Start Offset = N*300K
------------------------------

Now its obvious from the above procedure that after the first 300Kb is hashed, the next will be skipped, because the offset is multiplied by two. That means 300Kb will not be hashed. This will get even worse, as the next time the offset is multiplied by 2, 600Kb will be skipped.

Now all a miscreant needs to do is damage those parts of the file which are not hashed, like the second block or 300Kb, or the fourth block of 600Kb, etc. This means that Kazaa will think that they are the same files, and will download the damaged file as part of the regular file. This will result in incorrect files downloaded, even if the content was supposed to be verified.

Why was it done?
----------------------
the basic idea behind such an algorithm to calculate hash would be speed. This method allows Kazaa to hash files of gigabyte sizes in a few milliseconds, even on slower machines. But in doing so, they miss out a very important aspect, integrity.

Corrective Measures:
---------------------------
Unfortunately, its the way Kazaa calculates the hash and *nothing* can be done about it. The only way to correct this is that Sharman Networks actually changes the calculation algorithm to use all the bytes available in the file.
Partial hashing is usable to spot identical files in a friendly environment, and was already used by Napster. In hostile environment only complete hashes can be trusted though. Not only can mp3 and movie files be damaged due to this vulnerability - it is also possible to insert viruses to shared software without changing the partial hash numbers.

- tg
TankGirl is offline   Reply With Quote