源代码缺失,如何破解软件侵权比对困局?——从反编译实务看软著侵权的“隐蔽证据”挖掘

在计算机软件著作权侵权案件中，权利人最头疼的场景莫过于：明明发现对方软件功能、界面甚至缺陷都和自己的一模一样，但对方拒不提供源代码，或者干脆拿一个“清理”过的版本搪塞。此时，直接比对源代码已无可能，侵权主张是否就寸步难行？

司法实践给出的答案是：未必。近年来，从最高人民法院到各地知识产权法院，通过一系列判决确立了在源代码缺失情况下，反编译（或称反向工程、反汇编）目标程序以获取隐蔽侵权证据的可行路径。

一、反编译：从“技术手段”到“证据方法”的法律认同

首先需要厘清反编译在软件著作权侵权诉讼中的法律地位。《计算机软件保护条例》第三条规定，同一计算机程序的源程序和目标程序为同一作品。这意味着，对目标程序（如二进制代码）的分析，在法律上等同于对软件作品本身的分析。这为通过反编译探究软件内部表达提供了合法性前提。

在（2008）苏民三终字第79号案中，江苏省高级人民法院面对嵌入式软件无法直接比对源程序的困境，采纳了鉴定机构将源程序编译为二进制代码、再与芯片中读出的目标程序逐段比对的方法，明确指出：“不同的C源程序不可能生成相同的二进制代码”。这一论述确立了二进制代码比对在特定场景下的科学性与可采性。

更进一步的信号来自最高人民法院第49号指导案例（石鸿林案）。该案中，由于被告软件目标程序存储于加密芯片无法读取，法院综合软件运行中出现的相同系统缺陷、特征性运行情况等间接证据，推定双方软件构成实质性相似，并明确“在被告无正当理由拒不提供源程序时，应合理降低权利人的证明标准”。这一裁判逻辑为反编译手段的运用打开了空间——当被告不配合时，通过技术手段从目标程序中挖掘出的“代码指纹”便成为打破僵局的关键。

二、藏在二进制深处的“罪证”：必须反编译才能发现的五类内容

结合最高院近年判决及实务经验，以下内容通常深藏于二进制代码底层，未经反编译分析绝难发现，却是证明实质性相似的“王牌证据”。

1. 特定注释、开发者标识及无功能字符串

开发者在源代码中留下的注释、日志输出字符串、甚至调侃性备注，在编译后虽失去可读性，但仍以字符串常量形式存在于数据段。在（2024）最高法知民终704号案中，最高院认定被诉侵权软件中间代码中多处出现“th**”“xyz”“kommidi”等与权利软件相同的字符串，且这些字符串与软件功能无实质性关联。法院认为，在代码整体实质性相似比例较高的情况下，此类标识性字符串的出现，结合被告未作合理解释，可以构成认定实质性相似的“高度盖然性”因素。

实务启示：权利人可在反编译后，使用字符串搜索工具（如strings命令）扫描被诉软件，查找与己方相关的特定公司缩写、开发者姓名拼音、内部项目代号等。这些“意外遗留”往往成为被告难以辩驳的证据。

2. 独特的变量、函数命名规则与代码结构特征

每个开发团队都有其编码习惯：驼峰命名、匈牙利命名、拼音缩写混用、甚至拼写错误。这些在源代码层面一目了然的特征，经过编译后变量名通常被抹去，但借助AI反编译工具（如LLM4Decompile）可部分还原。在（2023）最高法知民终885号案中，原告主张被告软件存在与其相同的“函数名称英文使用错误”，“未严格遵循驼峰命名法”等特征。尽管该案因原告保护范围过窄未认定侵权，但最高院并未否定此类特征作为比对对象的适格性，而是强调需区分有限表达与独创性表达。

需注意《计算机软件保护条例》第二十九条的边界：因表达方式有限而相似的不构成侵权。因此，在组织证据时，应重点筛选非行业惯例、明显带有个人风格的命名与结构，并辅以技术专家论证其独创性。

3. 核心算法逻辑与数据结构的具体实现

这是软件独创性表达的“内核”。单纯比对二进制文件的哈希值或字节相似度，可能因编译器优化、地址偏移产生巨大差异而掩盖逻辑一致性。反编译可将机器指令转化为汇编代码或伪代码，进而分析控制流图、函数调用关系、数据流。

在（2008）苏民三终字第79号案中，法院正是通过二进制代码逐段比对，确认了代码逻辑层的实质性相似。而（2024）最高法知民终704号案则通过抓包获取的“中间代码”比对，发现双方“涉及钢琴陪练核心功能的相同函数以及相同的变量定义”，最终作出侵权认定。

4. 相同的系统缺陷与特征性运行情况

独立开发的两个软件出现完全相同的非必要缺陷，概率极低。石鸿林案中，法院将“相同的系统软件缺陷”和“加电运行时相同的特征性情况”作为认定实质性相似的重要依据。这类缺陷的根源往往在于源代码中的逻辑错误或非标准实现，要证明其对应性，通常需要反编译定位引发缺陷的具体指令序列，并与权利软件中的缺陷代码进行比较。若被告无法合理解释，则可形成强有力的证据链。

5. 嵌入的特定权利管理信息或商业秘密标记

软件中可能包含版权声明、授权校验代码、甚至隐蔽的“后门”或水印。根据最高人民法院第48批指导性案例要旨，对于芯片软件侵权，应以二进制代码为比对客体，并完善商业秘密证据的取证方法。实践中，权利人可通过反编译分析被诉软件，查找是否包含己方的版权标识代码、特殊算法参数等。此类信息一旦发现，既可证明接触可能性，又能直接指向抄袭。

三、实务建议：如何让反编译证据在法庭上“说话”

确保取证过程合法规范：通过公证购买被诉产品，委托有资质的司法鉴定机构进行反编译操作，全程录像，确保检材同一性。

合理选择比对维度：不应仅局限于代码字面相似度，而应结合字符串匹配、函数调用图相似度、缺陷复现逻辑等多维度综合分析。

善用举证妨碍规则：当被告无正当理由拒不提供源代码时，可援引《最高人民法院关于知识产权民事诉讼证据的若干规定》第二十五条，主张法院适用举证妨碍，推定权利人主张成立。

注意反向工程的合法边界：《最高人民法院关于审理侵犯商业秘密民事案件适用法律若干问题的规定》第十四条明确，通过反向工程获取技术信息不构成侵犯商业秘密，但前提是“从公开渠道取得”。若被告曾以不正当手段接触源代码，其反编译抗辩将不被支持。

结语

软件著作权侵权诉讼正从“源代码中心主义”走向“多证据综合判断”。在源代码缺失的情况下，反编译并非可有可无的技术点缀，而是刺破侵权面纱的利刃。处理此类案件，我们既需精通法律条文与裁判规则，也需理解技术原理与证据生成逻辑，方能从纷繁复杂的二进制世界中，提取出足以说服法官的“代码真相”。随着AI反编译技术的演进，这一领域的证据形态与比对方法还将持续演化，值得每一位从业者密切关注。