c# - 如何在不依赖 WinPCap 的情况下嗅探应用程序中的数据包?
背景:我现在了解了如何编写一个 C# 应用程序,该应用程序可以监视进出该应用程序所在 PC 上网卡的数据包。我知道的方法依赖于已安装在 PC 上的 http://www.winpcap.org/,但是,然后我使用 C# 包装器,例如 http://pcapdotnet.codeplex.com/ 或 http://sourceforge.net/projects/sharppcap/ 。
问题:但是,我的问题是,我需要做什么才能拥有一个可以嗅探不需要预安装第 3 方应用程序/驱动程序的数据包的 C# 应用程序?
澄清:也就是说,我确实想要我当前拥有的应用程序,但不需要我告诉用户必须先下载/安装 XYZ,然后才能使用该应用程序。出于该问题的目的,假设也不允许自动下载和安装第 3 方应用程序/驱动程序。 (对于 WinPCap,我不确定您是否可以将其捆绑在一起,但不幸的是,我相信无论如何您都不应该这样做)
谢谢
BACKGROUND: I now understand how to write a C# application that can monitor packets going in/out of the network card on the PC the application is running on. The approach I know relies on http://www.winpcap.org/ being already installed on the PC however, and then I use a C# wrapper such as http://pcapdotnet.codeplex.com/ or http://sourceforge.net/projects/sharppcap/ .
QUESTION: My question however, what would I need to do to be able to have a C# application that can sniff packets that does NOT require a 3rd party application/drivers to be pre-installed?
CLARIFICATION: That is I really want the application I currently have but without any requirement for me to tell the user to have to go and download/install XYZ prior to being able to use the application. For the purpose of the question assume that automating the download and install of a 3rd party application/drivers is not allowed either. (with WinPCap I'm not sure if you can bundle it, however I believe you're not supposed to in any case unfortunately)
thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
就我个人而言,我会坚持使用 WinPCap。但既然您问了,就可以使用以下代码从网络中嗅探数据包以启用原始套接字。
完成此操作后,您可以使用 Socket.Receive 或 Socket.BeginReceive 读取原始 IP 数据包。
Personally I would stick to WinPCap. But since you asked, it is possible to sniff packets from the network using for the following code to enable raw sockets.
Once this is done, you can use
Socket.Receive
orSocket.BeginReceive
to read the raw IP packets.有一种方法可以仅使用标准的winsocks 实现来捕获.NET 上的传入/传出数据包。我看过一个博客,其中包含如何操作的示例,但我不再有链接了。
长话短说,这是一个极端的边缘情况,因为这不是winsocks(标准Windows网络驱动程序)的目的。
Pcap 通常需要捕获数据包的原因是,它使用自己的 NDIS 网络驱动程序来解锁 NIC 的全部功能。最重要的是,它还提供了一种简单的方法来设置过滤器以限制在指定接口上捕获的数据包数量。
IE,驱动程序将在内核级别而不是用户模式级别忽略特定类型的数据包。因此,您将能够更有效地过滤数据包并在网络负载较大的情况下进行捕获。
在.NET中,要过滤数据包,您需要提供自己的应用程序层数据包过滤方案,但效率会低得多。
Windows 出于“安全原因”阻止对非标准协议的访问,因此它们并不真正支持使用原始数据包进行网络(即使可能存在代码使其成为可能)。 RAW 数据包始终用于研究新协议的设计,而不是一般用途。
出于所有这些原因,选择 Winpcap 和针对您的特定语言的包装器来实现任何类型的捕获应用程序通常是一个好主意。
注意:我个人更喜欢 SharpPcap,但当我在该项目上进行开发时,我也有偏见。 Pcap.net 在捕获方面的实现非常相似,主要在数据包的解析方式上有所不同。
There is a way to capture incoming/outgoing packets on .NET using just the standard winsocks implementation. I've seen a blog with example of how but I don't have the link anymore.
Long story short, it's an extreme edge case because that's not what winsocks (the standard windows networking driver) was intended for.
The reason Pcap is usually necessary to capture packets is, it uses its own NDIS networking driver that unlocks the full capabilities of your NIC. On top of that, it also provides an easy way to set filters to limit the amount of packets being captured on the specified interface.
IE, the driver will ignore packets of a specific type at the kernel level instead of the usermode level. Therefore, you'll be able to filter packets much more efficiently and capture under larger loads on the network.
In .NET, to filter packets, you'd need to provide your own application layer packet filtering scheme that would be much less efficient.
Windows blocks access to non-standard protocols for 'security reasons' so they don't really support the use of RAW packets for networking (even though code may exist to make it possible). RAW packets were always intended for researching the design of new protocols, not general use.
For all of those reasons it is usually a good idea to pick up Winpcap and a wrapper for your specific language to implement any type of capturing application.
Note: I personally prefer SharpPcap, but I'm also biased as I do development on the project. Pcap.net is very similar in its implementation when it comes to capturing, it mainly diverges when it comes to how packets are parsed.