Forum Replies Created
-
Posts
-
Windows XP belongs to NT family (Windows NT 3.51 – Windows NT 4.0 – Windows 2000 – Windows XP – Windows 2003).
May be your professor meaned Windows ME?
Well, I have not checked how EAPoL is realized in Windows, the general situation is the following.
WinpkFilter works between systems installed protocol drivers (base x86 NDIS-hook version under TCP/IP only but can be easily extended) and network adapters. So if “Layer 2 Packet” are generated by protocol driver then it is possible to intercept, if not (packet generated by network card driver) then there is no way…
Why is that? It still seems like it is running and blocking, but nevertheless it is a concern that the service is not staying running.
NTKernelService is only responsible for loading firewall settings into the driver during system start up. After doing this NTKernelService exits (in order to decrease consumed system resources). It is not necessary to have it running.
How do I get only pop3/smtp packets using winpkfilter?
You will get all packets with WinpkFilter but you can selectively process SMTP/POP3 packets. In order to implement this you have to parse packet headers (Ethernet, IP, TCP) and check source/destination ports for SMTP/POP3 ones (25/110).
How do I decode raw packets to see the content? Where may I find more VB examples of using that?
In C parsing is easy (typecasting to structures):
pEthHeader = (ether_header*)PacketBuffer.m_IBuffer;
if ( ntohs(pEthHeader->h_proto) == ETH_P_IP )
{
pIpHeader = (iphdr*)(PacketBuffer.m_IBuffer + ETHER_HEADER_LENGTH);
if (pIpHeader->ip_p == IPPROTO_TCP)
{
// This is TCP packet, get TCP header pointer
pTcpHeader = (tcphdr*)(((PUCHAR)pIpHeader) + sizeof(DWORD)*pIpHeader->ip_hl);
....I’m not a VB expert but getting Ethernet header is shown in WinpkFilter VB samples, getting other headers should be very similar.
what is actually a custom build?An API to do a special issue?
In general it is a special build generated for the Developer license licensees with customized names (and internal version resources information) for drivers and devices. It also may include some functional changes, but this is discussed individually.
Опять рекомендую обратить внимание на полученный NDIS_STATUS? Это вполне может быть NDIS_STATUS_NOT_SUPPORTED…
А какой статус (NDIS_STATUS) возвращается? Нижележащий драйвер сетевой карты может просто не поддерживать этот OID…
The WinpkFilter library you mentioned, is it free or do I have to purchase it? Is it the free downloadable ndisapi.dll ?
WinpkFilter is free for non-commercial use and available for download from here (http://www.ntkernel.com/w&p.php?id=7). Package includes drivers(ndisrd.sys/ndisrd.vxd), API DLL (ndisapi.dll) and several simple samples.
If you register WinpkFilter (any type of subscription starting from 95$) you also get access to the Internet Gateway source code (http://www.ntkernel.com/w&p.php?id=31) which implements NAT and gives a good clue to how to redirect packets.
Some code samples can be also found by looking through this forum. I can also C&P a redirect relative portion of code from NeT Firewall source, but it may appear a bit difficult to understand.
Yes, this is possible to implement in Visual basic using WinpkFilter library, however I can’t provide you with ready to use code in VB (as I’m not a VB coder). If you can use the C code I think I can provide some.
Also you can use port/protocol mapping avalable in NeT Firewall (set up redirector rules on the internal LAN interface).
I would not recommend using IM drivers on the legacy systems NT4, 9x/ME because these OS’s have a poor support for this type of drivers (various problems were many discussed in the developers community). Since Windows 2000 IM drivers support was improved and in general you can use IM drivers for 2000/XP/2003 instead NDIS hooking ones. But here is another disadvantage, you have to sign your drivers with MS (expensive and you have to do signing each time you rebuild driver) if you don’t want users to be warned about unsigned “dangerous” driver many times during installation process. These warnings can be relatively easily disabled on the most modern Windows XP SP2 and Server 2003 (including x64 versions) and you can find the required script in the WinpkFilter x64 installation. However, this is problem to do the same for the earlier OS’s because of bugs in the relative MS code. We had to use IM drivers for x64 because of new patching policy from MS (it detects patching NDIS and BSOD the system), however we plan to release NDIS hooking version for x64 which will also disable patch guard.
Also, with NDIS hooking driver you get more flexibility (an example one our customer needed to see adapters and filter packets below MS Ethernet Bridge in Windows XP, this is easily doable with NDIS hooking driver but can’t say the same for the IM). The only disadvantage of NDIS hook is a chance for the incompatibility with another NDIS hook solution…
Я перехватываю входящий пакет, где исходный IP равен адресу машины в локальной сети, а адрес назначения равен адресу в Интернет. Меняю исходный IP на IP внешнего интерфейса и передаю в стек. И ничего… Стек игнорирует пакет!
1) Включи IP маршрутизацию (ключ в реестре плюс перезагрузка).
2) Исходящий пакет перехватываем на внешнем (интернет-интерфейсе, туда его отроутит стек), маки там уже правильные, нужно только подменить IP/порт источника иначе пакет не уйдет далеко.
3) Для входящих так же на внешнем интерфейсе восстанавливаем IP/порт источника на адрес в локальной сети.Все крайне просто…
Ahh, it is clear now (under binding usually meant another thing). Then the solution is intercepting TCP/IP protocol registering and setting a new handler for ProtocolStatus. This handler is called with status WAN line up indication each time when new WAN connection is established. Another option is creating a protocol driver and binding it to NDISWAN, so it should be also possible to receive line up indications.
