How to Identify an Unknown Android Package Name

A package name appears in a support ticket. An MDM inventory flags something nobody recognises. A customer reads out a string from Settings after a call they now regret. In each case the starting evidence is the same: a reverse-DNS string such as com.system.service, and nothing else.

The string is attacker-controlled, so it proves nothing by itself. It is still enough to start from, and five checks will usually resolve the question without access to the device.

What a package name is

Android identifies every installed application by a package name, written in reverse-DNS form: com.example.myapp. It must be unique on a device and, for anything distributed through Google Play, unique across Play.

Three properties matter for identification:

• It is chosen by whoever built the application. There is no registration authority and no verification that the domain in the name belongs to the developer. com.bank.secure can be published by anyone who reaches Play or a sideload channel first.
• It is stable after installation. Unlike the application label and icon — which an application can change at runtime — the package name is fixed for the installed copy. That makes it a usable handle even when the display name is deliberately misleading.
• It is not an identity. Two applications with the same package name are not necessarily the same application. Establishing that they are is the whole point of check three below.

Check 1 — Is it actually a system package?

This is where most identification goes wrong, and it is where the common spyware naming pattern works.

Android's own components live under two prefixes:

• com.android.* — the Android Open Source Project components
• com.google.android.* — Google's applications and services

Anything else is not part of Android, regardless of what it sounds like. A package named com.system.service, com.android.system.core or com.systemui.service is not an Android system package. The name is constructed to survive exactly the glance most people give it: a user scrolling their application list sees the word "system" and moves on.

Genuine system packages that people mistake for suspicious include com.android.vending (the Play Store), com.google.android.gms (Play Services) and com.android.providers.media (the media store). These are expected on any device with Google services.

A name that imitates a system component and does not appear on Play is grounds to keep going, not to conclude.

Check 2 — Does it exist on Google Play?

Play exposes a package directly by identifier:

https://play.google.com/store/apps/details?id=<package-name>

Three outcomes:

The page loads and matches what the user described. Proceed to check three, which is the one that matters.

The page returns not found. The package is not distributed through Play, at least not in the region being queried. That is normal for enterprise applications, regional distribution and development builds. It is also normal for malware. The absence is a question, not an answer.

The page loads but describes something entirely different. The package name has been reused, or the user misread it. Confirm the string character by character before going further — rn and m are indistinguishable in many interfaces, and that substitution is used deliberately.

Check 3 — Does the installed copy match the Play copy?

This is the check that resolves the case, and it is the one that is usually skipped.

A package name on Play and the same package name on a device are only the same application if they carry the same signing certificate. The certificate is issued by the developer, not by Google, and it cannot be forged by a repackager — a modified build necessarily carries a different signature.

So the decisive question is not "does this package exist on Play" but "does the copy on this device have the certificate that Play distributes for it".

A mismatch means the installed application is a repackaged build carrying a legitimate application's name. For a banking application, that is a fraud incident rather than a malware curiosity, and it generally belongs with brand protection the same day, because the distribution channel is usually still live.

Droidwatch performs this comparison automatically on every Android analysis: package identity against Play, plus the full signing certificate chain — subject, issuer, validity window, signature scheme and fingerprints.

Check 4 — What does it request?

The manifest states what the application is able to do. For identification purposes the permission set is frequently conclusive on its own, because certain combinations have no legitimate application category.

The declarations worth reading first:

Any one of these has legitimate users. The first three together, on a package that is not on Play and imitates a system name, describe the capability set of an overlay attack. The full capability chain covers how these combine and what each one contributes.

Check 5 — Where did it come from?

Android records which application performed each installation, and that record answers a question the user frequently cannot.

With USB debugging enabled and the device connected:

adb shell pm list packages -3        # third-party packages only
adb shell pm list packages -i        # each package with its installer
adb shell pm path <package-name>     # the APK's path on the device
adb shell dumpsys package <package-name>

dumpsys package reports installerPackageName. The values to recognise:

• com.android.vending — installed from Google Play
• com.android.packageinstaller or com.google.android.packageinstaller — sideloaded, meaning a file opened directly rather than a store installation
• null — preinstalled, or installed by a method that recorded no installer
• Any other package — installed by another application, which is the dropper case

A sideloaded package that imitates a system name and requests accessibility is not an ambiguous finding.

adb shell pm path returns the APK location so the file can be pulled with adb pull and analysed directly, which is the only way to answer the question definitively.

What none of this establishes

The five checks establish identity and capability. They do not establish behaviour.

An application able to read SMS may never do so, or may do so only on instruction from its command-and-control server. Static analysis of the package shows what it can do; determining what it did requires either runtime instrumentation or device forensics.

For most identification questions that gap does not block the decision. A sideloaded package imitating a system name, absent from Play, requesting accessibility and overlay, is actionable without runtime confirmation.

Resolving it properly

The checks above can be performed by hand and are worth understanding, because they are what any tool is doing underneath. Running them as a single analysis is faster and produces something that can be attached to a ticket.

Submitting the APK returns the package identity and Play comparison, the full certificate chain, the permission and component analysis, MITRE ATT&CK Mobile mapping, extracted network indicators, and a risk score from 0 to 100 where higher is worse — with fixed verdict bands: 65 and above Malicious, 40 to 64 High Risk, 20 to 39 Suspicious, below 20 Benign. A 50 MB package completes in two to five minutes.

Three analyses a day are available without an account, five on a free account.

If the APK itself is not available — which is common when the report comes from a customer rather than from a device in hand — the public threat feed can be queried by hash without an account, and is published under CC BY 4.0. That only helps where the sample has been seen before, which is why the five checks above remain the fallback.

The reasoning that follows a positive identification is set out in the triage workflow, and the report walkthrough covers where each piece of evidence appears in the output.

Frequently asked questions

Is a package name unique? Unique on a device, and unique across Google Play. Not unique in the world: nothing prevents an application distributed outside Play from using a package name that belongs to a published application. That is what repackaging is.

Can an application change its package name? Not after installation. The label and icon can change at runtime; the package name cannot. This makes it the reliable handle when the display name is misleading.

Is a package absent from Google Play necessarily malicious? No. Enterprise distribution, regional availability, beta channels and internal tooling all produce packages that are not on Play. Absence raises the question that checks three, four and five answer.

What does com.system.service mean? Nothing in itself — but it is not an Android system package. Android components use com.android.* and com.google.android.*. A name under com.system.* was chosen by a developer, and choosing a name that reads as a system component is a decision worth examining.

What should be done with the APK once it is recovered? Treat it as live malware: analyse it in an isolated environment, record the SHA-256 before anything else, and do not redistribute the binary. Hashes and indicators are shared; samples are not.

To identify a package from its APK, submit it for analysis. No payment method required.