android - 反编译apk时出现异常

Question

我正在尝试制作一个安全的 Android 应用程序。我在我的应用中启用了 proguard。但它在反编译时不会隐藏任何 xml 文件或 list 。它只更改 .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 文件和 list 没有被泄露。我也想像这样保护我的应用程序。这怎么可能？

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 更难的最好方法:

Basically, there are 5 methods to protect your APK being cracking/ reversing/ repackaging:

1. Isolate Java Program

The easiest way is to make users unable to access to the Java Class program. This is the most fundamental way, and it has a variety of specific ways to achieve this. For example, developers can place the key Java Class on the server, clients acquire services by access relevant interfaces of the server rather than access to the Class file directly. So there is no way for hackers to decompile Class files. Currently, there are more and more standards and protocols services provided through interfaces, such as HTTP, Web Service, RPC, etc. But there are lots of applications are not suitable for this protection. For example, Java programs in stand-alone programs are unable to isolate.

2. Encrypt Class Files

To prevent Class files from being decompiled directly, many developers will encrypt some key Class files, such as registration number, serial number management and other related classes. Before using these encrypted classes, the program needs to decrypt these classes first, then loading these classes into JVM. These classes can be decrypted by hardware, or software.

Developers often loading cryptographic classes through a customed ClassLoader class (Applet does not support customed ClassLoader because of security). Customed ClassLoader will find cryptographic classes first, then decrypt them. And finally loading the decrypted classes to JVM. Customed ClassLoader is a very important class in this protect method. Because it itself is not encrypted, it may be the first target of a hacker. If the relevant decryption key and algorithm have been overcome, then the encrypted classes can easily be decrypted.

3. Convert to Native Codes

Convert program to native codes is also an effective way to prevent decompilation. Because native codes are often difficult to be decompiled. Developers can convert the entire application to native codes, or they can also convert only key modules. If just convert key part of the modules, it will need JNI technology to call when Java programs are using these modules. It abandoned Java's cross-platform feature when using this mothod to protect Java programs. For different platforms, we need to maintain different versions of the native codes, which will increase software support and maintenance workload. But for some key modules, sometimes this solution is often necessary. In order to guarantee these native codes will not be modified or replaced, developers often need to digitally sign these codes. Before using these native codes, developers often need to authenticate these local codes to ensure that these codes have not changed by hackers. If the signature check is passed, then developers can call relevant JNI methods.

4. Code Obfuscation

Code obfuscation is to re-organize and process Class file, making the treated codes accomplish the same function (semantics) with the untreated codes. But the obfuscated codes are difficult to be decompiled, i.e., the decompiled codes are very difficult to understand, therefore decompile staffs are hard to understand the really semantics. Theoretically, if hackers have enough time, obfuscated codes may still be cracked. Even some people are developing de-obfuscate tool. But from the actual situation, since the diversified development of obfuscation, the mature of obfuscation theory, obfuscated Java codes can well prevent decompilation.

5. Online Encryption

APK Protect is an online encryption website for APK. It provides Java codes and C++ codes protection to achieve anti-debugging and decompile effects. The operation process is simple and easy.

I suggest you use this last method for it can save you more time. I've tried. It is very simple to operate and it won't take long time.