Java rebuild android app for windows. An easy way to modify an Android application

Sometimes some applications on Android do not suit the user for some reason. An example is annoying ads. And it happens that way - everyone is good at the program, but only the translation in it is either crooked, or completely absent. Or, for example, the program is trial, but there is no way to get the full version. How to change the situation?

Introduction

In this article, we will talk about how to disassemble an APK with an application, look at its internal structure, disassemble and decompile the bytecode, and also try to make several changes to applications that can bring us this or that benefit.

To do all this yourself, you will need at least a basic knowledge of the Java language, in which Android applications are written, and the XML language, which is used everywhere in Android - from describing the application itself and its access rights to storing strings that will be displayed on the screen. You will also need the ability to handle specialized console software.

So, what is the APK package in which absolutely all software for Android is distributed?

Application decompilation

In the article, we only worked with disassembled application code, however, if you make more serious changes to large applications, it will be much more difficult to understand the smali code. Fortunately, we can decompile the dex code into Java code, which, although not original and not compilable back, is much easier to read and understand the logic of the application. To do this, we need two tools:

• dex2jar - translator of Dalvik bytecode to JVM bytecode, based on which we can get Java code;
• jd-gui is a decompiler itself that allows you to get readable Java code from JVM bytecode. Alternatively, you can use Jad (www.varanecas.com/jad); although it is quite old, in some cases it generates more readable code than Jd-gui.

They should be used like this. First, we launch dex2jar, specifying the path to the apk package as an argument:

%dex2jar.sh mail.apk

As a result, the mail.jar Java package will appear in the current directory, which can already be opened in jd-gui to view the Java code.

Arranging APK packages and getting them

An Android application package is essentially a regular ZIP file that does not require any special tools to view the contents and unpack. It is enough to have an archiver - 7zip for Windows or console unzip in Linux. But that's about the wrapper. What's inside? Inside, we generally have the following structure:

• META-INF/- contains a digital certificate of the application, certifying its creator, and checksums of the package files;
• res/ - various resources that the application uses in its work, such as images, a declarative description of the interface, and other data;
• AndroidManifest.xml- description of the application. This includes, for example, the list of required permissions, the required version of Android, and the required screen resolution;
• classes.dex- compiled application bytecode for the Dalvik virtual machine;
• resources.arsc- also resources, but of a different kind - in particular, strings (yes, this file can be used for Russification!).

The listed files and directories are, if not in all, then, perhaps, in the vast majority of APKs. However, there are a few more less common files/directories worth mentioning:

• assets- analogue of resources. The main difference is that to access a resource, you need to know its identifier, while the list of assets can be obtained dynamically using the AssetManager.list() method in the application code;
• lib- native Linux libraries written with the help of NDK (Native Development Kit).

This directory is used by game manufacturers, where they put their game engine written in C/C++, as well as by creators of high-performance applications (for example, Google Chrome). Understood the device. But how to get the package file of the application of interest? Since it is not possible to get APK files from the device without rooting (they are in the / data / app directory), and rooting is not always advisable, there are at least three ways to get the application file to your computer:

• APK Downloader extension for Chrome;
• Real APK Leecher app;
• various file hosting and warezniki.

Which one to use is a matter of taste; we prefer to use separate applications, so we will describe the use of Real APK Leecher, especially since it is written in Java and, accordingly, it will work even in Windows, even in nix.

After starting the program, you need to fill in three fields: Email, Password and Device ID - and select a language. The first two are the e-mail and password of your Google account that you use on the device. The third is the device ID, and you can get it by dialing the code on the dialer # #8255## and then finding the line Device ID. When filling out, you need to enter only the ID without the android- prefix.

After filling in and saving, the message “Error while connecting to server” often pops up. It has nothing to do with Google Play, so feel free to ignore it and look for packages that interest you.

Review and modification

Let's say you found a package you are interested in, downloaded it, unpacked it ... and when you tried to view some XML file, you were surprised to find that the file is not a text file. How to decompile it and how to work with packages in general? Is it really necessary to install the SDK? No, you don't need to install the SDK. In fact, for all the steps to unpack, modify and package APK packages, the following tools are needed:

• ZIP archiver for unpacking and packing;
• smali- assembler/disassembler of Dalvik virtual machine bytecode (code.google.com/p/smali);
• aapt- a tool for packing resources (by default, resources are stored in binary form to optimize application performance). Included with the Android SDK, but can be obtained separately;
• Signer- a tool for digitally signing a modified package (bit.ly/Rmrv4M).

You can use all these tools separately, but this is inconvenient, so it is better to use higher-level software built on their basis. If you're on Linux or Mac OS X, there's a tool called apktool . It allows you to unpack resources into their original form (including binary XML and arsc files), rebuild the package with modified resources, but it does not know how to sign packages, so you will have to run the signer utility manually. Despite the fact that the utility is written in Java, its installation is rather non-standard. First you need to get the jar file itself:

$ cd /tmp $ wget http://bit.ly/WC3OCz $ tar -xjf apktool1.5.1.tar.bz2

$ wget http://bit.ly/WRjEc7 $ tar -xjf apktool-install-linux-r05-ibot.tar.bz2

$ mv apktool.jar ~/bin $ mv apktool-install-linux-r05-ibot/* ~/bin $ export PATH=~/bin:$PATH

If you work on Windows, then there is an excellent tool for it called Virtual Ten Studio , which also accumulates all these tools (including apktool itself), but instead of a CLI interface, it provides the user with an intuitive graphical interface with which to perform operations for unpacking, disassembling and decompiling in a few clicks. This tool is Donation-ware, that is, windows sometimes appear with a proposal to obtain a license, but this, in the end, can be tolerated. It makes no sense to describe it, because you can understand the interface in a few minutes. But apktool, due to its console nature, should be discussed in more detail.

Consider apktool options. In short, there are three main commands: d (decode), b (build) and if (install framework). If everything is clear with the first two commands, then what does the third one, the conditional operator, do? It unpacks the specified UI framework, which is needed when you dissect a system package.

Consider the most interesting options of the first command:

• -s- do not disassemble dex files;
• -r- do not unpack resources;
• -b- do not insert debugging information into the results of disassembling the dex file;
• --frame-path- use the specified UI framework instead of the built-in apktool. Now consider a couple of options for the b command:
• -f- forced assembly without checking changes;
• -a- specify the path to aapt (the tool for building the APK archive) if for some reason you want to use it from another source.

Using apktool is very simple, all you need to do is specify one of the commands and the path to the APK, for example:

$ apktool d mail.apk

After that, all the extracted and disassembled package files will appear in the mail directory.

Preparation. Disable ads

Theory is, of course, good, but why is it needed if we do not know what to do with the unpacked package? Let's try to apply the theory for our own benefit, namely, we modify some software so that it does not show us ads. For example, let it be Virtual Torch - a virtual torch. For us, this software is perfect, because it is full of annoying ads and is simple enough not to get lost in the wilds of code.

So, using one of the above methods, download the application from the market. If you decide to use Virtuous Ten Studio, just open the APK file in the application and unzip it, for which create a project (File -> New project), then select Import File from the context menu of the project. If your choice fell on apktool, then it is enough to execute one command:

$ apktool d com.kauf.particle.virtualtorch.apk

After that, a file tree will appear in the com.kauf.particle.virtualtorch directory, similar to the one described in the previous section, but with an additional smali directory instead of dex files and an apktool.yml file. The first one contains the disassembled code of the application's executable dex file, the second one contains the service information needed by apktool to assemble the package back.

The first place we need to look is, of course, AndroidManifest.xml. And here we immediately meet the following line:

It is easy to guess that she is responsible for granting the application permissions to use the Internet connection. In fact, if we just want to get rid of ads, it will most likely be enough for us to ban the application from the Internet. Let's try to do it. Delete the specified line and try to compile the software using apktool:

$ apktool b com.kauf.particle.virtualtorch

The resulting APK file will appear in the com.kauf.particle.virtualtorch/build/ directory. However, it cannot be installed because it does not have a digital signature and file checksums (it simply does not have a META-INF/ directory). We have to sign the package with the apk-signer utility. Launched. The interface consists of two tabs - on the first (Key Generator) we create keys, on the second (APK Signer) we sign. To create our private key, fill in the following fields:

• Target File- keystore output file; it usually stores one pair of keys;
• Password and Confirm- password for storage;
• Alias- name of the key in the repository;
• Alias ​​password and Confirm- secret key password;
• Validity- Validity period (in years). The default value is optimal.

The remaining fields, in general, are optional - but you must fill in at least one.

WARNING

To sign an application with apk-signer, you must install the Android SDK and specify the full path to it in the application settings.

All information is provided for informational purposes only. Neither the editors nor the author are responsible for any possible harm caused by the materials of this article.

Now you can sign the APK with this key. On the APK Signer tab, select the newly generated file, enter the password, key alias and password for it, then find the APK file and boldly click the "Sign" button. If everything goes well, the package will be signed.

INFO

Since we signed the package with our own key, it will conflict with the original application, which means that when we try to update the software through the market, we will get an error.

Only third-party software needs a digital signature, so if you are modifying system applications that are installed by copying them to the /system/app/ directory, then you do not need to sign them.

After that, we drop the package on the smartphone, install and run. Voila, the ad is gone! Instead, however, a message appeared that we do not have the Internet or do not have the appropriate permissions. In theory, this could be enough, but the message looks annoying, and, to be honest, we just got lucky with a stupid application. A well-written software will most likely clarify its credentials or check for an Internet connection and otherwise simply refuse to start. How to be in this case? Of course, edit the code.

Typically, application authors create special classes for displaying advertisements and call methods of these classes during the launch of the application or one of its "activities" (in simple terms, application screens). Let's try to find these classes. We go to the smali directory, then com (in org there is only the open graphic library cocos2d), then kauf (exactly there, because this is the name of the developer and all his code is there) - and here it is, the marketing directory. Inside we find a bunch of files with the smali extension. These are classes, and the most notable of them is the Ad.smali class, by the name of which it is easy to guess that it displays ads.

We could change the logic of its work, but it would be much easier to stupidly remove calls to any of its methods from the application itself. Therefore, we exit the marketing directory and go to the neighboring particle directory, and then to virtualtorch. The MainActivity.smali file deserves special attention here. This is a standard Android class that is generated by the Android SDK and set as the entry point to the application (analogous to the main function in C). Open the file for editing.

Inside is the smali code (local assembler). It is rather confusing and difficult to read due to its low-level nature, so we will not study it, but simply find all mentions of the Ad class in the code and comment them out. We drive in the string "Ad" in the search and get to line 25:

Field private ad:Lcom/kauf/marketing/Ad;

Here, a field ad is created to store an object of class Ad. We comment by setting the ### sign in front of the line. We continue the search. Line 423:

New-instance v3, Lcom/kauf/marketing/Ad;

This is where the object is created. We comment. We continue the search and find in lines 433, 435, 466, 468, 738, 740, 800 and 802 calls to the methods of the Ad class. We comment. Look like that's it. We save. Now the package needs to be assembled back and checked for its performance and the presence of advertising. For the purity of the experiment, we return the line removed from AndroidManifest.xml, collect the package, sign it and install it.

Our guinea pig. Visible advertising

Op-pa! Advertising disappeared only while the application was running, but remained in the main menu, which we see when we launch the software. So, wait, but the entry point is the MainActivity class, and the advertisement disappeared while the application was running, but remained in the main menu, so the entry point is different? To reveal the true entry point, we reopen the AndroidManifest.xml file. And yes, it contains the following lines:

They tell us (and more importantly, the android) that the activity named Start should be launched in response to the generation of the android.intent.action.MAIN intent (event) from the android.intent.category.LAUNCHER category. This event is generated when you tap on the application icon in the launcher, so it defines the entry point, namely the Start class. Most likely, the programmer first wrote an application without a main menu, the entry point to which was the standard MainActivity class, and then added a new window (activity) containing the menu and described in the Start class, and manually made it an entry point.

We open the file Start.smali and again look for the line "Ad", we find in lines 153 and 155 the mention of the FirstAd class. It is also in the source code and, judging by the name, it is responsible for displaying ads on the main screen. We look further, there is a creation of an instance of the FirstAd class and an intent, according to the context related to this instance, and then the label cond_10, the conditional transition to which is carried out exactly before creating an instance of the class:

If-ne p1, v0, :cond_10 .line 74 new-instance v0, Landroid/content/Intent; ... :cond_10

Most likely, the program somehow randomly calculates whether it is necessary to show ads on the main screen, and if not, jumps directly to cond_10. Ok, let's simplify her task and replace the conditional transition with an unconditional one:

#if-ne p1, v0, :cond_10 goto:cond_10

There are no more mentions of FirstAd in the code, so we close the file and re-assemble our virtual torch using apktool. Copy to smartphone, install, run. Voila, all ads are gone, congratulations to all of us.

Results

This article is just a brief introduction to the methods of opening and modifying Android applications. Many issues remained behind the scenes, such as removing protection, parsing obfuscated code, translating and replacing application resources, as well as modifying applications written using the Android NDK. However, having basic knowledge, understanding all this is only a matter of time.

It happens that after the release of the application, its source code disappears somewhere. Is it true that this happens all the time? And there is nothing left but to decompile it and fix a few hundred lines of code, and all this must be done as quickly as possible.

So I had the task of modifying the application having only its apk. And those who have been involved in decompiling applications know how difficult it is to compile it later.

Decompilation

For Android "and there are the following utilities:

• ApkTool for resource decompilation.
• Dex2Jar to convert dex to jar.
• JD-GUI to get sources from jar.
• I also recommend JAD, some places decompile better than JD-GUI.

There is enough information on their use on the Internet.

If you try to compile the application after decompiling, then most likely it will not compile due to errors, it is especially difficult to decompile cycles and conditions. Some errors are easily corrected, but again, it will not be easy to figure out a lot of conditional jumps, and when their number is more than a hundred or even several thousand, then this way to restore the application loses its effectiveness, it is faster to write everything again.

This could be the end of experiments with decompilation, but laziness is the engine of progress and a new method was born.

Redefining classes

So, jar is a library, so why not just include it in a new project? We throw it into the libs folder, inherit from the main activity and compile it. Everything works, the main thing is that the class names do not match, so the package names must differ, otherwise the generated BuildConfig and R will at least 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 that's all, especially since the final keyword will not allow you to do this and inherit too, so let's move on.

Replacing classes

After unzipping the jar library, we get class files, these are compiled classes, we note that when building the project, the same class files are in the bin / classes folder, but what if we put 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 do not export it. This is done simply: from the libs folder, Eclipse itself exports libraries, so we 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 class files.

Now we take some class from the decompiled application sources, fix compilation errors in it, add, for example, showing a dialog to make sure that the new class is used. Next, we clean the project, in Eclipse it is Project-> Clean, copy the class files to the bin / classes folder, build the project and everything works!

With the next builds of the project, there is no need to clear it, so using this method is quite convenient. To make it easier to fix errors after decompilation, I used sources obtained from JD-GUI and JAD, usually this was enough.

But now it's time to compile the release version, and for it, of course, an 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, after which there should be no errors. Another unpleasant feature of the release build is that you need to clean the project every time and copy the class files, otherwise they disappear somewhere.

Conclusion

Only modifiable files are decompiled in this way, which eliminates the need to correct errors in all sources and improves reliability, since the entire part of the code will undergo the process of decompiling - fixing - compiling.

With a high probability it will not be possible to hide all traces of the original application, the names of the non-fussed 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.

It happens that after the release of the application, its source code disappears somewhere. Is it true that this happens all the time? And there is nothing left but to decompile it and fix a few hundred lines of code, and all this must be done as quickly as possible.

So I had the task of modifying the application having only its apk. And those who have been involved in decompiling applications know how difficult it is to compile it later.

Decompilation

For Android "and there are the following utilities:

• ApkTool for resource decompilation.
• Dex2Jar to convert dex to jar.
• JD-GUI to get sources from jar.
• I also recommend JAD, some places decompile better than JD-GUI.

There is enough information on their use on the Internet.

If you try to compile the application after decompiling, then most likely it will not compile due to errors, it is especially difficult to decompile cycles and conditions. Some errors are easily corrected, but again, it will not be easy to figure out a lot of conditional jumps, and when their number is more than a hundred or even several thousand, then this way to restore the application loses its effectiveness, it is faster to write everything again.

This could be the end of experiments with decompilation, but laziness is the engine of progress and a new method was born.

Redefining classes

So, jar is a library, so why not just include it in a new project? We throw it into the libs folder, inherit from the main activity and compile it. Everything works, the main thing is that the class names do not match, so the package names must differ, otherwise the generated BuildConfig and R will at least 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 that's all, especially since the final keyword will not allow you to do this and inherit too, so let's move on.

Replacing classes

After unzipping the jar library, we get class files, these are compiled classes, we note that when building the project, the same class files are in the bin / classes folder, but what if we put 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 do not export it. This is done simply: from the libs folder, Eclipse itself exports libraries, so we 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 class files.

Now we take some class from the decompiled application sources, fix compilation errors in it, add, for example, showing a dialog to make sure that the new class is used. Next, we clean the project, in Eclipse it is Project-> Clean, copy the class files to the bin / classes folder, build the project and everything works!

With the next builds of the project, there is no need to clear it, so using this method is quite convenient. To make it easier to fix errors after decompilation, I used sources obtained from JD-GUI and JAD, usually this was enough.

But now it's time to compile the release version, and for it, of course, an 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, after which there should be no errors. Another unpleasant feature of the release build is that you need to clean the project every time and copy the class files, otherwise they disappear somewhere.

Conclusion

Only modifiable files are decompiled in this way, which eliminates the need to correct errors in all sources and improves reliability, since the entire part of the code will undergo the process of decompiling - fixing - compiling.

With a high probability it will not be possible to hide all traces of the original application, the names of the non-fussed 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.

About how to decompile applications for Android, you know that I stopped on how to collect all the files that came out when disassembling the application back into APK.

Lyrical digression

A folder with files obtained as a result of decompilation using apktool is recommended for assembly. The code files, which are a set of instructions for the Dalvik virtual machine, are compiled back into the class archive without any problems. While converting from Dalvik to Java and back can lead to incompatibility issues. As a result, the program will not work correctly. Therefore, in order to successfully modify programs, and not just for the sake of research, you need to study the Dalvik instructions.

Assembly

Collecting such files back into an APK is quite simple. To do this, you need to run apktool with the appropriate build flag and pass it the path to the folder with the decompiled application inside. For example, if we have an app folder that is located in the same directory as apktool, then the command will look like this:

Shell

java -jar apktool.jar b app

java - jar apktool .jar b app

After assembly, the finished APK file will be in the directory app/build. The next step is to sign the APK. This is done in order for the application to work on devices where debugging is prohibited. That is, the launch of unsigned applications on such devices is prohibited. You can read more about digital certificates and the procedure for signing files here.

Signing a file is very simple: there is a special utility for this called signapk . It must be run by passing certificates as arguments, then the path to the application, and finally the path for the signed application (the result where to save). It looks something like this:

Shell

java -jar signapk.jar testkey.x509.pem testkey.pk8 *.apk apk_signed.apk

java - jar signapk .jar testkey .x509 .pem testkey .pk8 * .apk apk_signed .apk

Where can I get such a certificate, you ask? Certificates can be found on the Internet. Or generate it yourself. Detailed instructions on setting up and generating all the necessary files can be found, for example,.

Conclusion

As you can see, decompiling and building APK files is a fairly simple process, which, in addition, can be automated, making it easier for the researcher. The Dalvik virtual machine itself is also easy to learn and open, which, on the one hand, lowers the entry threshold for developers, and on the other hand, is the main reason for such a large percentage of piracy on the Android platform. This is partly why developers, for example, of games, are generally not interested in releasing interesting games with a story. It is much more profitable with the current attitude of users to rivet amazingly similar farms with donations. Therefore, we buy applications, support developers and, as a result, we get interesting content. But there is absolutely no need to donate!

Thank you all, see you again.

Recently, I told you how to use free online services (check the APK file). Today we will continue the topic of APK files, and I will show you how to decompile an APK file online.

But first, for those who are not in the know, I will tell you what APK decompilation and decompilation in general is, and in what cases it may be needed. Coders, IT-shnikam and other computer geeks are not recommended to read the next chapter! Go straight to the overview of online services.

• Foreword
• What is decompilation
• APK file decompiler online
  • APK Decompilers Online Service
  • Online service Javadecompilers
  • Online service APK-Deguard
• conclusions

What is a decompiler or decompilation process?

The decompiler tries to translate the compiled binary back into some kind of source code. The quality of this operation directly depends on the features of the source programming language.

There are a large number of decompilers for the Java programming language. Java bytecode contains a lot of information. This makes it easier for the decompiler to restore the original code to a recompilable state.

APK Decompilation

As you know, Android applications are usually written in Java. Since the release of the very first version of Android, programmers have been faced with the task of not only compiling from Java files into an APK file for installing it on an Android device, but also performing the opposite action, i.e. decompile the APK file.

Why do you need to decompile the APK file?

The answer is simple - in order to first of all see how this or that Android application works, and of course change it if necessary. When you decompile an APK file (if it hasn't been obfuscated first), you get a complete set of Java files with source code.

Most people just need to view the content, and in order to do this, many different tools need to be installed on the computer. Requires Java machine, Android SDK and tools such as: JavaDecompiler, dex2jar, etc. installed. In fact, although it is difficult, but the most correct way, alas, it requires some knowledge and skills from the user, and of course fuss.

Is there any easier way to decompile an Android app?

Oh sure. With the development of cloud technologies, free online services have appeared, which I will now discuss.

Decompile APK online with Javadecompilers

Let's start our review with an online service. This tool is based on the offline version of the Jadx decompiler.

1. We go to the Javadecompilers website, click the "Browse" button and select the required application.

2. Click on the "Upload and Decompile" button.

Java decompilers

3. After a few minutes (depending on the size of the application), the result will be displayed, which can be downloaded to your computer by clicking on the "Save" button.

Java decompilers

4. You can also view all the files in the directories and download each one individually.

Java decompilers

In addition, there are other tools on the site. In general, the site is very good. Definitely bookmarked!

Decompile APK online with APK-Deguard

Another interesting online service is called. Works on the same principle. We go in, upload the necessary file to the site and click on the "Upload" button.

APK Deguard

Here is what the decompiled APK file looks like on the site.

APK Deguard

The APK-Deguard online service, like the previous site, allows you to download the source code. In txt, zip and apk format.

APK Deguard

There is a limit on the maximum size of the downloaded application. The file size should not exceed 16MB. The service is not bad and quite usable, it has long been bookmarked.

APK Decompilers

And finally, in a nutshell about the service. In short, because there is not much to talk about, a site for decompiling APK files.

APK decompilers

In terms of functionality, it is inferior to the previous ones. Allows you to download sources to your computer without the ability to view directories and files on the site.