Reverse Enginer WinMx

[cuttingedge]

I dont think its gonna pass.....It's too drastic and not very well thought out thankfully.

the same was said about the DMCA.... read some old news posts...

Even if it passed tomorrow, it wouldn't stop file trade P2P, it would more than likely create a larger user base!
You cant stop open nap, its gonna happen and word of a new .dll for the WPN would spread fast even now with the current client we use in the state it's in.
Under the current wording of the bill in the arguments, sites like youtube would have to make drastic changes, and run the risk of massive prosecution. Fines in excessive amounts that would probably shut them down.
Ultimately resulting is alot of people pissed, lots of civil rights cases in court, and alot more P2P.....
 

[achilles]

Hans, back to reverse engineering. Do you believe there is anything else to be gained by reverse engineering considering we are most likely going to create a new network with better protocols that is not going to be compatible with the old client anyways.  I believe the best option is to break compatibility to fix the problem. I've been saying this for many months, and I believe those that have the ability to fix the problem are beginning to accept that is our best option.  I can only see a positive outcome by doing so. Many months, and even years for some have been spent in trying to create a good compatible client for the WPN, but none of them have been able to fill the shoes of WinMx.  I think its time we used what we have learned, and use that knowledge to create something that is going to be secure for many years to come. Just make sure to give it that familiar WinMx look. 

[Hans-Linux]

Hans, back to reverse engineering. Do you believe there is anything else to be gained by reverse engineering considering we are most likely going to create a new network with better protocols that is not going to be compatible with the old client anyways.  I believe the best option is to break compatibility to fix the problem. I've been saying this for many months, and I believe those that have the ability to fix the problem are beginning to accept that is our best option.  I can only see a positive outcome by doing so. Many months, and even years for some have been spent in trying to create a good compatible client for the WPN, but none of them have been able to fill the shoes of WinMx.  I think its time we used what we have learned, and use that knowledge to create something that is going to be secure for many years to come. Just make sure to give it that familiar WinMx look. 

It's already there and available: GnuNet.

Just needs  a significant number of users, a nice WinMx style user interface with WinMx style bells and whistles and be ported to M$ Windows.

The biggest problem is to get full  community support.

I can not find any way to without breaking the WinMX protocol to add Large File (4GB+) and IP 6 support to WinMX.

Hans   

[achilles]

Hans, back to reverse engineering. Do you believe there is anything else to be gained by reverse engineering considering we are most likely going to create a new network with better protocols that is not going to be compatible with the old client anyways.  I believe the best option is to break compatibility to fix the problem. I've been saying this for many months, and I believe those that have the ability to fix the problem are beginning to accept that is our best option.  I can only see a positive outcome by doing so. Many months, and even years for some have been spent in trying to create a good compatible client for the WPN, but none of them have been able to fill the shoes of WinMx.  I think its time we used what we have learned, and use that knowledge to create something that is going to be secure for many years to come. Just make sure to give it that familiar WinMx look. 

It's already there and available: GnuNet.
Can it be made to support secondary connections for those that do not have much bandwidth to provide? Also, can a bundled installer be created for windows users? Its a complex task for most users just to figure out how to install GnuNet. The average user would not know what to do with the installer thus making it impossible for some to migrate over to the new network.

[achilles]

It's already there and available: GnuNet.

Just needs  a significant number of users, a nice WinMx style user interface with WinMx style bells and whistles and be ported to M$ Windows.

The biggest problem is to get full  community support.

I can not find any way to without breaking the WinMX protocol to add Large File (4GB+) and IP 6 support to WinMX.

Hans   

Can it be made to support secondary connections for those that do not have much bandwidth to provide? Also, can a bundled installer be created for windows users? Its a complex task for most users just to figure out how to install GnuNet. The average user would not know what to do with the installer thus making it impossible for most to migrate over to the new network.

[White Stripes]

Can it be made to support secondary connections for those that do not have much bandwidth to provide?

i think that would break it... and the team working on gnunet dont seem to have considered such a connection type..

Also, can a bundled installer be created for windows users?

there is one ... newest is 0.8 series... which may not be compatible with 0.9 cos it never found anyone.. at least not for me... ...tho 0.4 did once apon a time (granted that was the linux version... hmm...) ... couldnt transfer anything due to overhead tho..

Its a complex task for most users just to figure out how to install GnuNet. The average user would not know what to do with the installer thus making it impossible for most to migrate over to the new network.

gnunet is technically still alpha software (if they are using that type version numbering).... even the friendly manual has things in it that gnunet doesnt and vice versa....

[achilles]

yeah Stripes, i'm not really sure GnuNet would be the right thing for WinMx. Maybe similar protocols that GnuNet uses, but not the GnuNet platform itself. A cross between Ares, and WinMx might be a better option. I just hope they store the hash values on the local disk or in the user space instead of in the registry like Ares does. Ares has given me many problems about wanting to rehash my entire library each time I reboot my machine. I just hope all the coders are coming together as a team.

[White Stripes]

the protocol ares uses is a fork of gnutella... its not compatible in any way now but it was once apon a time based on gnutella...

...no reason the new winmx cant be a fork of the old one.... (use and evolve the good parts and toss the bad... esp considering the work that has gone into taking winmx apart it would be a bit of a shame to throw all that away... )

and yes it would be very nice for the data to be stored in a subdir of the %appdata% directory rather than the registry but i think ares has that holdover from the 9x days.... (i think its still possible to use ares on 9x .. granted a fully updated 98 or 98SE and ME but thats still technically 9x)

soulseek uses the registry too...

...its often been said that the windows registry was one of the 'worst inventions in computing' ever.... guess microsoft didnt think that specifying a directory where all those oldschool .ini files should go into (as apposed to the windows directory itself which is where most programs put them) would have been a better idea... ...registry was introduced in windows 3.1 but wasnt really seriously made use of until win95...

[cuttingedge]

...its often been said that the windows registry was one of the 'worst inventions in computing' ever.... guess microsoft didnt think that specifying a directory where all those oldschool .ini files should go into (as apposed to the windows directory itself which is where most programs put them) would have been a better idea... ...registry was introduced in windows 3.1 but wasnt really seriously made use of until win95...

I should have paid attention in class

[Hans-Linux]

Can it be made to support secondary connections for those that do not have much bandwidth to provide?

i think that would break it... and the team working on gnunet dont seem to have considered such a connection type..

Gnunet requires 64 MB (128 MB recommended) RAM when used in basic configuration. Network traffic depends on whether the client forwards other users packets or not. If the client is configured to only up and down load files and chat, the data flow is like that of WinMx.

I run WinMX as primary and have about 15KB in and 22 KB out data out without my up and down loads.

Also, can a bundled installer be created for windows users?

Piece of cake when the final product is ready for release. The Windows installer for CLEANER,EXE was the first Windows installer I ever made. It took me 15 minutes to create. 

there is one ... newest is 0.8 series... which may not be compatible with 0.9 cos it never found anyone.. at least not for me... ...tho 0.4 did once apon a time (granted that was the linux version... hmm...) ... couldnt transfer anything due to overhead tho..
The latest version is 0.9.1.

Its a complex task for most users just to figure out how to install GnuNet. The average user would not know what to do with the installer thus making it impossible for most to migrate over to the new network.

The downloads from the Gnunet website are for developers.  If you use OpenSuse you can use their RPM with a OneClick install to install the command line version of 0.9.0. With Gentoo, use "emerge gnunet".
 
gnunet is technically still alpha software (if they are using that type version numbering).... even the friendly manual has things in it that gnunet doesnt and vice versa....

I understand that Gnunet is a "Framework" for developers to provide anonymous  transport layer for file sharing, chat and Virtual Private Networks, The file sharing and chat plugin are samples.

Today there are 3 maintained open source network protocols actively used for file sharing. They are, sorted according traffic volume:
BIT-TORRENT
GNUTELLA-2
I2P
FTP and related

Hans 

[Will]

A new client could have an updated protocol while still supporting the old clients at the same time.

[achilles]

That is possible Will,  but if users are still running the old client then are they not opening a gateway for attackers to exploit the network? Unless your are talking about only running the old client as a secondary. If that's the case then can we keep users from running the old client as a primary?

[Will]

A new client could have protections against attacks and/or easily be updated if needed, but yes the current attacks would only actually affect those who are still using the official client. Primary connections can be blocked aswell if need be.

[Bluey_412]

Reverse engineering may well let us see where the holes and exploits are

But I had the thought, kinda like patching the wall constantly, while the rest of the house is old and creaky, should we not build a new house, with awareness of why that danged northern wall constantly needs patching

It may seem harder, but build the new client from scratch, with the protections and protocol reinforcing built right in. The WPN protocols can remain, tightened up against abuse, even +2Gb, IPV6 and other desirables built in. If a backward compatibility cannot be provided, tough titties.

I also liked the concept of 'Super Primaries' with current regular primaries dropping to a form of Senior Secondary, with limited interconnectivity, although that might make Cache modifications necessary. to encourage persistent secondary-only users to update, their searches and connections would become limited to the local primary ONLY, so a file residing on (user's S)---(P)-----(P)-----(remote S)  would become unreachable

I agree with Achilles, backward compatibility is not necessarily a good thing, heavens, it has caused M$ enough headaches, so if we break the old client, we break it. If a group wants to be truly stubborn and go it alone with the old, then they are on their own desert island. I dont think that even anything below 3.53 should be in use right now, but there are some using earlier versions, possibly even for injecting attacks (I recall certain questions in the help room almost a year ago, coinciding with the re-arrival of a certain individual. Hmmmmmmmmmmmm)

[cuttingedge]

Is there a way to make the WPN only accept packets from 3.53 and 3.54????
Might be a great thing to try....If it can be done, why not! That could buy some time to actually work on the new client with out all the rush rush.  Last 2 days have been pretty clean results, even if I get attack results it's been easy to disconnect and reconnect and get good searches. Also I think there is a recent increase of users. More than likely a migration from limewire. 

[Bluey_412]

When NB first reappeared, he was askin about stuff to do with one of the older versions, to use it to engineer an attack on pie.info, wanting to cause greif for Sabre and his crew...

Take time but i can trawl thru logs to find stuff...

[Hans-Linux]

Question:
Why have these clients never been completed:

WinPY
WinZo
MoonMX

Answer:
It's impossible to build a new client that can handle than 2 GB files AND is compatible with the existing WinMX protocol.

Those who claim this to be possible should publish or send me in private the details of the protocol modification.

Hans   


 

[Hans-Linux]

Is there a way to make the WPN only accept packets from 3.53 and 3.54????
Might be a great thing to try....If it can be done, why not! That could buy some time to actually work on the new client with out all the rush rush.  Last 2 days have been pretty clean results, even if I get attack results it's been easy to disconnect and reconnect and get good searches. Also I think there is a recent increase of users. More than likely a migration from limewire. 

Only possible for new user's by modifying ALL cache servers to reject all but 3.53 and higher. This will not cause primaries known to the users to reject them.

Hans 

[Hans-Linux]

Can anyone state the PRO'S and CON's of these open source protocols that run on top of the TCP-IP / UDP stack and used by the various P2P applications:

Bit-Torrent
Gnunet
Gnutella-2
I2p
Tor
VPN (Virtual Private Network)
WPN (WinMx Private Network)

I am not asking about the applications and their user interfaces using these protocols.

Hans 

[White Stripes]

I also liked the concept of 'Super Primaries' with current regular primaries dropping to a form of Senior Secondary, with limited interconnectivity,

gnutella gnutella-2 and ares does that.... (later versions of fasttrack did too... i think...) ... that is a '3 layer' network if thats what you mean...

Gnunet requires 64 MB (128 MB recommended) RAM when used in basic configuration. Network traffic depends on whether the client forwards other users packets or not. If the client is configured to only up and down load files and chat, the data flow is like that of WinMx.

got the ram requirements ok... it just never could find anyone... constant errors from curl about not being able to find a url or an incorrect protocol... but it would never say what url or protocol...  ...and 0.4 didnt have as many options as 0.8....

ps... please dont make a 'quote-post' that looks like i said something that i didnt....

so if we break the old client, we break it. If a group wants to be truly stubborn and go it alone with the old, then they are on their own desert island.

what happened to 'wheres your loyalty' .... no im not trying to start a flame war... just glad you see that in with the new and out with the old is whats really needed (in whatever form that may be)....

Unless your are talking about only running the old client as a secondary. If that's the case then can we keep users from running the old client as a primary?

all the mxmoni and '0 of 0' nuts will go nuts if they cant keep their old toy.... reducing them to secondary only would be a good start.... ....then again... forcing them to the new would either force them to place nice or play elsewhere.... which is also a good thing.... ....the days of 'trading' need to go... its 'sharing' time now...

Answer:
It's impossible to build a new client that can handle than 2 GB files AND is compatible with the existing WinMX protocol.

Those who claim this to be possible should publish or send me in private the details of the protocol modification.

those devs have basically disappeared.... the protocol can go to 4gig since the file size is a 32bit number (size in byres) with a 128bit hash.... its the client that goes nuts if more than 2gigs are fed to it.... even if the hash and file data are completely valid...

...of these open source protocols that run on top of the...

the WPN (winmx peer network... not 'private') is not open source... its proprietary and was (still is being?) reverse engineered... no documentation on the protocol was ever released by the author...

Is there a way to make the WPN only accept packets from 3.53 and 3.54????

yes and no... theres a way to prevent earlier versions from connecting to the wpn via peer cache settings but if the attack traffic is coming from custom software using a different method to connect its kinda hard to 'tell the difference' ....


@all;
sorry about this horridly scatterbrained reply/post.... but this thread got 'noisy' really quick lol...