SGE protocol - Revision history

VANKRASN39: fix double redirect

2017-05-03T22:47:56Z

fix double redirect

← Older revision		Revision as of 17:47, 3 May 2017
Line 1:		Line 1:
	#redirect [[SGE protocol (saved ~~post)~~]]		#redirect [[SGE protocol/saved posts]]

VANKRASN39: change to redirect

2016-02-15T20:13:35Z

change to redirect

← Older revision		Revision as of 15:13, 15 February 2016
Line 1:		Line 1:
		⚫	#redirect [[SGE protocol (saved post)]]
	The '''SGE Protocol''' is used to facilitate login without going through the [[Simutronics]] website. The following is a post made by GM Ildran describing the essential parts of the protocol:

⚫	~~{{:~~SGE protocol saved post}}

	[[Category:Front Ends]]

GS4-KEIOS: 6 revisions: Krakiipedia Import

2014-12-31T19:34:36Z

6 revisions: Krakiipedia Import

← Older revision	Revision as of 14:34, 31 December 2014
(No difference)

Maintenance script at 18:14, 19 December 2005

2005-12-19T18:14:55Z

← Older revision	Revision as of 13:14, 19 December 2005
(No difference)

Maintenance script at 18:14, 19 December 2005

2005-12-19T18:14:55Z

← Older revision		Revision as of 13:14, 19 December 2005
Line 1:		Line 1:
	The '''SGE Protocol''' is used to facilitate login without going through the [[Simutronics]] website. The following is a post made by GM Ildran describing the essential parts of the protocol:		The '''SGE Protocol''' is used to facilitate login without going through the [[Simutronics]] website. The following is a post made by GM Ildran describing the essential parts of the protocol:

	{{:SGE ~~Protocol~~ ~~Saved~~ ~~Post~~}}		{{:SGE protocol saved post}}

	[[Category:Front Ends]]		[[Category:Front Ends]]

Maintenance script: SGE Protocol moved to SGE protocol

2005-12-19T18:13:27Z

SGE Protocol moved to SGE protocol

← Older revision	Revision as of 13:13, 19 December 2005
(No difference)

Maintenance script at 17:49, 19 December 2005

2005-12-19T17:49:46Z

← Older revision		Revision as of 12:49, 19 December 2005
Line 1:		Line 1:
	The '''SGE Protocol''' is used to facilitate login without going through the [[Simutronics]] website. The following is a post made by GM Ildran describing the essential parts of the protocol:		The '''SGE Protocol''' is used to facilitate login without going through the [[Simutronics]] website. The following is a post made by GM Ildran describing the essential parts of the protocol:

			{{:SGE Protocol Saved Post}}
	IOI: 4

	>I'm looking for the SGE stuff, too to be able to skip the copy/paste steps.

	Okay, the SGE protocol is a bit complicated. I'm doing this from my poorly commented code, so the details are fuzzy. I also didn't try to figure out what happened if you, for instance, did things in the wrong order or sent invalid data.

	First, basically all the communication is done via tab-delimited lines, where the first field is a single letter denoting the operation. So, I'll denote tabs by spaces for ease of reading (thus, "A B C" would really mean "A\tB\tC\n"). Stuff in uppercase is literal stuff to send, stuff in lowercase is symbolic. Here's the steps I take to log in (which work):

	* Connect to eaccess.play.net, port 7900.
	* Send "K".
	* Receive a single line, turn it into bytes. This is the password hashing key. It's 32 bytes long.
	* For each character pw[i] in the password, compute (pw[i] - 0x20) ^ hashkey[i] + 0x20. I don't honestly know what you're supposed to do if the password is longer than 32 characters, I just reject passwords that long.
	* Send "A accountname hashedpassword".
	* Receive a line. I just check to see if it includes a substring of "\tKEY\t", and if not, I assume they typed the wrong account or password.
	* Send "M".
	* Receive a line. It should be formatted as "M instancecode instancename instancecode instancename ...", ie, pairs of instancecode followed by instancename.
	* For each instancecode, send "N instancecode". That will give you some information about the instance. The only check I make here is to see if the second field matches ".[\| ]STORM.", which indicates that the instance supports the SF protocol (some don't, such as the AOH and MO instances). It may also tell you other information, like if the account has access to that instance, but since I have full access to every instance I don't make any further checks.

	At this point, you have the information you need to show the user a list of games they can log into. Once they've selected a game...

	* Send "F instancecode".
	* Receive a line that is a letter (I think it's F, but I just throw it away, heh) followed by a line that indicates the status of the account's subscription to the game. The two error cases I handle are "EXPIRED" and "NEW_TO_GAME". I don't really know what the difference between them is, I just tell the user they don't have a subscription to that game in both cases. Anything else I accept.
	* Send "G instancecode".
	* Receive a line that has website addresses and stuff for this game. I just throw it away.
	* Send "P instancecode"
	* Receive a line that has the pricing information and stuff for this game. I throw it away, too.
	* Send "C".
	* Receive a line of the form "C nc ns x x characterid charactername characterid charactername ...". nc is the number of characters, ns is the number of character slots, x indicates a number that I don't know what it means, and the rest of the line is pairs of characterid and charactername.

	At this point, you present the list of characters to the user to select one. They choose one...

	* Send "L characterid STORM".
	* Receive a line. This line has some preliminary info and then is the file that should be passed on to the launcher, but with fields delimited by tabs instead of newlines. Find the fields that start with GAMEHOST, GAMEPORT, and KEY, and connect using them.

	That should be everything you need to know. Let me know if you have trouble.

	- Ildran

	[[Category:Saved posts]]
	[[Category:Front Ends]]		[[Category:Front Ends]]

Maintenance script: Added FE category

2005-12-18T19:33:07Z

Added FE category

← Older revision		Revision as of 14:33, 18 December 2005
Line 40:		Line 40:

	[[Category:Saved posts]]		[[Category:Saved posts]]
			[[Category:Front Ends]]

Maintenance script: Added category

2005-12-18T05:04:44Z

Added category

← Older revision		Revision as of 00:04, 18 December 2005
Line 38:		Line 38:

	- Ildran		- Ildran

			[[Category:Saved posts]]

Maintenance script: Added initial info

2005-12-18T04:51:39Z

Added initial info

New page

The '''SGE Protocol''' is used to facilitate login without going through the [[Simutronics]] website. The following is a post made by GM Ildran describing the essential parts of the protocol:

IOI: 4

>I'm looking for the SGE stuff, too to be able to skip the copy/paste steps.

Okay, the SGE protocol is a bit complicated. I'm doing this from my poorly commented code, so the details are fuzzy. I also didn't try to figure out what happened if you, for instance, did things in the wrong order or sent invalid data.

First, basically all the communication is done via tab-delimited lines, where the first field is a single letter denoting the operation. So, I'll denote tabs by spaces for ease of reading (thus, "A B C" would really mean "A\tB\tC\n"). Stuff in uppercase is literal stuff to send, stuff in lowercase is symbolic. Here's the steps I take to log in (which work):

* Connect to eaccess.play.net, port 7900.
* Send "K".
* Receive a single line, turn it into bytes. This is the password hashing key. It's 32 bytes long.
* For each character pw[i] in the password, compute (pw[i] - 0x20) ^ hashkey[i] + 0x20. I don't honestly know what you're supposed to do if the password is longer than 32 characters, I just reject passwords that long.
* Send "A accountname hashedpassword".
* Receive a line. I just check to see if it includes a substring of "\tKEY\t", and if not, I assume they typed the wrong account or password.
* Send "M".
* Receive a line. It should be formatted as "M instancecode instancename instancecode instancename ...", ie, pairs of instancecode followed by instancename.
* For each instancecode, send "N instancecode". That will give you some information about the instance. The only check I make here is to see if the second field matches ".*[| ]STORM.*", which indicates that the instance supports the SF protocol (some don't, such as the AOH and MO instances). It may also tell you other information, like if the account has access to that instance, but since I have full access to every instance I don't make any further checks.

At this point, you have the information you need to show the user a list of games they can log into. Once they've selected a game...

* Send "F instancecode".
* Receive a line that is a letter (I think it's F, but I just throw it away, heh) followed by a line that indicates the status of the account's subscription to the game. The two error cases I handle are "EXPIRED" and "NEW_TO_GAME". I don't really know what the difference between them is, I just tell the user they don't have a subscription to that game in both cases. Anything else I accept.
* Send "G instancecode".
* Receive a line that has website addresses and stuff for this game. I just throw it away.
* Send "P instancecode"
* Receive a line that has the pricing information and stuff for this game. I throw it away, too.
* Send "C".
* Receive a line of the form "C nc ns x x characterid charactername characterid charactername ...". nc is the number of characters, ns is the number of character slots, x indicates a number that I don't know what it means, and the rest of the line is pairs of characterid and charactername.

At this point, you present the list of characters to the user to select one. They choose one...

* Send "L characterid STORM".
* Receive a line. This line has some preliminary info and then is the file that should be passed on to the launcher, but with fields delimited by tabs instead of newlines. Find the fields that start with GAMEHOST, GAMEPORT, and KEY, and connect using them.

That should be everything you need to know. Let me know if you have trouble.

- Ildran