Author Topic: Reverse Enginer WinMx (Read 24324 times)

Hans-Linux · « **on:** December 17, 2011, 06:38:13 am »

I obtained access to professional reverse engineering tools to assist me with reverse engineering WinMx.exe and DLL's.

The toughest part is unpacking and decrypting the actual WinMx executable which is protected by a Unpacker apparently falsely labelled "PKLITE32" or added a number of booby traps..

Before re-inventing the wheel, has anyone previously unpacked the actual WinMx executable?
If yes, what tools where used.?

Hans

Bieb · « **Reply #1 on:** December 17, 2011, 11:50:07 am »

httpss://archive.winmxworld.com/WinMX/Special%20Versions/

Hans-Linux · « **Reply #2 on:** December 17, 2011, 11:01:52 pm »

Thanks,
This has saved me lots of work.
The resulting .ASM file is 31 MB, has 218 functions and 3,000+ labels.
The pseudo code file is 4.2 MB.
Next step is to make the .ASM file compilable or port the pseudo code file to C.

Any Helpers?

Hans

achilles · « **Reply #3 on:** December 17, 2011, 11:42:40 pm »

Good luck Hans-Linux! I hope more coders like yourself get involved with WinMx. I miss my favorite P2P network! I believe one day soon we will see the network more secure, and better than ever before.

Bluey_412 · « **Reply #4 on:** December 18, 2011, 10:58:17 am »

Damn wishing that coding was one of my areas of expertise, but ahh well, we need hardware and network gurus too

Hans-Linux · « **Reply #5 on:** December 19, 2011, 11:41:33 am »

Quote from: Bluey_412 on December 18, 2011, 10:58:17 am

Damn wishing that coding was one of my areas of expertise, but ahh well, we need hardware and network gurus too

What are your areas of expertise?
Hans

Bluey_412 · « **Reply #6 on:** December 19, 2011, 12:00:01 pm »

System Troubleshooting & Hardware, and understanding the networks side o stuff, I hold a Dip IT for PC & network support

achilles · « **Reply #7 on:** December 19, 2011, 02:45:42 pm »

I have returned to school again, and I'm working on a degree in network & database security. I have a degree in Spanish now. I wish there was more I could do to help!

White Stripes · « **Reply #8 on:** December 19, 2011, 03:53:44 pm »

borland pascal + mfc (microsoft foundation classes) -> ASM -> ansi C ....

i dunno if this classifies as 'leet coding skills' or masochism... o.O

GhostShip · « **Reply #9 on:** December 20, 2011, 08:40:18 am »

Its not actually necessary to undertake reversing WinMX its a lot simpler to build a new clone using MFC and MDI for the window styles and then use the generic MxSocket stuff that's laying around, I also feel its wrong to tear apart Kevin/Frontcodes work when we already have the protocol to hand and thus the means to rebuild a completely new client given the coders, I'm also not sure rewriting a MFC (ATL/Com) based program in plain C is going to end up with anything familiar to anyone, but if folks want to go that route then I wish them good luck, despite my misgivings on the matter or breaking the WinMX licence agreement to do so.

Hans-Linux · « **Reply #10 on:** December 20, 2011, 12:09:14 pm »

The intention of this exercise is to obtain and fully documented the complete protocol specification and the informations needed add the relevant parts to protocol that prevent the occurring problems and to integrate some add-ons.

C++ is a wrapper to C. If you decomile a C++ applicatin or DLL you will get C functions with without the C++ wrappers. The Windows operating system kernek itself is written in C and ASM. I have written Windows applications and drivers in C and ASM in the early 1990 before MFC existed.

Besides this, the intended final product will be a WinMx compatible Linux client and primary using GTK-Gnutella using the GTK or WX library, This will subsequently ported to Windows using MinGW or Cyrus library. The WinMx protocol is intended to be a fall-back protocol to maintain compatibility.

Hans

Hans-Linux · « **Reply #11 on:** December 20, 2011, 12:22:10 pm »

Quote from: Bluey_412 on December 19, 2011, 12:00:01 pm

System Troubleshooting & Hardware, and understanding the networks side o stuff, I hold a Dip IT for PC & network support

Used to do the same while working as a Novell CNE. Learned on myself C and Assembler to write printer drivers and other stuff for DOS and early versions of Windows.

Hans

achilles · « **Reply #12 on:** December 20, 2011, 01:23:24 pm »

Hans, are you intending to develop a WinMx client that is compatible with the Gnutella network? That was not my ideal of a new improved WinMx client, but your the one doing all the work so it's your decision. I was hoping to see a new client strictly for the WinMx network.

GhostShip · « **Reply #13 on:** December 20, 2011, 07:10:18 pm »

Documenting the protocol is best done outside the client using the MxSniffer.

However as Achilles states, what you do is up to yourself.

achilles · « **Reply #14 on:** December 21, 2011, 01:25:28 pm »

I'm not against reverse engineering. Im actually for it if Hans is able to do it. I just dont want to see the WinMx client turned into another Guntella or torrent client. There are plenty of those clients already around. I want to see a client specifically designed for the WinMx network that is as much like the old client as possible. Then make any changes necessary to fix any security flaws, and build upon that client. Improvements could be made to that client like doing away with the 2gb file size limitation, etc..

White Stripes · « **Reply #15 on:** December 21, 2011, 01:38:49 pm »

Quote

I just dont want to see the WinMx client turned into another Guntella or torrent client.

its got nap built in already

there was a f/oss project that lost steam but was based on a 'plugin' system like winamp, pidgin, etc.... each p2p network was a loadable library... it has (can still be downloaded but damned if i can remember its name) a plugin for the 2.0 version of the winmx network along with gnutella torrent and a few others....

i cant help but wonder if hans' client is going to be something similar (winmx and gnutella in the same client but technically seperate) or if the networks will be 'linked' .......

anyone know what exactly it is hans is doing? cos i cant figure it out from his own wording... gnutella with winmx as a 'fallback' ? how is that going to work?

GhostShip · « **Reply #16 on:** December 21, 2011, 06:22:06 pm »

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

http://www.kceasy.com/

Files available from here.

http://sourceforge.net/projects/kceasy/

Shareaza is also multiple network supporting

http://shareaza.sourceforge.net/?id=tour

achilles · « **Reply #17 on:** December 21, 2011, 07:42:44 pm »

Yes , I have used both Kceasy, and Shareaza in the past. I like Shareaza, and I still use it occasionally. I used Opennap a lot in the past when Napster was big. I don't use it much anymore. I have Lobster for Open Nap. Its much better than the integrated Open Nap Component in WinMx.

Hans-Linux · « **Reply #18 on:** December 22, 2011, 06:24:36 am »

My intended plan:

1.) Convert WinMx.exe and OLEDLG.dll to ASM and C like Pseudo Code. (Done)
2.) Strip out the user interface (GUI) related code. (partly done)
3.) Analyse and document the various protocols.
4.) Create a basic clients with a command line interface for testing purposes (connection to primaries, search, download, upload).
5.) Add large file support (larger than 2 GB) if no protocol extensions are required.
6.) Add a search filter to limit returned search results to the desired search results. A search for "Beethoven" will only returns results that contain "Beethoven".
7.) Add extras such as checking for duplicates of files, Leach protection, etc.

When completed:
Create a primary with command line interface, facility to block search flooding, etc. Add, if necessary, protocol extensions to accommodate Large Files

The above will initially be Linux only and later ported to 32 and 64 bit Windows.

The cross platform client GUI will initially be GTK based like "GTK-Gnutella" with the command line client as "Back End" or "Plug-In". Other cross platform GUI options, such as WxWidgets will also be considered. This approach will allow anyone create a Open Source GPL licensed or $MS MFC closed source GUI with the command line client as "Back End" and to add or integrate his own Chat Client.

I intent to add the client "Back End" as addition client to "GTK-Gnutella", similar to KCeasy.

Hans

achilles · « **Reply #19 on:** December 22, 2011, 11:26:26 am »

Hans, I look forward to trying out your client! It's not exactly what I had in mind, but if you share your protocol findings with the community then it would help out in additional versions of the client being developed as well. Thank you for all your hard work!