aMule Forum
English => aMule Help => Topic started by: Olhado on August 21, 2009, 06:40:01 PM
-
I've got a huge problem with aMule 2.2.4 under Ubuntu. In short, some people can't download from me, which is a big issue because I'm a releaser. I had no idea what's going on until today, when someone told me that his or her ScarAngel eMule mode (which uses Dynamic Leecher Protection) has banned me because I'm using AppleJuice, or were using AJ in the past. This is totally puzzling to me, because I've never used it. In fact, I've never used another ed2k client on my system besides aMule straight from Ubuntu repositories. To my best knowledge, I've also never used AJ on my current IP, so I can't possibly be blocked based on that.
Does anyone have any idea what's going on and how I can fix it? I haven't upgraded to the newest aMule version because I prefer to use the one in Ubuntu repositories, but I can do that if it might possibly help...
-
Yell at the programmers of the ScarAngel mod?
-
Yell at the programmers of the ScarAngel mod?
I'd have to yell at the programmers of most mods, since most of them use DLP. Wouldn't it be wiser to yell at the programmers of aMule? ;)
-
Why would DLP block a source ?!?
I think your theory is all wrong, and it's rather related to something else. Some providers block default port 4662. Are you using that one ? Do you (and they) have protocol obfuscation enabled? Do you have "accept only obfuscated connections" activated? And so on...
-
I think your theory is all wrong, and it's rather related to something else.
It might be, but here's the exact message that the other user receives:
19/08/2009 20:25:31: [*AJ*](ban)- Client 195.206.112.113 'twoja mama [PL]' (aMule v2.2.4,Connecting/None/None)
("twoja mama [PL]" is my nick, of course).
As you can see, ScarAngel seems to ban me for using AJ. Now, I'm not saying that it simply bans aMule - if that was the case, far more users would've reported this problem (because many people have DLP turned on). I suspect that there's something in my config (I'm not using the default port by the way) that makes it look like I'm using AJ ???
-
Have a look at the dlp code and see what criteria there are to qualify as [*AJ*]. That's the easiest way to find out what might have happened.
-
Yell at the programmers of the ScarAngel mod?
I'd have to yell at the programmers of most mods, since most of them use DLP. Wouldn't it be wiser to yell at the programmers of aMule? ;)
We're doing nothing wrong, so sincerely, no. This is like saying it's wise to yell at Honda because your government decided that your car is a bicycle and bicycles are not allowed on the road. False positives are an inherent quality of poorly coded systems like DLP.
-
Yell at the programmers of the ScarAngel mod?
I'd have to yell at the programmers of most mods, since most of them use DLP. Wouldn't it be wiser to yell at the programmers of aMule? ;)
We're doing nothing wrong, so sincerely, no. This is like saying it's wise to yell at Honda because your government decided that your car is a bicycle and bicycles are not allowed on the road. False positives are an inherent quality of poorly coded systems like DLP.
But in your example, even if the government is at fault, Honda should still work very hard to get it to change its classification, because otherwise they're going to lose all their customers. I don't mean to sound arrogant, because I sympathize with you, but as a user, I'm not really interested in who's at fault here - it's a matter between the developers of aMule and the developers of DLP. The basic fact is that your product does not work the way I want it to work, and if I can't fix that easily, I'm going to look for a different product that does the job.
-
Aren't you forgetting something in your comparison? Like that you haven't paid us a dime for our "product", huh?
But I agree with you that if our client is banned my some mods, this must be looked at and fixed. Unless that mod bans everybody, there must be something we do different from eMule. (Or maybe it bans every client starting with "a" because it thinks it's applejuice.)
-
The basic fact is that your product does not work the way I want it to work, and if I can't fix that easily, I'm going to look for a different product that does the job.
The product works perfectly fine for what you want to do. It's the OTHER product that doesn't work.
Stu is right in that we should find out what it IS that is the difference, but more out of curiosity than anything else.
-
Haha, bIsApplejuice = (userhash[8] == AJByte);.
Looks like the AppleJuice detection code triggers on all other clients too with a probability of 1/256. :P
Try changing your userhash. (You will lose your credits though.)
Maybe we should import that Appljuice-detection and generate only userhashes that don't trigger it? And warn users with existing hashes?
if(thePrefs.GeTAntiLeecheruserhash() && HasValidHash())
{
PBYTE uhash=(PBYTE)GetUserHash();
LPCTSTR reason=theApp.dlp->DLPCheckUserhash(uhash);
if(reason)
{
BanLeecher(_T("*AJ*"),18);
return;
}
}
LPCTSTR __declspec(dllexport) DLPCheckUserhash(const PBYTE userhash)
{
int buflen;
BOOL bIsApplejuice = FALSE;
BYTE AJByte;
BYTE md5_hashval[16];
BYTE buffer[AJ_MD5_BUFFER_SIZE + 2]; // Need 2 extra bytes because _tprintf()
_TCHAR FormatString[] = L"@ppl" // adds a terminating UNICODE NULL char
L"%.2X%.2X%.2X%.2X%.2X%.2X%.2X%.2X"
L" uf€ablE "
L"%.2X%.2X%.2X%.2X%.2X%.2X%.2X"
L" 89";
buflen = _stprintf( (TCHAR *) buffer,
FormatString,
userhash[0], userhash[1], userhash[2], userhash[3],
userhash[4], userhash[5], userhash[6], userhash[7],
userhash[9], userhash[10], userhash[11], userhash[12],
userhash[13], userhash[14], userhash[15]
);
// Hash the data in the buffer using the MD5 algorithm
if (MD5_FUNCTION(buffer, buflen * sizeof(TCHAR), md5_hashval)) {
AJByte = ((md5_hashval[4] & 0x0F) << 4) | (md5_hashval[12] & 0x0F);
bIsApplejuice = (userhash[8] == AJByte);
}
//return bIsApplejuice;
if(bIsApplejuice)
return _T("*AJ*");
else
return NULL;
}
-
That is fucking retarded in so many ways.
-
Meaning no.
-
Aren't you forgetting something in your comparison? Like that you haven't paid us a dime for our "product", huh?
I know that I haven't. I'm not demanding anything for you, I'm just alerting you to a problem that I have with your creation (if it's not a product ;)).
But anyway - if what you write is true, and if I understand it correctly, then DLP is indeed seriously retarded, and aMule is not a factor in the equation at all, it's my hash. In fact, the situation is so absurd that I might try to contact the people responsible for DLP, or at least the people responsible for the ScarAngel mod, and try to learn their side of the story. Because if DLP really bans 1/256th of all clients, then someone has to do something about it :o
-
I've posted about it in the ScarAngel thread (http://forum.emule-project.net/index.php?showtopic=103882&view=findpost&p=1029491). Let's see what Stulle says about the issue.
And I'd call it "flawed". Calling buggy software "retarded" is not an attitude to be used towards a fellow developer of a similar project. ::)
-
But it is retarded. Flawed is when something is not working as intended, this is working as intended. It just so happens that the intention is retarded.
-
Also stulle knows me anyway HELLO STULLE.
-
Hi Kry, hi others,
I am aware of this flaw and so was Xman, who originally added this code to his DLP. He added it though to fight the AJ community. Now, like I said on the official eMule board, we might as well remove this code because i doubt there are many clients left that still use that technique to identify themselves. I will wait for some feedback from you and others on this idea and will then probably remove that code for future versions or if possible remove it from the DLP - I don't got it up me brains just now - and release a new version of that.
Greetings,
Stulle
PS: Kry, you're always hilarious!
-
Yay :D
I feel like I've been falsely accused and now I have a chance to fight for justice ;)
-
just to make sure everybody notices: i have released a new version of the DLP that removes the mentioned detection. i will subsequently - although probably nowhere really soon - remove the detection from MorphXT and StulleMule. clients using the DLP may simply update the Antileech.dll and make use of this change.
-
Stulle: Thanks for reacting so fast and being very constructive about the matter, I appreciate this.
Do you know if there are other checks with a high false positives rate in the code? I assume you know the code best, but could you please have another look? Thanks in advance.
-
I have set great events in motion ;)
Thanks :)
-
in fact i do not know that code very well. my only real contribution to the dlp is getting it released and doing the release build, all the rest is done by zz_fly - who took over the Xtreme project where Xman left it - and some of his contributors. the only reason i am taking care of the releases is that i am the only one with access to the SourceForge file release system for the eMule Xtreme project.
anyhow, i am positive that no other heuristic code will cause random clients to be punished without real reasons. there is some heuristic on random modstrings - which will probably only falsely trigger if somebody considers a random modstring to be the best name for his mod - and on HEX nick addons. the latter is again fairly safe because randomly adding HEX codes to the nick or making the nick entirely HEX is fairly stupid and seldome, imo.
keep in mind, i am not exactly familiar with all the heuristics and whatever detections. i am just writing from what i recall about it. if you want to be certain please review the code yourself and bring it up to me. when you want to bring something up please do it in a place i usually visit like emule-project so i won't miss it.
oh and about being swift with this, you're just lucky i am currently doing some coding and zz_fly had already done some work on the DLP or else it might have taken a lot longer. ;-)
-
Stulle, thank you for fixing it so quick ly! :D