E-Access protocol definitionEdit

Authors: Marshall, Sean, Will
Last Update: 11-9-2004


Currently there are two official SIMU Endorsed Apps that talk with this protocol, SGE and zMUD Per Michael Niemeyer (Technical Aide, Simutronics Corporation)

 "We will not disclose the method of doing account logins via the "eaccess"
 method. That method is what the Mac Wizard uses in standalone mode, and
 what the PC Windows SGE uses. This method is going to change in the future,
 and will no longer be available for unauthorized third-party programs, such
 as USGE."

see comment
Please note, this document was written originally before this comment was made.


port: 7900

Protocol OrderEdit

  1. Send version Line (optional) Example: AL4334 SGE16 1 14
    if version sent, server responds with CURRENT if current version.
  2. Send K action (following line syntax)
  3. Server Sends Key. (!!NOT LINE SYNTAX!!)
  4. Send Action A. (Login)
    After this, if it fails or you want a different user... you must disconnect and reconnect
  5. Send actions to obtain information about games...
  6. Send Action G. (select Game)
  7. Send actions to obtain information about charactors
  8. Send Action L. (select charactor)
  9. Use response with any client.

Line Syntax:Edit

NOTE: Exemption on K Action, Server does not follow protocol in response! (see K Action detail)

Action - Single Char
Details - May be multiple or no properties, each property prefixed by 0x09
Termination - 0x0a Hex Values ends server->client comm
0x0d,0x0a Hex Values ends client->server comm

Protocol Actions - Sending to server (summary only):Edit

K - Server responses with Key (to encrypt password with)
A - This action tells the server what user/pass you're dealing with
M - Asks the server for a list of games
N - Asks server for game capabilities
G - Tells the server what game you want, server responds with some details
C - Asks the server for a list of charactors specifically, other stuff included
L - Tells the server you want to play a charactor, server responds with connection info
F - (Unknown) SGE Sends it... Server response: NORMAL
B - (Unknown) zMUD Sends it... Server response: UNKNOWN
P - (Unknown) SGE Sends it w/ gamecode.. Server response: ?God knows what?

Version ActionEdit

INVALID LINE SYNTAX! (optional) This is where SGE checks to see if it's current. %% Client> AL4334 SGE16 1 14 Server> CURRENT %%

  • TODO: See what it says if it's not a current version.

K ActionEdit

Invalid Line Syntax! This action is ussually done first, as it is needed for authentication, which is also needed for almost every other step.

Example Client Server Response: %% Client> K(0x0d,0x0a) Server> |NMpR.uMjiEOmCMfGJTtrH\sWQqHdFhA(0x0a) %%

The server response, will always be 32 charactors, then 0x0a

A ActionEdit

This is the client sending the username and the hashed password (hashed by the K action's key)

2nd detail seems to always contain something about the success KEY - Successful auth, giving you a key to workwith NORECORD - There is no user with that username PASSWORD - That's an incorrect password REJECT - For suspended accounts, etc. There may be others for other types of account restrictions.

Code to hash password (pretty basic, works though): %%char *sge_encrypt_password (char *passwd, char *hash) { int i; char *final;

final = g_new (char, 33); /* i.e. malloc (sizeof (char) * 33) */ for (i = 0; i < 32 && passwd[i] != '\0' && hash[i] != '\0'; i++) { final[i] = (char)((hash[i] ^ (passwd[i] - 32)) + 32); } final[i] = '\0';

return final; }%%

Client sends 2 details: 1) username (plaintext) 1) hashed password

Successful auth: Server Responds with 4 details: 1) Username (may be differnt capitalization the one sent) 2) the word KEY in all caps (does this mean there may be more later?) 3) the key, this can be matched with the one that the server sends with Action L 4) full name of person registered with account

Bad User or Pass: Sever responds with 2 details: ~1) EMPTY ~2) NORECORD if bad user, PASSWORD if bad password

Example Exchange: %% Client> A(0x09)blahuser(0x09)hashedkey(0x0d,0x0a)Server> Server> A(0x09)BLAHUSER(0x09)KEY(0x09)15352427991eea6e21e8e5f6aae3432c(0x09)JOHN DOE(0x0a) %%

G ActionEdit

This is the client telling the server what game we want to play, the server responds with some info. Keep in mind that if a trial is available, you will start the trial with this action.

Client sends 1 detail: ~1) Game Code (ex: DR)

Server Responds with 5+ details: ~1) Game Name ~2) Account Type (PREMIUM|NORMAL|TRIAL <-- are known ones) ~3) (Unknown) 0? ~4) (Unknown) Blank... nothing in it The rest is a config file, which appears to have URLs/Filepaths in it: (a whole lot) ~5) ROOT=sgc/dr ~6) MKTG=info/default.htm ~7) MAIN=main/default.htm ~8) GAMEINFO=information/default.htm ~9) PLAYINFO=main/default.htm ~10) MSGBRD=message/default.htm ~11) CHAT=chat/default.htm ~12) FILES=files/default.htm ~13) COMMING=main/default.htm ~14) STUFF=main/comingsoon.htm ~15) BILLINGFAQ=account/default.htm ~16) BILLINGOPTIONS=offer/payment.htm ~17) LTSIGNUP= ~18) BILLINGINFO={KEY} ~19) SITE=sgc.GAMES=main/games.htm ~20) FEEDBACK=feedback/default.htm ~21) MAILFAIL=/sgc/dr/feedback/mailfail.htm ~22) MAILSUCC=/sgc/dr/feedback/mailsent.htm ~23) MAILSERVE=SGC ~24) SIGNUP= ~25) SIGNUPA=

Example trasaction: %% Client> G(0x09)DR(0x0d,0x0a)Server> G(0x09)DragonRealms(0x09)PREMIUM(0x09)0(0x09)(0x09)ROOT=sgc/dr(0x09)MKTG=info/default.htm(0x09)MAIN=main/default.htm(0x09)GAMEINFO=information/default.htm(0x09)PLAYINFO=main/default.htm(0x09)MSGBRD=message/default.htm(0x09)CHAT=chat/default.htm(0x09)FILES=files/default.htm(0x09)COMMING=main/default.htm(0x09)STUFF=main/comingsoon.htm(0x09)BILLINGFAQ=account/default.htm(0x09)BILLINGOPTIONS=offer/payment.htm(0x09)LTSIGNUP={KEY}&SITE=sgc(0x09)GAMES=main/games.htm(0x09)FEEDBACK=feedback/default.htm(0x09)MAILFAIL=/sgc/dr/feedback/mailfail.htm(0x09)MAILSUCC=/sgc/dr/feedback/mailsent.htm(0x09)MAILSERVE=SGC(0x09)SIGNUP= %%

C ActionEdit

This is the client requesting a list of charactors, it also returns how many char slots are available. It also returns how many are used.

Client Sends No Details

Server Responds with 3+(2xn) details: ~1) Unsure, guessing number of charactors used (more experimentation required) ~2) Number of Charactor Slots Available ~3) Unknown ~4) Unknown Repeat the next two for each charactor ~5) Charactor Code ~6) Charactor Name

Example Server Exchange: %% Client> C(0x0d,0x0a) Server> C(0x09)1(0x09)16(0x09)1(0x09)1(0x09)J_BLAHUSER_000(0x09)BlueGrass(0x0a) %%

L ActionEdit

Tells the server you want to play a charactor, server responds with connection info. With this, you can create a charactor, just put a 0 in place of where you would specify the charactor code from the C action. The server responds with a PAL format file where 1 line = 1 detail. The keycode in that file should match with the one we recieved after doing the A action.

Client Sends 2 Details: ~1) Charactor Code of charactor to play (0 if new char) ~2) the word "PLAY"

Server Sends 10 Details. ~1) - Word "OK"? Assuming this means you're cool, and can join that game. The rest seems to be the contents of the PAL file to connect. (Each line it's own detail) I assume it doesn't have to generate these lines in order, or this number of lines BEWARE ~2) UPPORT=5535 ~3) GAME=WIZ ~4) GAMECODE=DR ~5) FULLGAMENAME=Wizard Front End ~6) GAMEFILE=WIZARD.EXE ~7) ~8) GAMEPORT=4901 ~9) KEY=15352427991eea6e21e8e5f6aae3432c

HEX CODES -> KEY %% (0x09) = Tab or \t (0x0d) = CR or \r (windows prefixes this to \n's.. annoyingly) (0x0a) = LF or \n (line return) %%


File based off of Sean and Marshal's SGE_INFO file, Will took and reorganized existing information, while adding new things found when using zMUD.