Сниффер
Кто знает сниффер под 3.3.2. Поискал по интернету, что-то не густо.
|
А их никогда и не будет густо. Так уж сложилось традициями, что все сниферы под ВоВ всегда держатся в привате.
А после того, как близы перешли на RC4, снифить траффик можно только собрав session_key откуда либо. Прокси сейчас не работают из-за BN2 протокола, остались только инъекторы. |
|
Цитата:
|
прокси как работали, так и работают. просто приходится зарыться немного поглубже. :)
а вот юзать pcap - это хуже не придумаешь. слишком много проблем с пересброкой потока из пакетов. да и про то, чтобы вставлять свои пакеты в поток - можно забыть. |
Цитата:
|
Цитата:
|
Цитата:
нужно просто сделать, чтобы клиент не замечал, что на его пути что-то стоит. например вклиниваться в соединение с помощью LSP (можно своего, а можно и с помощью какого-нибудь проксификатора, благо все они под WinXP работают по этому принципу). кстати, насчет инжектов - Warden бдит. я насчитал 4 проверки, связанные с соединением и отправкой данных. если кто не знает их точных адресов - можно и напороться. :( |
Цитата:
место было удобное покамись не сметили да и биаша больше не захотел (то есть времени нету у него):sorry: покамись юзаем tiawps |
столкнулись с проблемой при использования метода 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 струткура вот сидим думаем ктог лючит мы или тивапс |
Я раз пробовал, еще когда была версия 332 - получилось.
Но он мне показался сильно геморным и я забил :( Кстати, а никто не пробовал заюзать мелкософтовский net monitor, у них там даже API имеется? |
да на 33,2 и у нас то работало
а вот с 3,3,3 фигня какая то просто мало рук чтоб вникать |
ну с портами там и хостами беда прыгают как зайчики, это раз
и 2 даже если поймаешь порт и хост, то иногда какого-то черта получает пакет 3 по счету после коннекта, который не декриптуется LENGTH: 65536 OPCODE: 0000 DATA: 00 00 00 00 не стал пока разбираться, чего-то нету желания |
да был такой
пакет и еще могло почему-то выйти 2 дампа сразу 1 стандартно а 2 громадный |
Цитата:
|
Цитата:
1. клиент авторизуется, подключается к реалм-серверу по умолчанию. 2. в процессе обмена данными приходит пакет "а подключись-ка та на такой-то адрес:порт" (обычно через секунду-две после логина, но не обязательно, может и в середине игры прийти). 3. клиент устанавливает соединение, согласовывает шифрование (с новыми сидами, ключами и всей прочей кухней) 4. и в первое соединение приходит пакет "переводи весь обмен данными на второе соединение". и дальше все данные с сервера начинают сыпаться в это соединение. в 3.3.3(без а) был такой баг - первое соединение не закрывалось, хотя объекты, с ним связанные удалялись. в (а) уже исправили, вроде-бы. иногда пакет из шага 2 не приходит, тогда клиент продолает работать в одно соединение (все по старому). видимо это тот случай, когда лоад-балансер считает нужным не переводить клиента на другой адрес:порт (на дефолтном меньше всего народа) если взять и исключить из потока этот пакет (моя прокся такие издевательства позволяет) - то клиент так и будет работать в одно соединение (второе-то не согласовано). минуты 3 где-то, потом сервер кикнет. |
Цитата:
|
Как вычислить этот пакет? я не могу его поймать. Сидел со сниффером пол часа так и не понял как его определить.
|
Цитата:
времена, когда для этого использовался зацикленый по кругу 20байтный session_key уже давно прошли. так что приходится поддерживать 4 rc4-состояния - на каждое направление с каждой стороны. инициализировать их из данных клиента и все до единого пакеты пропускать через них. точнее приходилось до недавнего времени. сейчас - 4 х кол-во подключений (если я правильно понимаю, близам ничего не мешает перекидывать клиента между разными адресами:портами по нескольку раз за сессию). да, кстати, у вардена свое шифрование со своими ключами, независимое от сессионного. и его состояния тоже нужно поддерживать, если есть желание читать\редактировать варденовский трафик. и они тоже меняются при загрузке нового варденоского модуля (один раз за сессию, почти в самом начале. и тоже ничего не мешает близзам грузить новые варденовские модули по сколько угодно раз) :) Цитата:
с шифрованым заголовком. естественно, до установки второго соединения. опкод - 1293. Код:
[S2C] SMSG_SECOND_CONNECTION (1293 = 0x050D) len: 30 |
Цитата:
я хотел сказать что даже цикличный ключ не позволял вклинится, но сказал криво. ок :) Цитата:
Цитата:
|
Цитата:
на самом деле это не так уж и сложно, если хочется только читать данные. единственное - придется подправлять после каждого патча. а вот если хочется их редактировать на лету - таким способом это делать ну очерь извратно. |
ну поняно
против лома нету приему если нет другого лома менячто поражает больше чем мудрее близы защиту делают тем сильнее их ломают |
Цитата:
к тому-же им пофиг на всё, кроме массового макро\ботоводства. |
Цитата:
|
а если б не сменили систему аутентификации, не так бы интересно было :)
|
Мы тут с LordJZ начали делать сниффер, но наткнулись на неприятность:
При логине и пока стоим на окне выбора персонажей пакеты декриптуются нормально Вот лог сниффера: Код:
World server address: 62.67.45.123:3724 Код:
CLIENT: Header = 14 Packet = 14 OK Opcode: CMSG_PLAYER_LOGIN Код:
private static void ProcessWorldPacket(byte[] data, Direction direction) |
похвально. pcap?
потерялась синхронизация на серверных опкодах. индексы уехали. |
Да, pcap? а потом "поверху" SharpPcap.
Цитата:
|
А помоему некорректно определяются large пакеты...
Код:
// check for large packet |
а очень просто. я даже сейчас объясню где багу ловите.
итак, вы входите в мир. попёрло много пакетов. и больших пакетов. что это означает? это означает, что когда вы в снифере видите "пакет", то это совсем не означает что он пришел полностью. это даже не означает что это пакет вообще. это просто какие то данные в потоке tcp. и даже на следующий "recv_from_server" тоже не обязательно пакет придет полностью. под "пакетом" будем подразумевать "игровой пакет" от близзов, дамп опкода. тут то все и происходит :) в следующей пачке данных вы считаете, что пришел новый пакет и начинаете декриптовать, тут индексы и съезжают. нужно запоминать размер пакета после декриптовки и ждать все данные для этого пакета. бывают пакеты по 40кб, и в сетевом потоке они будут приходить пачками по 4-5кб. так же случается ситуация, когда в одной пачке данных сразу несколько пакетов. за всем этим нужно тщательно следить. я могу конечно ошибаться, но по опыту (поверьте в мой опыт) даю 95% что это так. т.е. вы теряете конец текущего пакета и соответственно начало следующего. а это можно сделать по вышеописанной причине. это как бы даже нормально :) я тоже наступал на эти грабли :) с другой стороны, а зачем вам раскриптованный трафик сразу? это ведь все задержки и возможные ошибки. можно в сниф писать raw-трафик, я его так называю. а декодировать уже потом утилиткой. в снифф пишется ключ и raw-данные, словленные pcap. клиентские отдельно, серверные отдельно. ну всмысле они помечаются соответствующим заголовком. таким образом получается некий формат сниффа. ну и если вам вдруг будет все равно в каком формате записывать, хотел бы предложить разработанный нами формат raw - как раз для случая сбора трафика через pcap. если соберетесь - примеры снифов, утилит для декриптовки в pkt с исходниками и pktViewer - подарю. удобство в том, что возле каждого пакета лежит время и тик клиента. по ним чудно смотреть временные интервалы, разгадывать тайну мув-таймстампа и т.п. на сриншоте вьювера видно. ну еще в неком унифицированном, едином формате снифов, которого нам пока достичь не удалось, как мы не раздавали свои сниферы, сами снифы и утилиты для их обработки. |
лишнее подтвердждение того, что прокси удобнее будет :)
|
Спасибо всем за советы и подсказки:
Цитата:
http://github.com/arrai/tiawps/blob/...pter/decrypt.c Если я правильно понял с примера, то нужно дополнительно декриптовать еще 1 байт, или же сразу нужный размер. Код:
private static void ProcessWorldPacket(byte[] data, Direction direction) Цитата:
Цитата:
Цитата:
Цитата:
Цитата:
Да и с моим ничтожным опытом в программировании (чуть больше года на любительском уровне и когда есть время) наверное не постичь тайну аутеффикации, так как надо делать хук (подменить ИП сервера в памяти), надо еще чего-то и еще... Ладно хватит писать, пойду работать... |
Сначала надо расшифровать, потом проверить на флаг 0x80, если он выставлен, расшифровать еще 1 байт... А вы сначала проверяете, а потом расшифровываете.
|
Цитата:
в самом простейшем случае - использовать готовый LSP-редиректор (proxycap, например) для переброса всех соединений wow на свой сервер. всё. никаких подмен в памяти, никаких собственных аутентификаций. единственная заморочка, которая там есть - это обработка второго соединения и ключей для него. я так и не осилил ее - все эти новые сиды\хэши, осн.\доп. ключи и т.п. и откатился простому и тупому чтению готового arc4-состояния из памяти. Цитата:
единственное место где мне встречались large пакеты - это SMSG_COMPRESSED_UPDATE_OBJECT при телепорте (или логине, что по сути одно и то-же) в даларан, в час пик, когда там бегают толпы народа. все данные по этим разодетым и сверкающим "объектам" близы почему-то отсылают одним большим пакетом. пока кроме этого места я больше ни одного large пакета не видел. |
Цитата:
получается прокси сама должна перелючить режим шифрования, а клиенту послать видоизмененный пакет редиректа. Или я чего-то недопонимаю!? Я пробовал сначала написать прокси, сделал наброски, но потом все заглохло за неимением данных и неумением. |
Цитата:
|
Цитата:
наверное ачивок мало :) Цитата:
Цитата:
и потом использовать эти ключи для расшифроки пакетов (и обратной зашифровки - если требуется модифицировать пакеты на лету или добавлять\удалять их) |
|
Цитата:
нопомто с батлой мы прокси не могли перенаправить верно перешли на тиавапс уже теость с ключем декомпилировали но теперь опять в ОПе -) надежда опять на прокси вот что нам не удалось просто после батлы [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> я в эти дебри ещё никогда не лазил даже рук не хватате уна спросто -)) остлись просто " у самовара я и моя бабка" |
Цитата:
|
Текущее время: 23:01. Часовой пояс GMT +3. |
ru-mangos.ru - Русское сообщество MaNGOS