MOD APKs: Why a Valid Signature Doesn’t Mean a Safe App
How Android apps get modified, how attackers abuse it, and how to protect yourself
By Isha Sonaria | Cybersecurity
You download a popular app from a website instead of Google Play. It has no ads, every premium feature is unlocked, and it works perfectly. What could go wrong?
Quite a lot, as it turns out. That app is a MOD APK, and understanding how it is made is the first step to understanding why it can be dangerous.
What is a MOD APK?
Android apps are distributed as APK files. An APK is simply a signed ZIP archive containing compiled code, resources and a manifest. Because an APK can be unpacked, edited, rebuilt and re-signed, anyone with the right tools can create a modified version of an existing app. That modified version is a MOD APK.
Not all modifications are bad. Theming, translation, accessibility improvements and authorised security testing are all legitimate. The problem starts when modified apps are shared as if they were the original, with changes hidden from the user.
The difference comes down to a few questions: Do you own the app or have permission to change it? Is the purpose customisation or fraud? Are the changes documented or concealed? Technical ability to modify an APK does not grant legal permission to do so.
Inside an APK
To see how tampering works, it helps to know what is inside an APK:
- AndroidManifest.xml declares the package name, components and permissions.
- classes.dex holds the compiled app code, which runs on the Android Runtime (ART).
- res/ and resources.arsc contain layouts, images, colours and strings.
- assets/ and lib/ hold raw files and native libraries.
- Signature data identifies which key signed the package.
Two security ideas matter most here. First, signing: Android uses the signing certificate to identify the developer and to decide whether an update may replace an installed app. Second, sandboxing: each app runs under its own Linux user ID with private storage, so apps normally cannot read each other’s data.
The toolbox
Researchers and attackers use largely the same tools:
- JADX decompiles DEX code into readable, approximate Java. It is great for reading code but not for reliable rebuilding.
- Apktool decodes resources and the manifest, turns code into smali, and rebuilds an APK after edits.
- Android Studio builds apps and includes the APK Analyzer and emulator.
- ADB installs apps, reads logs and opens shell sessions on a device.
- MobSF runs automated static and dynamic analysis.
- zipalign and apksigner align and sign APKs.
A few common misconceptions are worth correcting. Apktool does not produce Java source; it produces smali, while JADX produces approximate Java. Any change to an APK invalidates the original signature, so the modifier must re-sign with a different key. And a rebuilt, signed APK is not automatically safe, because signing only attaches an identity and says nothing about behaviour.
How modification works
The workflow has seven stages: inspect the original, decode it, make an authorised change, rebuild, align and sign with a new key, then test in an isolated environment.
Because the modifier signs with a new key, the result is a different app identity. It cannot receive updates from the original developer, and Android refuses to install it over the original app.
I demonstrated this in a safe lab using a “Hello World” app I built myself. I changed only the app name in strings.xml, rebuilt it and signed it with a test key. The result: a different SHA-256 hash, a different signing certificate, and an install failure when I tried to place it over the original. A harmless edit created a technically valid but separately trusted application.
Get Isha Sonaria’s stories in your inbox
Join Medium for free to get updates from this writer.
The golden rule of this kind of research is to only ever work on apps you own or are explicitly authorised to examine.
Where the risk comes from
A repackaged app can keep the same name, icon and features while a small added module quietly does something else. Depending on the modification, the risks include:
- Fake login screens that imitate a trusted brand (phishing look-alikes)
- Removed licence or integrity checks
- Extra manifest permissions
- Code injection, data and credential theft
- Hidden adware and fraud
- Weakened authentication or insecure data storage
The user sees a working app and has no visible reason for suspicion. That is exactly what makes MOD APKs such an effective delivery vehicle for malware, especially when many people trust a single distribution source.
Two real-world case studies
Agent Smith (2019)
In July 2019, Check Point Research reported a campaign called Agent Smith. Bait apps such as photo utilities and games were installed from a third-party app store. The malware then replaced popular installed apps with malicious repackaged versions, without user interaction, and used them to show or hijack advertisements for fraudulent revenue. Reports estimated about 25 million infected devices, with India most affected.
The lessons: third-party stores lack security vetting, unpatched devices are exposed, and a genuine-looking app can be silently replaced. The same access could have enabled more serious abuse such as credential theft.
The Janus vulnerability (CVE-2017–13156)
Janus explains how Agent Smith could bypass integrity checks. Guardsquare reported that a file could be both a valid APK and a valid DEX file. An attacker could prepend malicious code to an APK without changing the signature checked under signing scheme v1. A fake “update” could then pass signature checks and replace a legitimate app, inheriting its permissions.
It affected Android 5.0 and newer using v1 signatures, while apps signed with scheme v2 on Android 7.0+ were protected. Google patched it in the December 2017 Android Security Bulletin.
The lesson: integrity checks are only as strong as their implementation, which is why whole-file signing schemes (v2 and later) matter.
How to detect a suspicious APK
No single check is enough, so analysts use layers:
- Source check: is it from an official store and a known publisher?
- Hash and signature: compare against the official release.
- Static analysis: review permissions, the manifest and suspicious APIs.
- Dynamic analysis: watch network and file activity in a sandbox.
- Malware scanning: use reputation services, MobSF and AV engines.
Every method has limits. Hash comparison needs a trusted reference, scanners miss new or obfuscated code, and sandboxes can be evaded by malware that delays its behaviour. Combining methods is what improves reliability.
What you can do
If you are a user: install apps from trusted stores like Google Play, avoid unknown APK files, review permissions, keep Android and your apps updated, use a reputable mobile security tool, and remove apps that behave strangely.
If you are a developer: follow the OWASP Mobile Application Security Verification Standard (MASVS), request least-privilege permissions, store data securely, protect network traffic, sign with APK Signature Scheme v2 or later, use obfuscation as a deterrent rather than a guarantee, use the Play Integrity API for integrity signals, and test regularly with the OWASP Mobile Application Security Testing Guide.
The takeaway
Rebuilding and signing an APK is technically simple. Verifying that it is trustworthy is hard. A new signature, a changed hash and a hidden code module can all exist inside an app that works exactly as you expect.
So remember: a valid signature proves who signed an APK, not that the APK is safe.
Sources: Check Point Research (2019) on Agent Smith; Guardsquare (2017) on the Janus vulnerability; Android Open Source Project and Android Developers documentation; OWASP MASVS and MASTG.
This article is based on my cybersecurity thesis on Android application modification. All APK research should be limited to applications you own or are authorised to examine.
