How to parse an apk file. We open, modify and pack Android applications. What is an APK file

In this article, you will learn what an android application consists of, how to open an APK file and with what programs.

What is an APK file?

APK is an Android operating system format used for archived executable application files, and the name of the file itself can be anything, but the extension should only look like this .apk. The analogs of APK in other operating systems are in Windows .msi, in Symbian - .sis, in Linux - .rpm or .deb.

See what's inside
In fact, .apk is a ZIP archive, so you can look at the internal device using any file manager or archiver, for example WinRAR or the X-plore mobile application.




It should be remembered that you only get visual access to internal resources, editing options are extremely limited.

Consider the structure
Inside .apk we see a number of files and folders, let's find out what they are for:

  • AndroidManifest.xml is a kind of "passport" of the application from which you can find out all the main points, requirements, version, permissions, and more.
  • META-INF this file contains metadata, that is data about data, checksums, data paths, resource paths and checksums, certificates. You can open this file with any text editor, but it is recommended to use Notepad ++.
  • The res folder contains all the program resources, graphical, such as icons, pictures, text, graphical interface elements. You can also easily access the folder.
  • classes.dex - the direct program code of the application, executed by the Dalvik VM virtual machine, you can see that inside this file you can only decompile .apk, we will talk about this in other articles. resources.arsc - compiled XML file, this file contains data on all resources used in the program.
  • lib - a folder with native libraries, which resources can only be accessed using specialized programs. Also, the APK can contain files and folders such as com, org, udk, but not always.

Now let's look at the internal structure in more detail for this we need a decompilation program, Java and an APK file. The main tool for disassembling .apk is Apktool, but this program only works from the line, which is not very convenient. For faster and more convenient parsing, you can use APKing, this is the same Apktool, but with the ability to work from the context menu.


And so we install APKing like any application for Windows and select .apk, right-click on it and Shift at the same time, after which we will see the following:



And we select the required action, for example, decompile completely, then the program will complete the operation and create a folder with the same name.



By opening the folder we will get access to all the resources of the APK file.



Now all text files can be edited, while observing the basic rules, you can use the popular Notepad ++ program, for example, consider AndroidManifest.xml

I mentioned the SmartAPKTool app. It can unpack, pack and sign modified apk files. Its advantage is the presence of a graphical interface. However, there is also a serious drawback. SmartAPKTool has not been updated for a long time, and the program incorrectly unpacks and packs applications for fresh versions of Android. Therefore, here I will try to explain how to use the application for these purposes. apktool.

Remark 1.
The SmartAPKTool program is still convenient to use for signing the collected apk-files.
Remark 2.
Links to the programs mentioned in the article are ↓

Program apktool does not have a graphical interface. This is a disadvantage for those who are not used to working with the command line. But there is also a plus: unlike SmartAPKTool, we will see all errors, which means we will know what to fix.

Download two archives: one common for all systems, the other for our system (in the example - Windows):

Unpack both archives into the same empty folder (in our example, C: \\ apktool \\). Its content should look like this:

From now on we can use the program apktool.

Remark 3.
64-bit Linux users will need to install the ia32-libs package:

sudo apt-get install ia32-libs

In the same folder we put the file that we need to unpack. For example, let's call it orig.apk
Pressing the Shift key and holding it down, right-click on any empty space in the folder (don't click on files!). After that, select the item "Open command window". In the console that appears, type:

apktool decode orig.apk

The file will be unpacked:

Now we have a folder with the unpacked application in the C: \\ apktool \\ directory. It is named the same as the original file, minus the extension: C: \\ apktool \\ orig \\. We can change the source files as described in the Android article: How to install two identical applications on one phone. After we have made the changes, let's build a copy of the application by packing the source files into apk:

apktool build orig result.apk

Here result.apk is the file name that we came up with for the copy build. If there are no errors, then the file will be built:

The rest is beyond the scope of the article:

  1. If there are errors during assembly, you need to find their cause and fix it.
  2. It remains to sign the resulting file result.apk. This can be done using SmartAPKTool, as mentioned above; everything in it is intuitive. There are also other ways to sign an apk file.
  3. When installing a copy, when it starts or runs, errors may also occur. They need to be caught using the adb utility included with the Android SDK.

It is necessary to sign the application, otherwise it will not be installed. Errors are not so common, and the most common problems that cause them are described in the article.

In the process of using various firmware for Android devices, sometimes it becomes necessary to change the system applications built into the operating system in one way or another. In this article, we will consider this issue in detail.

Naturally, you need to disassemble and reassemble the system APK file so that it works properly and stably. Let's figure out step by step what needs to be done for this.

First, you need to perform the process of deodexing the system APK files. We will tell you how to do this in.

So, the .apk file has been deodexed and decompiled. We disassemble the application of interest to us, let it bear a name, for clarity of example, framework- res. apk... We remember it in our head as an original application.

Let's say we made all the necessary changes to the application. We'll talk more about all aspects of APKs in. Now you need to pack it back. Let's remember the finished packaged application as a modified application 2.

Now we will explain why you had to mentally memorize applications as original and modified 2. The application built by ApkTool (or using a graphical user interface extension like SmartApkTool) will not work, but this is not a problem. We perform the following actions:

Putting these files back into the APK is easy enough. 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... Next, you need 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. Read more about digital certificates and the file signing procedure here.

Signing a file is very easy: there is a special utility for this called signapk. It must be started by passing first certificates as arguments, then the path to the application, and finally the path for the signed application (the result, where to save). It looks 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 to get such a certificate, you ask? The 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 assembling APK files is a fairly simple process, which 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 barrier to entry 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 of games, for example, are generally not interested in releasing interesting games with a storyline. It is much more profitable with the current attitude of users to rivet strikingly similar farms with donation. Therefore, we buy applications, support developers and, as a result, get interesting content. But there is absolutely no need to donate!

Thank you all, see you again.

Sometimes some applications on Android do not suit the user in some way. An example is annoying ads. And it also happens - 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 it is not possible to get the full version. How can the situation be changed?

Introduction

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

To do all this on your own, you will need at least some 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 the strings that will be displayed on the screen. You will also need to be able to handle specialized console software.

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

Decompiling applications

In this article, we worked only 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 dex the dex code into Java code that, although not original and not compiled 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 into JVM bytecode, on the basis of which we can get code in Java;
  • jd-gui is the decompiler itself that allows you to get readable Java code from the JVM bytecode. Alternatively, you can use Jad (www.varaneckas.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 run 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.

Device APK-packages and their receipt

An Android app package is essentially a regular zip file that doesn't require any special tools to view and unzip its contents. It is enough to have an archiver - 7zip for Windows or console unzip for 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, confirming its creator, and checksums of the package files;
  • res / - various resources that the application uses in its work, for example, images, a declarative description of the interface, and other data;
  • AndroidManifest.xml - application description. This includes, for example, a list of required resolutions, required Android version and 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 not-so-common files / directories worth mentioning:

  • assets - analogue of resources. The main difference is that to access an asset 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 using the NDK (Native Development Kit).

This directory is used by game makers to host a game engine written in C / C ++, as well as high-performance application makers (such as Google Chrome). The device was sorted out. But how do you get the actual package file of the application of interest? Since it is not possible to pick up APK files from the device without root (they are in the / data / app directory), and root is not always advisable, there are at least three ways to get the application file to the computer:

  • aPK Downloader extension for Chrome;
  • real APK Leecher application;
  • various file sharing 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, 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, which you use on the device. The third is the device identifier, and you can get it by dialing the code on the dialer # #8255## and then finding the Device ID string. When filling in, you only need to enter the ID without the android- prefix.

After filling 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.

View and Modify

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

  • zIP archiver for unpacking and packing;
  • smali - assembler / disassembler of bytecode of the Dalvik virtual machine (code.google.com/p/smali);
  • aapt - a tool for packing resources (by default, resources are stored in binary form to optimize application performance). Included in 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 a higher-level software built on their basis. If you work on Linux or Mac OS X, there is a tool called apktool. It allows you to unpack resources in their original form (including binary XML and arsc files), rebuild a package with changed resources, but it cannot 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 should 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 \u003d ~ / bin: $ PATH

If you work in 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 the CLI interface provides the user with an intuitive graphical interface with which to perform operations on unpacking, disassembling and decompiling in a few clicks. This tool is Donation-ware, that is, sometimes there are windows offering 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.


Let's take a look at the 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, conditional operator do? It unpacks the specified UI framework, which is needed in cases when you dissect any system package.

Let's consider the most interesting options of the first command:

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

Using apktool is very simple, for this you just need to 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.

Dissection. 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 to our own benefit, namely, 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 stuffed to the eyeballs with annoying ads and, moreover, simple enough not to get lost in the jungle 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 unpack it, for which create a project (File -\u003e New project), then select Import File from the project context menu. If your choice fell on apktool, then just execute one command:

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

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

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

As you might guess, she is responsible for granting the application permission to use the Internet connection. In fact, if we just want to get rid of ads, we most likely need to disable the Internet for the application. Let's try to do this. We delete the specified line and try to build 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 will not be possible to install it, since it does not have a digital signature and file checksums (it simply does not have the META-INF / directory). We need to sign the package using 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 - the output file of the keystore; it usually contains one key pair;
  • Password and Confirm - password for storage;
  • Alias - the name of the key in the repository;
  • Alias \u200b\u200bpassword and Confirm - secret key password;
  • Validity - validity period (in years). The default is optimal.

The rest of the fields are generally optional - but at least one must be filled in.


WARNING

To sign an application using 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 editorial board nor the author is 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 to it, then find the APK file and boldly press the "Sign" button. If all 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 receive an error.

A digital signature is required only for third-party software, 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 onto a smartphone, install and launch it. Voila, ads are 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 were just lucky with a dumb app. A normally written software will most likely clarify its authority 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 application launch or one of its "activities" (to put it simply, application screens). Let's try to find these classes. We go to the smali directory, then com (org contains only the open graphics 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 what exactly it displays ads.

We could change the logic of its operation, but it would be much easier to remove calls to any of its methods from the application itself. Therefore, we exit the marketing directory and go to the adjacent particle directory, and then to virtualtorch. The MainActivity.smali file deserves special attention here. This is a standard Android class that is created 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 quite confusing and difficult to read due to its low-level nature, so we will not study it, but simply find all references to the Ad class in the code and comment them out. We drive in the line "Ad" in the search and find ourselves on line 25:

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

This creates an ad field to hold an object of class Ad. We comment by placing the ### sign in front of the line. We continue to search. Line 423:

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

This is where the object is created. We comment. We continue searching and find in lines 433, 435, 466, 468, 738, 740, 800 and 802 calls to methods of the Ad class. We comment. Look like that's it. We save. Now you need to put the package back together and check its performance and the presence of ads. For the purity of the experiment, we return the string deleted from AndroidManifest.xml, collect the package, sign and install.

Our guinea pig. Advertising visible

Oops! 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 ads disappeared while the application was running, but remained in the main menu, so the entry point is different? To identify the true entry point, reopen the AndroidManifest.xml file. And yes, it has the following lines:

They tell us (and more importantly, the android) that an activity named Start should be launched in response to the generation of the intent (event) android.intent.action.MAIN from the android.intent.category.LAUNCHER category. This event is generated when tapping 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 the entry point.

Open the Start.smali file and again look for the line "Ad", find in lines 153 and 155 the mention of the FirstAd class. It is also in the source code and, judging by the name, is exactly 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 to show ads on the main screen, and if not, it jumps straight to cond_10. Ok, let's simplify her task and replace the conditional jump with an unconditional one:

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

There are no more references to FirstAd in the code, so close the file and reassemble our virtual torch using apktool. Copy to smartphone, install, launch. Voila, all ads have disappeared, and congratulations to all of us.

Outcome

This article is just a short introduction to the techniques for cracking 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, it is only a matter of time to understand all this.