powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / C++ [игнор отключен] [закрыт для гостей] / Мистический UDP пакет
13 сообщений из 13, страница 1 из 1
Мистический UDP пакет
    #38601881
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пишу свою пересылалку файлов по UDP. Пересылаю по проводному инету с провайдера А на провайдера Б.
Случайно получилось что один пакет стабильно рубится.
После изучения и урезания получил магические 16 байт, причем первые 8 без разницы какие, главное что их 8.
Код: plaintext
1.
2.
3.
4.
5.
char bad_udp[] = {21, 21, 21, 21, 21, 21, 21, 21, 00, 00, 00, 00, 00, 0x38, 00, 00};
int size_send = sendto(sock, bad_udp, 16, 0, (SOCKADDR *) &addr_server, sizeof(sockaddr_in));
if(size_send > 0) {
	printf("send %d bytes to %s:%d\n", size_send, inet_ntoa(addr_server.sin_addr), ntohs(addr_server.sin_port));
}


Похоже правда что провайдеры действительно балуются фильтрацией UDP. В данном случае проверяется значение вторых 8-ми байт. Изменяешь любой из них и все доходит.

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

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

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

PS Если кто подозревает что у меня с руками проблема, для тех полный вариант тестаЕсть ПК1 для него шлюз роутер к провайдеру А, есть ПК2 для него шлюз роутер к провайдеру Б. ПК2 слушает свой порт 45678. На роутере Б проброшен порт 45678 на ПК2. На ПК1 открывается случайный порт и отправляется пакет на внешний IP Б порт 45678. Другие пакеты проходят, этот - нет.
ПК1 и ПК2 в локалке, по локалке этот пакет доходит на IP ПК2:45678.
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38602276
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделал по своему плану, теперь одно и тоже сообщение в 4-х видах, в данном случае естественно помогло. Т.к. UDP то изначальная установка на потери и повторы, только повторы будут разные.

Прикинул изначальную вероятность такого попадания (1 / 2^64) * количество 8-байтовых фильтров, величина очень близкая к нулю, но я попал и хорошо что попал во время отладочных тестов.

Подзабыл теорию вероятностей, не знаю как прикинуть на сколько увеличилась вероятность прохождения пакета через фильтры если я могу послать его в четырех разных видах? В четыре раза или в четвертой степени?

И просто интересно что означает {00, 00, 00, 00, 00, 0x38, 00, 00}, это код на асме или просто статичный кусок заголовка?
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38602296
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima T,

Попробуйте сниффером выяснить:
а) покидают ли физически пакеты хост-источник
б) доходят ли физически пакеты до хоста-получателя

В качестве версии с потолка - это может быть даже багом оборудования, читал про подобное - тынц
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38602325
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftDima T,

Попробуйте сниффером выяснить:
а) покидают ли физически пакеты хост-источник
б) доходят ли физически пакеты до хоста-получателя

В качестве версии с потолка - это может быть даже багом оборудования, читал про подобное - тынц
Не, провайдер однозначно.
Выше писал подробное описание тестаЕсть ПК1 для него шлюз роутер к провайдеру А, есть ПК2 для него шлюз роутер к провайдеру Б. ПК2 слушает свой порт 45678. На роутере Б проброшен порт 45678 на ПК2. На ПК1 открывается случайный порт и отправляется пакет на внешний IP Б порт 45678. Другие пакеты проходят, этот - нет.
ПК1 и ПК2 в локалке, по локалке этот пакет доходит на IP ПК2:45678.

Еще подробнее (IP условные)
ПК1 192.168.0.10 шлюз 192.168.0.1
ПК2 192.168.0.20 шлюз 192.168.0.2
роутер А внутренний 192.168.0.1 внешний 87.226.122.53
роутер Б внутренний 192.168.0.2 внешний 217.11.80.157
на роутере Б правило с порта 217.11.80.157:45678 перенаправлять на 192.168.0.20:45678

с ПК1 запускаю отправку на 217.11.80.157:45678 - этот пакет не доходит (другие доходят)
с ПК1 запускаю отправку на 192.168.0.20:45678 - этот пакет доходит

Все тесты на одних и тех же EXE. Не вижу бага оборудования или бага в своем коде (тем долее после добавки шифрования он заработал при тех же условиях). Кроме того изначально обнаружил когда тестил с третьего провайдера (GPRS через телефон) на 87.226.122.53:45678. Терял стабильно один и тот же пакет на ответе. В итоге эти 16 байт выковыряны из того пакета.

PS провайдер А реально параноики неадекватные (были прецеденты), могли и фильтрацию запустить. Они у меня как резервный канал.
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38602375
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TНе вижу бага оборудованияА он может быть и не у вас, а у какого-либо провайдера в цепочке.

Если интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет.
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38602685
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
miksoftDima TНе вижу бага оборудованияА он может быть и не у вас, а у какого-либо провайдера в цепочке.
Баг оборудования или фильтр на провайдере - это не важно, важно что это есть.
По большому счету важна природа глюка, а она такова что не вписывается в концепцию "доставка UDP пакета не гарантируется", тут получилось что "доставка конкретного UDP пакета невозможна" хоть сколько раз его повторяй.

Вероятность повторения такого глюка сложно предсказывать, сглючило на пересылке одного конкретного файла (слал .pdb который компилятором создается), но файлов по инету я немного погонял 10-20, а на запрет нарвался. Может случайно "повезло", а может много таких "багов".
miksoftЕсли интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет.
Смысла нет искать конкретное место. В итоге работать будет там, где у меня не будет ни времени, ни возможности детально разбираться. В идеале должно само работать без вмешательств даже при наличии подобных явлений.

Не хотел делать лишнего шифрования того что не надо, но приходится.
Если кому интересно вот мой шифратор/дешифратор
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
// увеличение в 4 раза разнообразия одинаковых пакетов
#define XOR_ENCRYPT 1
#define XOR_DECRYPT 2
#define XOR_MASK_SIZE 13
// маски XOR (принципиально важно старшие 2 бита первого байта 00 для 0й, 01 для 1, 10 для 2й и 11 для 3й)
unsigned char mask_list[4][XOR_MASK_SIZE]= 
		{{0x10,0x6E,0x62,0x72,0x27,0x12,0x71,0xFE,0xDF,0x06,0xE4,0x91,0x63},
		 {0x53,0x0C,0x2B,0xDD,0x11,0xDC,0x77,0x49,0xC1,0x19,0x68,0xAA,0x31},
		 {0x97,0x38,0x3A,0x8E,0xCA,0xFE,0xAB,0xBB,0x9D,0x4E,0x7A,0x3C,0xD9},
		 {0xD2,0x0B,0x47,0xE9,0xFA,0x70,0xA9,0x91,0x04,0xE5,0xFB,0x96,0x51}};

// изменение пакета данных
bool udp_xor(char* msg, int size, int type)
{
	unsigned char* buf = (unsigned char*) msg;
	unsigned char* mask;
	if(type == XOR_DECRYPT) { // расшифровка, берем из сообщения
		mask = mask_list[buf[0] >> 6];
	} else if((buf[0] >> 6) != 0) {
		// неверное исходное сообщение, заняты старшие биты
		printf("encrypt error\n");
		return false;
	} else { // Зашифровка
		static int mask_num = 0;
		mask_num = (mask_num + 1) % 4;
		mask = mask_list[mask_num];
	}

	for(int i = 0; i < size; i++) {
		buf[i] ^= mask[i % XOR_MASK_SIZE];
	}
	return true;
}
//----------------------------
// примеры использования
if(udp_xor(msg, size_to_send, XOR_ENCRYPT)) {
	// отправка UDP пакета
	int size = sendto(sock, msg, size_to_send, 0, (SOCKADDR *) &addr, sizeof(sockaddr_in));
...
// прием
int size = recvfrom(sock, msg, UDP_MAX_SIZE, 0, (SOCKADDR *) &addr, &addr_size);
if(udp_xor(msg, size, XOR_DECRYPT)) {
	// обработка сообщения
...

...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38603086
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TmiksoftЕсли интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет.
Смысла нет искать конкретное место.
это, тем не менее, интересно
ибо может всплыть в самых неожиданных ситуациях.

не проходит в пакете с определённым смещением или в любом месте?
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38603120
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Изопропилэто, тем не менее, интересно
ибо может всплыть в самых неожиданных ситуациях.
Гиморно это. Согласен что интересно, но как-то надо разумно ограничивать свои творческие изыскания, а то я вместо написания собственного простенького протокола передачи файла стану спецом по низкоуровневому устройству интернета ))

Изопропилне проходит в пакете с определённым смещением или в любом месте?
Мой вывод: сглючевает по значению вторых 8ми байт
Код: plaintext
1.
{21, 21, 21, 21, 21, 21, 21, 21, 00, 00, 00, 00, 00, 0x38, 00, 00};


первые 8 другие были, менял по одному на ! потом из far скопировал, кстати 0x забыл дописать. Но если из восьми первых один убрать - проходит. (добавить в первые не пробовал).
После тоже было много, убирал с конца пока проходить не начал, в итоге остались эти 16 байт.
При изменении одного из вторых 8-ми - начинает проходить (правда не все менял, выборочно по одному 2-3 раза).
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38603623
Фотография Изопропил
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima T
Код: plaintext
1.
00, 00, 00, 00, 00, 0x38, 00, 00


если не по смещению 8 - проходит или нет ?
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38603654
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Это пров режет протокол торрента µTP (запросы на коннект пиру имеют такую сигнатуру).
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38603684
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ИзопропилDima T
Код: plaintext
1.
00, 00, 00, 00, 00, 0x38, 00, 00


если не по смещению 8 - проходит или нет ?
Код отправки
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
		char bad_udp[] = {0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 00, 00, 00, 00, 00, 0x38, 00, 00, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21, 0x21};
		char *buf_send = bad_udp;
		int size = 16;
		for(int i = 0; i < 9; i++) {
			int size_send = sendto(sock, buf_send, 16, 0, (SOCKADDR *) &addr_server, sizeof(sockaddr_in));
			if(size_send == size) {
				printf("send %d {", size);
				for(int i = 0; i < size; i++) {
					printf("%02X,", (unsigned char) buf_send[i]);
				}
				printf("}\n");
			}
			buf_send++;
			Sleep(100);
		}


лог отправкиsend 16 {21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,}
send 16 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,}
send 16 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,}
send 16 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,}
send 16 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,}
send 16 {21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,}
send 16 {21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,}
send 16 {21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,}
send 16 {00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,21,}
прием через инетrecv 16 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,}
recv 16 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,}
recv 16 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,}
recv 16 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,}
recv 16 {21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,}
recv 16 {21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,}
recv 16 {21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,}
recv 16 {00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,21,}
прием по локалке recv 16 {21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,}
recv 16 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,}
recv 16 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,}
recv 16 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,}
recv 16 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,}
recv 16 {21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,}
recv 16 {21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,}
recv 16 {21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,}
recv 16 {00,00,00,00,00,38,00,00,21,21,21,21,21,21,21,21,}

Если интересно - напиши интересующие варианты - затестю, отпишусь.
Anatoly MoskovskyЭто пров режет протокол торрента µTP (запросы на коннект пиру имеют такую сигнатуру).
Интересная версия, вполне правдоподобная, даже не по причине борьбы за лицензионность контента, а просто защита от перегруза каналов где домашним пользователям обещаны десятки мегабит.
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38603686
Dima T
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тест пакетами по 18
отправкаsend 18 {21,21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,}
send 18 {21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,}
send 18 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,}
send 18 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,}
send 18 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,}
send 18 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,}
прием с инетаrecv 18 {21,21,21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,}
recv 18 {21,21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,}
recv 18 {21,21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,}
recv 18 {21,21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,}
recv 18 {21,21,21,21,00,00,00,00,00,38,00,00,21,21,21,21,21,21,}
по локалке все доходит.
...
Рейтинг: 0 / 0
Мистический UDP пакет
    #38603845
Фотография Anatoly Moskovsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dima TAnatoly MoskovskyЭто пров режет протокол торрента µTP (запросы на коннект к пиру имеют такую сигнатуру).
Интересная версия, вполне правдоподобная, даже не по причине борьбы за лицензионность контента, а просто защита от перегруза каналов где домашним пользователям обещаны десятки мегабит.
Что значит правдоподобная. Так оно и есть на самом деле :)
Некоторые провадеры с дешевым конечным оборудованием включают фильтрацию µTP для защиты раутеров от перегрузки мелкими пакетами, которые любит µTP. Потому что одно дело 100Мбпс при пакете 1500 и другое дело при пакете 60 байтов
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / C++ [игнор отключен] [закрыт для гостей] / Мистический UDP пакет
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]