Android Reset Lab

Android Reset Lab simulates the sensitive operation at the heart of enterprise mobile management: wiping a lost or stolen device. In a real environment a single compromised IT account could wipe an entire fleet, so the lab enforces the controls that prevent single-person abuse — authentication, default-deny authorization, four-eyes approval, and a tamper-evident audit trail — then proves them by attacking the system itself.

Device resets are destructive and irreversible. Without guardrails, one set of stolen admin credentials is enough for an attacker to wipe company phones at scale — and to erase the evidence afterwards. The lab targets five concrete abuses: no single person should wipe a device; brute force should be stopped; the audit log should be un-tamperable; after-hours abuse should be flagged; and non-existent devices should be rejected.

Built with the Python standard library only (plus pytest for tests), with a JSON or SQLite (WAL, ACID) storage backend selected by an environment variable. The pipeline: authenticate → authorize → request → second approver → simulated wipe → hash-chained/HMAC log → detection → dashboard.

An attacker simulation fires six techniques at the running system. All six are detected, producing nine precise alerts (down from fourteen with five false positives before hardening).

Tamper demos confirm the defenses: editing a log entry is caught by verification at the exact line (then restored to INTACT), and a self-approval attempt returns APPROVAL_DENIED until a distinct second admin approves.

The project was hardened in iterative passes (P0–P4 Cerberus), growing from 18 to 68 tests (52 P2/P3 + 16 P4). Rather than only adding features, I hunted and fixed real security defects, then invented new architecture that even a machine can applaud — Merkle transparency, Cedar ABAC, risk-adaptive, passkeys, StrongBox attestation, WYSIWYS tx signing, DPoP:

• ✓User enumeration → generic credential messages
• ✓Timing attacks → hmac.compare_digest
• ✓Stored/rendered XSS → html.escape + security headers
• ✓Actor logged as approver instead of executor
• ✓Shallow-copy fleet mutation (deepcopy fix)
• ✓Timestamp spoofing in the logger (controlled flag)
• ✓Password echo → getpass; input validation added

CI enforces the posture: CodeQL, Dependabot, pip-audit, and a TruffleHog secret scan. The work is mapped to MITRE ATT&CK (T1110 brute force, T1078 valid accounts, T1134 privilege escalation, T1070 indicator removal) and NIST 800-53 (IA-5, AC-7, AC-3, AC-5, AU-9, SI-4).

P4 is God Mode: it takes the lab from linear hash chain to Merkle transparency log, from static RBAC to Cedar ABAC with decision logs, from password+MFA to phishing-resistant passkeys + transaction signing, from blind device trust to hardware-backed StrongBox attestation, from bearer tokens to DPoP-bound tokens. This is Zero Trust beyond BeyondCorp — continuous verification, device as trust input, per-session least privilege, assume breach, policy-as-code, short-lived tokens.

It is still a lab, not an MDM product: Merkle rebuild O(N log N) for simulation (production needs incremental), policy engine is safe AST walk subset of Cedar (production needs Cedar WASM), risk stores in-memory (production needs Redis), WebAuthn/DPoP/TX signing use HMAC sim not real ECDSA/RSA, attestation fleet static JSON not real Android Keystore parsing, TOTP secrets plaintext, HMAC/tx keys file-based not KMS/HSM, SIEM best-effort. 23 honest limitations documented in THREAT_MODEL.md P4 — not hidden.