Forum Replies Created
-
Posts
-
I’m making a firewall with this driver. In my firewall i need to allow packets from specific applications only. can I get this information from the packet header? What application has sent this packet. Or is there a way to do this.
There is no way to determine application context on the NDIS level. Actually not all packets you see have the associated app (these are routed packets, packets generated by TCP/IP stack). However you can track active connections information with TDI filter or with LSP and use this information to determine each packet associated application.
Also in this firewall I want to block websites with specific names. Is it possible if yes how. Any example will be heighly appriciated.
You can track and modify DNS requests for these names an example…
I can miss something because it passed pretty much time since my last research of this subject.
3E-1C-20-52-41-53 – this is what DeviceNDISWANIP returns for OID_802_3_CURRENT_ADDRESS request. NDISWAN generates first three bytes as a function of time during initialization stage; last three bytes are hexing codes for the word “RAS”. Note that you never see this MAC address in the packets, there are pairs of MACs used for each WAN connection, if I remember fine first three bytes will remain and last three bytes generated from the connection number.
Btw, mapping IP address to WAN interface is not easy task because it may have multiply IP addresses, each one associated with WAN connection (note that on Windows NT/2000/XP you may have multiply WAN connections). WinpkFilter driver can track information about each established WAN connection including its IP address (actually NT/2000/XP version has some relative code for this). Doing the same for Windows 9x/ME requires hooking one of device VIP VxD services, but luckily only one active WAN connection is possible. So if you own WinpkFilter Source Code license then you can customize the helper driver for your needs. In user-mode you can query required information using RAS API and IP Helper API.
There were no changes in the DLL since version 1.3.0 and this is why its version resource was not updated, so you should be able to use provided CBuilder DLL fine with the latest driver. MSVC DLL version was updated just in order to match main product version since it is used for all sample binaries.
DLL source code is provided with any WinpkFilter license except trial.
Yes, I understand what you are doing. However, there should be no problem to indicate any custom generated packets to MSTCP (actually there is no difference in reinjecting filtered packet or injecting new packet, both are done with one function). So the problem can be only in the packet itself.
In general the idea is correct and it should work. Only one note, setting m_PacketBuffer.m_dwDeviceFlags is not necessary, this field is used only when you read packets to distinguish incoming and outgoing ones, but it is ignored when you send packets.
Probably your RST packet is somehow wrong, in order to check this let you application to send SYN packet to the system which has not the requested port opened and capture resulting RST packet by sniffer. Then do the same with your WinpkFilter application running and compare the generated RST packet with captured one to find the difference.
This is just a sample, but you can define them as below:
string sought = “sex”;
string replacement = “foo”;plz also clear my doubt that can i store the return value into another PINTERMEDIATE_BUFFER buffer and then RecalculateTCPChecksum by passing the new buffer. plz solve my problem
I’m not sure I understand your problem here. The function I have provided recalculates checksum for the modified packet. If you want to copy the packet then just copy INTERMEDIATE_BUFFER structure but I can’t find any good reason whay you may need this…
This is MAC 802.3 Header Size:
#define ETHER_TYPE_LENGTH 2
#define ETHER_ADDR_LENGTH 6
#define MHdrSize (2*ETHER_ADDR_LENGTH + ETHER_TYPE_LENGTH )But I will buy the source anyway, because I need a customized device-object-name.
Just FYI: If you order Developer license you can request free custom build with costomized device-object-name.
By the way: ICMP is also diffcult to catch by a TDI-filter.
Yes this is correct, however PING request an example can be intercepted by filter over the DeviceIp.
There is no way to determine PID at the NDIS level, and actually some packets have not associated PID (packets destined to other systems which to be routed and packets generated by TCP/IP stack ARP, IGMP and others).
The only way to match packet against process is having LSP or TDI filter driver and keeping active connections table with associated PIDs. However, I should also note that LSP can be bypassed by direct acess to the TDI and itself TDI not always called in the correct process context (but it is in the most cases).
Tha depends of what do you mean under readable form. Packet itself is an array of bytes and not all of them have a printable representation. If you take any network sniffer it will parse packet headers and will show you binary dump of the packet and string representation of each byte (if it is printable, otherwise it will be substituted with “.”). Is this is the readable form you’d like to get?
Sorry but I can’t advise because I have not enough informaton. You are right, packet is not a PRINTABLE string but this is a BINARY string and if there is a SEX word on the web-page then it’s ASCII codes should be in that string.
As for the header, you should pass the header prior seeking the word (the code I have posted seeks the word starting from the TCP payload so it can’t modify the header).
You should use something like the code below. Also if modify IP header you should recalculate IP checksum, if modify UDP packet you should recalculate UDP checksum…
VOID
RecalculateTCPChecksum (
PINTERMEDIATE_BUFFER pPacket
)
{
tcphdr_ptr pTcpHeader = NULL;
unsigned short word16, padd = 0;
unsigned int i, sum = 0;
PUCHAR buff;
DWORD dwTcpLen;
iphdr_ptr pIpHeader = (iphdr_ptr)&pPacket->m_IBuffer[sizeof(ether_header)];
// Sanity check
if (pIpHeader->ip_p == IPPROTO_TCP)
{
pTcpHeader = (tcphdr_ptr)(((PUCHAR)pIpHeader) + sizeof(DWORD)*pIpHeader->ip_hl);
}
else
return;
dwTcpLen = ntohs(pIpHeader->ip_len) - pIpHeader->ip_hl*4;//pPacket->m_Length - ((PUCHAR)(pTcpHeader) - pPacket->m_IBuffer);
if ( (dwTcpLen/2)*2 != dwTcpLen )
{
padd=1;
pPacket->m_IBuffer[dwTcpLen + pIpHeader->ip_hl*4 + sizeof(ether_header)] = 0;
}
buff = (PUCHAR)pTcpHeader;
pTcpHeader->th_sum = 0;
// make 16 bit words out of every two adjacent 8 bit words and
// calculate the sum of all 16 vit words
for (i=0; i< dwTcpLen+padd; i=i+2){
word16 =((buff<<8)&0xFF00)+(buff[i+1]&0xFF);
sum = sum + (unsigned long)word16;
}
// add the TCP pseudo header which contains:
// the IP source and destination addresses,
sum = sum + ntohs(pIpHeader->ip_src.S_un.S_un_w.s_w1) + ntohs(pIpHeader->ip_src.S_un.S_un_w.s_w2);
sum = sum + ntohs(pIpHeader->ip_dst.S_un.S_un_w.s_w1) + ntohs(pIpHeader->ip_dst.S_un.S_un_w.s_w2);
// the protocol number and the length of the TCP packet
sum = sum + IPPROTO_TCP + (unsigned short)dwTcpLen;
// keep only the last 16 bits of the 32 bit calculated sum and add the carries
while (sum>>16)
sum = (sum & 0xFFFF)+(sum >> 16);
// Take the one's complement of sum
sum = ~sum;
pTcpHeader->th_sum = ntohs((unsigned short)sum);
}You should do something like the code below does, but don’t forget to recalculate TCP checksum after doing this:
PINTERMEDIATE_BUFFER ParsePacketHeaders ( PINTERMEDIATE_BUFFER pBuffer )
{
ether_header_ptr pEthernet = (ether_header_ptr)&pBuffer->m_IBuffer;
if(ntohs(pEthernet->h_proto) == ETH_P_IP){
iphdr_ptr pIp = NULL;
tcphdr_ptr pTcp = NULL;
pIp = (iphdr_ptr)&pBuffer->m_IBuffer[MHdrSize];
//printf("%i", MHdrSize);
UCHAR IpProto = pIp->ip_p;
if(IpProto == IPPROTO_TCP){
pTcp = (tcphdr_ptr)(((PUCHAR)pIp) + sizeof(DWORD)*pIp->ip_hl);
in_addr IP = pIp->ip_src;
PUCHAR pTcpData = (PUCHAR)pTcp + pTcp->th_off*4;
if(ntohs(pTcp->th_sport) == 80){
string foo = (char *)pTcpData;
while(foo.find("sex") != string::npos){
foo.replace(foo.find(sought), sought.size(), replacement);
}
const char* final = foo.c_str();
memcpy(pTcpData, final, foo.length());
printf("Dest Data: %snAddress of pTcpData: %x", pTcpData, &pTcpData);
}//port 80?
}//tcp??
} //IP Packet?
return pBuffer;
}The command line should be “PacketSniffer 1 -promisc” but not “PacketSniffer index 1 -promisc”. Also are you sure that there are packets available from interface with index 1? Usually (for Windows 2000/XP/2003) this is dial-up interface (NDISWANIP) for which there is no sense to use promiscuous mode (it is point-to-point connection), and it can evemn affect interface normal functionality.
