Minilogin Woes

[Aramid]

Originally Posted by sdtuasrt, MD

So, just to clarify:

I have three characters, a warrior, a cleric, and a druid. When zoning the account the warrior is on, the warrior's ip is the correct, real IP, and the ips of the accounts the Cleric and Druid are on are set to anything but the 127.* block?

Basically, yes ... UNTIL you zone those characters. You would then have to change there IP's to the correct one, one at a time, while changing the one that has already zoned to the incorrect one.
The reason is because minilogin only uses the IP address of the computer for identification. There is NO source code available to change this, never will be.

[sdtuasrt, MD]

Originally Posted by Aramid

Basically, yes ... UNTIL you zone those characters. You would then have to change there IP's to the correct one, one at a time, while changing the one that has already zoned to the incorrect one.
The reason is because minilogin only uses the IP address of the computer for identification. There is NO source code available to change this, never will be.

And I take it that decompilation of it would be a no-no.

Let me ask another question.

From what I can gather, minilogin does 'nothing' more than receive incoming client connections, displays a list of servers, and then redirects the client to the server.

Is this the only point at which minilogin is used? Or does it come into play during zoning, etc? If it is the only place during which it is used, it would be relatively simple for one to construct a small program which just automatically sent the correct packets when one says in the client, "Let me automatically reconnect to the last server I was on," and ignores other input?

Hm.

Hold on, need a packet sniffer.

[cole89103]

its been tried you wont get anything usefull out of decompiling minilogin many have tried to make minilogin public and all have failed there have been several work arounds but to make a public loginserver to work how you want it you need the crypto that eq uses to talk to the server and without that you will never get a public loginserver working

better just either use the php updater i mentioned or change the ips manually or use the public loginserver eqemulator.net provides

[nosfentora]

One solution could be to use VMWare or MS VirtualPC. You could install the os once in 1 virtual machine, then make X copies of it, and start each virtual machine. Should give you separate ip's for each machine.

[sdtuasrt, MD]

Originally Posted by cole89103

its been tried you wont get anything usefull out of decompiling minilogin many have tried to make minilogin public and all have failed there have been several work arounds but to make a public loginserver to work how you want it you need the crypto that eq uses to talk to the server and without that you will never get a public loginserver working

better just either use the php updater i mentioned or change the ips manually or use the public loginserver eqemulator.net provides

Unless they're using something really, really, really, really, really super complicated, it's crackable. It's always crackable. Someone had to be able to do it in the first place to get the public Login Server to work.

The Login Server, be it the public or the minilogin, has to transmit certain information. It absolutely has to. The Server Name being one of those pieces of information. Unless it is transmitted unencrypted, in plain text, then you have a huge cryptographical advantage -- you know what some of the content of the message already is. On top of that, one should easily be able to discern what the preambles and/or postables of the messages are using the opcodes listed, and indeed, minilogin itself.

There are only three reasons I can think of for the lack of release of source code for either minilogin or the public loginserver. The first is that it contains leaked sourcecode from SOE. The second is that source is no longer available. The third is that people only want software to be 'free' and 'opensource' when it benefits them to do so.

As to the second option, I find it possible, since development has been locked at Titanium. I'm afraid it comes down to a choice between number one and number three.

I readily admit that something such as the loginserver is a non-trivial task. I am also entirely unaware as to the authorship of the public login server -- which is why I believe a possible reason it cannot be made available is due to copyright violation. However, I do know that the emulator itself is open source, and as a programmer, I get extremely frustrated with having to reinvent the wheel. And the axle. And the cart. And the donkey. And all the laws of physics that enable those things to exist.

Oh well. Where's that packet sniffer?

[cole89103]

oh without a doubt its crackable but i dont reccomend discussing it on the forums here cause well most people that have have been banned for one reason or another so watch out lol

[AndMetal]

Originally Posted by sdtuasrt, MD

The Login Server, be it the public or the minilogin, has to transmit certain information. It absolutely has to. The Server Name being one of those pieces of information. Unless it is transmitted unencrypted, in plain text, then you have a huge cryptographical advantage -- you know what some of the content of the message already is. On top of that, one should easily be able to discern what the preambles and/or postables of the messages are using the opcodes listed, and indeed, minilogin itself.

This may seem a little off topic, but it should help to explain why minilogin has to use an IP address and doesn't have anything to do with the account name (at least in the Titanium client).

I personally was curious about the cryptography, so for the heck of it, I started sniffing some packets. From what I was able to gather, the login packet that is sent from the client to the server is 56 bytes total, 48 of which are the actual data. From that, there is a 24 byte hash of the username + password. If you're using Ethereal (looking at the entire packet), it starts at 0x4A and ends at 0x55. The last 16 bytes of the packet are apparently a checksum for the data.

Since we know where to look, we can put in what we know to be the username & password, and see what it puts out. Using a lot of math, I'm sure it wouldn't be impossible to reverse engineer the algorithm used, but I'm sure my brain would explode if I tried to figure it out by hand (and cryptography is definitely not my forte).

Because the username is encrypted as part of the hash, minilogin isn't able to decipher it, unless it included the cryptography algorithm (which it doesn't look like it does, because of its limitations). As a result, minilogin doesn't even know what your username is, it just forwards you onto the server itself (including your IP address, which it can detect very easily). So, in essence, your IP address becomes your "username", which is then references back to the actual username in the accounts table.

[cole89103]

little hint word on the grapevine is it uses rc4 encryption but it also uses compression ontop of the encryption just so you know

[Theeper]

I don't think Minilogin uses any type of encryption in communication with World. But why bother trying to decompile it though ? You can see how it works from the server source.

This subject has been beaten to death though. For some reason it has to be brought up again every few months. Someone should sticky the last few "I want to decompile Minilogin" threads.