Copyright (c) 2006 Dancefire (dancefire#gmail).
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".
作者：Dancefire (dancefire # gmail dot com )
( PDF格式及分析所用脚本程序下载连接： )
一、引言
麒麟操作系统是由国防科技大学、中软公司、联想公司、浪潮公司和民族恒星公司五家单位合作研制的服务器操作系统。按照麒麟官方的说法：
“Kylin服务器操作系统是国家863计划的重大研究成果，拥有完全自主版权的内核，与Linux在应用上二进制兼容，并支持64位，是中国独立研发成功的、具有完全自主知识产权的服务器操作系统。”[1]
--- 来自麒麟官方网站 和
863计划官方网站[2]
“银河麒麟操作系统是针对未来的主流网络服务和高性能计算服务的需求，参照国际主流标准，参考Darwin、FreeBSD、Linux和其它商用操作系统，借鉴UNIX操作系统和微内核操作系统的设计思想，设计并实现具有自主版权的、可支持多种CPU芯片和多种计算机体系结构的、具有高性能、高可用性与高安全性的、并与Linux应用和设备驱动二进制兼容的中文服务器操作系统，”
摘自麒麟操作系统2.0.21内自带的帮助文档
近日，有不少人对麒麟操作系统宣称的“完全自主版权”和“中国独立研发成功”这两个核心问题产生了质疑。随着麒麟2.0.14和2.0.21系统可以通过麒麟的官方网站下载后( )，这种质疑的声音越来越大。麒麟除内核以外的应用大部分都来自自由组织GNU的代码，这些代码并不属于“中国独立研发”，而且他们的版权也不属于麒麟操作系统的开发者。更有甚者，有人开始通过反汇编麒麟操作系统内核发现和美国的FreeBSD开放源代码操作系统非常相似。随后又有人成功的用FreeBSD的内核启动了麒麟操作系统。按照麒麟官方的介绍，麒麟具有Linux的二进制兼容的能力，可是丝毫没有提及与FreeBSD的兼容性，使得麒麟内核与FreeBSD的关系变得比较引人注目。在官方介绍中的简简单单的“参考”是无法解释这种相似程度的。
在强烈的关注声中，麒麟开发人员在2006年2月16日，给出了一个说明，《关于银河麒麟操作系统的说明》[3]，发布在 。其中提到了和FreeBSD的关系：
“课题组通过评测和分析，认为当时正在研发中的FreeBSD 5.0 具有比Unix SVR4.2 更好的发展势头，特别是SMPng 项目的开展，为FreeBSD 5.0 支持SMP 对称多处理器系统奠定了良好的基础，因此银河麒麟操作系统的系统服务层从SVR4.2 升级到当时正在研发中的FreeBSD 5.0。”
声明发出后一定程度上得到了大家谅解，可是虽然提及和FreeBSD的关系，却又十分隐晦，既没有明确的对官方网站新闻中的报道失实承认错误，没有明确阐述麒麟的操作系统是否具有“完全知识产权”以及是否是“中国独立研发”，甚至也没有对官方页面上的事实报道进行修正。而且，既然说明使用了FreeBSD 5.0的代码，却又说仅限于系统服务层，而丝毫未提及所占比例。这依旧让人们对这个获得863计划软件重大专项的资助的操作系统到底有多少创新产生一个大大的疑问。
为了调查清楚麒麟操作系统内核自主创新的百分比，以及与其它操作系统之间的关系，我将麒麟操作系统内核与FreeBSD、NetBSD、OpenBSD、Linux和Solaris的内核进行了可执行代码的相似度分析。
在整个过程中，我将尽量保持客观的原则进行分析。由于麒麟操作系统属于封闭源代码系统，因此在无法获得内核源代码的情况下，我将只进行二进制可执行代码文件的相似度分析。由于可执行代码受编译环境、内存分布情况以及模块的变动的影响很大，因此，会产生即使采用同一套代码，却产生很低的相似度情况。但是，对操作系统内核这种大型软件系统来说，却不会因为不同的代码而产生很高的相似度的情况。因此，我们将这次对二进制可执行代码分析所得的相似度作为相似度的下限。换句话说，真实的相似度应该会高于此次分析结果，但是由于分析方法的局限性，无法取得上限。
二、可执行文件的相似度比较
二进制可执行文件的相似度分析一直是一个难题。大家都知道，即使是同一份源代码，使用同一个编译器，可用不同的编译参数进行编译后，代码也会产生极大的差异。
当发生有人因为盗用别人的源代码而产生的侵权后，如果不能够将二者的源代码拿出进行比较的话，判断是否抄袭非常困难。因此，一直以来或多或少，总会有人无所顾忌的将开放源代码的软件拿来加入到自己的软件中，或者干脆就是在那些源代码的基础上稍加修改和更换了版权信息就宣称是自己研发的。因为他们知道，只要不把自己的源代码公诸于众，那么抄袭就很难判定。
下面我就详细说一下我采用的分析方法。
2.1 ELF可执行文件相似度分析方法
这次分析起始，我就碰到了一些难题。如果对二进制可执行文件进行基于字节的相似性分析，即使匹配上某些字节，也很难说明两段代码的相似性，另外匹配也很容易受到各种噪音的干扰而产生很低的相似度，可是噪音却无法被去除。
因此，使最小比较单元具有明确的语义和合理的过滤噪音是我首先要解决的问题。
2.1.1 反汇编
二进制文件的比较难以确定最小单元语义的根本问题在于二进制文件是以字节为单位，然而每个字节却没有特定的含义。你很难说89 e5和83 EC 89中的89相同说明什么，在这个例子中，前者的89 e5是i386的一条指令，而后者的89则是一个立即数，所以他们相同实际上什么都不说明。
针对这次分析，由于都是可执行代码，而且都采用了ELF的文件格式。由于这个特点，我首先将所有操作系统的内核通过objdump反汇编成汇编代码。这样做有一个直接的好处，就是每一行都是一条汇编语句，而每一条汇编语句又是一个程序不可分的最小逻辑单元。这样，接下来的分析就可以基于行来进行相似性的分析，因为每出现一行相同就说明有一个最小的逻辑单元相同，如果出现连续的行相似，那么就说明有连续的代码段相似。相同的行越多两个内核就越相似。
并且经过反汇编后，就避免了因文件内包含的其他无关信息，如字符串、资源文件、数据文件等，对分析结果产生的影响。
这个方法依旧无法避免因编译参数差异所造成的相似度下降的影响。虽然如此，但是我很幸运，从这次分析的结果看，依旧得到了不低的相似度。
2.1.2 过滤噪音
噪音的出现有很多原因，可能是内存分布不同、代码的增删导致的偏移地址的变化，对相同含义的常量而数值却不同等等。这些值的差异，可能会造成不同的执行结果，但是却对两段代码的相似性比较影响不大。请看下列两个代码段：
| c043e9e8 : | c04431d8 :
freebsd4_sigcode(): freebsd4_sigcode():
c043e9e8: call *0x10(%esp) | c04431d8: call *0x10(%esp)
c043e9ec: lea 0x14(%esp),%eax | c04431dc: lea 0x14(%esp),%eax
c043e9f0: push %eax | c04431e0: push %eax
c043e9f1: testl $0x20000,0x54(%eax) | c04431e1: testl $0x20000,0x54(%eax)
c043e9f8: jne c043e9fd 0x15> | c04431e8: jne c04431ed 0x15>
c043e9fa: movl 0x14(%eax),%gs | c04431ea: movw 0x14(%eax),%gs
c043e9fd: mov $0x158,%eax | c04431ed: mov $0x158,%eax
c043ea02: push %eax | c04431f2: push %eax
c043ea03: int $0x80 | c04431f3: int $0x80
c043ea05: jmp c043ea05 0x1d> | c04431f5: jmp c04431f5 0x1d>
c043ea07: nop | c04431f7: nop |
左边的代码是来自FreeBSD 5.3内核的，而右边的代码来自麒麟2.0.21/18的内核。通过人的分析，我们可以得出这两段代码实际上是相同的。可是对于计算机程序比较的时候，就不尽然。
请注意上述的有颜色的数字。用蓝色表示的代码地址[4]、绿色表示的偏移地址、红色表示的立即数、深蓝色表示的函数偏移地址和粉色表示的函数地址，这些数字的不同，就造成了代码比较时候的失败。上述13行代码，如果就这样比较的话，只有函数名一行可以匹配。因此虽然是相同的代码，却只有7.7%的相似度。下面我们就来去除这些干扰。
首先，我们将代码行地址、函数跳转地址和函数偏移地址去除。代码行所在的地址，实际上是说明了代码所在内存的位置，内存的位置会随着代码的删改而很容易产生变动，这些对我们比较代码逻辑没有意义。其中有些绝对地址，我们将其替换为“{Address}”，这样既不受地址变化的影响，又不至影响了代码的含义。
然后我们将绿色的偏移地址替换成特定字符串“{Offset}”。产生偏移地址的原因一般有两种，一种是结构体，另一种是数组。即使不对结构体删改，而仅仅是对结构体的声明顺序的变动都可以造成偏移地址的不同，我们在这里只关心程序在这里用到了一个偏移地址，而不关心用的到底是偏移了多少。数组的用法虽然不常出现，但是即使出现其中的位置也是很容易发生变动的。因此在这里，我们也将偏移地址的数值替换成统一的字符串。
最后，我们来处理红色的立即数。当然立即数并不是只有上述的几种情况下出现，虽然在上述的例子中，两边的立即数都完全一样，单是在某些情况下还是会出现不同。
立即数在程序中一般是常量，而常量有可能是与系统相关的数值，或者仅仅是一个符号，而不在乎具体数值。无论是什么含义，常量虽然在执行过程中不会改变，在设计过程中却很容易发生变动。不过对我们分析代码逻辑没有太大的影响，因此，在分析的时候我们对数值进行模糊化，将其替换为“{Number}”这个特定字符串。
至此，上述代码将会变为：
| : | :
freebsd4_sigcode(): | freebsd4_sigcode():
call *{Offset}(%esp) | call *{Offset}(%esp)
lea {Offset}(%esp),%eax | lea {Offset}(%esp),%eax
push %eax | push %eax
testl {Number},{Offset}(%eax) | testl {Number},{Offset}(%eax)
jne {Offset}> | jne {Offset}>
movl {Offset}(%eax),%gs | movw {Offset}(%eax),%gs
mov {Number},%eax | mov {Number},%eax
push %eax | push %eax
int {Number} | int {Number}
jmp {Offset}> | jmp {Offset}>
nop | nop |
现在这两段代码的相似度将变成真实的100%。
2.1.3 代码段顺序调整
经过上面的噪音过滤后，代码已经能够在基本不影响代码逻辑的前提下去除了噪音的影响。可是，还有一种情况会对匹配结果带来较大的影响。就是代码块位置的前后变动，我们来看下面这两段代码的比对。
begin(): <
mov {Address},%eax <
lea {Offset}(%eax),%esp <
xor %ebp,%ebp <
mov {Address},%esi <
mov %esi,{Offset}(%eax) <
pushl {Address} <
call <
add {Number},%esp <
call <
add {Number},%esp <
sigcode(): sigcode():
call *{Offset}(%esp) call *{Offset}(%esp)
lea {Offset}(%esp),%eax lea {Offset}(%esp),%eax
push %eax push %eax
testl {Number},{Offset}(%eax) testl {Number},{Offset}(%eax)
jne {Offset}> jne {Offset}>
movl {Offset}(%eax),%gs | movw {Offset}(%eax),%gs
mov {Number},%eax mov {Number},%eax
push %eax push %eax
int {Number} int {Number}
jmp {Offset}> jmp {Offset}>
nop nop
> begin():
> mov {Address},%eax
> lea {Offset}(%eax),%esp
> xor %ebp,%ebp
> mov {Address},%esi
> mov %esi,{Offset}(%eax)
> pushl {Address}
> call
> add {Number},%esp
> call
> add {Number},%esp
和刚才一样。左边来自FreeBSD 5.3的代码，右边来自Kylin 2.0的代码(但是为了举例，函数前后顺序稍作调整)。在两段代码实际上非常相似，但是由于代码前后的顺序不同，导致只有一个代码块sigcode()可以匹配的上，相似度仅为47.6%。
针对这类情况，我的解决办法是将代码块按照标号/函数名进行排序。经过排序，上述代码段比对将变为：
begin(): begin():
mov {Address},%eax mov {Address},%eax
lea {Offset}(%eax),%esp lea {Offset}(%eax),%esp
xor %ebp,%ebp xor %ebp,%ebp
mov {Address},%esi mov {Address},%esi
mov %esi,{Offset}(%eax) mov %esi,{Offset}(%eax)
pushl {Address} pushl {Address}
call call
add {Number},%esp add {Number},%esp
call call
add {Number},%esp add {Number},%esp
sigcode(): sigcode():
call *{Offset}(%esp) call *{Offset}(%esp)
lea {Offset}(%esp),%eax lea {Offset}(%esp),%eax
push %eax push %eax
testl {Number},{Offset}(%eax) testl {Number},{Offset}(%eax)
jne {Offset}> jne {Offset}>
movl {Offset}(%eax),%gs | movw {Offset}(%eax),%gs
mov {Number},%eax mov {Number},%eax
push %eax push %eax
int {Number} int {Number}
jmp {Offset}> jmp {Offset}>
nop nop
现在，这两段代码只有一行不同，相似度也就变为了95.2%。
但是这种依赖于标号/函数名排序的做法有效的程度实际上是有局限的。首先，并不是所有函数名都会保存于可执行代码中，至少inline函数就会在编译时扩展到调用的语句位置，还有一些函数在编译器优化时被优化掉。所以，不同的编译器，或者不同的编译参数都有可能导致某些函数名在执行体中消失，从而导致排序失败。另外，不是所有的可执行体都会保留函数名，对于Windows的PE文件来说，如果不用debug模式编译的话，除了导出函数外，其他的函数名一般不会保存在执行文件中，
在我用同样的方法分析Windows文件内核的时候出现了比较严重的问题，即使血亲关系很近的两个版本的Windows内核，无论排序或者不排序，相似度都非常的低，对于这类PE文件根本无法反映出相似度。所以，在最终的分析中，我剔出了原本列在比较目标中的XP内核。
因为ELF的这个特点，这次我的分析将只对使用ELF的文件格式的内核进行分析。
2.1.4 比较
在原本的计划中，我曾考虑采用常用于字符串相似度比较的编辑距离(Levenshtein Distance)算法[5]。这个算法的含义，是计算两字符串之间的距离有多远。编辑距离是指，从原字符串变化到目的字符串最少需要进行多少次包括添加、修改、删除在内的操作。举例而言：
如果计算kitten和sitting之间的编辑距离，我们最少需要进行3次操作，
1、 kitten -> sitten (修改s->k)
2、 sitten -> sittin (修改i->e)
3、 sittin -> sitting (增加 g)
因此，kitten和sitting之间的编辑距离是3。这个算法是俄国的科学家Vladimir Levenshtein在1965年提出的。这个算法主要是应用在DNA分析、拼字检查、语音辨识和抄袭侦测上。[6]
但是这个算法的计算复杂度太高，是O(nm)的复杂度。对于平均大小在100万行的操作系统内核源代码来说，就是万亿次级别的比对。对于普通的计算机，平均每两个内核的比对就要花去数小时。而此次参与比对的内核将有20个左右，完成一个比较完整的比对过程将会出现几百次比对，那么就要花数个月的时间，不太现实。
因此，这次我采用的是简化的比对办法。通过diff命令来比较两个内核源文件的差异。Diff使用的是一种更聪明的计算方法，虽然最坏情况差不太多，但是大多数情况下具有较高的性能[7]。
通过diff给出的结果可以得知第一个文件增改多少行代码后，就可以变为第二个文件。diff的算法和其实对于修改我们并不介意，我们只关心增加多少行代码就可以变为第二个文件。
假设内核A的代码有a行，内核B的代码有b行。而从内核A变化到内核B需要添加c行，由内核B变化到内核A需要d行。由此，我们可以得知，在内核A中，存在有b-c行代码和内核B是相同的。因此，我们将内核A中所存在的内核B的代码行数除以内核A自身的代码行数定义为两个内核的相似度，即
由公式可知，A->B和B->A的计算结果将有可能不同。因为我们判断相似度的原因不单纯是看二者的差异，更重要的是看他们之间的血亲关系的远近，因此我们取双向转换中的最大值，作为A<->B之间的相似度。
| A-B间的相似度 = max( (b-c) / a, (a-d) / b ) |
2.1.5 小结
分析方法还有待完善，可以看出，二进制可执行文件的分析依旧还有很大的难度，很容易受到各种外围环境的变化而导致相似度大幅下降，而无法反映真实的相似度。因此对于那些刻意隐瞒相关性的二进制可执行文件来说还是比较容易的逃过这种分析方法的检测。
但是，分析方法的缺陷却只会导致相似度的下降，而不会导致差异很大的代码产生很高的相似度。因此，我这次采用这次分析方法主要就是确定麒麟操作系统内核与其他操作系统之间的相似度的下限，并从数据中试图分析出他们的血亲关系。
2.2 多种操作系统内核相似度比较
麒麟操作系统内核镜像
这个镜像是作为的资源补充。
有朋友跟我说，担心在我的分析报告发布后，麒麟官方网站会删除我分析所用的那几个麒麟光盘镜像，这样可能会给别人验证我的分析带来一定的困难。
我总觉得麒麟开发组应该不会这么心虚吧？如果真的有自己的创新，只要是在尊重并认可别人劳动成果的基础上，即使再少大家也会支持的。如果选在这个时间段内删除岂不是有瓜田李下之嫌，他们应该不会这么做。
不管怎样吧，我把我所收集到的麒麟内核放到网站上好了，做为麒麟内核的镜像，也算是方便了大家去分析，省得去完整的下载安装一遍麒麟了。
所有的文件我都重新命了名，主要是为了避免重名，并且方便比较的时候知道所用的操作系统和版本。
因为保持分析的客观性很重要，所以在此我保证，下面没有任何一个文件的内容被修改过，他们和我从下拿到的内核文件完全一致，并且所有下列文件的版权归麒麟开发者所有。
如果谁有麒麟以前版本的内核，可以跟我联系。麒麟内核在麒麟安装光盘中的/boot/kernel和/KYLIN/RPMS目录下的Kylin_boot-*.rpm中。前者为光盘启动用的麒麟内核系列文件，后者为安装到硬盘上后的麒麟内核文件。
Kylin 2.0.0
Kylin 2.0-14
Kylin 2.0-21
阅读(2167) | 评论(0) | 转发(0) |
