反编译apk时出现异常

Question

我正在尝试制作一个安全的 Android 应用程序。我在我的应用中启用了 proguard。但它在反编译时不会隐藏任何 xml 文件或清单。它只会更改 .java 文件。

我尝试使用 apktool 从 Play 商店反编译另一个应用的 apk。然后我得到了以下异常

Exception in thread "main" brut.androlib.AndrolibException: brut.directory.Direc
toryException: java.util.zip.ZipException: error in opening zip file
        at brut.androlib.ApkDecoder.hasSources(ApkDecoder.java:199)
        at brut.androlib.ApkDecoder.decode(ApkDecoder.java:83)
        at brut.apktool.Main.cmdDecode(Main.java:146)
        at brut.apktool.Main.main(Main.java:77)
Caused by: brut.directory.DirectoryException: java.util.zip.ZipException: error
in opening zip file
        at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:55)
        at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:38)
        at brut.androlib.res.util.ExtFile.getDirectory(ExtFile.java:55)
        at brut.androlib.ApkDecoder.hasSources(ApkDecoder.java:197)
        ... 3 more
Caused by: java.util.zip.ZipException: error in opening zip file
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at java.util.zip.ZipFile.<init>(Unknown Source)
        at brut.directory.ZipRODirectory.<init>(ZipRODirectory.java:53)
        ... 6 more

然后xml文件和manifest没有显示出来。我也想像这样保护我的应用程序。这怎么可能？

Answer 1

要回答您的问题，让您的 APK 完全安全是不可能的。 XML 文件为easily parsed without apktool。

我问过 Ben Gruver/JesusFreke（开发 smali 的人），他说不可能完全保护 APK 文件，但你可以让其他人更难反编译。只要 Android 可以读取您项目中的资源/代码.. 工具也可以。

您在尝试反编译 Gmail 时看到的异常是因为需要为 Lollipop (which is actively being working on) 更新 apktool。

answer by @classc_abc 是我发现的最好的，它使反编译 APK 变得更加困难：

基本上，有 5 种方法可以保护您的 APK 被破解/ 反转/重新包装：

1. 隔离 Java 程序

最简单的方法是让用户无法访问Java Class 程序。这是最基本的方式，它有多种 实现这一目标的具体方法。例如，开发人员可以将 服务端的关键Java类，客户端通过访问获取服务 服务端相关接口而不是访问Class文件 直接地。所以黑客没有办法反编译Class文件。 目前，标准和协议服务越来越多 通过接口提供，例如HTTP、Web Service、RPC等。但是 有很多应用程序不适合这种保护。 例如，独立程序中的 Java 程序无法 隔离。

1. 加密类文件

为了防止Class文件被直接反编译，很多开发者 会加密一些关键的Class文件，比如注册号、序列号 号码管理和其他相关课程。在使用这些之前 加密的类，程序需要先解密这些类， 然后将这些类加载到 JVM 中。这些类可以通过以下方式解密 硬件或软件。

开发人员经常通过自定义加载加密类 ClassLoader 类（Applet 不支持自定义 ClassLoader 因为安全）。自定义的 ClassLoader 会发现加密的 首先类，然后解密它们。最后加载解密的 类到 JVM。 Customed ClassLoader 是其中一个非常重要的类 保护方法。因为它本身没有加密，它可能是 黑客的第一个目标。如果相关的解密密钥和算法 已被克服，那么加密的类可以很容易地 解密。

1. 转换为本机代码

将程序转换为本机代码也是防止 反编译。因为本地代码通常很难 反编译。开发人员可以将整个应用程序转换为原生 代码，或者他们也可以只转换关键模块。如果只是转换密钥 部分模块，Java时需要JNI技术调用 程序正在使用这些模块。它抛弃了Java的跨平台 使用此方法保护 Java 程序时的功能。对于不同的 平台，我们需要维护不同版本的原生代码， 这将增加软件支持和维护工作量。但对于 一些关键模块，有时这种解决方案往往是必要的。为了 保证这些本地代码不会被修改或替换， 开发人员通常需要对这些代码进行数字签名。使用前 这些原生代码，开发者往往需要对这些本地代码进行身份验证 代码，以确保这些代码没有被黑客更改。如果 签名校验通过，开发者可以调用相关的JNI 方法。

4. 代码混淆

代码混淆是对Class文件进行重新组织和处理，使 处理过的代码完成相同的功能（语义） 未经处理的代码。但是混淆代码很难 反编译，即反编译的代码很难 理解，因此反编译人员很难理解 真正的语义。理论上，如果黑客有足够的时间， 混淆的代码仍然可能被破解。甚至有些人在发展 去混淆工具。但从实际情况来看，自 混淆的多元化发展，混淆的成熟 理论上，混淆的 Java 代码可以很好地防止反编译。

5. 在线加密

APK Protect 是一个用于 APK 的在线加密网站。它提供Java 代码和C++代码保护，实现反调试和反编译 效果。操作过程简单易行。

我建议您使用最后一种方法，因为它可以节省您更多的时间。我有 试过了。操作非常简单，不会花很长时间。