SMSG_AUTH_CHALLENGE 4.1.0

[Lordronn]

Смотрел снифф с 4.1.0. Опкоды в вайвере не обновлял, вот решил обновить. Наткнулся на такую вещичку

Теперь как я понял ходит не клиентский и сервеный аус опкод, а один в два направления

не SMSG_AUTH_CHALLENGE, а MSG_AUTH_CHALLENGE

Packet S->C, MSG_AUTH_CHALLENGE (0), 48 bytes,
╔══════╦═════════════════════════════════════════════════╦═════════════════╗
║OFFSET║  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F ║ 0123456789ABCDEF║
╠══════╬═════════════════════════════════════════════════╬═════════════════╣
║ 0000 ║ 57 4F 52 4C 44 20 4F 46 20 57 41 52 43 52 41 46 ║ WORLD OF WARCRAF║
║ 0010 ║ 54 20 43 4F 4E 4E 45 43 54 49 4F 4E 20 2D 20 53 ║ T CONNECTION - S║
║ 0020 ║ 45 52 56 45 52 20 54 4F 20 43 4C 49 45 4E 54 00 ║ ERVER TO CLIENT.║

Packet C->S, MSG_AUTH_CHALLENGE (0), 48 bytes,
╔══════╦═════════════════════════════════════════════════╦═════════════════╗
║OFFSET║  0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F ║ 0123456789ABCDEF║
╠══════╬═════════════════════════════════════════════════╬═════════════════╣
║ 0000 ║ 57 4F 52 4C 44 20 4F 46 20 57 41 52 43 52 41 46 ║ WORLD OF WARCRAF║
║ 0010 ║ 54 20 43 4F 4E 4E 45 43 54 49 4F 4E 20 2D 20 43 ║ T CONNECTION - C║
║ 0020 ║ 4C 49 45 4E 54 20 54 4F 20 53 45 52 56 45 52 00 ║ LIENT TO SERVER.║

После всего этого идет аус_респонс - 2570
Теперь аус данные ходят в другом пакете видимо,
Видимо они в аус_респонс-се теперь бродят, или идут после редирект пакета 32845

[Chameleon]

Теперь клиент ожидает пакет с такими данными при открытии каждого соединения.
Была тема про него на ммовнед.

[Йоха]

Сообщение от Chameleon

Теперь клиент ожидает пакет с такими данными при открытии каждого соединения.

теперь это когда ? в 4.0.6 так и было, каждое новое соединение начинается с того что приходит от сервера auth_chalenge. А этих соединений вагон открывается/закрывается

[RomanRom2]

жесть
зачем это им, интересно ...

[Fabian]

It's since 4.1.0

[Chameleon]

Проверка на этот текст была добавлена в NetClient__WCMessageReady в билде 13875.

[LordJZ]

Самое интересное, что у этих пакетов натурально нет опкода. Отправляется размер + данные.
Возникает вопрос, как сохранять этот пакет в, скажем, PKT 3.0 логах? Для себя я реализовал самое простое и, на мой взгляд и для моего сниффера, правильное решение: в лог пишу нулевой опкод, а модули чтения автоматически подставляют имена опкодов для обоих пакетов на основе Chunk Opt Data.

P.S. Ваши «аус» — это ужасно.

[RomanRom2]

ну люди не понимаю если что есть челенж как таковой, просто называют по ... [задумался]... да даже не знаю, что заставило ЭТО назвать челенжем.
нулевой опкод - самое правильное решение.

[LordJZ]

Сообщение от RomanRom2

...
нулевой опкод - самое правильное решение.

Да, но нулевые опкоды тоже существуют. Например, в 4.0.6 нулевой опкод соответствовал чему-товроде CMSG_MESSAGECHAT_WHISPER.

[TOM_RUS]

Может они хотят протокол перевести на текстовый? Типа
SERVER TO CLIENT MESSAGE - UPDATE OBJECT GUID XXX FIELD YYYY=ZZZZ

[HuntsMan]

Да впринципе пофиг как сохранять. Придется в ядре реализовывать формирование таких безопкодных пакетов.

[Йоха]

Если я правильно понял, SMSG_AUTH_CHALLENGE ни куда не делся, как и CMSG_AUTH_SESSION.
Просто теперь два первых пакета - безопкодные, потом идет все как обычно.

Скрытый текст (вы должны войти под своим логином или зарегистрироваться и иметь 10 сообщение(ий)):

У вас нет прав чтобы видеть скрытый текст, содержащейся здесь.

И теперь первые 4 пакета не шифруются

[LordJZ]

Сообщение от Йоха

Если я правильно понял, SMSG_AUTH_CHALLENGE ни куда не делся, как и CMSG_AUTH_SESSION.
Просто теперь два первых пакета - безопкодные, потом идет все как обычно.
*** скрытый текст ***И теперь первые 4 пакета не шифруются

Да (хайд не проверял)

[Lordronn]

Скрытый текст (вы должны войти под своим логином или зарегистрироваться и иметь 15 сообщение(ий)):

У вас нет прав чтобы видеть скрытый текст, содержащейся здесь.

[Йоха]

Сообщение от Lordronn

*** скрытый текст ***

блин, все верно, я перепутал местами коды в дефайнах

[Йоха]

Не могу понять почему у всех соединений кроме первого неправильно расшифровываются заголовки ?

единственное предположение что неправильно собираются сиды, но в иде вроде все тривиально :
Порядок я правильно понял ?

Скрытый текст (вы должны войти под своим логином или зарегистрироваться и иметь 50 сообщение(ий)):

У вас нет прав чтобы видеть скрытый текст, содержащейся здесь.

[LordJZ]

Скрытый текст (вы должны войти под своим логином или зарегистрироваться и иметь 50 сообщение(ий)):

У вас нет прав чтобы видеть скрытый текст, содержащейся здесь.

[Йоха]

хм, что-то я наверно не понял в иде

[Йоха]

раньше я смотрел порядок в функции PacketRead_SMSG_AUTH_CHALLENGE
а сейчас что-то поменялось ?

[Evgeniy]

SMSG_AUTH_CHALLENGE 16826 никак не могу найти в IDA порядок сидов...кто может помочь?

signed int __thiscall RealmConnection__HandleAuthChallenge(int this, void *a2)
{
  int v2; // ecx@1
  int v3; // esi@1
  char *v4; // eax@3
  signed int v5; // ebx@3
  int v6; // eax@3
  int v7; // ecx@3
  char v8; // dl@3
  int v9; // eax@3
  char v10; // cl@4
  int v11; // eax@9
  int v12; // eax@9
  int v13; // ecx@9
  int v14; // edx@9
  int v15; // eax@9
  char v16; // cl@10
  char v18; // [sp+4h] [bp-5F8h]@3
  int v19; // [sp+14h] [bp-5E8h]@9
  char v20; // [sp+18h] [bp-5E4h]@11
  int v21; // [sp+2Ch] [bp-5D0h]@9
  int v22; // [sp+34h] [bp-5C8h]@9
  int v23; // [sp+38h] [bp-5C4h]@9
  int v24; // [sp+3Ch] [bp-5C0h]@3
  int v25; // [sp+40h] [bp-5BCh]@9
  char v26; // [sp+44h] [bp-5B8h]@3
  int v27; // [sp+48h] [bp-5B4h]@3
  char v28; // [sp+4Ch] [bp-5B0h]@3
  __int16 v29; // [sp+4Eh] [bp-5AEh]@3
  char v30; // [sp+50h] [bp-5ACh]@3
  char v31; // [sp+550h] [bp-ACh]@9
  int v32; // [sp+554h] [bp-A8h]@11
  int v33; // [sp+57Ch] [bp-80h]@9
  char v34; // [sp+5D8h] [bp-24h]@12
  char v35; // [sp+5ECh] [bp-10h]@3
  int v36; // [sp+5F4h] [bp-8h]@3
  int v37; // [sp+5F8h] [bp-4h]@9

  v3 = this;
  v2 = *(_DWORD *)(this + 18224);
  if ( v2 )
    (*(void (__stdcall **)(int, _DWORD, _DWORD, _DWORD))(*(_DWORD *)v2 + 24))(v3, "SMSG_AUTH_CHALLENGE", 0, 0);
  *(_BYTE *)(v3 + 18240) = 0;
  SecureRandom__Seed(0);
  v6 = OsGetAsyncTimeMs();
  SecureRandom__Seed(v6);
  sub_7023D0(&v18);
  v7 = *(_DWORD *)(v3 + 1284);
  v8 = *(_BYTE *)(v3 + 1328);
  v29 = 16826;
  v26 = 1;
  v27 = v7;
  v28 = v8;
  v9 = SecureRandom__GetHash(&v35);
  v24 = v9;
  v36 = v9;
  v4 = &v30;
  v5 = 1279;
  while ( 1 )
  {
    v10 = v4[v3 + 4 - (_DWORD)&v30];
    *v4++ = v10;
    if ( !v10 )
      break;
    --v5;
    if ( !v5 )
      goto LABEL_8;
  }
  if ( v5 )
    goto LABEL_9;
LABEL_8:
  *v4 = 0;
LABEL_9:
  v12 = *(_DWORD *)(v3 + 18276);
  v13 = *(_DWORD *)(v3 + 18280);
  v19 = *(_DWORD *)(v3 + 18272);
  v14 = *((_DWORD *)a2 + 2);
  v21 = v12;
  v15 = *((_DWORD *)a2 + 3);
  v25 = v13;
  v22 = v14;
  v23 = v15;
  v37 = 0;
  v31 = *(_DWORD *)(dword_F7DB40 + 48) != 0;
  SHA1__Init(&v33);
  v11 = v3 + 4;
  do
    v16 = *(_BYTE *)v11++;
  while ( v16 );
  SHA1__Update((int)&v33, (void *)(v3 + 4), v11 - (v3 + 5));
  SHA1__Update((int)&v33, &v37, 4);
  SHA1__Update((int)&v33, &v36, 4);
  SHA1__Update((int)&v33, a2, 4);
  SHA1__Update((int)&v33, (void *)(v3 + 1288), 40);
  SHA1__Final(&v20, &v33);
  WriteAddOns(&v32);
  (*(void (__thiscall **)(int *))(v32 + 28))(&v32);
  NetClient__Send(&v18, 2);
  if ( !*(_DWORD *)(dword_F7DB18 + 48) )
  {
    sub_701BB0(&v34);
    NetClient__Send(&v34, 2);
    sub_7578B0(&v34);
  }
  sub_702350(&v18);
  return 1;
}

[Fabian]

void *__thiscall ClientConnectionAuthChallenge::CliGet(void *this, int a2, int a3)
{
  void *v3; // esi@1
  int v4; // esi@1
  signed int v5; // ebx@1
  void *result; // eax@3
  void *v7; // [sp+Ch] [bp-8h]@1
  char v8; // [sp+13h] [bp-1h]@1

  v3 = this;
  v7 = this;
  v8 = 0;
  CDataStore::GetUInt8(&v8);
  *((_BYTE *)v3 + 52) = v8;
  v4 = (int)((char *)v3 + 20);
  v5 = 8;
  do
  {
    a2 = 0;
    CDataStore::GetUInt32(&a2);
    *(_DWORD *)v4 = a2;
    v4 += 4;
    --v5;
  }
  while ( v5 );
  a2 = 0;
  CDataStore::GetUInt32(&a2);
  result = v7;
  *((_DWORD *)v7 + 4) = a2;
  return result;
}