APK and IPA checksums (MD5, SHA-1, SHA-256): why they are requested and how to get them

When you submit a mobile app for a cybersecurity expertise, you are asked for the APK or IPA file along with its checksums — MD5, SHA-1 and SHA-256. Teams seeing this requirement for the first time often ask, "where do we get these?" In fact it takes a minute. But there is one subtle rule, and breaking it leads to extra back-and-forth and lost time.

What a checksum is

A checksum (hash) is a short "fingerprint" computed from a file's contents. The same file always produces the same value. Change even one byte and the value is completely different.

For the expertise, this answers several questions:

• Which file exactly was tested? Findings in the report relate to a specific build. The hash identifies that build unambiguously.
• Did the file change in transit? You can confirm it was not corrupted or swapped during upload or transfer.
• Is the tested file the same as the distributed one? It gives a basis for later comparison.

MD5 and SHA-1 are considered cryptographically weak today — collision attacks against them are known. So the main trustworthy value is SHA-256. MD5 and SHA-1 are usually requested as additional identifiers for compatibility and convenience.

How to get them

Linux

md5sum app-release.apk
sha1sum app-release.apk
sha256sum app-release.apk

macOS

md5 app-release.ipa
shasum -a 1 app-release.ipa
shasum -a 256 app-release.ipa

Windows (PowerShell)

Get-FileHash .\app-release.apk -Algorithm MD5
Get-FileHash .\app-release.apk -Algorithm SHA1
Get-FileHash .\app-release.apk -Algorithm SHA256

Without PowerShell, certutil works from the regular command prompt:

certutil -hashfile app-release.apk SHA256

It is convenient to write the results into one text file and submit them together with the file name, version number and build date. For example: app-release.apk, version 2.3.1 (build 45), SHA-256: ....

The main rule: the exact file you submit

A checksum is valid only for that exact file. Therefore:

1. Build the final file first, then take the hash, then submit that very file.
2. Do not rebuild after hashing. Even a build from the same code with the same settings often produces a different hash: build timestamps, the signature and other factors differ.
3. Do not re-sign the file or modify it by unpacking and repacking. If the signature changes, so does the hash.
4. Several files means one hash each. An APK and an IPA, or separate APKs for different architectures — each has its own value.
5. If you put the file in a zip, clarify which file the expertise expects the hash for: the archive itself or the APK/IPA inside it.

If you make fixes during the expertise and submit a new build, take fresh hashes for the new file as well. Sending old values with a new file is a common mistake.

How to verify a value

Besides producing a hash, it helps to know how to check one — for example, before uploading the file to the expertise portal or after receiving it from a colleague. On Linux you can write the values to a file and verify them automatically:

sha256sum app-release.apk > app-release.apk.sha256
sha256sum -c app-release.apk.sha256

If you see app-release.apk: OK, the file has not changed. In PowerShell a simple comparison is enough: (Get-FileHash .\app-release.apk).Hash -eq "EXPECTED_VALUE" should return True. If you compare by eye, check the whole string, not just the beginning and the end.

The store file may differ

This often raises questions, so it is good to know in advance:

• Google Play. With Play App Signing, you upload an AAB, and Google builds APKs from it and signs them with its own key. The APK users receive has a different hash from the file you submitted.
• App Store. Apple further processes and encrypts the app in the store, so an app downloaded from the store will not match your IPA's hash either.

This is normal. So submit for expertise not a copy from the store, but the file you built and prepared for testing, and state its hash. The code and settings must match the tested build.

Order of preparing the file

We followed this order when submitting our own product and recommend it to clients:

1. Build the final version with all fixes in and release settings (obfuscation, R8, RASP) enabled.
2. Install the file on a test device and briefly check the main flows and protection measures (root/jailbreak, tamper).
3. Only then take MD5, SHA-1 and SHA-256.
4. Submit the file, hashes, version and build number as one package.
5. Keep a copy of the file and the hashes yourself — for follow-up questions and re-testing.

This simple order prevents situations such as "we tested a different file" or "the values do not match".

Security scan

Want to get your app ready before submitting it for expertise? Request a security scan. The Claude AI agent and our specialist will review your APK or IPA and show what needs closing before submission.