Client Authorization

[Katil92]

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?

 

[Katil92]

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?

 

[geography]

you must fix the packet of client match for serverside!

 

[Katil92]

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.

 

[estsoft]

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.

 

[Niicke]

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

byte ServerIdx
byte GroupIdx
byte Reserved0
byte Reserved1

 

[estsoft]

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

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:

uint Reserved;

 

[Niicke]

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



The LoginSvr packet is just:

uint Reserved;

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

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

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;
}

 

[estsoft]

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.

 

[estsoft]

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.

 

[Katil92]

This was really helpful thank you very much. Are you able to disassemble the most recent clients?