[分享]内核对比：麒麟操作系统有否抄袭？

<STRONG>一、引言<BR><BR></STRONG>麒麟操作系统是由国防科技大学、中软公司、联想公司、浪潮公司和民族恒星公司五家单位合作研制的服务器操作系统。按照麒麟官方的说法：<BR><BR>“Kylin服务器操作系统是国家863计划的重大研究成果，拥有完全自主版权的内核，与Linux在应用上二进制兼容，并支持64位，是中国独立研发成功的、具有完全自主知识产权的服务器操作系统。”[1] --- 来自麒麟官方网站 http://www.kylin.org.cn/news.htm和 863计划官方网站[2] http://www.863.org.cn/863_105/indust/indust_news/200409160008.html<BR><BR>“银河麒麟操作系统是针对未来的主流网络服务和高性能计算服务的需求，参照国际主流标准，参考Darwin、 FreeBSD、Linux和其它商用操作系统，借鉴UNIX操作系统和微内核操作系统的设计思想，设计并实现具有自主版权的、可支持多种CPU芯片和多种计算机体系结构的、具有高性能、高可用性与高安全性的、并与Linux应用和设备驱动二进制兼容的中文服务器操作系统，” ---摘自麒麟操作系统2.0.21内自带的帮助文档<BR><BR>近日，有不少人对麒麟操作系统宣称的“完全自主版权”和“中国独立研发成功”这两个核心问题产生了质疑。随着麒麟2.0.14和2.0.21系统可以通过麒麟的官方网站下载后( http://www.kylin.org.cn/download.htm )，这种质疑的声音越来越大。麒麟除内核以外的应用大部分都来自自由组织GNU的代码，这些代码并不属于“中国独立研发”，而且他们的版权也不属于麒麟操作系统的开发者。更有甚者，有人开始通过反汇编麒麟操作系统内核发现和美国的FreeBSD开放源代码操作系统非常相似。随后又有人成功的用 FreeBSD的内核启动了麒麟操作系统。按照麒麟官方的介绍，麒麟具有Linux的二进制兼容的能力，可是丝毫没有提及与FreeBSD的兼容性，使得麒麟内核与FreeBSD的关系变得比较引人注目。在官方介绍中的简简单单的“参考”是无法解释这种相似程度的。<BR><BR>在强烈的关注声中，麒麟开发人员在2006年2月16日，给出了一个说明，《关于银河麒麟操作系统的说明》[3]，发布在 http://www.kylin.org.cn/download.htm 。其中提到了和FreeBSD的关系：<BR><BR>“课题组通过评测和分析，认为当时正在研发中的FreeBSD 5.0 具有比Unix SVR4.2 更好的发展势头，特别是SMPng 项目的开展，为FreeBSD 5.0 支持SMP 对称多处理器系统奠定了良好的基础，因此银河麒麟操作系统的系统服务层从SVR4.2 升级到当时正在研发中的FreeBSD 5.0。”<BR><BR>声明发出后一定程度上得到了大家谅解，可是虽然提及和FreeBSD的关系，却又十分隐晦，既没有明确的对官方网站新闻中的报道失实承认错误，没有明确阐述麒麟的操作系统是否具有“完全知识产权”以及是否是“中国独立研发”，甚至也没有对官方页面上的事实报道进行修正。而且，既然说明使用了FreeBSD 5.0的代码，却又说仅限于系统服务层，而丝毫未提及所占比例。这依旧让人们对这个获得863计划软件重大专项的资助的操作系统到底有多少创新产生一个大大的疑问。<BR><BR>为了调查清楚麒麟操作系统内核自主创新的百分比，以及与其它操作系统之间的关系，我将麒麟操作系统内核与FreeBSD、NetBSD、OpenBSD、 Linux和Solaris的内核进行了可执行代码的相似度分析。<BR><BR>在整个过程中，我将尽量保持客观的原则进行分析。由于麒麟操作系统属于封闭源代码系统，因此在无法获得内核源代码的情况下，我将只进行二进制可执行代码文件的相似度分析。由于可执行代码受编译环境、内存分布情况以及模块的变动的影响很大，因此，会产生即使采用同一套代码，却产生很低的相似度情况。但是，对操作系统内核这种大型软件系统来说，却不会因为不同的代码而产生很高的相似度的情况。因此，我们将这次对二进制可执行代码分析所得的相似度作为相似度的下限。换句话说，真实的相似度应该会高于此次分析结果，但是由于分析方法的局限性，无法取得上限。<BR><BR><B>二、可执行文件的相似度比较</B><BR><BR>二进制可执行文件的相似度分析一直是一个难题。大家都知道，即使是同一份源代码，使用同一个编译器，可用不同的编译参数进行编译后，代码也会产生极大的差异。当发生有人因为盗用别人的源代码而产生的侵权后，如果不能够将二者的源代码拿出进行比较的话，判断是否抄袭非常困难。因此，一直以来或多或少，总会有人无所顾忌的将开放源代码的软件拿来加入到自己的软件中，或者干脆就是在那些源代码的基础上稍加修改和更换了版权信息就宣称是自己研发的。因为他们知道，只要不把自己的源代码公诸于众，那么抄袭就很难判定。下面我就详细说一下我采用的分析方法。<BR><BR>2.1 ELF可执行文件相似度分析方法<BR><BR>这次分析起始，我就碰到了一些难题。如果对二进制可执行文件进行基于字节的相似性分析，即使匹配上某些字节，也很难说明两段代码的相似性，另外匹配也很容易受到各种噪音的干扰而产生很低的相似度，可是噪音却无法被去除。因此，使最小比较单元具有明确的语义和合理的过滤噪音是我首先要解决的问题。<BR><BR>2.1.1 反汇编<BR><BR>二进制文件的比较难以确定最小单元语义的根本问题在于二进制文件是以字节为单位，然而每个字节却没有特定的含义。你很难说89 e5和83 EC 89中的89相同说明什么，在这个例子中，前者的89 e5是i386的一条指令，而后者的89则是一个立即数，所以他们相同实际上什么都不说明。针对这次分析，由于都是可执行代码，而且都采用了ELF的文件格式。由于这个特点，我首先将所有操作系统的内核通过objdump反汇编成汇编代码。这样做有一个直接的好处，就是每一行都是一条汇编语句，而每一条汇编语句又是一个程序不可分的最小逻辑单元。这样，接下来的分析就可以基于行来进行相似性的分析，因为每出现一行相同就说明有一个最小的逻辑单元相同，如果出现连续的行相似，那么就说明有连续的代码段相似。相同的行越多两个内核就越相似。并且经过反汇编后，就避免了因文件内包含的其他无关信息，如字符串、资源文件、数据文件等，对分析结果产生的影响。这个方法依旧无法避免因编译参数差异所造成的相似度下降的影响。虽然如此，但是我很幸运，从这次分析的结果看，依旧得到了不低的相似度。<BR><BR>2.1.2 过滤噪音<BR><BR>噪音的出现有很多原因，可能是内存分布不同、代码的增删导致的偏移地址的变化，对相同含义的常量而数值却不同等等。这些值的差异，可能会造成不同的执行结果，但是却对两段代码的相似性比较影响不大。请看下列两个代码段：<BR><BR>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>

<TR>
<TD class=code bgColor=#e6e6e6><PRE>c043e9e8 <FREEBSD4_SIGCODE>:                        | c04431d8  <FREEBSD4_SIGCODE>:
freebsd4_sigcode():                                 freebsd4_sigcode():
9 S- j! z9 Y: Fc043e9e8: call   *0x10(%esp)                       | c04431d8: call   *0x10(%esp)
c043e9ec: lea    0x14(%esp),%eax                   | c04431dc: lea    0x14(%esp),%eax
c043e9f0: push   %eax                              | c04431e0: push   %eax
1 b. q6 [: |8 C& I$ R& oc043e9f1: testl $0x20000,0x54(%eax)               | c04431e1: testl $0x20000,0x54(%eax)
- d7 p$ x6 V8 |9 _c043e9f8: jne    c043e9fd <FREEBSD4_SIGCODE+0X15> | c04431e8: jne    c04431ed <FREEBSD4_SIGCODE+0X15>
c043e9fa: movl   0x14(%eax),%gs                    | c04431ea: movw   0x14(%eax),%gs
: q; a- J7 x- Bc043e9fd: mov    $0x158,%eax                       | c04431ed: mov    $0x158,%eax
. }/ ?: y/ O; `0 s3 X: Vc043ea02: push   %eax                              | c04431f2: push   %eax
c043ea03: int    $0x80                             | c04431f3: int    $0x80
c043ea05: jmp    c043ea05 <FREEBSD4_SIGCODE+0X1D> | c04431f5: jmp    c04431f5 <FREEBSD4_SIGCODE+0X1D>
c043ea07: nop                                      | c04431f7: nop
</PRE></TD></TR></TABLE>左边的代码是来自FreeBSD 5.3内核的，而右边的代码来自麒麟2.0.21/18的内核。通过人的分析，我们可以得出这两段代码实际上是相同的。可是对于计算机程序比较的时候，就不尽然。请注意上述的有颜色的数字。用蓝色表示的代码地址[4]、绿色表示的偏移地址、红色表示的立即数、深蓝色表示的函数偏移地址和粉色表示的函数地址，这些数字的不同，就造成了代码比较时候的失败。上述13行代码，如果就这样比较的话，只有函数名一行可以匹配。因此虽然是相同的代码，却只有7.7%的相似度。下面我们就来去除这些干扰。<BR><BR>首先，我们将代码行地址、函数跳转地址和函数偏移地址去除。代码行所在的地址，实际上是说明了代码所在内存的位置，内存的位置会随着代码的删改而很容易产生变动，这些对我们比较代码逻辑没有意义。其中有些绝对地址，我们将其替换为“{Address}”，这样既不受地址变化的影响，又不至影响了代码的含义。<BR><BR>然后我们将绿色的偏移地址替换成特定字符串“{Offset}”。产生偏移地址的原因一般有两种，一种是结构体，另一种是数组。即使不对结构体删改，而仅仅是对结构体的声明顺序的变动都可以造成偏移地址的不同，我们在这里只关心程序在这里用到了一个偏移地址，而不关心用的到底是偏移了多少。数组的用法虽然不常出现，但是即使出现其中的位置也是很容易发生变动的。因此在这里，我们也将偏移地址的数值替换成统一的字符串。最后，我们来处理红色的立即数。当然立即数并不是只有上述的几种情况下出现，虽然在上述的例子中，两边的立即数都完全一样，单是在某些情况下还是会出现不同。<BR><BR>立即数在程序中一般是常量，而常量有可能是与系统相关的数值，或者仅仅是一个符号，而不在乎具体数值。无论是什么含义，常量虽然在执行过程中不会改变，在设计过程中却很容易发生变动。不过对我们分析代码逻辑没有太大的影响，因此，在分析的时候我们对数值进行模糊化，将其替换为“{Number}”这个特定字符串。<BR><BR>至此，上述代码将会变为：
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>

3 l5 b$ D- b4 L' z3 _/ @1 b<TR>
<TD class=code bgColor=#e6e6e6><PRE><FREEBSD4_SIGCODE>:                        | <FREEBSD4_SIGCODE>:
freebsd4_sigcode():                        | freebsd4_sigcode():
call   *{Offset}(%esp)                   |   call   *{Offset}(%esp)
9 R  M$ q! j+ C( |& H$ j! t$ Q2 i lea    {Offset}(%esp),%eax               |   lea    {Offset}(%esp),%eax
push   %eax                              |   push   %eax
$ p$ S! Q) k+ u2 v testl {Number},{Offset}(%eax)           |   testl {Number},{Offset}(%eax)
: C1 z! t* s  c( d1 ?7 y( x; } jne    <FREEBSD4_SIGCODE+&#123;OFFSET>       |   jne    <FREEBSD4_SIGCODE+&#123;OFFSET>
movl   {Offset}(%eax),%gs                |   movw   {Offset}(%eax),%gs
/ f( N' R6 x( { mov    {Number},%eax                     |   mov    {Number},%eax
push   %eax                              |  push   %eax
) X! ]5 f; ^8 E! K2 G/ { int    {Number}                          |   int    {Number}
jmp    <FREEBSD4_SIGCODE+&#123;OFFSET>       |   jmp    <FREEBSD4_SIGCODE+&#123;OFFSET>
. z1 c) W, F) r9 q, r nop                                      |   nop

</PRE></TD></TR></TABLE>现在这两段代码的相似度将变成真实的100%。<BR><BR>2.1.3 代码段顺序调整<BR><BR>经过上面的噪音过滤后，代码已经能够在基本不影响代码逻辑的前提下去除了噪音的影响。可是，还有一种情况会对匹配结果带来较大的影响。就是代码块位置的前后变动，我们来看下面这两段代码的比对。<BR><BR>
<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
: k+ l+ Q+ i7 k* g' J) P7 V
/ ^' Y3 `/ T+ L9 f<TR>
2 S$ `6 l* C; m<TD class=code bgColor=#e6e6e6><PRE> begin():                                   &lt;
        mov    {Address},%eax              &lt;
2 {2 B! ^# D! b0 @        lea    {Offset}(%eax),%esp         &lt;
3 D. W1 m% N2 k+ W7 @" e        xor    %ebp,%ebp                   &lt;
        mov    {Address},%esi              &lt;
: F: p7 z6 K5 ]  c% W        mov    %esi,{Offset}(%eax)         &lt;
- Z# {  ^; n# r' k        pushl {Address}                   &lt;
        call   <INIT386>                   &lt;
1 h0 e" I4 h$ c9 X$ @( G        add    {Number},%esp               &lt;
& u4 x# W. o/ k9 a/ j% c        call   <MI_STARTUP>                &lt;
- P7 l* x/ W; M+ z9 g" L        add    {Number},%esp               &lt;
2 i8 ^" z; z* Fsigcode():                                   sigcode():
        call   *{Offset}(%esp)                       call   *{Offset}(%esp)
        lea    {Offset}(%esp),%eax                   lea    {Offset}(%esp),%eax
, `1 _  ?! N& `# X, r5 B2 W2 m7 E- x        push   %eax                                  push   %eax
/ V" O& ]- {- ]        testl {Number},{Offset}(%eax)               testl {Number},{Offset}(%eax)
        jne   <SIGCODE+&#123;OFFSET>                     jne   <SIGCODE+&#123;OFFSET>
        movl   {Offset}(%eax),%gs          |         movw   {Offset}(%eax),%gs
% {$ h- y" c: t% B; L        mov    {Number},%eax                         mov    {Number},%eax
. _& N1 U- R! Q. b        push   %eax                                  push   %eax
5 R' `6 G: ~; P7 T5 x, \        int    {Number}                              int    {Number}
, v% ~  ]9 {" B' b, ?8 K2 ~- Y: I        jmp   <SIGCODE+&#123;OFFSET>                     jmp   <SIGCODE+&#123;OFFSET>
' ?" H6 w2 x+ A1 m% q        nop                                          nop   
                                           &gt; begin():
                                           &gt;         mov    {Address},%eax
                                           &gt;         lea    {Offset}(%eax),%esp
                                           &gt;         xor    %ebp,%ebp
                                           &gt;         mov    {Address},%esi
- x1 R; z' i/ y( d2 q                                           &gt;         mov    %esi,{Offset}(%eax)
- o( Z/ e6 H" `% v% z; s, B                                           &gt;         pushl {Address}
& r6 ?- P- Y. y& n                                           &gt;         call   <INIT386>
+ o# z0 P! E1 p0 }                                           &gt;         add    {Number},%esp
  G6 b5 \- A; o7 S  y                                           &gt;         call   <MI_STARTUP>
9 M; i/ O2 q9 J( a1 Y: a9 f4 P) O1 f                                           &gt;         add    {Number},%esp
</PRE></TD></TR></TABLE><BR><BR>和刚才一样。左边来自FreeBSD 5.3的代码，右边来自Kylin 2.0的代码(但是为了举例，函数前后顺序稍作调整)。在两段代码实际上非常相似，但是由于代码前后的顺序不同，导致只有一个代码块sigcode()可以匹配的上，相似度仅为47.6%。针对这类情况，我的解决办法是将代码块按照标号/函数名进行排序。经过排序，上述代码段比对将变为：<BR><BR>
0 _& t7 Y$ o2 R. K5 Z2 L& I7 Z<TABLE cellSpacing=0 borderColorDark=#ffffff cellPadding=2 width=400 align=center borderColorLight=black border=1>
. b6 F6 Z5 ^, F' a1 i6 x, j  M( W
  F* y* r6 d5 e0 c<TR>
) A8 @% O- m) U) C<TD class=code bgColor=#e6e6e6><PRE>begin():                                   begin():
' w, r/ B* s3 U        mov    {Address},%eax                      mov    {Address},%eax
        lea    {Offset}(%eax),%esp                 lea    {Offset}(%eax),%esp
8 y" l; k* {7 N5 H% k8 ?7 z% i% M        xor    %ebp,%ebp                           xor    %ebp,%ebp
        mov    {Address},%esi                      mov    {Address},%esi
2 h0 A- U* g* m# j0 O4 ]        mov    %esi,{Offset}(%eax)                 mov    %esi,{Offset}(%eax)
        pushl {Address}                           pushl {Address}
        call   <INIT386>                           call   <INIT386>
- R! K, \% Z  I3 p! q7 K        add    {Number},%esp                       add    {Number},%esp
        call   <MI_STARTUP>                        call   <MI_STARTUP>
/ t% q; f! d' D8 Y" y. E" ~9 w, r0 O% T        add    {Number},%esp                       add    {Number},%esp
" v/ d# @* g+ N& T% M! {sigcode():                                 sigcode():
        call   *{Offset}(%esp)                     call   *{Offset}(%esp)
        lea    {Offset}(%esp),%eax                 lea    {Offset}(%esp),%eax
( {* V9 `, `& z. ?' n/ z        push   %eax                                push   %eax
& a  j' |7 v; x" O( |        testl {Number},{Offset}(%eax)             testl {Number},{Offset}(%eax)
        jne   <SIGCODE+&#123;OFFSET>                   jne   <SIGCODE+&#123;OFFSET>
% Y  a3 W5 Z/ |( N        movl   {Offset}(%eax),%gs        |         movw   {Offset}(%eax),%gs
: Y& V8 v& I" r# S4 P* B        mov    {Number},%eax                       mov    {Number},%eax
' ?: x+ j6 W9 p        push   %eax                                push   %eax
' u  r, _, S. ]7 Q: _. h- n        int    {Number}                            int    {Number}
/ u' D0 E' j) d( G        jmp   <SIGCODE+&#123;OFFSET>                   jmp   <SIGCODE+&#123;OFFSET>
8 I' _) E5 z( D- ~' |- n        nop                                        nop   

</PRE></TD></TR></TABLE>现在，这两段代码只有一行不同，相似度也就变为了95.2%。但是这种依赖于标号/函数名排序的做法有效的程度实际上是有局限的。首先，并不是所有函数名都会保存于可执行代码中，至少inline函数就会在编译时扩展到调用的语句位置，还有一些函数在编译器优化时被优化掉。所以，不同的编译器，或者不同的编译参数都有可能导致某些函数名在执行体中消失，从而导致排序失败。<BR><BR>另外，不是所有的可执行体都会保留函数名，对于<a href="http://www.hack58.net/" target="_blank" >Windows</A>的PE文件来说，如果不用debug模式编译的话，除了导出函数外，其他的函数名一般不会保存在执行文件中，在我用同样的方法分析<a href="http://www.hack58.net/" target="_blank" >Windows</A>文件内核的时候出现了比较严重的问题，即使血亲关系很近的两个版本的<a href="http://www.hack58.net/" target="_blank" >Windows</A>内核，无论排序或者不排序，相似度都非常的低，对于这类PE文件根本无法反映出相似度。所以，在最终的分析中，我剔出了原本列在比较目标中的XP内核。因为ELF的这个特点，这次我的分析将只对使用ELF的文件格式的内核进行分析。