Home › Forums › Discussions › General › Filtering packets by a process, in the WinpkFilter
- This topic has 2 replies, 2 voices, and was last updated 4 weeks ago by BrianC.
-
AuthorPosts
-
September 12, 2024 at 1:49 pm #13885
Hi, I’m currently using WinpkFilter for capture packets, and it works fine with filters and so on. But I decided to implement some kind of packets filtering by a specific process. And after 3 days of researching and trying different approaches, like WFP Calluots, ETW (Windows Event Tracing), also WinAPI (GetExtendedTcpTable) and others… – I’m here, again 🙂
And I found, in the socksify project you are actually using the GetExtendedTcpTable() approach. So, is it actually the best one for that needs or maybe there is some better? For example, WFP Callouts look nice but it requires kernel-mode for events like Connect and others, which is not really good for a such trivial task like just save process info for the IP connection…
So I would like to hear from the real expert, what is the best approach to filter traffic by a process with using WinpkFilter.
September 12, 2024 at 4:35 pm #13886The approach largely depends on the context. In general, if you need to work with a process context in the kernel driver, using WFP call-outs makes sense as they provide a more direct way to filter traffic based on process information at the kernel level. However, for user-mode operations, the overhead introduced by GetExtendedTcpTable() is similar to what you would encounter if you implemented the same functionality via a kernel driver.
So, if you’re aiming for a user-mode solution without the complexity of working in kernel mode, GetExtendedTcpTable() is a reasonable choice. But if you’re okay with working in the kernel and need tighter control, WFP call-outs would offer more flexibility and direct access to connection events like Connect and others.
September 12, 2024 at 9:43 pm #13889Thank You for response. And I was thinking about the same. User mode is good for me because I’m not that good in kernel programming, even simply things are not simply in this kind of programming. Also two drivers in one application does not sound good for me 🙂 And installing a driver for only getting process connects information is a bit overhead I think.. So if for the user-mode there is nothing better than using Api, GetExtendedTcpTable – then I will build my logic on this approach.
Thanks for help.
- This reply was modified 4 weeks ago by BrianC.
-
AuthorPosts
- You must be logged in to reply to this topic.