[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-83183":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":14,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":23,"hasPages":21,"topics":24,"createdAt":10,"pushedAt":10,"updatedAt":30,"readmeContent":31,"aiSummary":32,"trendingCount":16,"starSnapshotCount":16,"syncStatus":33,"lastSyncTime":34,"discoverSource":35},83183,"TEESimulator","JingMatrix\u002FTEESimulator","JingMatrix","Software simulation for Android hardware-backed key pairs with key attestation","",null,"Kotlin",1820,193,22,12,0,4,30,19.86,"GNU General Public License v3.0",false,"main",true,[25,26,27,28,29],"android","hardware-simulation","playintegrity","tee","trickystore","2026-06-12 02:04:32","# TEESimulator – A Full TEE Emulation Framework\n\n**TEESimulator** is a system module designed to create a complete, software-based simulation of a hardware-backed Trusted Execution Environment ([TEE](https:\u002F\u002Fsource.android.com\u002Fdocs\u002Fsecurity\u002Ffeatures\u002Ftrusty)) for [Key Attestation](https:\u002F\u002Fdeveloper.android.com\u002Fprivacy-and-security\u002Fsecurity-key-attestation).\n\nThe project's goal is to move beyond simple certificate patching and build a robust framework that can create and manage virtual, self-consistent cryptographic keys.\n\n## ✨ Core Principles\n\n*   **Bypass Hardware-Backed Attestation:** The primary goal of this project is to defeat Key Attestation, a security mechanism that allows apps to verify that they are running on a secure, unmodified device. This module provides the tools to bypass these checks on rooted or modified devices.\n*   **Stateful Emulation:** Instead of patching responses from the real TEE, the ultimate goal is to create and manage virtual keys entirely in a simulated software environment. Any request concerning a virtual key will be handled by the simulator, ensuring perfect consistency without ever touching the real hardware.\n*   **Architectural Interception:** By hooking low-level Binder IPC calls to the Keystore, the framework can transparently redirect requests for virtual keys to the software-based simulator, while allowing requests for real keys to pass through to the hardware TEE.\n*   **100% FOSS:** Licensed under GPLv3, ensuring it stays free, auditable, and compliant with open-source laws.\n\n## 📱 Requirements\n- Android 10 or above\n\n## 📦 Installation & Configuration\n\n1.  Flash this module via (Magisk \u002F KernelSU \u002F APatch) and reboot. It will replace [TrickyStore](https:\u002F\u002Fgithub.com\u002F5ec1cff\u002FTrickyStore), [TrickyStoreOSS](https:\u002F\u002Fgithub.com\u002Fbeakthoven\u002FTrickyStoreOSS) and their forks.\n2.  (Optional) Place a hardware-backed `keybox.xml` at `\u002Fdata\u002Fadb\u002Ftricky_store\u002Fkeybox.xml`. This provides the cryptographic \"root of trust\" for the simulator.\n3.  (Optional) Customize target packages in `\u002Fdata\u002Fadb\u002Ftricky_store\u002Ftarget.txt`.\n4.  (Optional) Customize the simulated security patch level in `\u002Fdata\u002Fadb\u002Ftricky_store\u002Fsecurity_patch.txt`.\n5.  Enjoy!\n\n**All configuration files are monitored and will take effect immediately upon saving.**\n\n### The `keybox.xml` Root of Trust\n\nThis file provides the master cryptographic identity for the simulator. It contains a private key and a valid, hardware-backed certificate chain from a real device. The simulator uses this to sign the virtual certificates it generates, making them appear legitimate to verifiers.\n\n```xml\n\u003C?xml version=\"1.0\"?>\n\u003CAndroidAttestation>\n    \u003CKeybox DeviceID=\"...\">\n        \u003CKey algorithm=\"ecdsa|rsa\">\n            \u003CPrivateKey format=\"pem\">...\u003C\u002FPrivateKey>\n            \u003CCertificateChain>...\u003C\u002FCertificateChain>\n        \u003C\u002FKey>\n    \u003C\u002FKeybox>\n\u003C\u002FAndroidAttestation>\n```\n\n### Mode and Keybox Configuration (`target.txt`)\n\nTEESimulator currently operates in two primary modes as it transitions towards full emulation.\nYou can control the simulation mode and the specific keybox.xml file used on a per-package basis.\n\n#### Mode Suffixes\n\n*   **`!` → Force Generation Mode:** Creates a complete, software-based virtual key. This is the foundation of the full TEE simulation.\n*   **`?` → Force Leaf Hacking Mode:** A legacy mode where a real TEE key is generated, but its attestation certificate is intercepted and modified.\n*   **No symbol → Automatic Mode:** The module selects the most appropriate mode for the device.\n\n#### Multi-Keybox Configuration\n\nYou can specify different keybox files for different groups of applications. This is done by adding a line with the filename in square brackets (e.g., [demo_keybox.xml]).\n\nAll applications listed after this line will use the specified keybox file, until a new keybox is declared. Applications listed before any custom keybox declaration will use the default `keybox.xml`.\n\nFor example:\n```\n# These two apps will use the default \u002Fdata\u002Fadb\u002Ftricky_store\u002Fkeybox.xml\ncom.google.android.gms!\nio.github.vvb2060.keyattestation?\n\n# Switch to a different keybox for the following apps.\n# The file must be located at \u002Fdata\u002Fadb\u002Ftricky_store\u002Faosp_keybox.xml\n[aosp_keybox.xml]\ncom.google.android.gsf\n\n# Switch again to another keybox.\n# The file must be located at \u002Fdata\u002Fadb\u002Ftricky_store\u002Fdemo_keybox.xml\n[demo_keybox.xml]\norg.matrix.demo\n```\n\n### Security Patch Level (`security_patch.txt`)\n\nThis file allows you to configure the `osPatchLevel`, `vendorPatchLevel`, and `bootPatchLevel` that the simulator will report in its patched or forged attestation certificates.\n\n**Note:** This only affects the Key Attestation data generated by the simulator. It does not change the actual system properties of your device.\n\n#### Global and Per-Package Configuration\n\nYou can set a global patch level that applies to all applications, and you can also override these settings for specific packages. The syntax is hierarchical:\n\n*   Settings defined at the top of the file, before any `[package.name]` line, are **global** and serve as the default for all apps.\n*   To create a specific configuration for an application, add its package name in square brackets (e.g., `[com.google.android.gms]`). All settings following this line will apply *only* to that package until a new package context is declared.\n\n#### Configuration Keys and Values\n\nYou can specify the patch level for the following components using a `key=value` format:\n\n*   `system`: The main OS patch level.\n*   `vendor`: The vendor patch level.\n*   `boot`: The boot\u002Fkernel patch level.\n*   `all`: A convenient shorthand to set the same date for `system`, `vendor`, and `boot` simultaneously. Any individual key can still be used to override the value set by `all`.\n\nDates should be provided in `YYYY-MM-DD` format (e.g., `2025-11-05`).\n\n#### Special Keywords\n\nIn addition to static dates, several special keywords provide advanced, dynamic control:\n\n*   **`today`**: Dynamically uses the current date every time an attestation is generated. This ensures the device always appears up-to-date without needing manual edits.\n\n*   **Date Templates**: You can create semi-dynamic dates using `YYYY`, `MM`, and `DD` as placeholders for the current year, month, and day. For example, `YYYY-MM-05` will always resolve to the 5th of the current month and year.\n\n*   **`no`**: This keyword instructs the simulator to **completely omit** the corresponding patch level tag from the generated attestation.\n\n*   **`device_default`**: This keyword forces the simulator to fall back and use the device's **real hardware value** for that specific patch level. This is essential for creating exceptions to a global override or an `all` rule.\n\n#### Example Configuration\n\nThis example demonstrates how to combine global settings, per-package overrides, and special keywords for fine-grained control.\n\n```\n# --- Global Configuration ---\n# This is the default for all apps unless specified otherwise.\n# - Forge a recent system patch level, the 5th of the current month (a common patch date).\n# - Use the device's real vendor patch level.\n# - Do not report a boot patch level at all.\nsystem=YYYY-MM-05\nvendor=device_default\nboot=no\n\n# --- Per-Package Override for Google Play Services ---\n# This app will report an older, specific date for its system patch.\n# It will inherit the global settings for vendor (device_default) and boot (no).\n[com.google.android.gms]\nsystem=2024-10-01\n\n# --- Per-Package Override for a Demo App ---\n# This app gets a completely custom configuration.\n[org.matrix.demo]\n# Set a base date for all patch levels...\nall=2025-09-15\n# ...but make an exception: use the real boot patch level instead of the one from 'all'.\nboot=device_default\n```\n","TEESimulator 是一个用于Android硬件支持密钥对的软件模拟工具，特别针对密钥认证进行了仿真。其核心功能包括绕过硬件支持的认证、状态化仿真以及架构拦截，能够在不接触真实硬件的情况下创建和管理虚拟密钥，并通过挂钩低级Binder IPC调用来透明地重定向请求。此项目完全基于开源软件开发，遵循GPLv3许可证。适用于需要在已root或修改过的设备上进行应用开发与测试的场景，尤其当这些应用依赖于安全环境下的密钥验证时。最低要求为Android 10系统版本。",2,"2026-06-11 04:10:22","top_language"]