I'm attempting to reverse engineer an android app called HeartTrace in order to pull sensor data at a higher frequency. I decompiled, adjusted the parameters, and recompiled the APK. However, the app no longer connects to Google Fit API. Does the API require a new signature from Google before recompiling? If not, what is the issue? Thanks!
As mentioned in Sign Your App,
Android requires that all APKs be digitally signed with a certificate before they can be installed.
Therefore, you need to digitally sign the app again using these two options:
use the same key which can be found in .keystore file if the app has already been published in apps store, or
generate a new key to be used in signing in
However, if you opt to use a new key, don't forget to check Signing Considerations.
I highly recommend going through the given documentation wherein these are being discussed in complete details:
describes how to sign your APKs, including creating and storing your certificate,
signing different build configurations using different certificates, and
configuring the build process to sign your APKs automatically.
And for additional information, this tutorial on Google Fit for Android: Reading Sensor Data and solution given in this SO post - Google maps does not work after resigning an apk which is related to decompiling an Android app might also help.
Related
I am using a simple TWA (a Website with PWA supported packaged into a native Android app) with bubblewrap. In order to get this TWA working properly it must have an assetlinks.json file including the sha256 fingerprint of the signing key uploaded to the webserver.
There seem to be two keys for signing: An app and an upload key.
If I release the app via playstore, the TWA want to see the app key
If I just install the local apk file it expects the upload key
Also different key tools will output different keys:
Bubblewrap seems to use the App Key: bubblewrap/bubblewrap fingerprint generateAssetLinks
Google Play seems to use the App Key as well.
The keytool seems to use the upload key: keytool -printcert -jarfile app-release-signed.apk | grep SHA256
Now I am wondering if I missunderstand something. Why does the local apk file expects a different key than the playstore release? Is it safe to upload both shasums to the assetlinks.json file in order to allow playstore releases and local testing?
So it took me some time to understand the whole process and also to find the correct documentation.
I highly recommend reading the documentation
The app key is used for Google Play releases and the upload key for local apk files.
It is safe to integrate both into the assetlinks.json file, also explained in the documentation
For local testing and google play releases at the same time it is required to have both keys listed in the file
The keys can be obtained from the 3 locations mentioned in the question
It might take some time that your device will recognize the update of that file. It is cached by google.
Also interesting to hear from a google developer:
Having both fingerprints in your asset link file is definitely more convenient, and it's something that I personally do. However, my TWAs are for testing, so I'm not too concerned about security implications.
The downside is that you increase your attack surface - if someone steals your debug key (which is probably sitting unencrypted, with some default password on your computer) they could claim to be associated with your website (and intercept links to it from their app).
We're working on an app which needs to integrate with a specific hardware component.
Now, after an update on the side of the hardware vendor, they tell us we need to sign our APK with their .keystore (which they've provided, including a password) in order to work with their hardware.
I can confirm this approach works in debug mode, the APK is signed and we have access to the hardware. However this doesn't work with Google Play signing, because Google expects the APK to be signed with our uploading certificate (and signs the APK with the key stored on their systems afterwards).
This strikes me as a very strange approach, shouldn't the .keystore and password be kept private? And are we opening ourselves up to a massive security risk if we sign the app with their keys?
Any advice is much appreciated, thank you!
It is very unusual and a potential security risk to use the signing key and password which is provided by a third party.
But: Apps that are signed with the same key as the OS on an android device can get special permissions. This might be necessary to use hardware features and system APIs on an android device which are usually not available to normal apps through Android.
Besides that, when you setup Google Play app signing, you can provide your own signing key and password. This would allow you to use the key from your hardware partner in production Play Store apps.
Recently Google has introduced security metadata that is added to every app uploaded into Google Play. We used to have a tampering protection that's calculating the app's signature (hash) in runtime and check if it's equal to hash that was calculated during the release. This worked fine for years, but now the GP is modifying the app's binary by adding the security metadata.
Is there a way to disable GP security metadata at all?
Is there a way to check (download) modified APK from the store without publishing it? It seems that apps in beta channels are not modified so this solution doesn't work.
There is no way to disable the Google Play security metadata.
You can't get it without publishing an app
APKs in alpha and beta channels are modified (or should be) but only if they were uploaded after the start date of the program (2018-06-19 12:00 UTC). However, the APK will have different metadata when it is in Beta to when it is in production.
Hashing solutions will continue to work, but not ones which hash the whole file. Alternatives you could consider include hashing the zip entries, or hashing the classes.dex files. These methods work successfully for other developers.
Another option which works if you occasionally have online access (which I assume you do if you are checking a hash) is to use the SafetyNet attestation API to check your app, and verify the signature offline on the server. Again, many big name developers use this successfully.
Not directly answering your questions, sorry, but posting anyway in case that helps you or anyone else in the same case: instead of checking the hash, have you considered verifying the signature of the APK? Apksig is an open source library and would allow you to achieve a similar result in a more robust way.
For our senior project, four of my classmates and I have teamed up to build an Android app that uses Google Maps.
So far everything is going fine, but we have hit one issue that we are not sure how to work around.
When using the Maps API, you sign up for an API key that is assigned to the program we are creating. In order to authenticate the API key on the Google Developer console, it must be associated with an SHA-1 certification, which appears to be generated by our JDK. It would seem that, even though all five of us are working on the same project, we all have different SHA-1 certifications.
Is it possible for all of us to use a single SHA-1 certification for our project, even though we are on different computers and phones, so that we don’t need to go through the process of discovering each of our individual certifications and registering them?
How do we get around this certification issue once we are prepared to publish the app (or at least share it with our other classmates for testing)? Clearly I can not take the time register each of my 40 classmates’ certifications individually, and once we release this to the public there will be no way to do so. How does one get around this?
I’ve searched on the Google API documentation pages about this, and there is plenty of information about the API key, but surprisingly little about the SHA-1 certification, which is an equally important aspect of authentication.
I've also searched on this site and found similar questions, but most of them seem to involve user credentials (IE login and password). At this time, the only credentials we are using is a Facebook login (via the FB API) so I don't think that is relevant (though I may be wrong).
Thank you so much for your time and wisdom.
This is because the SHA-1 fingerprint is generated by the keystore used to sign the builds. The default debug keystore located in the android home directory is different on every computer. You can either add the fingerprints from all the the debug keystores you are using or share the same keystore file.
Sharing the same keystore can be easily be done by storing it inside the project folder and then referencing it with the gradle build file with the signingConfig. see example
The other easy solution is to add everyone's SHA-1 fingerprint in the Google Cloud console for Google Maps API project you have setup.
Amazon's documentation is surprising lacking in information about the submitting binary process. From what I can tell, you submit an unsigned binary and they wrap it in their own code and produce a signed apk?
This leaves several questions:
Does the Amazon App Store perform a zipalign for you?
If you have your app in the Android Market (Google's) already, is it recommended to use the same package name or a different one? Does it make any difference?
I also saw elsewhere, that they offer the option to download the apk they prepare and sign it with your own key. Is it recommended to take this and then sign it with the same key you are using in the Android Market? Does it make any difference?
Are there any other considerations or pitfalls that one should know before diving into this process?
Yes. Amazon wraps your binary with code specific to their appstore that allows them to collect analytics data and enforce DRM. The app will be repackaged after that.
You should use the same package name. The Amazon distribution agreement currently has a number of provisos; e.g., that your app is not priced lower on another app store. They also do occasional checks to see whether the version of your app on the market is up to date. These checks are primarily done using the package name; changing the package name of your app could easily be viewed by them as a means to evade the terms of the agreement.
No. There may be good reasons why one would want to do this, but none that I can think of. By default, Amazon signs your apk with a signature that is specific to your Amazon developer account.
Other:
Read this. In particular, ensure that the app links correctly to the Amazon app store and not the Android market, or others. I don't have inside data, but I'd wager a fair amount that the vast majority of submissions that Amazon turn down fall afoul of that requirement.
Edit: Point 2 is no longer correct; see comment below.
Here is the reply I received from the amazon mobile app distribution team for a question concerning whether to submit signed or unsigned apk's:
"You can submit signed, or unsigned binaries to the store - we will then apply our signature to your app in either case. If you need to sign your app with a known signature (if you are using Facebook authorization for example) you can choose to upload your app using our self signing process (you will need to ask us for this to be enabled for you)."
The most straight forward way to submit an app is to export your signed apk from Eclipse (all zip aligned are ready to go), then upload via the Distribution Portal using our DRM and signature.
For the latest update of my app I just took the same signed apk I previously released to google play, and it worked well.
I have only published two little applications that sell almost nothing, but both got aproved and I followed exactly the same procedure I follow for publishing on the Android Market: I just exported the signed .apk from eclipse and also used the same package name. So far I have no problems, so I guess it's ok.
You should zipalign during every build, as a matter of practice.
I use the same exact build process for Amazon as I do before publishing to Google. Only difference is an Interface's variable to determine the market link (at build time, if/else is compiled out).