We publish applications on Google Play and earn millions. How to use the app signing feature on Google Play How to sign an apk with an original signature
So, you've worked many days (and maybe even nights), and now your first hybrid mobile application is ready. It is quite stable, most of the critical bugs are closed. There are small ones left, but remembering that perfectionism is evil, you make a strong-willed decision to publish the application.
A prerequisite for this is the presence of a signed APK file. You will learn how to sign an apk file in this article.
A small retreat
When my pet project was getting close to release, I started looking for information on how to quickly and painlessly publish an application. Many of the instructions found looked simple. I chose the instructions from the authors of the Ionic framework, on which the application was developed. Not everything worked out the first time; there are several peculiarities. The signing process is described in this article, with important points highlighted.Initial data
I'm assuming you have everything set up to develop hybrids. mobile applications using Apache Cordova. Must be installed:- Apache Cordova
- Java Development Kit
- Android SDK Tools
Go
First you need to create a release build of your application. But before that, let's make sure that all unnecessary plugins are removed. For example, we don't need a plugin that outputs debugging information to the console. Let's delete it:$ cordova plugin rm cordova-plugin-console
To generate a release build for Android, use the command build with a flag --release:
$ cordova build --release android
This command will create unsigned APK file in the directory:
Platforms/android/build/outputs/apk
For example, platforms/android/build/outputs/apk/ android-release-unsigned.apk. Then we will need to sign this file and run the utility zipalign to optimize and prepare the file for Google Play.
To sign a file you need a certificate. Let's create it using the utility keytool which is included in the JDK:
$ keytool -genkey -v -keystore lcf.keystore -alias lcf -keyalg RSA -keysize 2048 -validity 10000
Important
The value of the -alias parameter must be remembered, or better yet written down. In the example above, it is equal to lcf (based on the first letters of the application name Loyal Client Free). I will not give details here, if you are interested, write in the comments, I will tell you in more detail.The alias is used every time you sign * applications. To make it easier to remember, use the name of the keystore file as an alias, for example:
-keystore hello-world.keystore -alias hello-world -keystore weather-app.keystore -alias weather-app -keystore todo.keystore -alias todo
* You need to sign the application every time updates are released
Utility keytool asks a series of questions. There will be 8 of them in total. To have an idea of the questions and approximate answers in advance, they are all given below, under the spoiler.
Keytool questions and sample answers to them
1. Enter keystore password:
Here you must enter a password for the file (at least 6 characters). The entered password must be written down in a safe place; it is needed every time you sign the application.
2. Re-enter new password:
Re-enter your password.
3. What is your first and last name?
: Ivan Petrov
Your first and last name. Value in square brackets is the default value.
4. What is the name of your organizational unit?
: IT
The name of your company's division. You can leave it blank, I indicate IT.
5. What is the name of your organization?
: 2developers
The name of your organization. Please indicate if any.
6. What is the name of your City or Locality?
: Moscow
City name
7. What is the name of your State or Province?
: M.O.
Area name
8. What is the two-letter country code for this unit?
: RU
Code of the country. I indicate RU.
: y
Confirm if everything is correct or press Enter to enter again.
At the end, a message indicating successful key generation will appear. You will be prompted to set a password for the private key (if you want to leave it the same as for the certificate, press Enter):
Generating 2 048 bit RSA key pair and self-signed certificate (SHA256withRSA) with a validity of 10 000 days for: CN=Ivan Petrov, OU=IT, O=2developers, L=Moscow, ST=MO, C=RU Enter key password for
A file will be created in the current directory lcf.keystore.
Important
The created file must be saved in a safe place. If you are using a private repository, the file can be committed along with the application source code. In general, it is better to store certificates separately. If you lose the certificate, you will not be able to issue app updates.
There are two steps left and you will have an APK file ready for distribution. Let's move on to signing.
To sign your apk file, use the utility jarsigner, which is also included in the JDK.
$ jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore lcf.keystore android-release-unsigned.apk lcf
The certificate name is indicated after the parameter -keystore, alias - after the file name.
Finally, to optimize the apk file, we will use the utility zipalign:
$ zipalign -v 4 android-release-unsigned.apk LoyalClientFree.apk
The last parameter is the name of the file you will upload to Google Play.
Important.
Utility zipalign it is part of the Android SDK Tools and can be found here:/path/to/Android/sdk/build-tools/VERSION/zipalign
Conclusion
You now have a distribution-ready apk file that can be uploaded to Google Play. Fill out the description, determine the rating of your application and feel free to click “Publish”.With Google Play's App Signing feature, Google can manage your app's signing key, as well as protect that key and use it to sign your APKs for distribution. This storage method will protect you in case the key is lost or hacked.
Important! To use Android App Bundles (the recommended app publishing format), you must enroll in the Google Play App Signing Program before uploading the App Bundle to the Play Console.
Registration is open to account holders and users with global production management permissions who have accepted the Terms of Service. You can only register one app at a time with the Google Play App Signing Program.
Work principles
When you use Google Play's app signing feature, your keys are stored in the same infrastructure that stores Google's keys, and are protected by a dedicated key management service. Detailed information Google's technical infrastructure can be found in the Google Cloud Security documentation.
Android applications are signed with a private key. Each such key is associated with a public certificate, with which devices and services can verify the security of applications and their updates. Only those updates whose signature matches the signature are installed on devices installed application. Letting Google manage your app signing key will make the process more secure.
Note. Using Google Play's app signing feature is optional. You can download APKs and manage your own keys without using App Bundles. However, if you lose access to the keystore or it is compromised, you will not be able to update your application and will have to republish it with a different package name.
Descriptions of keys, objects and tools| Conditions | Description |
|---|---|
| Application signing key |
The key used by Google Play to sign APK files delivered to the user's device. When you sign up for the Google Play app signing program, you can upload an existing signing key or let Google generate a new one. |
| Download Key |
There are two ways to generate a download key:
|
| Certificate (.der or .pem) |
A certificate that contains the public key and Additional information about its owner. A public key certificate allows anyone to know who signed an App Bundle or APK file. This certificate can be shared because it does not include a private key. To register your keys with API providers, you can download the public certificate for your app signing key from Signing applications in Play Console. A public key certificate can be shared with everyone because it does not include a private key. |
| Digital fingerprint of the certificate |
A short and unique identifier for the certificate. The fingerprint along with the package name is often requested by API providers to provide access to their services. Digital fingerprints of MD5, SHA-1 and SHA-256 download and application signature certificates can be found on the page Signing applications in Play Console. You may also receive a different type of digital fingerprint. To do this, download the original certificate in DER format on the same page. |
| Java Key Store (.jks or .keystore) | Storage of security certificates and private keys. |
| PEPK tool |
A tool to export private keys from Java storage and encrypt them for transfer to Google Play. Once you've provided Google with your app signing key, choose to export and download your own key (and optionally its public certificate), then follow the instructions to download and use the tool. You can also download, view and use the open source PEPK tool. |
You can download APK files signed with the original app signing key before or after signing the app on Google Play.
If you're migrating to Android App Bundles, you can test them out in testing versions and use existing APKs in production versions. Here's how it works:
- You sign the App Bundle or APK and upload it to the Play Console.
- The app signing process depends on what you're downloading.
- App Bundle. Google optimizes APK files from the App Bundle and then signs them with an app signing key.
- APK file signed with the download key. Google verifies your signature, removes it, and re-signs the APK files with the app signing key.
- An APK file signed with the app signing key. Google verifies the signature.
- Google delivers signed APK files to users.
How to Sign Up for the Google Play App Signing Program
New applicationsStep 1: Create a download key
- Create a download key by following the instructions.
- Sign the new APK file with the download key.
Step 2: Prepare the release
- , following the instructions.
- Once you've chosen your version type, configure your app signing settings under "Let Google protect and manage your app signing key."
- If you click Continue, the generated key will become the download key that will be used to sign future releases. You can also choose the following Advanced settings:
- Use one key for different applications in the developer account (option 2).
- Upload the signing key of an existing application (option 2, 3 and 4), choosing the most appropriate export and download method. Once you download an application's signing key and its public certificate, you can either use it as the application's signing key.
Note. To continue, you must accept the Terms of Use and enroll in the App Signing Program.
Step 3: Register your app signing key with your API providers
If your application uses an API, then in order to authenticate you will most likely need to register a key certificate that Google uses to sign your application. To find a certificate:
- Sign in to Play Console.
- Select an application.
- From the menu on the left, select Release management > Application signatures.
-
- If the API provider requires a different type of fingerprint, you can download the original certificate in DER format and convert it as needed using the appropriate tools.
Step 1: Sign up for the Google Play App Signing Program
- Sign in to Play Console.
- Select an application.
- From the menu on the left, select Release management > Application signatures.
- If necessary, read the Terms of Use and click Accept.
Step 2: Submit the original key to Google and create a download key
- Find the original application signing key.
- Sign in to Play Console.
- Select an application.
- From the menu on the left, select Release management > Application signatures.
- Upload an existing application signing key in the method that best suits your release process.
- and upload the certificate to Google Play.
- You can also use the application signing key as the download key.
- Copy the digital fingerprints (MD5, SHA-1, and SHA-256) of the application signing certificate.
- To conduct testing, you may need to register a boot key certificate with the API provider using the certificate's fingerprint and application signing key.
Step 4: Sign your next app update with your download key
Released application updates must be signed with a download key.
How to create a download key and update key stores
You can create a download key when you sign up for the Google Play App Signing Program, or you can generate one later in the Release management > Application signatures.
To create a download key, follow these steps:
- Follow the instructions on the Android Developers site. Keep the key in a safe place.
- Export the certificate for the boot key in PEM format. Replace the following arguments with an underscore:
- $ keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem
When prompted during the issuance process, download the certificate to register it with Google.
If you are using a download key:
- The download key is registered with Google only to authenticate the identity of the app creator.
- Your signature is removed from all APK downloads before they reach users.
- The download key must use RSA encryption and must be at least 2048 bits in size.
- DSA and EC keys are not supported, nor are RSA keys smaller than 2048 bits.
Once you have created your download key, check and update the following locations if necessary:
- local system;
- protected local server(with different access control lists);
- cloud system (with various access control lists);
- special key management services;
- Git repositories.
How to update the signing key for new app installations
In some cases, you may be able to request an application signing key update. The new key will be used to sign new installations and updates of the application, and the outdated one will be used to update signed versions that are already installed by users.
The signing key can only be updated once for each application. In the unlikely event that you use the same signing key for multiple applications to run them in the same process, the key cannot be updated.
You should request an application signing key update in the following cases:
- You need a more secure key.
- The application signing key has been compromised.
Note. The request to update the app signing key on the Play Console is not related to the replacement of keys in Android P and later versions. This key replacement is not currently supported by Google Play.
Important notes about updating keysBefore requesting a key update, it is important to understand what changes this will entail.
- If you use the same signing key for multiple apps to use the same code or data, you'll need to update the apps to recognize both the new and legacy keys.
- If your app uses an API, be sure to register the certificates for the new and legacy app signing keys with the API provider before upgrading your app. Certificates are available on the page Signing applications Play Console.
- If many users of your application install updates through file-sharing networks, they will only be able to install updates signed with the same key as the application installed on their devices. If applications cannot be updated because installed version signed with a different key, users can uninstall and reinstall it to receive updates.
- Sign in to Play Console.
- Select an application.
- From the menu on the left, select Release management > Application signatures.
- In the "Update signing key for new app installations" card, select Request a key update.
- Choose what to do with the device.
- Depending on the option you choose, you may have to contact support to complete your request.
- Allow Google Play to generate a new app signing key (recommended) or download one.
- After updating your app signing key, if the key matches your download key, you can continue to use the old app signing key as your download key or create a new one.
- If you have also published your app outside of Google Play or are planning to do so, you can generate a shared app signing key and upload it to Google when you sign up for the Google Play App Signing Program.
- To protect your account, enable two-step verification for all accounts that have access to the Play Console.
- After the App Bundle is published in the test or working version You can open the App Bundle Browser and download a ZIP archive containing all the APK files for a specific device. These APK files are already signed with the app signing key. You can install them on your device from a ZIP archive using the utility command line bundletool.
- For greater security, generate a new download key that is different from the application signing key.
- If you want to test an APK signed with an upload key, register the key with a service or API that uses the app's signature for authentication (such as API Google Maps or Facebook Developer Pack).
- If you're using the Google API, you can register your upload certificate in the Google Cloud Console.
What to do if the key is lost or hacked
If you have lost access to your private download key or it has been hacked, and ask the owner of your account. When contacting support, the account owner must attach the upload_certificate.pem file.
When the support team registers a new download key, you will receive an email and can then update your key stores and register the key with API providers.
Important! Resetting the download key does not affect the app signing key, which Google Play uses to sign APK files before sending them to users.
Was this information useful?
How can this article be improved?
Sometimes some applications on Android do not suit the user in some way. An example is intrusive advertising. And it also happens that the program is good for everyone, but the translation in it is either crooked or completely absent. Or, for example, the program is a 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 package with an application, look at its internal structure, disassemble and decompile the bytecode, and also try to make several changes to the applications that can bring us one benefit or another.
To do all this yourself, you will need at least 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 use specialized console software.
So, what is an APK package in which absolutely all Android software is distributed?
Application decompilation
In this article, we only worked with disassembled application code, but if more serious changes are made to large applications, understanding the smali code will be much more difficult. Fortunately, we can decompile the dex code into Java code, which, although not original and not compiled back, is much easier to read and understand the logic of the application. To do this, we will need two tools:
- dex2jar is a translator of Dalvik bytecode into JVM bytecode, on the basis of which we can obtain code in the Java language;
- jd-gui is a decompiler itself that allows you to get readable Java code from JVM bytecode. As an alternative, you can use Jad (www.varaneckas.com/jad); Although it is quite old, in some cases it generates more readable code than Jd-gui.
This is how they should be used. First, we launch dex2jar, specifying the path to the apk package as an argument:
% dex2jar.sh mail.apk
As a result, the Java package mail.jar will appear in the current directory, which can already be opened in jd-gui to view the Java code.
Arrangement of APK packages and receiving them
Plastic bag Android applications, in fact, is a regular ZIP file, no special tools are required to view the contents and extract it. It is enough to have an archiver - 7zip for Windows or console unzip on Linux. But that's about the wrapper. What's inside? In general, we have the following structure inside:
- META-INF/- contains a digital certificate of the application, identifying its creator, and checksums of the package files;
- res/ - various resources that the application uses in its work, such as images, declarative description of the interface, as well as other data;
- AndroidManifest.xml- description of the application. This includes, for example, a list of required permissions, the required Android version and the required screen resolution;
- classes.dex- compiled application bytecode for virtual machine Dalvik;
- 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 a resource you need to know its identifier, but the list of assets can be obtained dynamically using the AssetManager.list() method in the application code;
- lib- native Linux libraries written using NDK (Native Development Kit).
This directory is used by game manufacturers, placing there the game engine written in C/C++, as well as by creators of high-performance applications (for example, Google Chrome). We figured out the device. But how do you get the package file of the application you are interested in? Since it is not possible to pick up APK files from the device without root (they are located 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 Varezniks.
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 in either Windows or 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 identifier, and can be obtained by typing the code on the dialer # #8255## and then finding the Device ID line. When filling out, you only need to enter the ID without the android- prefix.
After filling out 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 that interests you, downloaded it, unpacked it... and when you tried to view some XML file, you were surprised to discover that the file was not text. How to decompile it and how to work with packages in general? Is it really necessary to install the SDK? No, it is not necessary to install the SDK at all. In fact, all the steps to extract, modify and package APK packages require the following tools:
- ZIP archiver for unpacking and packing;
- smali- Dalvik virtual machine bytecode assembler/disassembler (code.google.com/p/smali);
- aapt- a tool for packaging 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 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 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 quite 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 Virtuous Ten Studio, which also accumulates all these tools (including the apktool itself), but instead of a CLI interface provides the user with an intuitive GUI, with which you can perform unpacking, disassembling and decompiling operations in a few clicks. This tool is Donation-ware, that is, sometimes windows appear asking you to get a license, but in the end this can be tolerated. There is no point in describing 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 look at the apktool options. In short, there are three basic commands: d (decode), b (build) and if (install framework). If everything is clear with the first two commands, then what does the third, conditional statement, do? It unpacks the specified UI framework, which is necessary in cases where you dissect any system package.
Let's look at 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 one built into apktool. Now let's look at a couple of options for the b command:
- -f- forced assembly without checking changes;
- -a- indicate 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; to do this, just specify one of the commands and the path to the APK, for example:
$ apktool d mail.apk
After this, all extracted and disassembled files of the package will appear in the mail directory.
Preparation. Disabling advertising
Theory is, of course, good, but why is it needed if we don’t know what to do with the unpacked package? Let's try to apply the theory to our benefit, namely, modify some software so that it does not show us advertising. For example, let it be Virtual Torch - a virtual torch. This software is ideal for us, because it is filled to capacity with annoying advertising and, moreover, is 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, simply open the APK file in the application and unzip it, create a project (File -> New project), then select Import File in the project context menu. If your choice fell on apktool, then just run one command:
$ apktool d com.kauf.particle.virtualtorch.apk
After this, a file tree similar to that 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 disassembled code of the application's executable dex file, the second contains service information necessary for apktool to assemble the package back.
The first place we should look is, of course, AndroidManifest.xml. And here we immediately encounter the following line:
It is not difficult to guess that it is responsible for granting the application permissions to use the Internet connection. In fact, if we just want to get rid of advertising, we will most likely just need to block the application from the Internet. 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 a META-INF/ directory). We must 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- keystore output file; it usually stores one pair of keys;
- Password And Confirm- password for the storage;
- Alias- name of the key in the storage;
- Alias password And Confirm- secret key password;
- Validity- validity period (in years). The default value is optimal.
The remaining fields are, in general, 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 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, 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 receive an error.
A digital signature is only required for third-party software, so if you are modifying system applications, which are installed by copying to the /system/app/ directory, you do not need to sign them.
After that, download the package to your smartphone, install it and launch it. 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 might be enough, but the message looks annoying, and, to be honest, we just got lucky with a stupid application. Normally written software will most likely clarify its credentials or check for an Internet connection and otherwise simply refuse to launch. 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 when the application or one of its “activities” (in simple terms, application screens) is launched. Let's try to find these classes. We go to the smali directory, then com (org contains only the open graphic library cocos2d), then kauf (this is where it is, 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, from the name of which it is easy to guess that it is the one that displays advertising.
We could change the logic of its operation, but it would be much easier to simply remove calls to any of its methods from the application itself. Therefore, we leave 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 installed as the entry point to the application (analogous to the main function in C). Open the file for editing.
Inside there is 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 will simply find all references to the Ad class in the code and comment them out. We enter the line “Ad” in the search and get to line 25:
Field private ad:Lcom/kauf/marketing/Ad;
Here an ad field is created to store an Ad class object. We comment by placing a ### sign in front of the line. We continue the search. Line 423:
New-instance v3, Lcom/kauf/marketing/Ad;
This is where the object creation occurs. Let's comment. We continue the search and find in lines 433, 435, 466, 468, 738, 740, 800 and 802 calls to methods of the Ad class. Let's comment. Look like that's it. Save. Now the package needs to be put back together and checked for functionality and the presence of advertising. For the purity of the experiment, we return the line removed from AndroidManifest.xml, assemble the package, sign and install.
Our guinea pig. Advertising visible 
Oops! The 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 identify the true entry point, reopen the AndroidManifest.xml file. And yes, it contains 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 an intent (event) android.intent.action.MAIN from the android.intent.category.LAUNCHER category. This event is generated when you tap on the application icon in the launcher, so it determines 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”, we find in lines 153 and 155 a 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. Let's look further, there is the creation of an instance of the FirstAd class and an intent that, according to the context, is related to this instance, and then the cond_10 label, 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 advertising should be shown 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 reassemble our virtual torch using apktool. Copy it to your smartphone, install it, launch it. Voila, all advertising has disappeared, for which we congratulate all of us.
Results
This article is just a brief introduction to the methods of hacking 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’s only a matter of time to figure it all out.
Post Views: 5,618
Android Studio provides ample opportunities both for application development and for increasing automation and comfort in programming.
If you are using a build system Gradle to create your applications, you can also configure several options to create signatures for your applications.
You probably don't want to publish your signing keys, passwords, and usernames to a public (or even private) repository. Therefore you can define key, password and username as properties in a separate file.
Before you start signing your application, you need to create a new property in your gradle.properties file. Let's call him Keys.repo and, as a value, specify the path to the folder where the key store and the file with properties will subsequently be located (for example, C:/Users/UserName/.signing).
Keys.repo=C:/Users/UserName/.signing
Then you need to create this folder or, if you specified an existing one, open it. You need to create a file in it YourProjectName.properties, inside of which the path to the key store, the key alias and the password will be written as properties in the following form.
RELEASE_STORE_FILE=/YourProjectName/KeyStoreName.jks RELEASE_STORE_PASS=****** RELEASE_ALIAS=KeyAlias RELEASE_KEY_PASS=******
How to create a key vault?
If you don't have a keystore, you can easily create one with using Android Studio. To do this, select the menu item Build -> Generate Signed APK.
In the window that appears, you need to click Create new... As a result, a window will open in which you can specify where the key storage will be located (for this lesson, it is better to immediately select the path that you specified in YourProjectName.properties in property RELEASE_STORE_FILE), as well as key information.
Then you need to create a folder YourProjectName and move it there required file key stores.
Now you can proceed directly to the signing process. To do this, you need to open the file in your project build.gradle(located in the app folder). Inside it in the block android you need to add the following code.
SigningConfigs ( debug ( /* no changes here */ ) release ( if (project.hasProperty("Keys.repo")) ( def projectPropsFile = file(project.property("Keys.repo") + "/YourProjectName.properties ") if (projectPropsFile.exists()) ( Properties props = new Properties() props.load(new FileInputStream(projectPropsFile)) storeFile file(file(project.property("Keys.repo") + props["RELEASE_STORE_FILE"] )) storePassword props["RELEASE_STORE_PASS"] keyAlias props["RELEASE_ALIAS"] keyPassword props["RELEASE_KEY_PASS"] ) ) else ( println "===================== ====================================" println " - Please configure release-compilation environment - e.g. in ~/. signing directory" println "============================================================ ==========" ) ) )
What are the different schemes for obtaining a signature?
There are two schemes for obtaining an APK signature: v1 JAR And v2 Full APK.
In the first case it is signed JAR-file, which is traditional way signing. Signing v1 does not protect some parts of the APK, such as ZIP metadata. The APK verifier must handle a lot of untrusted (not yet verified) data structures and then discard data that is not signed, leaving a lot of attack surface. Additionally, the APK verifier must decompress all compressed entries, which wastes a lot of time and memory. To solve these problems, the second scheme v2 Full APK has been developed.
Scheme v2 was presented in Android 7.0 Nougat (API 25) and works starting from version Android Studio 2.2 And Android Gradle plugin 2.2. This scheme provides faster application installation and good protection against unauthorized changes to the APK. The APK content is hashed and signed, then the resulting APK signature block inserted into the APK.
During verification, the v2 scheme treats the APK as a blob and performs signature verification on the entire file. Any modification to the APK, including modifications to the ZIP metadata, invalidates the signature. This form of verification is much faster and can detect more unauthorized modifications.
The new format is backwards compatible, so APKs signed with the new scheme can be installed on older devices (which will simply ignore the new signature) as long as those APKs are also signed with the v1 scheme.
By default, signing uses both schemes so that apps can be installed on any device. However, if there is such a need, you can disable the v1 or v2 signature. To do this, in the above code in the block release It is enough to add the following lines.
V1SigningEnabled false
V2SigningEnabled false
It is also important to note that you need to sign with scheme v1 before signing with scheme v2, since the APK will not pass verification under scheme v2 if it is signed with additional certificates after signing with scheme v2.
Once the code is added, include this code in a block buildTypes inside release. For example:
BuildTypes ( release ( minifyEnabled true shrinkResources true proguardFiles getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" signingConfig signingConfigs.release ) )
Now you can safely in the menu item Build choose Build APK, having previously changed the assembly type from debug on release. As you can see, this method is convenient because it is automatic, you only need to configure it once and your key storages can be safe.
