大约十年前，我接触到了微点。它是我接触到的第一款主动防御软件，让我首次接触到了行为防护的概念，这些经历令我记忆犹新。前两天才得知微点复活的消息，作为一名老用户，不测试一番自然是说不过去的。今天就先来测一下微点进程的自我保护吧。
自保能力不是杀软的全部，但现在不少病毒挖空心思针对杀软，再加上内核级木马的泛滥，自保的重要性不言而喻。犹记得当年的微点在自我保护方面可谓是可圈可点。不要说任务管理器、taskkill、ntsd和一般的ARK拿它没办法，就连icesword这样的神器也对其束手无策，而大名鼎鼎的pchunter也直言其所有进程“应用层拒绝访问”，这在当时的杀软界几乎是独一无二的。十年后的今天，主流操作系统已经从32位XP变成了64位Win 10，这使许多当年自保方面的精英疲态尽显。很多人说，在现在的操作系统上，许多杀软的自保功夫没那么硬了，行为防护也没那么狠了，这话不无道理。那么对微点来说，十年后的宝刀还能出鞘吗，让我们拭目以待。
操作系统：Win 10 64位1803（17134.112）
微点版本：测试版 2.0.20266.0154
和当年一样，微点在平常工作下一共有四个进程，分别是MPMon、MPSVC、MPSVC1、MPSVC2，其中MPMon的用户是本机用户，其余三个则是SYSTEM。这似乎意味着，MPMon的自我保护能力要弱于其它三个进程（后面的测试证实了这一点）。总共内存占用才十几M，这一点倒是继承了当年的优良品质。
既然这一次测试是专门冲着进程自保来的，废话不多说，进入正题。首先试试任务管理器，四个进程都扛住了这一波攻击，这说明不像有些完全无自保的杀软，微点在64位win10上至少还是具有一定自保能力的。
接下来我们加大火力，换系统工具taskkill。这个命令想必很多人都不陌生，它也是许多病毒用来对付杀软的武器之一（调用taskkill干掉杀软进程，算是一种经典手段了）。首先来试试最普通的方式，即“taskkill/im 进程名”。对MPMon来说，终止进程的信号可以成功发出，但进程并没有被终止，而对其它三个进程的操作则都抛出拒绝访问。总的结果是微点没有受到损伤。
我们知道taskkill的火力在加上/f（强行终止）后可以进一步升级，即“taskkill /f /im 进程名”。一番测试下来，MPMon终于最先抵挡不住缴了械，其它三个进程则扛了下来。从MPMon的名字（Micropoint Monitor）猜测它是监控主程序，果不其然，这波攻击下来，屏幕右下角的微点图标消失了。
为了继续测试，我双击微点图标试图重启该进程。有趣的是，尽管右下角的图标恢复了，状态却显示为非激活，并且主程序也打不开。这说明微点的MPMon进程在被破坏后，可以重启，但用户无法令其功能复苏。无奈之下，我只好重启后继续测试。
除了强行终止命令，我们还有其它办法提高taskkill的火力吗？当然可以。这次我们以管理员权限运行，但不加强行终止命令试试看。一通开火下来，我们发现结果和不提权限的情况相同，也是仅向MPMon发出终止信号，其余拒绝访问，微点未受损伤。不过有趣的是，后三个命令不再提示拒绝访问了，而是明确告诉我们“只能强行终止这个进程”，这似乎暗示我们提权并加/f后的taskkill将有一举拿下微点的战力。
果然，随着四条命令的发出，最高战力的taskkill向我们展示着它的成果：微点的四个进程全被清扫了出去。而且这次双击桌面图标后，四个进程均无法重启，可以说是被彻底干掉了。
在标准的进程防护测试中，一般要用一款ARK工具。无奈最新的64位Win 10下很难找到能用的ARK（pchunter都不能用），只好作罢。
本次的所有测试结果可以概括在下面这张表中。
本次测试下来，我们还是看到了微点在64位win 10下的进程自保能力。相比于那些完全不设置自保的杀软来说，情况要好得多。只有获取了管理员权限且加入强制终止的taskkill命令才能彻底干掉微点，而在不提权但加入强制终止的情况下，MPMon略显脆弱的防御使得微点软件遭到破坏，可以说是木桶效应的一个典型了。作为一名老用户，看到微点复生已是惊喜，我自然是希望微点能越来越好。本次测试下来，我主要有两点建议。
1、除了设法提升整体的自保能力以外，要特别注意强化MPMon，因为其自我保护最为脆弱，容易造成木桶效应。
2、应设法提高微点进程的恢复力。在本次测试中，所有被结束的进程都无法恢复其功能，甚至极端情况下进程都无法重启。
| 
发表于 2018-6-26 21:00:14
