Security InsightsJuly 27, 2026

Signature Verification Catches What a Checksum Cannot

A SHA-256 match proves the file you hold is the file that was listed. It says nothing about who built it. Signature verification answers the other question, and it is the one that catches repackaged APKs.

Two Different Questions

A checksum answers integrity: did this file arrive intact and unmodified from whatever was published. A signature answers authenticity: which signing key produced this build. They are not substitutes, and a repackaged APK is exactly the case where the difference decides the outcome.

Consider the failure mode. An attacker takes a legitimate APK, injects an ad or tracker SDK, re-signs it with their own key, and publishes it with a fresh checksum. The checksum matches the file perfectly, because they computed it after modifying the file. Nothing about that comparison protects you. The signing certificate is what differs, and it differs permanently.

How Android Uses the Certificate

Android ties app identity to the pair of package name and signing certificate. An update is only accepted when both match the installed copy. This is why a repackaged build cannot quietly replace a legitimate one: the install fails with a signature mismatch rather than succeeding silently.

That failure is a security control doing its job. The common advice to uninstall the original and install the new file works mechanically, and it also discards the exact protection that just fired. Before doing it, the question worth answering is why the certificate changed at all.

Legitimate certificate changes happen. A developer rotates signing keys, or moves to Play App Signing. Those are announced and documented. An unannounced change on a build from an unfamiliar mirror fits a different pattern.

Tips

Checksum match, unexpected signer

Repackaged buildDiscard; the checksum was computed after modification

Signature mismatch on update

Install attempt failsAsk why the signer changed before uninstalling the original

Reading the Signer From a File

Android build-tools ship apksigner, which reports the certificate digests for an APK without installing it. Run apksigner verify --print-certs file.apk and read the SHA-256 digest of the signing certificate. Keytool on a JDK gives equivalent output.

The digest is only useful compared against something. For an app you already have installed, compare the new file's signer digest against the installed copy. For a first install, the value tells you which signer to expect on every future update of that app, which is when the comparison starts paying off.

Verify the APK signature scheme version too. Modern builds use v2 or later, which signs the whole archive rather than individual entries. A build presenting only the legacy v1 scheme is either old or has been through tooling that stripped the newer block.

Practical Sequence Before Any Install

Checklist

  • 1
    Compute SHA-256 on the exact file on disk and compare against the listing.
  • 2
    Run apksigner verify --print-certs and record the certificate digest.
  • 3
    Compare that digest against the installed copy, if you already have the app.
  • 4
    Confirm the signature scheme is v2 or later.
  • 5
    Read the declared permission list before first launch, not after.
  • 6
    Treat a checksum match with an unexpected signer as the stronger signal, and stop.