Kubian  ·  Security Architecture

How Kubian protects sessions

Kubian combines hardware-backed integrity with a continuous native protection runtime and a verification backend. Three layers, one trust decision. Studio-controlled enforcement — without building an internal anti-cheat team.

Integrity · Runtime · Enforcement

1 · Hardware integrity

At session start, libKubianIntegrity.so runs a two-step exchange gated on the core library's hardware token: fetch a single-use challenge, mint a fresh Android KeyStore EC key bound to that nonce (StrongBox-first, TEE fallback), then trade the attestation chain — Build fingerprint, Android ID, Widevine ID and security level — for an integrity token. libKubianIntegrityCertificate.so provisions the one-time device certificate the same way, wiping key material from memory after use. The verification backend validates the certificate chain and signature cryptographically — X.509 and ECDSA verification run in native C via pyca/cryptography on OpenSSL 3.x, with KeyMint attestation structures DER-decoded via pyasn1 (cached per certificate).

2 · Runtime protection

A native protection loop (libKubianIntegrityCore.so) sweeps the running process and system every 2s — TracerPid debugger attach, Frida maps/ports/anon-exec, Zygisk / Riru / LSPosed / Magisk / KernelSU hooks, su paths, test-keys and debuggable properties, SELinux enforce state, memfd leaks, and a self .text hash against tampering, with ptrace TRACEME anti-debug. Detections are reported to the backend in realtime, bans are re-polled every 10s, device certificates auto-refresh, and enforcing checks terminate the process on Kick/Ban.

3 · Studio-controlled enforcement

Every realtime detection carries its own policy. For each check — Frida, injection, root, debugger, anti-debug — teams independently enable Alert, Kick, or Ban, or any combination. Bans are permanent, executed server-side on the device, and enforced network-wide across all protected apps.

A fresh challenge for every session

Every challenge is unique and single-use, so integrity responses cannot be replayed.

  1. Challenge request. The client requests a fresh challenge token from the Kubian verification backend when a protected session starts.
  2. Hardware signing. The device's hardware-backed key store signs an integrity certificate that proves platform integrity — verified boot state, bootloader lock, OS patch level, security level, and hardware-backed key properties.
  3. Submission. The signed integrity token is returned to the verification backend alongside the session integrity token.
  4. Verification. The backend verifies the certificate chain and signature, checks every integrity check against the studio's configuration, and checks for replay attempts and device bans.
  5. Verdict. A signed verdict is returned to the client. Trusted sessions proceed; failed sessions move into the studio's review and enforcement workflow.

What Kubian checks

Integrity & platform

  • Hardware integrity certificate chain
  • Verified boot state (green / root-of-trust)
  • Bootloader lock state
  • Device integrity
  • OS security patch level
  • Hardware-backed key properties

App & integrity

  • Application package name
  • Application certificate digest
  • Signed session integrity token
  • Challenge nonce (replay protection)
  • Device ban records

Runtime protections

  • Root & hidden root (Magisk, KernelSU)
  • Frida connection blocking
  • Hooking & injection frameworks
  • Debugger & app debugging prevention
  • In-app injection prevention
  • SELinux enforcement state
  • Per-check Alert / Kick / Ban policy

These are selected public capabilities, not a complete inventory. Additional safeguards remain intentionally undisclosed to keep the suite effective.

Decide what each detection does

Every realtime check maps to its own policy. Actions are independent, so a check can Alert only, Ban + Alert, Kick + Alert, or any other combination — per detection.

Alert

Log the detection to the offenders audit with full context for your team's review. No kick, no ban.

Kick

Remove the player from the active session. No server ban is issued, so a repeat offense can be escalated later.

Ban

Remove the player from the session and execute a permanent server ban on the device. Bans are enforced network-wide across all protected apps.

Realtime checkWhat it detectsDefault actions
Frida DetectionFrida server presence and connection attemptsAlert
Injection DetectionXposed, Zygisk, LSPosed, Substrate and runtime hooking frameworksAlert
Root (Hard)su binaries, uid 0, Magisk / KernelSU mounts and hidden rootBan Alert
Root (Soft)SELinux permissive, test-keys builds, insecure / debuggable propertiesKick Alert
Debugger DetectionAttached debuggers via TracerPidKick Alert
Anti-Debug Trapptrace / seccomp trap that blocks debugger attachmentAlert

The realtime policy is cryptographically signed by Kubian and recalculated every 30s asynchronously — a tampered response is rejected and the library falls back to full protection. When a ban is issued mid-session, the client detects it through a ban-state poll and enforces it immediately, even across restarts.

What you control in the Kubian dashboard

Kubian ships with an operational dashboard your team uses to watch, review, and enforce what happens on protected devices. Here is what each section is for.

Overview

Live counts of players validated, offenders flagged, pending reviews, and active bans, plus a 24-hour API request chart and the recent offender feed. This is where your team starts each day.

API Settings

The integrity policy. Every realtime check — Frida, injection, root (hard), root (soft), debugger, anti-debug — is switched on or off and assigned Alert, Kick, or Ban actions. Device, hardware, and application checks are configured here too.

Players

Every registered player on the project, searchable by UID, with registration date and verification history.

Offenders

The audit log. Every detection records the check that fired, the timestamp, the device, and the action that was taken — so your team can review and escalate.

Members

Team access with Owner, Admin, and Member roles — who can view, review, and manage the project.

Details

Project name, ownership, and the App ID and App Secret your SDK uses to authenticate requests to the verification backend. Secrets can be regenerated if compromised.

Certificates

The release APK is pinned to the project once, locking the Application SHA-256 and package name that integrity must match. This can only be done a single time.

Delete

The destructive action. Permanently purges the project, its keys, bans, players, logs, and members. There is no recovery.

Dashboard settings are recalculated every 30s asynchronously to avoid double-request edge cases, and the realtime policy they control is cryptographically signed by Kubian — a tampered response is rejected and the library falls back to full protection. Saved settings are still served out extremely fast.

Deploy Kubian for your studio

Low, scaling prices. Kubian Mini at $60/month and Kubian Max at $80/month, per application. Direct integration support on every plan.