Forcefully revoking any used permissions by apps on Android by (hot reloading firmware)?

Question

There is a recent malware called MalLocker that hijacks and occupies the full screen size by using SYSTEM_ALERT_WINDOW permission. It poses as ransomware by looking as such but doesn't encrypt files.

"The notification was intended to be used for system alerts or errors, but Android threats misused it to force the attacker-controlled UI to fully occupy the screen, blocking access to the device. Attackers create this scenario to persuade users to pay the ransom so they can gain back access to the device," - Microsoft

• Is there a way to forcefully withdraw any ongoing permissions used by Android apps (and preserving current state of the device)?

I think that the adb command can be useful here, but it is likely that debugging mode needs to be enabled on the android device, which requires the device to be in developer mode.

To troubleshoot:

• How can debugging mode be enabled without expressly enabling it in the GUI?
• Would it be useful to connect the infected device to a terminal while being in debugging mode, or can't a android device infect a PC this way up?
• If adb can be used, and the permission in context is revoked then how will this affect the unwanted overlay screen? Will the app just break or will it stay since it used the permission already?

_{Note: my last question is very practical, for this reason I just want to now how this affects running apps in general.}

Answer 1

User authorised permissions can be revoked from device settings. SYSTEM_ALERT_WINDOW is shown as Draw over other apps in device settings which is known for infamous chat head bubble in facebook messenger. Because of its potential abuse by malvertising apps,

Google started restricting the areas in which overlays can draw back in Android Oreo, and they’ve completely removed access to the API for Android Q (Go Edition.) The biggest problem with SYSTEM_ALERT_WINDOW is that, despite the fact that users are supposed to manually grant the permission through a special permission management screen, the Google Play Store automatically grants access to the permission upon installation. In Android Q, access to the SYSTEM_ALERT_WINDOW permission is transient: side-loaded apps only have access to the permission for 30 seconds and apps installed via Google Play have access to the permission until a device reboot.

But in a future Android release, SYSTEM_ALERT_WINDOW will be fully deprecated, and all Android apps using it will have to transition over to the new Bubbles API introduced in Android Q. [1]

MalLocker is exploiting this design problem that prevents user to reach device settings to uninstall the malware or revoke its permission. No other permissions can block user from exiting/switching/uninstalling/force stopping a malicious app. adb is only available from developer settings. However, some OEMs allow adb from recovery mode. Once a permission is revoked, either app crashes for unhandled exception or reprompt user to allow permission again.

An infected android device can infect other connected devices but that largely depends on the type of intrusion. A malware with root access on android device can change the device identity. It can show PC that it is a LAN device instead of MTP or it's a keyboard. It's no different than badUSB attack once the malware controls firmware of the device. Whereas a malvertising app with no exploitative features is harmless. Every app runs inside of ART sandbox except adb daemon (adbd). Theoretically, a vulnerability in adbd and adb sdk can be used by unprivileged apps to deliver payload in PC but this setup will require chain of high severity vulnerabilities to work.

---

[1] Bubbles in Android Q will fully replace the overlay API in a future Android version