Сниффер

[xmolex]

Кто знает сниффер под 3.3.2. Поискал по интернету, что-то не густо.

[Deamon]

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

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

[Dereka]

http://github.com/arrai/tiawps смотри

[Deamon]

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

http://github.com/arrai/tiawps смотри

Хм... Интересный вариант, в принципе можно и так.

[abdula123]

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

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

[Konctantin]

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

А как же аутентификация?

[Neverdie]

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

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

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

поделитесь тайной прохода аутентификации

[abdula123]

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

поделитесь тайной прохода аутентификации

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

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




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

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

[Neverdie]

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

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

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




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

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

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

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

[Neverdie]

столкнулись с проблемой при использования метода 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]

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

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

[Neverdie]

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

[Konctantin]

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

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

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

[Neverdie]

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

[Konctantin]

1 стандартно а 2 громадный

из-за смены портов

[abdula123]

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

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

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

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

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


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


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

[RomanRom2]

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

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

прокся умеет вклиниваться в трафик с циклическим ключем? или прокся самостоятельно устанавливает соединение и с сервером со своим ключем и с клиентом со своим ключем?

[Konctantin]

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

[abdula123]

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

прокся умеет вклиниваться в трафик с циклическим ключем? или прокся самостоятельно устанавливает соединение и с сервером со своим ключем и с клиентом со своим ключем?

размеры/заголовки пакетов XORятся потоком байт, генерируемых RC4. а этот поток назвать цикличным язык как-то не поворачивается

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


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

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



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

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

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

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

опкод - 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]

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

размеры/заголовки пакетов XORятся потоком байт, генерируемых RC4. а этот поток назвать цикличным язык как-то не поворачивается

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

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

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

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

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

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

да, кстати, у вардена свое шифрование со своими ключами, независимое от сессионного.

[abdula123]

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

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

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

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

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

[Neverdie]

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

[abdula123]

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

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

близы в плане защиты очень ленивые. ОЧЕНЬ, ОЧЕНЬ ленивые.

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

[Neverdie]

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

близы в плане защиты очень ленивые. ОЧЕНЬ, ОЧЕНЬ ленивые.

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

черный пиар всегда был дешевой рекламой

[Konctantin]

а если б не сменили систему аутентификации, не так бы интересно было

[Konctantin]

Мы тут с 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]

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

[Konctantin]

Да, pcap? а потом "поверху" SharpPcap.

потерялась синхронизация на серверных опкодах. индексы уехали.

А можно по подробнее, как за ними уследить?

[TOM_RUS]

А помоему некорректно определяются large пакеты...

// check for large packet
if ((m_buffer[index] & 0x80) != 0)
{
    ...
}

[RomanRom2]

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

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

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

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

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

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

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

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

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

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

[abdula123]

лишнее подтвердждение того, что прокси удобнее будет

[Konctantin]

Спасибо всем за советы и подсказки:

А помоему некорректно определяются 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]

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

[abdula123]

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

А это как нож в горло, как видите пока не в силах сделать сниффер, а до прокси еще как до неба...

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

на самом деле всё гораздо проще.

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

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

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

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

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

это баг нескоро бы всплыл.

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

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

[Konctantin]

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

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

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

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

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

[TOM_RUS]

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

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

Список достижений тоже не маленький и приходит при каждом логине/телепорте.

[abdula123]

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

Список достижений тоже не маленький и приходит при каждом логине/телепорте.

у меня 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

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

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

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

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

[YuruY]

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

[Neverdie]

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

у меня 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]

рук не хватате уна спросто

Я и предложил вам объедениться, а не вариться в собственном соку.