Apk manager ошибка 21 при декомпиляции

E: footer is wrong
Update package verification took 0.1s (result 1).
E: Signature verification failed
E: error 21

Install from ADB completed with status 2
Installation aborted

Load 7 more related questions

Show fewer related questions

На платформе Mac некое платное приложение было декомпилировано с использованием технологии Weex. Обнаружил, что декомпиляция прошла неудачно

Процесс выглядит следующим образом

1. Декомпилировать apk
   java -jar apktool_2.3.0.jar d xxx_1.0.0_beta_offical.apk

2. Перекомпилировать (перепаковать измененный файл в apk)
   java -jar apktool_2.3.0.jar b xxx_1.0.0_beta_offical

3. Установить на телефон для отладки после подписания

Оказывается, второй шаг всегда неудачен, и найтиhttps://github.com/iBotPeaches/Apktool/issues/1425 Эта проблема обнаруженаАвторупомянул

Seems you might have an outdated framework. Make sure to run apktool empty-framework-dir --force to refresh those.

Полный ответ таков

➜  Bug1425 apktool d app-debug.apk 
I: Using Apktool 2.2.2 on app-debug.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /home/ibotpeaches/.local/share/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
➜  Bug1425 apktool b app-debug
I: Using Apktool 2.2.2
I: Checking whether sources has changed...
I: Smaling smali folder into classes.dex...
I: Checking whether resources has changed...
I: Building resources...
I: Building apk file...
I: Copying unknown files/dir...
➜  Bug1425 

Говорят, что фреймворк устарел и должен быть/home/ibotpeaches/.local/share/apktoolПод каталогом (этот каталог появился в процессе декомпиляции первого шага, то есть каталог, который вам нужно повторно запустить) повторно выполнитьapktool empty-framework-dir --force

Затем повторите эти три шага, чтобы полностью решить проблему.

Специально запись

To answer your question, it is simply impossible to make your APK fully secure. XML files are easily parsed without apktool.

I asked Ben Gruver/JesusFreke (the guy who developed smali) and he said it is impossible to fully secure an APK file, but you can make it harder for others to decompile. As long as Android can read the resources/code in your project.. then so can tools.

The exception you are seeing while attempting to decompile Gmail is because apktool needs to be updated for Lollipop (which is actively being working on).

The answer by @classc_abc is the best I found for making it harder to decompile an 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.

1. 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.

1. 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.

1. 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.

1. 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.

Я пытаюсь декомпилировать apk. но я сталкиваюсь с этой ошибкой:

Could not find the main class: brut.apktool.Main. Program will exit.
Exception in thread "main" -----------------------------------------------------
---------------------
|Wed 02/26/2014 --  0:25:58.98|
--------------------------------------------------------------------------
java version "1.6.0_39"
Java(TM) SE Runtime Environment (build 1.6.0_39-b04)
Java HotSpot(TM) Client VM (build 20.14-b01, mixed mode, sharing)
java.lang.UnsupportedClassVersionError: brut/apktool/Main : Unsupported major.mi
nor version 51.0
        at java.lang.ClassLoader.defineClass1(Native Method)
        at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
1)
        at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
        at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
        at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
        at java.security.AccessController.doPrivileged(Native Method)
        at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
        at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
Could not find the main class: brut.apktool.Main. Program will exit.
Exception in thread "main" Press any key to continue . . .

Любое тело знает, что такое brut.apktool.Main и как я могу его исправить?

РЕДАКТИРОВАТЬ

Я установил jdk 1.7 и изменил значения JAV_HOME и PATH, и теперь я получаю эту ошибку:

    --------------------------------------------------------------------------
java version "1.7.0_51"
Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
Press any key to continue . . .