Dangerous Permissions to Avoid

Android isolates each app in its own user ID and private storage. Camera, microphone, location, contacts, SMS, and a handful of "special" services are not in that default box. They are capabilities the OS will not give unless you (or, on older versions, an install-time list you barely read) say yes. Runtime prompts exist because a yes is not a mood. It is a key. The key stays until you revoke it in Settings, even if you forgot the app was still installed. Malware authors study which keys unlock money. They do not need a kernel exploit if they can talk a hurried human into Accessibility plus notification listener plus SMS. The rest of this lesson names those keys as mechanisms — what the API can actually do — so "suspicious" is not a vibe. It is a mismatch: the stated job does not require that power. When the job and the permission disagree, Deny is the correct security control, not rudeness.

Ordinary permissions (internet, vibrate, receive boot) are noisy but rarely account-takeover by themselves. Dangerous and special permissions are the ones that read secrets or act as you. Camera for a camera app is matched. Contacts for a messenger you actually use can be matched. SMS for a wallpaper, Accessibility for a "battery saver," notification access for a flashlight — those are not matches. They are the install-time social engineering Module 1 already showed you in fake stores and banking trojans. Your job is to treat the prompt as a second install decision, not as a speed bump.

Android Accessibility was built so a screen reader, switch control, or voice access service can observe on-screen text and perform gestures a person with a disability cannot. That is a real, legitimate need. The same APIs can observe every pixel of a banking session, copy what you type, and click Approve on a payment you did not intend. There is no separate "malware Accessibility." There is one powerful service class. The difference is who you enroll and whether their job requires seeing every app. Banking trojans and stalkerware love this grant because it bypasses the usual "this app cannot see that app's screen" rule. Overlay phishing (lesson heading 4) often pairs with Accessibility so the fake pad can harvest, then the service can confirm inside the real app. A password manager from a vendor you already trust may need Autofill — a different, narrower capability. A random cleaner, RAM booster, or "WhatsApp plus" does not need to watch your UI. If an unfamiliar package asks to turn Accessibility on, that is a stop, not a maybe.

Enrollment is not the Play Store install. It is a separate Settings path: Accessibility → downloaded services (wording varies by OEM). Attackers put a tutorial in the app: "Turn this on or the saver will not work." That tutorial is the exploit. You do not need to know how to write an AccessibilityService. You need to know that anything in that list you do not recognize should be off, and that genuine assistive tools you chose on purpose can stay. Audit the list. Uninstall the stranger. Do not "test" a sideloaded APK to see if Accessibility is "really that bad."

SMS permission lets an app read (and sometimes send) text messages. Banks, Google, WhatsApp, and email still deliver one-time codes over SMS for millions of people. If hostile code can read those messages, the password you typed on a phishing page — or the session it already has — becomes a completed login. Call-log access is a cousin: it is private conversation metadata, and some regions treat it as sensitive as the messages themselves. A flashlight, a theme pack, a PDF scanner, or a "system cleaner" has no honest job that requires your inbox of OTPs. Default SMS handler is even hotter. The app that owns SMS can often intercept before you glance at the notification. Dual-SIM users sometimes install "second number" tools from blogs; those are a favorite trojan costume. If you need SMS from a carrier app, install that carrier's official listing via a URL you type, then still deny SMS to everyone else. This course will not teach you how to intercept SMS on a device you do not own, and it will not give you malware samples to reverse.

Notification access (Notification Listener) is the quieter twin. Many 2FA apps, banks, and mail clients show the code on the lock screen or as a heads-up. A listener can read that text without SMS permission at all. Authenticator apps that display a six-digit number in a notification are in scope. So are "Your bank: 482193 is your code" banners. Hide sensitive content on the lock screen (next lesson) reduces shoulder surfing; it does not stop an enrolled listener. Settings → Apps → Special app access → Notification access (path varies) is the list to empty of strangers. A weather widget does not need to read your OTP banners.

Device-admin (and newer device-owner / work-profile hooks) were built for corporate wipe, lock, and policy. In the wrong package they make uninstall painful: the app demands you deactivate admin before you can remove it, while it keeps running. Ransomware-style lockers and aggressive "antivirus" scareware use this pattern. A personal game, wallpaper, or battery saver has no reason to be device admin. If you see that prompt, Refuse. If something already snuck in, deactivate admin in Security settings first, then uninstall — on your phone, following OEM screens, not a random YouTube "force remove" that asks you to sideload a second mystery tool. Draw over other apps / Appear on top / Display over other apps lets a window sit above whatever you are using. Combined with a stolen tap or with Accessibility, it is classic overlay phishing: you think you are typing into the real bank because you launched the real bank, but the fields you can see are the attacker's. Chat heads and a few accessibility aids have a legitimate overlay need. A newly installed "player" or "cleaner" does not. Special app access again: revoke overlay for anything that is not an app you can name a UI reason for.

These grants often arrive as a stack, not as one prompt. Module 1's banking-trojan lesson was the story; this is the parts list. Accessibility + overlay + SMS or notification listener is a complete account-takeover kit without a single kernel bug. You do not need to assemble that kit to recognize it. You need to refuse any one of those pieces when the job does not require it. One Deny can collapse the chain.

The defensive test is one sentence: would this app be unable to do the thing on the icon without this capability? Camera app → Camera. Maps you are navigating → Location while using. Password manager you chose → Autofill (and only that vendor). Phone app → Phone. Flashlight → Camera or a flashlight API, depending on OEM — not Contacts, not SMS, not Accessibility, not device admin. A QR scanner → Camera while using, not always-on, not your whole photo library unless you explicitly pick a file. When the store page or first-run screen asks for extras "to improve experience," read that as optional tracking or as a grab. Deny. Use the app without the feature. If it is genuinely broken without a matched permission, grant the minimum (approximate location, photos you pick, one-time camera) and leave the radioactive list untouched. You can always add a permission later from App info. You cannot un-send an OTP that already left the device.

Open Settings on a phone you own. Paths vary by Pixel, Samsung, Xiaomi, and others; look for Security & privacy, Privacy, or Apps → Special app access. You are listing who has Accessibility, notification access, device admin, and appear-on-top — not downloading samples, not enabling unknown sources to "compare a bad APK." Write what you find in a private notes file. No account passwords, no OTPs, no screenshots of other people's screens.

mkdir -p "$HOME/cyberlium-lab"
NOTES="$HOME/cyberlium-lab/perm-match-notes.txt"

{
  echo "date: $(date -Iseconds 2>/dev/null || date)"
  echo "ethics: own device Settings audit — no live APKs, no other people's phones"
  echo ""
  echo "=== SPECIAL APP ACCESS (write names you actually see) ==="
  echo "accessibility_services:"
  echo "  (keep genuine assistive tools YOU chose; uninstall strangers)"
  echo "notification_access:"
  echo "device_admin:"
  echo "appear_on_top / overlay:"
  echo ""
  echo "=== MATCH TEST (one line each, fictional or your apps — no secrets) ==="
  echo "flashlight_needs_sms: NO — job is torch, not OTP inbox"
  echo "maps_needs_location_while_using: YES — navigation is the job"
  echo "battery_saver_needs_accessibility: NO — classic malware-shaped ask"
  echo "password_manager_needs_autofill: YES if it is the vendor I already trust"
  echo ""
  echo "revoked_or_uninstalled:"
  echo "still_open: next lesson = privacy defaults (location, ads, lock screen)"
} > "$NOTES"

chmod 600 "$NOTES"

You now treat Android permissions as capability keys, not as compliments to an icon. Accessibility can see and tap; SMS and notification listeners can steal the second factor; device admin and overlay turn uninstall and the screen into attacker-controlled surfaces. The test is job-match: a flashlight does not need SMS. Next — Mobile Privacy Settings — you tighten location, ads, lock-screen notification content, and the permission manager on a phone you own so leftover grants shrink even when the app is "normal."