Forum Replies Created
-
Posts
-
Вот типовой HTTP GET пакет. Где искать URL видно вполне наглядно. Детали смотри в спецификации HTTP.
00000000 00 15 E9 76 C3 A0 00 16 E6 5C CA A8 08 00 45 00 ...v.........E.
00000010 03 66 3C C2 40 00 80 06 9E A3 C0 A8 01 65 40 FB .f<.@........e@.
00000020 19 24 43 FF 00 50 D1 1A 24 E5 1D 0E F2 A5 50 18 .$C..P..$.....P.
00000030 FF FF 1F 85 00 00 47 45 54 20 2F 20 48 54 54 50 ......GET./.HTTP
00000040 2F 31 2E 31 0D 0A 48 6F 73 74 3A 20 77 77 77 2E /1.1..Host:.www.
00000050 6E 74 6B 65 72 6E 65 6C 2E 63 6F 6D 0D 0A 55 73 ntkernel.com..Us
00000060 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C er-Agent:.Mozill
00000070 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73 3B 20 a/5.0.(Windows;.
00000080 55 3B 20 57 69 6E 64 6F 77 73 20 4E 54 20 35 2E U;.Windows.NT.5.
00000090 31 3B 20 72 75 3B 20 72 76 3A 31 2E 38 2E 31 2E 1;.ru;.rv:1.8.1.
000000A0 33 29 20 47 65 63 6B 6F 2F 32 30 30 37 30 33 30 3).Gecko/2007030
000000B0 39 20 46 69 72 65 66 6F 78 2F 32 2E 30 2E 30 2E 9.Firefox/2.0.0.
000000C0 33 0D 0A 41 63 63 65 70 74 3A 20 74 65 78 74 2F 3..Accept:.text/
000000D0 78 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F xml,application/
000000E0 78 6D 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F xml,application/
000000F0 78 68 74 6D 6C 2B 78 6D 6C 2C 74 65 78 74 2F 68 xhtml+xml,text/h
00000100 74 6D 6C 3B 71 3D 30 2E 39 2C 74 65 78 74 2F 70 tml;q=0.9,text/p
00000110 6C 61 69 6E 3B 71 3D 30 2E 38 2C 69 6D 61 67 65 lain;q=0.8,image
00000120 2F 70 6E 67 2C 2A 2F 2A 3B 71 3D 30 2E 35 0D 0A /png,*/*;q=0.5..
00000130 41 63 63 65 70 74 2D 4C 61 6E 67 75 61 67 65 3A Accept-Language:
00000140 20 72 75 2D 72 75 2C 72 75 3B 71 3D 30 2E 38 2C .ru-ru,ru;q=0.8,
00000150 65 6E 2D 75 73 3B 71 3D 30 2E 35 2C 65 6E 3B 71 en-us;q=0.5,en;q
00000160 3D 30 2E 33 0D 0A 41 63 63 65 70 74 2D 45 6E 63 =0.3..Accept-Enc
00000170 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 64 65 66 6C oding:.gzip,defl
00000180 61 74 65 0D 0A 41 63 63 65 70 74 2D 43 68 61 72 ate..Accept-Char
00000190 73 65 74 3A 20 77 69 6E 64 6F 77 73 2D 31 32 35 set:.windows-125
000001A0 31 2C 75 74 66 2D 38 3B 71 3D 30 2E 37 2C 2A 3B 1,utf-8;q=0.7,*;
000001B0 71 3D 30 2E 37 0D 0A 4B 65 65 70 2D 41 6C 69 76 q=0.7..Keep-Aliv
000001C0 65 3A 20 33 30 30 0D 0A 43 6F 6E 6E 65 63 74 69 e:.300..Connecti
000001D0 6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A on:.keep-alive..
...
Изначально я понял задачу несколько по другому: нужно сохранить копию некого файла, который другое приложение скачивает. Если речь о том чтобы из IM драйвера скачать файл по HTTP, то придется реализовать TCP/IP стек + HTTP протокол. Вместо реализации собственного TCP/IP можно использовать TDI оригинального стека, но HTTP писать придется по любому.
Весь сетевой трафик идет через IM драйвер, в том числе пойдут и данные скачиваемого файла. Правда построить файл из данных пакетов будет не просто, придется пропарсить TCP/HTTP заголовки и выделить данные принадлежащие файлу. По поводу парсинга заголовков копай в сторону сетвых сниферов в исходниках…
IP fragmentation does not cares about upper protocols, so only first fragment of the fragmented TCP packet has a TCP header. You should buffer fragments by IP ID, not by TCP sequence number and so on…
I would advise to look through some good book devoted TCP/IP protocols before trying to implement something like this. You definitely need better understanding of the networking basics. I would recommend Richard Stevens books (TCP/IP Illustrated), but ofc this is not the only option.
I gather the answer is “no”. WinpkFilter is just a way to enable me to easily add such code. True??
Yes, thats right.
Well, WinpkFilter was designed mainly for packet filtering solutions but not for spoofing. Interface functions for sending packets are designed as non-blocking for better performance and sending packets through the WinpkFilter at the rate above the network bandwidth causes packet loss (this caused by network limits, not the WinpkFilter internal queue size). Basically you can change your application to send packets on some fixed realistic rate to avoid packet loss. This can be implemented with a waitable periodic timer, which callback routine would calculate time passed since last fireup and how many data should be passed during this time at the given rate. Then send calculated amount of data on the network and requeue the timer. Such approach will allow you to send packets on the network at a given rate which should be chosen below the real network bandwidth.
payload Correct for TCP packet, for UDP an example it would be
payload and so on…
Is this ethernet checksum (http://folk.uio.no/od/tcp-ip-intro/subsection3_2_3.html) something which I need to care about (in addition to the length / checksum fields in the other headers)? Or is this computed automatically?
It is hardware checksum and you won’t even see it on NDIS level.
Unfortunately it is not so easy, as there may be many ethernet packets for each TCP/IP packet.
Well, yes, IP packet can be fragmented and you may have to gather all fragments before processing the packet. However, fragmented IP packets are rather rare in modern networks, also these packets are recommended to be blocked by firewalls. Basically, I don’t think you will ever meet fragmented TCP packet, but it is still possible to generate fragmented ICMP or UDP packets.
Can I implement this with WinpkFilter? Is there a better way?
Am I missing something in the walkthrough provided above?
How do I buffer multiple ethernet packets and (after processing) send them to their intended destination using WinpkFilter? I know how it works for one packet at a time, but what about multiple?In general the approach is correct. Sending multiply packets does not differ from sending a single one.
Basically TDI is above NDIS, but some events logged by TDI filter upon completion, an example in case of sending an outgoing packet TDI filter will pass this packet to NDIS, get the return status and log it after this. So you got packet from NDIS before than from TDI.
Well, the problem is that Cisco VPN client is also utilizes NDIS hooking approach to making network filter driver. As soon as there is no standard for these drivers conflicts are always possible. We will check if we can do anything about it, thanks for reporting.
i take a look at your TDI driver, but it can only monitor ip packets or block packets which match a rule….i want to decide it self…if the packet can pass the TDI-System
is it possible to tunnel packets like your NDIS driver…..
Possible but the driver should be changed for this.
can you help me to find a solution to attach a packet to his process ??
Another option is a Layered Service Provider (LSP), you can read more in MSDN.
@ulli-um wrote:
hi,
what is the reason for the most desktop firewalls to add a combination of NDIS and TDI ?
To get the proccess id which is the packet from??Yes, thats right.
You can find the TDI filtering solution here http://www.ntkernel.com/w&p.php?id=8
Packets can’t bypass NDIS layer, but if you want an application context you need something like TDI filter. Most of the desktop firewalls on the marker is a combination of NDIS and TDI/LSP filters.
Driver code and data are located in non paged memory by default. Though, you can make parts of your driver pageable with a special compiler directives.
