App-spezifische Richtlinien
Globaler oder gezielter Scope, Paketregeln, benannte Profile sowie Keybox-, Template- und Privacy-Auswahl pro App.
Docs ↗OPEN-SOURCE
Eine richtlinienbasierte Kompatibilitätsschicht für Android Keystore und Attestation.
CleveresTricky lässt private Schlüsseloperationen auf dem echten Android-KeyMint- oder StrongBox-Pfad und ergänzt kontrollierte Zertifikatskompatibilität, App-Richtlinien, Identitätskontrollen, RKP-Schutz, DRM-Datenschutz und Diagnose in einer nativen Manager-WebUI.
Es wird kein nutzbarer Keybox-Inhalt und kein privater Attestation-Schlüssel mitgeliefert. Verwende nur Material, das dir gehört oder für dessen Test du ausdrücklich autorisiert bist.
01 / FUNKTIONEN
Kompatibilität, ohne Androids Schlüssel-Engine zu ersetzen.
Das Projekt legt Richtlinien und Zertifikatskompatibilität um den echten Android-Keystore-Pfad, statt jede gezielte Schlüsseloperation in eine separate Software-KeyMint-Implementierung umzuleiten.
Echte KeyMint-/StrongBox-Operationen
Signieren, Verschlüsseln, Key Agreement und unterstützte Schlüsselerzeugung bleiben beim Geräte-KeyMint oder StrongBox; CleveresTricky steuert die kompatible Zertifikatsantwort darum herum.
Docs ↗Granulare Identität
Build-, Attestation-, Telephony-, Region- und Security-Patch-Darstellung können unabhängig voneinander gesteuert werden.
Docs ↗Sicherheitsmodell
Root-eigener Zustand, begrenzte Eingaben, Symlink-Ablehnung, atomare Schreibvorgänge, Payload-Integrität und Tamper-Lockdown.
Docs ↗Native Manager-WebUI
Läuft über die native KernelSU/APatch-Bridge ohne lokalen TCP-Dienst; mobile Bedienung, Logs und Validierung sind integriert.
Docs ↗Neun vollständige Sprachen
English, Türkçe, 简体中文, Español, Deutsch, Русский, Bahasa Indonesia, हिन्दी und العربية auf der Website und in der Projektdokumentation.
Docs ↗
02 / ANDERE MODULE
CleveresTricky vs. andere Module
TrickyStore und TeeSimulator lösen Teile desselben Problems, aber für Endnutzer sind die architektonischen Kosten wichtiger als eine lange Feature-Liste. Hier geht es gezielt um unnötige Komplexität und Wartungsaufwand.
CTCleveresTrickyRecommended fit
Besonders passend, wenn der echte Android-KeyMint-/StrongBox-Pfad für private Schlüssel erhalten bleiben soll und gleichzeitig Attestation-Kompatibilität, App-Richtlinien, unabhängige Identitäts-/Privacy-Steuerung, geschütztes RKP, verschlüsselte Wiederherstellung und mehrsprachige Verwaltung in einem öffentlichen Projekt gewünscht sind.
Official repository ↗TSTrickyStore
TrickyStore ist einfach, doch diese Einfachheit hat ihren Preis: Releases sind seit 1.1.0 Closed Source, das Targeting bleibt dateibasiert und umfassendere Policy-, Recovery- und Diagnosefunktionen liegen außerhalb des Moduls. Sobald das Setup über „für diese Pakete die Zertifikatskette ändern“ hinausgeht, wird es schwerer zu prüfen und zu verwalten.
Official README ↗TEETeeSimulator
TeeSimulator ist technisch ambitioniert, für ein normales Endnutzer-Kompatibilitätsziel aber unnötig komplex. Es injiziert in keystore2, hookt und leitet Binder-Verkehr um und kann im Generation-Modus Zielschlüssel in ein prozessinternes Software-KeyMint verschieben. Damit muss deutlich mehr Android-Verhalten emuliert und dauerhaft synchron gehalten werden, statt den nativen Private-Key-Pfad zu bewahren.
Official repository ↗| Kriterium | CleveresTricky | TrickyStore | TeeSimulator |
|---|---|---|---|
| Quellmodell | Öffentlicher Quellcode | Geschlossene Releases ≥ 1.1.0 | Öffentlicher Quellcode |
| App-Modell | Regeln + Profile + Privacy | target.txt + Modus-Flags | Profile + App-Zuweisung |
| Manager-WebUI | Native KernelSU/APatch-WebUI | Nicht dokumentiert | Profil-WebUI |
| Identität / Datenschutz | Unabhängige Identitätskontrollen | Patch-Level-Anpassung | Profil-Identitätsfelder |
| Backup & Wiederherstellung | Authentifiziertes verschlüsseltes Backup | Nicht dokumentiert | Nicht dokumentiert |
| RKP-Verhalten | Echter Android-Passthrough / geschützte Caller | Nicht dokumentiert | Gezielte RKP-Deny-/Fallback-Strategie |
| DRM-Identifier-Datenschutz | Isolate / redact auf unterstütztem Identitätspfad | Nicht dokumentiert | Nicht dokumentiert |
| Lokalisierung | 9 integrierte Sprachen | Englisches + chinesisches README | Überwiegend Englisch |
Quellmodell
- CleveresTricky
- Öffentlicher Quellcode
- TrickyStore
- Geschlossene Releases ≥ 1.1.0
- TeeSimulator
- Öffentlicher Quellcode
App-Modell
- CleveresTricky
- Regeln + Profile + Privacy
- TrickyStore
- target.txt + Modus-Flags
- TeeSimulator
- Profile + App-Zuweisung
Manager-WebUI
- CleveresTricky
- Native KernelSU/APatch-WebUI
- TrickyStore
- Nicht dokumentiert
- TeeSimulator
- Profil-WebUI
Identität / Datenschutz
- CleveresTricky
- Unabhängige Identitätskontrollen
- TrickyStore
- Patch-Level-Anpassung
- TeeSimulator
- Profil-Identitätsfelder
Backup & Wiederherstellung
- CleveresTricky
- Authentifiziertes verschlüsseltes Backup
- TrickyStore
- Nicht dokumentiert
- TeeSimulator
- Nicht dokumentiert
RKP-Verhalten
- CleveresTricky
- Echter Android-Passthrough / geschützte Caller
- TrickyStore
- Nicht dokumentiert
- TeeSimulator
- Gezielte RKP-Deny-/Fallback-Strategie
DRM-Identifier-Datenschutz
- CleveresTricky
- Isolate / redact auf unterstütztem Identitätspfad
- TrickyStore
- Nicht dokumentiert
- TeeSimulator
- Nicht dokumentiert
Lokalisierung
- CleveresTricky
- 9 integrierte Sprachen
- TrickyStore
- Englisches + chinesisches README
- TeeSimulator
- Überwiegend Englisch
Die Kritik richtet sich an die Architektur, nicht an die Entwickler: TrickyStore tauscht Transparenz und integrierte Verwaltung gegen Einfachheit; TeeSimulator nimmt für Flexibilität eine deutlich größere Interception-/Emulationsfläche in Kauf. CleveresTricky lässt normale Private-Key-Operationen bei Android KeyMint/StrongBox und ändert nur die nötige Kompatibilitätsschicht darum herum.
DECISION / MODEL
Warum CleveresTricky für Endnutzer oft praktischer sein kann
Für Endnutzer ist „mehr Simulation“ nicht automatisch besser. Jede zusätzliche Binder-Umleitung, Software-KeyMint-Funktion und jeder Fallback-Modus ist eine weitere Fläche, die Android-Änderungen folgen muss. CleveresTricky hält den Ansatz bewusst kleiner: native Schlüsseloperationen bleiben erhalten, Änderungen erfolgen nur an den wirklich nötigen Policy- und Zertifikatspunkten.
Androids Schlüsselpfad bleibt nativ
Private Schlüsseloperationen bleiben bei Android KeyMint oder StrongBox. Dadurch bleiben der eigene Key-Lifecycle und hardwaregestützte Eigenschaften der Plattform erhalten, statt die gesamte Schlüssel-Engine zu emulieren.
Nur ändern, was nötig ist
Zertifikatskompatibilität, App-Scope, sichtbare Identität und Privacy werden getrennt aufgelöst; Nutzer brauchen keine globale „alles ändern“-Konfiguration.
Ein Betriebsmodell
Verschlüsseltes Backup/Restore, geschützte RKP-Caller, Diagnose, Validierung und native Manager-UI reduzieren die Anzahl separater Module und Konfigurationsebenen.
03 / ANLEITUNG
Installieren, prüfen und konfigurieren ohne Rätselraten.
Verwende das offizielle GitHub-Release, prüfe bei Bedarf die Authentizität und konfiguriere nur die kleinste benötigte Policy. Aktuelle Kompatibilitätsdetails bleiben in der Repository-Dokumentation statt in schnell veraltenden UI-Badges.
Offizielles Release herunterladen
Nutze das aktuelle Paket aus der Releases-Seite statt neu gepackter Mirrors.
Authentizität prüfen
Prüfe SHA256SUMS und GitHub Build Provenance, wenn die Herkunft wichtig ist.
Mit unterstütztem Manager installieren
Folge der aktuellen Installer-Dokumentation im Repository; nicht unterstützte Wege stoppen, bevor ein Teilmodul zurückbleibt.
Neustarten und Dashboard + Logs prüfen
Bestätige einen gesunden Service, bevor Identität oder Key Material geändert werden.
Zuerst App-Scope festlegen
Globalen Scope nur verwenden, wenn er passt; sonst gezielte Regeln oder Profile für tatsächlich betroffene Apps anlegen.
Nur autorisiertes Key Material hinzufügen
Importiere verifizierte Keyboxes, die dir gehören oder die du ausdrücklich testen darfst. Das Projekt liefert kein funktionsfähiges privates Attestation-Material.
Identität/Privacy gezielt aktivieren
Build, Patch, Telephony, Region, Attestation oder Privacy nur dort aktivieren, wo es notwendig ist.
Validieren, sichern und Fehler suchen
Effective State und Logs prüfen, Apps mit gecachten Altwerten neu starten und vor riskanten Änderungen ein verschlüsseltes Backup erstellen.
04 / FAQ
Wichtige Projektgrenzen
Das Modul steuert einen lokalen Kompatibilitätspfad; es schreibt Hardware-Realität nicht um und garantiert kein Remote-Verdict.
Garantiert CleveresTricky ein Play-Integrity-Ergebnis?+
Nein. Remote-Policy, Firmware, realer Gerätezustand, Zertifizierung und Key Material können das Ergebnis beeinflussen. Das Projekt verspricht kein bestimmtes Remote-Verdict für jedes Gerät.
Ist eine Keybox enthalten?+
Nein. Es wird keine nutzbare Keybox und kein privater Attestation-Schlüssel mitgeliefert. Füge nur Material hinzu, das dir gehört oder das du verwenden darfst.
Ist DRM-Privacy ein Widevine-Bypass?+
Nein. Der unterstützte Privacy-Pfad isoliert einen stabilen DRM-Geräteidentifier; er erhöht weder Security Level noch Lizenzen, Provisioning, Content Keys oder HDCP.
Ersetzt CleveresTricky Android KeyMint oder StrongBox durch Software?+
Im normalen Kompatibilitätspfad nein. Die zugrunde liegenden Private-Key-Operationen laufen weiter über Android KeyMint oder StrongBox. CleveresTricky beobachtet den Keystore-Pfad und legt kontrollierte Zertifikatskompatibilität und Policy um diese echten Operationen.
Community
Der CleveresTech-Community beitreten
Projektupdates verfolgen, Setups vergleichen, Diagnosen teilen und konkrete Fragen mit anderen Nutzern auf Telegram diskutieren.
OPEN-SOURCE / GITHUB
Lies den Quellcode, bevor du dein Gerät veränderst.
Beginne mit Repository, aktuellen Release Notes und Security Model. CleveresTricky ist darauf ausgelegt, prüfbar, konfigurierbar und klar über seine Grenzen zu sein.