TEESimulator is a root-required Android security module (Magisk/KernelSU/APatch) that intercepts Android hardware-backed key attestation and keystore operation flows. It runs a privileged Kotlin daemon via app_process that harvests real device attestation parameters (verified boot key/hash, OS/vendor/boot patch levels, device identifiers, AVB vbmeta digest) using a throwaway hardware key, resolves per-app profiles from config.json, then ptrace-injects native interceptor libraries into the running keystore2 (Android 12+) or legacy keystore (Android 10/11) daemon. The interceptors PLT-hook AIBinder_transact (keystore2 path) or binder ioctl transactions (legacy path) and route targeted apps' key operations to an in-process Rust implementation of the AOSP KeyMint reference trusted application. Attestation certificates are either re-signed under a user-supplied keybox (patch mode) or fully minted in software (generation mode), with root-of-trust fields normalized to verified state so the resulting keys still pass Google hardware attestation checks. The architecture is a hybrid monolith: a Kotlin control daemon (app/), C/C++ interceptor libraries plus a ptrace injector executable (common/, keymint/, keystore/, injector/), a Rust static library exposing a C ABI for KeyMint operations and DER-level attestation re-signing (rust/teesim-km/), a native logd reader (logcat/), and a framework-free JavaScript SPA served by the daemon over a root-only Unix-socket HTTP API (module/webroot/). Control-plane messages use length-prefixed JSON frames authenticated by SO_PEERCRED. The daemon also reads/writes keystore2's SQLite database directly for key listing, deletion and re-rooting, maintains per-app key usage statistics, fetches Google's attestation certificate revocation list with disk cache to classify keyboxes, and can self-update from GitHub releases. The code is unusually well-crafted for a root module: a bounded hand-rolled JSON parser for -fno-exceptions native code, tokenized PII redaction (SHA-256 with per-install salt) shared between Kotlin and C++, RAII-wrapped ptrace primitives, a single shell-command choke point in the WebUI with POSIX quoting, and a schema-driven pure-JS validation layer with a node test suite. The trade-off is inherent fragility: Binder transaction ordinals, keystore2 DB schema, hidden framework APIs and BoringSSL symbol compatibility all require hand-maintained per-Android-release tables, and several components acknowledge legacy 10/11 edge cases. The project is actively maintained (recent commits, current root-rotation knowledge, CI builds) and dual-use in nature since it is explicitly designed to defeat hardware-backed attestation.
This repository implements the judge server component of the DMOJ online judge platform. It securely compiles and executes user-submitted code in over 50 programming languages, runs it against predefined test cases, and returns verdicts (AC, WA, TLE, MLE, RTE, etc.). The system is designed for programming contests and supports IO-based, interactive, and signature-graded problems, along with runtime data generators and custom output validators. Architecturally, the judge is a Python daemon that connects to a central site bridge via TCP/TLS. It uses a multiprocessing model where a main Judge process spawns JudgeWorker processes per submission. The core sandbox (cptbox) leverages ptrace on Linux/FreeBSD and seccomp on Linux to isolate untrusted code, with a syscall allowlist and filesystem jail. Language executors are implemented as pluggable subclasses of a base executor framework, each handling compilation, runtime flags, and security policies. Graders orchestrate the execution pipeline: they compile, run, check output, and report results. The system also includes a CLI for local judging and a test suite harness for offline validation. Key modules include the sandbox (dmoj/cptbox/), executors (dmoj/executors/), graders (dmoj/graders/), checkers (dmoj/checkers/), problem configuration (dmoj/problem.py), and network protocol (dmoj/packet.py). The codebase is well-structured with clean abstractions, extensive test fixtures, and CI/CD pipelines. It is not a data research project; it is a production-grade application used on dmoj.ca.