WinMX World :: Forum

WinMX World Community => Strategic Directions => Topic started by: MinersLantern on December 06, 2015, 10:16:48 am

Title: the WPN and the cure
Post by: MinersLantern on December 06, 2015, 10:16:48 am

Not much happening still.

Since it takes one person who knows how to attack the network to bring the entire thing down as it has been for years...

Maybe its time to open source the exploit(s) itself. Source code examples and heavily commented as to exactly how it works.

Since it takes only one to bring it down, what does it matter if its 10 or a thousand more?

The WPN has to change protocol anyway, why hang on protecting the old one which is dead?

At least with detailed information someone, somewhere will be more willing to alter things on their own for fun and fame if no other reason.

Title: Re: the WPN and the cure
Post by: TOAD on December 06, 2015, 10:20:34 am
I will bet any money it will be the same situation this time next year.
Title: Re: the WPN and the cure
Post by: GhostShip on December 06, 2015, 01:32:05 pm
I have been looking in the direction of changing the protocol for some time now, the problem is simply one of chicken and egg, if we go with a whole new client that's incompatible we may lose the remaining bulk of the userbase, when we have some thing that folks are happy with and take up is at least in the multiple thousands that will be a viable option however when your in our situation with minimal quantities of coders and a client that's lacking in a few areas still we would be foolish to undertake the path your suggesting.

I have written at least 5 new protocol update concepts and i usually run them past those here who have some idea of if they may be useful, some are seen as useful and some not so good however the main problem facing the the wpn as it currently sits is one of not being able to differentiate between valid and spoof packets passed along the TCP stream, this means the network is continuously being made to work itself to death and normal users traffic is dangerously low, if anyone published the protocol as it sits as KM did we can kiss whats left of the network goodbye, the only reason we still have a network is the distribution of the primary protocol was to existing WPN folks, simply tossing the last remaining support of the network into a pot wont help us, those that want the protocols and are willing to commit to doing something with it need only make a public statement here and they will receive that data and support, currently we have OurMX which is MFC C++ based and there exists a Winpy primary version that String wrote that could be updated that's written in python, if folks have the relevant skills then show yourselves, if not then please be patient, we have the network to lose and little to gain if theres no one ready to leap forward and offer their skills, if your not sure you have the skills required then drop me a line and I can show you material to get you started, this is a community exercise and those willing to take part are urged to, that's the way ahead.
Title: Re: the WPN and the cure
Post by: Plum on January 17, 2016, 05:58:11 am
That is why I've proposed doing a dual protocol arrangement. That way, the existing users can transfer to the newer system as convenient. They can select either a hardened WPN, the new one, or both. And you might be able to use the update broadcast feature to request that those who get the message to download OurMX. If you want to broaden the user base or at least hits more, you could even add G2 support (if you can create a version that follows the rules but adds sanity). But make sure the user can decide what their copy supports.

When you get a new protocol, you might want to ask for what versions and clients are supported by whatever peer/host. So if someone connects to the old one using the new one and finds those with the new one, then they are to communicate with them using solely the new protocol. (Same if you pick up a OMX user using G2.)

The thing to do with the TCP management is use a stateless approach. For instance, there is the "TCP cookies" approach where the address of the other guy is included in the time stamp. So no memory is used during the handshake in the event of junk TCP packets. This makes a minor but compatible change to the TCP protocol that will work regardless of whether the other party does it too. So you encode their IP in the timestamp or unique identifier to where when they return it to you, you can see that the 2 match, and do so using logic rather than memory (the ID *is* the memory).

Now, I already gave a way to tell that fake results are being sent. What you do is to have the UI, not just the protocol, do post result processing to see if what is returned is valid and meets the search criteria in any way. If not, it never goes into the results buffer. So similar to the TCP cookie approach, the goal is to make things as stateless as possible. You don't commit memory for anything unless you know it is valid. So this change will allow the original client to handle the garbage without crashing (though it will take quite a CPU hit). The old client committed everything to memory and had no sanity checks to see if any of it was what was being searched. It puts the sole duty for searching on the OTHER machine and blinding trusting the data.  But my approach is to search within the results immediately and only accept what is valid. And if you want to rule out fake file generating clients some, you send the search out to the network with a letter or 2 missing and THEN apply the original search to the results. So anything that was dynamically created, assuming you search for literal strings (and not an OR search), would tell on itself. So you might search for "Britney Spears", the protocol sends out "Britney Spea," and the UI or other code checks to see what comes in is "Britney Spears" before adding it to the results buffer. The dynamic fake makers won't know you are actually searching for "Britney Spears," and thus they send out the truncated results. But I just found one problem with that exact example. There might be a real file called "Britney Speach" or another celebrity named "Britney Spearhead." While that is not what you are looking for and should not be returned, you don't want to eject clients that truly actually contain other files with similar names. (If you use the intelligence of another client sending bad results to eject them for that session, then you only want to eject those that return shorter results than the original, not the same or longer. And if you want to keep an ejection list, keep it small, like the last 10 ejected IPs or something -- remember the principle of "as stateless as possible").

I agree that you don't want to publish specs for an immature protocol.