How to Check an APK Is the Developer’s Original: Hash and Signing Certificate

You can check an APK that didn’t come straight from its developer yourself, without taking the download site’s word for it. There are two steps: compare the file’s SHA-256 hash, then compare its signing certificate. The hash shows that the file is byte for byte the one that was published. The certificate shows whose release it is.

Where to get the values to compare against

• From the developer, when they publish them. Some projects list the SHA-256 of their signing certificate in the README or on their website, and some publish checksums next to their downloads.
• From the repository you would otherwise install from, such as F-Droid or IzzyOnDroid.
• From us: every app page on 2113 Apps shows “File SHA-256” and “Signer SHA-256” under More Information, and the verified-android-apps list has both values for every file we host.

A value from a second, independent place is worth more than one from the same page as the download.

Step 1: compare the file hash

System	Command
Linux	sha256sum app.apk
macOS	shasum -a 256 app.apk
Windows (PowerShell)	Get-FileHash app.apk

Get-FileHash uses SHA-256 by default and prints the hash in capitals. Case doesn’t matter when you compare. On the phone itself, Fossify File Manager shows a file’s SHA-256 in its properties.

Change a single byte and the hash is completely different. Each version, and each CPU-specific build of the same version, has its own hash, so compare against the exact file you downloaded.

Step 2: check the signing certificate

When Android installs an update, it compares the certificates of the new version with those of the installed app, and allows the update only if they match. So the signing certificate is what ties an APK to its developer.

With apksigner, on a computer

apksigner comes with the Android SDK Build Tools. Run:

apksigner verify --print-certs app.apk

It checks the signature, then prints the signing certificate. Which line to compare depends on the Build Tools version. We ran Canta 3.2.2 through two of them. Version 36.1.0 and earlier print:

Signer #1 certificate SHA-256 digest: 0a2640317c43272188c3e13194c15460691f12c39ea19bba727dd67fb56289d4

Version 37.0.0 names the signature scheme instead:

V2 Signer: certificate SHA-256 digest: 0a2640317c43272188c3e13194c15460691f12c39ea19bba727dd67fb56289d4

With version 37, apps signed with the newer v3 scheme, such as NewPipe, get a line starting with V3.0 Signer: instead. If the file was changed after it was signed, apksigner prints DOES NOT VERIFY and an error instead of a certificate. That is what we got after changing a single byte in a copy of the Canta APK.

With keytool, if you have Java

keytool -printcert -jarfile app.apk

This prints the certificate’s SHA256: fingerprint in capitals, with colons between the bytes. It only reads the old v1 (JAR) signature, which many current APKs no longer carry. For those it answers Not a signed jar file: of the APKs we tried, NewPipe and Termux printed a fingerprint, while Fossify Calendar and Kiwix didn’t. A v1 signature also doesn’t protect every part of the file, while the v2 and later schemes that apksigner checks cover the whole APK. So if you can, use apksigner.

On the phone

• App Manager shows the checksums of an installed app’s signing certificate in the Signatures tab of its app details, in MD5, SHA1, SHA256 and SHA512. Its manual warns to compare only the SHA256 one, because MD5 and SHA1 can give the same checksum for different certificates.
• AppVerifier, an open-source app from the Accrescent store or GitHub, compares an installed app’s certificate hash with one you give it, or with its own list of known apps.

What the result means

• Hash and signer both match: the file is identical to the published release and signed with the expected key. That shows who made it. It doesn’t show that the app is safe or free of bugs.
• The signer matches but the hash doesn’t: a different file from the same developer, usually another version or a build for another CPU type. Compare against the right file.
• The signer doesn’t match: someone other than the expected developer signed it, so don’t install it. The exception is F-Droid, which signs the apps it builds itself with its own keys. Those are real F-Droid builds, but Android won’t install one over the developer’s own version, or the other way round, without uninstalling first.
• More than one certificate: an APK can carry more than one, for example after the developer rotated their signing key. A match with any of them is expected.