How to verify apps with AppVerifier that are not in the internal database?

soupslurpr

https://github.com/soupslurpr/AppVerifier/blob/master/INTERNAL_DATABASE_CRITERIA.md

IcyScroll

For the verification info of an app from a source to be added to the internal verification info database, the source must be listed on the app's website or repository as an official way to get the app.

AppVerifier is used (with "Show hasMultipleSigners" on in Settings to visually verify that) to verify the validity of the submitted verification info to be included in the internal database.

I'm having trouble understanding the second paragraph and hasMultipleSigners in general. How exactly does it "verify the validity of submitted (where?) verification info"?
If I turn it on, it shows hasMultipleSigners: false on every app, no matter what.

Dumdum

IcyScroll then it's good enough to download their app multiple times, on different dates, ideally from various sources, devices, IP addresses, etc.
Every copy that you got this way should have the same hash of it's signature. If that's the case, then it's likely a genuine install, coming from the developer. So it's good idea to save it's SHA256 or SHA512 hash in a public database, so that others don't have to do the same "experiment" in order to have any kind of assurance that their install likely hasn't been tampered with by a third party. If all the signature hashes wouldn't turn out to be identical, that could indicate that at some point one or more of the sources serving said app were compromised and pushed an apk signed by a malicious third party. However, this type of attack is not persistent, as the developer would very likely notice it. Existing installs wouldn't be updated to it since Android uses Trust on First Use (TOFU) model to pin the certificate upon install.

Thank you. That's more or less how I figured that apps could be "verified" without a published hash.

I am aware that this "verification" method is not a perfect solution. However I think this is much better than just mindlessly downloading and hoping an app was signed by it's original developer.

Agreed. This is how I've done it before AppVerifier (similarly anyway, I would install an older version of an app and then update to newest) and will likely continue doing it even with AppVerifier.

soupslurpr I used AppVerifier to get the hash for Feeder

I assume by this, you mean the same way that IcyScroll mentioned above? Either way, this still doesn't explain why the source is "Github" for Feeder, unless you mean you're using Feeder's APKs from Github to check the hashes (via IcyScroll's method)?

soupslurpr

Dumdum just downloading the apk file once from the source (in that case GitHub) and obtaining its signing certificate hash with AppVerifier.

IcyScroll

soupslurpr To be honest that's fair enough, for use in a database. Having a place that saves a fingerprint from an older version of an app is still very useful and more reliable than downloading an older version of an app from the same source. It's like having a friend who already had the app installed.
The chance for a fingerprint to be compromised for long enough to affect safety of such model is very low. If an already added fingerprint would turn out to be fake, somebody would raise the alarm. Hopefully.

But if the process of getting signature hashes can be so straightforward, why does AppVerifier has so little of them? Also I don't understand - why don't you currently accept hash contributions? I get that nobody wants to spend their entire days adding those to the app but allowing people to post hashes freely would be beneficial for everyone. The more hashes from a greater span of time, the higher the assurance of them being valid - the easier for you to verify if they match before adding them to your app. Then it would be possible to slowly add missing crucial apps, all while people keep on contributing (and confirming) hashes, making the available data better and more useful.

I'm not trying to be mean, just trying to help. I appreciate your project the way it is. Thanks for taking time to respond on this forum.

soupslurpr

IcyScroll I don't want to spend resources and encourage others to do so on a stopgap solution.

Adding apps to the internal database requires checking where the app is being distributed, downloading them from those different sources, obtaining all the signing certificate hashes, and then adding it to the code and committing it.

Secure app stores are the true solution.

IcyScroll

soupslurpr

IcyScroll It's like having a friend

I'm afraid you didn't get that part 😅

IcyScroll

soupslurpr Secure app stores are the true solution.

Agreed. But having an option to verify apps not willing to get included in Accrescent in the near future is helpful. Especially since there are not many of those stores just yet and Accrescent seems to be rather far from a stable release right now.

Getting an app from Google Play can be considered secure but not necessarily ideal, due to Google signing apps.

soupslurpr

IcyScroll entries were posted as GitHub pull requests. I verify that the hashes from there is legit, along with the status of "hasMultipleSigners" which says whether an app is signed by multiple signers or only one signer.

soupslurpr

IcyScroll Of course, Accrescent is in a allowlist-only alpha at this time.

With an app that isn't in AppVerifier's database, you can still verify with friends over a trusted communication channel (such as a verified Signal chat).

bootloader

soupslurpr I know it is not the same security as Signal, but I'm thinking this might work in a community level as well. GOS users, who has Google Play installed could share their hash of apps, what are not in AppVerifier's database. I try and open a different topic for compare hashes!

soupslurpr

IcyScroll how would abuse be countered in that system?

IcyScroll

soupslurpr Sorry, my previous reply was supposed to be a joke.

By the "system" I meant a solution like AppVerifier.
By "allowing people to post hashes freely" I meant a platform where users would be able to post hashes, just so they become available somewhere on the internet (especially in case they were not officially published by an app's developer). There are probably many solutions that could be used for this purpose - let's say it would be a Flarum instance, like the one we're on now. Every thread there would be titled [app name] and OP would provide the first hash of its certificate from their install, similarly to how I did with AppManager earlier:

io.github.muntashirakon.AppManager
32:0C:0C:0F:E8:CE:F8:73:F2:B5:54:CB:88:C8:37:F1:51:25:89:DC:CE:D5:0C:5B:25:C4:3C:04:59:67:60:AB
Don't trust just this hash, cross-verify whenever possible!

Then others would be able to do the same, from their install.

Having some kind of system like this would be beneficial for people looking to cross-verify their install, including anyone who would wish to maintain a database of known legit hashes of certificates, like you do.

soupslurpr how would abuse be countered in that system?

I don't think abuse would be a problem as long as there would be at least a dozen of active non-malicious people and editing would be disabled or set to 10 minutes, like here. Even if bots were to raid such system, they wouldn't be able to delete other (older) posts. Even in such edge-case scenario, the damage would be limited as malicious hashes wouldn't be valid for an app (downloadable on a temporarily compromised source) indefinitely (someone will notice eventually). Given that, I think it would be enough for merely cross-verification purposes, aiding in finding a legitimate hash.

leo

Relevant to the discussion:

https://en.wikipedia.org/wiki/Key_server_(cryptographic)

Onlyfun

Murcielago Thank you for detailed guide! can you add where to obtain the app's SHA-256 fingerprint please?

Murcielago

Onlyfun

You're welcome. Unfortunately, there is no general answer to this. With some developers, you can find them on Github or their website (e.g. Signal), others do not publish them at all.

There is also a discussion sharing hashes here in the forum, maybe you'll find it helpful:

https://discuss.grapheneos.org/d/15368-lets-compare-hashes-for-apps-not-in-appverifiers-database

Onlyfun

Murcielago got you! appreciate the link!

DeletedUser312

I am a new user of App Verfier and have just read this: https://github.com/soupslurpr/AppVerifier through. Unfortunately, I am not sure if I understood, what an identical hash exactely means, i.e. when I compare APK from different sources. Can s.o. explain? Does it mean that those apps are absolutely identical? Or does it only mean that the two apps originally came from the same author/builder/signer?

I have been told that Aurora Store is just another front end for the Playstore. I downloaded an App from Aurora and the same App from Playstore. App Verifier shows me that the two apps I downloaded have the same hash. So does this prove, that I got the original playstore version from Aurora?

If someone would offer a maliciously altered app (that originally came from Playstoe) on a website, would that app necessarily show a different hash than the original app from the playstore?

Thanks.

IcyScroll

DeletedUser312 Does it mean that those apps are absolutely identical?

No, developers can provide different builds of the same app with different features. An example: Aves Gallery and Aves Gallery Libre. The hash merely proves that an app came from (was signed by) a specific party.

DeletedUser312 Or does it only mean that the two apps originally came from the same author/builder/signer?

This.

DeletedUser312 So does this prove, that I got the original playstore version from Aurora?

Yes.

DeletedUser312 If someone would offer a maliciously altered app (that originally came from Playstoe) on a website, would that app necessarily show a different hash than the original app from the playstore?

Yes, the hash for said app would be different as it would have been signed by a different party without access to private key used for signing. Assuming original dev keeps their key secure (hasn't been leaked/stolen, remains a secret).

« Previous Page