[4.0.1:13205] Auth @ Realmserver

[Cromon]

Hey there!

Im working on the network protocol of 4.0.1 and got a nice amount of opcodes. Basically up to a certain point a sandbox already works but im now a bit stuck extending the information to be more precise and not just "By sending those bytes it magically works". Actually im working on the proper handling of SMSG_AUTH_CHALLENGE and CMSG_AUTH_SESSION.

So far ive got the following:

struct SMSG_AUTH_CHALLANGE
{
         uint8 unk1[9];
         uint32 serverSeed;
         uint8 unk2[25];
};

struct CMSG_AUTH_SESSION
{
uint8 unk1[24];
uint16 build;
uint8 unk2[14];
uint32 clientSeed;
uint8 unk3[8];
uint32 sizeTillAccountName;
uint32 sizeAddonsUncompressed;
uint8 addonsCompressed[sizeTillAccountName - 4];
string AccountName;
};
[/code]

Ok, so far so good, in the client this now looks like that:

int __thiscall CreateCMSG_AUTH_SESSION(void *this, int a2)
{
  void *v3; // esi@1
  int v4; // ebx@1

  v3 = this;
  CDataStore__WriteUInt32(0x3000u);
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1364));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1368));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1374));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1377));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1388));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1363));
  CDataStore__WriteUInt32(*((_DWORD *)v3 + 336));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1365));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1348));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1360));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1370));
  CDataStore__WriteUInt32(*((_DWORD *)v3 + 346));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1372));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1366));
  CDataStore__WriteUInt32(*((_DWORD *)v3 + 5));
  CDataStore__WriteUInt16(*((_WORD *)v3 + 690));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1367));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1371));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1376));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1378));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1373));
  CDataStore__WriteUInt64(*((_DWORD *)v3 + 338), *((_DWORD *)v3 + 339));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1375));
  CDataStore__WriteUInt32(*((_DWORD *)v3 + 4));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1369));
  CDataStore__WriteUInt32(*((_DWORD *)v3 + 6));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1361));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1362));
  CDataStore__WriteUInt8(*((_BYTE *)v3 + 1379));
  CDataStore__WriteUInt32(*((_DWORD *)v3 + 331));
  *((_DWORD *)v3 + 332) = 0;
  v4 = *((_DWORD *)v3 + 331) - *((_DWORD *)v3 + 332);
  sub_7C9AD0(&a2, *((_DWORD *)v3 + 331) - *((_DWORD *)v3 + 332));
  CDataStore____jmp_WriteBytes(a2, v4);
  return CDataStore__WriteString((char *)v3 + 28);
}

First thing im irritated:
Before cataclysm the client sent 20 bytes with its hash in CMSG_AUTH_SESSION. From the layout i see above there is no place where 20 bytes get written. So is the verifier transmitted in another form (maybe placed in another weak hash?)

The hash i was talking about can be found in CNetClient::HandleAuthChallenge:

// preceding some other auth_challenge code
 SHA1Init(&v32);
  v11 = v3 + 4;
  do
    v16 = *(_BYTE *)v11++;
  while ( v16 );
  SHA1Update(&v32, v3 + 4, v11 - (v3 + 5));     // AccountName
  SHA1Update(&v32, &v35, 4);                    // 0 (v35 = 0)
  SHA1Update(&v32, &v34, 4);                    // ClientSeed
  SHA1Update(&v32, a2, 4);                      // ServerSeed
  SHA1Update(&v32, v3 + 0x508, 40);             // SessionKey
  SHA1Unk(&v28, &v32);
  sub_463F60();
  (*(void (__thiscall **)(int *))(v23 + 28))(&v23);
  sub_48F580(&v18);
  sub_954BE0(&v18);
  return 1;
}

Now my other problem is that v32 (which is SHA_CTX) is a local variable of that function and is first used in SHA1Init. That irritates me. v32 is never used after SHA1Unk so the hash seems to be lost?

Does anyone of you have some more info about the auth-protocol? Would be really nice!

Greetings
Cromon

[TOM_RUS]

Nothing is lost, you just doing it wrong: Paste2: Next Generation Pastebin - Viewing Paste 1061795

[Cromon]

Nah, its correctly working now. CMSG_AUTH_SESSION looks like that:

                var hash = new byte[20];
                hash[4] = packet.ReadByte();
                hash[8] = packet.ReadByte();
                hash[14] = packet.ReadByte();
                hash[17] = packet.ReadByte();
                byte unk5 = packet.ReadByte(); // => 1
                hash[3] = packet.ReadByte();
                uint unk7 = packet.ReadUInt32(); // => 0
                hash[5] = packet.ReadByte();
                byte unk9 = packet.ReadByte();
                hash[0] = packet.ReadByte();
                hash[10] = packet.ReadByte();
                uint unk12 = packet.ReadUInt32(); // => 0
                hash[12] = packet.ReadByte();
                hash[6] = packet.ReadByte();
                uint unk15 = packet.ReadUInt32(); // => 0
                var build  = packet.ReadUInt16();
                hash[7] = packet.ReadByte();
                hash[11] = packet.ReadByte();
                hash[16] = packet.ReadByte();
                hash[18] = packet.ReadByte();
                hash[13] = packet.ReadByte();
                ulong unk21 = packet.ReadUInt64();
                hash[15] = packet.ReadByte();
                client.ClientSeed = packet.ReadUInt32();
                hash[9] = packet.ReadByte();
                uint unk24 = packet.ReadUInt32();
                hash[1] = packet.ReadByte();
                hash[2] = packet.ReadByte();
                hash[19] = packet.ReadByte();
                var addonSize = packet.ReadUInt32();
                uint uncompressed = packet.ReadUInt32();
                var addons = packet.ReadBytes((int)(addonSize - 4));
                var accName = packet.ReadCString();
                client.ClientDigest = hash;

And to test:

				try
				{
					client.SessionKey = authInfo.SessionKey;
					client.Info = ClientInformation.Deserialize(authInfo.SystemInformation);

					var srp = new SecureRemotePassword(accountName, authInfo.Verifier, authInfo.Salt);

                    SHA hash = new SHA();
                    hash.Update(accountName);
                    hash.Update((uint)0);
                    hash.Update(client.ClientSeed);
                    hash.Update(RealmServer.Instance.AuthSeed);
                    hash.Update(client.SessionKey);
                    hash.Final();
                    BigInteger clientVerifier = new BigInteger(hash.Digest);

					if (clientVerifier != client.ClientDigest)
					{
						LoginHandler.SendAuthSessionErrorReply(client, LoginErrorCode.AUTH_FAILED);
                        return false;
					}
					else
					{
						return true;
					}
				}

[TOM_RUS]

Lol, exactly match to my hex-rays output:

void __thiscall PacketWrite_CMSG_AUTH_SESSION(AuthSession *this, CDataStore *data)
{
  CDataStore *_data; // edi@1
  AuthSession *_this; // esi@1
  int size; // ebx@1

  _data = data;
  _this = this;
  CDataStore__PutInt32(data, 0x3000u);          // opcode = CMSG_AUTH_SESSION
  CDataStore__PutInt8(_data, _this->digest[4]);
  CDataStore__PutInt8(_data, _this->digest[8]);
  CDataStore__PutInt8(_data, _this->digest[14]);
  CDataStore__PutInt8(_data, _this->digest[17]);
  CDataStore__PutInt8(_data, _this->unk20[0]);
  CDataStore__PutInt8(_data, _this->digest[3]);
  CDataStore__PutInt32(_data, _this->unk12);
  CDataStore__PutInt8(_data, _this->digest[5]);
  CDataStore__PutInt8(_data, _this->unk13[0]);
  CDataStore__PutInt8(_data, _this->digest[0]);
  CDataStore__PutInt8(_data, _this->digest[10]);
  CDataStore__PutInt32(_data, _this->unk19);
  CDataStore__PutInt8(_data, _this->digest[12]);
  CDataStore__PutInt8(_data, _this->digest[6]);
  CDataStore__PutInt32(_data, _this->unk5);
  CDataStore__PutInt16(_this->build[0]);
  CDataStore__PutInt8(_data, _this->digest[7]);
  CDataStore__PutInt8(_data, _this->digest[11]);
  CDataStore__PutInt8(_data, _this->digest[16]);
  CDataStore__PutInt8(_data, _this->digest[18]);
  CDataStore__PutInt8(_data, _this->digest[13]);
  CDataStore__PutInt64(_this->UnkUInt64.low, _this->UnkUInt64.high);
  CDataStore__PutInt8(_data, _this->digest[15]);
  CDataStore__PutInt32(_data, _this->unk4);
  CDataStore__PutInt8(_data, _this->digest[9]);
  CDataStore__PutInt32(_data, _this->clientSeed);
  CDataStore__PutInt8(_data, _this->digest[1]);
  CDataStore__PutInt8(_data, _this->digest[2]);
  CDataStore__PutInt8(_data, _this->digest[19]);
  CDataStore__PutInt32(_data, _this->addonData.m_size);
  _this->addonData.m_read = 0;
  size = _this->addonData.m_size - _this->addonData.m_read;
  CDataStore__GetBytesArray(&_this->addonData, (int)&data, _this->addonData.m_size - _this->addonData.m_read);
  CDataStore__PutBytesArray(data, size);
  CDataStore__PutCString(_data, _this->accountName);
}

[Cromon]

Yep, i also got it from my hexrays output of CreateCMSG_AUTH_SESSION (see first post). After testing everything else i started counting the adjacent bytes and realized that there are 20

[MaiN]

WTF? Why do they write the bytes like that? It's not like it was hard to figure out and it's very annoying to look at. Or perhaps it's randomized so you'll have to figure out the order next patch?

[LordJZ]

WTF? Why do they write the bytes like that? It's not like it was hard to figure out and it's very annoying to look at. Or perhaps it's randomized so you'll have to figure out the order next patch?

The same reason they randomized opcodes

[TOM_RUS]

WTF? Why do they write the bytes like that? It's not like it was hard to figure out and it's very annoying to look at. Or perhaps it's randomized so you'll have to figure out the order next patch?

It's randomized The guy who wrote that shit is really crazy. I like how they waste theirs time on that shit instead of fixing bugs or something else...

[XTZGZoReX]

That's just one of many stupid attempts to obfuscate their packets.

[davehh]

struct SMSG_AUTH_CHALLANGE
{
         uint8 unk1[9];
         uint32 serverSeed;
         uint8 unk2[25];
};

SMSG_AUTH_CHALLANGE is

struct SMSG_AUTH_CHALLENGE
{
    uint32 ClientKey_part3;
    uint32 ServerKey_part1;
    uint8  unk;
    uint32 Seed;
    uint32 ServerKey_part3;
    uint32 ServerKey_part2;
    uint32 ClientKey_part1;
    uint32 ClientKey_part2;
    uint32 ServerKey_part4;
    uint32 ClientKey_part4;
};

You'll need these ServerKey and ClientKey after SMSG_REDIRECT_CLIENT.

[Cromon]

Ok, interesting, atm i do not need SMSG_REDIRECT_CLIENT.

[TOM_RUS]

Ok, interesting, atm i do not need SMSG_REDIRECT_CLIENT.

Client won't send you movement and bunch of other opcodes if you ignore SMSG_REDIRECT_CLIENT. You can enter world, but you can't interact with client (movement, spell casting and many other things won't work).

[Cromon]

I can enter world and move without problems.

[TOM_RUS]

I can enter world and move without problems.

Sorry for typos. You can enter world, move etc, but server won't know where client is because client won't sent movement packets.

For some reason forum ignores my modifications in previous post.

[Cromon]

Sorry for typos. You can enter world, move etc, but server won't know where client is because client won't sent movement packets.

Ah, ok, thats very interesting, that saves me a lot of reversing time finding a problem that doesnt even exists