java - 如何检查二进制文件是否是从特定来源构建的

Question

我正在处理的遗留项目包括一些二进制 jar 文件形式的外部库。我们决定，为了分析和潜在的补丁，我们希望接收该库的源代码，使用它们构建新的二进制文件，并在经过详细和足够长的回归测试后切换到这些二进制文件。

假设我们已经检索并构建了源(我实际上正处于计划阶段)。在实际测试之前，我想执行一些“兼容性检查”以排除源代表与“旧”二进制文件中的内容截然不同的东西的可能性。

使用 javap 工具，我能够提取用于编译的 JDK 版本(至少我相信它是 JDK 的版本)。它说，二进制文件是使用主要版本 46 和次要版本 0 构建的。根据 this article它映射到 JDK 1.2。

假设相同的 JDK 将用于源代码编译。

问题是:如果这两个二进制文件都是从相同的来源构建的，是否有可靠且可能有效的验证方法？我想知道是否所有方法签名和类定义都相同，以及大多数或可能所有方法实现是否相同/相似。

库很大，所以我认为对反编译的二进制文件进行详分割析可能不是一种选择。

Answer 1

我建议采用多阶段流程:

应用之前建议的 Jardiff 或类似的，看看是否有任何 API 差异。如果可能，选择一个具有报告私有(private)方法等选项的工具。在实践中，Java 中的任何实质性实现更改都可能会更改某些方法和类，即使公共(public) API 未更改也是如此。

如果你有一个 API 匹配，用指定的编译器编译一些随机选择的文件，反编译结果和原始类文件，并比较结果。如果它们匹配，则将相同的过程应用于越来越大的代码体，直到您发现不匹配或检查了所有内容。

与实际的类文件相比，反编译代码的差异更有可能为您提供有关差异性质的线索，并且更容易过滤非显着差异。

如果发现不匹配，请进行分析。这可能是由于您不关心的事情。如果是这样，请尝试构建一个脚本来删除这种形式的差异并恢复编译和比较过程。如果出现广泛的不匹配，请尝试使用优化等编译器参数。如果对编译器参数的调整消除了差异，则继续进行批量比较。此阶段的目标是找到在示例文件上产生匹配的编译器参数和反编译代码过滤器的组合，并将它们应用于库的批量比较。

如果您无法在反编译代码中获得相当接近的匹配，您可能没有正确的源代码。即便如此，如果您有一个 API 匹配，那么构建您的系统并使用编译结果运行您的测试可能是值得的。如果您的测试至少与您从源代码构建的版本运行得一样好，请继续使用它。