[WentloogWhix]

This is my first post, and I must say in the last few years of using eMule I am dumbstruck by just how good it is. Thanks to the many developers who have given freely of their time and expertise.

It seems that the publishing industry (music, books, movies, whatever) has decided that the only way to stop eMule is to screw up the files, and persuade ISPs to block eMule traffic. I have no idea how to solve the second problem, but the first one is worrying me greatly.

I started downloading a large zipped file recently, and it went fine for the first few days. At about 80% a bunch of new users at a german ISP suddenly appeared on the scene, all supposedly with a complete copy of the file and all happy to give out small pieces of the file. I became suspicious becuase these users would come and go quite rapidly, and only allow a small download, much less than the normal 8MB chunk I am used to. So by the time I had finished downloading 8MB from around 20 different users, eMule told me the chunk was corrupted. Overnight this process caused me to download 380MB of completely useless data.

The problem here is that we are based on a model of trust, rather than one of distrust. From a security point of view we need to be based on distrust, i.e. the user is fake and the data is fake, until proven otherwise. I understand and appreciate that OSS is based on trust, but when it comes to data we should be less trusting.

This would result in the following changes in eMule behaviour:

• Before downloading the file we would have to download a complete hash table. From what I can see this happens at the end, not the beginning.
  
• We would need to be able to download and check the hashes of much smaller pieces. 8MB is all very well when you have oodles of bandwidth, and you are assuming the file is OK, but isn't so great when you know that it could all be corrupt. Maybe 8kb would be better. Bittorrent seems to use even less.
  
• The entire chuink should only be downloaded from one user, so "blame" can be assigned if the chunk is corrupt, and the user can be distrusted. At present it is too easy to download an 8MB chunk from a dozen users. Which one do you blame if the chunk is corrupt?
  
• Once a user has sent a corrupt piece, we should assume the user is having technical difficulties and distrust his content for a few hours. Alternatively we could try downloading it again and if it is identical then we ban the user, at least for a while.

This process would allow users to identify and ignore posters who are actively poisoning legitimate files. It doen't address the issue of bogus files though. That's a problem that is already catered for by means of comments and marking stuff as spam.

I realise I am asking a lot from the developers, and I have no idea whether this would mean a complete revision of the protocols. I am happy to work with the people working on the problem.

Once again, thanks for an excellent program that has been a valuable resource, and has become part of my hobby or listening to audio books.

[Andu]

I'm still looking for a single change that isn't already part of the client...

[WentloogWhix]

Andu, on 04 October 2009 - 09:43 PM, said:

I'm still looking for a single change that isn't already part of the client...

I don't follow. How do I restrict my downloads to a single user at a time? I can find no setting to do this.
How do I ban clients that have issued fake data? The "ban client" option didn't stop my download from being corrupted by the active poinoners, nor did it stop them from continuing. I eventually had to ban the IP range of the entire ISP, but that didn't work either because other users passed on their corrupted data to me without checking it first.

How do I force my client to upload the entire hash table first, and how do I specify that my upload chunks should be 2k?

I provided a link in **** to a file I recently created. I watched a user downloading the file, and he managed two 8MB chunks before it became clear he was also downloading the "same" file from another source. I could see by the way the uploaded pieces were being fragmented.

If I am the only source, how is it possible for an eMule 0.49c user to be misled in this way? Clearly either the change isn't part of the client, or it is disabled by default, or it doesn't work.

In order to illustrate the point I am making, consider the following file:
ed2k://|file|****
I have provided a complete hash set and the AIC Hash. I have only uploaded 47.34MB or the file, which I created, and yet the "entire" 226.62MB of the file can be downloaded. How is that possible, when I have now stopped sharing it?

The first file that I discovered being corrupted is
ed2k://|file|****
I challenge you to download an uncorrupted version of this file. It is now marked as corrupted/fake, yet 87% of it was fine. There is no way I can tell emul to only download this file from a particular user, so now the file is poisoned and wasting everyone's time.

This post has been edited by torpon: 04 October 2009 - 11:29 PM

[fox88]

1. I've doubts that your links are not contradicting the rules of this forum.
2. Normal chunk is over 9MB.
3. We've no idea about your configuration. I've strong suspicion that you enjoy a huge number of fake servers.
Maybe you even should've posted this in support forum.

[WentloogWhix]

fox88, on 04 October 2009 - 11:30 PM, said:

1. I've doubts that your links are not contradicting the rules of this forum.
2. Normal chunk is over 9MB.
3. We've no idea about your configuration. I've strong suspicion that you enjoy a huge number of fake servers.
Maybe you even should've posted this in support forum.

The links point to nonexistent or corrupt files, so I don't think any rules have been broken. As I said in the post, I have stopped sharing the one file, and I know the other is now corrupt.

9MB or 8MB - whatever. It seems to vary depending on the file.

I am using the server list provided at www dot server-met dot de
Quality (Best Indexed) & Fake-Free Server.met (21 servers)

I will gladly post my entire setup and configuration, but it isn't going to solve the problem. If you have a better server list with 2 fake-free servers I'll use that instead.

Whatever configuration I have is immaterial, unless it can explain how someone can download 42MB out of 226.62MB and yet the "entire" file is now available. I repeat: the TOTAL upload for this file by all users is 42MB. Since it was only posted a day or two ago it is easy to confirm.

Perhaps I should provide some more background: I have shared dozens of files with hundreds of users, and downloaded several files for my own use. I have never ancountered this problem before, and it seems like something new. At least to me anyway.

Unless I misunderstand how the servers work, they only store file names and hashes, not content. In any case, I prefer to search on the KAD network because the servers don't seem to be that accurate.

The poisoned files I am referring to are NOT fake files that contain junk but with a misleading name. There seems to be rogue versions of emule that lie about the hashes (i.e. they claim to be providing sections of a legitimate file with a legitimate hash) but they send junk data in short bursts (way below the 8/9MB chunk size) and only once the entire chunk is accumulated do you discover that it's junk. I'm sure the rogue software also regularly changes its user id to avoid banning. Hpw else do you explain a dozen different users from the same ISP that appear in the download queue, enthusiastically share small sections of a file, then disconnect and disappear, only to reappear 10 minutes later with a different name and id, but still a 100% complete copy of the file.

I first experienced this with the 1.2GB file. When I started downloading it, there were around 20 out of 40 users who had successfully downloaded around 20% of the rar file, and one single user in the USA who had a complete copy of the file. Once I had caught up with the "pack" of 20 users who had downloaded the most so far, this percentagewas now close to 50%. A simple file preview established that the contents of the file were as described, and the MP3s that made up the audio book were complete.

By the time we got to 87% things changed. Firstly, the original poster was suddenly joined by a dozen or so users from a the same german ISP. They had miraculously jumped ahead of everyone else and had 100% of the file, except that every chunk that came from them was corrupt, and no amount of banning would stop these users from sharing their content. I would have liked to tell emule to ignore them completely and only download from the one user is the USA who appeared to have a legit copy, but that option isn't available.

Also, it wouln't surprise me if that user's queue was being poisoned by hundreds of requests for the file, because my place in his queue remained somewhere near the back.

The net result of all of this rogue activity was that there were 20 of us stuck on 87%, and all remaining downloads were corrupt. Hence my original post. I guess you'll have to experience it first hand before you believe me.

[Tuxman]

Sending corrupt parts is quite an old technique... however, how should eMule "know" about what's poisoned and what is not?

[WentloogWhix]

Tuxman, on 05 October 2009 - 05:18 PM, said:

Sending corrupt parts is quite an old technique... however, how should eMule "know" about what's poisoned and what is not?

As I said before,

• Restrict chunk sizes to much smaller pieces, say 2kB not 9MB
  
• Download a chunk from only one user, not multiple users
  
• use the full hash to check that the chunk is valid before sharing it to anyone else
  
• ban the user's IP address if it isn't valid

If the hash table doesn't identify each chunk as valid or not, then it's useless, especially for big files.

At this stage the first two restrictions are not being applied, making the checking meaningless.

Also, there is no facility where I can decide which source to choose from. I can't, for example, just download a file from someone I trust without also being forced to accept contributions from the rest of the mob.

[Wulp]

I think Andu is right: Most of what you request is alredy implemented.

WentloogWhix, on 04 October 2009 - 10:14 PM, said:

Before downloading the file we would have to download a complete hash table. From what I can see this happens at the end, not the beginning.

Do you mean the hashset, i.e. a set of hashes of every chunk? This is already done right after you added a download. As soon as you connect to a source, it sends you the hashset. Since the hashset must match the filehash, eMule can immediately check if the hashset is correct.

Quote

We would need to be able to download and check the hashes of much smaller pieces. 8MB is all very well when you have oodles of bandwidth, and you are assuming the file is OK, but isn't so great when you know that it could all be corrupt. Maybe 8kb would be better. Bittorrent seems to use even less.

Every chunk has a fixed size of 9.28 MB, except for the last chunk of a file. In case of corruption you might save more data by smaller chunks, but they wouuld also cause more overhead. I think BitTorrent uses dynamical chunk sizes where it can automatically specify smaller chunk sizes for smaller files and bigger sizes for bigger files. I can't say if this method is better. At least in eMule I suppose it would break with backwards compatibility, so it's not a simple matter.
Also, eMule already has it's "AICH" system which can detect a corruption with an accuracy of 180 kB AND provides the possibility to ban clients that send malicious data. The only downside is, the AICH hash which is needed for that is not always available in every case, so if you don't have this hash the system cannot work (but still corrupted chunks will be detected of course). (Read here for more about AICH.)

Quote

The entire chuink should only be downloaded from one user, so "blame" can be assigned if the chunk is corrupt, and the user can be distrusted. At present it is too easy to download an 8MB chunk from a dozen users. Which one do you blame if the chunk is corrupt?

See above, with AICH it is already possible to detect and ban the malicious clients. Moreover it would be quite a step back to limit downloading to one user per chunk, IMO.
I think it's interesting to know if from the problematic files you refer to you have the hashset and AICH hash.

I'm also not sure what you mean by model of trust or distrust. In the end the data you recieve must match the hash, otherwise it is beeing rejected. How much more distrustful can eMule be? And this has nothing to do with OSS, by the way

[Tuxman]

WentloogWhix, on 05 Oktober 2009 - 07:10 , said:

Restrict chunk sizes to much smaller pieces, say 2kB not 9MB

Sub-chunk transfer is not really compatible with the eD2K protocol's default chunk size.
(But it is available as an extension to it...)

WentloogWhix, on 05 Oktober 2009 - 07:10 , said:

Download a chunk from only one user, not multiple users

This may be a significant speed loss under some circumstances.

WentloogWhix, on 05 Oktober 2009 - 07:10 , said:

use the full hash to check that the chunk is valid before sharing it to anyone else

Hm, that's what AICH is about. Actually. Well, partially.

edit: Wulp was faster.

This post has been edited by Tuxman: 05 October 2009 - 05:15 PM

[WentloogWhix]

Andu, on 04 October 2009 - 09:43 PM, said:

I'm still looking for a single change that isn't already part of the client...

Are you referring to the eMule 0.49c client or the MorphXT client?

[WentloogWhix]

Tuxman, on 05 October 2009 - 06:14 PM, said:

This may be a significant speed loss under some circumstances.

Download the correct data slowly or download the wrong data at high speed. It's a tough choice.

Perhaps an option to go into a mode where I an super-suspicious of the data would provide the best of both worlds, i.e. after the first corrupt chunk is detected.

[WentloogWhix]

Wulp, on 05 October 2009 - 06:12 PM, said:

I think it's interesting to know if from the problematic files you refer to you have the hashset and AICH hash.

When I published my own file I included the complete hashset, and I was able to list the complete hashset of the corrupted file, so I guess the answer is yes.

So We’re In Agreement Maxim - said:

If you’re happy with your security, so are the bad guys.

see Vulnerability Assessment Team Security Maxims

It seems to me that everyone in this forum is quite happy with the hashing system as it stands, and that the level of trust is Ok, and we will just bypass any files that are being actively poisoned until the bad guys have completely broken the system. Or am I over-reacting?

To put my money where my mouth is: I will donate US$100 to the first version/mod of eMule that can successfully stop a poisoning attack, and allow me to block users from sending me stuff, and allow me to block them from receiving stuff, and not permit users to take or send partial chunks of data.

Contact me via this post or in private when you are ready to collect the money.

[Tuxman]

WentloogWhix, on 05 Oktober 2009 - 09:00 , said:

I will donate US$100 to the first version/mod of eMule that can successfully stop a poisoning attack

eMule already bans "poisoning" clients... and did you try recent Client Analyzer versions?

Quote

clients that are banned for sending corrupt parts by eMule are now stored for 60 days and banned on sight

Only an idea.

[WentloogWhix]

Tuxman, on 05 October 2009 - 08:09 PM, said:

eMule already bans "poisoning" clients... and did you try recent Client Analyzer versions?

er, which installer at http://sourceforge.n...ts/emule/files/ are you referring to? I have never heard of a "Client Analyzer" version. Just 0.49c

I will up my donation to US$150 if the anti-poisoning features I mentioned are included in the "base" eMule distribution, i.e eMule 0.49d or whatever. I am currently using eMule 0.49c Xtreme 7.2, and it didn't ban anything correctly, and allowed me to download 380MB of junk in one night. Not bad for a 1.2GB file. Considering I only get 3GB of download bandwidth per month, it's a pretty significant percentage.

[Wulp]

Ok. To follow your example from above:

WentloogWhix, on 04 October 2009 - 11:39 PM, said:

I have provided a complete hash set and the AIC Hash. I have only uploaded 47.34MB or the file, which I created, and yet the "entire" 226.62MB of the file can be downloaded. How is that possible, when I have now stopped sharing it?

If I'm not totally mistaken the official eMule never uploads unverified chunks. That means as long as you don't have a valid hashset for a downloading file (which is quite unusual) you won't upload any data of that file.
A malicious client however can of course always pretend that it has chunks available that it doesn't have in reality or replace them by corrupted chunks. But if someone with an official eMule downloads those corrupted chunks he will never spread them himself. Therefore this request is unfounded, because it's already implemented:

Quote

use the full hash to check that the chunk is valid before sharing it to anyone else

The next one:

Quote

ban the user's IP address if it isn't valid

This request is also implemented, though can only work when AICH hash is available which is not always the case (details are described in the link I posted above). So I don't know how much room there is for improvement.

But if AICH works then this one is also totally unnecessary:

Quote

Download a chunk from only one user, not multiple users

Given that supposedly 99% of all data is not corrupted it's also quite drastical and counterproductive means.

Remains the last one:

Quote

Restrict chunk sizes to much smaller pieces, say 2kB not 9MB

This might be reasonable but is also not without problems, as I stated above.

[WentloogWhix]

Given that the existing safeguards don't effectively stop poisoning attacks, what about the other aspects:

• successfully stop a poisoning attack, and
  
• allow me to block users from sending me stuff, and
  
• allow me to block them from receiving stuff, and
  
• not permit users to take or send partial chunks of data.
  
• download a chunk from only one user, not multiple users, once corrupted data is detected

FWIW, my emule client failed miserably to block the rogue users sending corrupted data because they didn't send an entire chunk, so it had no idea who to block, and didn't block anyone, not even the ones I manually asked it to block.

A 9MB chunk received contributions from over a dozen different rogue users, who continued to issue small pieces all night with impunity. How else did I end up downloading over 42 corrupted 9MB chunks? Or was I just downloading the same chunk 42 times over from the same group of rogue clients.

The malicious clients have found a way to break the system. That's why I'm asking for it to be fixed.

Even after I banned the ISPs entire IP range by manually editing the ipfilter.dat file, it was still impossible to download the file under attack, and other eMule 0.49c clients appeared to be stalled or distributing corrupted chunks.

This post has been edited by WentloogWhix: 05 October 2009 - 09:45 PM

[Andu]

I was referring to the official client. Except for the 'dl chunks from single sources' every single request is already in the client in one form or the other. The devs don't like manual bans so you won't be seeing those. Also dling chunks from single clients seems like a bad idea.

I think that 0.50a will be helping with your problem. From what I've gathered from the devs' posts the AICH is supposedly going to be strengthened and tied more into the network. Meaning that you'll probably be able to receive the AICH root hash for every file and therefore the effectiveness of such attacks will get less.

[GilesBathgate]

WentloogWhix, it seems to me that you are completly un-aware of AICH, as you have never acknowleged any posts regarding AICH.

[WentloogWhix]

GilesBathgate, on 06 October 2009 - 02:37 PM, said:

WentloogWhix, it seems to me that you are completly un-aware of AICH, as you have never acknowleged any posts regarding AICH.

You are mistaken, but only because the hashsets that I posted were edited out. Look at my second post. The second set ****** is where the full hashset was posted.

The AICH hash for the file that is no longer beiong shared is

WJHW2DVGBUVJYSHKP3BQHN3PWMSLTHL

and the complete hash set is along the lines of

237630536|C1DC8795FB69420D61DB3255B .... 346B6E8A35E9881:B1DE92AB6F491955B66763B1507DDC67:78D8D9329AB7504C22 ... 70C2AF94FA98:E3EEAF00724B4E30A2BD603A855C0093:BDAF47741C231EDEBBFCDAEEEDDC06D1:EEE015735CDE14E225F832B66D638657:5A9B7188C723D020D9AAF4B661596234:6296FC08E28 ... F9:F069FAE8FD22AB96A858BA68DC9C5445:53B82E0BECB1CF10357C9894DEE82160:71D33F031003B4FFE056F9CB54EEE980:C8B0BEEF31B1565B24DF884E9C2907D2:604A538A80369 ... EC32EAD6:35E1FDF2C85085CD6D11505FA5EE3434:FDB001AC5A8EBE10D94BE3D7DC3AB3F3

I have left out some pieces, but will gladly send you the complete hash set privately, given that it is useless and contains no copyrighted material whatsoever. Just random junk from rogue software.

I am conducting an experiment: I installed eMule 0.49c (from "eMule0.49c-Installer2.exe" from SourceForge) on a spare WindowsXP machine. It has never run eMule before. I added a request for the file referred to above, which I have on my main computer, but isn't shared. Only 47.34MB of the total 226.62MB file was ever shared.

At present the test machine is busy downloading this file. So far it has found 10 sources (i.e. 10 rogue copies of emule) and downloaded 1.01MB, getting a each of 344.42, 195.90, 57.33, 255.98, 10.41, 19.04 and 143.57kb from 7 of the 10 sources. I will report back what happens later, once we get to a more sizeable proportion of the file.

If the reassurances in this forum are to be believed, then eMule has the AICH hashes, as well as the rest of the complete hashset, and will detect that this is a fake copy of the file. I have taken some additional precautions, such as insisting on only obfustated connections, and adding an ipfilter.dat file that eliminates bogon IP addresses.

I will report back the results once they are in.

[WentloogWhix]

Part 13 was downloaded and is corrupt, so it was thrown out in its entirety. Good so far.

Screen shot on PicTiger

Now for the bad news: none of the corrupt sources have been blocked, and they continue to spew out their corrupt data, and eMule continues to accept it, no questions asked.

I guess this will continue indefinitely. Ah, the joys of infinite speed, unlimited bandwidth, and infinite trust. After all, nothing can go wrong, go wrong, go wrong ...

This post has been edited by WentloogWhix: 06 October 2009 - 08:11 PM