Security Architecture

How SCG
actually works.

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

01 The Problem 02 Validation Pipeline 03 Hardware Attestation 04 HWID Banning 05 Continuous Protection 06 Setup Guide 07 FAQ
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 — using our challenge — it's clean. If it can't prove it cryptographically, it fails.

02 — Validation Pipeline

Six gates. Every session.

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

01
Challenge Generation
Our backend generates a cryptographically random nonce — a one-time value tied to this exact session. The device cannot proceed without it, and once used it is permanently burned. This eliminates replay attacks entirely.
02
Hardware Attestation Request
The device's Trusted Execution Environment receives the challenge and produces a signed attestation certificate chain. This chain proves the device has a locked bootloader, verified boot state, and an unmodified OS. It is generated inside hardware — not software.
03
App Identity Verification
The attestation certificate contains the APK's signing certificate fingerprint as observed by the hardware itself. Our backend compares this against the fingerprint registered at signup. A re-signed or modified APK produces a different fingerprint and fails immediately.
04
Runtime Environment Scan
The bridge scans the device runtime for indicators of tampering — suspicious loaded libraries including known hook frameworks like Frida and Xposed, active debuggers, and modified system properties. Results are bundled into the encrypted payload.
05
Encrypted Payload Transmission
Everything collected is AES-256-GCM encrypted and RSA-PSS signed before leaving the device. The payload is bound to the session nonce and a strict timestamp window — making it impossible to intercept, replay, or modify in transit.
06
Server-Side Verdict
Our backend independently verifies the full attestation chain, validates every security signal against your dashboard configuration, and issues a signed pass or fail verdict. Your game never makes the security decision — the server does, every time.
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. This is the same technology that secures mobile payments and biometric authentication.

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 re-validates at randomized intervals during active gameplay. A player who passes the initial check cannot simply stay in the session indefinitely — the checks keep running silently in the background.

Each re-validation runs the same full 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 app
Create your account at dashboard.sigchainguard.com. Register your game, upload your APK for certificate verification, and complete the one-time 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 the SCG setup window, enter your API key, and run the BTKV verification build. 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 in the dashboard — Photon endpoint, custom webhook, or direct Unity response.
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 here — kick, ban, show error
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. We never collect or store any content from your game.
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 (Valve Index, HTC Vive) are planned for a future release.
What is SCG's uptime guarantee?+
We target 99.9% uptime. If we cause more than 2 hours of downtime in any billing period, that month is automatically credited to your account — no need to ask. You can monitor live API status at any time from your dashboard.

Ready to integrate?

Most developers are up and running in under 30 minutes. No credit card required to start.

Get Started →