除了安装操作系统和杀毒软件外，其它常见应用软件基本上都可以通过免费和开源软件来替代。个人也绝对虽然有可以破解的各种共享软件，但是还是要支持免费和开源软件。刚开始的时候可能感觉不是特别好用，但是习惯后使用起来一般还是不会太多的影响到工作效率。
对于日常办公，首先可以安装WPS2007的个人免费版本，完全可以替代Office软件，而且和Office的输出文档的兼容性较好。同时我使用了OpenOffice套件,感觉功能也基本可以满足需要。对于个人日程事务管理可以使用Sunbird计划和任务安排软件，对于事务提醒可以使用Anotes软件。邮件客户端使用ThundBird客户端，这样基本上日常办公需要就基本可以应对了。
喜欢画思维导图的，可以到http://cn.edrawsoft.com/freemind.php下载免费的思维导图软件，这样基本也不用再使用MindManager了。另外Edraw还可以画些漂亮的流程图和商业图表，可惜是30天的试用版本。
在娱乐和即时通讯方面，对于QQ,MSN，暴风影声，eMule基本都是免费的。对于下载个人不是特别喜欢使用讯雷，而且现在讯雷广告特别多，可以使用Emule。感觉emule上的免费资源比讯雷多些，同时搜索各种英文的文档和电子书也比较方便。
对于浏览器一般情况都使用FireFox,但是新浪博客和一些网站对FIreFox的支持上还有些界面会乱掉的问题。对于输入法原来我喜欢使用拼音加加，现在改用搜狗拼音，感觉很好用。对于PDF文档的查看可以使用免费的FoxitPDF，特别是可以增加批注和编辑，很方便。对于文档压缩和解压缩，采用免费的7-Zip就可以满足需求。由于写博客经常要截些屏幕和图片，我原来采用的是破解的HprSnap,现在采用免费的ScreenHunter软件。
离线的软件我常用的就这些。还有些是要在线使用的软件＆互联网应用。用的比较多的如Google和Hotmail的邮箱。对于网络硬盘，强烈推荐免费的蜘蛛网的网络硬盘，我试用了很多网络硬盘感觉这款比较好用。对于在线记帐，可以使用财客在线软件。
收藏、分享这篇文章!

Click here to read more from 网络技术

瘟神的尾行
——Rootkit技术发展史
作者：小金
一. 无法驱逐的“助手”
网管小张正在手忙脚乱的寻找他的手工杀毒工具包，因为他在安装一个网管工具的时候无意中走了神，点击了“下一步”按钮后才惊觉安装程序的界面里一个不引人注目的角落里写着“安装CNNIC网络实名”这一行小字，而且最开头部分有一个小小的勾。于是著名的“中国网民的得力助手”便理所当然的在他的机器里安了家。
心里把厂商骂了十八遍的小张终于翻出了他外出修机时最得意的工具IceSword和超级巡警，果然在进程列表和SSDT列表里发现了红色警报，小张笑了笑，对付这些一般用户无法卸载的恶意流氓，自己可谓经验丰富了，当下便三下五除二的把CNNIC的进程给终结了，SSDT也给恢复了初始状态，然后小张去删除注册表启动项——突然发出的一个错误提示声音把小张吓了一跳，再定睛一看，他的笑容凝固了：“删除项时出错”。不会吧？小张急忙去删除CNNIC目录，结果彻底愣在了那里，系统弹出的错误提示很明确的告诉他，“无法删除文件，文件可能正在被使用”。怎么回事？小张一下子没了头绪……
达尔文的进化论告诉我们，“物竞天择，适者生存”，同样，在这安全与入侵的网络世界里，也在进行着这样一场选择的过程……
二. 被AIDS纠缠的互联网
Rootkit是什么？如果您在几年前就是本刊的读者，那您一定已经看过小金写的涉及Rootkit的相关文章，一种在当时可以被称为“艾滋病毒AIDS”的技术产物，只是，在这场“适者生存”的残酷游戏里，最终存活的，只剩下Rootkit了，于是，今天的Rootkit地位已经等同于当年的感冒病毒——因为它实在是太普遍了，在用户上网的同时，瘟神时刻都紧随着其后，以求伺机而入。
小知识：什么是Rootkit？
Rootkit自身也是木马后门或恶意程序的一类，只是，它很特殊，为什么呢？因为，你无法找到它。
正如自然界的规则一样，最流行的病毒，对生物的伤害却是最小的，例如一般的感冒，但是最不流行的病毒，却是最夺命的。Rootkit木马就是信息世界里的AIDS，一旦感染，就难以用一般手段消灭了，因为它和自然界里的同类做的事情一样，破坏了系统自身检测的完整性——抛开术语的描述也许难以理解，但是可以配合AIDS的图片想象一下，由于AIDS破坏了人体免疫系统，导致白细胞对它无能为力，只能眼睁睁看着人体机能被慢慢破坏。计算机系统没有免疫功能，但是它提供了对自身环境的相关检测功能——枚举进程、文件列表、级别权限保护等，大部分杀毒软件和进程工具都依赖于系统自带的检测功能才得以运作，而Rootkit木马要破坏的，正是这些功能。
要了解Rootkit木马的原理，就必须从系统原理说起，我们知道，操作系统是由内核（Kernel）和外壳（Shell）两部分组成的，内核负责一切实际的工作，包括CPU任务调度、内存分配管理、设备管理、文件操作等，外壳是基于内核提供的交互功能而存在的界面，它负责指令传递和解释。由于内核和外壳负责的任务不同，它们的处理环境也不同，因此处理器提供了多个不同的处理环境，把它们称为运行级别（Ring），Ring让程序指令能访问的计算机资源依次逐级递减，目的在于保护计算机遭受意外损害——内核运行于Ring 0级别，拥有最完全最底层的管理功能，而到了外壳部分，它只能拥有Ring 3级别，这个级别能操作的功能极少，几乎所有指令都需要传递给内核来决定能否执行，一旦发现有可能对系统造成破坏的指令传递（例如超越指定范围的内存读写），内核便返回一个“非法越权”标志，发送这个指令的程序就有可能被终止运行，这就是大部分常见的“非法操作”的由来，这样做的目的是为了保护计算机免遭破坏，如果外壳和内核的运行级别一样，用户一个不经意的点击都有可能破坏整个系统。
由于Ring的存在，除了由系统内核加载的程序以外，由外壳调用执行的一般程序都只能运行在Ring 3级别，也就是说，它们的操作指令全部依赖于内核授权的功能，一般的进程查看工具和杀毒软件也不例外，由于这层机制的存在，我们能看到的进程其实是内核“看到”并通过相关接口指令（还记得API吗？）反馈到应用程序的，这样就不可避免的存在一条数据通道，虽然在一般情况下它是难以被篡改的，但是不能避免意外的发生，Rootkit正是“制造”这种意外的程序。简单的说，Rootkit实质是一种“越权执行”的应用程序，它设法让自己达到和内核一样的运行级别，甚至进入内核空间，这样它就拥有了和内核一样的访问权限，因而可以对内核指令进行修改，最常见的是修改内核枚举进程的API，让它们返回的数据始终“遗漏”Rootkit自身进程的信息，一般的进程工具自然就“看”不到Rootkit了。更高级的Rootkit还篡改更多API，这样，用户就看不到进程（进程API被拦截），看不到文件（文件读写API被拦截），看不到被打开的端口（网络组件Sock API被拦截），更拦截不到相关的网络数据包（网络组件NDIS API被拦截）了，幸好网络设备的数据指示不受内核控制，否则恐怕Rootkit要让它也不会亮了才好！我们使用的系统是在内核功能支持下运作的，如果内核变得不可信任了，依赖它运行的程序还能信任吗？
这段概念是三年前写下的，而如今的网络世界，越来越多的木马后门在反病毒产品的围剿下消灭殆尽，就如同在一个密封的箱子里投入五大毒虫，让它们自相残杀，无论结局怎么样，总会有一方顽强的存活下来，而幸存的这只毒虫，就是最强最可怕的，只不过，反病毒产品并非每次都能成为存活下来的一方，而能够存活下来的非反病毒产品，必然是Rootkit。
这唯一幸存的毒虫所采用的技术迅速成了众人研究学习的重点，于是，Rootkit在短短几年内就走下了神秘的舞台，越来越“平民化”了，网络终于成为一个新的“艾滋病村”，在如此“平民化”的氛围里，Rootkit终于有了它“平民化”的名称： 驱动木马、驱动马、带驱动的木马，诸如此类，而它的本名，也被缩写为“RK”，多用于高人之间的交流称谓。
而普通上网民众，对这些东西的存在完全是概不知情的，或者，仅限于一个模糊的概念……
 
当其他类型的木马后门技术已可以轻而易举被歼灭以后，Rootkit技术就成了这场对抗赛的主力军，于是，为了存活，“驱动马”也开始出现不同的发展分支，在普通网民尚未察觉的时候，它们早已经“变异”出不同派系了……
一切的开端：SSDT Hook
在很早很早以前，一些用户突然觉得自己的机器存在异常，并经常有被人监控的感觉，于是使用杀毒软件进行全盘扫描，答案却是否定的，于是用户就信任杀毒软件，放心的去用了，直到有一天，“灰鸽子”木马在网上闹得轰轰烈烈，用户慌忙去下载了最新专杀工具，这一下，用户被吓坏了：我是什么时候被感染的灰鸽子？
普通网民第一次与“会隐形的木马”打交道，莫过于灰鸽子事件了，但是为什么“灰鸽子”无法被任务管理器和那时候的杀毒软件找到，甚至用户自己手动去查找，也是无功而返呢？这是因为，灰鸽子使用了最初的Rootkit技术：SSDT钩子。
而后，又有一些尚在雏形阶段的恶意流氓软件，也开始大玩“隐身”了，用户们是丝毫没有察觉的，除非一些恶意程序太过于张扬，但是，即使如此，他们也始终找不到异常情况发生的依据，任务管理器里没有、搜索文件没有、就连注册表监视软件，也没了回应……
造成这些现象的原因是什么呢？因为灰鸽子，以及后来出现的恶意程序，它们使用的交互接口，并非Ring 3用户层上的标准Win32 API，而是通过各种手段，例如驱动程序，进入到Ring 0内核层的Native API。
“Native API”（原生API）是Windows NT架构系统中真正工作的API，众所周知，Windows是一个通过大量API函数来实现程序功能的系统，然而，由于Windows是支持POSIX标准（可移植操作系统接口，Portable Operating System Interface）的系统，这就意味着，它除了能运行标准Windows平台程序（即Win32程序）以外，还支持少量其他平台上的程序运行，如OS/2。由于不同平台的程序功能实现方法差异，系统就必须分别为它支持的各个符合POSIX标准的程序提供相应的接口函数，如果根据这个思路去开发一套庞大而完整的接口函数调用，那就太不切实际了，于是，在NT架构系统上，开发者设计了两种不同性质的API接口层，一种被称为“用户态API”，它包括常见的Win32 API和POSIX接口API等，这些API运行在Ring3用户层上，构成了今天的Windows世界；而另一种是被称为“Native”性质的API，它们才是真正的系统API，通常运行在内核态上，实现真正的系统核心功能调用。同时为了实现POSIX，开发者还设计了被称为“子系统”（Sub System）的技术来将不同的系统环境区别开来，正常情况下，从系统引导到桌面时，我们就处于“Win32”子系统下，这时候起到作用的自然就是Win32 API。普通程序员平时接触到的几千个Win32 API，实际上都是通过几百个Native API的不同封装形式来实现的。系统厂商极少提供这些API的公开文档，是因为它们要比一般的函数难以应用而且可能发生变化，当程序员使用Win32 API时，最终的执行过程是在系统经过兼容性检查、错误处理、参数选项分离等一系列复杂转换后，才送入Native API进行处理的，Native API才是真正执行并反馈运行结果的主体，用户层的API调用只是一种封装形式罢了，例如fopen和CreateFile这两个Win32函数，它们的真正执行函数是Native性质的NtCreateFile，这就是rootkit可以让一般的进程工具不能发现自己的原因，因为它直接干涉了Native API的执行结果。
因为API还有这样复杂的故事，所以现在的恶意程序纷纷为了能最大限度提升自己的权限而变身rootkit性质程序，去“钩”这些原生API，而达到同等层次的安全检测工具和反病毒产品，也为了达到同样的效果而做了同样的事情，到了这个地步，安全产品和恶意软件在执行过程中已经没有区别了，唯一的区别是对用户和系统环境造成的后果差异而已。
既然大家都要控制到原生API层，那么他们的做法有没有共同点呢？答案是一定的，Windows作为一个规范的系统，就必须在原生API和用户层API之间存在一个标准的接口来实现数据传递，并限制用户使用其他不知名的操作来达到目的，这个接口由一个名为“ntdll.dll”的动态链接库文件负责，所有用户层API的处理都是调用这个DLL文件中的相关API入口实现的，但它只是一个提供从用户层跳转到内核层的接口，它并不是最终执行体。当API调用被转换为ntdll内的相关API函数后，系统就会在一个被称为“SSDT”（System Service Descriptor Table，系统服务描述符表）的数据表里查找这个API的位置，然后真正的调用它，这时候执行的API就是真正的原生API了，它们是位于NT系统真正内核程序ntoskrnl.exe里的函数。这一过程，就是系统服务的调用，例如外壳程序需要运行一个新的进程，那么它就会调用kernel32.dll导出的API函数CreateProcess，接下来就是kernel32.dll内的执行过程，实际上它只是把这个请求又包装了一下，变形为自己发出的参数，去调用ntdll.dll里导出的NtCreateProcess函数，然后ntdll.dll通过一个中断请求int 2Eh（Sysenter）进入内核态，并把我们最初的新建进程请求转换为“服务号”一起传递过去，到了内核的世界里，在正常手段下对API的调用都需要先通过一个函数地址描述表的转变来实现，SSDT就是这个表，它记录了一个庞大的地址索引，内容为几百个原生API在内核中导出的地址位置，除此之外还有一些有用的其他信息，在这个例子里，系统根据SSDT里记录的服务号与函数对应关系来确认我们要使用什么函数，以及这个函数在内核中的位置信息，最终实现功能调用，函数执行完毕后再把结果通过ntdll接口一层层传递回去，直到发出请求的程序收到一个表示处理结果的状态代码，这一次系统服务的调用过程就结束了。
由于上述原理，无论是恶意程序还是反病毒产品都会优先考虑把SSDT的内容给篡改以达到效果，简单的说，例如一个恶意程序把SSDT里对于获取进程标识的服务号对应的原生API地址修改为指向自己位于Ring0层的驱动入口，那么每次系统执行到这个函数时，都会由于SSDT的错误引导而进入了作者指定的服务模块中，就会导致相关的操作请求和参数被这个第三方模块记录和篡改，于是各种奇怪的现象就会发生了，就拿隐藏自身进程的rootkit技术来说，其原理就在于通过篡改SSDT里枚举进程的原生API服务号先指向自己的模块，再由自己的模块另行传递到真正的系统服务上（如果没有这一步操作或者操作错误，那么这个对应的系统服务就会作废甚至引发系统崩溃），并对真正的系统服务返回的数据进行加工处理，如删除带有自己进程名的数据，那么最终返回的数据里自然就“看不到”这个进程了。
通过操纵SSDT，以这个技术维生的Rootkit嚣张跋扈过一段时间，无论是木马后门还是流氓插件和恶意软件。在幕后挣钱的作者们也结结实实的过了个肥得流油的好年，然而好景不长，Anti-Rootki t（反Rootkit，即“ARK”）的概念被提出了，ARK工具也诞生了，如国产的IceSword、超级巡警等。此类ARK工具的运作原理和Rootkit大相径庭，它们也是通过驱动模块将自身投入系统内核中，从而达到了与Rootkit们平起平坐的公平竞争地位，然后，位于用户层的程序主体和进入内核态的驱动模块同时产生一个相同的查询API，例如枚举当前系统进程列表等，由于Rootkit的存在，用户层的程序主体最终得到的数据会比驱动模块返回的数据少那么几个——很明显，Rootkit驱动拼命要隐藏起来的用户层程序就此暴露，不打自招了；而同时，ARK还能将当前SSDT服务号指向的函数幕后的执行主体找出来，如果某个服务号指向的函数对应的执行主体不是NTOSKRNL.EXE（XP及以上系统中，某些机器是ntkrnlpa.exe），则可以断定该服务号有问题了。超级巡警以及后来的ARK更是直接提供了“一键恢复”功能，只需用户鼠标轻轻一点，所有第三方程序在SSDT挂住的钩子纷纷“脱钩”，短时间内就把RK布下的层层障碍给解除了，在一段时间内RK的势头迅速被压了下去，短暂的世界太平，短暂的，恩。
对于SSDT Hook，现在的所有Anti-Rootkit工具都能轻易找出并解除它的钩子（脱钩，Unhook），如IceSword、RKU、超级巡警等。
运行IceSword，首先点击“进程”，观察这里是否存在红色标记的进程，如果有，说明你的系统里绝对存在SSDT Hook，那红色的进程正是被底层驱动隐藏起来的文件，将它的具体位置记下来，并将其终止。
现在点击进入SSDT列表，会发现一些被红色标注出来的行列，记住它的“当前服务函数所在模块”，这个就是实施SSDT Hook的底层驱动文件。
然后，使用超级巡警切换至高级模式，将SSDT恢复为初始状态，它的所有防御就被解除了，现在直接查找刚才记录的文件去删除吧。
进一步试探：Shadow SSDT Hook
RK作者不甘心，无论是出于技术上的抗争还是利益上的损失，反正，ARK既然让我丢了面子或瘪了钱包，那么，“有朝一日龙得水，定叫长江水倒流！”，一些人开始尝试研究破解Anti-Rootkit工具，誓与之抗争到底，另一些人，则开始了新的探索，最终，双方都有了成效：首先，pjf的大作IceSword被成功反汇编了，虽然得到的并不是最初的C语言代码而是汇编语句，但是对于研究Rootkit的人来说，汇编在他们眼里，就如同看网络小说一样轻而易举，很快，就有人识破了作者的检测逻辑，可以绕过IceSword以及其他采用类似检测方法的工具的Rootkit就此诞生，甚至一部分RK已经开始反过来监控ARK，一旦相应ARK的驱动被加载，立即开始玉石俱焚——将用户机器弄成经典的蓝屏死机，不明就里的用户在几次与蓝色屏幕对望后，通常都会无奈的放弃；而另一种蓝屏则是更深层次的问题导致的，下面会提到。
 
而探索另一个方向的研究者们，也传来了捷报：Windows系统里，除了那个大家都在玩的SSDT（KeServiceDescriptorTable）以外，还有一个隐藏得非常深入的类似SSDT结构的数据段在同时工作着，它被称为“Shadow SSDT”（SSDT映射），这个“KeServiceDescriptorTableShadow”功能并未从系统内核中导出，但是通过外联的系统级别调试器，却看到了它的踪影。Shadow SSDT的作用和SSDT本身差不多，只不过它主要是提供一些基于图形用户界面（GUI）下的系统服务函数，并保存了一份与SSDT相同的服务列表，当然，这也是提供给基于GUI下的程序调用的。Shadow SSDT被安排在win32k.sys中，非常少文献提及它，因此这几乎是个被人遗忘的角落，Rootkit作者们很快就发现，控制这里也能达到一定的效果，因为Shadow SSDT同样具备了SSDT的所有功能，只不过是要利用的时候多了一些步骤而已，于是RK又有了新的玩法，这一次，轮到ARK傻眼了，那时候ARK根本没有做到Shadow SSDT这一步，于是，只钩住Shadow SSDT的Rootkit们得以无法无天的生存下去，任由用户怎么发现恶意程序怎么恢复SSDT都好，始终都是影响不到此类Rootkit！
这个情形，一直到具备了Shadow SSDT检测功能的ARK工具出现才结束，例如大名鼎鼎的RootKit Unhooker（RKU），它那强大的SSDT以及其Shadow检测脱钩功能，帮助许多人解决了这些新生的捣蛋鬼，于是，Rootkit作者们又开始寻求新的生存之道。
此类Hook由于出现得比较晚，很多当初流行的ARK都没有涉及这块，所以，我们只能使用RKU、狙剑等工具对其进行操作。
运行RKU（Rootkit Unhooker），它是英文软件，但是操作十分简便。点击“Shadow SSDT”，如果系统中存在Shadow SSDT Hook，你会发现软件底部状态栏里“Services/Hooked”不再是“xxx/0”的状态，同时相应被Hook的函数显示行里，“Hooked”一栏为“Yes”，现在记下这个文件的位置和地址，然后直接点“UnHooked ALL”，接下来，去找文件删除吧。
逼近顶峰：Inline Hook
世界上最荒谬的事情是什么？是顺着被人故意弄乱方向的路牌，往错误的方向走了好远都没察觉到有问题？还是被朋友恶作剧的将男女洗手间的标识换了位置？如果有天去造访寺院，却发现里面居然是清一色的道士在念经，你一定会惊呼，这简直太荒谬了！
在狂热的Rootkit领域里，类似的荒谬正在散布开来，那就是高级的Hook形式——Inline Hook。
在最初的运作流程里，所有被设置了挂钩的函数操作，最终还是要回到原始功能模块内处理的，毕竟第三方程序作者不是Windows系统编写者，为了保证系统的正常运行，最明智的做法当然是让被拦截的相关函数请求在经过自己编写的模块的层层检测并发现无害以后，立即将这个即将进行正常工作的请求原封不动的送到它该干活的地方去，以便系统完成整个工作流程，所以大家都在打SSDT等地方的主意，就是为了在这条必经之路上插上一脚，力求能绊倒那些看着不顺眼的路人。而现在，路上出现会砍脚的保安了，怎么办，难道玩不下去了吗？然而，迎接挑战正是每个研究者的兴趣所在，于是，荒谬的念头带出了可怕的技术，这就是Inline Hook。
其实，Inline Hook早就作为一种高级的Hook技术存在了，在用户层上的一些特殊程序如游戏外挂等，为了获得最完整可靠的数据，它们都不再采用错误指路牌的方法来将数据转移了，因为这样很可能会因为触发程序编写者针对此问题而设置的处理程序，最终功亏一篑。那么，怎么样才能让这个处理程序不能达到触发条件呢？那就是千万别去钩这个程序，但是如果不钩住程序，又该如何取得相关数据呢？在这样的思考模式下，一种新的钩子技术诞生了：它虽然也在玩钩子，但是它却不是来钩目标程序的，而是将系统里相应的API函数给虏了去，由于任何普通程序作者对系统API都是绝对信任的，于是，当他们的程序请求调用相关API并将参数一同发送过去时，由于提供这个API的相应模块被钩住了，它的“先知”——布施钩子者就抢先一步得到了数据内容，接下来就得看作者的编程功底来决定程序的生死了，因为作者并不能自己写出相应的系统函数，他就必须得设法将数据送回原函数执行模块里去，这一步稍有差错，就会导致调用这个API的程序崩溃退出。
正因如此，Inline […]

Click here to read more from 网络技术

新一代的系统保护神
——主机防御系统体系简介
作者：小金
一. 与流氓木马说再见
现在是深夜时分，网民周颖正在打开某个刚认识不久的QQ网友发来的页面，这个网友自称是周颖喜欢的某明星的粉丝，两人聊得十分投机，最后，网友发来一个地址，说是自己收集的所有资料，周颖便不假思索的点击了。
在看到一个相册图片显示完的同时，周颖的电脑也弹出了一个窗口提示“CreateProcess请求被拦截”，宿主程序为“iexplore.exe”，执行对象为“123.exe”，周颖皱了皱眉，点击了“拒绝”按钮，随手把网页也关闭了。然后她气愤的在QQ上发了一句话：“刚认识就发木马，你也太不厚道了吧，你这人真无聊，不理你了！”，对方发来一个问号，周颖不再理会，直接就把这人拖进了黑名单。
经历了这么一件事情，周颖的好心情也被破坏了个殆尽，她气呼呼的和群里熟悉的朋友们发了一阵牢骚后就关机睡觉了。
在周颖盖上被子的时候，远方某处有个在百度黑客贴吧以“黑客高手”自居并收取高额“教学和工具费用”的小青年在迷糊的梦中被手机铃声吵醒，他刚接通电话，那边就传来了一阵骂声：“你收老子3000元做这个网页木马，说绝对私人流通躲避查杀100%好用的，老子今晚刚测试第一次就被个小丫头发现了！什么破玩意儿！三天内不退钱我就把你举报到网监科去！”，电话挂断了，小青年也被吼得睡意全无，他首先想到的是难道自己最得意的“免杀版”被反病毒厂商收集到了？可是在看到所有用作病毒测试的防毒软件均未提示发现病毒，莫名其妙，遇上不想付钱的无赖了……
网络有毒，这是所有人都必须认同的一点，即使你只是打开了一个网页看些新闻时事，没准你的浏览器就正在进行下载执行来自远方的未知木马的操作——只要你的系统有些相关安全漏洞没补上，这一切就发生了。
有人会说，不怕，我有杀毒软件，再多病毒也躲不过的——实际上，许多人的机器里就出现过木马与杀毒软件共享一片天下的事情，这是因为传统杀毒软件的局限性导致的，它们依赖于病毒特征码检测，针对这个特性，木马和病毒作者或第三方人士只需要做些特殊修改，就能使程序的特征码改变而无法被杀毒软件检测到，这就是大众意义上的“免杀版”；另一种情况则是“地下流传”的私人后门，由于大部分私人后门并非公众化产物，反病毒厂商不可能得知其存在，更不可能拥有其标本，也就没办法加入特征库查杀了。
很明显，周颖遇到的就是所谓的“免杀版”木马，而且入侵者尝试利用的或许更是针对浏览器的0day攻击，保护她的并不是杀毒软件，而是前不久经由朋友介绍使用的“主机入侵防御系统”软件。
二. 主机入侵防御系统的概念
主机入侵防御系统（Host Intrusion Prevent System，HIPS）是近几年出现并迅速发展的新兴产物，与传统意义的防火墙和杀毒软件不同，它并不具备特征码扫描和主动杀毒等功能，所以想用它来替换传统杀毒软件然后安枕无忧睡大觉的用户可以不必尝试了，主机入侵防御系统是不会区别正常程序和木马的，它只有一个动作，那就是让你了解一个进程的加载情况并让你决定这个进程能否运行，换句话说，系统的安全性取决于用户本身，因为主机入侵防御系统只是一种将系统控制权交给用户的防御体系。
操作系统是一个复杂而庞大的平台，程序的执行也不是简单的功能，在Windows环境里，当用户点击某个程序图标时，系统便产生一个消息由外壳程序传递到系统内核，由内核进行诸多初始化工作如分配内存、产生进程标识、协助加载程序运行所需的组件等，这些系统步骤都是可以由特殊程序进行监视并干涉的，只是通常情况下普通用户无法拥有这种待遇，而主机入侵防御系统则为用户提供了对于这个系统加载的监视和拦截功能。这个监视和拦截的过程被称为“防御”（Defend）。
目前主机入侵防御系统可提供三种防御：应用程序防御体系AD（Application Defend）、注册表防御体系RD（Registry Defend）、文件防御体系FD（File Defend），这三种体系合称为“3D”，根据实际情况，并非所有HIPS都提供了完整的3D体系，例如文件防御体系就经常被取消。
应用程序防御体系（AD）在大部分HIPS里属于最重要的功能，这个功能的优劣足以直接影响到系统安全。AD通过拦截系统调用函数来达到监视目的，当一个程序请求执行时，系统会记录该程序的宿主（即该程序的执行请求由哪个程序发出），在Windows里，用户启动的程序，其宿主为Windows外壳程序Explorer.exe，因为用户的交互界面是由该程序负责的，用户双击鼠标执行一个程序时，实际上就是通过Explorer.exe向内核传递的消息，于是它便成为用户程序的宿主；而并非所有程序都是通过Explorer.exe执行的，系统自身也执行着许多基本进程，这些进程几乎都由smss.exe所产生，而这些通过smss.exe产生的进程又能成为其它进程的宿主，如services.exe成为svchost.exe的宿主等，这些层层叠叠的关系被称为“进程树”（Process Tree）。基于这个原理，许多伪造成系统程序的木马其实很容易被发现，因为它们大部分通过系统启动项加载，而这个启动项是属于Explorer.exe负责的，于是木马们的宿主就成了它——csrss.exe居然由Explorer.exe加载运行，这本身就违背了系统设计的初衷。
让我们继续学习用户程序的执行过程，当程序执行的请求被系统捕获后，系统会产生一个创建进程的函数调用，称为CreateProcess，位于kernel32.dll，这个函数的功能是执行一些基本的初始化工作，然后将程序请求封装传递到内核接口ntdll的NtCreateProcess函数中，该函数把有关的参数从用户空间拷贝到内核并做进一步处理，直至最后新的进程被成功创建，而ntdll也只是个内核接口而已，实际的内核体是ntoskrnl.exe。程序员通过编写内核驱动拦截NtCreateProcess、NtCreateSection等函数就实现了对创建进程的控制，在这点上，病毒作者和安全专家做的事情都是相同的，只不过用来实现破坏系统安全作用的被称为Rootkit木马，用来保护系统的被称为“应用程序防御体系”而已。HIPS的“应用程序防御体系”也是通过驱动拦截实现的，只是它把创建进程的决定权交给用户。
在HIPS的监视下，当一个进程被请求创建时，用户层的应用程序接口函数CreateProcess被拦截并被获取调用参数来分析出程序的执行体和宿主等，而后HIPS将这个执行请求挂起（暂停执行CreateProcess及以后的步骤），并于桌面弹出一个对话框报告用户当前拦截的进程创建信息，其中包括执行体、宿主、被拦截的API等，最后等待用户决定是否继续让其执行。用户必须具备相关的进程概念，如桌面快捷方式和幕后调用的可执行程序实际文件名的对应关系，这样才不至于出现一头雾水的后果，用户的决定对于系统安全才是致命的，如果一个用户在双击“千千静听”后对着HIPS拦截的“Explorer.exe试图创建TTPlayer.exe进程”的报告感到不解，那么或许传统意义的杀毒软件更适合这类未入门的初哥。
HIPS的AD体系不仅能拦截到用户或某个程序产生的进程创建请求，它还能拦截到进程产生的所有操作，如DLL加载、组件调用等，这样我们也能用它来拦截一些DLL形态的进程注入，只要用户的基础知识达到一定程度，AD体系足以让你不再害怕大部分木马病毒的来袭，试想一下，如果用户在浏览网页时HIPS突然报告说浏览器进程“试图创建123.exe进程”、或者运行某些安装程序时HIPS拦截到该安装程序“试图创建1.exe进程”，只要用户选取了“拒绝执行”功能，这些潜在的木马就无法入侵用户的系统了——但是要注意一点，那就是木马本体已经被释放或下载回来了，只是它们无法被执行而已，HIPS不是杀毒软件，它不能阻止非法程序的下载和释放，更不提供自动删除文件的功能，它所做的，只是拦截进程操作而已，使用HIPS保护的系统安全取决于用户自身。
HIPS里还有个相当重要的功能是注册表防御体系（RD），众所周知，在Windows系统结构中，注册表一直扮演着一个重要角色，许多非法程序和木马也通过修改注册表达到许多黑暗目的，如主页修改劫持等，而木马等程序的自启动也是由注册表的启动项负责的，因此，要进一步确保系统安全的话，对注册表的监视保护是必须的，从很早以前就开始使用电脑的用户应该会记得当初流行的许多注册表监视工具，然而这些工具并不能帮助用户保护注册表，因为它们仅仅是位于用户层的程序而已，其调用的API函数也是经过层层封装返回的，在当前许多进入了核心层的木马面前，这些程序根本就是被耍猴的对象，要正确监视到真正的注册表操作，就必须进入核心层，抢先拦截到系统相关的底层注册表操作函数，这就是注册表防御体系的工作。
系统提供了一系列的注册表读写访问函数来实现用户层的功能，而这些API和之前提到的创建进程函数一样，也是一种对系统内核导出函数的封装传递，如果相关函数被驱动木马拦截，普通的注册表监视程序，包括系统自带的注册表编辑器也无法发现某些项目或执行相关操作，这就是“删不掉的启动项”的来由。
在内核层中，注册表的名称并非为Registry，而是“HIVE”（蜂巢），它的数据结构称为“Cell”（蜂室），这是最底层最不可被欺骗的注册表形态结构，许多高级的Rootkit分析程序都提供分析注册表的功能，实际上就是通过分别读取用户层返回和HIVE数据结构来判断对比系统中是否存在被恶意隐藏的数据项，分析HIVE文件是漫长的过程，这是对付高级隐藏时才不得以而为之的方法，而平时安全工具只需要拦截到内核层导出的操作函数如NtOpenKey、NtCreateKey、NtQueryKey等就可以了，这正是注册表防御体系要做的事情。
RD默认提供了对几个常见的系统敏感注册表项进行监视，如启动项、服务驱动项、系统策略项、浏览器设置项等，所有木马要自启动都必须经过启动项或服务驱动项的添加修改来实现，而要对浏览器进行劫持和主页修改就得通过修改浏览器设置项等，而这些操作默认都被RD视为敏感行为而拦截挂起，并弹出警告框报告用户该次操作的具体内容和发出操作请求的执行体，操作最终能否通过也同样取决于用户本身，由于它拦截了系统核心层导出的API函数，无论是木马还是用户程序的操作都逃不过法眼，从而实现了真正有效的监视和拦截。
最后是文件防御体系（FD），这个功能的作用是监视系统敏感目录的文件操作，如修改删除系统目录里的任何文件或创建新文件等，也可用来发现被驱动木马隐藏的文件本体，FD体系在许多杀毒软件里已经提供，一部分HIPS为了提高效率，并不具备FD，因为它相对要消耗的资源比较大，而前面的AD+RD+有一定经验的用户操作，就已经足够防止危害的文件操作产生了。
实现文件防御体系的要点同样也是拦截系统底层函数如NtOpenFile等，HIPS默认对系统敏感目录进行监控保护，一旦发现异常读写，则把相关操作挂起，并提示用户是否放行，FD不仅仅只有HIPS提供，其他安全工具如360安全卫士、超级巡警等也具备此功能，该功能运作起来要比前两者消耗的资源大些。
目前主流的HIPS软件有以下几款：
SNS（Safe and Sec Personal）、EQSecure、SSM（System Safety Monitor）、PG（ProcessGuard）、GSS（Ghost Security Suite）、SS（SafeSystem 2006）
国内公认较好用的HIPS是SSM，下面就以SSM为范本，对HIPS的实际操作进行解说。
三. SSM的使用
简介
System Safety Monitor，简称SSM，是一款对系统进行全方位监测的防火墙工具，它不同于传统意义上的防火墙，因此与任何网络和病毒防火墙都不相冲突。
之所以选择SSM，是因为相对于其他HIPS而言，SSM的操作比较简便，适应普遍大众的接受能力，且提供了中文版支持，其他如PG、SNS等操作相对烦琐了些，国产的S3在安全性上不如SSM，所以，对于一般环境的用户而言，SSM是最佳选择，而且由于HIPS不会与当前的传统防火墙产生冲突（不过要小心HIPS遭遇某些防火墙的误杀），用户在HIPS的基础上保留原有的防火墙也不失为一种更加强安全的选择——当然，这样的做法会消耗更多系统资源，如果硬件配置不够，建议根据个人实际能力来决定保留HIPS还是保留传统防火墙吧，开着HIPS照样被木马进驻的用户并非少数，而遭遇入侵的关键在于用户自己的操作过程，因为前面已经说过，HIPS仅仅用作行为拦截和警报而已。
SSM可由以下地址获得：http://www.syssafety.com/files.html
安装
HIPS并不强求用户安装时的系统环境是否染毒（文件型的除外，如熊猫烧香），也就是说，即使当前的环境中存在木马甚至Rootkit，在安装HIPS后照样能不慌不乱的对其进行限制操作，但是为了避免以后出现针对HIPS安装环境的木马，最好还是养成预先准备的习惯为好，经验告诉我们，“亡羊补牢”总是会晚一步的。
SSM的安装过程并不复杂，与一般的安装程序没什么差别，用户可以像安装QQ一样简单的完成它，安装完成后会提示重启以便SSM生效。
基本设置
重启完成后用户大概会习惯性的以为SSM会如传统意义上的防火墙软件一样在开机时出现在系统托盘里，那么SSM就让你失望了，它默认并不会随系统启动，首次运行还得用户手工进入开始菜单的程序组里寻找“System Safety Monitor”项运行它，在一些用户的系统上，SSM首次运行时还会出现svchost.exe与explorer.exe进程通讯被拦截的情况，如果遇到这种情况，用户必须在短时间内选择“允许”操作，否则会导致系统蓝屏。
首次运行SSM，用户会看到一堆英文，不用担心，进入Options，将里面的Language设置为Chinese，点击Apply Options即可，SSM就变成中文了，然后记得选中“自动启动”以确保SSM每次都能随系统启动。
对于高级用户，如果使用IceSword检查SSDT列表，会发现“祖国河山一片大红”的壮观景象，几乎所有的系统函数都被一个“safemon.sys”给“吸收”过去了，这是正常现象，这个文件就是SSM的核心驱动。
学习使用SSM
由于HIPS是一种特殊的系统防护程序，而并非传统的防火墙，这就注定了它不能像一般防火墙那样安装后定期更新一下病毒库就可以放任不管了，刚安装完毕的SSM仅对基本的几个系统进程给与信任关系，其他程序在首次运行时会被SSM拦截，这就需要用户手工运行常用的程序并设置规则为“永久允许”。
SSM会拦截所有进程创建的详细信息，并报告用户当前是什么程序试图执行另一个程序，并显示出所有运行参数，通常情况下用户自己请求运行的程序，其加载者为Explorer.exe，可以放心的通过执行。而一些由用户启动的程序在运行时可能会产生Hook调用和组件调用等，这些操作在通常情况下也是正常的。
如何判断一个程序的运行过程是否正常，关系到HIPS能否保护系统的关键，对于普通无经验用户来说，必须牢记以下几点：
•记住自己刚才运行了什么程序
•仔细观察被拦截的程序名和路径是否合法
•观察加载的DLL是否程序路径下或文件版权完整、且文件名不为胡乱组合字符
•一个浏览器程序在正常使用过程中（浏览网页）突然弹出执行另一个程序请求的，100%属于危险操作
用户只要至少牢记以上几点，就能防范80%的危险操作了，如果不慎允许了一些危险程序的执行，也不必惊慌，开启SSM的进程监控器选项，找到相应进程，点击右键选择“编辑规则”，然后设置为“阻止”即可，即使该危险程序有几个进程辅助运行，在HIPS面前也是小儿科罢了，因为被HIPS阻止运行的进程是永无翻身之日的，只会一个一个减少直到没有一个能够执行。
标准状态下，SSM仅开启了应用程序防御（AD）体系，要增加注册表防御（RD）体系，还得我们选择“模块”项，点中注册表，然后勾选“启用该模块”，从此注册表的敏感操作也就会被记录拦截了，默认情况下SSM已经提供了几个常见的敏感项，用户可酌情添加。
只要有木马程序试图操作敏感项目，SSM就会跳出“模块报警”并默认对其拦截操作，接下来又要用户自行判断是否放行该操作。与上面提及的一样，用户要记住执行该注册表操作的程序是否自己指定的，否则就不要通过，宁可错杀一个，也不要放过任何自己不敢保证的程序。
与注册表操作监视的形式，SSM也提供了服务监视，这对于一些通过设置服务达到隐秘启动的木马和Rootkit来说可谓灭顶之灾，那么这里该如何判断呢？同样的道理，不是自己运行或安装某个值得信任的工具时弹出的提示以外，一律不要允许！
SSM属于HIPS类程序中最简便的一款，通过使用和熟悉它，用户可掌握基本的HIPS知识，以便为日后换用更高级的HIPS做准备。
四. 结语
在木马和病毒横行的今天，已经难以有一款安全产品的出现足以让用户们产生眼前一亮的感觉了，HIPS类产品的问世解决了大部分安全专家和有经验用户头痛的防毒问题，然而美中不足的是，HIPS类产品距离大部分普通家庭用户仍然太远，其相关的一些操作需要用户具备一定的系统知识方可使用，就在一定程度上阻碍了HIPS的普及，这个尴尬的门槛，广大用户什么时候才能跨过去呢？是将HIPS的所谓“操作难度”降低、增加自动操作功能，使其最后沦为传统的杀毒防御产品一类的地步，还是让用户学习一定的计算机知识，以跨过这种在具备一定经验知识的用户眼里不足畏惧的所谓“门槛”？无论选择哪种，这都是个难题……
收藏、分享这篇文章!

Click here to read more from 网络技术

一、眼睛，我凭什么相信你？
某天，QQ上有朋友给小白发了个编译成EXE文件的精彩Flash，Flash的确很好看，把小白逗得哈哈大笑。可是才过一会儿，他就笑不出来了：光驱不停弹出、鼠标乱跑、文件被删除……在他手足无措的时候，电脑突然重启，系统彻底瘫痪。
这是出现在许多描写黑客入侵的文章不约而同采用的“经典”题材，有朋友看了觉得奇怪：一个Flash文件都会造成这么大破坏？那我怕怕，我不看Flash了……
有时候我真不得不佩服某些朋友举一反三未雨绸缪的态度，同时也理解他们的害怕，是啊，谁能告诉我，眼前的文件到底是什么？但是也不要太过于紧张了，留意那些文章后面一般都会有的说明：“原来这个Flash被捆绑了木马。”
可是另一个问题又来了：什么是捆绑？
二、步入文件捆绑——从自解压文件说起
提起文件捆绑，许多朋友都会邹眉头，可是提起压缩文件，相信不会有人感到陌生。不知道大家有没有注意过一般压缩工具都会带的一个功能：生成自解压文件。这样压缩出来的文件是一个可执行文件，运行它就释放出整个压缩包了，有这样一个功能的确方便了用户，一些安装程序也是把自身做成自解压文件，可见这个方法的普遍性。
产生一个自解压文件的步骤如下：
1.把所有文件进行压缩编码，合成为一个普通压缩包
2.压缩工具产生一个文件外壳，写入压缩包的文件信息
3.把压缩包封装进这个文件外壳里，最终产生的可执行文件就是我们要的
一个自解压文件就是这么简单，那么，它与文件捆绑技术有什么关系呢？最大的关系就在于文件外壳。自解压文件和捆绑程序都是给原来的文件加了一个文件外壳，而它们的区别在于编码、用途、运行方式。
让我们先理解文件捆绑的概念：有一个可执行文件，它外表看起来并没有什么不妥，图标、把那版权也没问题，但是当你运行它的时候，它秘密分解成多个文件，只让其中一个或多个显示出来（通常是正常的，例如Flash），而其他程序（有害的）都是偷偷运行，让用户在不知不觉中受到侵害。实现这种“母鸡带崽”的技术就是“捆绑”（Bind），其实它不神秘，自解压文件就是一个光明正大带崽招摇过市的文件捆绑人员。
但是我们不能把自解压文件称为“捆绑”，为什么呢？现在，来看看一个捆绑文件是怎么产生的：
1.文件捆绑器产生一个文件外壳，把用户选择的可执行文件数量、体积、运行方式写入这个外壳里
2.在这个文件外壳后部追加可执行文件的数据，每个文件之间可能有特殊区别符号。
3.根据用户设定的文件图标、其他配置信息重写资源段
就这样，一个危害人间的捆绑文件产生了，你能认出来吗？
说白了，文件捆绑就是把几个可执行文件合并在一起，当用户运行这个文件集合体时，管理集合体的分离代码自动把每一个文件分离出来并偷偷执行，我们只要用自解压文件的知识就可以理解它。
三、实战分析捆绑文件
1.文件捆绑
EXE Bundle是一款比较强大的EXE捆绑机（EXE Binder），它支持最多10个文件的捆绑，我把冰河控制端作为用户程序，其他一大堆后门作为后台运行程序，捆绑界面如图1。
最后生成一个程序，看看图标，还认识吗？不过看看体积……（图2）
2.分析内部
用eXeScope载入文件（图3），发现什么问题没有？文件头部冒出两个EXEB字段，资源段里出现多个打不开的字串表，估计这些表就是分别对应每个EXE的分段。不同的捆绑器会产生不同的文件头部，但是追加文件的方法都一样的。
太复杂了？那么现在用二进制编辑工具打开它，搜索ASCII字符“This”，看看你发现了什么：
在第二个“This”的上面，我们看到这个
====================================================
bundle.INI
[Data Files]
ExtPath=1
Attrib2File1=1
[Delete Box]
CheckBox7=0
[执行文件]
File1=1
[Name Files]
File1=bundle.exe
File2=G_CLIENT.EXE
File3=G_SERVER.EXE
File4=GetAdmin.exe
File5=WinS.exe
File6=server.exe
File7=HAll.exe
File8=
File9=
File10=
File11=
======================================================
这是一段配置文件，显然，它作为一个分界线把文件外壳与文件集合体分开了，不同的文件捆绑器产生的信息不同，不必太计较这个，继续往下看：
1.G_CLIENT.EXEMZP
2.G_SERVER.EXEMZP
3.GetAdmin.exeMZ
4.server.exeMZP
如果你研究过一个程序的内部，就会知道我们查找“This”的原因：这是Windows下程序在DOS环境下运行显示的出错字符串，位于程序的头部。而这些“*****MZ”就是每个程序的起始段。
继续找下去，所有捆绑文件的头部都被发现了（图4），但是在最后一个程序后面找不到多余代码了，所以可以证明文件捆绑器是把自己放最前面，其他文件都塞后面的。
3.小结
分析这个捆绑文件可以得知，文件捆绑器仅仅把程序代码追加到文件外壳的尾部，并且改写它的配置信息，对程序代码并没有做任何编码处理，因此文件体积会相对扩大。
所以，可以对文件捆绑技术下个简单的概括：所谓文件捆绑，就是把多个可执行文件合并在一起，运行时偷偷释放出来所有并全部执行。
四、教你几招——与自解压文件的区别、防范捆绑文件的方法
如果你看到这里已经大彻大悟，那么我的苦心算是没有白费，如果还迷糊，那就看这里的概括……
与自解压文件的区别：
首先让我们看看两种文件的结构图（图5）。自解压文件仅仅是在原有的压缩包上加了个解压缩的可执行文件头，捆绑文件则是另一种结构体。但是从运行结果上看，它们是相同的。
但是，如果要具体区分，它们仍有本质上的不同：
1.自解压文件是压缩所有文件，并且大部分仅仅做释放文件功能；捆绑技术是集合可执行文件，释放后全部运行。
2.自解压文件里一般只有一个头部，捆绑技术产生的文件一般有多少个程序就有多少个头部
3.自解压文件体积一般比原来的文件集合要小，捆绑技术产生的文件却要大一点点
4.自解压文件一般难以再处理，捆绑技术产生的文件可以再加壳、压缩。
如何防范捆绑文件？
1.不要随意打开别人给你的文件
2.用字处理软件打开文件，如果查找到多于2个的“This program”字符串，那它一定是捆绑文件（这几乎是万能药）
3.杀毒程序的监控（不如人工准确）
4.对于一些捆绑器产生的伪造Flash文件之类，只要用一款查看文件调用函数的工具打开，如果看到调用了wsock32.dll、winsock.dll之类的，必然是木马无疑
5.消除对捆绑文件的恐惧心理！要明确一点，它们只对可执行文件有效，不是随便一张图片都能捆绑的！
收藏、分享这篇文章!

Click here to read more from 网络技术

此文只能说是一篇笔记，是关于本机API的.本机API是除了Win32 API，NT平台开放了另一个基本接口。本机API也被很多人所熟悉，因为内核模式模块位于更低的系统级别，在那个级别上环境子系统是不可见的。尽管如此，并不需要驱动级别去访问这个接口，普通的Win32程序可以在任何时候向下调用本机API。并没有任何技术上的限制，只不过微软不支持这种应用开发方法。
User32.dll,kernel32.dll,shell32.dll,gdi32.dll,rpcrt4.dll,comctl32.dll,advapi32.dll,version.dll等dll代表了Win32 API的基本提供者。Win32 API中的所有调用最终都转向了ntdll.dll，再由它转发至ntoskrnl.exe。ntdll.dll是本机 API用户模式的终端。真正的接口在ntoskrnl.exe里完成。事实上，内核模式的驱动大部分时间调用这个模块，如果它们请求系统服务。Ntdll.dll的主要作用就是让内核函数的特定子集可以被用户模式下运行的程序调用。Ntdll.dll通过软件中断int 2Eh进入ntoskrnl.exe，就是通过中断门切换CPU特权级。比如kernel32.dll导出的函数DeviceIoControl()实际上调用ntdll.dll中导出的NtDeviceIoControlFile()，反汇编一下这个函数可以看到，EAX载入magic数0×38，实际上是系统调用号，然后EDX指向堆栈。目标地址是当前堆栈指针ESP+4，所以EDX指向返回地址后面一个，也就是指向在进入NtDeviceIoControlFile()之前存入堆栈的东西。事实上就是函数的参数。下一个指令是int 2Eh，转到中断描述符表IDT位置0×2E处的中断处理程序。
反编汇这个函数得到：
mov eax, 38h
lea edx, [esp+4]
int 2Eh
ret 28h
当然int 2E接口不仅仅是简单的API调用调度员，他是从用户模式进入内核模式的main gate。
W2k Native API由248个这么处理的函数组成，比NT 4.0多了37个。可以从ntdll.dll的导出列表中很容易认出来：前缀Nt。Ntdll.dll中导出了249个，原因在于NtCurrentTeb()为一个纯用户模式函数，所以不需要传给内核。令人惊奇的是，仅仅Native API的一个子集能够从内核模式调用。而另一方面，ntoskrnl.exe导出了两个Nt*符号，它们不存在于ntdll.dll中: NtBuildNumber, NtGlobalFlag。它们不指向函数，事实上，是指向ntoskrnl.exe的变量，可以被使用C编译器extern关键字的驱动模块导入。Ntdll.dll和ntoskrnl.exe中都有两种前缀Nt*,Zw*。事实上ntdll.dll中反汇编结果两者是一样的。而在ntoskrnl.exe中，nt前缀指向真正的代码，而zw还是一个int 2Eh的stub。也就是说zw*函数集通过用户模式到内核模式门传递的，而Nt*符号直接指向模式切换以后的代码。Ntdll.dll中的NtCurrentTeb()没有相对应的zw函数。Ntoskrnl并不导出配对的Nt/zw函数。有些函数只以一种方式出现。
2Eh中断处理程序把EAX里的值作为查找表中的索引，去找到最终的目标函数。这个表就是系统服务表SST，C的结构SYSTEM_SERVICE_TABLE的定义如下:清单也包含了结构SERVICE_DESCRIPTOR_TABLE中的定义，为SST数组第四个成员，前两个有着特别的用途。
typedef NTSTATUS (NTAPI *NTPROC) ( ) ；
typedef NTPROC *PNTPROC；
#define NTPROC_ sizeof (NTPROC)
typedef struct _SYSTEM_SERVICE_TABLE
{ PNTPROC ServiceTable; // 这里是入口指针数组
PDWORD CounterTable; // 此处是调用次数计数数组
DWORD ServiceLimit ; // 服务入口的个数
PBYTE ArgumentTable; // 服务参数字节数的数组
) SYSTEM_SERVICE_TABLE ,
* PSYSTEM_SERVICE_TABLE ,
* * PPSYSTEM_SERVICE_TABLE […]

Click here to read more from 网络技术

数据库日常维护工作是系统管理员的重要职责。其内容主要包括以下几个部分：
一、备份系统数据
SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。
1、备份数据库
每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出数据库。对一般数据库系统卸出数据库周期建议为每周一次。
除了按计划周期卸出数据库之外，还需在每次运行没有日志的操作后卸出数据库。例如：
·每次强制地运行了 DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）；
·每次用 sp_dboption 允许 select into/bulkcopy 做快速拷贝，或用 SELECT INTO 命令创建一个永久性的表，或使用了 WRITETEXT 命令。
卸出数据库的命令为：
DUMP DATABASE database_name
TO dump_device
database_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程 sp_helpdevice 可以获得设备的信息。
下面一条命令用来卸出数据库 my_db ：
DUMP DATABASE my_db
TO db_bk_dev
2、备份事务日志
如果事务日志与数据库放在同一个设备上，则事务日志不应与数据库分开备份。master 数据库和小于 4M 的用户数据库就是这种情况。一般数据库系统的数据库和日志分别放在不同的设备上，因此，可以用 DUMP TRAN 命令单独备份日志。
备份事务日志的周期直接影响数据的恢复程度，因此建议每天备份。
备份事务日志的命令格式为：
DUMP TRANsaction database_name
[TO dump_device]
[WITH TRUNCATE_ONLYWITH NO_LOGWITH NO_TRUNCATE]
其中 database_name 是要备份事务的数据库名称，dump_device 是备份设备名称，仅当包含了 WITH TRUNCATE_ONLY 或 WITH NO_LOG […]

Click here to read more from 网络技术