MNM you may find it on the developers website, social media, app's website. Make sure not to get it from the same place you got the app from since if the app can be replaced the posted hash probably can too.

In general you should try to use app stores which verify their apps. Accrescent has Aves and is installable through the GrapheneOS App Store.

    soupslurpr
    So there's no way to have the SHA other than directly from developers themselves?

    Also, I recall looking at AppVerifier yesterday where it says that the source for, lets say, Feeder is from Github. But where is the provided signature/verification info? Bitwarden, for example, has the SHA-256.txt files in Releases but I couldn't find anything for Feeder.

        Dumdum right, you can also get it from a friend who has the app installed already.

        If you can't find anything then it doesn't exist?

            soupslurpr If you can't find anything then it doesn't exist?

            I don't understand this question. Is it even meant to be a question?

                10 days later

                soupslurpr
                Then where did you get the SHA for Feeder, and why does your app say the source is from Github? If it "doesn't exist", then the information your app provides is just incorrect. Made up. False.

                    I'm also confused on how to verify apps that aren't found in the database. Do I have to download the apks to my files app? I already have them in Obtainium.

                    Dumdum
                    It is actually the developer's responsibility to prevent manipulation as far as possible and it should be in the interest of a reputable developer that no third party secretly exchanges his software and thus damages his reputation.

                    So: if a developer does not publish a hash/fingerprint for his app, he is sloppy or has something to hide.
                    For users, this means it's better to keep your hands off and use software from other developers…

                        Eagle_Owl I agree, publishing at least a hash of the fingerprint should be much more common. I don't understand why so few developers do so. Even posting it in only one place, next to the download, would be better than not doing it at all. Maybe it's just not a common knowledge among non-security-centered developers? Might be worth letting them know and seeing how they respond before assuming malice.

                        In the meantime, I think I might have found a mitigation to this problem:

                        Dumdum where did you get the SHA for Feeder, and why does your app say the source is from Github?

                        My guess is that if a developer does not provide hash signature (or anything else that could be used for verification) 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.

                        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.

                        @soupslurpr if you woud like, I am willing to provide a few hashes of useful apps that I "verified" this way - for cross-verification purposes ;)
                        I'm also curious if that's something you and others did to get some hashes for AppVerifier's database.

                        App Manager has an apk scanner enabling users to check hashes from MD5 up to SHA512 so it might be relevant to this thread.
                        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!

                              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)?

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

                                        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.

                                            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.

                                                soupslurpr

                                                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.

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