How to make Imorpheus work again. My theory

[Kewbase]

I have been following the events with IMorpheus .
Too bad it doesn’t work anymore, because maintaining such an indepent FastTracknetwork would be a breakthrough in filesharing.

Don’t know if you know the confidential RIAAmemo about the FastTracknetwork. It contains some usefull information about the structure and procedures You can find this article at http://www.dotcomscoop.com/riaamemo.html

What I get from this it that Morpheus connects to a central login server owned by MusiscCity. If this server is down, Morpheus connects to the supernodes that are mentioned in the registry.

My theory on what happened is that StreamCast/MusicCity closed down their login server last week. That made users of version 1.3.3. connect to the supernodes., thus creating an independent network.
StreamCast/MusicCity has found out what was happening and has rebooted the login server. Morpheus 1.3.3.connects to this server and this login server somehow prevents that you connect to the supernodes.

How to solve this. The Ipadress of the login server is hard coded in the application. If we can find a way to remove or disable this piece of code, Morpheus might try to connect to the supernodes again.
Unfortunately I don’t know how to do this , maybe one of you guys has the necessary knowledge or know someone who can do the job.

I'll be happy to test it.

[colinmacc]

My theory is that a Kazaa SuperNode or Nodes has again "poisoned" the network. I don't think this is anything to do with Streamcast or MusicCity at all. They've washed their hands of FastTrack. There's no reason for them to get involved.

If you read the article further, you'll see that if none of the preset supernodes in the registry is functional, then the client still links to a Kazaa IP address to get a list of supernodes from there.

I'm not sure of the solution to this one. But clearly the network isn't as "self-organising" as we were lead to believe.

I see the possibility for a shadow network existing though, we just need some way of securing the supernodes, and disabling the hidden link to Kazaa forever. However I do feel that intrinsic within the Morpheus client is the potential for external tampering, so if iMorpheus is ever to have a future someone needs to reverse engineer the client and publish the source.

Time for the big guns!

[TankGirl]

First of all, welcome aboard guys and enjoyable stay at Napsterites Underground to you both!

Originally posted by colinmacc
I see the possibility for a show network existing though, we just need some way of securing the supernodes, and disabling the hidden link to Kazaa forever. However I do feel that intrinsic within the Morpheus client is the potential for external tampering, so if iMorpheus is ever to have a future someone needs to reverse engineer the client and publish the source.

Good points. There is surely the possibility to neuter any particular Morpheus version from the backdoors and control holes that Kazaa has left there but I am starting to doubt whether it is really worth the effort. Rather than guessing what tricks Kazaa will play next through the supernodes under its control it might be better to leave the commercial FastTrack network altogether and focus on safer and spyware-free open source solutions. This also seems to be the conclusion of giFT developers who are currently focusing their efforts on OpenFT protocol and clients on their new SourceForge site.

- tg

[BuzzB2K]

Originally posted by colinmacc
My theory is that a Kazaa SuperNode or Nodes has again "poisoned" the network. I don't think this is anything to do with Streamcast or MusicCity at all. They've washed their hands of FastTrack. There's no reason for them to get involved.

First of all Welcome All to this little haven from "Corporate Forums"

The network_config that was modified a couple of weeks ago and is currently the one I see in my registry for both Grokster & iMesh started out with a message from KaZaA about updating to the "KaZaA Media Desktop" (KMD) - but both Grokster & Morpheus directed you to their own website for an update (possibly a message written in the program itself?)

Two days ago when the old Morpheus quit connecting again I looked at the network_config again and this time it had a Grokster ver. 1.5.1 update message! I wrote my backup network_config back into the registry and after about 20min got the "Client too Old..." message, but now it has the KMD Update message - However it still tells you to go to MusicCity for an update...

Update - All 3 are now showing the "KaZaZ Update Message" & the "Grokster Update Message" - The Grokster message was not in there when I extracted the information below... I have the KaZaA message, but it will take a little bit to do the Grokster...

[BuzzB2K]

Originally posted by TankGirl
This also seems to be the conclusion of giFT developers who are currently focusing their efforts on OpenFT protocol and clients on their new SourceForge site.

- tg

Last fall when the OpenFT project got locked out of FastTrack it was only 9 Bit encryption on the SuperNode comunications, now it' been increased to 41 Bits!!

Original network_config
:KaZaA.ConnectedNetworks:Grokster fileshare MusicCity
:Grokster.ConnectedNetworks:KaZaA fileshare MusicCity
:fileshare.ConnectedNetworks:KaZaA Grokster MusicCity
:MusicCity.ConnectedNetworks:KaZaA fileshare Grokster
RequiredClientEncryptionBits:9
RequiredSupernodeEncryptionBits:9
ConnectProtocolHeaderVersion:3
ConnectUsingV2Encryption:0
EnableBroadcasts:0
AuthUrlMask:5
MaxBroadcastBandwidth:1000000
DownloadSearchTime:120
DownloadSearchStep:1
NetworkFullnessMax:50
BroadcastStatsControlNodes:152.7.24.101:1214 212.179.35.118:1214 128.163.61.203:1214 24.51.82.113:1214

Update network_config
:KaZaA.ConnectedNetworks:Grokster fileshare MusicCity
:Grokster.ConnectedNetworks:KaZaA fileshare MusicCity
:fileshare.ConnectedNetworks:KaZaA Grokster MusicCity
:MusicCity.ConnectedNetworks:KaZaA fileshare Grokster
RequiredClientEncryptionBits:41
RequiredSupernodeEncryptionBits:41
AuthUrlMask:5
MinSupernodeLibVersion:20
MinSupernodeSoftwareVersion_1752395113:126
BroadcastStatsControlNodes:128.255.173.7:1214 24.205.221.214:1214 130.111.152.143:1214 212.179.35.118:1214

You might notice that MusicCity is still listed as a "ConnectedNetwork"
You can also see the SuperNode that switched

[fogelbise]

>>>warning does not address the main topic<<<

Don’t know if you know the confidential RIAAmemo about the FastTracknetwork. It contains some usefull information about the structure and procedures You can find this article at http://www.dotcomscoop.com/riaamemo.html

Thank you for that link. The part I found interesting on the memo:

However, the encryption of this communication precludes further learning absent cooperation from one of these companies or court ordered discovery. In that regard, we recently learned that FastTrack is very interested in exploring alternatives to litigation and its principals are willing to sit down with the record companies to discuss ways of resolving any dispute. FastTrack is willing to sell the company and the technology, or enter into a licensing arrangement. FastTrack is also willing to implement filtering technologies to prevent
infringements.

reminds me of the accusations that there was more to the Sharman acquisition than met the eye. one way to access the encrypted communications...

Edit: in looking for more info at the dotcomscoop site, the author made similar conclusions in this march 5th 2002 article:
http://news.dmusic.com/article/4556

also:

Message Boards discuss available music, films, and software.

MusicCity employees participate in message board discussions and CEO acknowledges MusicCity controls message boards.

[should we provide notice by letters and when?]

ooooooops!