Does anyone fully understand the authentication process?

Can anyone explain it? In layman's terms, of course. Just briefly. I'd like to understand the basics.

Here's an example: (It's most likely wrong but that's why I made this thread)

1.) What exactly is the purpose of separated server executables? Why can't it be one single command window?

2.) What does NDLogin do exactly? Aside from checking database stuff, executing stored procedures, etc...

When the user tries to log in, all the information is passed onto NDLogin, which processes this information, which is then forwarded to DS_SERVER and lastly to NDServer? I don't get it.

3.) What is DS_SERVER for? (Lol)

4.) How are DS_SERVER and NDServer communicating with each other? I mean what pieces of information are exchanged between the two?

5.) What is the file "AuthAddr" for? Why is it necessary? This file contains a simple URL address that points to a .py file (Python script, created by 'ZeroBurner'). This python script is supposed to somehow return a login success or login fail message to the NDServer, which the NDServer somehow understands... How does this work?

I can understand LOG_SRV dot exe. It's responsible for creating logs. Pretty obvious. You can't start most server executables without running LOG_SRV first because, duh, it wouldn't be able to create logs. I get that.

I can also understand MS dot exe. It's basically the in-game messenger.

I also kind of understand NDServer dot exe. It's mainly responsible for running maps but it gets complicated because it has to communicate with DS_SERVER.


What I know about the login process so far: (it might be wrong, too)

On user login
Check the following:
-- does account name exist / match
-- is password correct / match
At these phases, account credentials are sent to NDLogin and then to DS_SERVER? How does this work exactly?

-- is account restricted / banned
-- does client/server version match
At this phase, this is just a simple SQL stored procedure stuff, right? So it's checked by DS_SERVER only? Or is NDServer involved as well?


-- does company code match
At this phase, NDLogin checks the login packets coming from the client, for the company code (called "LMBC", also known as "Login Mode By Company"). If it matches, this phase passes. I don't understand this, though, because I successfully compiled an NDLogin exe and I altered the LMBC code in such a manner that it matches the client, yet it refused to log me in. I got a "size mismatch" error. This error was only visible on the NDLogin server console window. Does anyone know why this happens?

-- is 1 map running at least
At this phase, it sends a request to NDServer to see if at least one map is running? This phase isn't that important, anyway.

-- has virtual keyboard been used
This phase doesn't matter too much becase I think it's client sided. Please correct me if I'm wrong.

-- does packet length match
At this phase, some packet length is checked? What packet or packets? Is it an NDServer/DS_SERVER/NDLogin thing?

> If success, enter character selection screen

On map enter
> Check the following:
-- is current map running
This phase is obvious and needs no discussion.

-- does packet length match
At this phase, some other packet length is checked... I remember receiving an error called "DS>GS Packet Size <recv / sent> or something. What is this?


Thank you for reading.

give the guy a hand. Here are a couple of pointers what DS_SERVER Does.

[Only registered and activated users can see links. Click Here To Register...]
Btw these are the structures linking opertools and ds server/

Also dont forget mapping opertool port, which links direct to the IGN cache held in DS server.
Not forgetting depending on amount of people logged, the 15 minute delay of pooled data held in cache.
The time taken To release all data from IGNS logged off, will depend on the total IGN'S logged on.This is highlighted in the database table in ninedragons_account
table=[dbo].[Tbl_ND_GameConnect]
curr_state=1
temp_id=????

The more temp_id>0 will then increase the 15 minute period we initially allowed for cache to be released.

[Only registered and activated users can see links. Click Here To Register...]

To be honest i thought you knew all this. I will explain the port 80 question associated with AuthAddr later. You can ofc create a ipsec tunnel, which ofc will create a form of a proxy server barrier, preventing direct access to the Ip address you wish to remain hidden mainstream. (Literally a VPN, on a server host provider) The dedicated host provider ie OVH,will be the entry point in ndreg.xrg

useful article to protect your server against attacks.

[Only registered and activated users can see links. Click Here To Register...]

[Only registered and activated users can see links. Click Here To Register...]

The above example was only for webservers port 80 and 443. But this also applies to all other ports

The biggest giveaway and to give anyone a clue what ds server does i guess, is when you kill ds server .exe and the opertool process is still in memory!!!!