"how to filter fakes" [mis]info

[guessed]

https://www.winmxworld.com/tutorials/filtering_fakes.html

"How To Fitler Fakes and Protect The Network"

petty typo:  Filter, not Fitler


"How to eliminate the fakes from your results:"

This claim implies fakes can be 'eliminated' by using certain steps.  Doubtful, perhaps reduced, but not eliminated.

The suggested 'trick':  add "-c: -user" to searches.  Then claims: "If you do search for ANY files without those you are helping the RIAA DOS attack our network.  "

poppy cock on both accounts.  If that ever worked, it doesn't now.. as the webpage assumes:  "Remember they [RIAA/MPAA] read forums also."  All the RIAA need do is fake random directories like "d:\shared\" to defeat the above.  And if they were using c: user, they aren't now.

I tested this by searching for "c: user" and got less than 1300 hits and all looked like real files from real users.  No apparent fakes at all.


Is the solution applying a simple block list?  i.e. https://www.winmxworld.com/files/block_list.txt ?

That seems to be a pie-in-the-sky claim too.  It is incredible that that is an exhaustive list.  I feel quite certain that RIAA resources does not limit them to such a paltry assortment of IPs.

It would seem ineffective to limit detection of fake file flooders to "a small group of individuals with several methods to log and gather the IPs of the flooders with fast and accurate results."  What we the people need are real automated tools, that can detect the fake file flooders and show their IP.

I think filtering fake file flooders is a great idea.. I am just not convinced that the current offerings of block lists and .DLL filters are all they are made out to be.  Sounds like they are over-hyped at this point.

[WinMX355_32548]

O.K., guessed, I'll try to go over your points there;

At this moment in time it is quite possible to effectively eliminate fakes from search results using the "-user" filter.  This is because nearly all, if not all, of the fakes being seen on the network at this moment in time reside on a "\user\files\" path.  By using "-user" you're omitting this path.

The "helping the RIAA DOS attack our network" aspect of not filtering is true in the sense that if a secondary user initiates a search query containing a string that matches any of the highly-faked files placed on the network, for instance "star wars", or "star", or "wars", the weight of search results returned by the network to the initiator of the search (the primary of which the secondary user is attached) can cause the primary to be overloaded in many ways due to inabilities to be able to handle the mass of incoming UDP datagrams (search results).  This is what you could define as a Denial of Service attack, or DOS, as the strength of the incoming search results can easily result in denial of service for the primary.

"All the RIAA need do is fake random directories like "d:\shared\" to defeat the above." - Yes, true, but at present they don't which is why the "-user" filter is effective.

Your error in searching for "c: user" is that the fakers do not run from C: drives.  At present they operate without any root drive information shown in accordance with the WinMX v3.54 protocol.  You also cannot search for only "user" and expect results, as the word "user" itself is filtered internally by the WinMX client (hard-coded).  If you want to see fake files, try searching for "\user\files\" next time (be sure to run as a primary when you do this so you yourself can 'reap the benefits' of such a search).

"Is the solution applying a simple block list?" "That seems to be a pie-in-the-sky claim too." - You sound like someone who knows little about what they are talking.  I'll assume your errors in understanding are related to an assumption that only 1 IP address could not possibly do any damage to a network of tens/hundreds of thousands of users, and that 40 or so addresses, equally so, could not impact against that.  You would be very wrong to think that if this is true.  I would ask you to consider that the media companies do not run legitimate WinMX clients that are limited to interfacing with the network in a typical way, rather, that they operate custom designed (and probably illegal (dmca violations, anyone?)) software that emulates a typical WinMX secondary protocol client but is by no means limited to a single connection to a primary user on the WPN.  Or, more plainly put, a legimate secondary client only ever initiates a single outbound TCP link into a single primary on the network, whereas the media company's system is designed to allow a single IP address, running custom client software, to connect out into 10's of thousands of primary users at once.  There is the error in your thinking.

As for "automated tools",  well yes, of course "real automated tools" sound like a brilliant idea.  You'll be sure to let everyone know when you have the system designed now, won't you?  O.K., in a less-arsey way: if you have any ideas that you feel could work in this regard, please by-all-means communicate your thoughts to others who may take those ideas into consideration.

Just to finish up with regards your last comment.  I'm sorry that you feel unconvinced that the DLL and associated filtering tactics are not as good as people purport them to be.  If you have any thoughts as to how any aspect of these methods could be improved then, again, please communicate them to others who can take those ideas into consideration.

Thanks for listening.

[guessed]

Your error in searching for "c: user" is that the fakers do not run from C: drives.

If this is the case, then why is it suggested to filter -c: ?


 

At present they operate without any root drive information shown in accordance with the WinMX v3.54 protocol.

If that is the case, could not this failure to match winmx protocol be used to auto-filter them?

You also cannot search for only "user" and expect results, as the word "user" itself is filtered internally by the WinMX client (hard-coded).

How can that be?  Why did I get 1200+ results when I searched for "c: user"?  I then enabled 'show full path' and all of the file had both c: and user in the path.

If you want to see fake files, try searching for "\user\files\" next time (be sure to run as a primary when you do this so you yourself can 'reap the benefits' of such a search).

That does in fact reveal fake file flooders.  Is \user\ treated differently internally than just 'user'?

"Is the solution applying a simple block list?" "That seems to be a pie-in-the-sky claim too." - You sound like someone who knows little about what they are talking.

Stating the obvious

 I'll assume your errors in understanding are related to an assumption that only 1 IP address could not possibly do any damage to a network of tens/hundreds of thousands of users, and that 40 or so addresses, equally so, could not impact against that.  You would be very wrong to think that if this is true.

I make no such assumption, but believe that the RIAA uses far more IPs than the few listed on the block list.

As for "automated tools",  well yes, of course "real automated tools" sound like a brilliant idea.  You'll be sure to let everyone know when you have the system designed now, won't you?  O.K., in a less-arsey way: if you have any ideas that you feel could work in this regard, please by-all-means communicate your thoughts to others who may take those ideas into consideration.

It should be obvious that that task is beyond my current capability, else I would be writing it instead of merely critiquing it.  But even though I am not a programmer, if I was provided enough details I just may be able to offer some ideas.

Just to finish up with regards your last comment.  I'm sorry that you feel unconvinced that the DLL and associated filtering tactics are not as good as people purport them to be.  If you have any thoughts as to how any aspect of these methods could be improved then, again, please communicate them to others who can take those ideas into consideration.

I don't think i was attacking the DLL per se, but rather the limited list of IPs that it filters.  not its design, but the current ability to detect and add the IPs of the current flooders to the block list.

As far as the winmx protocol is involved, is there a text that explains in detail just what happens, what data is transferred etc, when a search is done, when a browse is done, when a file download request is done etc.

https://www.winmxworld.com/tutorials/filtering_fakes.html gives an example of search results and then lists the source IP, from a covad connection.  What tools are needed to determine that IP?  If I do a search and find what appears to be a fake file flooder, as in the \user\files\ search, what then?  Would mx sniffer reveal the IP?  Is the IP linked internally to each search result/user name?  When I make a download request, is it sent directly to the UPload user's IP?  Or does it go through some circuitous routing like via my primary to their primary to them?

One obvious difficulty with all of this is that most of us do not have access to the winmx source code.  So some possible filtering ideas that could be added to a new compiled version are unlikely.  Rewriting a future client may be a long range solution but that to me would be a daunting task.

For the aspect you mention of one super-flooder IP making hundreds/thousands of connections to as many primaries might be to query primaries for suspect IPs.  If multiple primaries report back with matches.. bingo.  you have an IP to be added to the blocked list.

But I would go farther than just adding IPs to the block list..  Since I believe that such flooding is an illegal DoS attack, collecting evidence of this would be desirable for bringing legal acrtion against them.  Just as handicams have been useful in exposing many heinous police brutality cases, putting some similar automated tools in the hands of all users so as a group they can begin to document this flooding with date and time stamps, connections and IPs etc.. would help to bring it to a just end.

[WinMX355_56284]

Q: If this is the case, then why is it suggested to filter -c: ?
A: It's an out-of-date method now to filter using -c:.  I'll take a guess that the page was written in the past where fakes served from C: drives was common.

Q: If that is the case, could not this failure to match winmx protocol be used to auto-filter them?
A: They do follow the WPNP: the v3.54 version of the protocol.

Q: How can that be? Why did I get 1200+ results when I searched for "c: user"? I then enabled 'show full path' and all of the file had both c: and user in the path.
A: Because you used a combination query string containing both "C:" and "user".  The point I didn't make too clear was that, on their own, these strings would not return results as they are naturally filtered by the client.  The fact that the combination did return results, though no apparent fakes, is because the fakers do not meet the string criteria you searched for, because they operate under the v3.54 protocol of the WPNP which doesn't necessarily display root drives (drive C: in this case).

Q: That does in fact reveal fake file flooders. Is \user\ treated differently internally than just 'user'?
A:  Yeah.  The string "user" is filtered internally by the client, but "\user\" is not, in the same way "abuser" would not be filtered, either.

Q: Stating the obvious.
A: I would hope that one would have a solid understanding of something before criticising it.

Q: I make no such assumption, but believe that the RIAA uses far more IPs than the few listed on the block list.
A: Based on what grounds?  Because you just *think* they should/would/need to?

Q: I was provided enough details I just may be able to offer some ideas.
A: Best way is to learn for one's self in my opinion.  Don't let anyone else tell you 'how things are', be original, figure it out yourself.

Q: I don't think i was attacking the DLL per se, but rather the limited list of IPs that it filters.
A: If you are aware of other addresses that you feel should be included, shout them out.

Q: ...but the current ability to detect and add the IPs of the current flooders to the block list.
A: I think you should have some idea of how this could be done in a different/better way before laying criticism at current methods.

Q: As far as the winmx protocol is involved, is there a text that explains in detail just what happens, what data is transferred etc, when a search is done, when a browse is done, when a file download request is done etc.
A: Not really, that I'm aware of, but there are plenty of help sites out there that might.

Q: What tools are needed to determine that IP? If I do a search and... etc.
A: Lots of questions, many of which would take too much time to go into.  I'll leave the answers to these as an exercise for the reader.

HF.

[Me Here]

I have corrected the spelling errors on that page, and appreciate you mentioning them to us.  We try to be the best we can here in the information we give folks and honestly I make no bones about loving my spell checkers as I am a terrible speller, and quite fluent in typonese as well..lol

I have the -c: filter still on this site as you may or may not know it took months to get the information to folks pre Sept 20th about using the filters, and prior to that date we had two forms of flooding taking place.  One with a full path on a root drive of c: and the other on a WinMx 3.54b4 protocol of no root directory but instead a file path of \user\files\file name.

At this time its true its only necessary to use the -user filter to remove nearly 100% of fakes from your search results.

I have chosen not to change that page until a time when I am sure they dont revert back to the old habits, as its hard to get information out to the users fast enough to really protect connections and remove the fakes from the searches.

I would also like folks to keep in mind the 'fakes' we are talking about are not the occasional mislabeled file but only the fake data uploaded as lists of shares to primaries by the Media companies.

[guessed]

Still starving for internal workings of the process..

To test the theory of the current blocklist effectiveness, wouldn't it be possible to temporarily block the addys from accessing the peer cache servers?  [yes, this would involve the cooperation of all the cache server operators - which shouldn't be hard to get at least for a temporary proof of concept test right?  well..?]

Or wouldn't it be possible to monitor peer cache requests, to detect any IPs trying to make hundreds or thousands of connections?  maybe have a timed lockout, with escalating intervals for repeated attempts?

I'm still looking for answers...

If I have a screen full of fake files on a search.  What is an easy way for me to determine the flooders IP so I can report the same so it can be added to the block list?

A functional crude method?  I could activate a temporary firewall log, but once I know a flooders nick, what commands, PM?, browse?, download request?, whois?, would trigger a direct p2p responce so their IP would show on my firewall log?

[GhostShip]

Guessed, I,ll let you into an open secret, the fake uploaders connect as secondaries using TCP and do not even need to touch the peer caches, they are part of a high speed server network operated by Macrovision called Smokeblower.

The caches by the way are not designed to filter anyone or anything and as such are out of the equation.
Also, we would not in any case ask any of them to disrupt the network just to prove something we know the answer to.

While I understand your frustration regarding the mechanics of the blocklist you must be aware that any information given here could be used to attack its effectiveness and that unfortunately means we will not reveal the full system of operations publicly.

I hope you can see the common sense reasoning and respect the people doing the hard work, and perhaps find a little trust in them as the rest of the community does.

[guessed]

Guessed, I,ll let you into an open secret, the fake uploaders connect as secondaries using TCP and do not even need to touch the peer caches, they are part of a high speed server network operated by Macrovision called Smokeblower.

If we need to contact the peer cache servers in order to learn what primaries are available to attempt connects to, why don't they?  How do they know what primaries are available?

The caches by the way are not designed to filter anyone or anything and as such are out of the equation.
Also, we would not in any case ask any of them to disrupt the network just to prove something we know the answer to.

If they don't need the peer cache servers then obviously this would be a futility.

While I understand your frustration regarding the mechanics of the blocklist you must be aware that any information given here could be used to attack its effectiveness and that unfortunately means we will not reveal the full system of operations publicly.

I hope you can see the common sense reasoning and respect the people doing the hard work, and perhaps find a little trust in them as the rest of the community does.

I understand the need not to publish your methods of detecting and profiling the flooders.

What I wanted as to know a simple way to determine a flooders IP when I have a screen full of fake files and the nicks of the flooders.

[Bearded Blunder]

If we need to contact the peer cache servers in order to learn what primaries are available to attempt connects to, why don't they? How do they know what primaries are available?

They use their own custom networking tools and servers to find them.

What I wanted as to know a simple way to determine a flooders IP when I have a screen full of fake files and the nicks of the flooders.

I can't think of a really simple way off the top of my head, the hash numbers on a whois will return the node IP not theirs (the primary they are using to flood through).  Determining this would require using networking tools beyond the scope of a typical user.

[KM]

your client needs to use a peer cache to find primaries to connect to because it has been turned off so would have no way to know of any primary users that are online, a peer cache doesn't just go and ask another peer cache for primaries, it stays online all of the time so is able to find them itself and keep track of them - in case you hadn't noticed the flooders don't turn off at night, they stay on 24 hours a day, they keep track of primaries themselves and don't need someone else to do it for them

and as for the number of IP Addresses blocked by the block list - that is all of them (well, with the exception that it sometimes takes an hour or two to notice when they change one), they don't need to have thousands of computers running winmx to flood, they just run a single program on a single computer that connects to thousands of primaries, the fact that they have a handful of computers is more of a not putting all your eggs in one basket type thing

and btw, trying to have the client detect flooders automatically, as well as the obvious fact that an automatic solution would be more likely to block innocent users (as it can't use common sense) and it would be stuck using certain fixed rules to detect them that the flooders could just change how they operate to get past - there is also the fact that it wouldn't start blocking until after it had received a load of results from the floooders, and it's a bit too late then

[jszma]

so is the only thing we have to type is -user or should we still use -c: -user

[Me Here]

At this time the only useful filter is the -user

This is the one I would recommend and I use when searching, thats not to say they may not change this in the future, however for now it should work great!

[ñòóKýçrÕôK]

O.K., guessed, I'll try to go over your points there;

At this moment in time it is quite possible to effectively eliminate fakes from search results using the "-user" filter.  This is because nearly all, if not all, of the fakes being seen on the network at this moment in time reside on a "\user\files\" path.  By using "-user" you're omitting this path.

The "helping the RIAA DOS attack our network" aspect of not filtering is true in the sense that if a secondary user initiates a search query containing a string that matches any of the highly-faked files placed on the network, for instance "star wars", or "star", or "wars", the weight of search results returned by the network to the initiator of the search (the primary of which the secondary user is attached) can cause the primary to be overloaded in many ways due to inabilities to be able to handle the mass of incoming UDP datagrams (search results).  This is what you could define as a Denial of Service attack, or DOS, as the strength of the incoming search results can easily result in denial of service for the primary.

"All the RIAA need do is fake random directories like "d:\shared\" to defeat the above." - Yes, true, but at present they don't which is why the "-user" filter is effective.

Your error in searching for "c: user" is that the fakers do not run from C: drives.  At present they operate without any root drive information shown in accordance with the WinMx v3.54 protocol.  You also cannot search for only "user" and expect results, as the word "user" itself is filtered internally by the WinMx client (hard-coded).  If you want to see fake files, try searching for "\user\files\" next time (be sure to run as a primary when you do this so you yourself can 'reap the benefits' of such a search).

"Is the solution applying a simple block list?" "That seems to be a pie-in-the-sky claim too." - You sound like someone who knows little about what they are talking.  I'll assume your errors in understanding are related to an assumption that only 1 IP address could not possibly do any damage to a network of tens/hundreds of thousands of users, and that 40 or so addresses, equally so, could not impact against that.  You would be very wrong to think that if this is true.  I would ask you to consider that the media companies do not run legitimate WinMx clients that are limited to interfacing with the network in a typical way, rather, that they operate custom designed (and probably illegal (dmca violations, anyone?)) software that emulates a typical WinMx secondary protocol client but is by no means limited to a single connection to a primary user on the WPN.  Or, more plainly put, a legimate secondary client only ever initiates a single outbound TCP link into a single primary on the network, whereas the media company's system is designed to allow a single IP address, running custom client software, to connect out into 10's of thousands of primary users at once.  There is the error in your thinking.

As for "automated tools",  well yes, of course "real automated tools" sound like a brilliant idea.  You'll be sure to let everyone know when you have the system designed now, won't you?  O.K., in a less-arsey way: if you have any ideas that you feel could work in this regard, please by-all-means communicate your thoughts to others who may take those ideas into consideration.

Just to finish up with regards your last comment.  I'm sorry that you feel unconvinced that the DLL and associated filtering tactics are not as good as people purport them to be.  If you have any thoughts as to how any aspect of these methods could be improved then, again, please communicate them to others who can take those ideas into consideration.

Thanks for listening.

an excellent and very well put arguement