APKiD statically fingerprints how an Android APK or DEX was built, identifying compilers, packers, obfuscators and app-shielding products for malware analysts and authorized researchers.
| Tool | rednaga/APKiD — Android application identifier for packers, protectors, obfuscators and oddities, 'PEiD for Android' |
| Category | static analysis / YARA-based malware triage |
| Primary Use | Rapid triage of APK and DEX samples to identify the compiler (dx), packer, obfuscator or RASP SDK used during authorized malware analysis |
| Safe Use | Educational and documentary analysis for authorized professionals: triage samples in malware research labs, CSIRT workflows, and defensive app-store or enterprise vetting pipelines |
| Telemetry Note | Purely local static scanner — it contacts no external services, so defenders observe its use only as local process/file activity; its detections help blue teams cluster malicious samples by toolchain |
Every Android sample that lands in a triage queue carries a fingerprint of its birth: which compiler produced the classes.dex, whether a commercial packer wrapped the payload, and whether an obfuscator mangled the identifiers before shipping. rednaga/APKiD is the purpose-built tool for reading that fingerprint. The README pitches it bluntly as _PEiD_ for Android — a reference to the classic Windows packer identifier — and describes its job as telling you "how an APK was made" by identifying compilers, packers, obfuscators, and what the authors charmingly call "other weird stuff." With roughly 2,570 stars and the primary language listed as YARA, the project signals clearly where its detection muscle lives: in a curated, community-maintained rule set rather than in heuristics or emulation.
The architectural picture that emerges from the README is refreshingly simple. APKiD is a thin orchestration layer around YARA rules compiled with yara-python and a DEX-aware module, yara-python-dex, that lets YARA match patterns directly on DEX bytecode rather than treating it as an opaque blob. That choice matters for practitioners: it means the tool's knowledge base is inspectable and extensible. If you encounter a shielding product the rules don't recognize, the maintainers explicitly invite GitHub issues with your classification guess and the sample hash (MD5, SHA1, or SHA256), and pull requests for new rules are welcome provided you include a file hash so the rule can be validated. This is crowd-sourced detection engineering, and it is the single biggest reason the tool stays current in a market where new commercial protectors appear constantly.
Installation is the canonical one-liner: pip install apkid. For analysts who prefer containment, the README documents a Docker path — clone the repo, docker build . -t rednaga:apkid, then invoke docker/apkid.sh against a target — with the sample output showing the tool correctly attributing an example classes.dex to the dx compiler. That sample line, |-> compiler : dx, is the whole product in miniature: one artifact, one verdict, no noise. The usage block shows the current version at v2.1.2, accepting APK, DEX, or whole directories as positional input.
The CLI surface is deliberately small but well-tuned for batch triage. Scanning options include -t/--timeout for the YARA scan window, -r/--recursive for descending into subdirectories, --scan-depth for how far to unpack nested zips (a common trick in shielded apps is to nest archives), and --entry-max-scan-size to cap how large a zip entry may be before it's skipped — 0 meaning no limit. The --typing {magic,filename,none} flag controls how the tool decides which embedded files deserve scanning: by content magic, by filename, or indiscriminately. Output side, -j emits JSON and -o DIR writes per-file JSON results to a directory, which implies --json anyway — the expected integration point for feeding APKiD verdicts into a larger analysis pipeline or a MISP-style enrichment workflow.
What the tool detects deserves unpacking, because the README's linked talk titles map the detection taxonomy better than the sparse feature list does. The referenced presentations cover Android compiler fingerprinting (HITCON 2016), detecting pirated and malicious Android apps (RedNaga, 2016), fast identification of app-shielding products (NowSecure Connect 2019), and fast identification of mobile RASP SDKs (BlackHat USA Arsenal 2023). The repo's topic list reinforces this breadth: android-protection, appshielding, rasp, packers, obfuscation, antivirus, malware-detection. So in practice APKiD answers three distinct questions: who compiled this, who protected this, and is anything unusual hiding in the oddities bucket — the last category explicitly open-ended, with the maintainers welcoming rules for anti-disassembler, anti-VM, and other anti-analysis tricks.
Where this fits in an authorized workflow is straightforward: it sits at the very front of Android malware analysis. Before you waste hours fighting a decompiler, APKiD tells you whether you're up against a known packer and therefore whether you need a dedicated unpacking step, or whether the sample is a plain dx-built app you can decompile immediately. For CSIRT and enterprise defense teams, the same verdicts cluster samples by toolchain: a sudden burst of payloads sharing an obfuscator fingerprint is a campaign signal, not a coincidence. App-store abuse teams and anti-piracy researchers — an audience the README's own linked material addresses — get a fast way to spot repackaged apps whose protection layer doesn't match the original publisher's.
The internal engineering, as revealed by the "Hacking" section, is worth understanding before you extend the rules. Development installs follow the familiar git clone → python prep-release.py → pip install -e .[dev,test] pattern, where prep-release.py compiles the YARA rules into the package; any rule edit requires re-running it. The hard dependency chain is yara-python plus yara-python-dex, and the README carries a Windows-specific footnote pinning yara-python==3.11.0 and walking through building yara-python-dex from the MobSF fork via pip wheel — a hint that DEX-module support on Windows is the fragile edge of the dependency graph and that Linux or the Docker image is the low-friction path.
Licensing is a detail that professional users should not skip. The repo carries a dual-license scheme: a commercial license for closed-source integration and a GPL option for open-source use, with the terms split across LICENSE.COMMERCIAL and LICENSE.GPL. GitHub's metadata renders this as NOASSERTION, but the README is unambiguous that you must pick one. If you're embedding APKiD into a proprietary product or a commercial SAST/antimalware pipeline, the commercial path applies; for internal lab tooling under an open-source umbrella, GPL is the default. This is the same model used by several RedNaga projects and reflects a sustainable funding posture for detection research.
Operationally, the tool is quiet by design: it performs purely local static scanning and, per the README, reaches out to nothing. There is no telemetry, no sample upload, no cloud lookup — the privacy property that makes it default-safe for handling sensitive or customer-derived samples. The maintainer-facing release notes (./prep-release.py readme, python setup.py sdist bdist_wheel, twine upload) confirm the classic PyPI distribution model, and the .travis.yml CI reference indicates dev/test environments are reproducible if you want to contribute rules upstream.
The honest limitations: APKiD identifies protections, it does not remove them. A verdict like "packer: X" tells you what wall you're facing, not how to climb it, and an unrecognized sample returns silence — which is why the issue-driven rule submission loop matters. False negatives degrade gracefully into "unknown," and because rules match static artifacts, a determined author can shave fingerprints off a known protector. Within those bounds, APKiD remains the de facto first command in Android triage for analysts who need to know what they're dealing with before committing reverse-engineering effort, and its active rule community is what keeps it earning that slot.
Bottom line for the authorized practitioner: pip install apkid, point it at a directory of samples with -r -j, and let the JSON feed your triage tracker. Treat its verdicts as attribution-of-toolchain rather than attribution-of-actor, contribute rules back when you hit an unknown protector, and respect the dual license if it migrates from your lab into a product. For a tool whose entire premise is "tell me how this was built," it delivers exactly that, quickly and without ceremony.
rednaga/APKiD.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.