疑似软件版权侵权的技术取证与代码篡改相关问询

问题1：对方是否可能基于我的可执行文件重新编译，使其二进制不同但仍可正常运行？ #

完全有可能，常见实现方式包括：

• 源码修改后重编译：若对方获取你的源码（或通过反编译还原的近似源码），修改变量/函数名、调整语句顺序、添加无意义代码，再用不同编译器版本、优化选项（如-O0/-O3）或链接参数编译，生成的二进制会与原文件逐字节不同，但功能一致。
• 二进制混淆/加壳：直接对你的二进制文件使用混淆工具（如自定义异或混淆、VMProtect），破坏ELF头部标识，导致Ida无法自动识别格式，只能以Binary模式打开，但运行时会自动还原逻辑，不影响功能，你提到的疑似异或混淆就属于这类情况。
• 重新链接/打包：替换程序依赖的第三方库版本、调整段表/符号表信息，也会造成二进制差异，但核心逻辑不变。

问题2：从技术角度如何收集侵权证据，尤其是获取二进制相似性相关证据？ #

可从多维度开展证据收集：

非二进制层面的一致性佐证 #

• 对比系统库、辅助文件的文件名、目录结构、文件格式：比如配置文件的键值对规则、资源文件（图标、文本）内容，这类信息通常不会被修改，可作为间接侵权证据。
• 录制双方程序的运行行为：用strace捕获系统调用序列，对比操作流程、输出日志、核心功能的执行结果，若完全匹配，可佐证功能同源。

二进制相似性分析 #

• 修复对方二进制结构：参照你的ELF64文件头部格式，补全对方二进制缺失的标识字段，让Ida能识别为ELF格式，再手动定位入口点，分析函数控制流。重点对比双方的函数流程图、字符串常量、全局变量结构——核心逻辑的分支、循环结构很难通过混淆完全篡改。
• 使用专业对比工具：
  • 用diff命令对比双方十六进制片段，聚焦未被混淆的区域（如固定魔法值、字符串常量区）。
  • 用BinDiff将你的Ida反编译数据库与对方还原后的二进制对比，工具会自动识别相似函数结构、控制流，生成相似性报告；或用radare2进行批量函数对比。
• 混淆还原：针对疑似异或混淆的部分，对比双方同功能模块的十六进制数据，反推异或密钥，还原对方原始二进制后再与你的文件做直接对比。

证据固化 #

• 用sha256sum生成侵权软件、系统镜像的哈希值，录制操作视频，防止证据被篡改。
• 整理Ida反编译截图、二进制对比报告、运行行为记录为可复现的文档，确保证据链完整。

内容的提问来源于stack exchange，提问作者AndroC