XFER

[RomanRom2]

понадобилось мне тут прикрутить таки эту фичу на сервере
правда нужна она мне в другом проекте, ну да не важно...

сижу, курю, ничего не понимаю...
объявлено несколько опкодов, XFER_INIT, XFER_DATA, XFER_ACCEPT, XFER_RESUME, XFER_CANCEL.

клиент 1.12.1, посылаю ему XFER_INIT в формате:

    FileNameLength: byte;
    FileName: string;
    FileSize: uInt64;
    FileMD5: array [0..15] of byte;

... и не понимаю следующего:
1. даунлоадинг на клиенте запускается (появляется этот синенький фон от эльфов) только если имя файла в структуре равно 'Patch', 5 байт. с другим именем фона эльфов не появляется, просто "кнопка" Connecting заменяется на Downloading.

2. никакие опкоды клиент не посылает. никаких ACCEPT, RESUME и уж тем более CANCEL я не наблюдал. если во время даунлоадинга патча нажать кнопку "Cancel", то клиент просто закрывает соединение и все. когда ж они посылаются?

3. непонятно с именем файла. указывать нужно обязательно Patch, при этом клиент создает файл wow-patch.mpq. как же тогда получались всякие WoW-1.9.1.4983-to-1.9.2.4996-enGB-patch.exe и/или их даулоадеры? зачем тогда указывать имя файла, если работает только одно единственное? или быть может там есть и другие варианты?

4. клиент создает wow-patch.mpq сразу того размера, который указан в структуре, только на 40 байт больше. почему? как он понимает, что файл не докачен и посылает опкод XFER_RESUME?

5. после посылки INIT нужно слать последовательно XFER_DATA любыми блоками, при этом клиент так же не присылает никаких подтверждающих опкодов, но при этом правильно показывает процент прогресса. т.е. по сути отправка патча заключается в посылке двух опкодов, сначала INIT, затем нескольких DATA. остальное клиент все сделает сам. это действительно работает и странно тогда, зачем нужны ACCEPT, RESUME, CANCEL.

есть мнение, что сервер должен посылать файл-архив MPQ, внутри которого тот самый экзешник. но я помню еще у вада на wowemu был сделан XFER, и у клиентов оседали патчи с правильными именами. надо блин достать из архивов и проснифать чтоли...

поиск по имеющимся у меня сорцам эмуляторов тех времен показал, что везде реализованы опкоды INIT и DATA, с именем файла Patch. так же реализованы обработчики ACCEPT, RESUME и CANCEL c понятным функционалом.

может кто знает что с этим можно сделать?

[RomanRom2]

4. в конец файла дописывается структура 40 байт:

fnID: longint; = 66 6E 49 44, fnID собственно
fnIDUnk: longint; = 0
fnMD5: array[0..15] of byte;
fnDownloadedBytes: uInt64;
fnSize: uInt64;

[RomanRom2]

2 и 5. прошу прощения, присылается все. у меня были пустые обработчики уже сделаны, я просто про них забыл и думал что их нет.

[RomanRom2]

все сделал. всем спасибо за помощь.

[YuruY]

Дак у нас всегда так с помощью, раньше такое было только на TC а последнее время и Мангос этим страдает.
Такчто скажу за всех: "незачто, обращайтесь исЧо, чем сможем тем поможем".



Печалька, чо. Вот иду в очередной раз в рейд (со сниффером конечно а их (сниффов) уже с панд у меня гигами) и думаю .. а нужноль это будет комуто и когдато?
Но привычка ... че там без сниффера и на оффе еще делать. /:

[RomanRom2]

да не, все нормально на самом деле я и не расчитывал особо, т.к. понимал, что маловероятно об этом кто то что то помнит или знает, тема то непопулярная.

насчет снифов - складывай пока, они по любому пригодятся. по моему разумению наиболее ценные снифы последнего билда в транке (в связи с изменяющимися опкодами и пр. структурами). так, последний билд катаклизма уже состоялся, но не знаю как со снифами для него. а по пандам есть мнение, что патчей больше не будет, только новый аддон. это, например, косвенно можно оценить по поступившей информации о продлении пвп сезона. новый сезон открывается обычно с новым пве контентом, поэтому есть такое вот мнение.

не берусь конечно просить их (снифы), но с удовольствием взял бы. медленно, но верно, я двигаюсь к ним через классические клиенты и когда нибудь таки доберусь

каким снифером можно сейчас пользоваться? тоже бы поснифал, ибо играю довольно много в последнее время.

[Konctantin]

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

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

[RomanRom2]

спасибо, работает снифы потекли рекой
надеюсь близзы не научились палить инжекторы. оно поддерживает два соединения? по формату снифа вижу что да, но сам снифф пока не смотрел, что там.

[Konctantin]

RomanRom2, хочу допилить чтобы писался ИД (ConnectionIndex) соединения, но не представляю от куда его вытянуть. Есть какие-то идеи?

[RomanRom2]

по спецификации ID соединения может быть любым и в рамках одного сниффа должно быть разным. например 1 и 2, "a" и "b", не важно, лишь бы они были разные. это что касается самого значения.

изначально предполагалось, что тянуть это значение как бы и не откуда... поэтому его можно (и нужно) придумывать самому. а именно "мониторить" соединения и (далее варианты) - например, инкрементировать значение на каждое новое подключение клиента; брать адрес (указатель/поинтер) какого нибудь хендлера этого соединения; получать какой нибудь "хеш" от "ип адрес"+"порт"; тд и тп.

[YuruY]

а по пандам есть мнение, что патчей больше не будет, только новый аддон. это, например, косвенно можно оценить по поступившей информации о продлении пвп сезона. новый сезон открывается обычно с новым пве контентом, поэтому есть такое вот мнение.

Какраз под новый "полусезон" на птр поставили 5.4.7 (чеб еще разок опкоды не сменить, а может еще не раз).

[RomanRom2]

есть собранный сниффер под свежий билд? нужно время, что бы вникнуть в сорцы, а его как всегда ...

[YuruY]

Константину в ПМ напиши.

[SeT]

https://github.com/Anubisss/SzimatSzatyor снифер под последний билд

[Konctantin]

Интересно, а детектится ли данный сниффер? точнее не спалится ли загрузка сторонней длл?

Судя по сканируемыми адресам точки инжекта не проверяются, а вот безопасна ли сама загрузка дллки?

[Fabian]

another sniffer written in C# by me can be found on https://github.com/Arctium/Arctium-Tools
As far as I know the addresses NetClient::Send and NetClient::ProcessMessage are not scanned by things like warden so the injection is save atm.

А в чем преимущество инжектящегося сниффера? Не проще ли просто собирать траффик и разбирать его?

[Konctantin]

Сначала о сложностях перехвата трафика:
* Весь трафик зашифрован (имеется в виду заголовки сам опкод и размер пакета)
* Есть несколько сессий и переконеты, который шифруются по разному
* Переконект это такой пакет. в котором приходят данные о том куда переподключатся (этот пакет надо разбирать)
* и еще кажись кое что

И так, для того чтобы собрать трафик, надо разшифровать заголовки, отслеживать пакет переконекта, перечитывать ключ сессии, и собирать в кучу кучки пакетов, и еще обрабатывать Large пакеты.

теперь по поводу инжектора:
для его работы надо всего знать 2 адреса для перехвата, которые ищутся очень легко.

ЗЫ. Пакет переконекта постоянно шифруют по разному.

ЗЫЫ. С инжектором не надо парится с сжатыми пакетами.

Пакет "переконекта" не нужен. Все что нужно для расшифровки новой сессии - сиды для HMAC, они идут в SMSG_AUTH_CHALLENGE (ну второй пакет от сервера).

Со сжатием вроде бы тоже ничего сложного, обычный DEFLATE.

А с инжектором остается надеяться, что проверку не добавят.

[Konctantin]

только как вы будете знать с какой сессси снифать трафик?

Снифать со всех?

[Konctantin]

я уже не помню что та ми к чему, но помню что обновлять сниффер под новую версию клиента - это гемор еще тот. а вот с инжектором - всего 2 оффсета.

Вот к примеру:

         
FILL_OFFSET(17688, 0x3988D7, 0x3965BB, 0xE7080C);
FILL_OFFSET(17898, 0x399B6A, 0x3979B2, 0xE73344);
FILL_OFFSET(17930, 0x39A93E, 0x398786, 0xE75344);
FILL_OFFSET(17956, 0x39A66A, 0x398482, 0xE75344);

я читаю еще и локаль, для имени снифа

[Konctantin]

Есть еще способ, без инжекта, отладчиком - 2 HW бряка на отправку и приемку и читаем данные c помощью ReadProcessMemory

[Fabian]

I think the easiest and still secure way is to do it over a dll injection.
I use Netclient::ProcessMessage and Netclient::Send atm, but I should use NetClient::OneMessageReady too because some smsg opcodes won't be catched over ProcessMessage, but the most will be and the most important...

Of course you can just capture the tcp packets and decrypt them later, but for this you always need the sessionkey (easy to get). anf if one packet is fucked up or you forget to decrypt it, all future packets can't be decrypted, because the crypt stuff is out of sync then.

[RomanRom2]

мне кажется Константин слегка преувеличивает сложность перехвата трафика

проблемы с сессиями действительно никакой нет, снифать нужно все сессии. раньше это было две-три сессии последовательных, теперь две параллельных. трафик нужен из обоих.

шифрованность трафика тоже как бы не является проблемой, т.к. зная сессионый ключ можно потом делать с собранным RAW все что угодно, вплоть до распаковки варден модулей.

со сжатыми данными я, честно говоря, тоже не припомню каких либо проблем. мы собираем тот трафик, который в натуре как бы. причем тут сжатый не сжатый... не понял в общем.

снифер типа "инжектор" действительно является самым простым с точки зрения затрат на сбор и обработку непосредственно данных: на выходе имеем готовый расшифрованный сетевой дамп, с которым ничего делать не надо. ибо инжектор перехватывает готовые к отправке/приему буферы, в которых все уже готово, ни больше ни меньше. но он не является безопасным, как об этом говорит Фабиан. опять же, с точки зрения близзов - когда нибудь могут и запалить.

безопасным снифером можно считать снифер типа pcap. он никуда не внедряется, ничего не перехватывает из чужого процесса и всякое такое. он работает на сетевом интерфейсе. это безопасно с точки зрения близзов. но на выходе мы имеем RAW, который потом придется декодировать, т.е. совершать какие то телодвижения, напрягаться. тут только можно сказать что то вроде "ах, ужас какой!" один раз сделать декодер и тоже не париться. или сразу делать декодирование на лету, многие сниферы так и делались.

но самым прозрачным и безопасным снифером до сих пор остается снифер четвертого поколения, который пока что никто не смог повторить. по правде сказать тут слегка в тему анекдот про неуловимого джо

в любом случае залезать в процесс экзешника нам все равно необходимо для того что бы вытащить ключ. пожалуй за исключением инжектора, там ключ по факту не нужен. если только потом, для варден модулей, коль уж мы все равно залезли в процесс, чо бы и не вытащить ключ.

времена, когда не нужно было ни того ни другого, прошли. ключ можно было собрать по трафику в до HMAC-овские времена.

ну и еще хотел бы добавить, что за мою скоро уже 10ти летнюю практику снифанья никогда инжектор не палился, чего ему и желаю дальше только вот мне никогда такой способ не поддавался

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

для его работы надо всего знать 2 адреса для перехвата, которые ищутся очень легко.

ну вот как? каааааак? с чего начинать, куда смотреть... расскажите методу, плиз.

но вот что еще меня удивляет. я помню, когда мы делали инжектор (им занимался Deamon), там нужно было не только офсеты для буферов перехватывать, а еще и "патчить" проверки от изменений памяти. итого что то 4-5 проверок снимать. разве этого сейчас делать не нужно? близзы стали так халатно относится к своей интеллектуальной собственности? сомневаюсь.

[Konctantin]

ну вот как? каааааак? с чего начинать, куда смотреть... расскажите методу, плиз.

Ну я не спец в этом, а ищу их можна сказать по строке "ClientServices.cpp"
выше находится массив с функциями:


внутри NetClient__ProcessMessage0 - находится функция ту которую мы ищем.

signed int __thiscall NetClient__ProcessMessage0(void *this, int a2, int a3, int a4)
{
  void *v4; // edi@1
  bool v5; // zf@1
  int v7; // [sp+4h] [bp-18h]@2
  int v8; // [sp+8h] [bp-14h]@2
  int v9; // [sp+Ch] [bp-10h]@2
  int v10; // [sp+10h] [bp-Ch]@2
  int v11; // [sp+14h] [bp-8h]@2
  int v12; // [sp+18h] [bp-4h]@2

  v4 = this;
  sub_798A6B();
  v5 = *((_DWORD *)v4 + 339) == 5;
  dword_10AB260 += a4 + 2;
  if ( v5 )
  {
    v10 = -1;
    v8 = a3;
    v11 = a4;
    v9 = 0;
    v12 = 0;
    v7 = (int)off_D298E8;
    NetClient__ProcessMessage(a2, &v7, 0);
    v7 = (int)off_D298E8;
    sub_408F9E(&v7);
  }
  sub_79B357();
  return 1;
}

это приемка пакетов, а отправка тоже по строке ("creaturecache.wdb"):
единственная ссылка ведет нас сюда

  sub_628B9E(1464684354, "creaturecache.wdb", PH_CMSG_CREATURE_QUERY, 0, 0, 1, 0);

а в PH_CMSG_CREATURE_QUERY

void __cdecl PH_CMSG_CREATURE_QUERY(int a1)
{
  char v1; // [sp+0h] [bp-14h]@1
  int v2; // [sp+10h] [bp-4h]@1

  sub_6909BB(&v1);
  v2 = *(_DWORD *)a1;
  NetClient__Send_d(&v1);
  sub_690F91(&v1);
}

int __cdecl NetClient__Send_d(int a1)
{
  int result; // eax@1
  void *v2; // eax@2

  result = sub_A65D94();
  if ( result )
  {
    v2 = (void *)sub_A65D94();
    result = sub_79A82A(v2, a1, 2);             // NetClient__Send
  }
  return result;
}

int __thiscall sub_79A82A(void *this, int a2, int a3)
{
  int v3; // ebx@1
  int v4; // eax@1
  int v6; // [sp+Ch] [bp-18h]@1
  int v7; // [sp+10h] [bp-14h]@1
  int v8; // [sp+14h] [bp-10h]@1
  int v9; // [sp+18h] [bp-Ch]@1
  int v10; // [sp+1Ch] [bp-8h]@1
  int v11; // [sp+20h] [bp-4h]@1

  v11 = -1;
  v3 = (int)this;
  v4 = *(_DWORD *)a2;
  v6 = (int)off_D298E8;
  v7 = 0;
  v8 = 0;
  v9 = 0;
  v10 = 0;
  (*(void (__stdcall **)(int *))(v4 + 8))(&v6);
  v11 = 0;
  NetClient__Send2(v3, (int)&v6, a3);
  v6 = (int)off_D298E8;
  return sub_408F9E(&v6);
}

Способы примитивные, но хз... как-то так и ищу.
Последние 2 раза делал дифы баз ИДА.

[Fabian]

PH_CMSG_CREATURE_QUERY: Contains a constructor and the destructor at the end:

CliQueryCreature::CliQueryCreature and CliQueryCreature::~CliQueryCreature

or Player before the Cli, but I don't remember.

The construcor contains an offset (vtable) which points to functions for read the data from CDataStore, read the netmessage (opcode) as uint32.

your 'NetClient__ProcessMessage0' is 'NetClient::HandleData'
your 'sub_79A82A' has JamClientMessage and CONNECTION_ID as args and is named ::Send too you ::Send2 just have CDataStore as first arg.

NetClient__Send_d is used a few times too yea, but it calls the netClient functions, so..
NetClient__Send_d:

int __cdecl ClientServices::Send(JamClientMessage *a1)
{
  int result; // eax@1
  void *v2; // eax@2

  result = ClientServices::Connection();
  if ( result )
  {
    v2 = (void *)ClientServices::Connection();
    result = NetClient::Send(v2, a1, 2); // NetClient::Send(JamClientMessage *,CONNECTION_ID)
  }
  return result;
}

there is another ClientServices::Send function for the old stuff which calls 'NetClient::Send(CDataStore *,CONNECTION_ID)' instead of the JamClientmessage stuff.

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

но самым прозрачным и безопасным снифером до сих пор остается снифер четвертого поколения, который пока что никто не смог повторить. по правде сказать тут слегка в тему анекдот про неуловимого джо

Ну это уже лишнее... Я вот играю в WoW через Wine и собираю пакеты tcpdump, в этом случае уже очень сложно спалить факт перехвата траффика, если вообще возможно. А настоящие параноики могут и где-нибудь на роутере траффик собирать.

[RomanRom2]

ну я так и сказал - анекдот про неуловимого джо
- а чо, его никто поймать не может?
- да нахер он кому нужен...

близзы, к слову, умеют палить проксификаторы. это достоверная информация. они ругаются, но не банят за них, понимают, что в некоторых случаях без такого способа подключения не обойтись. а это вообще говоря один из способов сбора снифов.

[LordJZ]

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

...
близзы, к слову, умеют палить проксификаторы. это достоверная информация. они ругаются, но не банят за них, понимают, что в некоторых случаях без такого способа подключения не обойтись. а это вообще говоря один из способов сбора снифов.

Ну правильно, стандартные методы-то они игнорируют, вот и приходится пользоваться.

[Konctantin]

Кто может поделится структурой JamClientMessage?
На сколько я понимаю там что-то на подобии такого:

struct JamClientMessage
{
    void *vTable {
        void Release();
        void WriteData();
        void WriteOpcode();
        void Unk2();
        void Unk3();
    };
    DWORD m_unk4;  
    DWORD m_unk8;
    DWORD m_unk12;
    DWORD m_unk16;
    DWORD m_unk20;
    DWORD m_unk24;
    DWORD m_unk28;
};

[RomanRom2]

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

[SeT]

https://github.com/Anubisss/SzimatSzatyor
Да все также...