Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / C++ [игнор отключен] [закрыт для гостей] / Мистический UDP пакет / 13 сообщений из 13, страница 1 из 1
01.04.2014, 14:04
    #38601881
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Пишу свою пересылалку файлов по 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
01.04.2014, 18:51
    #38602276
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Сделал по своему плану, теперь одно и тоже сообщение в 4-х видах, в данном случае естественно помогло. Т.к. UDP то изначальная установка на потери и повторы, только повторы будут разные.

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

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

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

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

В качестве версии с потолка - это может быть даже багом оборудования, читал про подобное - тынц
...
Рейтинг: 0 / 0
01.04.2014, 19:36
    #38602325
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
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
01.04.2014, 20:44
    #38602375
miksoft
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Dima TНе вижу бага оборудованияА он может быть и не у вас, а у какого-либо провайдера в цепочке.

Если интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет.
...
Рейтинг: 0 / 0
02.04.2014, 10:35
    #38602685
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
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
02.04.2014, 14:41
    #38603086
Изопропил
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Dima TmiksoftЕсли интерес еще остался, то можно попробовать отправлять этот магический пакет с разными TTL и посмотреть до какого промежуточного хоста он доходит, а до какого уже нет.
Смысла нет искать конкретное место.
это, тем не менее, интересно
ибо может всплыть в самых неожиданных ситуациях.

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

Изопропилне проходит в пакете с определённым смещением или в любом месте?
Мой вывод: сглючевает по значению вторых 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
02.04.2014, 23:46
    #38603623
Изопропил
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Dima T
Код: plaintext
1.
00, 00, 00, 00, 00, 0x38, 00, 00


если не по смещению 8 - проходит или нет ?
...
Рейтинг: 0 / 0
03.04.2014, 02:43
    #38603654
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Это пров режет протокол торрента µTP (запросы на коннект пиру имеют такую сигнатуру).
...
Рейтинг: 0 / 0
03.04.2014, 07:16
    #38603684
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Изопропил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
03.04.2014, 07:33
    #38603686
Dima T
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
тест пакетами по 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
03.04.2014, 10:16
    #38603845
Anatoly Moskovsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мистический UDP пакет
Dima TAnatoly MoskovskyЭто пров режет протокол торрента µTP (запросы на коннект к пиру имеют такую сигнатуру).
Интересная версия, вполне правдоподобная, даже не по причине борьбы за лицензионность контента, а просто защита от перегруза каналов где домашним пользователям обещаны десятки мегабит.
Что значит правдоподобная. Так оно и есть на самом деле :)
Некоторые провадеры с дешевым конечным оборудованием включают фильтрацию µTP для защиты раутеров от перегрузки мелкими пакетами, которые любит µTP. Потому что одно дело 100Мбпс при пакете 1500 и другое дело при пакете 60 байтов
...
Рейтинг: 0 / 0
Форумы / C++ [игнор отключен] [закрыт для гостей] / Мистический UDP пакет / 13 сообщений из 13, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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