Ru-MaNGOS
Страница 1 из 8 1 2345 Последняя »
Показывать 40 сообщений этой темы на одной странице

Ru-MaNGOS (http://mangos.ytdb.ru/index.php)
-   Опкоды, Формулы, Клиент (http://mangos.ytdb.ru/forumdisplay.php?f=9)
-   -   Сниффер (http://mangos.ytdb.ru/showthread.php?t=419)

xmolex 23.03.2010 08:53
Сниффер
 
Кто знает сниффер под 3.3.2. Поискал по интернету, что-то не густо.

Deamon 23.03.2010 10:43
А их никогда и не будет густо. Так уж сложилось традициями, что все сниферы под ВоВ всегда держатся в привате.

А после того, как близы перешли на RC4, снифить траффик можно только собрав session_key откуда либо. Прокси сейчас не работают из-за BN2 протокола, остались только инъекторы.

Dereka 23.03.2010 10:47
http://github.com/arrai/tiawps смотри

Deamon 23.03.2010 11:00
Цитата:
Сообщение от Dereka (Сообщение 2949)
Хм... Интересный вариант, в принципе можно и так.

abdula123 29.03.2010 16:56
прокси как работали, так и работают. просто приходится зарыться немного поглубже. :)

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

Konctantin 29.03.2010 17:11
Цитата:
прокси как работали, так и работают. просто приходится зарыться немного поглубже.
А как же аутентификация?

Neverdie 29.03.2010 18:09
Цитата:
Сообщение от abdula123 (Сообщение 3389)
прокси как работали, так и работают. просто приходится зарыться немного поглубже. :)

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

abdula123 31.03.2010 01:34
Цитата:
Сообщение от Neverdie (Сообщение 3391)
поделитесь тайной прохода аутентификации
а нету никакой тайны. клиент аутентифициуется на близовском сервере обычным порядком.

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




кстати, насчет инжектов - Warden бдит. я насчитал 4 проверки, связанные с соединением и отправкой данных.

если кто не знает их точных адресов - можно и напороться. :(

Neverdie 31.03.2010 10:24
Цитата:
Сообщение от abdula123 (Сообщение 3472)
а нету никакой тайны. клиент аутентифициуется на близовском сервере обычным порядком.

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




кстати, насчет инжектов - Warden бдит. я насчитал 4 проверки, связанные с соединением и отправкой данных.

если кто не знает их точных адресов - можно и напороться. :(
ну предсполсдений раз юзали инжект то не кто нас не трогал
место было удобное покамись не сметили
да и биаша больше не захотел (то есть времени нету у него):sorry:

покамись юзаем tiawps

Neverdie 20.04.2010 21:56
столкнулись с проблемой при использования метода tiawps
при попытки перевести дамп в читаемый вид
получаем файл с одним и темже размером

и рветца наче тут

CLIENT:
LENGTH: 10
OPCODE: 0510
DATA:
00 08 10 05 00 00 0A 00 00 00


SERVER:
LENGTH: 8
OPCODE: 050F
DATA:
00 06 0F 05 0A 00 00 00

неможем покамись определить

[13:00] <Kosuha> но мне кажеться чтото с
[13:00] <Kosuha> case 1293:
[13:00] <Kosuha> forwarding connection
[13:01] <Kosuha> какойто
[13:01] <Kosuha> попался

вопрос собетсвенно такой
кто нить юзает тивапс и работает ли нормально у вас ?
а то 1 в 1 струткура вот сидим думаем ктог лючит мы или тивапс

Konctantin 20.04.2010 22:02
Я раз пробовал, еще когда была версия 332 - получилось.
Но он мне показался сильно геморным и я забил :(

Кстати, а никто не пробовал заюзать мелкософтовский net monitor, у них там даже API имеется?

Neverdie 20.04.2010 22:07
да на 33,2 и у нас то работало
а вот с 3,3,3 фигня какая то
просто мало рук чтоб вникать

Konctantin 20.04.2010 22:18
ну с портами там и хостами беда прыгают как зайчики, это раз
и 2 даже если поймаешь порт и хост, то иногда какого-то черта получает пакет 3 по счету после коннекта, который не декриптуется

LENGTH: 65536
OPCODE: 0000
DATA: 00 00 00 00

не стал пока разбираться, чего-то нету желания

Neverdie 20.04.2010 22:21
да был такой
пакет
и еще могло почему-то выйти 2 дампа сразу
1 стандартно а 2 громадный

Konctantin 20.04.2010 22:25
Цитата:
1 стандартно а 2 громадный
из-за смены портов

abdula123 21.04.2010 17:47
Цитата:
Сообщение от Neverdie (Сообщение 4786)
да на 33,2 и у нас то работало
а вот с 3,3,3 фигня какая то
просто мало рук чтоб вникать
это не "фигня какая то", это близзы сделали лоад-балансер и теперь у каждого реалма по нескольку пар адрес:порт, между которых они клиентов распеределяют.

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

в 3.3.3(без а) был такой баг - первое соединение не закрывалось, хотя объекты, с ним связанные удалялись. в (а) уже исправили, вроде-бы.


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


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

RomanRom2 21.04.2010 21:42
Цитата:
Сообщение от abdula123 (Сообщение 4852)
если взять и исключить из потока этот пакет (моя прокся такие издевательства позволяет) - то клиент так и будет работать в одно соединение (второе-то не согласовано). минуты 3 где-то, потом сервер кикнет.
прокся умеет вклиниваться в трафик с циклическим ключем? или прокся самостоятельно устанавливает соединение и с сервером со своим ключем и с клиентом со своим ключем? :acute:

Konctantin 21.04.2010 21:48
Как вычислить этот пакет? я не могу его поймать. Сидел со сниффером пол часа так и не понял как его определить.

abdula123 22.04.2010 15:17
Цитата:
Сообщение от RomanRom2 (Сообщение 4868)
прокся умеет вклиниваться в трафик с циклическим ключем? или прокся самостоятельно устанавливает соединение и с сервером со своим ключем и с клиентом со своим ключем? :acute:
размеры/заголовки пакетов XORятся потоком байт, генерируемых RC4. а этот поток назвать цикличным язык как-то не поворачивается :)

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


так что приходится поддерживать 4 rc4-состояния - на каждое направление с каждой стороны. инициализировать их из данных клиента и все до единого пакеты пропускать через них.

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



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


Цитата:
Сообщение от Konctantin (Сообщение 4870)
Как вычислить этот пакет? я не могу его поймать. Сидел со сниффером пол часа так и не понял как его определить.
приходит практически в самом начале, в первой десятке пакетов.
с шифрованым заголовком. естественно, до установки второго соединения.

опкод - 1293.

Код:
[S2C] SMSG_SECOND_CONNECTION (1293 = 0x050D) len: 30
ip                  : 62.67.45.65
port                : 6112
unk1                : 6
digest              : 11ae18435c2a504058d60ed647df65bc09d23248

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

[S2C] SMSG_SWITCH_TO_SECOND (1295 = 0x050F) len: 4
seq                : 10

[C2S] CMSG_SESSION_SWITCHED (1296 = 0x0510) len: 4
seq                : 10

[S2C] SMSG_SWITCH_ENCRYPTION (1297 = 0x0511) len: 0
последний приходит уже во второе соединение.

RomanRom2 22.04.2010 16:07
Цитата:
Сообщение от abdula123 (Сообщение 4911)
размеры/заголовки пакетов XORятся потоком байт, генерируемых RC4. а этот поток назвать цикличным язык как-то не поворачивается :)

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

Цитата:
Сообщение от abdula123 (Сообщение 4911)
так что приходится поддерживать 4 rc4-состояния - на каждое направление с каждой стороны. инициализировать их из данных клиента и все до единого пакеты пропускать через них.
только так и можно это организовать. плавали, знаем. именно по этому принципу работал наш сканер респонсов :secret:

Цитата:
Сообщение от abdula123 (Сообщение 4911)
да, кстати, у вардена свое шифрование со своими ключами, независимое от сессионного.
:yes3:

abdula123 23.04.2010 07:50
Цитата:
Сообщение от RomanRom2 (Сообщение 4918)
только так и можно это организовать. плавали, знаем. именно по этому принципу работал наш сканер респонсов :secret:
:yes3:
есть еще как минимум один способ - ставить брейкпоинты (лучше аппаратные, варден на них не реагирует, а на int3 в некоторых местах может и стойку сделать) в функциях отправки и приема пакетов - до и после шифрования соответственно и по каждому срабатыванию копировать пакеты себе.

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

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

Neverdie 23.04.2010 08:54
ну поняно
против лома нету приему если нет другого лома
менячто поражает больше
чем мудрее близы защиту делают тем сильнее их ломают

abdula123 23.04.2010 09:35
Цитата:
Сообщение от Neverdie (Сообщение 4946)
ну поняно
против лома нету приему если нет другого лома
менячто поражает больше
чем мудрее близы защиту делают тем сильнее их ломают
близы в плане защиты очень ленивые. ОЧЕНЬ, ОЧЕНЬ ленивые.

к тому-же им пофиг на всё, кроме массового макро\ботоводства.

Neverdie 23.04.2010 10:04
Цитата:
Сообщение от abdula123 (Сообщение 4951)
близы в плане защиты очень ленивые. ОЧЕНЬ, ОЧЕНЬ ленивые.

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

Konctantin 23.04.2010 19:05
а если б не сменили систему аутентификации, не так бы интересно было :)

Konctantin 31.05.2010 21:26
Мы тут с LordJZ начали делать сниффер, но наткнулись на неприятность:
При логине и пока стоим на окне выбора персонажей пакеты декриптуются нормально
Вот лог сниффера:
Код:
World server address: 62.67.45.123:3724
Connected to 62.67.45.123:3724
SERVER: Header = 44    Packet = 44    OK      Opcode: SMSG_AUTH_CHALLENGE
Session Key: 6250DC798DDEA48A01102CE9B7EA33060D425E42DC2145E0477FBEC637F1287C00EAC7B10B54B3BB
CLIENT: Header = 278    Packet = 278    OK      Opcode: CMSG_AUTH_SESSION
SERVER: Header = 15    Packet = 15    OK      Opcode: SMSG_AUTH_RESPONSE
SERVER: Header = 192    Packet = 270    REUSE  Opcode: SMSG_ADDON_INFO
SERVER: Header = 8      Packet = 78    REUSE  Opcode: SMSG_CLIENTCACHE_VERSION
SERVER: Header = 36    Packet = 70    REUSE  Opcode: SMSG_TUTORIAL_FLAGS
Redirect to 62.67.45.165:1119
SERVER: Header = 34    Packet = 34    OK      Opcode: SMSG_REDIRECT_CLIENT
Connected to 62.67.45.165:1119
SERVER: Header = 44    Packet = 44    OK      Opcode: SMSG_AUTH_CHALLENGE
Session Key: 6250DC798DDEA48A01102CE9B7EA33060D425E42DC2145E0477FBEC637F1287C00EAC7B10B54B3BB
CLIENT: Header = 46    Packet = 46    OK      Opcode: CMSG_REDIRECTION_AUTH_PROOF
SERVER: Header = 4      Packet = 4      OK      Opcode: SMSG_FORCE_SEND_QUEUED_PACKETS
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_READY_FOR_ACCOUNT_DATA_TIMES
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_CHAR_ENUM
CLIENT: Header = 10    Packet = 10    OK      Opcode: CMSG_REALM_SPLIT
SERVER: Header = 25    Packet = 25    OK      Opcode: SMSG_ACCOUNT_DATA_TIMES
SERVER: Header = 291    Packet = 312    REUSE  Opcode: SMSG_CHAR_ENUM
SERVER: Header = 21    Packet = 21    OK      Opcode: SMSG_REALM_SPLIT
SERVER: Header = 41    Packet = 41    OK      Opcode: SMSG_WARDEN_DATA
Но при заходе персонажем в мир начинается каша, серверные пакеты неправильно декриптуются или разбираются:
Код:
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_PLAYER_LOGIN
SERVER: Header = 25    Packet = 25    OK      Opcode: SMSG_ACCOUNT_DATA_TIMES
SERVER: Header = 36    Packet = 1460  REUSE  Opcode: SMSG_TUTORIAL_FLAGS
SERVER: Header = 16    Packet = 1424  REUSE  Opcode: MSG_SET_DUNGEON_DIFFICULTY
SERVER: Header = 24    Packet = 1408  REUSE  Opcode: SMSG_LOGIN_VERIFY_WORLD
SERVER: Header = 29    Packet = 1384  REUSE  Opcode: SMSG_ACCOUNT_DATA_TIMES
SERVER: Header = 6      Packet = 1355  REUSE  Opcode: SMSG_FEATURE_SYSTEM_STATUS
SERVER: Header = 293    Packet = 1349  REUSE  Opcode: SMSG_MOTD
SERVER: Header = 12    Packet = 1056  REUSE  Opcode: SMSG_LEARNED_DANCE_MOVES
SERVER: Header = 12    Packet = 1044  REUSE  Opcode: SMSG_CONTACT_LIST
SERVER: Header = 24    Packet = 1032  REUSE  Opcode: SMSG_BINDPOINTUPDATE
SERVER: Header = 9      Packet = 1008  REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 999    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 990    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 981    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 972    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 963    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 954    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 945    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 936    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 927    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 25    Packet = 918    REUSE  Opcode: SMSG_TALENTS_INFO
SERVER: Header = 12    Packet = 893    REUSE  Opcode: SMSG_INSTANCE_DIFFICULTY
SERVER: Header = 9      Packet = 881    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 9      Packet = 872    REUSE  Opcode: SMSG_SET_PROFICIENCY
SERVER: Header = 285    Packet = 863    REUSE  Opcode: SMSG_INITIAL_SPELLS
SERVER: Header = 8      Packet = 578    REUSE  Opcode: SMSG_SEND_UNLEARN_SPELLS
ERROR: SERVER Size = 581        >        packet.Length = 570
ERROR: SERVER Size = 27961      >        packet.Length = 1460
ERROR: SERVER Size = 46186      >        packet.Length = 1460
ERROR: SERVER Size = 27772      >        packet.Length = 1355
CLIENT: Header = 7      Packet = 7      OK      Opcode: CMSG_PLAYED_TIME
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_NAME_QUERY
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_SET_ACTIVE_MOVER
CLIENT: Header = 7      Packet = 7      OK      Opcode: CMSG_SET_ACTIONBAR_TOGGLES
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_REQUEST_RAID_INFO
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_GMTICKET_GETTICKET
ERROR: SERVER Size = 34578      >        packet.Length = 118
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_QUERY_TIME
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_QUEST_POI_QUERY
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_MEETINGSTONE_INFO
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_LFD_PLAYER_LOCK_INFO_REQUEST
CLIENT: Header = 6      Packet = 6      OK      Opcode: MSG_GUILD_BANK_MONEY_WITHDRAWN
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_CALENDAR_GET_NUM_PENDING
CLIENT: Header = 8      Packet = 8      OK      Opcode:
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_QUESTGIVER_STATUS_QUERY
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_NAME_QUERY
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_TIME_SYNC_RESP
CLIENT: Header = 42    Packet = 42    OK      Opcode: MSG_MOVE_FALL_LAND
CLIENT: Header = 10    Packet = 10    OK      Opcode: CMSG_ZONEUPDATE
CLIENT: Header = 43    Packet = 43    OK      Opcode: CMSG_JOIN_CHANNEL
CLIENT: Header = 49    Packet = 49    OK      Opcode: CMSG_JOIN_CHANNEL
CLIENT: Header = 47    Packet = 47    OK      Opcode: CMSG_JOIN_CHANNEL
CLIENT: Header = 43    Packet = 43    OK      Opcode: CMSG_JOIN_CHANNEL
CLIENT: Header = 47    Packet = 47    OK      Opcode: CMSG_JOIN_CHANNEL
CLIENT: Header = 6      Packet = 6      OK      Opcode: CMSG_WORLD_STATE_UI_TIMER_UPDATE
ERROR: SERVER Size = 44279      >        packet.Length = 29
ERROR: SERVER Size = 7350      >        packet.Length = 1460
ERROR: SERVER Size = 61367      >        packet.Length = 649
ERROR: SERVER Size = 31772      >        packet.Length = 62
ERROR: SERVER Size = 21770      >        packet.Length = 388
ERROR: SERVER Size = 12076      >        packet.Length = 54
ERROR: SERVER Size = 10025      >        packet.Length = 108
ERROR: SERVER Size = 50091      >        packet.Length = 62
ERROR: SERVER Size = 41905      >        packet.Length = 61
ERROR: SERVER Size = 20541      >        packet.Length = 66
ERROR: SERVER Size = 26947      >        packet.Length = 54
ERROR: SERVER Size = 15250      >        packet.Length = 66
ERROR: SERVER Size = 13283      >        packet.Length = 147
ERROR: SERVER Size = 5655      >        packet.Length = 170
ERROR: SERVER Size = 16965      >        packet.Length = 54
ERROR: SERVER Size = 25301      >        packet.Length = 62
ERROR: SERVER Size = 39797      >        packet.Length = 62
ERROR: SERVER Size = 12419      >        packet.Length = 54
CLIENT: Header = 32    Packet = 32    OK      Opcode: CMSG_WARDEN_DATA
ERROR: SERVER Size = 18762      >        packet.Length = 439
ERROR: SERVER Size = 9091      >        packet.Length = 159
ERROR: SERVER Size = 32369      >        packet.Length = 120
CLIENT: Header = 42    Packet = 42    OK      Opcode: MSG_MOVE_SET_FACING
CLIENT: Header = 42    Packet = 42    OK      Opcode: MSG_MOVE_START_FORWARD
ERROR: SERVER Size = 37437      >        packet.Length = 5
CLIENT: Header = 42    Packet = 42    OK      Opcode: MSG_MOVE_STOP
ERROR: SERVER Size = 11046      >        packet.Length = 54
ERROR: SERVER Size = 59547      >        packet.Length = 54
ERROR: SERVER Size = 32659      >        packet.Length = 120
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_SET_SELECTION
CLIENT: Header = 14    Packet = 14    OK      Opcode: CMSG_QUESTGIVER_HELLO
ERROR: SERVER Size = 23216      >        packet.Length = 54
ERROR: SERVER Size = 12149      >        packet.Length = 295
ERROR: SERVER Size = 25893      >        packet.Length = 42
Сама функция которая обрабатывает пакеты:
Код:
private static void ProcessWorldPacket(byte[] data, Direction direction)
{
        int i = 0, size = 0, opcode = 0;
        int HEADER_LENGTH = 4;

        bool isLarge = data.Length > 0x7FFF;
        HEADER_LENGTH += (isLarge ? 1 : 0);

        if (direction == Direction.SERVER)
        {
                Crypt.DecryptServer(data, HEADER_LENGTH);
        }
        else
        {
                HEADER_LENGTH += 2;
                Crypt.DecryptClient(data, HEADER_LENGTH);
        }

        if (isLarge)
                size = data[i++] & 0x7F;

        size = (size << 8) | data[i++];
        size = (size << 8) | data[i++];

        for (int j = 0; j < HEADER_LENGTH - 2; j++)
                opcode |= ((0xFF & data[i++]) << (8 * j));

        size += 2;

        if (size > data.Length)
        {
                Console.WriteLine("ERROR: {0} Size = {1} \t>\t packet.Length = {2}", direction, size, data.Length);
                return;
        }

        using (BinaryReader reader = new BinaryReader(new MemoryStream(data)))
        {
                reader.BaseStream.Position += HEADER_LENGTH;
                byte[] newData = reader.ReadBytes(size - HEADER_LENGTH);
               
                HandleWorldPacket((WorldOpcodes)opcode, newData);

                Console.WriteLine("{0}:\tHeader = {1}\tPacket = {2}\t{3}\tOpcode: {4}",        direction, size, data.Length, data.Length == size ? "OK" : "REUSE", (WorldOpcodes)opcode);

                if (size < data.Length)
                {
                        ProcessWorldPacket(reader.ReadBytes(data.Length - size), direction);
                } 
        }
}
Подскажите, в чем загвоздка, или есть какой-то нюанс?

RomanRom2 31.05.2010 22:38
похвально. pcap?
потерялась синхронизация на серверных опкодах. индексы уехали.

Konctantin 31.05.2010 23:07
Да, pcap? а потом "поверху" SharpPcap.

Цитата:
потерялась синхронизация на серверных опкодах. индексы уехали.
А можно по подробнее, как за ними уследить?

TOM_RUS 31.05.2010 23:34
А помоему некорректно определяются large пакеты...
Код:
// check for large packet
if ((m_buffer[index] & 0x80) != 0)
{
    ...
}

RomanRom2 01.06.2010 01:53
а очень просто. я даже сейчас объясню где багу ловите.

итак, вы входите в мир. попёрло много пакетов. и больших пакетов. что это означает?

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

тут то все и происходит :) в следующей пачке данных вы считаете, что пришел новый пакет и начинаете декриптовать, тут индексы и съезжают.

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

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

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

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

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

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

abdula123 01.06.2010 04:00
лишнее подтвердждение того, что прокси удобнее будет :)

Konctantin 01.06.2010 09:58
Спасибо всем за советы и подсказки:
Цитата:
А помоему некорректно определяются large пакеты...
Да так и есть, щас переделаю:
http://github.com/arrai/tiawps/blob/...pter/decrypt.c
Если я правильно понял с примера, то нужно дополнительно декриптовать еще 1 байт, или же сразу нужный размер.
Код:
private static void ProcessWorldPacket(byte[] data, Direction direction)
{
        int i = 0, size = 0, opcode = 0;
        bool isLarge = (data[i] & 0x80) != 0;
        int HEADER_LENGTH = isLarge ? 4 : 5;

        if (direction == Direction.SERVER)
        {
                Crypt.DecryptServer(data, 0, HEADER_LENGTH);
        }
        else
        {
                HEADER_LENGTH += 2;
                Crypt.DecryptClient(data, 0, HEADER_LENGTH);
        }

        if (isLarge)
                size = data[i++] & 0x7F;

        size = (size << 8) | data[i++];
        size = (size << 8) | data[i++];

        for (int j = 0; j < HEADER_LENGTH - 2; j++)
                opcode |= ((0xFF & data[i++]) << (8 * j));

        size += (2 + (isLarge ? 1 : 0));

        if (size > data.Length)
        {
                Console.WriteLine("ERROR: {0} Size = {1} > packet.Length = {2}", direction, size, data.Length);
                return;
        }

        using (BinaryReader reader = new BinaryReader(new MemoryStream(data)))
        {
                reader.BaseStream.Position += HEADER_LENGTH;
                byte[] newData = reader.ReadBytes(size - HEADER_LENGTH);
                HandleWorldPacket((WorldOpcodes)opcode, newData);

                Console.WriteLine("{0}:\tHeader = {1}\tPacket = {2}\t{3}\tOpcode: {4}",
                        direction, size, data.Length, data.Length == size ? "OK" : "REUSE", (WorldOpcodes)opcode);

                if (size < data.Length)
                {
                        ProcessWorldPacket(reader.ReadBytes(data.Length - size), direction);
                } 
        }
}
Но надо проверить, а это уже вечером.

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

Цитата:
ну и если вам вдруг будет все равно в каком формате записывать,
не все равно, формат ваш (pkt)

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

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

TOM_RUS 01.06.2010 10:05
Сначала надо расшифровать, потом проверить на флаг 0x80, если он выставлен, расшифровать еще 1 байт... А вы сначала проверяете, а потом расшифровываете.

abdula123 01.06.2010 15:30
Цитата:
Сообщение от Konctantin (Сообщение 7769)
А это как нож в горло, как видите пока не в силах сделать сниффер, а до прокси еще как до неба...

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

в самом простейшем случае - использовать готовый LSP-редиректор (proxycap, например) для переброса всех соединений wow на свой сервер. всё.

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

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

Цитата:
Сообщение от TOM_RUS (Сообщение 7771)
Сначала надо расшифровать, потом проверить на флаг 0x80, если он выставлен, расшифровать еще 1 байт... А вы сначала проверяете, а потом расшифровываете.
это баг нескоро бы всплыл.

единственное место где мне встречались large пакеты - это SMSG_COMPRESSED_UPDATE_OBJECT при телепорте (или логине, что по сути одно и то-же) в даларан, в час пик, когда там бегают толпы народа.
все данные по этим разодетым и сверкающим "объектам" близы почему-то отсылают одним большим пакетом.

пока кроме этого места я больше ни одного large пакета не видел.

Konctantin 01.06.2010 16:06
Цитата:
единственная заморочка, которая там есть - это обработка второго соединения и ключей для него.
я так и не осилил ее - все эти новые сиды\хэши, осн.\доп. ключи и т.п. и
Ну на сколько я понимаю до редиректа используются статические сиды, потом, после редиректа, они приходят в пакете SMSG_AUTH_CHALLENGE и уже надо декриптовать пакеты используя эти сиды.

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

Или я чего-то недопонимаю!?

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

TOM_RUS 01.06.2010 16:37
Цитата:
Сообщение от abdula123 (Сообщение 7792)
кроме этого места я больше ни одного large пакета не видел.
Список достижений тоже не маленький и приходит при каждом логине/телепорте.

abdula123 01.06.2010 17:18
Цитата:
Сообщение от TOM_RUS (Сообщение 7796)
Список достижений тоже не маленький и приходит при каждом логине/телепорте.
у меня SMSG_ALL_ACHIEVEMENT_DATA - обычный пакет с 2хбайтовым размером.
наверное ачивок мало :)

Цитата:
[S2C] normal pkt, sz:27329, opcode:1149 (SMSG_ALL_ACHIEVEMENT_DATA)
...
[S2C] large pkt, sz:42257, opcode:502 (SMSG_COMPRESSED_UPDATE_OBJECT)

Цитата:
Сообщение от Konctantin (Сообщение 7793)
получается прокси сама должна перелючить режим шифрования, а клиенту послать видоизмененный пакет редиректа.

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

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

YuruY 01.06.2010 17:21

Neverdie 01.06.2010 17:53
Цитата:
Сообщение от abdula123 (Сообщение 7800)
у меня SMSG_ALL_ACHIEVEMENT_DATA - обычный пакет с 2хбайтовым размером.
наверное ачивок мало :)






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

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

но теперь опять в ОПе -)

надежда опять на прокси

вот что нам не удалось просто после батлы

[11:18] <Kosuha> мне нужно всеголишь реалм лист
[11:18] <Kosuha> перекинуть
[11:18] <Kosuha> т.е. это стадия логин сервера

[12:55] <Kosuha> будет работать в области логгера и прокси
[12:55] <Kosuha> там с прокси я бы щас бился
[12:55] <Kosuha> а выяснил
[12:55] <Kosuha> что изза ИП клиент полюбому рвёт коннект
[12:56] <Kosuha> и реалм лист подменяют как что прослушивая Winsock
[12:56] <Kosuha> я в эти дебри ещё никогда не лазил даже

рук не хватате уна спросто -)) остлись просто " у самовара я и моя бабка"

YuruY 01.06.2010 18:20
Цитата:
рук не хватате уна спросто
Я и предложил вам объедениться, а не вариться в собственном соку. ;)


Текущее время: 11:18. Часовой пояс GMT +3.
Страница 1 из 8 1 2345 Последняя »
Показывать 40 сообщений этой темы на одной странице

ru-mangos.ru - Русское сообщество MaNGOS