Сниффер

[Lordronn]

Я правильно понимаю принцип декриптации:

первые 4(из них 2 без опкодных) пакет не зашифрованы. Начиная с пятого идут шифрованные пакеты. Для расшифровки нам нужны сиды из пакета аутентификации и сессион кей. С помощью этого расшифровываем пакета. Все верно или я что-то упустил?

[Konctantin]

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

[Lordronn]

А, т.е первые 4 все же зашифрованы, но default сидами

[Konctantin]

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

[Lordronn]

Так пакет с сидами идет почти с сразу. Он то ли третий, то ли четвертый. или мы его пропускаем и ждем такой же следующий? А до него все расшифровываем default сидами

[LordJZ]

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

Так пакет с сидами идет почти с сразу. Он то ли третий, то ли четвертый. или мы его пропускаем и ждем такой же следующий? А до него все расшифровываем default сидами

Вот я написал примерный код для расшифровки RAW 3.1, только не тестил: https://gist.github.com/995263

[Йоха]

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

Так пакет с сидами идет почти с сразу. Он то ли третий, то ли четвертый. или мы его пропускаем и ждем такой же следующий? А до него все расшифровываем default сидами

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

[Lordronn]

1.Хм, если я решу сменить реалм не входя в игру, то у меня откроется новое соединение. Получается для пакетов с этого соединения надо будет использовать сиды из пакета? Или только для игровых пакетов, которые идут при входе на персонажа????

2.Как отследить время, когда надо закрывать соединение? Единственное что приходит в голову, там это смотреть когда придет реконект пакет и закрывать соединение, с которого оно пришло

[Йоха]

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

1.Хм, если я решу сменить реалм не входя в игру, то у меня откроется новое соединение. Получается для пакетов с этого соединения надо будет использовать сиды из пакета? Или только для игровых пакетов, которые идут при входе на персонажа????

неважно куда соединение, первое - сиды по умолчанию, все остальные из пакета

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

2.Как отследить время, когда надо закрывать соединение? Единственное что приходит в голову, там это смотреть когда придет реконект пакет и закрывать соединение, с которого оно пришло

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

[Йоха]

Наконец-то на работе смог зайти в ВоВ после патча 4.2.
Близы что-то накосячили с поддержкой uPnP, получилось зайти в мир только после того как отключил в ADSL модеме поддержку uPnP. Хотя может это DLINK криво этот протокол реализовал в модеме...

Поправил снифер до 14333 билда, собственно все как обычно: новые опкоды, новый адрес ключа, новый порядок сборки сидов

[Lordronn]

Везет, а я с 4.1.0 совокуплялся дня 3 без перерыва. Так и не собрал нормальный декриптор.

[Йоха]

пиши сюда в чем затык, буду подсказывать

[Lordronn]

Решил переписать его почти с 0. Оставлю только саму прокси часть и мемори ридер. Начал с обнаружения сессион кея. Надеюсь я все верно нашел

public long SessionKey = 0x00D7DA5C;

[Lordronn]

Пошаманил я с декриптором, но оценить работу не могу ввиду отсутствия многих данных. Я пока смог найти только 2 пакета:

SMSG_AUTH_CHALLENGE = 35856,
CMSG_AUTH_SESSION = 10656,

Со второго соединения поймал пакет. Опкод = 416, длина 36 байт. Это случайно не CMSG_AUTH_CONTINUED_SESSION ?

Дальше он ничего не уловил, что и не странно.

В 4.2.0 SMSG_AUTH_CHALLENGE порядок чтения сидов тотже? Я пытался выяснить это сам с помощью ИДЫ, но ничего толком не понял в этом обработчике

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

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

[Йоха]

Адрес ключа верный.

Сборка сидов совершенно ясно описана в функции

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

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

С опкодами еще проще, в первом соединении после дурацких безопкодных пакетов идут подряд
SMSG_AUTH_CHALLENGE
CMSG_AUTH_SESSION
А во втором
SMSG_AUTH_CHALLENGE
CMSG_AUTH_NEW_SESSION (или как у тебя называется CMSG_AUTH_CONTINUED_SESSION )

[Lordronn]

Ясно, а я пытался разобраться в PH_SMSG_AUTH_CHALLENGE)


А как быть с ASLR? Читаю и получаю одни нули. Читаю после AUTH_NEW_SESSION

Сделать как говорит Константин

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

да, это она противная и была,

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"MoveImages"=dword:00000000

Оффеты верны, ключ получил и локаль тоже

не получается, из-за отсутствия в реестре MoveImages на Win7 x64 Ultimate. Использовал глаза и поиск - нету. Дебаг привилегия присутствует

[Йоха]

Ну правильно, его там нет по умолчанию, создай этот параметр

Или используй метод чтения памяти процесса с учетом ASLR, тут на форуме где-то была тема, там я и ТОМ_РУС выкладывали решение, вот тема

[Lordronn]

А может быть такое, что пакет разбило не на 2 части, а на 21? Я тут сделал вывод информации дабы посмотреть. Увидел что 1 пакет разбили на 22 части.

[Йоха]

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

Например у меня проверяется в таком порядке:
0. Получаем данные с сокета, копируем в буфер.
1. Ожидаем недостающие данные или ждем начало нового пакета?
2. Хватает данных для обработки заголовка пакета ? (размер данных минимум 4 байта (сервер) или 6 (клиент), если нет то переходим к 0.
3. Проверка на "большой" пакет
4. Хватат ли данных для большого пакета ? (плюс 1 байт), если нет то переходим к 0.
5. В этом месте уже ясно что за опкод и размер пакета. Следовательно ждем данные равные размеру пакета
6. Пакет есть в буфере целиком - обрабатываем его, если нет то переходим к 0.
7. Повторяем с пункта 2 пока данные в буфере не закончились, иначе переходим к 0.

[Lordronn]

У меня почти также. Осталось побороть ASLR. Не очень понял зачем нужен BaseAddress в C#. Для чтения я прибегнул к функции ReadProcessMemory из библиотеки kernel32.

В ХР я читал так

        public byte[] ReadSessionKey()
        {
            using (ProcessMemoryReader reader = new ProcessMemoryReader("wow"))
            {
                return reader.Read(reader.ReadInt(_wow.SessionKey) + _wow.Offset, 40L);
            }
        }

        public long SessionKey = 0x00D7DA5C;
        public long Offset = 0x508;

[Йоха]

По умолчанию в виндах до версии 7 процесс загружается в память по виртуальному адресу 0x00400000, и этот адрес не меняется для всех программ (если не предпринимать специальных действий для этого).
В семерке поменяли механизм загрузки процессов в память и теперь (при включеном ASLR, а он по умолчанию включен) базовый адрес выбирает неким случайным образом винда.
И адрес 0x00D7DA5C который мы берем из IDA (которая тоже предполагает что процесс грузится по адресу 0x00400000) будет неверным если винда выберет любой другой базовый адрес.
Что бы исправить это недоразумение вычисляем смещение адреса ключа относительно базового адреса 0x00400000 (0x00D7DA5C - 0x00400000 = 0x0097DA5C).
В снифере получаем BaseAdress процесса wow.exe, прибавляем к нему полученный 0x0097DA5C и получаем валидный адрес по которому находится ключ в памяти с учетом ASLR.

[Lordronn]

Собственно с ключем вроде разобрался благодаря Косте! Хотяя вроде все ровно не тот ключ, ибо после разбора пакетов получаю большой размер.Йоха, можешь кинуть лог я посмотрю правильно ли декриптую или нет по номерам опкодов

[Sid]

Йоха, на шарпе пишешь сниффер? Хотелось бы начать подробней изучать принципы и механизм работы подобных программ

[Йоха]

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

Йоха, можешь кинуть лог я посмотрю правильно ли декриптую или нет по номерам опкодов

лог чего ? Работы снифера ?
ну вот, включил вывод отладочной информации в консоль (это логин до состояние окна выбора персонажа):

ready
connect 195.12.234.53:80
close   195.12.234.53:80
connect 213.248.127.130:1119
connect 195.12.246.220:3724
* StartSession
S opcode=0x0000 len=    48  , ip = 195.12.246.220:3724 (009C)
C opcode=0x0000 len=    48  , ip = 195.12.246.220:3724 (009C)
S opcode=0x8C10 len=    39  , ip = 195.12.246.220:3724 (009C)
C opcode=0x29A0 len=   360  , ip = 195.12.246.220:3724 (009C)
got key
S opcode=0xBEFB len=    14  , ip = 195.12.246.220:3724 (009C)
S opcode=0x0B27 len=   882  , ip = 195.12.246.220:3724 (009C)
S opcode=0x6AAE len=   262  , ip = 195.12.246.220:3724 (009C)
S opcode=0xA237 len=     6  , ip = 195.12.246.220:3724 (009C)
S opcode=0x7E72 len=    34  , ip = 195.12.246.220:3724 (009C)
S opcode=0x0410 len=   271  , ip = 195.12.246.220:3724 (009C)
connect 195.12.246.219:3724
S opcode=0x0000 len=    48  , ip = 195.12.246.219:3724 (0104)
C opcode=0x0000 len=    48  , ip = 195.12.246.219:3724 (0104)
S opcode=0x8C10 len=    39  , ip = 195.12.246.219:3724 (0104)
C opcode=0x01A0 len=    40  , ip = 195.12.246.219:3724 (0104)
C opcode=0xF226 len=     4  , ip = 195.12.246.220:3724 (009C)
C opcode=0x1091 len=     4  , ip = 195.12.246.220:3724 (009C)
C opcode=0xB6E2 len=     8  , ip = 195.12.246.220:3724 (009C)
S opcode=0x8490 len=     6  , ip = 195.12.246.220:3724 (009C)
C opcode=0x09A0 len=     8  , ip = 195.12.246.220:3724 (009C)
S opcode=0x0C10 len=     2  , ip = 195.12.246.219:3724 (0104)
C opcode=0x0920 len=     8  , ip = 195.12.246.220:3724 (009C)
close   195.12.246.220:3724
S opcode=0x3C02 len=   331  , ip = 195.12.246.219:3724 (0104)
C opcode=0x7E3B len=     8  , ip = 195.12.246.219:3724 (0104)
C opcode=0x7E3B len=     8  , ip = 195.12.246.219:3724 (0104)
C opcode=0x7E3B len=     8  , ip = 195.12.246.219:3724 (0104)
S opcode=0xAA66 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0xAA66 len=   146  , ip = 195.12.246.219:3724 (0104)
S opcode=0xAA66 len=   611  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=    39  , ip = 195.12.246.219:3724 (0104)
C opcode=0xE2FB len=     5  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)
S opcode=0x7A36 len=   505  , ip = 195.12.246.219:3724 (0104)

Добавлено через 2 минуты

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

Йоха, на шарпе пишешь сниффер? Хотелось бы начать подробней изучать принципы и механизм работы подобных программ

Я c# не знаю вообще, пишу на с++.
Ну а механизмы они от языка не зависят -) Почитай эту тему с начала, тут очень много полезной информации, я сам начал писать снифер с нуля читая эту тема и задавая вопросы про непонятные места. Если что неясно, спрашивай, всегда готов ответить на вопросы.

[Lordronn]

Те, которые не зашифрованны идут нормально, что и не странно, а вот дальше идет бред. Размер самого пакета 16 байт, а после декриптовки получаю 17кб, при том что это пакет целый, а не частичный.

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

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

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

[RomanRom2]

значит ключ неправильный.

[Lordronn]

Я пропатчил реестр дабы вырубить ASLR, Йоха подтвердил что адрес верный. Чтение ключа идет верно

[Йоха]

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

Я пропатчил реестр дабы вырубить ASLR, Йоха подтвердил что адрес верный. Чтение ключа идет верно

Сиды правильно собираются ?

Покажи свой кусок кода где идет расшифровка заголовка пакета.

[Lordronn]

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

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

[LordJZ]

Костя видимо вам скинул мой старый код от 4.0.6. Он не предназначен для работы с 4.1.0+.

[Lordronn]

Простите, а вы рабочем не поделитесь?

[LordJZ]

Напишите самостоятельно.

[Йоха]

Посетила мысль сделать очередной вариант снифера -) На этот раз он самодостаточен.
Тип - перехват функций WIN32 API. Перехватываются соответственно winsock функции: bind, connect, recv, send. Возможно что-то еще надо будет перехватывать ... там разберемся.
Преимущества такого подхода в том что не нужно городить огород из проксификаторов или подобных программ, ну и конечно то что можно влиять на происходящее - подменять данные, адреса и т.д. на лету. К тому же разбор данных не усложняется, а остается такой же как в прокси варианте снифера. Мы так же получаем готовые данные с сокета. И еще немаловажный момент - с точки зрения API все делается легально, никаких "грязных хаков" -). Память процесса wow.exe не меняется, warden спокойно курит.

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

[RomanRom2]

четвертое поколение?

[Йоха]

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

четвертое поколение?

Мне кажется у тебя другой принцип используется

В моем варианте просто перехват функций API, с сетевой моделью никак не связано, перехват осуществляется так же как и для любой другой функции.
Кстати посмотрел wow.exe импортирует функции из wininet.dll, видимо загружает файлы с веб сервера при помощи InternetreadFileExA, надо проверить что он там загружает и если что, то можно сделать сохранялку этих файлов себе куда-нибудь.

[RomanRom2]

винапишный хук по моему близзами палится.
все таки на данный момент безопасным способом является либо прокси/проксификатор, либо pcap/pssdk. самым скрытым и неспалеваемым способом по прежнему остается "четвертое поколение" (LSP), т.к. работает на уровне ос, куда приложению не добраться.

[Йоха]

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

Ну и как показывает практика, вов нормально работает.

Насчет бесплалевности LSP весьма сомнительно...
Ничто не мешает близам запустить во время работы вов драйвер и спалить все потроха ОС и все что хочешь...

[RomanRom2]

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

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

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

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

очень и очень много параноиков, трясущихся за свою ******у на винте и пароли от одноклассников.

Последнее улыбнуло

[Йоха]

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

Все остальное верно, но не существенно. Так сказать на летные характеристики не влияет.

Я уже реализовал подход с перехватом как ты говоришь "баянистым" -) путем джампа на месте стандартного пролога. и все чудесно, антивирь молчит, вов играет, я получаю данные.
Кстати есть такая штука: detours - автор сама MS, сейчас это монстрило стоит 10к зелени, но первый ее простой вариант в виде одного .h и 1 .cpp файла прекрасно справляется с поставленой задачей