Rooting Risks

On stock Android, each app runs as its own Linux user. App A cannot read App B's private files. Permissions (lesson 1) are extra capabilities on top of that isolation. Root is user ID 0: the account that can change ownership, remount partitions, inject into other processes, and install packages as system. That is powerful for a researcher on a spare device with no bank, no authenticator, and no photos they cannot lose. It is a blast-radius multiplier on a daily driver. Malware that obtains root — because you granted a "booster" su access, because a malicious module ran, because you were already rooted and tapped Allow on a Superuser prompt — is not limited to the grants you matched to a job. It can attempt to read other sandboxes, capture more than notification banners, and survive uninstall of the visible icon. You do not need a catalog of root exploits to understand the defense: do not put uid 0 on the phone that holds your life. This course will not list those exploits or how to chain them.

A Superuser/allow prompt on a rooted phone is the new "Accessibility tutorial." Habit says tap Allow so the screen goes away. Habit is how the sandbox dies. Stock phones never show that prompt because nothing is offering uid 0. That absence is a feature. Do not install a su manager "just to see the UI." Do not practice granting root to a fictional package. The lab in the next lesson uses paper profiles, not privileged shells.

A bootloader lock is a vendor control: the firmware expects a signed OS. Unlocking (a vendor developer option people turn on before custom software) typically wipes the device and turns off verified boot's full guarantee that the system partition is still the vendor's. You should treat an unexpected "unlocked" state as an incident, not as a flex. This paragraph is not a tutorial. We will not name fastboot sequences, OEM unlock toggles as a recipe, or how to relock after a patchwork ROM. Why defenders care: official monthly/quarterly security patches ride the vendor's signed images. Custom setups often lag, skip, or break those updates. Topic 1's patch-management lesson still applies — unpatched kernels and drivers are a larger window. Warranty and OEM support may refuse an unlocked device. None of that is a dare to unlock "then relock later." Relocking a non-stock image can brick. The beginner recommendation is: leave it locked, take OEM updates, do not follow a YouTube "boost RAM" unlock video.

If you buy a used phone, check developer status and whether the seller brags about "unlocked for ROMs." A daily driver for banking should be a device whose boot state you understand and whose OS is vendor-signed. If you cannot verify that, treat the device as lower trust: not the authenticator, not the only bank app, until you know it is stock. Checking Settings and the vendor's own about/boot screens on a phone you own is in scope. Running exploit tools is not.

Many banking, payments, and DRM apps call Google Play Integrity (historically SafetyNet) or OEM equivalents. Those APIs attest, roughly: is this a genuine Android device running an unmodified, certified software stack? Root, unlocked bootloaders, custom ROMs, and some Magisk-style setups fail that attestation. The app then refuses to open, or it limits features. That is not the bank being superstitious. It is the bank declining to run high-value crypto on a device whose sandbox they no longer trust. "Hide root," "deny list," "spoof attestation" tutorials exist to make those apps launch anyway. This course will not teach them. They are dual-use: hobbyists use them to keep a ROM; fraudsters use them to run banking malware on tampered devices. If a bank app refuses to run, the defensive answer is return to stock and locked — or use a non-rooted device for money — not a hide module. Do not attack the attestation API. Do not "test" a bank by feeding it a spoof.

Work profiles and corporate MDM may also refuse rooted or integrity-failed devices. That is the employer protecting their data, the same least-privilege idea as device admin in reverse: they will not put mail on a phone that has uid 0. Circumventing MDM is out of scope and often a policy violation. Use the device they issued as issued, or use a personal unrooted phone for personal accounts.

A custom ROM is a replacement OS image. Some are maintained by careful communities; some are abandoned; some are malicious rebuilds. Evaluating signing, update cadence, sepolicy, and verified boot for a ROM is specialist work. It is not Module 2 of a beginner Android-hardening path. Mentioning ROMs here is so you do not confuse "I flashed a privacy ROM" with "I completed this lesson." Those can even conflict: a ROM that lags patches or breaks Integrity can be worse for a bank user than Pixel/Samsung stock with defaults tightened from lessons 1–3. Researchers and enthusiasts who still want that power use a spare device that does not hold the only copy of photos, does not hold banking, and does not hold the only 2FA. Isolation is the control: high-value accounts live on a locked daily driver. Experiment lives on junk hardware. Never root because an ad promised more RAM. Never root the only phone. Never follow a "hide Magisk for GPay" guide as homework for this course.

On a phone you own, note what you can see without toggling developer unlock: OS version and security patch date, whether you personally unlocked anything, whether bank apps you already use open normally (do not probe Integrity APIs with extra tools). Write "stock / unknown / I already tampered" honestly. If you already rooted years ago, this lesson's advice is still: move money and 2FA off that device if you can, take patches if you still can, do not add hide modules as a "fix." We still give no commands to root, unroot, or spoof.

mkdir -p "$HOME/cyberlium-lab"
NOTES="$HOME/cyberlium-lab/root-risk-notes.txt"

{
  echo "date: $(date -Iseconds 2>/dev/null || date)"
  echo "ethics: no rooting steps, no Magisk hide, no Integrity spoof, no exploits"
  echo ""
  echo "=== WHAT ROOT WOULD CHANGE (write in your words) ==="
  echo "uid0_means:"
  echo "sandbox_cost:"
  echo "malware_with_root_is_worse_because:"
  echo ""
  echo "=== MY DEVICE (Settings / About — do not toggle OEM unlock) ==="
  echo "security_patch_date:"
  echo "bootloader_state_if_shown: locked / unlocked / I do not know"
  echo "bank_apps_open_normally: yes / no / I do not use them here"
  echo "this_is_daily_driver_with_money_or_2fa: yes/no"
  echo ""
  echo "recommendation_I_will_follow:"
  echo "  stock + locked for money/messaging; spare device only if I tinker"
  echo "custom_roms: advanced topic — not this course's daily-driver advice"
} > "$NOTES"

chmod 600 "$NOTES"

You now treat root as uid 0, not as a free performance pack. The sandbox, verified boot, and Play Integrity exist so banking and messaging can assume isolation; unlocking and hiding fight those assumptions. Custom ROMs stay advanced and optional on spare hardware. This course's daily-driver advice remains stock plus locked. Next — Lab — APK Permission Analyzer — you score fictional permission profiles on paper into a locked notes file. You never download real APKs for that lab.