NDIS с нуля ^_^

[Olga]

Добрый день!
В программировании драйверов я по сути новичок, но предо мной встала задача работы с Ethernet трафиком на уровне NDIS.
По этому хотела бы прояснить для себя сначала концептуальные моменты.
Суть задачи такова - перехватить пакет(ы), вычленить TCP/UDP заголовок и в зависимости от IP:Port
принять решение пропустить/изменить/запретить.
Перечитав форум и цикл статей Грома решила за основу взять passthru из DDK.
Задача ещё осложняется тем, что мой родной язык - паскаль, и мне не всегда очевидны элементарные для сишника обороты 

И так суть вопросы:

1. В каких функциях я должна анализировать пакеты?
Исходящие, как я понимаю в MiniportSend и MiniportSendPackets,
а входящие в ProtocolReceive и ProtocolReceivePacket?
Если да, то как получить доступ к данным кадра? Правильно ли я понимаю, что в ProtocolReceive третий параметр - это указатель на данные пакета?
А как быть с другими функциями?

2. Если я захочу анализировать данные протокола более высокого уровня, например HTTP, неужели мне придётся
собирать всю цепочку пакетов, чтобы вытащить от туда допустим POST параметры?

3. Если в системе установлены два NDIS драйвера, которые имеют разное мнение о судьбе IP пакета, что произойдёт?

Спасибо

[resource]

пропущу 1й вопрос (это МСДН)
2) ещё как придётся, это ж NDIS.
3) вопрос неясен. Если кто-то пропускает пакет, то он и пройдёт дальше, а если нет, то....... не пройдёт - всё просто. А что имели ввиду вы?

[x64]

Olga,
Уверена, что нужен NDIS? Не проще ли TDI/WFP использовать?

[Olga]

Первый успех, у меня (о, чудо!) скомпилился пример passthru и DbgPrint говорит о том, что управление попадает в PtReceive!
Вот бы теперь понять как работать с пакетом.
Как я понимаю мне нужен аргумент HeaderBuffer
DDK хелп говорит, что это указатель на заголовок пакета. Как его правильно обработать?
Для начала бы понять, что он из себя представляет и какой имеет формат.

вопрос неясен. Если кто-то пропускает пакет, то он и пройдёт дальше, а если нет, то....... не пройдёт - всё просто. А что имели ввиду вы?

Если плохой NDIS драйвер отправляет сетевой пакет, а хороший брандмауэр (на том же уровне NDIS) считает, что этот пакет отправлять нельзя.
Кто победит в данном случае?

Уверена, что нужен NDIS? Не проще ли TDI/WFP использовать?

Да, это принципиально в моём случае.

[resource]

Если плохой NDIS драйвер отправляет сетевой пакет, а хороший брандмауэр (на том же уровне NDIS) считает, что этот пакет отправлять нельзя.
Кто победит в данном случае?

Что значит "на том же уровне"? Не бывает такого. Есть стэк устройств, все идут по порядку.

[Olga]

Похоже путь предстоит долгий 
А раз так, подумала, что буду выкладывать тут результаты своего знакомства с увлекательным миром программирования сети в нулевом кольце.
Может кому пригодится впоследствии.

Итак.

Нашла (на этом форуме) пример, как получить IP адреса в PtReceive

Код:

PCHAR			Buf = HeaderBuffer;

// Check the packet //
	
	PktType = ((USHORT) Buf[12]) * 0x100U + (USHORT) Buf[13];

	switch(PktType) 
		{
		case 0x0800: 
			DbgPrint("Packet type IP 0x%x\n", PktType);

			// Trying to check IP adderss...
			pIpHdr = (PIP_HDR)LookAheadBuffer;
			pOctSrc = (PUCHAR) &(pIpHdr->iph_src);
			pOctDst = (PUCHAR) &(pIpHdr->iph_dest);
			
			DbgPrint("Packet from %d.%d.%d.%d to %d.%d.%d.%d\n",\
						*pOctSrc, *(pOctSrc+1), *(pOctSrc+2), *(pOctSrc+3),\
						*pOctDst, *(pOctDst+1), *(pOctDst+2), *(pOctDst+3) );

			switch(pIpHdr->iph_protocol) 
				{
				case 0x01:
					DBGPRINT(("ICMP: ...\n"));
					break;
					
				case 0x06:
					//	Trying to check TCP related parameters
					pTcpHdr = (PTCP_HDR)((PUCHAR)LookAheadBuffer + sizeof(IP_HDR));
					DbgPrint("TCP: from port %d to port %d\n", pTcpHdr->tcp_src, pTcpHdr->tcp_dest);
					break;

				case 0x11:
					DbgPrint("UDP: ...\n");
					break;
					
				}
			
			break;
			
		case 0x0806:	
			DbgPrint("Packet type ARP 0x%x\n", PktType);
			break;
		}

Насколько мне (стало) известно 12-й и 13-й байт во фрейме Ethernet определяют тип протокола, использующего данный фрейм.
Стало быть HeaderBuffer таки содержит данные пакета, в котором поле Data начинается сразу за 13-м байтом и имеет размер не менее 46 и не более 1500 байт.
Уже хорошо.
Так же из кода понятно, что LookAheadBuffer содержит IP адреса источника и назначения пакета, а так же сигнатуру протокола транспортного уровня TCP/IP.

Добавлено через 5 минут и 43 секунды:

Что значит "на том же уровне"? Не бывает такого. Есть стэк устройств, все идут по порядку.

Да, я видимо не до конца понимаю устройство среды NDIS.
Т.е. если хоть один драйвер в цепочке не пропустит пакет, этого будет достаточно, чтобы пакет не ушёл?

[supermaxus]

Есть спец тема https://forum.shelek.ru/index.php/topic,7748.0.html, там больше половины ваших вопросов разобрано. Тема длинная, но зачем по несколько раз одно и то же обсуждать?

[Olga]

Я её всю перечитала )
Всё равно множество вопросов. Буду спрашивать по мере своего продвижения.

[supermaxus]

Насколько мне (стало) известно 12-й и 13-й байт во фрейме Ethernet определяют тип протокола, использующего данный фрейм.

ip протокол идет внутри ethernet кадра и имеет, как минимум, 4 вариации своего фрейма (кадра). Естественно, что их структура между собой различается. И там не все так однозначно:)

PS имхо, плохо читали - Вы спрашиваете, что там есть - например, код доступа к данным ethernet-кадра, хотя там точно есть целая функция этому посвященная, перечислены все процедуры для приема данных, в литературе о драйверах где-то была ссылка http://www.computerbooks.ru/books/Programming/Book-Pogramming-Sistem-Security/Glava%204/Index21.htm про ndis, ну и другое

[Olga]

PS имхо, плохо читали

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

[sinsin]

Olga, если хочешь, то есть примеры: http://www.wd-3.com/archive/ExtendingPassthru.htm, там же где-то еще вторая часть должна быть