【问题标题】:Why .Jar decompiling result is different in decompilers?为什么 .Jar 反编译结果在反编译器中不同?
【发布时间】:2017-07-03 16:10:25
【问题描述】:

我用两个反编译器JD-GUI和Luyten反编译了.jar文件,但是结果不一样。

例如,来自 Luyten 的结果具有更具体的命名空间。

源代码在某些行中也有所不同。

为什么两个反编译器对同一个 .jar 文件进行不同的反编译?

【问题讨论】:

  • 因为有多个可能的 Java 源代码可以产生相同的字节码。
  • 产生完全相同字节码的"java源代码"之间的唯一区别是基于语法。 rick 正在查看的字节码已经被编译。反编译器以不同的方式处理翻译。例如,如果您要将 JD-GUI、CFR、Procyon 和 Fernflower 的输出复制粘贴到 java 文件中并编译它,它们将不会生成完全相同的字节码。当然它会发挥相同的作用(不包括边缘情况),但这不是重点。关键是任何两个反编译器将字节码翻译回java的过程都是不同的。

标签: jar decompiling jd-gui


【解决方案1】:

您列出的反编译器使用不同的后端来处理 java 字节码的解析。

  • Luyten 使用Procyon
  • JD-GUI 使用 JD-Core(无可用源)

您可以将反编译器想象成不同的学者将古代文本翻译成现代英语。学者“Luyten”“JD-GUI”转录的源材料是相同的,但每个学者转录文本的方式不同。两者都创造了通常相当清晰的现代英语,但每个都有自己的细微差别。

例如:如果古代的资料说"a man reached down and picked up an apple",学者们可能会说:

那人捡起一个苹果。

那个男人抓了一个苹果。

两者都能理解含义,但略有不同。有时一个人可能比另一个人更了解源材料的奇怪之处,因此会产生比另一个人更准确的结果。

例如,JD-GUI can't decompile a method if the last instruction of a method is the last one in a try-catch block 但 Procyon 可以将其翻译成 java 就好了。

【讨论】:

    猜你喜欢
    • 2020-08-22
    • 1970-01-01
    • 2021-02-20
    • 1970-01-01
    • 2020-09-29
    • 2023-03-18
    • 1970-01-01
    • 1970-01-01
    • 2015-02-20
    相关资源
    最近更新 更多