Разбор пакетов WoW
Разбор структуры пакетов из wow.exe это просто! :)
Нужно: 1. Интуиция. 2. Знание "СИ". 3. IDA+HexRays. 4. Терпение. :) Качаем IDA+HexRays. нацеливаем IDA на wow.exe декомпилируем, потом сохраняем всё в .c файл с помощью HexRyas:) ищем в файле строчку типа Код:
(461, (int) Код:
sub_5F9870(459, (int)sub_401220, 0); Код:
sub_5F9870() это что то типа OpcodeHandler() Код:
sub_5F9870->OpcodeHandler Код:
OpcodeHandler(459, (int)sub_401220, 0); ищём по коду эту функцию sub_401220(). ...... находим что то типа Код:
//----- (00401220) -------------------------------------------------------- переименовываем её в ReadString() находим в начале файла. int __thiscall ReadString(int this, int a2, unsigned int a3); и переименовываем все рядом стоящими функции типа так... Код:
int __thiscall ReadByte(int this, int a2); теперь мы знаем какие функции какой тип данных считывают из пакета :) ИТАК. теперь мы хотим разобрать структуру какого либо SMSG пакета. Обратите внимание, что CMSG пакеты разбираются по другому и пока что я это описывать не буду.:) И ещё, некоторые пакеты SMSG которые есть в Opcodes.h(Мангос) их нету в wow.exe это связанно с тем что эти пакеты только для GM клиента и в обычном клиенте их просто нет:) Так вот... к примеру мы хотим узнать что за структура у пакета SMSG_LOOT_LIST = 0x3F9, переводим 0x3F9 в десятичное число и ищём по нашему коду. OpcodeHandler(1017, (int) нашли к примеру OpcodeHandler(1017, (int)sub_65E100, 0); переходим к sub_65E100 Код:
//----- (0065E100) -------------------------------------------------------- всё, структуру опкода мы знаем:) все адреса приведённые здесь sub_65E100, sub_401220 и т.д. меняются с каждой версией клиента, так что нужно полагаться на интуицию ;) и ещё... клиент бывает считывает Пакованный гуид из пакета... функция считывания выглядит примерно так Код:
//----- (006A5870) -------------------------------------------------------- ReadInt8(v6, (int)((char *)&a2 + 3)); но!!!!!! строка не уникальна и в других версиях клиента может меняться... Автор: Дерека. |
Хорошая статья. Скажите, а где можно более детально узнать о разборе пакетов?
Я так понимаю что опкоды (например такой 0x3F9) берется из снифов! Я правильно понял? В статье говорится о разборе SMSG пакетов, а как разбирать СMSG? ПыСы Может подобные вопросы и покажутся нубскими, но я думаю не только у меня есть большое желание научиться этому.... |
Я делал мини гайдик на английском по поиску опкодов и структур для 4.0. Но в принципе и для 3.3.5 некоторая инфа тоже может быть полезна.
|
Я прочитал его, но возник вопросик: мы ищем в дампе иды результат сложения оффсета и 8080? или ищем само выражение т.е 1111 + 8080(к примеру)?
|
Цитата:
|
Я осуществляю поиск в IDB с помощью скрипта на питоне (findinstructions.py). Можно найти в блоге разработчиков IDA.
|
Цитата:
sub_5F9870(459, (int)sub_401220, 0); подобных строк нет, точнее в "субах" нет вложенных субов. Собственно говоря вопрос, что делать? (база idb взята с форума) |
Цитата:
|
Цитата:
1. Качаем xml с адресами почти всех обработчиков от LordJZ либо Камиллу. 2. Находим нужный опкод, смотрим нужные адреса. 3. ??? 4. PROFIT! |
Ну понимаеш, LordJZ допустим не всегда будет снабжать нас всем необходимым, поэтому хотелось бы быть более независимым и сделать что то самому
|
А толку то? В бете панд уже опять все изменилось кардинальным образом.
|
вот собственно мы и незаметно перешли к той теме о которой я и хотел спросить)) Так кто-нибудь уже декомпилил панд? Как оно?
|
Вроде бы разобрался на основе 14333 с Jam и Auth опкодами, с ними все прозрачно.
Использовал Opcode Calculator от Chameleon. Но не понятно, что делать с regular opcodes, согласно его гайду Цитата:
Текстовый поиск по + 4844 или + 0x12EC ничего не дает, кроме Код:
void __usercall ClientDestroyGame(int a1<ebx>, double a2<st6>, double a3<st5>, double a4<st4>, double a5<st3>, double a6<st2>, double a7<st1>, double a8<st0>, int a9, int a10, int a11) |
Цитата:
Но необходимости в ручном поиске сейчас по большому счету нет т.к. под основные версии доступны полные дампы маппинга опкодов к хэндлерам. Цитата:
|
Спасибо за быстрый ответ.
Для 14333 есть функция, Код:
protected override bool NormalCheck(uint opcode) Код:
//----- (00485940) -------------------------------------------------------- Правильно ли, что в *((_DWORD *)v5 + v8 + 2392) будет как раз адрес обработчика? |
Разве обработчик не
Код:
v9 - ((v6 | (v6 << 16)) ^ 0x62A3A31D) ? Код:
char __thiscall NetClient::ProcessMessage(ClientConnection *this, int a2, int opcode, int a4) |
Да, так и есть... Значит, чтобы получить адрес хендлер нужен адрес jamOffs или адрес _this.
Написал функцию получения jamOffst и _this по известным хендлерам, для разных пакетов _this получается разный... При этом jamOffst совпадает с данными от LordJZ Код:
//unsigned int op = 30375; //smsg notification |
Цитата:
Мне интересно, Amaru, что вы хотите разработать на основе этой информации? Проблема маппинга опкодов к хэндлерам уже решена полностью. Проблема маппинга опкодов между версиями решена удовлетворительно, хотя всегда есть место для улучшения. Основная проблема для поддержки новых и будущих версию, как я вижу - это создание автоматизированного парсера структуры Jam bitstream пакетов. Чтобы в ядре порядок данных в структуре пакетов мог оставаться стабильным между версиями, а порядок сериализации этих данных для конкретной версии основывался бы на информации сгенерированной этим чудесным парсером. Имея такую штуку можно было бы думать о переходе между новыми версиями за разумное время, без траты уймы времени на ручную перестановку порядка филдов в куче JAM пакетов. |
Я пытаюсь получить handle для конкретного опкода
Как выяснилось, надо дополнительно знать либо _this, либо jamOffs Решая обратную задачу, располагая найденным адресом какого либо хендлера, можно получить и _this и jamOffs, а далее использовать их для получения хендлеров всех остальных окодов. Но то ли я что-то не понимаю, либо что-то не так считаю, но адреса остальных хендлеров не получаются При этом посчитанный в начале jamOffs совпал с адресом, указанным LordJZ в его xml, что означает, что хендлер, из которого он считался, был найден правильно |
Запарившись разбираться, написал патч, который считает все auth и special оффсеты, а также перехватывает адрес хендлера обычных пакетов, когда идет к нему обращение
https://github.com/Zakamurite/OpcodeHandleDumper Офсет выдается относительно IDA, для известных опкодов адреса корректны, но можно найти и левые адреса, но среди них использующихся/известных опкодов не находил, скорее всего это несуществующие опкоды |
"обработки пакета под номером 459(SMSG_NOTIFICATION)" - подскажите откуда берется символьное значение опкода SMSG_NOTIFICATION=459, из клиента?
|
из сниффа
|
Это не ответ, тот кто писал сниф - выдумал названия, или гдето в клиенте есть точные названия?
|
насколько я знаю было, но давно, очень давно
|
Цитата:
|
Я начал собирать снифом с оффа информацию с билда 18019. Парсер пакетов как оказалось устарел и неисправен - опкоды изменились. Где можно взять последнюю возможную информацию как теперь в вов 5.4 искать среди дезасемблированого кода нужную информацию по обработке пакетов а также соответствие опкода - номеру. Выложеный вариант файла для IDA 6.1 у меня не открывается.
|
Я так понял, что вов 5.4 - табу? никто так и не ответил.
|
Цитата:
Номера опкодов пока что одинаковые для всех билдов 5.4.7 Если ида не открывает - качай другую ида |
Я разобрался с SMSG_..., остался вопрос как в клиенте 18291 искать подготовку пакетов CMSG_... ?
|
Поделитесь .pkt или .bin с оффа для 4.3.4?
|
Текущее время: 08:06. Часовой пояс GMT +3. |
ru-mangos.ru - Русское сообщество MaNGOS