Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

Client Authorization

Newbie Spellweaver
Joined
Mar 28, 2010
Messages
28
Reaction score
9
I am trying to simulate a custom client on the official game servers and it seams that the auth key in the packet with the opcode 101 is somehow validated by the backend. For me it looks like some random timestamp but also thought that it could come from the xingcode guard. Does anyone know how the auth key is generated in the client or becoming accepted by the backend without the official client?
 
Newbie Spellweaver
Joined
Mar 28, 2010
Messages
28
Reaction score
9
Is the magic key inside xdata used for permutations on the auth key or what is it good for?

The server doesn't accept the same key twice so maybe it has knowledge about the data or matches passed time if it represents a timestamp?

I can't see any packets send before opcode 101, am I missing some service ports?
 
Upvote 0
Newbie Spellweaver
Joined
Mar 28, 2010
Messages
28
Reaction score
9
you must fix the packet of client match for serverside!

The Packet Layout and encryption is correct so far the server is just not accepting the auth key somehow.

Here an Example:
E2 B7 0E 00 00 00 00 00 65 00 DB E8 C5 D5

The bold marked part is the auth key as documented in the open source project Minerva but the server doesn't accept it outside the official client it self.
 
Upvote 0
Junior Spellweaver
Joined
Jan 16, 2014
Messages
150
Reaction score
189
Unless it has changed very recently, that value in Connect2Svr is not used and is just junk. It's not the AuthKey (that's sent in the reply), and is only used when sent to WorldSvr during the transfer from LoginSvr to WorldSvr.
 
Upvote 0
Banned
Banned
Joined
Apr 14, 2012
Messages
68
Reaction score
39
The Packet Layout and encryption is correct so far the server is just not accepting the auth key somehow.

Here an Example:


The bold marked part is the auth key as documented in the open source project Minerva but the server doesn't accept it outside the official client it self.

The bold marked part isn't authkey, the C2S_CONNECT2SVR structure is

Code:
byte ServerIdx
byte GroupIdx
byte Reserved0
byte Reserved1
 
Upvote 0
Junior Spellweaver
Joined
Jan 16, 2014
Messages
150
Reaction score
189
The bold marked part isn't authkey, the C2S_CONNECT2SVR structure is

Code:
byte ServerIdx
byte GroupIdx
byte Reserved0
byte Reserved1

That is for the WorldSvr Connect2Svr (opcode 140). OP is asking about the LoginSvr Connect2Svr (opcode 101).

.. and it seams that the auth key in the packet with the opcode 101 is somehow validated by the backend.

The LoginSvr packet is just:
Code:
uint Reserved;
 
Upvote 0
Banned
Banned
Joined
Apr 14, 2012
Messages
68
Reaction score
39
That is for the WorldSvr Connect2Svr (opcode 140). OP is asking about the LoginSvr Connect2Svr (opcode 101).



The LoginSvr packet is just:
Code:
uint Reserved;

My bad you're right, so this parameter is really useless :thumbup:

I mean, idk if there is a difference as they share the structure defined in NetLib so.. unless they have changed in the following versions, it really has no use as the proc function doesn't give a damn what the client is sending

Code:
int PROCCALL OnCSCConnect2Svr(CProcessLayer *pProcessLayer, 
							  PROCESSDATACONTEXT *pProcessDataCtx)
{
	ALIAS_PTR(USERCONTEXT, pUserCtx, pProcessDataCtx->pUserCtx);
	ALIAS_PTR(USERDATACONTEXT, pUserDataCtx, pUserCtx->pData);
	ALIAS_PTR(C2S_CONNECT2SVR, pC2SConnect2Svr, pProcessDataCtx->cpPacket);
	UNUSED_ARG(pProcessLayer);


	if( sizeof( C2S_CONNECT2SVR ) != pProcessDataCtx->iLen )
		return P_ERROR;

	pUserDataCtx->dwAuthKey = GetTickCount();

	S2C_CONNECT2SVR	sS2CConnect2Svr;
	sS2CConnect2Svr.wMagicCode = MAGIC_CODE;
	sS2CConnect2Svr.wPayLoadLen = sizeof( S2C_CONNECT2SVR );
	sS2CConnect2Svr.wMainCmd = CSC_CONNECT2SVR;

	sS2CConnect2Svr.dwAuthKey = pUserDataCtx->dwAuthKey;
	sS2CConnect2Svr.wIndex = pUserDataCtx->wUserIdx;
	sS2CConnect2Svr.wRecvXorKeyIdx 
			= static_cast<WORD>(pUserCtx->recvXorKeyIdx);
#if (_PROTODEF_VERSION_ > 0x0008)
    sS2CConnect2Svr.dwRecv2ndXorSeed = USERCONTEXT::XorKeyTable.XorSeed2nd;
#endif
	pUserCtx->UniCastE((char *)&sS2CConnect2Svr, sizeof( S2C_CONNECT2SVR ) );

	return P_OK;
}
 
Last edited:
Upvote 0
Junior Spellweaver
Joined
Jan 16, 2014
Messages
150
Reaction score
189
I am trying to simulate a custom client on the official game servers and it seams that the auth key in the packet with the opcode 101 is somehow validated by the backend. For me it looks like some random timestamp but also thought that it could come from the xingcode guard. Does anyone know how the auth key is generated in the client or becoming accepted by the backend without the official client?

I would double-check your encryption process, and make sure that you are setting the packet checksum correctly.
 
Upvote 0
Junior Spellweaver
Joined
Jan 16, 2014
Messages
150
Reaction score
189
Current EP8 setup for OnCSCConnect2Svr is:

That is the response packet. OP's problem is that he is not sending the request packet correctly, so the server is not responding. It is most likely due to an incorrect packet checksum.

The Packet Layout and encryption is correct so far the server is just not accepting the auth key somehow.

Here an Example:

The bold marked part is the auth key as documented in the open source project Minerva but the server doesn't accept it outside the official client it self.
 
Upvote 0
Back
Top