Author Topic: Reverse Enginer WinMx (Read 24387 times)

White Stripes · « **Reply #20 on:** December 22, 2011, 01:26:27 pm »

Quote

KCeasy was the one I think you where thinking of Stripes.

not quite... but close enough that i found the one i was thinking of called giFT...

http://gift.sourceforge.net/about.mhtml

KCeasy is one of the UIs for giFT .... and it seems the wpn2 plugin is nolonger available...

granted not that it matters considering v2 isnt in use anymore and hasnt been for... uh... ..... um..... yeah... that long... lol...

RebelMX · « **Reply #21 on:** December 22, 2011, 08:31:14 pm »

I too have a few worries/misgivings about this method of "attack"!
As GhostShip has stated, the protocol is almost completely documented. As such there are various clients that have already accomplished some of what Hans is attempting. I personally have got to stage 4 on Hans list, mainly concentrating on the primary protocol and client side, rather than file transfers as they are actually performed outside of the WPN network really (i.e. client to client directly).

On top of this, adding search filters OF ANY KIND is likely to open the program up to lawsuits as certain agencies will claim that its *possible* to therefore filter copyright protected software/files. This is a path that clearly noone really wants to walk...

On top of this the breach of license for use of WinMX as well as the C&D order sent to Kevin/Frontcode would to me, mean that any reverse engineering will likely result in a similar fate?

Don't get me wrong I'm all for progress, I just think perhaps this is a little bit too far at pushing the legal greyness, and some hard work put in to get there would be a bloody waste if some a$$hole agency suddenly closed your work, code, and documented protocol files down for ever Hans. Just my 10 pence worth.

Bluey_412 · « **Reply #22 on:** December 22, 2011, 08:33:46 pm »

Regarding Item 6 in Hans' list (Hans Liszt?), I have more than once experienced search results which contained no VISIBLE reference to the search term, but seemed likely, and upon closer exhamination, were either files in a subdirectory , revealed by 'Show Full Paths' or WinMX is reading and returning results with reference in mp3 metatags. Is this possible?

Bluey_412 · « **Reply #23 on:** December 22, 2011, 08:41:02 pm »

Richy have you viewed this?

https://forum.winmxworld.com/index.php?topic=11628.0.html

I think even the cartel may not really know much longer what is and is not theirs to claim rights over.

The current brawl in Congress over SOPA and IPROTECT could turn into a massive jellyfight and fail with less powers for the Cartel than before (We can but dream)

But, considering the doings of Congress lately, who knows?

Bluey_412 · « **Reply #24 on:** December 22, 2011, 08:42:57 pm »

Has anyone ever tried to contact Kevin/Frontcode, just to find out his attitude? Mebbe he doesn't give a flying fig about WinMX and would grant a release...

GhostShip · « **Reply #25 on:** December 23, 2011, 08:31:31 am »

Many have Bluey but he religously ignores all attempts. Whether this is for legal reasons or perhaps simply wanting to put the whole episode behind him, no one has ever had a response to their attempts to contact Frontcode Technologies or the newer entity WinMX Technologies.

Our own strategies are always based on this remaining to be the case.

Bluey_412 · « **Reply #26 on:** December 23, 2011, 10:14:50 am »

Which would make me think that WinMX per-se, could be classed as abandonware, in which case there should be no issue with the idea of decompiling etc, and making changes, whether ad-hoc or a full rebuild

I can see the point of what Hans is doing, particularly that his efforts could well discover the exploits that KM OR WHOMEVER have been using to cause disruption

An old legal axiom, which has been shown to operate with software too, is that for every loophole discovered and patched, 2 new loopholes are opened

If the WinMX clients can be rebuilt to virtually bulletproof status, then the WinMX NETWORK can also be suitably beefed, making it harder for external entities to cast their disruptive web

That REBUILD if done from scratch, would avoid the Loophole jeopardy mentioned above, so we could well end up with a network the old could only dream of. The basic protocols CAN remain the same, but yet the old clients will become incompatible, so I guess we will indeed have a 'New-WinMX' but if that needs to be the case, so be it

I think the best analogy I could come up with would be the constant repairing of a 1962 Morris so that it can indeed be registered and use the highways, versus the latest model Vauxhall VRX8 needing nothing except the same road... The poor old Morris is not a new, not even a restored car, just repaired.

Is that what WinMX has become?

Bluey_412 · « **Reply #27 on:** December 23, 2011, 10:19:09 am »

Indeed, is that what WinMX world is guarding?

Vive-la WinMX, by the way, and no, we dont want a WinMX torrent client

For those who want Torrents, with the speed and total lack of security and safety, Bit-Torrent et-al await

Lots of us LIKE the linear and 'behind the scenes' way WinMX slowly operates. Remember the 10% concept...

achilles · « **Reply #28 on:** December 23, 2011, 03:35:39 pm »

It's going to be interesting to see if reverse engineering can be successfully done to document all primary protocols. I don't see anything wrong in doing so, and I'm really excited to see someone that cares enough to attempt what I've been told is an extremely difficult thing to do.

GhostShip · « **Reply #29 on:** December 23, 2011, 10:35:34 pm »

I would just like to make it clear once more that we already have all the protocols winmx uses, I'm starting to wonder where all the effort in reinventing the wheel is heading. The architecture of the client that Hans has suggested is he stated based on a gnutella client and thus there is some scope for reusage of code elements in a WPN supporting client as both it and and the gnutella network share some basic characteristics, however there are differences that need adressing and I'm sure they will be if the project reaches that stage.

@Bluey, a list of exploits and the mechanisms behind them was issued in march to those who operate the network support infrastructure and those developers who asked for information that are known to us here. There are no mysteries in how any of the network attacks are undertaken, whats not so easy to approach is translating that knowledge and applying it to a static client that will then continue to be a target due to the defined nature of its protocol, the new client approach is really the best way ahead, there are some ideas that will allow a patch to be used in the short term but as you may have guessed that would be a limited lifespan fix and thus not the first choice of fixes to hold the attacker back with in the field.

achilles · « **Reply #30 on:** December 23, 2011, 11:53:09 pm »

GS, if I'm not mistaken we have had conversations in the last year about not having all the protocols to the primaries at hand. How long has WinMx world had documentation to all protocols to the primaries? If we do have all the protocols to the primaries then what's the need for using the patch to connect to the network for so long? If we have had that much information at hand I would have thought a new client with primary and secondary functionality could have been developed by now. Has all this information on the primary protocols been shared with Hans? How close are we to having a new client or to having a fix? Maybe Hans will discover something others have not that he can share with the community.

Hans-Linux · « **Reply #31 on:** December 24, 2011, 01:02:52 am »

After reading all the comments, studying the internals of WinMX and the protocol information available to me, I would be re-inventing the wheel. RebelMX has already done most of the work. I will therefore concentrate on designing and coding a secure file transfer client that can called from or linked into a new WinMX style client if the client provides the necessary information.

The only information I discovered while examing the decompiled code is that it is a messy patchwork adopted from a number of open source P2P clients and in my opinion can not be patched or otherwise utilised to build a bullet proof WinMx like client and be compatible with the existing primaries and secondaries. The only way to save the WinMX network is to build and switch the users to modern and secure infrastructure and multi platform client applications without historical baggage.

it will be wise for the WinMX community, including those in Japan, to put their heads together and find a solution that will accomplish this.

Hans

White Stripes · « **Reply #32 on:** December 24, 2011, 01:15:50 am »

Quote

RebelMX has already done most of the work.

um... ... he has done a bit but the majority was done by a collection of folks over a span of quite a bit of time...

Quote

it will be wise for the WinMX community, including those in Japan, to put their heads together and find a solution that will accomplish this.

unfortunatly it seems many in japan... the end users anyway... started talking about bittorrent and kinda... drifted off...

http://win-mx.4th.jp/

RebelMX · « **Reply #33 on:** December 24, 2011, 05:36:07 pm »

I too would like to reiterate that what I have completed, is really just pulling together all the information gathered by many people and putting it into working code.
That said, we have documentations on all the protocols used within WinMX, but there are still some gaps, and unknown packets. If these could be firmed up, either by packet sniffing or reverse engineering, I would like to see. I have some questions about oddities in some packets which currently are accepted as being how they are, but I believe actually have a different use in some bytes. Currently I am unable to find any packet results where they show differently to the docs but I am 100% sure there is a good reason for the packet being "weird".

White Stripes · « **Reply #34 on:** December 24, 2011, 07:07:33 pm »

Quote

Currently I am unable to find any packet results where they show differently to the docs but I am 100% sure there is a good reason for the packet being "weird".

'reserved' field filled with randomness that is ignored? .... considering the differences between 3.31 and 3.53 and then the differences between 3.53 and 3.54b4 the packets may simply be blanks that would have been fleshed out in 3.54 final and later versions with 3.53 simply being a 'bugfix' release with some blanks left in for future use...

RebelMX · « **Reply #35 on:** December 24, 2011, 09:40:57 pm »

Better than that even! Packets with fields that are null's. Most packets have nulls at the end, some seem to have 2 nulls...
These are packets used by all versions of the protocol so i doubt that when 3.31 was created it was planned to be filled out in 3.54? But perhaps so.

Lagerlout666 · « **Reply #36 on:** December 25, 2011, 02:06:11 am »

Or to keep would be lookers baffled as to WTF is that. As he was a pretty clever person was young Kevin.

achilles · « **Reply #37 on:** December 25, 2011, 06:17:49 am »

Is it possible to figure out what those mystery packets are using reverse engineering?

Hans-Linux · « **Reply #38 on:** December 25, 2011, 10:39:27 am »

Quote from: achilles on December 25, 2011, 06:17:49 am

Is it possible to figure out what those mystery packets are using reverse engineering?

You can figure it out by yourself. Just send me your e-mail address and you will get the "C" and assembler code. You can then run the assembler code through a suitable assembler and linker and the result will be a ,EXE. You can single step with a debugger such as WinGW or Microsoft
Visual C++ Express 2010 and learn the internals of WinMX, find what you are looking for, make changes and fix bugs.

You will need lots of time and patience.

Hans

achilles · « **Reply #39 on:** December 25, 2011, 12:52:03 pm »

Hans, I'm not a coder. Even though I somewhat understand what you are informing me to do I would not have the ability to make bug fixes. My ability to code in C is very basic. I will say the same thing I have been saying since I joined this forum. The best solution to save the WinMx network is to create a new client as similar to the old one as possible, but with updated more secure protocols. That would mean breaking compatibility with the old client & old network. Then have the user base migrate over to the new network. The users are what make up the network, and I gurantee you will not have any problem convincing the users to migrate to the new client considering the state of our current network. The only requirement I believe to make this successful is to make the look, and feel of the new client as much like the old one as possible. The GUI needs to be comparably similar to the old, and the client needs to provide the same functionality as the old. Many improvements and add-ons could be made like like doing away with the 2gb file cap, better hashing, showing duplicate file search results of files already in the users library, leach protection, etc.. Well I'm at work on my iPhone so I must go. Can chat more later.