Security Architecture

How SCG
actually works.

A transparent look at the security layers protecting your game — written for developers, not marketing teams.

Hardware TEE Attestation
APK Certificate Binding
AES-256-GCM Encrypted
RSA-OAEP + PSS Signed
Zero Client Trust
Nonce Replay Prevention
Cross-Game HWID Banning
Frida + Xposed Detection
SDK Version Control
Hardware TEE Attestation
APK Certificate Binding
AES-256-GCM Encrypted
RSA-OAEP + PSS Signed
Zero Client Trust
Nonce Replay Prevention
Cross-Game HWID Banning
Frida + Xposed Detection
SDK Version Control
01 — The Problem

Software checks live in the attacker's environment.

Traditional anti-cheat runs entirely in software — meaning it lives in the same environment as the attacker. On Android VR headsets, the gap between attacker and defender is especially narrow. Tools exist that make hooking, patching, and bypassing software checks accessible to anyone willing to spend an afternoon on it.

The result is an arms race developers can never win. Every software check can eventually be found, studied, and bypassed. SCG exits that race entirely by moving the trust anchor to hardware — a place no software can reach.

Core Principle

Our backend never trusts anything the client reports. Every security claim is verified against hardware-signed attestation data generated by the device's secure chip. If the hardware says it's clean — it's clean. If it can't prove it cryptographically, it fails.

02 — Validation Pipeline

Eight gates. Every session.

Every time a player launches your game, SCG runs an 8-gate validation pipeline before a single frame renders. The process is typically under 30ms and completely invisible to legitimate players.

01
Payload Integrity
All required fields must be present and valid. Missing or malformed data fails immediately — no partial passes.
02
SDK Version Minimum Check
The SDK version sent by the bridge is checked against the minimum allowed version in our database. Outdated SDKs are blocked instantly.
03
Timestamp Validation
The payload timestamp must be within a strict 30-second window of server time. This prevents replay attacks — a captured payload is useless after 30 seconds.
04
Nonce Replay Prevention
Our backend generates a cryptographically random nonce per session. Once used it is permanently burned. Replaying any captured payload fails here — always.
05
SDK Version Control
The exact SDK version is validated against our version registry. If a vulnerability is found in a specific version, we deprecate it instantly — all games using that version are blocked until updated.
06
Hardware TEE Attestation
The full attestation certificate chain is verified against the hardware root CA. Rooted devices, modified firmware, and unlocked bootloaders all fail here. This cannot be faked in software.
07
APK Baseline Fingerprint
Your APK's signing certificate fingerprint — as read directly by the hardware — is compared against what was registered at setup. Re-signed or tampered builds fail instantly.
08
Developer Configured Checks
Hook detection (Frida, Xposed), root detection, ADB status, developer mode, and installer source checks. You configure which checks are flags vs instant fails in your dashboard.
03 — Hardware Attestation

The chip proves it. Software cannot lie.

The Trusted Execution Environment is a physically isolated processing area built into the device's chip. It operates independently of the Android OS — meaning even a fully compromised or rooted device cannot forge what the TEE reports.

The attestation certificate chain produced by the TEE is signed all the way up to a hardware root certificate authority. Our backend verifies this chain mathematically on every request. A broken or forged link anywhere in the chain causes immediate failure.

Verified Boot State
Bootloader Lock Status
TEE Security Level
Key Origin Proof
Session Nonce Binding
APK Cert Fingerprint
Package Name Confirmation
What This Catches

Rooted devices, custom ROMs, unlocked bootloaders, and modified firmware all fail hardware attestation — regardless of what any software layer claims. A device cannot pass without the hardware genuinely being in a clean, unmodified state.

SCG Hardware Verification
TEE chip signs the attestation
Verified against root CA mathematically
Nonce-bound — replay impossible
Cannot be faked in software
Detects rooted + modified devices
Software-Only Anti-Cheat
Runs in attacker's environment
Can be hooked and bypassed
Checks can be patched out
No hardware proof available
Arms race developers can't win
04 — HWID Banning

Bans that stick. Permanently.

Every device gets a Hardware ID derived from values physically burned into the chip at the factory. These values do not change with factory resets, OS updates, app reinstalls, or account changes. They are properties of the hardware — not the software.

When you ban an HWID, that device is blocked from your game permanently. With cross-game banning enabled, the same block applies across every SCG-protected game on the platform — automatically, with no extra configuration.

Privacy Note

HWIDs are one-way hashed before storage. We never store raw hardware identifiers. The hash is unique per device but cannot be reversed to reveal the original values. Player identities are never collected or stored by SCG.

05 — Continuous Protection

Passing launch is not enough.

SCG supports mid-session re-validation. Developers can trigger a manual re-check at any point using SCG.ReValidate(). This runs the full 8-gate pipeline identically to the initial validation. Rate limited to once every 2 minutes per player, enforced server-side.

Each re-validation runs the same full 8-gate pipeline as the initial check. Results appear in your dashboard in real time. Your game can act on a mid-session failure immediately — or you can review flagged sessions and take manual action at your discretion.

No Internet During Gameplay

If a player loses connection mid-session, SCG returns a NO_CONNECTION result — not a failure. Your game decides how to handle offline sessions. We recommend allowing limited offline play while queuing re-validation on reconnect.

06 — Setup Guide

Up and running in three steps.

Integration is designed to be as fast as possible. Most developers complete the full setup in under 30 minutes.

STEP 01
Sign up and register your game
Create your account on the dashboard. Register your game, upload your APK for certificate verification, and complete the one-time BTKV ownership challenge. Your API key is issued once verified.
STEP 02
Drop in the Unity package
Download the .unitypackage from your dashboard and import it into your Unity project. Open Window → SigChain Guard → Setup, enter your API key, and run the settings checker. No other configuration needed.
STEP 03
Call SCG.Validate()
Add a single call to your game start logic. The bridge fires automatically before Unity finishes loading. Configure your response handling — Photon endpoint, custom webhook, or direct Unity result handling.
GameManager.cs C#
1using SigChainGuard;
2
3public class GameManager : MonoBehaviour
4{
5  async void Start()
6  {
7    // Bridge fires before Unity — hardware check runs instantly
8    SCGResult result = await SCG.Validate();
9
10    if (result == SCGResult.PASSED)
11    {
12      LoadGame(); // ✓ Verified — safe to proceed
13    }
14    else if (result == SCGResult.FAILED)
15    {
16      // your own logic — kick, show error, disconnect
17    }
18    else if (result == SCGResult.NO_CONNECTION)
19    {
20      // handle offline — your choice
21    }
22  }
23}
07 — FAQ

Common questions.
Straight answers.

Does SCG work without Meta Store or AppLab?+
Yes — SCG works on any Android VR headset regardless of distribution method. Sideloaded builds, internal dev builds, Meta Store, AppLab — all supported. There is no dependency on Google Play Services or Meta's platform SDK.
Can a modder bypass SCG by decompiling the APK?+
No. The trust anchor is hardware — not the APK. Even with complete access to the decompiled code, an attacker cannot produce a valid hardware attestation certificate for a modified or rooted device. The certificate chain is verified by our backend against a hardware root CA on every single request.
Does SCG collect personal player data?+
No. SCG stores hardware identifiers (one-way hashed), validation results, and device signals. We do not collect player names, accounts, emails, locations, or any personally identifiable information.
What happens if my player has no internet connection?+
SCG returns SCGResult.NO_CONNECTION — not a failure. Your game decides how to handle the offline state. We recommend allowing limited offline play and re-validating silently when the connection is restored.
How does cross-game HWID banning work?+
When you ban a player's HWID and enable cross-game banning in your dashboard, that device hash is added to a shared flagged-device database. Every other SCG-protected game that checks against this database will see the flag — automatically, with no action required from other developers.
What Android VR headsets are supported?+
SCG supports Meta Quest 2, Quest 3, Quest Pro, Pico 4, and any Android-based VR headset running Android 10 or higher with hardware TEE support. PC VR headsets are planned for a future release.
Is JWT auth integration available on all plans?+
Yes — JWT verification for game servers is available on all plans including Starter. You should not need to be on a higher tier just to verify results server-side.

Ready to integrate?

Most developers are up and running in under 30 minutes. Register your game and get your API key today.

Get Started →
SCG STATUS
APIONLINE
ValidationACTIVE
Latency
Uptime99.9%