[Stulle]

yes, you understood correctly that a list needs to be maintained. that was the major reason for making this a easily exchangable dll file.

it is further right that how a list is used is up to the implementation, however, not any implementation is allowed because of the statement that is checked for. a whitelist implies "the client in question is not known to be good and thus we need to assume it is bad". a blacklist - which is implemented in the dlp - however says the client in question is bad" upon punishment.

the check you questioned earlier is a different approach. it will check for mod behaviour - quite like the CA - and check if a set of given clients behave as expected. althogh this method is using name and modstring rather than some other figures the CA makes use of. the list is thus not a whitelist but just a list that ensures we are not trying to judge any client by the same behaviour even though they might not show this behaviour normally. the clients within the list, however, do show just this behaviour and are thus checked for this specific behaviour.

to ensure we understand each other, with the specific behaviour i do mean sending the modversion within the name for verification. notable is that there is the - by now well known - exception of eMule MorphXT's workarround.

[taz-me]

1. I'll start with a trivial thing : leecher wanting to download from us, will probably want to be identified by us as another client (source) - and from it's point of view probably as the one we downloaded the most from (thus be given a high credit by us - if we don't identify it). Current detection of nick thief (and thus fakers or mod thief - which is highly dependent on at least on CA) is based on our own nick - which is not that relevant (as long as that client doesn't change identity - if he does then the below might be somthing to think of), if the above is correct.
Code sharing between CA & DLP that will enable detection of other (i.e. not ours) nick thieves should provide a better platform (although it means longer lists - currently available only on CA. Due to CA's logic of random additions to nick - sharing nick thief identification is problematic (so problematic - that if CA client starts a new session, after the time block factor even if the leecher keeps our nick - leecher might earn one free ride).

2. If larger scale maintained lists are acceptable checks for "ancient" (pre current official) mod versions against last official version can be considered, or for even larger scale list an accurate check of mod version against it original official (WiZ idea).

3. Another idea not related to lists : (an alike to "bad shareaza") mods with enabled obfuscation based on "ancient" offical...

[Stulle]

1. you are mixing things up. this is not about nick thieves, this is about mod thieve code that is used for distinguishing between clients behaving as expected and behaving unexpected. this thread is dedicated to increasing the capability of the DLP and not about it being a good system or not. i have told you this in the past and i urge you not to drive discussion anywhere else than i just said, which is - again - the improvement of the DLP by means of additional strings to check for, removing wrong positives and devising new legit methods to be implemented in the DLP.

2. i have no idea what you are talking about. if you suggest checking if a client holds the right emule version number when sending a modstring is of course fine unless it triggers false positives. such a check will thus have to be like "MorphXT 11.2 and 11.3 are based on 0.49c, 11.1. is based on 0.49b" and so forth. checking just for a minimum version might be okay but i don't like it too much and you proved exactly why, because we never know what happens in the future. thus is the check implemented by zz_fly well sufficient.

3. something like this has already been implemented. i think it is used to figure out xunlei clients or something and was originally coded by dolphin, iirc. it will check if a "pretend-to-be-old" client sends packets he should not be sending. if you suggest anything else provide me with code for it and some logging that shows this code is actually finding leechers doing this.

[taz-me]

Stulle, on 28 January 2010 - 07:23 PM, said:

1. you are mixing things up. this is not about nick thieves, this is about mod thieve code that is used for distinguishing between clients behaving as expected and behaving unexpected. this thread is dedicated to increasing the capability of the DLP and not about it being a good system or not. i have told you this in the past and i urge you not to drive discussion anywhere else than i just said, which is - again - the improvement of the DLP by means of additional strings to check for, removing wrong positives and devising new legit methods to be implemented in the DLP.

All I ment falls within your definition : possible shared code for nick thieves - that will enable to identify nick thieves of other clients (stolen nicks of others not our own), perhaps via adding not a full random tags to nick (as it is done in current CA) but something based on hash for SUI detected clients (I'm under qualified for suggesting coding it - however if idea is worthy, I'm sure it can be coded).

Quote

2. i have no idea what you are talking about. if you suggest checking if a client holds the right emule version number when sending a modstring is of course fine unless it triggers false positives. such a check will thus have to be like "MorphXT 11.2 and 11.3 are based on 0.49c, 11.1. is based on 0.49b" and so forth. checking just for a minimum version might be okay but i don't like it too much and you proved exactly why, because we never know what happens in the future. thus is the check implemented by zz_fly well sufficient.

Both full list or short one (min version) can be done upon modders expressing their wish for check against their mods (and sending the versions to be checked) - however it's up to you (and or zz_fly) to do with any suggestion what you find appropriate.

[Stulle]

1. this is not making any sense to me. there is no way we can figure out if other clients are stealing the nick of other people. besides, that would not make any sense for them. i suggest you think about how nick thieves work and why they are even doing what they do.

2. i don't like it and i don't see much point in it. not speaking for zz_fly, though.

This post has been edited by Stulle: 28 January 2010 - 05:58 PM

[taz-me]

Stulle, on 28 January 2010 - 07:58 PM, said:

1. this is not making any sense to me. there is no way we can figure out if other clients are stealing the nick of other people. besides, that would not make any sense for them. i suggest you think about how nick thieves work and why they are even doing what they do.

Regardless of nick theft reason : If a client (with forced enabled SUI) equipped with a code based on what I offered will send his nick with tags based on his hash, nick thief leecher of his nick can be detected by other clients with such a code (his lack of SUI, or hash that doesn't match the tags added to the nick if leecher enabled SUI).

[Stulle]

i have no idea what you are talking about. nick, hash and SUI are all unrelated to each other! rephrase that or - if possible - get somebody to translate it for you!

[jerryBG]

taz-me, on 28 January 2010 - 07:38 PM, said:

Stulle, on 28 January 2010 - 07:58 PM, said:

1. this is not making any sense to me. there is no way we can figure out if other clients are stealing the nick of other people. besides, that would not make any sense for them. i suggest you think about how nick thieves work and why they are even doing what they do.

Regardless of nick theft reason : If a client (with forced enabled SUI) equipped with a code based on what I offered will send his nick with tags based on his hash, nick thief leecher of his nick can be detected by other clients with such a code (his lack of SUI, or hash that doesn't match the tags added to the nick if leecher enabled SUI).

as far as i know, if you use the mod equiped with Nickthief, your mod sends to each user the exact same/mirrored nick string of the appropriate user, so, to you it will always appear only as "you" 

[taz-me]

I'll try to give sort of an example :

Agreed upon nick tag prefix : pre
Agreed upon nick tag postfix : ost
1. Our nick : kiki, hash : 1234567890, our mod : lulu - we are with SUI enabled
2. We send as nick [pre1234]kiki[7890ost]
3. Any mod (including our own - to answer jerryBG) with our new code will check new clients for tags in nick [preXXXX]YYYY[ZZZZost] : if found (should be decided whether to check if detected modstr will be checked aginst list of mods with feature) - if SUI off (of detected client) it's a nick thief, if SUI on (of detected client) compare detected hash against XXXX??ZZZZ no match - nick thief.


the legth of XXXX, ZZZZ (both take from hash) as well as tag prefix, tag postfix and if desired checking modstr being included in list are to be implemented the same on mods with this detection code (being DLP or CA based mods).

This way any client with code can detect nick thieves of all other clients with code (including thives of it's own nick).

[jerryBG]

taz-me, on 28 January 2010 - 09:38 PM, said:

This way any client with code can detect nick thieves of all other clients with code (including thives of it's own nick).

the detection method is pretty clear, the nickthief-user would have to mirror your hash as well to get thru, you've replaced the random generation of tags with the dependance on userhash, clear, but you are still talking about being able to detect the theft act of one remote user to another, which can't be, since remote nickthief-user will appear to you always as nickthief of YOUR OWN nick only.

this claim of yours leaves very confusing(at least) impression.

[Stulle]

nope, that won't do. the only problem with nickthieves is that some use smarter methods by now which don't mirror blindly. making the system rely on something else than a random string will only cause the bad modders to not mirror that new string. we gain nothing.

anyway, you are still not making lots of sense in your explanation, especially keeping in mind what jerryBG just stressed, nick thieves show us what we sent them in order to gain benefit. they will not show us anything they have "stolen" from other clients. the whole idea is mirroring!

[taz-me]

About idetifying faked mods via checks of modstr versions against their "correct" official version :

Idea abondoned due to statistical data collected over 3 days (Since "war" started - I took the liberty of using myself and giving one of my beta testers a private beta - same as 1 however with entries of older official versions (for MorphXT I've used 9.0 based on 0.47c), even sent him to download some porn - so that not only Israelli leechers will be candidates for identify). In theory more (since if official version was sent and not copied - it was likely that last official was sent) "bad guys" should have been identified - however none identified ...

Stulle, on 28 January 2010 - 11:28 PM, said:

nick thieves show us what we sent them in order to gain benefit. they will not show us anything they have "stolen" from other clients. the whole idea is mirroring!

I'll get more data (looking for tags within nicks that are not the same as the data collectors) - to figure if idea can lead to new detections.

[Stulle]

many "modern" leecher mods also allow the client version to be mirrored/stolen. that leaves of course a huge opening for detecting the leecher because of not supporting new protocol features but then, there needs to be a new protocol part that we can judge this upon.

[taz-me]

Some ideas, (some are sort of recycled however not exactly as before). Some / all of them are candidates for both CA as well as DLP (no dedicated CA thread). Since some code used in DLP was coded by WiZ, and stuff from DLP is used as sort of enhancement by CA - perhaps this thread could serve both ...

I'll try to categories them :

1. pure "official" related missing opcodes / tags : for leechers not sending modstr (from collected data - at some points random modstr senders are not sending modstr), if found worthy for implementation - check should included version being upto 0.49c (one can't tell content of future official versions):

a. LOW2HIGH
b. ICS

(it might be also worthy to check for popular mods without these features, which their modstr is sent by leechers - due to being a mod thief or due to user selectable modstr).

2. leechers based on certain official version (the idea is recycled) :

a. source exchange protocol version

list is likely to get longer ...

[Stulle]

1. i don't understand that. it seems to me you are suggesting punishing clients sending certain opcodes but no modstring. that is already done.

2. i don't get that either. explain.

[taz-me]

Stulle, on 05 February 2010 - 08:26 PM, said:

1. i don't understand that. it seems to me you are suggesting punishing clients sending certain opcodes but no modstring. that is already done.

I wasn't sure whether these opcodes (those are used by legit mods - but not by official) are addressed as well.

Quote

2. i don't get that either. explain.

If I'm not mistaken current source exchange protocol version is 4, mods based on old official versions (which supported lower
source exchange protocol versions) shouldn't be using version 4.

[Stulle]

hmmm yeah, that is true. however, did you ever see any old mod "supporting" new source exchange? i don't think there is much sense checking for this is there will never be a positive. it would be an utter waste. also note that this is not directly related to the DLP but rather to the anti-leecher-system in general because all these checks can only be performed within the program and not within the DLP.

[taz-me]

Stulle, on 06 February 2010 - 10:49 AM, said:

i don't think there is much sense checking for this is there will never be a positive. it would be an utter waste. also note that this is not directly related to the DLP but rather to the anti-leecher-system in general because all these checks can only be performed within the program and not within the DLP.

I haven't been visiting or using leechery related stuff for quite some years, but at the time there were quite a lot of leecher mods letting the user set the sent modstr. Re-thinking it is (again) related to lists of mods versions versus official versions (with or without specific protocol or feature changes). On the other hand even without lists, it can assist to identify mod thieves (i.e. any client sending modstr indicating official that should support source exchange protocol version 4 - however via protocol dialog turned out to support lower version, can be "framed" as mod thief).

About such stuff being rather general anit leecher and not DLP - you are right (it might be worth to open a subforum or a topic dedicated to anti-leecher-system under "emule development", with or without shifting DLP topic there - for all I care, you might as well be given moderator power on that subforum if wished).

[Stulle]

the question remains, will there be valid positives. i doubt it because if a user sets the mod string to some other mod i doubt it will be an outdated mod. thus would it be nice to get some researched material on this giving some detail on if there are actually leechers to be found with this method.

there are numerous ways leechers/bad clients could be distinguished from legit but many will probably never get any positive results. setting up checks for any possibility when only one or two possibilities actually occur is a shitload of work that has little use and uses up computer ressources.

[feathia]

Hi everybody, we chinese emule fans find a mod named eMule v0.49c [eMule-GIFC 1.0].It's based on StulleMule, but we can't find the source. We think it must be a GPL breaker. And some friends also find some badly things on this mod.

The mod's adress is here: http://code.google.c...fc/updates/list

Sorry for my poor English, thanks.

This post has been edited by feathia: 22 February 2010 - 02:10 PM