我在驱坛生涯的回忆(包含NDIS架构简述)

by monkeyy 2003-11-29深夜
这篇文章是因为花猫所写的《病毒的本质》这篇文章的触动，让我有了写下自己在驱坛所有感悟的冲动，但是又愿意在那儿做一个荒唐的独白或者是弱智般的宣读教义，所以就写下了自己关于NDIS结构的理解。也包含一点Windows网络组件的结构，但是不多，这个东西太庞大了，就是写一本书也不足为过。为防止有的人觉得很无聊和浪费时间，我告诉大家下面的文字大约有5000字左右。不过关于NDIS架构的描述还是值得你去看看，至少到今天我还没有看到任何关于NDIS架构的文章，如果你有自己的心得，我们的交流将会让我们彼此有所进步，何乐而不为呢？下面就是我写下的文字：

都说人能记得住第一次，并且是一生难忘。我却忘了自己写的第一个程序，写的第一个NDIS驱动，甚至第一次与别人合作别人研究技术。大学四年在我的身上本来有太多的第一次，可是我都忘了，忘的干干净净，记住这些第一次有什么意义呢？人总会去踏出第一步，这一步并不是成功，而是你为了实现成功的第一步。人总是需要去超越自己的环境，自己的背景，不然怎么能算成功呢？或者这就是所谓的酸葡萄效应，我自身的弱智让我难以达到真正的成功，于是我开始这样阿Q起来。这样去讲又有什么意义呢，在乎别人的看法是重要的，但是用别人的观点来约束自己却是不可饶恕的！

驱坛的人也都匆匆的来去，已经不记得谁第一个走，只知道突然有一天胡老大很少露面了，GJP也很少露面了，NDIS版的斑竹只剩下了mikeluo。在驱坛注册是个偶然的机会，可这个机会却改变了我太多，而今我的头儿就是我在驱坛认识的一个网友。还记得那个时候为了查找在Windows下截获数据包的办法，看到很多的RAW Socket，终于在驱坛看到了NDIS这个名词，终于开始了自己的NDIS之旅。我２００１年６月在驱坛注册的，那个时候的驱坛可以说代表了我国Windows驱动界的最高水平，Huyuguang、Lu0、GJP等等这些高人几乎天天出没其间。从我第一次登陆驱坛到今天已经3个年头了，在驱坛的日子我一直很少说话，因为知道自己的实力，我一向厌恶误导别人，如果你没有十足的把握，那么你就应该标上讨论的字样，这样总不会有太多的贻害；所以自己一向很少开口。上大学的时候私下里和别人合作研究过技术，最后终于成为了不错的朋友，我仍然喜欢这种人与人的交往，哪怕从来没有见过面，只是在电话的这头听到过他的声音，哪怕自己做的一切都是没有报酬的，哪怕别人只是在电话那头说了一句“来北京，我一定好好请你吃顿饭”，这都无关紧要，我需要的仅仅是技术，而不是报酬。但是我仍然喜欢不多说话，可能有人要说是保守，实际上在Winsdows下进行NDIS驱动开发只要不使用微软反对的方法，一般没有什么高深的。如果你要研究一些Native的话，确实需要很高的技术，我想这个也就是GJP、Lu0、胡老大这些高人可以做了，所以自己也从来不去试图这样的研究。我同意花猫的话，编程需要的是资料和耐性。

我一直以为个人防火墙的检测技术急需更新，现今的个人防火墙检测技术已经无法应对个人网络安全了，怎么去更好的保密数据和系统的完整性已经是最重要的问题了。可是到今天我仍然没有看到天网、诺顿等等这些个人防火墙有什么举措，可能有人要说我狂妄。那么问问在NDIS版兄弟们，做一个天网需要的是什么，除了时间还有别的吗？无论它用NDIS还是TDI甚至是SPI，早就没有什么技术可言了，需要的仅仅是怎么去组合他们。软件只是一种工具，好的软件技术无法替代劣质的软件思想。象天网这样的防火墙纵然是使用TDI与NDIS的双层过滤，纵然是使用我们至今未能知道的NDIS HOOK技术又能怎么样呢？它能弥补它在检测模式上的弱智吗？不能，永远不能。可惜人们已经放弃了在个人防火墙上进行一次检测模式更新，完全放弃了。我仍然同意老莫的话，在网络安全中驱动开发是必须和很小的一部分，加、解密、认证、入侵检测等等才是真正需要掌握的！

说了这么多我并不是要评判什么，我也没有任何权利去干涉别人的工作和生活，就算是对现在才来到NDIS版的朋友们的一点意见吧，希望不会给你们造成太多的误导。

现在来写点东西吧，在网上关于NDIS的文章确实很多了，但是直到今天我还没有在国内的什么地方看到过关于NDIS架构的文章或者是Windows网络组件架构的文章(国外的很久没有去了，以前也没有看到过)。要写点东西还是写点不曾见到的吧，众所周知的文字翻来覆去的描写，除了助长自己嚣张的气焰和满足自己的虚荣可能就没有别的用处。

Windows网络组件的架构确实比较复杂，尤其是在应用太和核心太的交界处，为了实现Sokcet操作的接口统一、减少核心太与应用交互的麻烦与在文件系统中支持网络操作，这个接口做了很多复杂的处理，说起来真的是很繁，再加上在这个交界处我写过的测试程序很少，所以也就不再多言了，只是在下面给出一张Windows网络组件的结构图，这个图当初费了很大的工夫才画出来，画出来后的不久就在PCAUSA看到了，虽然有些出入，但是我相信自己在架构上的理解是没有错误的，那些测试程序给了我信心。
 
Windows网络组件体系结构
对于NDIS结构我觉得已经没有任何必要去谈Miniport或者是Protocol了，如果有疑问的话，就应用自己去找资料或者是看看DDK、MSDN的文档了，在网上关于这个的文字已经很多了。我个人认为对于NDIS结构的理解千万不要过于相信微软的文档，这就是我直到今天一个最大的心得，可以说微软关于NDIS架构的描述有误导的嫌疑。相反，当你自己搞清楚了WDM驱动，更确切的说是微软的驱动模型之后你就会发现，NDIS并不是一个和其它驱动不同的驱动，相反它们的本质结构是一致，不同之处只是因为网络驱动所需特性让微软在原来的驱动模型上做了一些修改，这就是NDIS架构的本质。下面就让我们从微软的误导开始来看NDIS的架构，其中也许存在着谬论，但是我想这样的谬论也还是值得一写的！J

1、关于IMD中Protocol与Miniport的关系，微软说他们是上下层次关系，初一看这明显是错误。从逻辑的角度看他们应该是并行关系，一个为TCP/IP协议送出数据，一个为TCP/IP协议接收数据。如果是上下关系，那这个数据怎么能够顺利的发送、接收呢？实际上在这里微软已经隐约的道出了NDIS架构的实质，但是由于缺乏足够的解释，在这里通常会给Developer们造成一种误导，觉得这个存在矛盾。

2、实际上微软说的并没有错，确实是上下结构，并且就是我们在Device Attach中看到的上下结构。但是在软件的数据流程上，它确实是并行的结构，它只是将原本一条数据通道根据方向的不同改成了两个通道。

3、最有意思的东西就要开始，NDIS同分层驱动模型没有任何的差别，而微软似乎一直在掩盖的东西，它的文档中没有任何关于这个的说明，除了上面提到的那个隐约的说法。以前大家常说的在IMD中存在反向绑定就是一个例子，实际上并不存在反向绑定，那个所谓的反向绑定是对Device Attach的另一种说法。
    要说清楚这个东西，我们就需要来说说真正的虚拟网卡与IMD中Miniport驱动的区别。在IMD中，当Protocol绑定到真正的网卡后会初始化一张虚拟的网卡让TCP/IP协议来绑定，可是我们都知道这个虚拟的网卡并不能在设备管理器中显示出来，我们并不能为它设置IP等等信息，而使用NdisIMRegisterLayeredMiniport这个东西就可以虚拟一张真正的网卡！为什么呢？因为在IMD中并没有建立什么真正的网卡设备，而只是为已经存在的网卡设备建立了一个设备实例，然后将这个实例Attach到真正的网卡设备实例上，这就是典型的Windows下的分层驱动模型。那么我们就应该想到为什么微软要这么做呢，为什么不象TDI或者是其它分层驱动那么直接Attach Device还有搞个Protocol这个东西。我想原因有二，一是为了不破坏NDIS架构的完整性，因为NDIS最基本的架构就是协议和小端口；二是为了保持网络驱动的特性。现在我们来看看网络驱动的特性，网卡设备不是简单的Device Object，因为Device Object是对设备的通用抽象，它无法表示网卡驱动特性。对一个网卡来说最重要的就是Interface概念，在应用程序中，通常不会去指定本地IP地址，比如你用JAVA或者.NET去连接某个主机，这个动作最终转化成Socket动作，Socket根据协议族类型来挑选WSH DLL，然后由WSH DLL负责和协议驱动进行交互，实际上解析Socket的动作是在WSH DLL中进行的。但是在多网卡、多IP的环境中，应用程序无法去选择使用哪个IP作为本地IP，因为它不知道任何的路由信息，所以它只能向协议驱动传送一个通配符地址，然后由协议驱动来选择本地IP和网卡。我想大家都知道了网卡驱动的特性了，那就是路由中关于Interface的问题。如果微软同意我们随意在网卡设备上的Attach Object，同时保持路由，那么整个路由部分将是十分的混乱，所以要开发可以配置IP等网络信息的虚拟网卡需要微软做特殊的处理。我以为这就是微软的工程师们为什么在IMD中并不实现真正的虚拟网卡的原因；主要是路由信息的混乱，IMD中Miniport本身只是一个网卡设备的实例，我们为它添加路由信息是不符合逻辑和无法想象。我们不得不承认微软的工程师在软件结构的设计上确实很厉害，在我看来Linux就要差许多了，至少我没有在Linux中看到任何这样的东西。

上面只是说了TCP/IP协议和网卡在NDIS中的问题，这也是目前我们开发中最常用到的地方，说到这里我突然想起了另一个问题。ATM承载IP网卡的驱动，现在世面上已经存在ATM承载IP的网卡了，它的技术难点又在哪儿呢？我曾经有幸肤浅地做过这样的事情，但不是很深入，只是略知一点点。他们的技术难点主要在于网卡设备类型的转换和具体协议相关动作解析上。ATM和Eternet是不同的网络类型，在数据链路层是完全不同的，那么我们如何将下端的ATM类型的网卡设备转化为以太网卡设备让TCP/IP来绑定，这个实现我一直没有机会去实验，因为没有ATM的网卡，但我觉得应该不是太难，不过这话仍然值得商榷。协议相关动作解析是比较困难和繁琐的事情，比如在ATM中没有MTU的问题，然而在TCP/IP中会向网卡查询MTU，那么这个ATM承载IP的网卡该如何回答TCP/IP协议的查询呢？当然这个例子是比较简单的，比较复杂的应该是ATM中所有信令的模拟，这将消耗Developer许多的精力。

实在话，我很久就不再去崇尚程序设计技术；相反，那么优秀的软件架构更容易引起我的兴趣。所以当我搞清楚Windows网络组件的结构时，真的很惊讶，尤其是从Winsock SPI到WSH DLL这一段结构上的处理，可以说是应用太和核心太交互同时支持多接口的典范。原来我一直在想，在已经存在了Base SPI这个东西之后为什么微软的工程师还要设计出WSH DLL这个东西，在Base SPI中就已经将Socket中的协议族解析结束了，也就是说已经确定了应用程序使用的是TCP/IP协议还是IPX/SPX协议还是NetBEUI协议，他们为什么还有加一个WSH DLL这一层来具体的根据协议类型来解析Socket的动作。后来才发现是为了文件系统直接操作网络的支持和科学的细分模块的需要，在这个中间我确实第一次感到了微软的工程师们在设计上的精湛。关于文件系统支持网络操作，我在做网络组件的探讨时，只是为了找到在Windows中嵌入一个让Winsock支持的全新的协议，并没有说到一定要文件系统也支持该协议，所以没有详细的分析过文件系统对网络支持的具体模型，在这里也就不再多言，所以在上面的图中我也未曾画出来，因为对于这个东西我基本没有写过什么真正的测试代码。

NDIS是一个设计很优秀的接口模块，同时在Windows网络组件中这样的接口至少还有TDI、SPI，但是他们都是各有区别，在细节上都有一些不同。我真的很佩服微软的工程师在软件架构上的设计，所以我觉得我们不应该只去研究他们的实现以后的东西、怎么去找到一个undocument函数、怎么去突破一种限制，我们应该去研究一些他们实现的架构，这些架构真的是很精湛。或许是我的弱智才认为这个东西很神奇，但是你还是应该去尝试一下，这会给你带来很多的惊喜！

实际上Windows网络组件是一个很庞大的结构，我真的很难去了解太多，我仅仅是一个比较能吃苦的程序员而已。同时由于内容很多，很繁杂，所以很难用文字的方式将它表述的很清楚，所以我觉得自己不可能去写书，呵呵！

希望能有高手来讲解一下Windows网络组件中优秀的架构设计！这里面真地有许多值得我们学习和借鉴的！

这篇文章是为了回花猫的，他写了一个《病毒的本质》，希望大家不要迷信病毒编写是多么的神奇。我是写这个东西，想告诉大家我的一点看法。对于Windows下的NDIS驱动开发是很简单的，不要去迷信神话，但是对NDIS架构的掌握是不容易的，所以胡老大是我一直很尊敬的人。同时，我们不应该只去研究微软已经实现的东西，应该也抽点时间去看看他们的总体结构，看看他们的软件架构，这同样是我们应该学习的！

如果有什么意见和建议，或者是想要讨论些什么东西，请使用我在驱坛留下的邮件地址给我留言！不过如果因为很忙也没有时间来得及给你回信的话，请你能够见谅！

先回复一下，有时间在仔细讨论。

至少到目前为止，我认为ndis的架构是目前几个操作系统中最优秀的一个。唯一的不足就是隐藏了太多的东西。

给你置顶一下，大家慢慢讨论。

非常好，多谢！

感谢你的文章。
NDIS很象斜派武功。厉害，实用。易走火入魔（挂），不好练。
不被名们正派（MICROSOFT）推崇（却在偷偷的用而不公布核心的文挡）。


[编辑 -  12/5/03 by  asmsys]

感谢你的文章。
NDIS很象斜派武功。厉害，实用。易走火入魔（挂），不好练。
不被名们正派（MICROSOFT）推崇（却在偷偷的用而不公布核心的文挡）。


[编辑 -  12/5/03 by  asmsys]

你说的是hook，不是ndis，ndis就是ms推出来的架构。ndis在ddk里面是有文档的。大多数的开发他的文档里面都写的很清楚了，已经够利用。不公开的只是ndis本身的源代码而已。

可其实，其可是，看不到源代码，终究有隔靴搔痒的感觉。

的确,用来形容HOOK更准确.和API的文挡比较,NDIS不是很明了,当然也和我水平低有关.

很荣幸加入了NDIS驱动开发这个光荣的队伍中，希望能在这片土地上创造出辉煌

很荣幸加入了NDIS驱动开发这个光荣的队伍中，希望能在这片土地上创造出辉煌

非常感谢！

感谢你的文章。
NDIS很象斜派武功。厉害，实用。易走火入魔（挂），不好练。
不被名们正派（MICROSOFT）推崇（却在偷偷的用而不公布核心的文挡）。


[编辑 -  12/5/03 by  asmsys]

这两天真的是有点忙，忙的连留点时间给自己都是那么的困难。看来这位兄弟对NDIS还是很感兴趣，实在是性情中人，呵呵！

NDIS是一个标准，实际上是为了在Windows平台下统一Network Device Interface。关于NDIS的应用，也就是我们使用NDIS开发东西，微软的文档已经足已解决所有的问题，包括后来由GJP公布出的2K与XP下的HOOK技术，这个东西等他公布了之后，你确实能在ndis.h文件中找到一些启发，但是真正第一个将它实现的就是GJP了，这就是高人的不同，呵呵！

我写的东西和实际开发已经没有多少关系了，更多的是在讨论NDIS这个软件包的软件架构，他和NDIS这个标准的最终结构是不同的。NDIS标准的最终架构就是Minipot和Protocol，可是这个软件包的架构是什么样子的呢，这个软件的设计上是什么样子的呢？这就是我这篇文章要讨论的东西。就好象TCP/IP协议的架构大家都是明白的，可是在Windows中这个TCP/IP软件包的架构又是什么样子的呢？这是不同的概念。

对NDIS架构进行深入地分析，我们会讨厌去看源代码的。NDIS的源码有多少？这个问题我一直在想，但是我一直认为不会很多。NDIS并不是一个非常神奇、非常不可思议的东西；相反，他是在继承了分层驱动模型这个基础上做出来的。分层驱动模型这个东西，大家都知道吧，做这样的设备管理器不需要太多的代码，但是需要好的设计。分层模型仍然使用了微软的惯用“伎俩”――回调函数。我不知道你是否意识到，回调函数可以说是微软最基本、也是最常用的一个东西，从Application到Kernel，那个没有回调函数的影子？分层的管理器不需要太多的代码，那么网络特性是否需要很多代码呢？网络特性主要是网卡PNP、电源、路由，以及协议的PNP。这些东西我觉得也不会有太多的代码！呵呵，总之，我觉得代码量不会非常的大！

对了，说到这里我还得感谢fracer和mikeluo以前对我的帮助，真的感谢二位，我也说哪句话吧，“兄弟，来沈阳我一定好好请你吃顿饭。”呵呵！

作架构真的是很难的东东。需要的是经验，智慧。看ndis是很久以前的事情了，印象最深刻的，并不在于它的这些架构，而是它能在文档中把这些架构讲解的非常清楚。这个可不容易。我个人觉得，能够作OS的人和公司都不在少数。但是能够把DDK做出来的人，我觉得只有微软。
另外，关于ndis，有一个建议，有时间看看linux下网络堆栈的实现，大有好处，二者结合比对，感悟更多。

先回复一下，有时间在仔细讨论。

至少到目前为止，我认为ndis的架构是目前几个操作系统中最优秀的一个。唯一的不足就是隐藏了太多的东西。

给你置顶一下，大家慢慢讨论。

为了保持对ndis3的兼容性，多了一堆垃圾，增加了复杂性。

但是居然还兼容了，这是我认为非常了不起的地方。

讲一个细节：

对于ndis的接收发送函数，原来的设计是由ndis来做同步，
ndissetattribute(serial)，导致ndis部分地方不能重入，
简化了编码，却降低了效率。
nt4 sp3之后，这个地方也改过来了，现在send/recv都可
重入，特别是多cpu和多网卡。

如上种种，是我在好几年以前，到几年以前（我有2年没
仔细看过ddk了）的学习过程中，体会最深的一些事情。

包括还有那句关于内存分配的经典描述：
“谁分配，谁释放”
这是安全的，代码清晰的，同时也带来了许多的回调过程，
又让代码变得看起来混乱起来。

核心异步处理的方法本质是回调，这成了我自己后来编写
代码的一个思维方式。

我的道路可能颇为奇怪，我是在学习win32的同时学习driver
的，抛开最早用vb学习写win程序那段历史，我记不清楚我是
先用win32写的第一个win程序还是用ddk写的第一个driver。
最后花在ndis上面的时间最多，所幸的是，那段时间的学习，
不只是给了我ndis得知识，也许更值得怀念的是从中学习到
的编程思想。

nt的核心是面向对象的，驱动程序也是面向对象的，只不过
是用c写出来的而已，一直以来，我都在写着这样的应用程序，
也许那些年来对ndis的阅读和思考在我心中带来了太深的烙印
吧。

[quote]先回复一下，有时间在仔细讨论。

至少到目前为止，我认为ndis的架构是目前几个操作系统中最优秀的一个。唯一的不足就是隐藏了太多的东西。

给你置顶一下，大家慢慢讨论。

为了保持对ndis3的兼容性，多了一堆垃圾，增加了复杂性。

但是居然还兼容了，这是我认为非常了不起的地方。

讲一个细节：

对于ndis的接收发送函数，原来的设计是由ndis来做同步，
ndissetattribute(serial)，导致ndis部分地方不能重入，
简化了编码，却降低了效率。
nt4 sp3之后，这个地方也改过来了，现在send/recv都可
重入，特别是多cpu和多网卡。

如上种种，是我在好几年以前，到几年以前（我有2年没
仔细看过ddk了）的学习过程中，体会最深的一些事情。

包括还有那句关于内存分配的经典描述：
“谁分配，谁释放”
这是安全的，代码清晰的，同时也带来了许多的回调过程，
又让代码变得看起来混乱起来。

核心异步处理的方法本质是回调，这成了我自己后来编写
代码的一个思维方式。

我的道路可能颇为奇怪，我是在学习win32的同时学习driver
的，抛开最早用vb学习写win程序那段历史，我记不清楚我是
先用win32写的第一个win程序还是用ddk写的第一个driver。
最后花在ndis上面的时间最多，所幸的是，那段时间的学习，
不只是给了我ndis得知识，也许更值得怀念的是从中学习到
的编程思想。

nt的核心是面向对象的，驱动程序也是面向对象的，只不过
是用c写出来的而已，一直以来，我都在写着这样的应用程序，
也许那些年来对ndis的阅读和思考在我心中带来了太深的烙印
吧。


 [/quote]


再说一点体会。

从前，我很在意看某个函数该如何使用，后来我很在意看那些
参数的含义，特别是类似FLAG这样的参数。

此外，每个函数的调用IRQL_LEVEL和工作的LEVEL，也是我特别
在意的地方了，因为就只这一个信息，都足够告诉我很多了，大致
也能猜测到一些内部实现机制。

前段时间花了一些精力把原来的driver都改成SMP Safe了，
为了快速重现错误，为此弄了台至强的机器来，2 ht cpu。
让我对其中的一些细节了解又多了一些。

DDK的描述真的是很不错的，确实写这个东西应该也只有微软了！以前也常有人说NDIS应该看看Linux下的东西，但是终究没有非常仔细的去看过，既然兄弟再次提到这个东西，看来真的该抽时间去看看了！

看来老大就是老大，我看到这些调用IRQL_LEVEL和工作的LEVEL的时候基本猜不出任何东西，只知道这个东西很重要，一定要小心处理。

“谁分配，谁释放”这个东西在设计上确实不错的，尤其在NDIS中的那些PACKET环境中，恐怕这样做是最好的方式了！不知道谁是否有更好的方法可以来处理这个问题吗？我是想不出来了，呵呵！

对于NDIS架构，我原来有这样一个理解，不就是一个回调函数的集合吗？说白了不就是去管理这些回调函数吗？后来才发现绝对不要这么去理解，这肯定是不行的，但是这是最容易说清楚流程的一个说法。对于我刚开始说的NDIS架构，我真正的启发在于看ATM这个东西的时候，以前没有想过两种介质，但是在涉及到ATM哪个东西后，就发现了问题。如果系统本身有两个网卡，那么NDIS中的IMD就应该告诉TCP/IP有两个网卡，这才符合逻辑。碰到ATM后就发现，IMD不仅要告诉TCP/IP有两个网卡，并且每个网卡的性质必须是继承的，也就是说IMD中的Mniport必须继承真实网卡的所有信息，这同样这才符合逻辑。所以我得出了在网卡设备的管理上实际是分层的，因为分层是解决这个问题最简单的方法，同时它又是Windows其它驱动模型的本质。

我对NDIS的很多感悟对于写NDIS驱动并没有太多的价值，因为我喜欢软件中体现的思想，而不是这个软件做出来是什么样子，不过这些东西对于了解Windows的网络组件结构确实还略微有点用处。

monkeyy就是比较刻苦！敬佩
做技术的，一定要想的深一些，不能只注重简单的功能实现，难得就是“认真”啊！ 呵呵，仅是我的感想。

[quote][quote]先回复一下，有时间在仔细讨论。

至少到目前为止，我认为ndis的架构是目前几个操作系统中最优秀的一个。唯一的不足就是隐藏了太多的东西。

给你置顶一下，大家慢慢讨论。

为了保持对ndis3的兼容性，多了一堆垃圾，增加了复杂性。

但是居然还兼容了，这是我认为非常了不起的地方。

讲一个细节：

对于ndis的接收发送函数，原来的设计是由ndis来做同步，
ndissetattribute(serial)，导致ndis部分地方不能重入，
简化了编码，却降低了效率。
nt4 sp3之后，这个地方也改过来了，现在send/recv都可
重入，特别是多cpu和多网卡。

如上种种，是我在好几年以前，到几年以前（我有2年没
仔细看过ddk了）的学习过程中，体会最深的一些事情。

包括还有那句关于内存分配的经典描述：
“谁分配，谁释放”
这是安全的，代码清晰的，同时也带来了许多的回调过程，
又让代码变得看起来混乱起来。

核心异步处理的方法本质是回调，这成了我自己后来编写
代码的一个思维方式。

我的道路可能颇为奇怪，我是在学习win32的同时学习driver
的，抛开最早用vb学习写win程序那段历史，我记不清楚我是
先用win32写的第一个win程序还是用ddk写的第一个driver。
最后花在ndis上面的时间最多，所幸的是，那段时间的学习，
不只是给了我ndis得知识，也许更值得怀念的是从中学习到
的编程思想。

nt的核心是面向对象的，驱动程序也是面向对象的，只不过
是用c写出来的而已，一直以来，我都在写着这样的应用程序，
也许那些年来对ndis的阅读和思考在我心中带来了太深的烙印
吧。


 [/quote]


再说一点体会。

从前，我很在意看某个函数该如何使用，后来我很在意看那些
参数的含义，特别是类似FLAG这样的参数。

此外，每个函数的调用IRQL_LEVEL和工作的LEVEL，也是我特别
在意的地方了，因为就只这一个信息，都足够告诉我很多了，大致
也能猜测到一些内部实现机制。

前段时间花了一些精力把原来的driver都改成SMP Safe了，
为了快速重现错误，为此弄了台至强的机器来，2 ht cpu。
让我对其中的一些细节了解又多了一些。

 [/quote]

严重同意ing
每当看到一个函数或一个结构，一个FLAGS时，我做的第一件事是去看能不能在WIN95，NT4。0，NDIS3.0上运行，是不是MANDATORY COMMAND。

[quote]感谢你的文章。
NDIS很象斜派武功。厉害，实用。易走火入魔（挂），不好练。
不被名们正派（MICROSOFT）推崇（却在偷偷的用而不公布核心的文挡）。


[编辑 -  12/5/03 by  asmsys]

这两天真的是有点忙，忙的连留点时间给自己都是那么的困难。看来这位兄弟对NDIS还是很感兴趣，实在是性情中人，呵呵！

NDIS是一个标准，实际上是为了在Windows平台下统一Network Device Interface。关于NDIS的应用，也就是我们使用NDIS开发东西，微软的文档已经足已解决所有的问题，包括后来由GJP公布出的2K与XP下的HOOK技术，这个东西等他公布了之后，你确实能在ndis.h文件中找到一些启发，但是真正第一个将它实现的就是GJP了，这就是高人的不同，呵呵！

我写的东西和实际开发已经没有多少关系了，更多的是在讨论NDIS这个软件包的软件架构，他和NDIS这个标准的最终结构是不同的。NDIS标准的最终架构就是Minipot和Protocol，可是这个软件包的架构是什么样子的呢，这个软件的设计上是什么样子的呢？这就是我这篇文章要讨论的东西。就好象TCP/IP协议的架构大家都是明白的，可是在Windows中这个TCP/IP软件包的架构又是什么样子的呢？这是不同的概念。

对NDIS架构进行深入地分析，我们会讨厌去看源代码的。NDIS的源码有多少？这个问题我一直在想，但是我一直认为不会很多。NDIS并不是一个非常神奇、非常不可思议的东西；相反，他是在继承了分层驱动模型这个基础上做出来的。分层驱动模型这个东西，大家都知道吧，做这样的设备管理器不需要太多的代码，但是需要好的设计。分层模型仍然使用了微软的惯用“伎俩”――回调函数。我不知道你是否意识到，回调函数可以说是微软最基本、也是最常用的一个东西，从Application到Kernel，那个没有回调函数的影子？分层的管理器不需要太多的代码，那么网络特性是否需要很多代码呢？网络特性主要是网卡PNP、电源、路由，以及协议的PNP。这些东西我觉得也不会有太多的代码！呵呵，总之，我觉得代码量不会非常的大！

对了，说到这里我还得感谢fracer和mikeluo以前对我的帮助，真的感谢二位，我也说哪句话吧，“兄弟，来沈阳我一定好好请你吃顿饭。”呵呵！ [/quote]
你把我看的太高了，我不是一个高人，充其量是一个NDIS编程的熟练工，对于NDIS HOOK的技术，我也是从NORTON那里看来的。
对于NDIS,说到底就是一个面向低端平台的网络接口规范。我最痛恨的就是他的效率，整个NDIS流程就是数据包的传递其实就是在COPY MEMORY中进行的。以至于当别人在同样配置的LINUX平台上用SYN FLOOD 攻击你的系统时，你只能苦笑。

[quote][quote]感谢你的文章。
NDIS很象斜派武功。厉害，实用。易走火入魔（挂），不好练。
不被名们正派（MICROSOFT）推崇（却在偷偷的用而不公布核心的文挡）。


[编辑 -  12/5/03 by  asmsys]

这两天真的是有点忙，忙的连留点时间给自己都是那么的困难。看来这位兄弟对NDIS还是很感兴趣，实在是性情中人，呵呵！

NDIS是一个标准，实际上是为了在Windows平台下统一Network Device Interface。关于NDIS的应用，也就是我们使用NDIS开发东西，微软的文档已经足已解决所有的问题，包括后来由GJP公布出的2K与XP下的HOOK技术，这个东西等他公布了之后，你确实能在ndis.h文件中找到一些启发，但是真正第一个将它实现的就是GJP了，这就是高人的不同，呵呵！

我写的东西和实际开发已经没有多少关系了，更多的是在讨论NDIS这个软件包的软件架构，他和NDIS这个标准的最终结构是不同的。NDIS标准的最终架构就是Minipot和Protocol，可是这个软件包的架构是什么样子的呢，这个软件的设计上是什么样子的呢？这就是我这篇文章要讨论的东西。就好象TCP/IP协议的架构大家都是明白的，可是在Windows中这个TCP/IP软件包的架构又是什么样子的呢？这是不同的概念。

对NDIS架构进行深入地分析，我们会讨厌去看源代码的。NDIS的源码有多少？这个问题我一直在想，但是我一直认为不会很多。NDIS并不是一个非常神奇、非常不可思议的东西；相反，他是在继承了分层驱动模型这个基础上做出来的。分层驱动模型这个东西，大家都知道吧，做这样的设备管理器不需要太多的代码，但是需要好的设计。分层模型仍然使用了微软的惯用“伎俩”――回调函数。我不知道你是否意识到，回调函数可以说是微软最基本、也是最常用的一个东西，从Application到Kernel，那个没有回调函数的影子？分层的管理器不需要太多的代码，那么网络特性是否需要很多代码呢？网络特性主要是网卡PNP、电源、路由，以及协议的PNP。这些东西我觉得也不会有太多的代码！呵呵，总之，我觉得代码量不会非常的大！

对了，说到这里我还得感谢fracer和mikeluo以前对我的帮助，真的感谢二位，我也说哪句话吧，“兄弟，来沈阳我一定好好请你吃顿饭。”呵呵！ [/quote]
你把我看的太高了，我不是一个高人，充其量是一个NDIS编程的熟练工，对于NDIS HOOK的技术，我也是从NORTON那里看来的。
对于NDIS,说到底就是一个面向低端平台的网络接口规范。我最痛恨的就是他的效率，整个NDIS流程就是数据包的传递其实就是在COPY MEMORY中进行的。以至于当别人在同样配置的LINUX平台上用SYN FLOOD 攻击你的系统时，你只能苦笑。 [/quote]

两位老大又都出来了，好爽啊！哈哈哈哈哈哈！

不过为什么大家都变的这么谦虚了，是不是该是我狂妄的时候了！ :D :D :D :D :D


实在话，我第一次接触NDIS是看Hu老大公布的98下的源码，我记得哪个时候Hu老大还说我好那个，主要是那个时候98很少人去看了。然后第一次领悟到HOOK这个东西就是GJP老大的那篇文章，我记得是很早就发的一个帖子，记得当时还和Hu老大争论了起来，我还记得哪个时候的GJP叫现在这个名字，头像是一个人在弹琴。我忘了太多东西，可是这些给我重大影响，帮我很多的东西我记得很清楚。对NDIS的认识我基本是从Hu老大的教导中开始的，尽管Hu老大没有直接教我什么，但是他的帖子很有价值！对于核心编程中的HOOK就是GJP给了我很多的想法，还有很多关于编程的认识基本上都是从你们的帖子中得到的！来驱坛混的几年是我人生的一大快事！

不过我仍然坚持那个观点，“软件只是一种工具，是体现我们思想的工具。”在安全领域尤其如此！呵呵！

技术对我帮助最大的就是hu_yuguang和gjp，做事的态度上对我影响最大的就是我老师xiaocy，还有soso，monkey做事的态度，值得我学习。
我现在还处在想到哪里就写到哪里的阶段，基本上没有设计，和规划。到各位高手所说的那种阶段，还是天差地远。
最近看linux下的网络部分的代码，对回调，信号，
等过程理解比以前深入多了，HOOK就是在替换回调函数。
ndis做了那么久，还处在摸索阶段，整体上的认识并不深刻，写代码也始终在模仿的阶段，加上对windowsNT的结构结构，甚至就是WDM的理解都是肤浅而表面的，看来得拼命了！
感受最深的就是我的E文真的太差了，真是害人不浅
现在投靠linux，希望能打好基础，去掉呼噪的心态，
静下心来，好好体会其中闪烁的智慧之光:)
[编辑 -  12/15/03 by  antspower]

[编辑 -  12/15/03 by  antspower]

写驱动也有一段时间了. 不过基本还在为了完成自己的那份工作而已...

虽然还能勉强应付自己的工作, 不过始终对于架构的东西还没认识像诸位的那么深, 一直没有潜心去研读下去, 看来真的要加油再加油了... 谢谢各位的帖子