* android.permission.INTERNET
* android.permission.FOREGROUND_SERVICE
* android.permission.RECEIVE_BOOT_COMPLETED
* android.permission.WAKE_LOCK
The rest are fishy, but not really anything that facilitates a virus.
* android.permission.QUERY_ALL_PACKAGES - allows you to enumerate what apps are installed
* android.permission.SYSTEM_ALERT_WINDOW - google says it's used for overlays. for a TOTP app this seems plausible for stuff like showing the code while you're entering it into the app that's requesting it
* android.permission.REQUEST_INSTALL_PACKAGES - I'm not even sure what this permission does. You can install an apk from chrome/firefox, which doesn't have this permission.
* android.permission.DISABLE_KEYGUARD - disables lockscreen. unless the attacker also has physical access, this is pointless.
I thought they just ask the OS to open the file, and when it happens to be a .apk file, Android brings up the package installer. Is that not how they do it?
The permission model is messy but made much worse by the volume of SDK code that is actually in most apps today. SDKs ship as big blobs with their own manifests and if you build in the SDK then you are collecting their permissions even if you aren't using the code that needs it. And given that virtually zero consumers choose apps based on permissions, there is little incentive to pare down the list to the minimum needed.
android.permission.RECEIVE_BOOT_COMPLETED is really the only thing suspicious in that list since this is used for a few more old school malicious behaviors. Complaining about android.permission.INTERNET is frankly hilarious since that permission no longer does anything (every app has access to the internet).
This is incorrect. If an app doesn't specify this permission in its manifest, it cannot access the internet.
Apps could always send content over the internet by sending an intent to a browser with relevant GET parameters to whatever server is consuming the data.
«To perform network operations in your application, your manifest must include the following permissions: ... .INTERNET and ... .ACCESS_NETWORK_STATE»
Though yes, applications (with particular regard to those that did not open network sockets internally) could use intents to have other applications perform network operations.
The true solution really is app review in the case of mobile apps. Google has the power and money, they just don't care.
Most of the commercial industry is, but don't forget about ClamAV[1] and other open-source projects.
I wasn't attempting to discuss its quality but oppose slapping "scam" label on every AV there is.
Also if there is any way to access even the slightest NSFW content and the app is not Chrome then forget about getting it listed.
it is trivially easy to evade scanning
-obfuscation
-renaming
-a long web of external obfuscated files
-a blank or unregistered domain which is activated and calls a script as soon as it goes live (this is the most effective way)