嗅探原理和工具编写及使用(2)

sunxufei:
哦，交换机是以MAC地址进行交换的，不是IP那一层的，要IP已经路由器了
现在交换机便宜了，因此以后你想用sniffer抓密码概率不大了，不过还能多公司仍然是交换机和H
 

UB一起用的，这样小范围内是有效地，至于ADSL CABLE FTTB,我的FTTB是用华为设计的设备

,呵呵,不仅仅工网IP,只有我和交换机两个MAC(这次中国人干的不错),没希望找到第三者,很安全,但

不都这样安全,很多人的网络还是很糟糕的.
很多加密协议可以用来提高安全性,但老的POP3,SMTP,HTTP,FTP这种协议应用广泛,不可能在短

时间内完全取代,而且加密也是有待价的,所以对于要求较高的场合,才会加密.
不过sniffer不是给大家偷密码用的,我当初用来学习网络,看看包的样子,后来就用来当作网管工具,

分析网络的健康与否,其实这样的话,你知道,很有可能sniffer就是接在我需要探测的网络上,听诊器

吗,到处都听听,呵呵,因此即使用了交换机,sniffer仍然是有用处的,但不是抓密码!!
Wincap很简单,大3的学生不要怕,去他的网站看看,有例子的,VC6编译,BCB也行的,把lib的格式转

换一下,不过写这种程序,你最好先熟悉协议,很多协议在linux里有现成的源代码,主要是一些struct

吧,移植时注意VC可不是gcc,有些c的高级语法,编译选项要注意,否则差一个byte你就得不到正确的

结果.
如果你搞不到sniffer,Win2000 Server也有网络包查看器的,不比sniffer强大,但简单的东西入手

也快.
反嗅探和嗅探技术其实很old了,呵呵,不过CSDN经常old的.
注意不要干坏事,有矛必有盾

sevencat:
网卡的混杂模式好像要通过NDIS设置。
下面是转贴的。
哪位UP一下，我来贴完。
一、驱动开发网
作者：gjpland
看到很多仁兄提供的数据包的拦截技术，其中最多的是编写IM DRIVER在NDIS中间层
对MINIPORT（网卡驱动程序）和协议驱动程序之间的数据包进行拦截。这是微软提供的一种技术
但编写该过滤程序拦截程序非常的复杂，安装也很麻烦。

本人简单的介绍一种更有效的基于NDIS包拦截技术。

大家都知道，NDIS协议驱动程序是通过填写一张NDIS_PROTOCOL_CHARACTERISTICS的表

，并调用NDIS API
函数NdisRegisterProtocol进行注册。现在我们来关注一下NDIS_PROTOCOL_CHARACTERI

STICS这张表，
这张表中存有所有协议驱动程序与底层的派发函数的入口。如SendHandler,ReceiveHandler,Bi

ndAdapterHandler等，
当网卡有数据包进入时，会通过表中ReceiveHandle 或ReceivePacketHandler通知协议驱动程

序有一个该协议
的数据包进入，反之协议驱动程序是通过SendHandler或SendPacketsHandler函数向网卡驱动

发送数据包到网络
上去的，有人会奇怪程序中明明不是调用NdisSend或NdisSendPackets函数发送的吗？没错，

是这样的，
但是你可以看一下NDIS.H的头文件里对这两个函数的定义就知道了，他们都是一个
宏定义，实际还是通过这表中SendHandler或SendPacketsHandler发送的。

现在我们所要做的事情应该很清楚了，只要我们能够将每一个协议程序所填写的NDIS_PROTOCO

L_CHARACTERISTICS
表里的派发函数指向自己的函数,我们就能成功的对数据包进行拦截。那么每个协议驱动程序的这张

表到底存放在
那里呢？太简单了，看一下下面的我对NdisRegisterProtocol重新给出的原型就很明白了。

struct _NDIS_PROTOCOL_BLOCK
{
PNDIS_OPEN_BLOCK OpenQueue; // queue of opens for this protocol
REFERENCE Ref; // contains spinlock for OpenQueue
UINT Length; // of this NDIS_PROTOCOL_BLOCK struct
NDIS50_PROTOCOL_CHARACTERISTICS ProtocolCharacteristics;// handler

addresses

struct _NDIS_PROTOCOL_BLOCK * NextProtocol; // Link to next
ULONG MaxPatternSize;
#if defined(NDIS_WRAPPER)
//
// Protocol filters
//
struct _NDIS_PROTOCOL_FILTER * ProtocolFilter[NdisMediumMax+1];
WORK_QUEUE_ITEM WorkItem; // Used during NdisRegisterProtocol to
// notify protocols of existing drivers.
KMUTEX Mutex; // For serialization of Bind/Unbind requests
PKEVENT DeregEvent; // Used by NdisDeregisterProtocol
#endif
};
typedef struct _NDIS_PROTOCOL_BLOCK NDIS_PROTOCOL_BLOCK,

*PNDIS_PROTOCOL_BLOCK;

EXPORT
VOID
NdisRegisterProtocol(
OUT PNDIS_STATUS Status,
OUT PNDIS_PROTOCOL_BLOCK NdisProtocolHandle, /*注意NDIS_HANDLE所指向的

就是PNDIS_PROTOCOL_BLOCK的结构，不要有什么怀疑。*/
IN PNDIS_PROTOCOL_CHARACTERISTICS ProtocolCharacteristics,
IN UINT CharacteristicsLength
);

NDIS_PROTOCOL_BLOCK（协议表)

是NDIS维护所有系统中已注册协义的单向链接表。字段NextProtocol指向下一个协议表。
庆幸的是，当我们注册一新的协议时，NDIS总是会把新注册的协义放在链表的头并返回这张表，

所以只要我们注册一个新的协议
通过新协议注册返回的链表头就可以轻而易举的遍历系统中所有协议表.现在我们所希望得到的每个

协议的
NDIS_PROTOCOL_CHARACTERISTICS表就放在我们面前了，如何勾挂表中的派发函数，我

想不必多说了吧。顺便说一句
NDISREGISTERPROTOCOL为NDIS_PROTOCOL_BLOCK所分配的内存是NonPagedPool

类型的。对于核心DRIVER来说，核心区内存
是一个线性的内存区，所有核心DRIVER是可以随便访问核心内存区的任意地址。所要注意的是不

同IRQL级别下对分页
和非分页内存。

有人会问这样就行了吗？真的拦截下来了吗？如果有那位仁兄心急现在就写程序的话，
准会失望的，因为他会发现结果什么东西都没拦截到或偶而会拦截到一些数据包。为什么？
因为NDIS网卡驱动和协议驱动在发送和接收到数居时并不是调用PNDIS_OPEN_BLOCK->Proto

colCharacteristics
里的派发函数。怎么办？
有必要先介绍一下NDIS网卡驱动和协议驱动之间是如何BINDING 的吧，
NdisRegisterProtocol在注册完一个协议后，不久NDIS会通过调用表中
BindAdapterHandler派发函数，通知协议对每一个网卡进行BINDING。或者当系统通PNP找到

一块新的网卡时
也会调用BindAdapterHandler对协议进行BINDING。协议在BINDING 调用里，会根据自己的

需要使用NdisOpenAdapter
将自身绑定到适合的网卡。并返回NdisBindingHandle.NdisBindingHandle是什么？NdisBin

dingHandl其实是
指向NDIS_OPEN_BLOCK表的一根指针，那么NDIS_OPEN_BLOCK表有什么用呢？当协议顺

利的绑定后，每个绑定的网卡
和每一个协议之间建立了数据传输的通道，而NDIS_OPEN_BLOCK就是用来维护这一数据通道的

表。
struct _NDIS_OPEN_BLOCK
{
PNDIS_MAC_BLOCK MacHandle; // pointer to our MAC
NDIS_HANDLE MacBindingHandle; // context when calling MacXX funcs
PNDIS_ADAPTER_BLOCK AdapterHandle; // pointer to our adapter
PNDIS_PROTOCOL_BLOCK ProtocolHandle; // pointer to our protocol
NDIS_HANDLE ProtocolBindingContext;// context when calling ProtXX funcs
PNDIS_OPEN_BLOCK AdapterNextOpen; // used by adapters OpenQueue
PNDIS_OPEN_BLOCK ProtocolNextOpen; // used by protocols OpenQueue
PFILE_OBJECT FileObject; // created by operating system
BOOLEAN Closing; // TRUE when removing this struct
BOOLEAN Unloading; // TRUE when processing unload
BOOLEAN NoProtRsvdOnRcvPkt; // Reflect the protocol_options
NDIS_HANDLE CloseRequestHandle; // 0 indicates an internal close
KSPIN_LOCK SpinLock; // guards Closing
PNDIS_OPEN_BLOCK NextGlobalOpen;

//
// These are optimizations for getting to MAC routines. They are not
// necessary, but are here to save a dereference through the MAC block.
//
SEND_HANDLER SendHandler;
TRANSFER_DATA_HANDLER TransferDataHandler;

//
// These are optimizations for getting to PROTOCOL routines. They are not
// necessary, but are here to save a dereference through the PROTOCOL block.
//
SEND_COMPLETE_HANDLER SendCompleteHandler;
TRANSFER_DATA_COMPLETE_HANDLER TransferDataCompleteHandler;
RECEIVE_HANDLER ReceiveHandler;
RECEIVE_COMPLETE_HANDLER ReceiveCompleteHandler;

//
// Extentions to the OPEN_BLOCK since Product 1.
//
RECEIVE_HANDLER PostNt31ReceiveHandler;
RECEIVE_COMPLETE_HANDLER PostNt31ReceiveCompleteHandler;

//
// NDIS 4.0 extensions
//
RECEIVE_PACKET_HANDLER ReceivePacketHandler;
SEND_PACKETS_HANDLER SendPacketsHandler;

//
// More NDIS 3.0 Cached Handlers
//
RESET_HANDLER ResetHandler;
REQUEST_HANDLER RequestHandler;

//
// Needed for PnP
//
UNICODE_STRING AdapterName; // Upcased name of the adapter we are bound to
};

上面的表结构可以很清楚的看到这张表是一个单向链接表，并且存放了和PNDIS_OPEN_BLOCK-

>ProtocolCharacteristics
一样的数据收发派发函数，当第N块网卡发送数据包到第N个协议时，就会调用第N个协议与第N个

网卡之间建立的
ND