[DatHebIkWeer]

If a downloaded block is identified as corrupt by eMule it should log the userhash of the clients who uploaded (part of) it.
It should be possible to select a user and block it from further upload both from the logfile and from the downloads screen.
It would be great if eMule itself could identify malicious sources and autoblock them or show a warning.

I have a malicious uploader now who already uploaded 4.5 GB of corrupt blocks to me, and I have no means to stop it. I noticed that some blocks he only participated a few bytes in were also fully rejected by eMule. That means a malicious uploader can also cripple other peoples uploads.

[xilolee]

It is already banned (just for a session, i think) when you receive the correct masterhash from other (good) sources AND when the recovery packet is available from at least a good source...
Check this topic (click) to see what i mean

[DatHebIkWeer]

It is not banned. A malicious uploader can just keep uploading and eMule won't do anything about it. It will just keep requesting new data from the malicious host. The only thing eMule does is hash a block after download and see if it's good after download. Then if it is bad and eMule can retrieve good fragments it will. That is a great thing. The difficult job is being done by eMule.
What we need is the very simple thing of solving the problem at the source.
A client that persistently uploads bad data is malicious and needs to be blocked.

I have some more experience with intentionally malicious uploaders now. They can also download maliciously. They just keep downloading, requesting as much bandwidth as they can and do not seem to do anything with the downloaded data. The blocks they show don't change. This may be professional trolling by people who want to bring the system down.
We have to do everything we can to prevent this.


The simple solution is either an automatic or a manual block by user hash built in original eMule and every mod.

This block option should be possible for both uploading and downloading.
To prevent abuse it can be made so that downloading can only be blocked if uploading is also blocked.

[tHeWiZaRdOfDoS]

A "ban" is always a two-way block in eMule though I don't think that one should let users do that work, it should be done automatically.
eMule WILL ban clients if they transfer too many bad blocks but unfortunately this somehow fails in some cases (though it would be interesting to track WHY it fails) and for the ongoing downloads: who tells you that YOU transferred your blocks correctly and the remote client actually finished another chunk?


BTW: you could try a mod with my CA system as I store and re-ban corrupt part senders between restarts to prevent getting bad chunks again.

[DatHebIkWeer]

tHeWiZaRdOfDoS, on 20 July 2012 - 06:15 AM, said:

A "ban" is always a two-way block in eMule though I don't think that one should let users do that work, it should be done automatically.

That would be great.

tHeWiZaRdOfDoS, on 20 July 2012 - 06:15 AM, said:

eand for the ongoing downloads: who tells you that YOU transferred your blocks correctly and the remote client actually finished another chunk?

In my world and the world of eMule 0.50a the blocks I upload are tested good. But of course if another client uses a different hashing, upload or download method chunks I send may be perceived bad by him. In that case it would be wise if he banned me or got a proper version of the software. We have to do what has to be done sometimes with no hard feelings. We would have to investigate client compatibility if that happens.

A one way ban of malicious uploaders by the user would not be as dramatic as it sounds. It would not be some kind of cruel exclusion, it would just mean that the client would terminate the current download and not request new downloads from that peer for a while.
I found out that you can use the reask delay in some cases for this.
If a rogue uploader is the only one currently uploading a certain file, you can just pause that file and restart it. In that case the current download is terminated and the next one will only be queued in 20 minutes or so. So you save some network resources for a while.
A drawback of that is that you will also terminate good downloads if they are going at the same time. But I already did it in that case too, if the rogue uploader was going to upload a part of a chunk that was already being done by the good one. In some cases it is better to suffer a bit of delay by this termination than to have to see another uploaders good work destroyed.

I may in time try your mod. But it better be good .

[Birrell]

That is a great thing. The difficult job is being done by eMule.
What we need is the very simple thing of solving the problem at the source.
A client that persistently uploads bad data is malicious and needs to be blocked.
If a rogue uploader is the only one currently uploading a certain file, you can just pause that file and restart it. In that case the current download is terminated and the next one will only be queued in 20 minutes or so. So you save some network resources for a while.
A drawback of that is that you will also terminate good downloads if they are going at the same time. But I already did it in that case too, if the rogue uploader was going to upload a part of a chunk that was already being done by the good one.

This post has been edited by Birrell: 27 July 2012 - 03:09 AM