I exported application for the first time and I'm a little bit confused about keystore.
I want to use one keystore for all next apps. So in Eclipse I will make new keystore but what to put in Alias? Can I put there app name or what? Because I want make universal keystore for all kinds of apps. Can I will put different Alias in my next app? Or will be better to put in alias my first and last name?
Is keystore visible when someone decompile your app?
Thanks for little explanation about keystores.
The keystore is simply a file format designed to contain one or more keys, a.k.a. certificates. It doesn't matter whether you keep all your keys in a one keyfile, and it doesn't matter what you name the keyfiles or the key aliases. Nothing but the actual content of the key itself has any affect whatsoever on your app.
The keystore does not normally become part of the app, and you should make sure not to put it in your /res folder or anywhere else where it might end up getting compiled into the APK. In fact, it's probably a good idea to keep it outside the project directory entirely. Most of the strength of the key is in the practical impossibility of guessing or regenerating its contents. If someone acquires a copy of your keystore, the only thing stopping them from publishing bogus versions of your app is whatever password you put on it.
If you want to split hairs, the docs are wrong. The certificate does not identify the author of the app. It only proves that the app was signed by someone who was in possession of your key. Protect your keystores!
If you want to have one keystore file for all the apps then you cannot change the alias name. It is asked during creating the keystore file.
Next time whenever you compile and build the apk file you have to use the existing keystore file.
Hope you understood.
Related
What I want to know is can a signed apk be extracted and edited? And can the attacker again compress the apk and attack a victim?
I know that we can use proguard to obscure the code but some people said that the apk still can be extracted and modified through reverse engineering.
My main concern is I want to encrypt my java files because I have some authentication data in my java files.
Can anyone give me a bulletproof method to protect java files from being inaccessible.
Edit -
Found few old thread in stack but they never explained about signed apk and protect them from getting exploited.
Yes. Cryptographic signing is not encryption. Signing proves that whoever signed it knew a secret key. Assuming the key is kept secure, you can be sure that two files signed by the same key are from the same person. With some forms of signing with public and private keys, it can be used to prove the identity of the signer. This does not provide any protection against reading that data, although it does provide protection against a counterfeit copy of the app being claimed as the real thing (assuming the user pays attention to the signature).
There is no way to do what you want to do. In the end, an app has to be run by a processor or interpreter. That means it needs to be translated into instructions that the processor understands. If you want something to be secure, do not put it on a client device. There is no way to protect it if you're sending it to a device that needs to decrypt it and use it.
Any APK can be decompressed and have its sources read. You cannot, however, edit it and sign it without the signing key.
There is no way to encrypt your source files and everything inside of them is readable by anyone. Authentication data shouldn't be stored in an application if it is expected to be secret.
signed apks can easily be reverse engineered. You should never place authentication data in the source code. There is no bullet proof solution for this. However you can make it difficult for the attacker by encoding and not placing your critical data in obvious places.
You should use another way to use your authentication data, I've read something about building a binary and storing inside the lib directory as a .so file, I'm not sure how exactly it's the proccess because I didn't tried, but you can research another methods, storing private data on Java source it's not secure.
I recently asked myself why in android we have to first sign and then zipalign the apk. I searched for some background information, how those processes are technically working in detail. I'm still a little bit unhappy, cause those description do not really technically explain why this sequence is necessary.
But lets start from the beginning:
I know the fact that in the apk-build-process following order is necessary
a lot of prior steps...
creating the apk-file
signing the apk-file (modifies apk)
zipaligning the apk-file (modifies apk)
I found some information here:
zipalign
So it is clear that zipalign will align internals to 4-byte-boundaries, so that all can be loaded with mmap.
It seems that a Signing- process would destroy this alignment. Therefore zipaligning has to be called at the end of the process after signing.
But why is it possible to make a re-aligning of the apk-content, without destroying the signature of the apk!?
the apk gets modified and the signature should not be valid after a modified apk, i thought...
Maybe someone has more technically background information than I did found here:
Signing your application
Thanks, if anyone has some helpful, more technically detailed information.
Luke
The digital signature of the APK is performed by hashing the APK components. As such, you are protecting the contents of the individual files, and not their position in memory. In other words, the APK contents are signed, but not the APK itself as a single file. As you correctly state, zipalign is merely padding the files in the APK so they start on an aligned boundary, to mmap(2) more efficiently (and be able to discard files easily). The contents, however, do not change, and therefore the signature is not violated.
MD5 fingerprint of any app can be easily acquired using keytool. Then what is the most unique identifier an app has?
I am trying to build a client server app and I want a secure the communications.
My problem revolves around these two assumptions -
1) Someone can reverse engineer my app and understand how I interact with server webservices
2) My app can be simply uninstalled and replaced with malicious app with similar package name.
The system can easily compromised using these two loopholes.
My solution to these problems was transmitting MD5 signature of my app to the server. The MD5 signature will be conveyed to server before hand. MD5 signature is unique for every app, But there is big problem in this approach. MD5 signature of any apk can be generated using keytool. Anyone may pull my apk and generate MD5 and use it in the webservices communication.
What is the unique identifier of an android app?
Package name and MD5 fingerprint can be easily compromised!
Basically you want to be sure that you are talking to your client app at server end.
Verify Back-End Calls from Android. This link could be helpful as it gives high confidence for such a case. (HTTPS is must here)
As an additional step for #Maddy 's answer, you might think about tamper resistance/integrity protection techniques, that will make your app inoperable in case somebody tried to modify it. DexProtector (http://dexprotector.com) could be the solution here. The slides under the link also should be helpful.
N.B.
I am Licel's CEO, thus I am affiliated with DexProtector.
First question
1) My app can be simply uninstalled and replaced with malicious app with similar package name.
best approach is probably the use of ANDROID_ID
Try this link http://blog.vogella.com/2011/04/11/android-unique-identifier/
Check this also http://android-developers.blogspot.in/2011/03/identifying-app-installations.html
Solution for the second issue
2) Someone can reverse engineer my app and understand how I interact with server webservices
Use DexGuard, which can make reverse engineering even harder, like by encrypting strings
https://www.saikoa.com/dexguard
Proguard
“The ProGuard tool shrinks, optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer.”
When you create android project.
1. proguard.cfg file is automatically generated in the root directory of the project.
2. The default configuration file only covers general cases, so customize as per your needs.
Enable it
“Set the proguard.config property in the /project.properties file. The path can be an absolute path or a path relative to the project’s root.”
Case1: Just add proguard.config=proguard.cfg if the proguard.cfg is in projects root path.
Case2: Configure from other location [proguard.config=/path/to/proguard.cfg]
Remove the “#” (or uncomment) the proguard configuring statement in project.properties. Which will be in commented initially.
Customize it. try this link http://1belong2jesus.wordpress.com/
This question already has answers here:
The apk must be signed with the same certificates as the previous version
(15 answers)
Closed 9 years ago.
I unconsciously deleted the apk file from my app and now I wanted to put a new version on the market. The error message is always this:
You uploaded an APK that is signed with a different certificate to your previous APKs. You must use the same certificate. Your existing APKs are signed with the certificate(s) with fingerprint(s):
and then goes a lot of numbers and letters. I know the password that I used to create the firsk apk.
This is probably a duplicate question, but I will still sum this up for you:
When you are creating APK, you use a keystore file containing a certificate to sign it.
Then, when you want to issue and update, certificates in old and new version must match, otherwise the system does not allow you to install it.
You most probably created this keystore file when you first generated the APK and then just forgot about it, so it is possible it is still sitting comfortably somewhere on your harddrive. You should look for it first :)
(They are quite small, 1-2kB, and every IDE has default path where to save them, so try creating a new one, see where it got saved and look if there isn't another similar file)
If you can't find it, it's time to panic. You are pretty much screwed if you want to issue and update. So, lesson number one:
Always backup your keystore files.
(I still do not understand why this is not shown as some big red flashy box during the APK upload dialog on Google Play :D)
So how to deal with this? You can change your package name, create new keystore, back it up, generate APK, unpublish your old app, publish new APK with same name and info.
Good luck with this. This almost made my hair gray this summer, so hope it won't happen to you :)
I'm not familiar with the idea of signing files, and I can't find a satisfactory answer so far, so I think I'd better ask:
What I want to know is when signing a binary file (for Android), does the signing tool assign some sort of checksum to the file so that when a hacker changed something in the apk file, the program would refuse to start because the checksum doesn't match. Does this mechanism exist in Android's signing tool?
Well, I understand when a hacker has the binary, he can disable anything he wants, including the checksum check. But the question is: Does Android's signing tool provide this level or protection in the first place?
Thank you for reading, and answering!
The answers that say "no, they can't modify your apk" are only about halfway right: Yes, no one can modify your code and resign it with your key, meaning the malicious cracker can't make the modified app look like it actually came from you. But that doesn't mean they can't modify and run the APK after resigning it with a different key.
They could take your signed APK, modify its code, and resign it themselves with their own key; they couldn't issue that app as an update or anything like that, but the modified self-signed APK would normally be installable by any user, root or not.
EDIT: Worth crawling around xda-developers to see what people are doing in that respect (some semi-legitimate, like modifying and reissuing theme APKs; other much less so). Tools like android-apktool are particularly interesting.
Also see these SO questions:
Can I re-sign an .apk with a different certificate than what it came with?
is it even possible to modify .apk, by adding additional class to .dex and re-packing with modified manifest.xml?
Android binary signing is accomplished using the Jarsigner tool, part of the standard Java SDK. Signing a jar with this tool simply adds two files; one that contains the hashed values for each file within the jar/application (the signature or .sf file), and one that verifies the signature file and identifies the signing certificate (DSA file).
So checking the signature would, yes, necessarily involve checking whether the hashes of the binary file match the provided value, which would detect any changes to the binary. And yes, the Android documentation says that the system will not install or run an application without a valid signature.
So yes, you can assume that signing your file properly will prevent it from running after being altered.
Yes, the OS must check that the content of the binary actually matches up to the signature. It would be worthless otherwise - someone could just take a signature from a legitimate application and stick it on to any other binary.