Virus 版 (精华区)

发信人: Kernel (好冷), 信区: Virus
标  题:  分布式病毒协议－－病毒通讯、自我进化与资源分享
发信站: 哈工大紫丁香 (Tue Dec  2 23:07:09 2003), 站内信件


分布式病毒协议－－病毒通讯、自我进化与资源分享的大同世界
By Koms Bomb/CVC.GA
现在的病毒（包括蠕虫），基本上都是单独行动，要么依靠感染文件，要么依靠网络。这
样的单独行动，影响是很有限的。Nimda和Klez很短时间内横扫全球，但它们的战绩只是感
染了几千万台机器，这大概也是目前VXer的“成就感”。然而这种成就也太微小了些，无
法真正产生深远的影响。病毒界向来是单打独斗，VXer之间的交流仅限于技术交流，却很
少有真正的联合。
现在的病毒繁殖，都是简单地产生和本代一模一样的个体，即使加入强力的polymorphism
甚至metamorphism，那也是不一样的面孔掩盖一样的质地，没有本质的进化。
当今的病毒生存环境，都是以单机为主，所有赖以传播和繁殖的信息都是来自单机，即使
是通过网络传播，最后也是驻扎在某一台机器中，以此机器为生存环境。
生物的繁殖，总要进行进化，才能不被自然淘汰。生物的生存，总要与外界交换信息，才
能更好地生存。对于一个VXer来讲，他们更愿意把Virus比做生物，那为什么不使之更加生
物化一些呢？
本文几乎不涉及太多具体的技术细节，只是给大家一个前景，并留给大家一个讨论的话题
。
我想象的，就是所有病毒，只要遵守某种社会规范，就能相互对话，交换信息。这种协议
，就是分布式病毒协议（Distribute Virus Protocol－－DVP）。
DVP是病毒对话的公共语言，是它们听得懂且能理解的。病毒通过这种协议来同其它的病毒
（也可以是病毒作者）交换信息，获取更多的信息来进行传播和进化。比如一个邮件病毒
可以从别的病毒那里获取更多的mail地址，然后向这些地址传播。或者一个病毒可以从别
的病毒那里获取最新的升级模块，对自身进行进化。

这种协议有以下几个要求：
1，几乎所有类型的病毒都可以方便地使用这种协议。汇编病毒，C/C++病毒，甚至Delphi
和VB病毒。
2，不过分依赖于操作系统。我们没有理由不顾及Win32之外的系统，比如Linux蠕虫可能也
需要mail地址来传播，那么它也渴望能够和其它人对话。
3，网络协议使用TCP/IP。由于1和2的需要，我们不能依赖过于高级的网络协议。TCP/IP是
最合适的，只要能用socket就可以使用。
4，具有良好的可扩展性。可以方便向协议那增加新的对象。

DVP的元素构成：
1，身份标识（Virus ID,VID）。我们需要确定各病毒的身份，避免不同病毒出现预期之外
的“杂交”，所以每种病毒都要有一个全球唯一ID。我们可以用128位的GUID来做为VID。
这样是合适的，在Delphi里按下Ctrl+Shift+G生成的GUID具有概率意义上的唯一性。而且
我们的病毒数量肯定要比全球的COM接口和类少得多。
VID是由VXer自己生成的。
2，功能号(Function ID,FID)。也就是告诉别人我这句话是要做什么的。比如请求一些资
源，或者提供一些资源。
3，对象。一个对象就是一个结构，是信息和资源数据的载体。不同的信息和资源被视为不
同的对象。比如可以把mail地址做为一个对象看待。对象是可以不断增加的。每种对象也
要有一个ID（Object ID,OID），用来区分不同的对象。
FID和OID是协议的重要部分，不能是随机的，也不能由个别VXer生成。要由一个统一的组
织来创建相应的ID。这样做的原因很简单，避免混乱。
如果病毒收到不认识的FID或OID，则忽略整个请求。

比如我们可以定义mail地址对象结构如下
typedef struct
{
 //n个mail地址字符串，每个字符串以空字符结尾，最后添加一个空字符
}DVPMailAddrObj;
大致可以定义以下几种对象
1），对象信息。自身所拥有对象的清单。
2），email地址。
3），IP地址。以后发动网络攻击的任务可能会从黑客转移到病毒上。这显然比几个黑客要
有效得多。那么病毒之间应该可以交换IP地址。比如某个病毒本来不会发动DoS攻击，但一
旦它从别的病毒那里获取一些IP地址后，这位热心的病毒可能也参与到攻击当中。
4），带宽信息。如果某个病毒所在机器带宽小，则它可以找到其它宽带的病毒，把自己发
送到对方机器上去，享受更优越的环境。
5），本机信息。如本机有什么东西，比如有SQL数据库，则可以把其它SQL病毒招来。
6），密码。把管理员密码拐弯抹角发给VXer。
7），病毒自身。把自己发送到对方病毒机器上去。
8），其它，不断补充中。

4，数据。对象其实相当于C++里的类，只是一些结构，数据才相当于实例。


一个简单的DVP请求的结构
Signature,8 byte;//DVP signature,can be 'DVP/CVC.'
FID: 4 byte;//eg,1 means start a new query
VID: 16 byte;//GUID,hehehehe
Objects ;//the most complex structure

DVP工作的大致流程：
1，监听端口PortServer，接收其它病毒发起的扫描和请求。
2，随机扫描其它主机，检测是否有支持DVP的病毒存在。如果发现有，则通过发送端口Po
rtClient发送自己知道的信息对象，并请求对方的信息。

为了简化交互过程，协议应该采用无会话交互。也就是每个参与对话的病毒都患有失忆症
，不记得上一句说什么。我个人认为这样是方便且合理的。方便之处在于，病毒无须记得
上次说什么，不需要一种上下文环境，编程简单且代码少。合理之处在于，协议的设计可
以使得每一句都有足够的信息。这样也避免了混乱，可以用一个线程简单地处理多个请求
而不用怕冲突。
下面用A.Client表示病毒A作为客户端发起请求，同理B.Server表示病毒B作为服务端接受
请求。
一个典型的交互可能是这样：
A.Client搜索网络，寻找其它支持DVP的病毒。
如果找到B.Server，则发起请求，内容包括自身信息以及对象清单，自身信息包括VID，等
等。至此，A忘记了B的存在。
B.Server接受请求，查看A的清单，如果发现有自己需要的，则B.Client（B作为客户端）
向A发起新的请求，直接请求需要的数据。不管有没优发现自己感兴趣的，最后B.Client都
向A发起新的请求。告知自身信息以及对象清单。

DVP除了可以让病毒分享资源外，它的一个重要应用是使病毒自动升级自动进化成为可能。
一个病毒出来以后，VXer可以对其部分模块进行升级，然后通过DVP放到网上，这样已有病
毒就可以改写自身的部分模块。和DVP本身一样，自动升级也有很多复杂的问题亟待解决，
我会专门写一篇文章讨论之。

DVP思想存在的缺陷：
DVP协议显然要公布于众的，否则没有病毒的支持，这个协议也就无法生存。但这样一来，
有心之人（尤其是AVer），很容易利用这个协议，把一些假情报以DVP的形式放到网上，这
样就会对支持DVP的病毒产生负面影响。比如AVer可能把10000个不存在的email地址发给病
毒，这些可怜的病毒大部分时间都花在向无效地址发送自身的工组上了，浪费了大好青春
。这个问题在支持通过DVP自升级的病毒上更为严重。AVer可以给病毒发一个假的升级模块
，病毒升级完之后就成了什么都不懂的白痴，甚至弹出一个MessageBox告诉用户”我是病
毒“。
DVP协议必定是开放的，但只要开放，就不能避免上面这个问题。我们的病毒显然不能有数
字签名，因为任何病毒都不知道和它对话的是什么病毒。而且即使有签名，复杂的算法也
会使汇编病毒难以实施。

这篇文章只是粗略描述了DVP的思想，目的是扔一小块砖，引来一大块玉。我希望这个思想
如果可行，那么制定DVP这可以成为CVC的一个项目。DVP不是一两个人能完成的。一旦DVP
成型，那么希望CVC会有更多支持DVP的病毒出现。

 
我重新看了一遍上次的那个相同的帖子，觉得最大的问题还是在协议本身会被AVer所历用
,为样遵守DVP的病毒就完全暴露在AVer的面前，那么只要aver把DVP协议搞定了，所有的D
VP病毒也全干掉了，
引用：
------------------------------------------------------------------------------
--
DVP协议显然要公布于众的，否则没有病毒的支持，这个协议也就无法生存。但这样一来，
有心之人（尤其是AVer），很容易利用这个协议，把一些假情报以DVP的形式放到网上，这
样就会对支持DVP的病毒产生负面影响。比如AVer可能把10000个不存在的email地址发给病
毒，这些可怜的病毒大部分时间都花在向无效地址发送自身的工组上了，浪费了大好青春
。这个问题在支持通过DVP自升级的病毒上更为严重。AVer可以给病毒发一个假的升级模块
，病毒升级完之后就成了什么都不懂的白痴，甚至弹出一个MessageBox告诉用户”我是病
毒“。
------------------------------------------------------------------------------
--
我的想法是，病毒升级并不是单纯的升级，而是前一个病毒与后一个病毒杂交，派生出新
的病毒，而根据DVP协议病毒是分布式的，到他单独存在时是什么都不做的无用的代码，而
当他与另一部分相遇时，病毒才算是病毒 

--

※ 来源:．哈工大紫丁香 bbs.hit.edu.cn [FROM: 218.108.199.61]