Android Clone and Fake-app Analyser
An offline Python analyser that safely compares an authorised Android package with a candidate package using identity, signing, capability, resource, archive, and bounded static-code evidence.
Project definition
Problem statement
A copied or repackaged Android package can resemble an authorised application while changing its signer, permissions, exported components, embedded hosts, or static resources. Legitimate updates and companion applications can also look similar.
This project compares several static evidence sources together and explains why a package needs review without declaring that it is malicious.
Project objectives
- Inspect an APK as a bounded ZIP archive without extracting, installing, or executing it.
- Use Android SDK tools when available to collect manifest and cryptographic signing evidence.
- Compare package names, labels, signer fingerprints, permissions, components, icons, hosts, archive members, libraries, and bounded DEX tokens.
- Produce stable finding codes, review priorities, evidence values, and explicit limitations.
- Evaluate the implemented rules on four legitimate controls and eight review-required controlled pairs.
- Reproduce every fixture, result, figure, and dashboard output from the command line.
Project structure
Project components
Archive safety layer
Rejects oversized, over-expanded, high-ratio, traversal, and excessive-entry archives before bounded reads.
Manifest adapter
Uses apkanalyzer for ordinary binary manifests and a marked fixture path for the controlled corpus.
Signing adapter
Uses apksigner to retain verification state, schemes, certificate fingerprints, and evidence source.
Static evidence extractor
Collects identity, capability, exposure, icon, host, library, archive-member, and bounded token evidence.
Comparison engine
Calculates explicit similarities and produces contextual findings without converting the score into a verdict.
Experiment suite
Builds 12 deterministic package pairs and retains reports, metrics, figures, CSV results, and an offline dashboard.
Methodology
Project workflow
- 01Choose authorised packages
The student selects a known reference APK and a candidate that they are permitted to inspect.
- 02Inspect safely
Both archives pass bounded structural checks before static evidence is read.
- 03Acquire platform evidence
Android SDK adapters collect manifest and signer results where the official tools are installed.
- 04Compare evidence
The analyser calculates similarities and interprets them together with signing, permission, component, and host changes.
- 05Review findings
The JSON result retains every code, priority, explanation, source value, and analysis boundary.
- 06Reproduce the experiment
One command rebuilds all 24 fixtures and the complete 12-pair evidence set.
Demonstration scenario
The student compares a controlled authorised reference with a same-package candidate signed by a different certificate. The packages are highly similar, but the signer evidence raises a critical finding. A legitimate signed update also scores highly and remains a no-review case, demonstrating why the similarity score cannot act as the verdict.
Engineering
Tools and method
- Core package
- Typed Python modules for safety, manifests, signing, media, inspection, comparison, fixtures, experiments, and commands.
- Bounded evidence model
- File size, entry count, expanded size, compression ratio, single-entry size, and read-length limits are enforced centrally.
- Transparent comparison
- Label edit similarity, set Jaccard scores, perceptual icon distance, weighted aggregation, and rule findings remain individually visible.
- Quality controls
- 50 tests, 95.69 percent coverage, Ruff checks, dependency audit, delivery validator, non-root container, and read-only runtime checks.
Testing
Evaluation
Evaluation measures
- True positives, true negatives, false positives, and false negatives across 12 controlled pairs
- Precision, recall, and accuracy at the declared review threshold
- Composite similarity and review-priority distribution by scenario
- Finding activation and evidence breadth by scenario
- Archive-safety rejection controls
- Automated test count, statement coverage, dependency audit, and container identity
Project boundaries
- Only packages owned by the student or explicitly authorised for inspection should be analysed.
- The analyser never installs or executes APK, DEX, or native code and never contacts embedded hosts.
- The prepared corpus is synthetic. Its perfect classification shows internal consistency only and is not field accuracy.
- Static similarity cannot prove authorship, malicious intent, legal infringement, or user harm.
- Ordinary binary APKs require installed Android SDK tools for complete manifest and signing evidence.
- No information is collected.
Included
- 01Complete Python source code and command-line tools
- 02Bounded APK archive inspection without extraction or execution
- 03Manifest, signer, permission, component, icon, host, file, and DEX-token comparison
- 0424 controlled APK fixtures and 12 detailed JSON evidence reports
- 05Nine labelled result figures and an offline results dashboard
- 0650 automated tests with 95.69 percent statement coverage
- 0781-page project report in PDF and editable Word formats
- 0821-page setup and usage guide in PDF and editable Word formats
- 0945 annotated references
Project record
No information is collected on this page.
- Permanent project ID
- GP-CY-0ABQ3M8
- Catalogued
- 21 Aug 2026
- Completed
- 25 Aug 2026
- Verified
- 25 Aug 2026
- Demonstration
- Included in repository
Handover
After purchase
- 01Payment is confirmed
The project is marked unavailable and cannot be purchased again.
- 02Repository access is granted
The buyer's submitted GitHub account receives access to the private repository.
- 03The purchase record is delivered
The certification sheet is prepared from the reviewed buyer details and sent privately by email.