Сниффер

[RomanRom2]

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

Приветствую,
решил написать свой сниффер, больше из спортивного интереса.

похвально. спрашивайте, поможем. какой формат снифов используете?

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

использовать pcap мне почему-то не понравилось ... И с первого взгляда я не нашел как фильтровать трафик от конкретного приложения.

я вам в прошлый раз наврал, у меня не pcap, а pssdk. но роли особой не меняет. фильтры тут настраиваются очень и очень просто, пример по этой ссылке: http://www.microolap.com/products/ne...PF_example.htm

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

Больше всего понравился вариант предложеный abdula123.

ну понятно, по проксёвому пути пошли. ну что ж, ждем продолжения.

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

Настраиваем правило, для приложения wow весь трафик перенаправлять на localhost, наш порт. И все, весь поток данных от wow.exe у нас. Вчера много тупил, сегодня мой прокси отлично работает.

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

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

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

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

[Йоха]

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

похвально. спрашивайте, поможем. какой формат снифов используете?

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

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

я вам в прошлый раз наврал, у меня не pcap, а pssdk. но роли особой не меняет. фильтры тут настраиваются очень и очень просто, пример по этой ссылке: http://www.microolap.com/products/ne...PF_example.htm

Да это практически тоже самое , в общем все равно, не хочется связываться с разбором пакетов :-)

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

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

инфа 100% ?

насчет бана уверен что его никогда не будет. Сам по себе проксификатор - абсолютно легальное решение. И может использоваться на компьютере для совершенно не связяных с вов задач.
К тому же я играл как-то год назад через проксификатор наверно недели 2 на офе, когда у нашего провайдера были какие-то проблемы с маршрутом, пакеты терялись по пути в европу и играть было совершенно невозможно. Нашел прокси в инете, до которого был хороший маршрут без потери пакетов и через него отлично играл.
А определить трафик какого приложения проксификатор заворачивает на прокси - невозможно, это делается в ядерном драйвере.

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

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

угу, запасся исходниками tiawps ... но учитывая что моему проекту всего 2 дня, пока до всего еще руки не дошли :-)
тем более на работе не всегда бывает время полностью посвятить себя програмированию, иногда приходится работать ;-)

[Deamon]

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

инфа 100% ?

Вохе привет.

[Konctantin]

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

if (!Regex.IsMatch(search.ToString(), @"213.248.127.\d{3}:1119") && first && search.Port != 80)
{
	first = false;
	return new WowReactor(Conn);
}

[Йоха]

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

Вохе привет.

какому такому Вохе ?

[RomanRom2]

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

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

спасибо
спрашивайте, все расскажем покажем.

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

Да это практически тоже самое , в общем все равно, не хочется связываться с разбором пакетов :-)

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

procedure OnSessionCreate(Sender: TObject; hTcpSession : Pointer; var Need : LongBool);
procedure OnSessionDelete(Sender: TObject; hTcpSession : Pointer);
procedure OnSessionConnect(Sender: TObject; hTcpSession : Pointer);
procedure OnClientData(Sender: TObject; hTcpSession : Pointer; pData : Pointer; DataSize : Integer);
procedure OnServerData(Sender: TObject; hTcpSession : Pointer; pData : Pointer; DataSize : Integer);
procedure OnSessionClose(Sender: TObject; hTcpSession : Pointer; var Need : LongBool);

это всё что я делаю по делу

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

инфа 100% ?

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

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

насчет бана уверен что его никогда не будет. Сам по себе проксификатор - абсолютно легальное решение. И может использоваться на компьютере для совершенно не связяных с вов задач.

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

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

но с точки зрения реализации прокся - самый простой вариант. начните с нее, я тоже с нее начинал

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

[RomanRom2]

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

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

Константин , нужжный коннект определяется по dst ip addr. у меня два критерия:
1. коннект на 213.248.127.130:1119 - это однозначно коннект на BattleNet2
2. коннект на любой порт на подсеть адресов 62.67.*.* - это коннект на реалм.

первая проверка уже потеряла актуальность - раньше в этом трафике я выдирал реалм лист, из него айпишники и названия реалмов. а так же билд клиента. по этим данным строилось имя файла. сейчас с битстримом лень делать разбор реалмлиста (тем более вон шифрование добавили), названия файлов у меня сейчас выглядят так:
11723_[01ED]_62.67.45.88.3724_4C2139F3.raw
11723_[0512]_62.67.45.85.6112_4C2139F4.raw
11723_[01ED]_62.67.45.88.3724_4C213BB5.raw
11723_[0512]_62.67.45.85.1119_4C213BB6.raw

как видите, видно "вторую сессию"
кстати, про вторую сессию. любой новый коннект на 62.67.*.* я считаю новой сессией и открываю новый снифф. вот и всё. всё просто. и не важно сколько "переконнектов" еще сделает клиент (я пробовал менять несколько раз реалм), откроется новая сессия (как понятно - 512ая ) и все будет чики-пуки

ЗЫ. насчет сорри, не удержался. смачный смайлик

[LordJZ]

У нас с Konctantin получилась универсальная прокся, но даже сам WoW (в частности BN2) лезет куда-то по http, плюс скачивает себе модули. Я подумал определять по первому пакету (как раз ваши 1EDh и 512h), и в противном случае отключаться от соединения (наша реализация это позволяет).

[Konctantin]

62.67.*.*

Это актуально лишь в том случае, если вы используете русские игровые миры

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

[Йоха]

У меня получился вот такой расклад по коннектам:
Это запуск клиента, логин и вход и игровой мир, потом выход

CONNECT 213.248.127.130:1119
CONNECT 213.248.127.132:1119
CONNECT 62.67.45.98:3724
CONNECT 213.248.127.132:1119
CONNECT 213.248.127.132:1119
CONNECT 213.248.127.132:1119
CLOSE   213.248.127.132:1119
CLOSE   213.248.127.132:1119
CLOSE   213.248.127.132:1119
CLOSE   213.248.127.132:1119
CONNECT 62.67.45.157:3724
CLOSE   62.67.45.98:3724
CONNECT 213.248.127.132:1119
CLOSE   213.248.127.132:1119
CONNECT 213.248.127.132:1119
CLOSE   213.248.127.132:1119
CLOSE   62.67.45.157:3724
CLOSE   213.248.127.130:1119

если говорите что 213.248.127.132:1119 это BNET, то что такое 213.248.127.130:1119 ? то же самое ?

62.67.45.98:3724 и 62.67.45.157:3724 это явно игровые миры

[Konctantin]

213.248.127.132:1119

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

ЗЫ. Надо снифонуть этот трафик по этому коннекту, и посмотреть что за пакеты в нем ходят

[RomanRom2]

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

Это актуально лишь в том случае, если вы используете русские игровые миры

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

верно, это для русских реалмов. но у меня евро аккаунт
сейчас проверил. итак:
213.248.127.130:1119 - это БН2.
62.67.45.174:6114 - это мой реалм.
и большинство "наших" - все на русских аккаунтах играет, не так ли?

ну да ладно.
меняю реалм - 195.12.236.164, однако.
80.239.233.88
внимание! - 213.248.123.52

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

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

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

в идеальном случае надо сделать как у меня было раньше - читать из БН трафика реалм лист и коннекты фильтровать в соответствии с этим листом. и всё. вот схема "на всю жизнь". а сейчас мы просто упрощаем.

[Konctantin]

в идеальном случае надо сделать как у меня было раньше - читать из БН трафика реалм лист и коннекты фильтровать в соответствии с этим листом. и всё. вот схема "на всю жизнь". а сейчас мы просто упрощаем.

В идеале:

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

а перебор и сравнение, это немножко не то, да конешно, таким образом можно взять имя рилма, и еще чего-то, "вклеить" в дамп, но... это пока не то что надо...

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

[Йоха]

Коннект на адрес 213.248.127.132_1119

GET /b03a85262f8f83f767da530c046dd36315e503887bf4bc36656f62b5335209f3.pfty HTTP/1.1
User-Agent: Battle.net Web Client
Host: EU.depot.battle.net:1119
Accept: */*

ответ:

HTTP/1.1 404 Not Found
Server: Apache
Content-Type: text/html; charset=iso-8859-1
Content-Length: 338
Date: Sat, 03 Jul 2010 09:35:38 GMT
X-Varnish: 2119243220 2086117285
Age: 241637
Via: 1.1 varnish
Connection: keep-alive

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /b03a85262f8f83f767da530c046dd36315e503887bf4bc36656f62b5335209f3.pfty was not found on this server.</p>
<hr>
<address>Apache Server at eu.depot.battle.net Port 1119</address>
</body></html>

в общем на этот адрес идут обычные HTTP запросы на получение каких-то файлов:
*.pfty

потом запрос каких-то *.xml

Но на все запросы, ответ был один: HTTP/1.1 404 Not Found

[Konctantin]

какие-то модули, или хз... Но в процессе разработки

[LordJZ]

О чем я и говорил...

[Shadez]

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

какому такому Вохе ?

Вох.ру Тамошние эксперты любят уточнять достоверность данных подобным выражением

http://lurkmore.ru/%D0%98%D0%BD%D1%84%D0%B0_100%25 - прим. модератора

[Йоха]

коллеги подскажите где взять полный перечень опкодов ?

[LordJZ]

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

коллеги подскажите где взять полный перечень опкодов ?

http://github.com/mangos/mangos/raw/...game/Opcodes.h

[Йоха]

простите за глупые вопросы, просто раньше никогда не разбирал вов-трафик.
Я получаю в своем приложении поток данных, в котором начало "\xed\x01" или "\x12\x05".
Как дальше разбирать пакеты, подскажите описание формата пакетов вов

[Konctantin]

Первые 2 пакета идут не зашифрованные, после начинается поток уже шифрованных пакетов.
Но шифруются пакеты не полностью, а только их заголовки.
Алгоритм шифрования ARC4 http://github.com/mangos/mangos/tree...c/shared/Auth/.

описание пакета:

    Заголовок:
         2 байта - размер пакета
         Если Пакет идет от клиента к серверу тогда
             4 байта Опкод
         иначе
              2 байта опкод     

         далее идут данные

Ps. В одном ТСР пакете может стразу прийти несколько игровых пакетов, поэтому и определяется размер, дабы вычислить столько надо обработать данных

[Йоха]

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

Первые 2 пакета идут не зашифрованные, после начинается поток уже шифрованных пакетов.
Но шифруются пакеты не полностью, а только их заголовки.
Алгоритм шифрования ARC4 http://github.com/mangos/mangos/tree...c/shared/Auth/.

описание пакета:

    Заголовок:
         2 байта - размер пакета
         Если Пакет идет от клиента к серверу тогда
             4 байта Опкод
         иначе
              2 байта опкод     

         далее идут данные

благодарю.

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

Ps. В одном ТСР пакете может стразу прийти несколько игровых пакетов, поэтому и определяется размер, дабы вычислить столько надо обработать данных

это понятно.

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

[Konctantin]

вот так у нас в прокси:

            Header.AddRange(pkt, 0, SizeLength + OpcodeLength);
            AuthCrypt.Process(d, pkt, 0, SizeLength + OpcodeLength);
            
            bool large = (pkt[0] & 0x80) != 0;
            if (large)
            {
                Header.Add(pkt[SizeLength + OpcodeLength]);
                AuthCrypt.Process(d, pkt, SizeLength + OpcodeLength, 1);
                SizeLength += 1;
            }

            int i = 0;

            /// Size includes OpcodeLength, but doesn't include SizeLength.
            int Size = 0;
            for (int j = 0; j < SizeLength; ++j)
                Size = (Size << 8) | (pkt[i++] & (j == 0 ? 0x7F : 0xFF));

            int Opcode = 0;
            for (int j = 0; j < OpcodeLength; ++j)
                Opcode |= (pkt[i++] & 0xFF) << (j * 8);

[user456]

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

Да это практически тоже самое , в общем все равно, не хочется связываться с разбором пакетов :-)

А кто говорит что надо самому долбаться (разве что на Дельфи)? Во-первых если поставить Comodo Firewall то он сам собирает фрагментированные ip-пакеты и raw-сокеты получают от него клиентские пакеты с просчитанными контрольными суммами (пришлось вспоминать отчего кривые кс под вин7 были). Во-вторых если на си писать, то есть либы типа libnids в которых это все уже сделано (даже демка снифера прилагается, правда оно похоже pcap-овое, но никто не мешает юзать сборщики пакетов по-своему).

насчет бана уверен что его никогда не будет

Там же в лицензионном прописано что перехват и перенаправление траффика запрещен. К сожалению можно обнаружить и raw-сокеты и pcap, а прокси так еще проще. Вопрос только в том будет ли им влом разбирать что чем занимается и банить. Думаю чем больше людей будут иметь один и тот же запущенный процесс, тем больше к нему будет внимания.

[Йоха]

Подскажите я правильно понял суть алгоритма расшифровки ?

- создаем экземпляр класса AuthCrypt
- вызываем функцию Init(BigNumber), в качестве параметра передается выдраный из памяти вов session key
- для расшифровки заголовка пакета вызываем функцию DecryptRecv

[LordJZ]

Эти функции вам предстоит написать.

[Йоха]

в смысле ? реализация же есть в мангосе
или это не то ?

[Йоха]

просто я уже сделал прокси который сохраняет на диск так сказать raw поток обмена между клиентом и сервером. Как объяснили первые два пакета идут нормальные, а потом начинается шифрованный обмен. Вот собственно и вопрос возник. В исходниках мангоса есть реализация класса AuthCrypt. Я спрашивал как раз касательно его применения.

[YuruY]

Эти функции вам предстоит написать.

Читать умеем?

[LordJZ]

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

просто я уже сделал прокси который сохраняет на диск так сказать raw поток обмена между клиентом и сервером. Как объяснили первые два пакета идут нормальные, а потом начинается шифрованный обмен. Вот собственно и вопрос возник. В исходниках мангоса есть реализация класса AuthCrypt. Я спрашивал как раз касательно его применения.

Дак если вы берете реализацию из мангоса, почему-бы и не использовать ее так же, как в мангосе?..

[RomanRom2]

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

просто я уже сделал прокси который сохраняет на диск так сказать raw поток обмена между клиентом и сервером. Как объяснили первые два пакета идут нормальные, а потом начинается шифрованный обмен. Вот собственно и вопрос возник. В исходниках мангоса есть реализация класса AuthCrypt. Я спрашивал как раз касательно его применения.

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

[Йоха]

Большое спасибо RomanRom2 за бесценные советы

Сделал запись снифа в raw формат, но что-то с ключом не то у меня, вроде читается нечто из памяти, но утилитка конвертирующая raw файлы в pkt зависает на моих файлах -(

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

[Йоха]

Итак, снифер готов. с ключом оказалось все в порядке.
Косяк оказался с форматом raw снифа.
Вроде на сайте написано что формат такой:

заголовок серверных данных:
1 байт: 0xFF
4 байта: DateTimeToUnix(Now)
4 байта: GetTickCount, тики, полученные с машины, где работал снифер (обычно - клиентская машина)
4 байта: длина пакета
?? байт: пакет

Однако порывшись в снифах выяснилось что поле "длина пакета" должно идти сразу после сигнатуры (0xff), а не последним.

В общем все работает, спасибо всем кто помогал, и отдельное спасибо RomanRom2!


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

[RomanRom2]

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

Однако порывшись в снифах выяснилось что поле "длина пакета" должно идти сразу после сигнатуры (0xff), а не последним.

спасибо. исправил на сайте описание.

[alien]

хмммм... двойные стандарты?
На логах снифера которые лежали недавно на фтп size был последним как и в описании.
Кому верить?

[RomanRom2]

все верно. мой фолт.

итак, в raw-файлах длина лежит в начале, в pkt-файлах - в конце. вот такой косяк, уж не знаю как так вышло, простите христа ради
опять исправил на сайте, спасибо alien за наблюдательность.

[Йоха]

Что-то я запутался немного с расшифровкой заголовков пакетов
за основу взял код из tiawps

Инициализация выглядит так:

BYTE digest[SHA_DIGEST_LENGTH];
ZeroMemory(&digest, SHA_DIGEST_LENGTH);

HMAC_CTX ctx;
HMAC_CTX_init(&ctx);
HMAC_Init_ex(&ctx, seed, SEED_KEY_SIZE, EVP_sha1(), NULL);
HMAC_Update(&ctx, m_sessionkey, SESSION_KEY_LENGTH);

uint32_t length = 0;
HMAC_Final(&ctx, digest, &length);
HMAC_CTX_cleanup(&ctx);

EVP_CIPHER_CTX_init(&m_key);
EVP_EncryptInit_ex(&m_key, EVP_rc4(), NULL, NULL, NULL);
EVP_CIPHER_CTX_set_key_length(&m_key, SHA_DIGEST_LENGTH);
EVP_EncryptInit_ex(&m_key, NULL, NULL, digest, NULL);

// drop first 1024 bytes
BYTE trash;
for(int i = 0; i < 1024; ++i)
{
    DecryptData(&trash, 1);
}

Сама функция расшифровки так

void CCrypt::DecryptData(BYTE *data, int len)
{
    int outlen = 0;
    EVP_EncryptUpdate(&m_key, data, &outlen, data, len);
    EVP_EncryptFinal_ex(&m_key, data, &outlen);
}

Расшифровываются нормально только первый серверный и первый клиентский пакет. Потом ерунда какая-то получается.
В самом tiawps разобраться по человечески не получается, там такой дикий код что можно его выставлять как пример к лозунгу "как не нужно писать программы на С"

Подскажите что я упустил ?

[LordJZ]

Первые 2 пакета — не зашифрованы вообще, следовательно, у вас расшифровка не работает вообще. По этому куску кода нельзя судить о правильности...

P.S. tiawps просто написан на Function C

[Йоха]

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

Первые 2 пакета — не зашифрованы вообще, следовательно, у вас расшифровка не работает вообще. По этому куску кода нельзя судить о правильности...

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

P.S. запутался еще больше ... другой файлик нормально расшифровывается ... закономерность не могу уловить

[Йоха]

разобрался вроде, мелкие ошибки были везде и в декодировании и в основной программе...
Сейчас расшифровывается нормально второе соединение, после SMSG_AUTH_CHALLENGE.
А первый поток - нет. Видимо сиды в tiawps нерабочие. Там такие:
const uint8_t serverSeed[SEED_KEY_SIZE] = { 0xCC, 0x98, 0xAE, 0x04, 0xE8, 0x97, 0xEA, 0xCA, 0x12, 0xDD, 0xC0, 0x93, 0x42, 0x91, 0x53, 0x57 };
const uint8_t clientSeed[SEED_KEY_SIZE] = { 0xC2, 0xB3, 0x72, 0x3C, 0xC6, 0xAE, 0xD9, 0xB5, 0x34, 0x3C, 0x53, 0xEE, 0x2F, 0x43, 0x67, 0xCE };

а на данный момент другие ?