Skip to content

小测一下,结果不算好 #2

Description

@midpoint

实测对比(同一个 APK:我们的 lab 包)

┌────────────────┬───────────┬────────────┐
│ │ ddc 0.1.4 │ jadx 1.5.5 │
├────────────────┼───────────┼────────────┤
│ 耗时 │ 0.012s │ 3.0s │
├────────────────┼───────────┼────────────┤
│ 输出文件 │ 12 │ 12 │
├────────────────┼───────────┼────────────┤
│ javac 编译错误 │ 100 │ 1 │
└────────────────┴───────────┴────────────┘

速度快了约 250 倍,但输出质量的差距是数量级的。

ddc 的具体问题(都来自同一个方法 Obf.s):

// ddc 输出 —— 编不过
if (null != 0) { // 应为 if (enc != null)
...
v9 = v10; // v8/v9 从未声明
} else {
return 0; // String 方法返回 int
}

// jadx 输出 —— 与源码几乎一致
if (bArr == null) return null;
char[] cArr = new char[bArr.length];
for (int i3 = 0; i3 < bArr.length; i3++)
cArr[i3] = (char) (((bArr[i3] & 255) ^ i2) ^ ((i3 * 31) & 255));

错误是系统性的,不是零星 bug:PackageInfo 被当成 PackageManager、boolean 被解引用、byte[]↔String 互转、return outside method。另外嵌套类 Guard$Report
整个没被产出,导致所有引用它的地方都编不过。

我排除了输入因素:把 dex 换成 d8 默认模式(不带 --release)重生成,结果一模一样。

建议

  1. 别删 jadx。 「替换」在这里没有依据——jadx 在同一个输入上只差 1 个错误,那 1 个还是 catch 块的局部变量问题,手工修 5 秒。
  2. ddc 留着当快筛工具。 它的价值在速度:-l 列类名、-c 单类反编译、以及那 20 多个查询子命令,用来快速摸清一个 APK 的结构很合适。真要读代码还是回 jadx。
  3. README 那句「1.09M 文件 javac 零语法错误」要当成有范围的。 那是他们自己的 7 个 benchmark APK 上的结果,不能推广——在我们这个 12 类的小包上就崩了。它现在还只是 v0.1.4。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions