Signature Verification Catches What a Checksum Cannot
SHA-256 proves the file matches the listing. It says nothing about who built it. Signature verification is what 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 build — Discard; the checksum was computed after modification
Signature mismatch on update
Install attempt fails — Ask 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
- 1Compute SHA-256 on the exact file on disk and compare against the listing.
- 2Run apksigner verify --print-certs and record the certificate digest.
- 3Compare that digest against the installed copy, if you already have the app.
- 4Confirm the signature scheme is v2 or later.
- 5Read the declared permission list before first launch, not after.
- 6Treat a checksum match with an unexpected signer as the stronger signal, and stop.
Cross-check Against the Come Sports Manifest
The signature digest is only useful when compared to the developer's current signer. Confirm package name, version, file size, and SHA-256 of the APK you are checking against /en/come-app/#platform-manifest or /en/dream11-app/#site-downloads; a signer digest that does not match the manifest signer means the file is not a developer-signed release, regardless of how the local signature verification passes.
All four checks (package name, version, file size, SHA-256) are anchored at the Come Sports release manifest. A mismatch on any field is treated as tampering evidence per /en/blog/sha-256-apk-integrity/ — delete the build and re-fetch from the verified manifest.
Frequently Asked Questions
What does SHA-256 verification prove about an APK?+
A matching SHA-256 hash proves the downloaded file is bit-for-bit identical to the one Come Sports listed. It does not prove the file is safe, signed, or appropriate for your device — a signature check is a separate step.
How does Come Sports decide which APKs to list?+
Come Sports lists APKs that come from a named publisher, ship a fixed version, and let us verify the SHA-256 hash, file size, and version code against the publisher's public statement. Listings that fail any of those checks are removed.
Is Come Sports affiliated with Dream11 or FanCode?+
No. Come Sports is an independent verification platform. We are not owned, operated, or sponsored by Dream11, FanCode, or any trademarked entity referenced on this site. See the disclaimer page for the full independence statement.
