Source code for Minilogin
 

Can someone point me to the location of the Minilogin source code. I want to add some functionality to it to allow multiple user ID logins and to utilize the accounts file.

Regards,

Minilogin source has never , is not , and never will be open source.

Why is that???
 

I guess my question is why not? What make this piece of code different from the all the other source code???? It's unsupported code and there is much potential for improvements within it. If you ask for an improvement you get the "That unsupported".... Well, If thats the case why not let delevopers out there tweek the code for thier own needs, Why hide the source???

Makes no sense to me!!! :?

We have a very good reason to hide the source for a login server: encrypted passwords.

Same reason the loginserver code is not released.

There is no need for your seperate loginserver anyways unless you are trying to prove that you made the emulator yourself. Just use the EQEMu loginserver and you'll be fine.

And if you're trying to setup a lanserver, then you're obviously missing some key points.

Just looking at my own copy of the login server gives me a warm fuzzy feeling inside.
Now to go off and practive the secret handshake...

heh too bad thats outdated and it doesnt include the crypto that you need to be able to use it :)

Yeah I know. I've got no idea why I kept it.
Lets just call it novelty value

Sure there's a need. My wife and I both want to play on our own server. We're not interested in setting up a server that can be seen by the outside world, in fact, it wouldn't matter if the outside world COULD see it as we have Charter for an ISP and they don't allow servers. However, the way my LAN is set up, I can't go through the EQEMu login servers to play. My Linux box, the one that runs the server, is also my gateway. If I set up the server to work on the external IP address (which I'd have to do to connect to the EQEMu login servers), I can't connect from my LAN. If I set it up to use Minilogin, I can only connect one account at a time. I seem to remember a long time ago when MiniLogin would allow up to 16 connections at once, which even that would be overkill. If I had a MiniLogin that allowed even just 2 connections at once, I'd be able to do what I want to. As it is, I can't, and I guess I won't be able to.

I run 4.4 and 5.0 with minilogin and i can have more then 1 account on at one time, i have had all 3 of my computers on it at once. My best guess would be its a set up issue not a minilogin issue.

There's supposed to be a MiniLoginAccounts.ini which specifies which IPs use which accounts in a format like IP name password.

Although upon trying this myself, I receive this output of minilogin:

LoginServer.ini read.
Error in MiniLoginConfig.ini on line #1: Invalid format, should be 'IP username
password'
MiniLoginAccounts.ini read.
Server mode: Standalone
Login server listening on port:5999

While both my .ini's look like:

127.0.0.1 name pass

A quick search shows no answers on the solution for this yet, but Mattmeck, you suggested there's a weird character seperation in this post.

Edit: Seperating the fields with the space character from ALT+0160 seems to get rid of the error message with minilogin, though despite my having defined 127.0.0.1 and my external IP to be a non-eqemu account, world.exe still reports that account connecting. Does Minilogin 5.0 still support multiple accounts? Perhaps the primary machine running minilogin always logs in as 'eqemu' and others are able to be specified?

Another edit: This was answered here and thus far appears to work rather well.

I was wondering, could the encryption and decryption routines be made into pre-compiled DLLs?
That way, the minilogin source can be released or at least an API whitepaper
so someone can make a graphical client?
Maybe a graphical client will let you be able to monitor connections on the fly, kick users etc...

Just a thought =)

Chrysm you know that people can crack DLLs, we already have a DLL but it has more features than just the loginserver crypt plus only two people have the source to the DLL.

An idea would be more to source it with the encryption routines pre-compiled into DLLs, BUT have eqemu's general login server encryption different than the one that's released. Meaning having a more generic encryption routine for the general public's download.
Granted that would make private servers in this case less secure, but if there's no public showing for it, wouldn't it be pointless to be more secure?
I'd find it a trade off in that case, you can have your own login, but it's not as secure as the one that eqemu runs.

How would that work ? As I understand it, the login server needs to decrypt the password that the EQ client encrypts. To have a different encryption algorithm would require altering the client, no ? (or just ignore the password, as I think minilogin does)

Yeah, I guess you're right.

Hmm, good point. I was thinking more of perhaps having it encrypt the pw into the db by a fashion (or more just put it in raw, and read it like that or something) perhaps the same as ignoring it which would be another way to go.
Either way, it doesn't need to store pws, since it is a private access server only, and if it's encrypted in the db, that should be fine as well. Just not source then at that point, and precompiled.

Why are you wasting your time debating this? Source code will not be released. a full version of a login server will not be released. be happy we give out minilogin at all....


You give them the world and they still want more.

You just don't get it, we don't give a damn if you know the passwords of ppl logging into your login server, we care about people getting the encryption from client->server, because we can't alter it, its the same as eqlive's and we aren't going to let someone go off and start packetlogging EQ passwords.

To add: DLL's are linked to exes so someone could take the DLL and make it into a DLL useable by a packetcollector, get the idea?

Do not try to argue that statement because they have the DLL on their computer and any modifying that needs to be done to the DLL they can and will do.

Hey, wasn't trying to piss anyone off, was just trying to be helpful in general, sorry for trying guys.

Yes

Don't want to argue.

I just wanted to state what I was thinking. Someone makes an open source login for example, as a basic framework with functionality of little things like checking ip's etc etc.
In the source code would be a blank function to encrypt and decrypt whatever and it's left blank. Then the source is submitted for approval to the EQEMu team to overlook it and if it's deemed ok to use, the dev team inserts the functions and then releases the binary. No one other than the devs would still have access the the secret information but, other people who want to help could make the basic program for approval.

That was my line of thinking on that part. I know you guys are right and the encryption/decryption routines shouldn't be given out.

Secondly, I thought as far as DLLs go, it's basically a header file with functions in it, and you just call those functions to do what you want. Am I wrong in that assumption? I know shit about how windows works.


PS-THIS IS NOT AN ARGUMENT I just want to discuss some ideas and stuff. It is by no means to cause trouble or anything, just to learn. Just in this post, I have learned the overview and I guess it helps with having a better understanding of the entire structure.

DLLs are compiled binaries in essence are they not?

Anyways this conversation is is very deja-vu. I'm sure I missed past threads regarding the closed source decryption used by EQEMu but I was whitness to many such threads over at the ShowEQ boards.

Best to keep the decryption out of the hands of the masses.

Yeah I know I didn't want to stir up anything heh!

My understanding of a DLL is it is compiled but, it has "holes" where the program using it hooks into to be able to use the funcions not access the data unless the function specifically says it can. In this case, the function would pass the secret stuff over to the program for handling.

Anything that can be used in many different programs, best to put into a DLL and release an API so the programs you wrtie can actually use the functions in the DLL. Better than writing source code every single time =)

Ok, I won't post anymore... I have those hairs standing on end on my neck... something bad is abo.......

Not saying you were im saying not to argue it :P

Its pointless to try putting in checks because the exe/dll is on your computer and you can just hex edit it, so anything could be disabled.

Carp I just got laid off... something bad did happen =P