Android反编译器:良性和恶意应用程序上的性能

良性和恶意应用程序上的 Android 反编译器性能

反编译器是 Android 恶意软件分析和应用安全审核中不可或缺的工具。许多学术著作也使用Android反编译器作为程序分析管道的第一步。在这种情况下，反编译通常被视为一个“已解决”的问题，因为人们只是期望可以从应用程序中准确地恢复源代码。

另一方面，众所周知，例如，混淆会对反编译器的有效性产生负面影响。因此，为了更好地了解涉及反编译的自动分析管道的潜在故障模式，必须表征反编译器在良性和恶意应用程序上的性能。

为此，据我们所知，我们使用三组应用程序进行了首次大规模研究 Android 反编译失败率。即，3，018个开源应用程序，13，601个从Google Play抓取的应用程序，以及现有的24553个恶意软件样本集合。

除了最先进的Dalvik字节码反编译器Jadx之外，我们还研究了三种流行的Java反编译器的性能。此外，还介绍了对 54945 个恶意软件应用程序的后续研究的结果，我们还对反编译失败的原因进行了分析。

反编译器，即可以从程序二进制文件重建源代码的工具，在对恶意软件进行逆向工程或执行软件安全审计时是无处不在的辅助工具。在 Android 平台上，反编译器还广泛用于在手动或自动检查之前将 Android 应用程序的 Dalvik 字节码提升到 Java 源代码中。

一般来说，与本机代码反编译相比，从 Dalvik 字节码重建源代码的挑战性要小得多。这是因为由于Android系统对Dalvik字节码的限制，许多反编译本机机器码的障碍都被消除了。例如，简单地从本机二进制文件中恢复正确的汇编代码列表本身就是一个不可判定的问题，因为代码和数据可以穿插。

反编译器的典型使用模型对于本机代码和 Dalvik 字节码不同：虽然人们普遍认为本机代码反编译器在许多情况下无法重建语法和语义正确的源代码，因此最好用作手动逆向工程的辅助工具，但 Dalvik 字节码反编译通常被认为是一个“已解决”的问题， 可以简单地预期正确的 Java 源代码可以从 DEX 文件完全重建。

虽然控制流混淆在 Dalvik 字节码中可能比在本机代码中更罕见，但由于上述寄存器类型冲突问题，问题仍然存在：在分析 Android 平台的恶意软件或商业应用程序时，反编译破坏混淆在多大程度上是一个问题。

应该注意的是，Android 应用程序还可以包含本机代码组件，其反编译与其他本机代码二进制文件面临相同的挑战，并且也可能受到控制流混淆的影响。但是，由于本机代码反编译的局限性已经得到了很好的研究，并且由于本机代码反编译的使用模型非常不同，因此我们选择将重点限制在Dalvik字节码反编译上。

我们首先从三个不同的来源收集APK，以研究不同类型应用程序的反编译特征。我们从 F-Droid 存储库中收集了 3018 个开源应用程序以及来自Google Play商店的13601个应用程序。最后，我们使用了由Wei等人编译的现有Android恶意软件数据集（AMD）。

从 F-Droid 存储库中检索应用非常简单，因为可以简单地枚举和下载所有应用。但是，Google Play商店不允许批量下载应用程序。因此，与之前的工作类似，我们必须通过对内部Google Play API进行部分逆向工程来实现自定义爬虫。

在下一步中，将使用四个不同的反编译器对每个应用进行反编译。除了最先进的原生Android反编译器Jadx之外，我们还使用了三种流行的Java反编译器CFR，在调用 Java 反编译器之前，我们使用 dex2jar 将每个应用程序的 Dalvik 字节码转换为 JVM 字节码。如果失败，来自每个反编译器的错误消息将馈送到自定义解析器，该解析器记录反编译失败的方法。

为了比较反编译器的每个方法的性能，我们方法的最后一步是统一反编译器输出。我们首先使用 apkanalyzer 提取应用程序中，每种方法来自安卓软件开发工具包。我们使用此方法签名列表作为参考点，并将这些签名与每个反编译器的失败方法进行匹配。

每个应用程序的方法总数以及每个方法的大小（即方法字节码的大小）也使用 apkanalyzer 确定。由于所有反编译器在其错误报告中对方法签名使用略有不同的格式，因此我们首先对失败的签名进行预处理，使其具有统一的格式。

我们还必须对CFR进行一些修改，以便它输出有关无法反编译的方法的足够信息。最后，我们对统一签名进行简单的文本匹配。

最终表明，反编译器的失败率通常非常低，良性应用程序上的故障似乎很少与混淆有关。然而，在恶意软件上，混淆似乎是导致失败的一个更突出的原因，尽管绝大多数恶意应用程序仍然可以由一组反编译器完全反编译。