How can you tell if an APK has been modified?

What to check first when an APK looks tampered with

Start with the signing identity, because a modified apk usually breaks the trust chain even when the package name still looks legitimate. Compare the certificate used to sign the file with the publisher you expect, then compare the APK hash against a known-good release from a trusted source. If those do not line up, treat the file as untrusted before you install or sideload it.

Look beyond the signature as well. Tampering can preserve the outward package name while changing the manifest, embedded resources, native libraries, or bundled code. A reliable review checks whether requested permissions, component declarations, and embedded endpoints match the official build you intended to use.

For mobile apps, the integrity question is broader than “does it open?” because a repackaged APK can behave normally at first and still contain altered code paths, injected advertising SDKs, credential theft logic, or hidden remote-control features. The Mobile App Security Guide is a useful companion when you need to connect APK integrity checks with mobile reverse-engineering, keystore use, and tamper-resistance testing.

How runtime behaviour exposes repackaging or code injection

Static checks tell you whether the file still resembles the expected build, but runtime behaviour shows what the APK actually does on a device. Watch for new network destinations, unexpected certificate failures, suspicious background services, unusual permission prompts, and code paths that activate only after installation or first launch. A clean-looking APK can still be altered to contact different infrastructure or exfiltrate data once it runs.

Behavioural changes matter most when the app touches sensitive accounts, internal APIs, or device privileges. If the app suddenly requests broader access, loads code dynamically, or interacts with destinations not documented by the publisher, that is a practical indicator of modification even if the package name and icon remain unchanged.

Dynamic analysis is strongest when you compare the APK against a trusted baseline instead of judging it in isolation. Run it in an isolated environment, observe outbound connections, inspect loaded classes and libraries, and confirm that any backend endpoints or certificate pins match the expected release path. The goal is to distinguish ordinary app updates from hidden functional drift.

What evidence gives you confidence before deployment

The most useful evidence is a chain of agreement: trusted publisher, known-good hash, expected manifest, and runtime behaviour that matches the official build. If any one of those fails, the file may still be technically installable, but it should not be treated as the same artifact you vetted originally. The stronger the assurance needed, the more you should rely on a reproducible provenance trail rather than a single checksum alone.

Use the official app store or vendor release channel as your primary reference point, then compare the APK you received against that reference before you allow it into testing, staging, or endpoint fleets. For higher-risk deployments, keep a copy of the expected hash, signing certificate fingerprint, and release notes so you can prove the file you are reviewing is the file you intended to use.

When the APK is part of an enterprise rollout, the practical question is not only whether it is modified, but whether the modification changes trust in the app, its permissions, or its supply path. That is why integrity review should sit alongside mobile app vetting, not after users have already installed the package.

Risk and Threat Considerations

Modified APKs are attractive because they can preserve the appearance of a trusted app while changing its behaviour, permissions, or network targets. That makes repackaging a common route for credential theft, ad fraud, malware delivery, and silent data collection, especially when users install from unofficial stores or forwarded files.

Failure mechanism: Attackers replace or inject code after the original build, then rely on users or devices trusting the name, icon, and package metadata even though the signing certificate, hash, or runtime behaviour no longer matches the legitimate release.

Impact: The result can be account compromise, sensitive-data exposure, unexpected device permissions, or downstream compromise of any backend system the app can reach with stored tokens or active sessions.

Practitioner Guidance

What to verify: Verify the signer, the hash, and the app’s manifest together, not as separate checkboxes. A matching hash without a trusted signing identity is weak assurance, and a trusted signer without matching runtime behaviour is not enough for a high-risk deployment.

Decision rule: If the APK differs from the official release in signature, hash, declared permissions, or outbound destinations, block installation until the source is validated and the difference is explained. If the package is already in use, treat the issue as a potential compromise review, not just a file-integrity problem.

Practitioner takeaway: The safest stance is to trust only APKs whose origin, integrity, and behaviour all agree, because a repackaged app can look legitimate while quietly changing what it does on the device.

Related resources from NHI Mgmt Group

• What does SOC 2 Type II actually tell you about an AI vendor?
• Why does model accuracy alone not tell you whether an AI tool is usable in security operations?
• What does a strong ATT&CK evaluation result tell you about endpoint security maturity?
• How do you tell legitimate heavy usage from abuse at the device level?