Mobile Trust Lab is a reproducible Android security research project that compares client-authoritative state with a constrained, tamper-evident local cache. It includes two variants of the same application, a deterministic static auditor, scoped Frida observation scripts, tests, and evidence-to-remediation reports.

Maintainer and contact

This repository is owned and maintained by TAKU-ZE.

Project inquiries and verification correspondence: takumoze@gmail.com

For reviewers

Start with these documents:

  1. Reviewer quickstart — reproduce the core result in about five minutes.
  2. Evidence matrix — map each claim to source, checks, evidence, and limitations.
  3. Validation status — see exactly what has and has not been executed.
  4. AI-assisted research workflow — understand how Claude supports the work and where human review remains authoritative.
  5. Architecture — follow trust boundaries and evidence flow across the repository.
  6. Testing guide — run the verification layers independently.
  7. Rule coverage — inspect positive controls and false-positive boundaries.
  8. Build artifacts — build APKs and verify deterministic checksum manifests.

The shortest verification path is:

git clone https://github.com/TAKU-ZE/mobile-trust-lab.git
cd mobile-trust-lab
python scripts/verify.py

Expected summary:

Scanner tests: PASS (36/36)
Vulnerable findings: 6
Hardened findings: 0
Sample reports: REPRODUCIBLE (4/4)
Documentation links: VALID (71/71)
Result: PASS

The first public verify-and-build evidence run passed all three Python jobs and the Android artifact job: workflow run #4. The run publishes both signed lab APKs with adjacent checksum manifests.

No third-party Python packages, Android device, or API key are required for this verification path.

Research question

Which Android client controls fail when balances, progression, entitlements, and one-time rewards are treated as authoritative local state, and which controls reduce that risk without overstating the protection provided by the client?

The project answers this with a controlled A/B implementation:

Control Vulnerable variant Hardened variant
Sensitive state Plain authoritative SharedPreferences values HMAC-protected local cache using Android Keystore
Reward replay Local boolean gate Integrity-protected local transition
Debugging Enabled Disabled
Backup Enabled Disabled
Cleartext traffic Allowed Disabled
Admin component Exported without permission Not exported

The hardened variant is a defense-in-depth demonstration. Production balances, entitlements, and replay decisions still require a trusted, server-authoritative service.

Implemented scope

  • Two buildable Android application variants with the same UI and workflow.
  • Six transparent static rules covering manifest configuration and client trust patterns.
  • JSON, Markdown, and HTML reports with evidence and remediation.
  • Unit and integration-style tests for vulnerable and hardened targets.
  • Independent positive and negative regression boundaries for every scanner rule.
  • Runtime observation scripts restricted to the two lab package names.
  • An offline APK build script that discovers tools from ANDROID_SDK_ROOT or ANDROID_HOME.
  • A zero-dependency server-authoritative reward and idempotency reference.
  • Deterministic APK packaging with SHA-256 and JSON evidence manifests.
  • GitHub Actions verification across Python versions plus signed APK artifact publishing.

Evidence summary

The vulnerable fixture produces six findings:

  • MT-001: debuggable application;
  • MT-002: application backup enabled;
  • MT-003: cleartext traffic allowed;
  • MT-004: unprotected exported component;
  • MT-005: sensitive client-authoritative state in SharedPreferences;
  • MT-006: replay-sensitive reward state enforced locally.

The hardened fixture produces zero findings under this six-rule scanner. That result is not a claim of complete application security. See the evidence matrix and validation status for coverage boundaries.

Repository layout

lab-app/             Android vulnerable and hardened variants
auditor/             Zero-dependency Python source scanner
fixtures/            Deterministic scan targets
frida/               Package-scoped runtime observation scripts
scripts/             Cross-platform reviewer verification
docs/                Methodology, evidence, limitations, and reviewer guidance
sample-reports/      Reproducible JSON, Markdown, and HTML results
reference_service/   Server-authoritative reward and idempotency reference
tests/               Scanner and real-variant tests

Project maturity

The repository treats reviewability as part of the implementation:

Optional APK build

The core reviewer verification does not require the Android SDK. To build both APKs, install a JDK and Android SDK, set either ANDROID_SDK_ROOT or ANDROID_HOME, then run:

./lab-app/build-apks.sh

Generated APKs, signing material, and local SDK configuration are excluded from Git.

Scope and responsible use

The repository is limited to purpose-built lab packages and owned or explicitly authorized environments. It contains no production targets, customer data, credentials, or third-party confidential material. The Frida scripts observe state transitions and refuse to attach outside the lab package names.

Further reading