Forum Replies Created
-
AuthorPosts
-
and,at the first,the filter buffers had fixed the total size. when reached the end of the size(the last filter buffer),how could be add more filter rules? to “new” a new buffer and join with the old buffer?
If you look at the definition below _STATIC_FILTER_TABLE can contain any number of filters (ANY_SIZE is defined as 1) specified in the m_TableSize. Of course you got to have enough free kernel memory to keep large table.
typedef
struct _STATIC_FILTER_TABLE
{
unsigned long m_TableSize; // number of STATIC_FILTER entries
STATIC_FILTER m_StaticFilters[ANY_SIZE];
}STATIC_FILTER_TABLE, *PSTATIC_FILTER_TABLE;
The best available code signing walkthrough from Microsoft:
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx
I’ll try to find some time to rebuild VirtNet for x64.
SSL encryption is implemented in user mode above winsock layer, so there is no way for the driver to intercept unencrypted data.
Interception of unencrypted data is still possible, but very specific for the particular application. Some of the application use Microsoft SSL crypto provider implemented in secur32.dll and in order to intercept unencrypted data you have to inject your own DLL into the target process and hook SPI functions between application and secur32.dll:
InitializeSecurityContext
AcceptSecurityContext
DecryptMessage
EncryptMessage
DeleteSecurityContextAnother possibility commonly used in Windows is OpenSSL library, the solution is similar but another set of functions has to be hooked. Custom SSL libraries or another methods of traffic encryption may require different methods.
Create blockpage packet with all current headers, add unicode string of html, change IP length, change seq and ack, recalculate checksums and send packet to adapter.
Instead I would do the following:
1) Wait for a response packet from WWW-server
2) If HTTP response packet contains a censored word then modify HTTP packet to contain a redirect packet like:<html> <head> <META HTTP-EQUIV="Refresh" CONTENT="0;URL=http://www.censored.com/"> </head> <body> </body> </html>
This simple redirect packet in most cases will be smaller in size than HTTP server response and you can add padding string between to exactly match the size of the original packet. This way you won’t need to affect SEQ/ACK fields, just recalculate TCP checksum.
LSP sample is available in WIndows SDK. Personally I don’t like LSP, its implementation in Windows wishes better.
Transparent local proxy? If you can’t intercept application network activity on the TDI level then probably mentioned antiviruses use Layered Service Provider (LSP) to redirect the connection to the local proxy and thus it does reach TDI only from the name of local proxy, not in the context of the calling application. If this is really so you have to create your own LSP and layer it just above AV LSP to get connection first.
The problem is some routers have been configure to block most protocols except TCP taffic.
In this case you may want to tunnel packets inside the SSL stream over TCP. An example, this method is used in http://www.projectloki.com VPN solution.
I do realize that using a common protocol like IPSEC may get me through the router, but it may confuse traffic as well. My encryption solution is disruptive and does not fall into the normal encryption schema.
Why not to use GRE tunneling then? Routers usually pass GRE and even may NAT if you use extended GRE header.
Why do you want to add/change IP options? If you want to add extra encryption related information to the packet there are other possibilities.
First of all I would recommend to use one of the known protocols to tunnel encrypted packets. There are several options and all of them will be successfully processed by routers:
1) IPSEC ESP protocol
2) GRE
3) IP-in-IP
4) IP-in-UDPAs an example you can look at the GRETunnel sample from WinpkFilter samples set. It does not actually encrypt the tunneled packet but it is fairly simple to add encryption. If you need to have an extra information attached to the packet you can also use extended GRE.
WinpkFilter hooking driver does not work with IPv6 and IPsec?
WinpkFilter hooking driver intercepts only TCPIP.SYS (IPv4) and ignores other protocols (it can be changed if needed). As soon as IPv6 is available only since Wndows XP I don’t see a problem to use NDIS IM driver instead NDIS hooking one for Windows XP and higher.
As for IPSec, as I have already told that depends from implementation, if WinpkFilter is above IPSec you will capture unencrypted packets and you will capture encrypted ones otherwise.
WinpkFilter NDIS IM driver is suitable for filtering IPv6. As for IPSec, it is actually depends from the particular implementation (WinpkFilter driver can be installed below or above IPsec driver).
i mean “IP header compression”–> RFC 2507(ftp://ftp.isi.edu/in-notes/rfc2507.txt)
If here you mean to use Windows built-in IP header compression for dial-up links then I think it is implemented below the WinpkFilter (inside of NDISWAN.SYS), so it should not interfere with the changes you do to the packet and its IP header.
What do you actually mean under “IP header compression”? RFC 2507(ftp://ftp.isi.edu/in-notes/rfc2507.txt)? Or some sort of your custom protocol compression?
For the majority of Internet users it is enough to use one the Stealth modes to be fully protected from external attacks. TCP stateful inspection is mostly important for server systems.
-
AuthorPosts