My personal ideas for a “safe” NEW WinMx file transfer system

[Hans-Linux]

It seems to me that seach bots are considered to be the problem. Their IP's can easily be recognised using “Wireshark” and examining the logs.  Most search bots are used by search engines like Google, Yahoo, Bing, Badu, etc and by the collectors and sellers of e-mai addresses.  I get hit on average 50,000 times each day by search bots, pings, port scanners, etc.

The real problem is that the search for files returns the wrong results!

This can only be fixed by modifying the WinMX network with NEW and SECURE Clients and Primaries, or modifying the Client and Primaries as required and blocking acces of non-patched Client and Primaries. 

I do not know the protocol and do not have the time to disassemble the WinMX program and analyse the resulting assembler code to find out.  The simple solution is to create replacement DLL for the Clients and Primaries that:
a) Verify that it the execution code has not been modified or patched in menory.
b) Verify and only forwards incoming search results that actially contain the search key
c) Sends a message to the blocklist that the IP no. falsifies search requests.
d) Checks frequently whether the blacklist has been updates and downloads the updated blacklist.

A professional programmer who has the well documented source code and other necessary information at hand can do this in few hours.

Hans

[White Stripes]

The real problem is that the search for files returns the wrong results!

current attack.... injects a search for "c:" when it sees a user search for something else..... ....winmx stores file list as full path so searching a drive letter returns everything that everyone is sharing on that drive... you could get the same results even if the attack wasnt happening by searching for "c:" yourself.....

or modifying the Client and Primaries as required and blocking acces of non-patched Client and Primaries.

this was done at one point but abandoned due to the problems it caused with 3rd party toys & utilities..... mainly chat servers....

b) Verify and only forwards incoming search results that actially contain the search key

im all for that one....

c) Sends a message to the blocklist that the IP no. falsifies search requests.

blocklist is only 'one way' .... downloaded list...

sending info about an ip that falsified search requests wouldnt work tho due to winmx itself blindly passing on what is fed to it.... so youd get completely innocent users mixed in there....

d) Checks frequently whether the blacklist has been updates and downloads the updated blacklist.

that ones already done....



the big problem is the blind passing of data.... winmx wasnt designed to work with anything but itself.... so a newer release with a new feature could pass data through an older version till ppl updated for instance... unfortunatly the weak crypto the program used was broken and 3rd party stuff flowed in and .... well .... you see what eventually happened with that....

this is a program with a circa 2002 'mindset' being used in 2011 without any real fixes from the dev (frontcode) before it was forced to abandon it by the riaa...

[GhostShip]

I don't agree stripes, many of the later fixes to the client where found under the hood, prior to the 3.54 series many areas of the client suffered from potential buffer overflow issues and much of the later work was to stabilise the client against this kind of attack as well as add a new library, the next step was to have been some improvements in delivering meta data for video files this much is clear when comparing the release changelog with the current protocol itself.

Step forward in time and for some years now its been possible to use a few new additions to the C++  libraries that offers a level of protection against buffer overflow attacks and this has been used in many later p2p clients to good effect, lack of coders and coding time are all that's missing in large numbers within our community and thus any project technically perfect or otherwise will still struggle to achieve its goals, we often ask for patience here but its not because we are sitting on our thumbs, its because we are doing what we can to deliver something the community can use and wont break down after 1 week.

My pet annoyance atm is that nothing I have posted here is new to forum readers, any time I spent here is time lost from the actual projects we are working on, so if possible please minimise my time here by assuming folks are working on the problem and wont be giving up, that will be the truth.

New ideas and implementational models are always going to be of benefit however the vast majority of the userbase is not looking for a whole new method of using winmx so please bear in mind that any new model has to at least fit some of the "perceived" parameters of the current client as otherwise we are simply suggesting utilising another p2p network and at that point its no longer the WinMX community by definition.

[White Stripes]

<sarcasm>oh so much wasted time, oh heavens to zill no....</sarcasm>

anyway, yes hans (and gs) there were minor bugfixes for buffer overflows in the 'file' and 'primary' side of things and a major overhaul on the chat..... other than that there is no real difference between the overall protocol first made in ~2002 and used in the 3.3 versions vs the circa 2004 3.5 versions... (which is why 3.31 can still work along side 3.53 and 3.54b4... and even chat with them... just not a pretty or very readable chat....) .....

the metadata function is moot at this point in time since frontcode is gone but would have been an example of the 'blind passthrough' of a 3.metadata version vs a 3.53 user to allow a painless update process....

with mx being 'frozen' at the last stable version; 3.53 the thing could theoretically be 'locked' at 3.53 (the 2k2 protocol w/ 2k4 chat revisions) to prevent attacks by dumping data that isnt 'right' till a clone comes out...
...hell of a lot easier said than done tho...

@gs the lack of coder interest isnt just limited to a lack of interest in winmx its a general lack of interest in the oldschool 'closed loop' p2p app style... a lot of coders are abandoning these old style projects.... even hearn himself is making a torrent app

and with hans having "'c' coder" in his sig perhaps he can throw something rather big into the bucket to help speed up your full retirement.... no harm in that is there? *grins*

[GhostShip]

Of course not Stripes anything that helps the community is all good with me and lets be fair, I have done more than my fair share here and deserve a well deserved retirement allowing the other here to set out their new ideas and continue to set their plans in motion, good things are around the corner for sure  

If things get too whacky legally maybe we should all take up building a torrent client like Kevin is continuing to do, however while the law is what it is there is nothing wrong with ensuring this network of friends is kept operational and those in the community who care enough to do so take up any job they can to facillitate the networks survival for the future, torrents are pretty much old school already so I dont see they are the way ahead but there are aspects of the technology that may prove helpful so please dont ever think our discussions are not fruitful to someone even it that someone is not myself.

[silicon_toad2000]

Though most of this conversation goes over my head, I'd just like to thank ghostship for delaying his retirement to help us where he can.
I was one of the members of the community who asked him to stick around and help with the fix.

[Bluey_412]

Hmmm...

I must ask, is the interoperability support for older versions, pre 3.53 part of the problem?

If that link was broken, would it simplify the fix for the current problems, or, could it even BE a part of the problem?

Ergo, what if all interoperability for those older versions was dispensed with, so we can concentrate on a fix that only works with 3.53 and later and for the stubborn (why?) users of those older versions, they get a splash screen on startup to tell them, update or it's 'game over'

@ Patrick: keep your insults to yourself, contribute at least constructive thoughts, or stick-it-in-yer-ear!

[White Stripes]

for the stubborn (why?)

quickmx... tho there is <self censored> for the 3.5 versions... also last fully functional version of bendmx works with 3.31.... ...eagles patch also works but the status display doesnt

ps... no im not using an old (or any for that matter) version of mx... just noting that that may be why cos it was the why for me for a while...

tho there are other bugs with the elden clients i dont think they would mess with the newer ones... 3.5x seems to soak up the attack just as well as an older client would... ....still an interesting question tho...

i dont think the splashscreen idea would work since 'hosts' fixes still would... the 3.3 specific variant would need to be blocked from connecting to 3.5 ... and  not just mx 3.3 but chat clients and servers that are '3.3' ... patch sniffs and if its not valid 3.5 traffic silently drop it...


now how well that would work i havent a clue....

[GhostShip]

All non 3.5x clients could in theory be blocked at the caches as they use a different packet number than the older clients for the initial key swap routine, currently the caches support both client types.

[Hans-Linux]

I noticed after reading all the comments that:

1) There is a strong reluctance to depart from the traditional WinMX user interface. This should be taken into consideration when thinking about replacing the WinMX 3.54 software with a new version incorporation a modern protocol and IP6 compatibility.
2) Many of the problems are caused by maintaining backward compatibility
3) Departing from backward compatibility should be no problem, provided the users of the current version are adequatly informed about any upgrade.

Questions:
1) How is the data obtained to update the Block List?
2) Is the Block List automatically or manually updated?
3) Is it possible to patch the Client and Primary part of the present WinMX version to reject search results that do not inculde at the beginning the path a string consisting of a letter [a~z or A~Z], a ':', a '\', a string and another '\'? for Windows users and /String/ for Linux users.
4) Hardcode the installation part of the application to include “\WinMX\data\” or “/WinMX/data/” into the down and upload directory tree.

I have since 20 years designed and coded close to the hardware command line application in“C”.  NO “C++”!  I am semi retirerd and can donate some time to help fix the current version and to create a new open source version of WinMX, but will not get involved in politics.

The forum administrator knows my email address.

Hans

[achilles]

Thank You Hans! If we could only find more coders like yourself to add to the community we could have the updated Client we have been waiting to see for the past several years now!

[White Stripes]

All non 3.5x clients could in theory be blocked at the caches as they use a different packet number than the older clients for the initial key swap routine, currently the caches support both client types.

still begs the question; are they causing additional harm in the first place?

1) How is the data obtained to update the Block List?

various.... see; https://forum.winmxworld.com/index.php?topic=10706.0.html

2) Is the Block List automatically or manually updated?

manually

3) Is it possible to patch the Client and Primary part of the present WinMX version to reject search results that do not inculde at the beginning the path a string consisting of a letter [a~z or A~Z], a ':', a '\', a string and another '\'? for Windows users and /String/ for Linux users.

ahhh... regex... but therein lie the problem.... current patch catches just ip addresses... not actual data packets...
ofc the latter is the desired modis operandi now but.... well....

4) Hardcode the installation part of the application to include “\WinMX\data\” or “/WinMX/data/” into the down and upload directory tree.

source to the original app is unavailable.... redirection of the .dat (config) files and file downloads would need to be done with dll injection too...

a new open source version of WinMX, but will not get involved in politics.

err... good luck with that....

since 20 years designed and coded close to the hardware command line application

DOS was in there somewhere wasnt it .... i miss DOS.... (if you go as far back as CP/M ill be even more impressed)

in“C”.  NO “C++”!

can i hug you? LMAO  ... microsofts .NET seems to be the choice of poison nowadays with C++ being the rarity....

[Hans-Linux]

I am just a long time user of WinMX and know nothing of the historical baggage and behind the scene infrastructure.

Reading about the Block List and comments,  I can only say, the solution for the community is to bite the sour apple, dump the historical baggage and move forward into the 22nd century.  Middle age tin armour can't protect against spend-uranium-tungsten  core armour piercing projectiles.

IMHO, the bittorrent protocol is today's best high and most reliable speed file transfer protocol. This is very well suited. The source, end-points and contents can quite easily be disguised by using a combination of encryption and Thor or Onion routing similar to what is used in spread spectrum combat communication systems. 

To aboid re-inventing the wheel, I would take a very close look at “GNUnet” specifications and source code, which is developed at German government expense by the Technical University of Munich.

My first programming job was in 1972 programming the first 8000 (1 bit) and 8004 (4 bit) microprocessor used in a HF HAM radio using a toggle switches.  DOS came with my first Japanese 8008 PC Clone in 1985 using the DOS Debug to write simple assembler code and BASIC.  Then new world arrived withTurbo “C”.  I still use it to occasionally code DOS applications for industrial controllers.  “NET, “#”, “C++” is crap. To much overhead.

Lets see if the WinMX community will continue to use “Tin Armour”.

Hans

[White Stripes]

I am just a long time user of WinMX and know nothing of the historical baggage and behind the scene infrastructure.

i didnt know how bad it was till i started using chat and forums after the shutdown.... hate to say it but if put on paper the historical drama of mx would span multiple volumes.... reading old forum posts (not on this site but elsewhere) there were some scary chat hacks back then (back then being v3.3x and possibly earlier)....

I can only say, the solution for the community is to bite the sour apple, dump the historical baggage and move forward into the 22nd century.

not sure if that will happen.... too many hardcore devotees....

IMHO, the bittorrent protocol is today's best high and most reliable speed file transfer protocol. This is very well suited. The source, end-points and contents can quite easily be disguised by using a combination of encryption and Thor or Onion routing similar to what is used in spread spectrum combat communication systems.

have to agree...

bittorrent and tor dont work too well together tho... but there is a bittorrent client that uses tor-like anonymisation at the expense of being incompatible with current torrent systems.... its name escapes me however but it was built around the vuze (azureus) client...

the 't' word is a bad word on this forum tho...

My first programming job was in 1972 programming the first 8000 (1 bit) and 8004 (4 bit) microprocessor used in a HF HAM radio using a toggle switches.

...wow...

DOS came with my first Japanese 8008 PC Clone in 1985 using the DOS Debug to write simple assembler code and BASIC.  Then new world arrived withTurbo “C”.

different machine different decade.... but i was playing with debug, basic, and borland turbo c (when borland released it as freeware) too.... windows95 came along and threw a wrench into the works..... linux came to my attention too late to get back in the game... ...had fun making the VGA card do 'silly tricks' (among other things) for a long while tho...

ahh.. and the commodore 64.... damn i wish i knew 6502 asm.... www.pouet.net keeps a good job of new neat stuff coming in for that machine tho...

To aboid re-inventing the wheel, I would take a very close look at “GNUnet” specifications and source code, which is developed at German government expense by the Technical University of Munich.

a mirad of f/oss p2p apps have been linked to... not much done about it tho....

Lets see if the WinMX community will continue to use “Tin Armour”.

too many 3rd party old apps that are no-longer developed but still very much in use would be lost if the backward compatibility, or main protocol were 'scrapped' for something else.... ....mix that with the hardcore holdouts and .... well.... you get a patch that has been in development since may... when the attacks started... and is still in development in august.... ....i wonder what things will be like in october....

[cuttingedge]

As you said yourself Hans, You have been a long time user of winMX....I look at it as the public swimming pool in the neighbor hood. The cute girls sit and sun them selves there, the kids splash around learning to swim, sometimes someone pisses in there! But there is still enough chlorine in the water to keep it safe....
 Torrents are great and been around for a bit, other p2p clients work but are not as user friendly as the MX user interface. Building a new client version that is tough by todays standards would be great, but it would have to have the same look and feel. Kinda like fuel injecting an old muscle car. 

[GhostShip]

The long term plan:
Some time ago it was suggested to build an open src client and being a common sense idea much progress was made in that arena after a decent period of research and the release of relevant educational material that was shared with many of the then existing community coders, the basic idea was to use some aspects of the wpn that winmx excels in and are familiar to the users but make critical upgrades to the network under the hood and over time restore some shine to a weary but popular network.

What went wrong:
Due to the selfishness of many attack supporters and the attackers themselves this project was shelved before it was completed and thus we all lost out as the project was not finally completed and made open src so that updates and upgrades could be made by those following after the initial src release.
Also many of the coders are proficient in some form of programming language its regretfully in using opposing or non compatible platform technologies and this has been a divisive problem too as many developers will only or can only code in their specific coding language thus meaning while it looks like there are many mx supporting folks to utilise there are not that many who can work together further add to the mixture a lack of trust and respect for others work and we can see why things where crawling along before the attacks put a halt to the whole project.

The future:
In my own view the future is going to be a simple road of clone the interface and create as much of the look and feel of the original client as possible and make key changes at intervals until the network can be improved and secured to a better standard, following this "safe" route will keep the community together and also give regular users a more transparent and expansive role in feature or improvement selection.
No one should  forget that the network is made up of many tens of thousands of folks and they will not always agree on all matters even if an idea is set out to make them safer thus public discussion is always going to be the way ahead and willing coders have to do their best to bend to the communities will where a coder might like a specific feature but the community do not, once again discussion is the way ahead.

I don't envisage we simply copy a bit torrent client/ network and call it a chat-less and search-less wpn, that would be a lie and one not acceptable here to most folks, however dht and other technologies are potential war winners if employed in some capacity within the wpn framework, we don't have only apples and oranges here to choose from so let us look at what we do have and work towards improving and then perhaps replacing the parts that are unsuitable for usage, lets keep discussing and looking for the best and only then should we look to migrate users, rushing into untested waters will see the thanks of no one if things go awry.

[cuttingedge]

Gs, what do you mean by "SRC" client? As in SRC Technologies the company? I guess i'm not familiar with the term other than in HTML as in "The .Jpeg goes here".

Just a thought....If you have a half constructed client, and Hans is willing to donate a bit of spare time, would this be something he might be able to get up and running or finish? I feel like having a team of coders becomes the problem cause, like you said they write different stuff and have their own set of ideas. As far as the community goes, we are lucky to have this at all! It could have been all over in 2005 and thats that. If one guy writes or modifies the client, it is what it is and the community will use what is given to them to use. I like the idea of keeping it winMX orientated and I am sure thats what most want out of all this.
 I think about it this way....This glitch, bug, attack, war, what ever you want to call it, is what will make this, no, force this network to grow and get tougher!
Just remember Bad publicity is still publicity, and suddenly because of the disturbance, users who ARE capable of creating and doing are coming out to say they want their winMX back. 
Keep it rolling, keep the conversation alive, ideas keep poping out, People keep coming forth with your knowledge, there is nothing the opposition can do about it! Let em all know were not going to sit back and let this crap happen to our community!  THE TIME IS NOW TO GET THIS GOING IN THE RIGHT DIRECTION!!!!!






Sorry I get excited some times 

[GhostShip]

No worries Cutting Edge 

By src I mean src code, the basic set of code instructions that form all computer programs, obviously if we have the src code to a clone winmx client we can over time improve and update in whatever direction is seen to be the most fruitful, our current problems all stem from the fact that no one has the src code for WinMX and thus a whole lot of effort has had to go into reinventing the wheel, this has never been something anyone here is shirking from but the model we proposed was to build a secondary client first and then move forward with a new primary backbone and thus keep the community in one mass,  a primary client implementation is not on the table yet but given time and coders theres no reason this need remain the case.

[cuttingedge]

Oh....The part of the .EXE that no one can seem to unlock....I see. When I look at the .EXE, I see all the redirects and alot of the easily read code. then theres the jibberish....
GS do you remember which version of MX had the window in the settings or options where you could see the jibberish and add code lines? 

[cuttingedge]

Ok the .rsrc in winmx 3.54 looks like the programmer was having fun.....


 0004DC80 ³ 00918C80 ³ ˆˆˆˆˆˆˆˆˆˆˆ   ˆˆˆˆˆˆˆˆˆˆˆˆˆ€ 0           ˆˆ»»»»»»»»»»»»pˆˆ;»»» ³
 0004DCC0 ³ 00918CC0 ³ »»»»»»»»»·ˆ;»»»»»»»»»»»»»ˆ;»»»»»· {»»»»»€;»»»»»° »»»»·€»»» ³
 0004DD00 ³ 00918D00 ³ »»° »»»»°ˆ »»»»»· {»»»»pˆ  ;»»»»»»»»»»»€  ;»»»»»»»»»·€  »» ³
 0004DD40 ³ 00918D40 ³ »»·»»»»°ˆ   »»»»³»»»»pˆ    ;»»»° »»»»€    ;»»»p {»»·€    » ³
 0004DD80 ³ 00918D80 ³ »»0 ;»»°ˆ     »»»  »»pˆ      ;»»  »»€      ;»»  »·€       ³
 0004DDC0 ³ 00918DC0 ³ »»  »°ˆ       »»  »pˆ        ;»p {»€        ;»»»»·€         ³
 0004DE00 ³ 00918E00 ³ »»»»°ˆ         »»»»pˆ          ;»»»€          ;»»·€          ³
 0004DE40 ³ 00918E40 ³  »»°ˆ           »»p€            ;·              3        ø   ³
 
Looks alot diffrent in PE explorer but the shapes are there.....Is that like a work of art????
I really wish I had a program that could make sense of that code but  I spose if one of us had that our troubles would be over.
GS, being part of Frontcode back in the day, how did you not have access to that important tidbit of incryption information?