|
|
说起VxD技术，很多接触电脑的人都会感到陌生，不过提起CIH病毒，我相信您一定不再摇头。
有过一定Windows编程经验的人可能听说过VxD这个词。80386的保护模式给了我们非常多的“保护”，对于一个不懈地追求自由的人来说，“镀金的笼子也是笼子”，翻遍Windows编程的书籍，也许最终只找到这样一扇通向自由的门：试一试VxD。
VxD是什么？为什么CIH会如此猖獗?
CIH运行在Ring 0，挂接IFS（Installable File System）服务，截获File Opening操作，然后把自己“传染”到别的PE格式的文件中，如果到了该发作的时间，它就攻击主板的Flash Memory。
CIH之所以能破坏硬件资源（通过攻击主板的Flash Memory，达到破坏硬件的目的），正是因为它利用了VxD技术。对于一般的运行于Ring 3的Windows应用程序来说，想破坏主板的Flash Memory是不可能的，因为这是80386保护模式对于代码权限的盘查所不允许的，其结果顶多是引起操作系统异常，也就是在Windows中经常出现的、令用户心跳加速的、蓝底白
VxD = Virtual “something" Device，这里的x代表Something。比如说VKD代表Virtual Keyboard Device（键盘驱动），VPICD 代表 Virtual Programmable Interrupt Device（可编程中断控制器驱动）。VxD是Windows 3.1、Windows 95的驱动程序模型（Windows 98也支持VxD）。
在很多人的印象中，VxD是与硬件设备打交道的，对于软件来说没有太大的作用，其理由之一是：用来开发VxD的DDK一般来说都分发给硬件开发商，对于搞软件开发的人来? SDK才是看家本领，而SDK中对于VxD却是言及甚少。这种想法可是大错而特错了。
由于VxD运行在系统的Ring 0级，拥有与操作系统同等的级别，所以，VxD可以最大程度地帮助我们走出80386保护模式强加给我们的“镀金的笼子”。我们就拿最近轰动一时的CIH病毒来说一说VxD这柄利剑的强大。字的“General Protection Fault”，在这里，我们该感谢那个“镀金的笼子”，至少它使我们免受邻居家那个只学过Turbo C编程的小孩的搔扰。
除了搞破坏，VxD还可以用来做些什么呢？
在这里我简单谈一下VxD的应用。
由于VxD可以虚拟根本不存在的硬件，因此，可以利用VxD虚拟硬件狗来破解一些有版权的软件的保护（怎么又是干坏事？我只是想告诉硬件狗的制造者：有些吝啬鬼想通过这种手段来省银子，早作提防啊!）。
由于VxD工作在操作系统的最底层，所以,掌握它 能使你具备扩展操作系统的能力。有没有想过在Windows 95里按下Ctrl＋Alt＋Delete键，而后弹出的是你自己设计的对话框（聪明的你一定可以发挥你天才的想像力，比如说显示一张你女朋友的照片，以提醒自己关了电脑之后别忘了去赴约会），VxD可以帮助你跟Windows 95开开玩笑。
好吧，说点正经的应用。想不想利用VxD来作些“实时”控制之类的东西？当然，作实时工控，首选的操作系统还是DOS，但是如果你经不住Windows那张漂亮面孔的诱惑，也可以在Windows下作“准实时”控制应用。一般来说，通过VxD的协助，在很多情况下，我们还是可以获得比较满意的实时效果的。据测试，486/66的PC机上运行Windows 95，在没有别的应用程序干扰的情况下，VxD可以处理10kHz的硬件中断，不会漏掉一个中断！精心设计你的应用程序和VxD（最好再买台好点的电脑），相信你可以获得满意的“实时”效果。
再讲一个有趣的应用吧（今天有点发晕了，平时我可不大爱吹牛的）。如果你有一堆16位的DLL，（假设你曾在Windows 31下作过应用程序开发，并曾为讨老板的欢心而奋力地写过许多功能不错的DLL），而你又懒得通过重写代码或者利用烦琐的Thunk移值到Windows 95下，那么，试一试VxD，可能会给你“它山之石可攻玉”的经历。当然，我的前提是你对于VxD已经有了比较多的认识并有一些实战经验，否则你大概会因此导致神经衰弱的。
再说一个比较有趣的应用。想不想使DOS TSR、Win16应用程序、Win32应用程序之间产生一些协作？想不想打破Win32应用程序4GB独立线性地址空间带来的限制？通过VxD作中介，你会发现原来“万物通于一理”。别相信坐在你对面的那个权威的“No”，相信你自己。
对于VxD，我们已经说得够多了，也许你已经兴奋得想立刻去书摊上找本《21天轻轻松松掌握VxD技术》来一读为快了。先安静会儿，现在开始泼冷水。
VxD的明天依然美好吗?
1996年的Windows Hardware Engineering Conference（WinHEC）会议上，Microsoft宣布了一种新的Windows设备驱动程序模型——Win32 Driver Model（WDM）。这种新的设备驱动程序模型将成为Windows 2000（即Windows NT 5.0）的核心。
这个消息令从事Windows设备驱动程序（VxD）开发的人感到沮丧（虽然大家早已预料到Windows系列与Windows NT系列最终将走到一起）。WDM的浮出水面把一个吃尽苦头的VxD开发者又推到了一个新的起跑线上。如果你曾去DDK的汇编代码里观光过，你一定可以体会这个消息对VxD开发者是个沉重的打击，而对于Windows NT设备驱动程序（Kernel Mode Driver）者来说，却是另一番心情——因为WDM基本等于Kernel Mode Driver＋Plug and Play。
VxD将让位于WDM，现在令我们欣慰的是Microsoft宣布Windows 98（Windows 98支持VxD）可能会坚持到200X年，Windows 2000的诞生也许在2000年之后。在这期间，掌握VxD技术的你还是可以主动要求老板给你加薪的。即使到了WDM一统天下之时，也不用灰心，因为无论是VxD还是WDM，都要求开发人员对计算机硬件有着全面而细致的了解。通过VxD的锻炼，你至少熟悉了计算机的硬件资源并对保护模式有了比较深刻的认识，这些东西都是将来从事WDM开发的硬功夫。
好了，该说说Windows NT了。在Windows NT中，80386保护模式的“保护”比Windows 95中更坚固，这个“镀金的笼子”更加结实，更加难以打破。在Windows 95中，至少应用程序I/O操作是不受限制的，而在Windows NT中，我们的应用程序连这点权限都被剥夺了。
Windows NT的驱动程序模型与Windows 3.1、Windows 95是截然不同的。所以说，如果有人告诉你，他的运行Windows NT的机器被CIH破坏了，你可以充一回专家，教训教训他：“这是不可能的，记住，CIH利用的是VxD技术，而VxD在Windows NT中是跑不动的”。
在Windows NT中，存在三种Device Driver：
1．“Virtual device Driver” (VDD)。通过VDD，16位应用程序，如DOS 和Win16应用程序可以访问特定的I/O端口（注意，不是直接访问，而是要通过VDD来实现访问）。
2．“GDI Driver”，提供显示和打印所需的GDI函数。
3．“Kernel Mode Driver”，实现对特定硬件的操作，比如说CreateFile, CloseHandle (对于文件对象而言), ReadFile, WriteFile, DeviceIoControl 等操作。“Kernel Mode Driver”还是Windows NT中唯一可以对硬件中断和DMA进行操作的Driver。SCSI miniport Driver和 网卡NDIS Driver都是Kernel Mode Driver的一种特殊形式。
好了，就说到这里吧，对于Kernel Mode Driver我也知之甚少。
如果你对Windows设备驱动程序开发有兴趣的话，建议你去如下的Web站点去逛逛。
http://hejiasheng.363.net/tppmsgs/msgs0.htm#6
Vireo Software (VtoolsD) home page
http://hejiasheng.363.net/tppmsgs/msgs0.htm#7
Dan Norton"s DDK resource page
http://hejiasheng.363.net/tppmsgs/msgs0.htm#8
Microsoft home page
http://hejiasheng.363.net/tppmsgs/msgs0.htm#9
O"Reilly Associates home page
http://hejiasheng.363.net/tppmsgs/msgs0.htm#10
Nu－Mega Technologies (Soft－ICE) home page
http://hejiasheng.363.net/tppmsgs/msgs0.htm#11
Windows Hardware Technical Information for IHVs and OEMs
http://hejiasheng.363.net/tppmsgs/msgs0.htm#12
Blue Water Systems (WinRT) home page
http://hejiasheng.363.net/tppmsgs/msgs0.htm#13
Universal Serial Bus Home Page
http://hejiasheng.363.net/tppmsgs/msgs0.htm#14
DDK annotations |
|
