APK and app scanner: a full teardown of any Android app

Stage 1: SHA-256 against known samples

The first thing the scanner does is hash the entire file with SHA-256. This is a fixed-length fingerprint of every byte in the file. Change one byte and the fingerprint changes completely.

That fingerprint is checked against roughly 2,950 known sample hashes from the Echap stalkerware indicator set. If it matches, the scan is effectively over before it has started: the file is byte-for-byte identical to a sample that has already been analysed and attributed to a specific family. This is the highest confidence a verdict can have. The report will say Known stalkerware, name the family, give the danger code (for example GS-STK-AND-7685 for the mSpy family) and set confidence to Exact hash match.

Most files you scan will not match at this stage, and that is normal. Stalkerware vendors rebuild their apps often, and a rebuild with a different version string produces a new hash. A miss here means nothing on its own. The scanner carries on.

We also compute SHA-1 and MD5 for the Identity section, because other tools and online sandboxes often index by those, and you may want to cross-reference.

Stage 2: ZIP parse

Next the scanner reads the ZIP central directory and lists every entry. This sounds dull, but a few things are already visible at this stage:

The entry list is kept for the Code section of the report.

Stage 3: Decoding AndroidManifest.xml

The manifest is stored as Android binary XML ("AXML"). The scanner decodes it back into a readable tree, and this is where most of the real information comes from.

From the manifest the scanner extracts:

Identity. The package name (com.example.something), the version name and version code, and the minimum and target SDK levels. Package names matter enormously: the database contains 600+ package names tied to specific families, and stalkerware apps have a habit of choosing names that look like system components (com.android.core.monitor, android.helper.system, com.system.user, com.systemservice). A match on package name gives Package-name match confidence, one step below a certificate match, because package names can be copied by anyone.

A very low target SDK is also noted. Apps targeting old Android versions get older, looser permission behaviour, and some monitoring apps deliberately keep an old target to avoid newer restrictions on background location or SMS access.

Permissions. Every <uses-permission> line, sorted into risk tiers. The permission audit page explains each one in depth. Here, the scanner is interested in both single high-risk permissions and combinations. Reading SMS on its own might be a legitimate messaging app. Reading SMS plus call log plus fine location together is rule GS-R-030 and is what a monitoring app looks like.

Notification listener services (BIND_NOTIFICATION_LISTENER_SERVICE) get the same treatment. A notification listener sees the content of every notification, which on most phones means the content of every incoming message from every messaging app, without needing any SMS permission at all. ATT&CK T1517, Access Notifications.

• A receiver for android.intent.action.BOOT_COMPLETED, together with the RECEIVE_BOOT_COMPLETED permission, means the app starts itself every time the phone restarts. Normal for an alarm clock. Essential for anything that wants to monitor you without being reopened.
• A receiver protected by BIND_DEVICE_ADMIN with the android.app.action.DEVICE_ADMIN_ENABLED filter means the app is a device administrator. Device admin apps can be made very hard to uninstall (the uninstall button is greyed out until admin is revoked), can wipe the device, and can enforce lock settings. Rule GS-R-018, ATT&CK T1626.001.

Hidden launcher icon. The scanner looks at the app’s activities. If there is no activity with the MAIN action and LAUNCHER category, or if the launcher activity is an activity-alias that the app can disable programmatically, the app can exist on the phone with no icon in the app drawer. Rule GS-R-014, "Hides launcher icon", ATT&CK T1628.001. Legitimate apps almost never do this. Nearly every stalkerware app does.

Intent filters. The scanner lists any filter that catches outgoing calls (NEW_OUTGOING_CALL), incoming SMS (SMS_RECEIVED, with a high priority value so it sees the message before the default messaging app), or package install events (PACKAGE_ADDED, used to notice when the victim installs a security app).

Stage 4: Certificate extraction and signer matching

Every Android app must be signed, and the signing certificate cannot be changed without breaking updates. This makes the certificate one of the most reliable identifiers of who really built an app, regardless of what name or icon they gave it.

The scanner reads the certificate from META-INF/*.RSA (or .DSA/.EC) and, where present, from the APK Signature Scheme v2/v3 block. It computes the SHA-1 and SHA-256 fingerprints of the certificate and extracts the subject and issuer fields (the "CN=" and "O=" values the developer typed when they generated the key).

The fingerprints are then compared against 470+ signing certificates in the database. A certificate match gives Signing-certificate match confidence. This catches a huge amount that package-name matching misses: when a vendor renames their app from "SpyPhone" to "Battery Saver Pro" and changes the package name, they very often keep signing with the same key, because changing it would break updates for existing paying customers.

The scanner also notes:

• Self-signed debug certificates (CN=Android Debug), which appear in apps built from a developer machine rather than released properly.
• Certificates whose subject fields are empty, random-looking, or deliberately imitate Google (CN=Android, O=Google Inc. without the real Google key).
• Certificates with absurdly long or short validity windows, which are weak signals on their own but add up.

Stage 5: String extraction – domains, IPs, URLs

The scanner walks through every DEX file, the resource table, and anything in assets/ that looks like text or configuration, and pulls out strings that look like network destinations: fully qualified domain names, IPv4 addresses, full URLs, and a few things that look like API keys for push and analytics services.

Why strings? Because an app that sends your messages to a server has to know the server’s address, and that address is somewhere in the file. Obfuscation tools can scramble class names, but a domain has to be a domain at the moment it is used, and in most stalkerware it is simply sitting there as a plain string constant.

The extracted list is shown in full in the Network indicators section, with the obvious noise (Google, Android schema URLs, common libraries) grouped separately so the interesting addresses stand out.

Stage 6: C2 matching

Each extracted domain and IP is compared with 900+ known command-and-control domains and with the distribution and website domains of every family in the database. Command and control (C2) is the server a monitoring app reports to and takes instructions from: "upload the last hour of audio", "send the current GPS fix", "turn on the camera".

A match here gives C2-domain match confidence and names the family. To give a concrete example, the TheTruthSpy family (GS-STK-AND-1405, which also covers the old GuestSpy monitoring builds, package com.guest) uses dozens of subdomains following patterns like protocol-a###.thetruthspy.com and media-sync-a###.fonetracker.com; these are in the database, and an app containing any of them will be attributed to that family even if its package name and certificate are new.

The scanner also applies a few generic network rules with no family attribution: hard-coded raw IP addresses used as the primary endpoint (GS-R-041), domains using "dynamic DNS" style hosting, and endpoints whose path contains words like /upload, /sync, /keylog, /callrecord, /sms.

Stage 7: Native libraries and packers

Some monitoring apps ship native code to record calls, capture audio at low level, or simply to hide logic from DEX-level analysis. The scanner lists each .so file and architecture and extracts strings from the native binaries too, so a C2 domain hidden in native code is still found.

It also checks for signs of commercial or open-source packers and protectors. The usual pattern is a tiny stub DEX whose only job is to decrypt and load the real code from assets/ at runtime. The scanner looks for known stub class names, for high-entropy blobs in assets/, and for the DexClassLoader / InMemoryDexClassLoader calls that load code dynamically. Packing is not proof of anything; plenty of banking and game apps use it. But a tiny app with a device admin receiver, an accessibility service, no launcher icon, and a packed payload is a combination that has only one sensible explanation. Packing is reported as GS-R-050 ("Dynamically loads code at runtime") and feeds into the score.

Stage 8: Danger scoring and the verdict

Now the scanner has a list of findings, each tagged with a rule ID, a weight, and any family attribution. It produces three things:

Severity (0-100). A weighted sum of findings, capped at 100. Family-level matches set a floor (a certificate match to a stalkerware family will never score below the Dangerous band, whatever else is going on). Combinations count more than sums: GS-R-030 adds more than the three permissions it is built from would add separately.

Confidence. The strongest kind of evidence found, in a fixed order: Exact hash match, then Signing-certificate match, then Package-name match, then C2-domain match, then Heuristic. This is shown separately from severity on purpose. An app can be high severity and heuristic-only (it behaves like spyware but we cannot name it) or lower severity with exact-hash confidence (a known "watchware" parental app that is honest about what it does).

Verdict. One of five words: Clean, Low risk, Suspicious, Dangerous, Known stalkerware. "Known stalkerware" is reserved for family matches of hash, certificate or package name in the stalkerware (STK) class. Apps in the watchware (WCH) class, meaning visible monitoring and parental apps such as Life360 (GS-WCH-AND-7021), are given their own purple label and explained as what they are: software that monitors, but doesn’t hide. Whether that is OK depends entirely on whether you knew it was installed and agreed to it.

Every finding carries a danger code in the format GS-<CLASS>-<PLATFORM>-<NNNN>. The class tells you the kind of problem (STK, WCH, SPY, TRJ, ADW, PUA, CFG, DOC, CLN); the platform here is always AND; the number identifies the family or, for heuristic verdicts, the heuristic profile.