A simple way to modify the Android application
It happens after the release of the application of its source code somewhere disappear. True, it happens all the time? And nothing remains but to decompile it and correct a few hundred lines of code and all this needs to be done as quickly as possible.
So I had the task to modify the application with just its apk. And those who have been decompiling applications know how hard it is to compile it later.
For Android, the following utilities exist:
Information on their use on the Internet is enough.
If you try to build an application after decompiling, then most likely it will not compile because of errors, cycles and conditions are especially hard to decompile. Some errors are easily corrected, but again it will not be easy to understand the multitude of conditional transitions, and when their number is more than one hundred or even several thousand, then this way to restore the application loses its efficiency, it is faster to write everything anew.
')
It was at this point that the experiments with decompilation could be completed, but laziness was the engine of progress and a new method was born.
So jar is a library, so why not just connect it to a new project? We throw it into the libs folder, inherit from the main activation and compile. Everything works, the main thing is that the class names do not match, so the package names should be different, or at least the generated BuildConfig and R will match.
In this way, you can inherit from Activity, Service, BroadcastReceiver, and possibly some other classes declared in the manifest. You will also need to specify new class names in the manifest, otherwise they will not be used.
Now you can redefine virtual functions, but only, all the more so, the final keyword will not allow this to be done and inherited too, so we go further.
Having unzipped the jar library, we get class files, these are compiled classes, note that when building a project in the bin / classes folder, the same class files lie, and what if you slip the files from the library there ...
Not everything is so simple, first you need to compile the project. To use the classes of the original application, you need to somehow attach it to the project, but not export. This is done simply: from the libs folder Eclipse itself exports libraries, so move the jar library to the lib folder and connect it to the project, in Eclipse it is Project-> Preferences-> Java Build Path-> Libraries-> Add Jars ... further in the Order and Export tab you need to make sure that the checkbox is not set, because we do not need to export the library, everything will be in the class files.
Now we take some class from the decompiled source of the application, fix the compilation errors in it, add, for example, show a dialog to make sure that the new class is used. Next, we clear the project, in Eclipse it is Project-> Clean, copy the class files into the bin / classes folder, build the project and everything works!
With the following builds of the project there is no need to clean it up, so using this method is quite convenient. To make it easier to correct errors after decompiling, I used the sources from JD-GUI and JAD, which was usually enough.
But now the time has come to collect the release version, and for it, of course, the obfuscator is used and it will give out hundreds of errors for class name matches and unresolved references. Now it's time to remove the classes that have been replaced from the compiled class files, there should be no errors after that. Another unpleasant feature of the release build is that you need to clear the project each time and copy the class files, otherwise they disappear somewhere.
In this way, only modified files are decompiled, which eliminates the correction of errors in all source codes and improves reliability, since all part of the code will undergo a process of decompilation - correction - compilation.
Most likely, it will not be possible to hide all traces from the original application, the names of non-obfuscated classes such as Activity and Service, as well as the names of their packages will be preserved and will be available after decompiling the modified application, but for pirated versions this is not a problem, which is why it is worth protecting application protection methods are similar to other methods of protection against code changes.
Updating classes in jar - the idea of replacing classes came from this feature for the jar library.
So I had the task to modify the application with just its apk. And those who have been decompiling applications know how hard it is to compile it later.
Decompilation
For Android, the following utilities exist:
- ApkTool for decompiling resources.
- Dex2Jar to convert dex to jar.
- JD-GUI for getting sources from jar.
- I also recommend JAD , some places are better decompiled than JD-GUI.
Information on their use on the Internet is enough.
If you try to build an application after decompiling, then most likely it will not compile because of errors, cycles and conditions are especially hard to decompile. Some errors are easily corrected, but again it will not be easy to understand the multitude of conditional transitions, and when their number is more than one hundred or even several thousand, then this way to restore the application loses its efficiency, it is faster to write everything anew.
')
It was at this point that the experiments with decompilation could be completed, but laziness was the engine of progress and a new method was born.
Class overrides
So jar is a library, so why not just connect it to a new project? We throw it into the libs folder, inherit from the main activation and compile. Everything works, the main thing is that the class names do not match, so the package names should be different, or at least the generated BuildConfig and R will match.
In this way, you can inherit from Activity, Service, BroadcastReceiver, and possibly some other classes declared in the manifest. You will also need to specify new class names in the manifest, otherwise they will not be used.
Now you can redefine virtual functions, but only, all the more so, the final keyword will not allow this to be done and inherited too, so we go further.
Class replacement
Having unzipped the jar library, we get class files, these are compiled classes, note that when building a project in the bin / classes folder, the same class files lie, and what if you slip the files from the library there ...
Not everything is so simple, first you need to compile the project. To use the classes of the original application, you need to somehow attach it to the project, but not export. This is done simply: from the libs folder Eclipse itself exports libraries, so move the jar library to the lib folder and connect it to the project, in Eclipse it is Project-> Preferences-> Java Build Path-> Libraries-> Add Jars ... further in the Order and Export tab you need to make sure that the checkbox is not set, because we do not need to export the library, everything will be in the class files.
Now we take some class from the decompiled source of the application, fix the compilation errors in it, add, for example, show a dialog to make sure that the new class is used. Next, we clear the project, in Eclipse it is Project-> Clean, copy the class files into the bin / classes folder, build the project and everything works!
With the following builds of the project there is no need to clean it up, so using this method is quite convenient. To make it easier to correct errors after decompiling, I used the sources from JD-GUI and JAD, which was usually enough.
But now the time has come to collect the release version, and for it, of course, the obfuscator is used and it will give out hundreds of errors for class name matches and unresolved references. Now it's time to remove the classes that have been replaced from the compiled class files, there should be no errors after that. Another unpleasant feature of the release build is that you need to clear the project each time and copy the class files, otherwise they disappear somewhere.
Conclusion
In this way, only modified files are decompiled, which eliminates the correction of errors in all source codes and improves reliability, since all part of the code will undergo a process of decompilation - correction - compilation.
Most likely, it will not be possible to hide all traces from the original application, the names of non-obfuscated classes such as Activity and Service, as well as the names of their packages will be preserved and will be available after decompiling the modified application, but for pirated versions this is not a problem, which is why it is worth protecting application protection methods are similar to other methods of protection against code changes.
Updating classes in jar - the idea of replacing classes came from this feature for the jar library.
Source: https://habr.com/ru/post/212341/
All Articles