================================================================================
SCREECHVR: EXTREME-DEPTH VR ANTI-CHEAT RESEARCH, MODDING THREAT INTELLIGENCE,
FULL ATTACK-SURFACE AUDIT & DEFENSIVE ARCHITECTURE
================================================================================

1. EXECUTIVE SUMMARY
================================================================================

ScreechVR is a Unity 2021.3 LTS multiplayer VR game (Meta Quest standalone) using
Photon PUN 2 + Photon Voice, PlayFab, Meta/Oculus SDK, and a Cloudflare Worker
backend. IL2CPP for Quest builds. No dedicated authoritative game server exists.

This report consolidates all prior research (28 reports, 26 deliverables, Ghidra
binary analysis, critical review, threat catalog) into a single comprehensive
document with 36 sections covering the full attack surface, modding threat model,
defensive architecture, cost analysis, and implementation roadmap.

Key findings:
- 13 confirmed vulnerabilities (V1-V13) with exact file:line evidence.
- Client-trusted currency, moderator status, ban enforcement, cosmetics, leaderboards.
- No movement validation, no server-side game state authority.
- Master client is a player, not a trusted server.
- Meta attestation docs now accessible (previously 404). Token valid 24h, nonce
  one-time, timestamp freshness, rate limits 100/hr 200/day per device.
- Photon pricing verified: free tier 20 CCU (dev only), 100 CCU $95/12mo,
  500 CCU $95/mo, 1000 CCU $185/mo. PUN 2 in maintenance/LTS mode.
- Recommended: Cloudflare Workers + D1 + PlayFab + Photon PUN2 (v1), €0 additional
  spend. Dashboard local-only (http://127.0.0.1:<port>). No dedicated server for v1.
- Movement exploits can only be detected, not prevented, without dedicated server.
- All tests are planned, not executed. No implementation performed.

================================================================================
2. SCOPE, ENVIRONMENT AND ASSUMPTIONS
================================================================================

Game: ScreechVR (Voideration Anti-Cheat)
Engine: Unity 2021.3.32f1, URP 12.1.13
Platform: Meta Quest standalone (Android/IL2CPP)
Multiplayer: Photon PUN 2 + Photon Voice
Backend: PlayFab (auth, inventory, currency, bans, title data, leaderboards)
Additional: Cloudflare Worker (CCU, /link, /motd, /redeem), Discord bot
Locomotion: Custom gorilla-tag-style (GorillaLocomotion.Player)
Research date: 2026-10-29
Budget: €0 additional monthly spend
Max CCU: 100 (planned)
Heartbeat: 5 minutes (retained per user requirement)

Assumptions:
- IL2CPP for Quest builds (verified in Packages/manifest.json and build docs).
- No dedicated game server exists (verified: Photon Cloud is relay-only).
- No CloudScript/Azure Functions deployed (none found in repo; verify in dashboard).
- Meta attestation eligibility unverified (docs accessible, eligibility unknown).
- PlayFab UserData "Moderator" writability unverified (likely client-writable).
- All tests are planned, not executed.

================================================================================
3. SOURCE INVENTORY
================================================================================

Local project files inspected (read-only):
- Assets/Scripts/Oculus_Login.cs (auth, currency, ban, MOTD, title data, inventory)
- Assets/Scripts/ScreechApi.cs (worker HTTP client)
- Assets/Scripts/PhotonVRManager.cs (networking, rooms, cosmetics, gun)
- Assets/Scripts/PlayerSpawner.cs (spawn/despawn)
- Assets/Scripts/UsernameValidator.cs (content creator check)
- Assets/Scripts/AppEntitlementCheck.cs (Oculus entitlement, log only)
- Assets/Scripts/KickIfBanned.cs, Kick_Player.cs (ban/kick)
- Assets/Scripts/LevelSelect.cs, MapLoader.cs, sceneyessss.cs (scene loading)
- Assets/Scripts/Gamemode_System.cs, GamemodeManager.cs, Gamemode_.cs, DeployGamemode.cs
- Assets/Scripts/GetCosmetics.cs, SecondaryCosmetics.cs, BuyCosmetic.cs, Cosmetic_Yes.cs
- Assets/Scripts/TagManager.cs, TagPlayer.cs, TagLeaderboard.cs
- Assets/Scripts/BestJumpscare.cs (collider kill)
- Assets/Scripts/NewGorillaLocomotionScripts/Player.cs (locomotion)
- Assets/Scripts/Hand_Physic.cs (grab/physics)
- Packages/manifest.json (SDKs)
- Assets/Resources/GorillaPrefabs/Gorilla Rig.prefab

Research documents (27 reports + 26 deliverables + consolidated docs):
- research/ (27 reports + README + FINAL_RESEARCH_SUMMARY)
- research/FINAL_SECURITY_ARCHITECTURE/ (26 deliverables)
- docs/screechvr-technical-map-2026-10-28.md
- docs/voideration-screechvr-architecture.md
- docs/voideration-anticheat-research.md
- docs/voideration-anticheat-review.md
- research/QUEST_MODIFICATION_THREAT_CATALOG.md
- research/FINAL_SECURITY_CORRECTION_BUNDLE.txt (latest, 53,215 bytes)
- research/SCREECHVR_SECURITY_REVIEW_v01-v06 (6 versions)

External sources:
- Meta Quest Attestation API: https://developers.meta.com/vr/documentation/native/ps-attestation-api/ (ACCESSIBLE 2026-10-29)
- Meta User Verification: https://developers.meta.com/vr/documentation/spatial-sdk/ps-ownership/ (GATED - 404)
- PlayFab login best practices: https://learn.microsoft.com/gaming/playfab/identity/player-identity/login/login-basics-best-practices
- Photon PUN custom authentication: https://doc.photonengine.com/pun/current/connection-and-authentication/authentication/custom-authentication
- Photon pricing: https://www.photonengine.com/realtime/pricing (ACCESSIBLE 2026-10-29)
- Cloudflare Workers pricing: https://developers.cloudflare.com/workers/platform/pricing/
- Cloudflare D1 limits: https://developers.cloudflare.com/d1/platform/limits/
- Cloudflare D1 pricing: https://developers.cloudflare.com/d1/platform/pricing/
- OWASP API Security Top 10 2023: https://owasp.org/API-Security/editions/2023/en/0x11-t10/
- OWASP Cryptographic Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
- Tomahawk research: local files + Ghidra binary analysis (libTomahawkCore.so, 5.3MB)

================================================================================
4. SOURCE-INTEGRITY COMPARISON
================================================================================

Verified: all research files exist at documented paths. No contradictions between
research reports and source code (verified against Oculus_Login.cs, ScreechApi.cs,
BuyCosmetic.cs, PhotonVRManager.cs, Player.cs, TagPlayer.cs, TagManager.cs,
KickIfBanned.cs, AppEntitlementCheck.cs, UsernameValidator.cs, PlayerSpawner.cs,
BestJumpscare.cs, GetCosmetics.cs, SecondaryCosmetics.cs, LevelSelect.cs, MapLoader.cs,
Gamemode_System.cs, GamemodeManager.cs, Hand_Physic.cs).

No credentials reproduced. No implementation performed. No production changes.

================================================================================
5. EXISTING ARCHITECTURE AND TRUST BOUNDARIES
================================================================================

Trust model (verified):
- Client (untrusted): all game logic, movement, currency display, moderator status, cosmetics, IAP grants, leaderboards.
- Photon Cloud (semi-trusted relay): room management, RPC routing, ownership. Master client is a player.
- PlayFab (trusted backend): auth, inventory, currency, bans, title data, leaderboards.
- Cloudflare worker (trusted): CCU, /link, /motd, /redeem, session validation, ban check.
- No dedicated authoritative server exists.

Trust boundaries:
1. Client -> Photon: untrusted input enters network.
2. Photon -> PlayFab: custom auth (server-to-server).
3. PlayFab -> Worker: session validation.
4. Worker -> Dashboard: admin API (backend-enforced).

================================================================================
6. UNITY MONO VS IL2CPP
================================================================================

ScreechVR uses IL2CPP for Quest builds (verified: Unity 2021.3 LTS, URP 12.1.13,
IL2CPP scripting backend per build docs). Mono is used in Unity Editor for development.

IL2CPP implications:
- No managed assemblies in final build (harder to decompile than Mono).
- Native binary (ARM64 .so files) can still be patched (disassembler required).
- IL2CPP metadata (global-metadata.dat) can be extracted (IL2CPPDumper).
- Runtime instrumentation (Frida) still works on IL2CPP (native hooks).
- Symbol stripping reduces but doesn't eliminate reverse engineering.

Defense: IL2CPP + symbol stripping + server-side validation. IL2CPP is not a
security boundary, only an obstacle.

================================================================================
7. UNITY MANAGED ASSEMBLY MODIFICATION
================================================================================

Not applicable to Quest builds (IL2CPP). Relevant for PC builds if ever released.
For Quest: native binary patching required (harder, requires ARM64 disassembly).
For PC (if released): Mono assemblies can be decompiled/modified with dnSpy/ILSpy.
Defense: IL2CPP for all platforms + server-side validation.

================================================================================
8. RUNTIME PATCHING AND MOD-LOADER ECOSYSTEMS
================================================================================

Relevant tool families (defensive classification):
1. Official developer tools: Unity Profiler, Meta Quest Developer Hub, PlayFab SDK.
2. General analysis tools: Ghidra, IDA, rizin, dnSpy, ILSpy, IL2CPPDumper.
3. Mod-loader frameworks: BepInEx (Mono), MelonLoader (Mono/IL2CPP), Harmony.
4. Diagnostics (false positive risk): Unity Profiler, Meta diagnostics, ADB.
5. Integrity signals: Meta App Attestation, PlayFab auth, Photon custom auth.

For Quest (IL2CPP): mod loaders require native injection (harder). BepInEx/MelonLoader
work on Mono builds only. IL2CPP modding requires native hooks (Frida, etc.).

For PC (if released): mod loaders work on Mono. IL2CPP modding requires native injection.

Defense: IL2CPP + server-side validation. Client detection is a signal, not proof.

================================================================================
9. NATIVE MODIFICATION AND INSTRUMENTATION THREATS
================================================================================

Native code modification:
- ARM64 binary patching (requires disassembler).
- Runtime hooking (Frida, native hooks).
- Memory modification (requires root/debugger).
- Process instrumentation (requires ADB/debugger).

For Quest: requires developer mode (ADB) or root. Meta attestation may detect.
For PC: more attack surface (DLL injection, memory editing).

Defense: Meta attestation (if available) + server-side validation + behavioral detection.

================================================================================
10. QUEST APK MODIFICATION AND SIGNING
================================================================================

APK modification:
- Extract APK, modify resources/code, re-sign with different key.
- Meta Store builds are signed by Meta. Sideloaded builds can be re-signed.
- Unity asset modification via UABEA (textures, materials, prefabs, scenes).
- IL2CPP binary patching (native code).

Detection: Meta entitlement check (AppEntitlementCheck, currently log-only), version
enforcement (title data), build IP whitelist.

Defense: Meta entitlement + version enforcement + server-side ban check. Client integrity
is a signal, not a gate.

================================================================================
11. PCVR MODIFICATION SURFACES
================================================================================

Not applicable (ScreechVR is Quest-only currently). If PC version is ever released:
- More attack surface (DLL injection, memory editing, file modification).
- No Meta attestation (different platform).
- Would need separate security review.

Marked as out of scope for v1. Retain short future-platform note.

================================================================================
12. ASSET, SHADER AND CONFIGURATION MODIFICATION
================================================================================

Asset modification (UABEA):
- Textures, materials, prefabs, scenes can be modified.
- Visual mods (cosmetics) vs gameplay-affecting (movement, hitboxes).
- Defense: Asset integrity hashes (v2). Server-side inventory validation for cosmetics.

Configuration modification:
- Player.cs fields (jumpMultiplier, maxJumpSpeed, etc.) can be modified.
- BuyCosmetic.Price can be modified.
- Defense: Server-side validation of outcomes (currency balance, cosmetic ownership).

Local storage:
- PlayerPrefs (username, TOS agreement). No sensitive data.
- PlayFab UserData (USERNAME, Moderator, EQUIPPED). Moderator is client-writable (verify).

================================================================================
13. MEMORY AND RUNTIME STATE MANIPULATION
================================================================================

Memory modification:
- Currency (_currency) can be modified locally.
- Movement parameters (jumpMultiplier, maxJumpSpeed) can be modified.
- Moderator status (AccountPref) can be set client-side.
- Position/velocity can be modified.

Defense: Server-side validation of all valuable state. Client memory is untrusted.

What can be prevented: Currency (server-side grants), moderator status (server-side
verification), ban status (server-side check).
What can only be detected: Movement exploits (heuristic), memory modification
(behavioral anomalies).

================================================================================
14. VR INPUT AND TRACKING MANIPULATION
================================================================================

VR input manipulation:
- Controller input spoofing (synthetic input events).
- Tracking pose manipulation (abnormal pose deltas).
- Locomotion state desynchronization.

Defense: Server-side validation of movement (requires dedicated server). For v1:
heuristic detection (speed/teleport flags) + manual review.

Legitimate considerations: VR tracking noise, recentering, tracking loss, latency,
packet loss, legitimate teleport (TP_YA).

================================================================================
15. CLIENT-SIDE DETECTION LIMITATIONS
================================================================================

Client-side detection cannot guarantee security:
- Modified client can remove checks.
- Modified client can force success return values.
- Modified client can suppress telemetry.
- Modified client can alter local clocks.
- Modified client can fake clean status.

Defense: Server-side enforcement of all security decisions. Client detection is a
signal for flagging, not banning. Never auto-ban on client-reported signals alone.

================================================================================
16. REAL-WORLD VR MODDING ECOSYSTEM RESEARCH
================================================================================

Legitimate modding ecosystems:
- BepInEx (Mono), MelonLoader (Mono/IL2CPP), Harmony (patching).
- Asset replacement (UABEA, AssetRipper).
- Cosmetic mods (texture/model replacement).

Overlap with unauthorized cheating:
- Same tools used for both legitimate mods and cheats.
- Visual mods (cosmetics) vs gameplay-affecting (movement, currency).
- Policy: only flag if modification affects competitive integrity.

ScreechVR does not officially support third-party mods. All modifications are
unauthorized. But visual-only mods should be logged, not banned.

================================================================================
17. PHOTON RPC AND RAISEEVENT AUDIT
================================================================================

Actual enforcement points:
- Photon Cloud: relays RPCs, no param validation, no rate limiting, no game logic.
- Photon Master Client: player with flag, controls room properties and scene sync. Untrusted.
- Worker: can enforce rate limits on Worker API calls only (not Photon RPCs).
- PlayFab: can enforce bans, inventory, currency (server-side).
- Dedicated server: not available (v2+).

Client-controlled state (cannot be prevented without dedicated server):
- Movement/position (Player.cs, locomotion).
- Tag/infection state (TagPlayer.cs, TagManager.cs RPCs).
- Score/leaderboard submissions (GDH leaderboard).
- Cosmetic equip (GetCosmetics.cs, Photon props).
- Game state (Gamemode_System.cs, CurrentMode).

What can be prevented (server-side):
- Currency minting (move grants to worker/CloudScript).
- Moderator spoof (server-side role verification).
- Ban bypass (Photon custom auth ban check).
- Cosmetic spoof (backend inventory check).
- Version mismatch (title data + custom auth).

What can only be detected (heuristic, not prevention):
- Movement exploits (speed, teleport, fly).
- RPC floods (rate limit + flag).
- Tag/Infection spoof (flag non-tagger RPCs).
- Leaderboard faking (flag anomalies).
- Master client abuse (log + flag).

Recommended short-term (v1): Backend validation + heuristic detection + manual review.
Recommended long-term (v2+): Dedicated authoritative server for movement, scoring, bans.

================================================================================
18. PHOTON AUTHENTICATION AND IDENTITY MAPPING
================================================================================

Correct authentication flow (PlayFab Photon integration):
1. Client: Oculus Core.Initialize + Users.GetLoggedInUser -> Oculus ID + username.
2. Client: PlayFab LoginWithCustomID (Oculus ID, CreateAccount=true) -> PlayFab session ticket.
3. Client: PlayFab GetPhotonAuthenticationToken (photonAppId) -> Photon custom auth token.
4. Client: Photon ConnectUsingSettings with custom auth params (Photon token as auth param).
5. Photon server: calls custom auth URL (server-to-server) with auth params.
6. Backend: validates Photon token via PlayFab's /photon/authenticate endpoint. Returns allow/deny + UserId.
7. Photon enforces result. Client cannot bypass.

Token distinctions:
- PlayFab Session Ticket: for PlayFab API calls (/redeem, inventory). Verified by PlayFab (GetAccountInfo).
- Photon Custom Auth Token: for Photon connection. Verified by Photon's servers (server-to-server).
- Meta Oculus ID: hardware-bound identifier. Used as PlayFab CustomId.
- Meta User Proof: one-time proof of account control (getUserProof). Verified server-side with Meta.
- Meta Attestation Token: device/app integrity token. Verified server-side with Meta.

CORRECTED: Worker does NOT validate Photon token via GetAccountInfo (GetAccountInfo verifies
account existence, not token validity). Worker delegates to PlayFab's /photon/authenticate
endpoint. Worker uses its own PlayFab credentials for ban checks.

================================================================================
19. VOICE-RELATED TRUST BOUNDARIES
================================================================================

Photon Voice (PunVoiceClient) on same GO as PhotonVRManager in every gameplay scene.
Singleton picks FindObjectsOfType()[0], never destroys duplicates.

Voice-specific concerns:
- Voice identity must match gameplay identity (same Photon player).
- Voice session lifecycle tied to Photon room lifecycle.
- No voice-specific permissions observed (all players can talk).
- Voice relay is server-side (Photon Voice servers), not client-to-client.
- No "God voice" or privileged voice observed in codebase.

Trust boundary: Voice is relayed by Photon Voice servers. Client cannot spoof voice
identity (Photon authenticates the player). But client can mute/unmute locally.

================================================================================
20. PLAYFAB EXECUTION-CONTEXT AUDIT
================================================================================

PlayFab CloudScript execution context:
- currentPlayerId: automatically set by runtime for authenticated calls. Trusted.
- args: client-supplied arguments. UNTRUSTED.
- context: additional info (playStreamEvent, playerProfile, currentEntity). Trusted for server-triggered calls.
- server object: PlayFab server API. Trusted.
- http object: outbound HTTP. Trusted (but URL/content controlled by code).

Key handlers and their trust properties:
- helloWorld: uses currentPlayerId (trusted). No security concern.
- makeAPICall: uses currentPlayerId (trusted). Updates Level stat to 2. No validation of stat value.
- makeEntityAPICall: uses context.currentEntity (trusted). Sets entity objects with client-supplied prop1 (UNTRUSTED input).
- makeHTTPRequest: makes HTTP to httpbin.org (test endpoint). Should be removed before production.
- handlePlayStreamEventAndProfile: uses context.playStreamEvent and context.playerProfile (trusted). Makes HTTP to httpbin.org (test).
- completedLevel: uses currentPlayerId (trusted). Accepts levelName and monstersKilled from client (UNTRUSTED). No validation of level completion.
- updatePlayerMove: uses currentPlayerId (trusted). Accepts playerMove from client (UNTRUSTED). Cooldown validation is server-side (good). Stat name fixed from "" to "movesMade".
- unlockHighSkillContent: uses context.playStreamEvent (trusted). Sets HighSkillContent based on stat value.
- RoomCreated/Joined/Left/Closed/PropertyUpdated/EventRaised: Photon room callbacks. Args from Photon (semi-trusted). EventRaised handles playerMove -> processPlayerMove.
- OnPurchaseItem: uses context.playerId (trusted). Accepts ItemId, VirtualCurrency, Price from client (UNTRUSTED price). Should use server-side catalog price.
- ReportPlayer: uses Args.ReporterId (UNTRUSTED - client-supplied). Moderator check via client-supplied ID (insecure). Should use server-side role verification.
- checkUserBanStatus: uses currentPlayerId (trusted). Returns ban status. No security concern.
- Heartbeat: uses currentPlayerId (trusted). Accepts sequenceNumber, timestamp from client (UNTRUSTED). Validates sequence (server-side) and timestamp freshness.
- VerifyModerator: uses currentPlayerId (trusted). Checks IsMod in ReadOnlyData (server-side). Secure.
- ServerGrantCurrency: uses currentPlayerId (trusted). Validates amount (1-10000). Grants via server API. Secure (but needs authorization check).
- ServerValidatePurchase: uses currentPlayerId (trusted). Placeholder for server-side price lookup.

================================================================================
21. MODERATOR AND PRIVILEGED-HANDLER SECURITY
================================================================================

Moderator authorization (verified):
- ReportPlayer uses Args.ReporterId (client-supplied) to check moderator status. INSECURE.
- Fix: use server-side ReadOnlyData (IsMod key) via isModServerSide(currentPlayerId).
- Moderator IDs hardcoded in original (removed in V08, replaced with server-side check).
- Webhook URL hardcoded in original (preserved per user request, should be moved to Title Internal Data).

Privileged handlers:
- ServerGrantCurrency: should require server/admin authorization. Currently any authenticated player can call it.
- ServerValidatePurchase: placeholder, needs catalog configuration.
- ReportPlayer: moderator ban capability should be server-side verified.

================================================================================
22. ECONOMY, PURCHASES AND PROGRESSION SECURITY
================================================================================

Currency flow (verified):
- Oculus_Login.cs: AddCurrency(int amount) calls PlayFab AddUserVirtualCurrency with client-specified amount.
- PlayFab validates session ticket but NOT amount. Client can grant arbitrary currency.
- BuyCosmetic.cs checks local _currency >= Price before calling PlayFab PurchaseItem.
- PlayFab PurchaseItem validates price server-side against catalog (STRONG EVIDENCE, verify in dashboard).
- Currency_Code = "HC". _currency is client-held int.

Purchase flow:
- BuyCosmetic: client checks local balance, calls PurchaseItem (server validates price).
- OnPurchaseItem (CloudScript): accepts price from client (should use server-side catalog price).
- SpokesSigmaIAP: IAP (Oculus). Receipt validation UNVERIFIED.
- ATM_TAB/Atm_Manager: not deeply read. Currency flow unknown.

Progression:
- completedLevel: sets lastLevelCompleted, updates level_monster_kills. No validation of level completion.
- unlockHighSkillContent: unlocks content when stat threshold reached. Uses PlayStream event.
- updatePlayerMove: validates cooldown (15s). Fixed empty stat name bug.
- Leaderboard (GDH): client-submitted scores. No server validation.

================================================================================
23. FIVE-MINUTE HEARTBEAT ARCHITECTURE
================================================================================

Design (proposed, not implemented):
- Server-side heartbeat with sequence numbers, timestamp freshness, rate limiting.
- Client sends: { sequenceNumber, timestamp, challengeResponse }.
- Server validates: sequence increments, timestamp within 5 min, rate limit (max 1 per 4 min).
- Server updates: last_heartbeat_seq, last_heartbeat_time in PlayFab internal data.
- Replay protection: sequence number must be greater than last.
- Rate limiting: max 1 heartbeat per 4 minutes (allow slack).
- Failure: log warning, return error. Do NOT ban on heartbeat failure alone.

What heartbeat CAN detect:
- Session liveness (player is still connected).
- Replay attempts (duplicate sequence numbers).
- Stale sessions (timestamp too old).
- Abnormal request rates (too frequent).

What heartbeat CANNOT detect:
- Modified client (client can imitate heartbeat).
- Memory modification (client can fake values).
- Runtime instrumentation (client can hook heartbeat function).

Cost: 5-min heartbeat = 288 req/player/day. At 100 CCU = 28,800 req/day (within 100k free tier). D1 writes: 288 writes/player/day. At 100 CCU = 28,800 writes/day (within 100k free tier).

Alternative: 30s request (no D1 write) + 5-min D1 write. Or KV for session state (but KV free tier is 1,000 writes/day - too low for per-player heartbeat).

================================================================================
24. META APP ATTESTATION ELIGIBILITY AND DESIGN
================================================================================

From official Meta docs (fetched 2026-10-29):
- Platform: Android only. Quest 2, Quest Pro, Quest 3, Quest 3S.
- Requires: Platform SDK v55+, Meta Horizon OS v55+.
- Wi-Fi required.
- Token valid 24h by default (configurable).
- Server must validate: exp, nonce, timestamp, app_integrity_state, package_cert_sha256_digest, device_integrity.
- Rate limits: 100 req/hour, 200 req/day per device.
- Device ban: server-to-server, requires Data Use Checkup approval.
- security_update_pending_days: only available if device_state is Advanced or Basic.

What remains unverified for ScreechVR:
- API availability to all Quest developers vs gated.
- Whether ScreechVR's Meta app has required permissions.
- Unity 2021.3.32f1 + Platform SDK v55+ compatibility.
- Whether attestation works for sideloaded builds.

Handling policy (proposed):
- Trusted (Advanced, StoreRecognized): normal access.
- Suspicious (Basic): flag + increased monitoring, allow with restrictions.
- Untrusted (NotTrusted or NotRecognized): restrict sensitive actions, flag for review.
- Unsupported (older device, SDK < v55): allow with warning.
- Unavailable (service outage): allow with flag. Do not block.
- Inconclusive (errors): flag + manual review. Do not auto-ban.

================================================================================
25. WORKER AND D1 SECURITY
================================================================================

Worker endpoints (verified from ScreechApi.cs and worker.js):
- /updateplayers (POST, body {"players": count}): public, no auth. Rate limit needed.
- /redeem (POST, body {"code", "ticket"}): PlayFab session ticket required. Weak rate limiter (per deep audit).
- /motd (GET): public. Returns MOTD from title data.
- /validate-session (proposed): Meta proof + PlayFab ticket + ban check.
- /heartbeat (proposed): session liveness, duplicate detection.
- /report-flag (proposed): telemetry -> detection rules.
- /ban-check (proposed): real-time ban status.

D1 database (proposed schema):
- sessions, players, flags, bans, audit_log, ccu_snapshots, webhooks, detection_rules, evidence.

Security:
- Parameterized queries (D1 binding API). No SQL injection if used correctly.
- Rate limiting: per-IP and per-user.
- Input validation: Zod schemas (or manual validation in worker).
- CORS: allowlist dashboard origin only.
- Secret management: all secrets in worker env vars (encrypted at rest).
- Environment separation: dev/staging/prod.

OWASP API Security Top 10 (2023) coverage:
- API1 BOLA: server-side ownership checks.
- API2 Broken Auth: JWT + MFA + rate limiting.
- API3 BOPLA: field-level authorization.
- API4 Unrestricted Resource Consumption: rate limits, input size limits.
- API5 Broken Function Level Auth: RBAC server-side.
- API6 Unrestricted Access to Sensitive Business Flows: rate limits, idempotency.
- API7 SSRF: no user-supplied URLs.
- API8 Security Misconfiguration: environment separation, secret management.
- API9 Improper Inventory Management: API versioning.
- API10 Unsafe Consumption of APIs: validate all external API responses.

================================================================================
26. LOCAL DASHBOARD SECURITY
================================================================================

Dashboard is LOCAL-ONLY: http://127.0.0.1:<port>. No public access. No domain needed.

Closed registration: No public signup. Dashboard is private by default.

Initial owner enrollment: Secure out-of-band process (CLI command, invite link with
single-use token, or manual DB insert). No self-service registration.

Backend authorization: Every sensitive API endpoint verifies identity and owner
permissions server-side. Deny-by-default. Direct API calls bypassing the frontend
are blocked (backend-enforced, not frontend-hidden).

MFA enforcement: TOTP required for all owner actions. Login rate limit: 5 attempts
per 15 minutes per IP. Account lockout after 10 failed attempts.

Session security: Short-lived access tokens (15 min) + refresh tokens (7 days,
rotating, revoked on logout). Secure cookie handling (SameSite=Strict, HttpOnly,
Secure). Session revocation on password change or MFA reset.

Secure recovery: Password reset via email (time-limited link). MFA reset requires
out-of-band verification. No self-service owner creation or promotion.

CSRF protection: SameSite cookies + CSRF tokens for state-changing requests.
Not applicable if using Bearer token auth (no cookies).

Audit logging: All login attempts (success/failure), player lookups, moderation
actions, settings changes, rule changes, ban/unban actions logged with actor,
timestamp, IP, and reason.

Secret storage: All secrets in worker env vars (Cloudflare dashboard, encrypted
at rest). No privileged credentials in frontend JavaScript. No API keys in client.

Emergency access revocation: Owner can revoke all sessions, rotate JWT secret,
disable dashboard access. Process documented.

Additional staff roles: RBAC (Owner/Admin/Moderator/Viewer). Least privilege.
No role can escalate to Owner. Owner role cannot be assigned via dashboard.

Local-only design:
- Server binds to 127.0.0.1 only. No LAN or internet exposure.
- Dashboard unavailable when owner PC is off. Game backend remains online independently.
- No domain needed. No public hosting. No Cloudflare Pages.
- Secure local credential storage: OS keychain or encrypted config file.
- Startup/shutdown: manual or via system service. No auto-start without approval.

Dashboard security test plan (all UNEXECUTED):
1. Unauthenticated API requests -> expect 401.
2. Registration attempts -> expect 404 (no registration endpoint).
3. Non-owner account -> expect 403 on all sensitive endpoints.
4. Direct API calls bypassing frontend -> expect 401/403 (backend-enforced).
5. Role escalation attempt -> expect 403 (server-side role check).
6. Owner creation attempt -> expect 403 (no endpoint exists).
7. Expired session -> expect 401.
8. Revoked session -> expect 401.
9. Stolen session token -> expect 401 (if token rotation/revocation implemented).
10. MFA bypass -> expect 403 (MFA required for all owner actions).
11. Login brute force -> expect 429 (rate limit).
12. CSRF (if cookie-based) -> expect 403 (CSRF token mismatch).
13. Account recovery abuse -> expect rate limit + verification.
14. Emergency session revocation -> verify all sessions invalidated.
15. Secret exposure in frontend -> verify no secrets in JS bundle (code inspection, NOT test).

All tests are PLANNED, not executed. No fabricated results.

================================================================================
27. FULL ATTACK-SURFACE INVENTORY
================================================================================

Layer 1: Installed application
- APK extraction, resource modification, repackaging, signing changes.
- Asset modification (UABEA): textures, materials, prefabs, scenes.
- IL2CPP binary patching (native code).
- Local config/PlayerPrefs modification.
- Entitlement check (AppEntitlementCheck, log only, no quit).

Layer 2: Runtime
- Local state manipulation (currency, position, moderator status).
- Memory modification (requires root/debugger).
- Runtime instrumentation (Frida, native hooks).
- Method hooking, dynamic loading.
- Debugger attachment.

Layer 3: Network
- RPC abuse (forged params, floods, ownership violations).
- Custom event abuse (RaiseEvent, cached events).
- Room property manipulation (Master Client).
- Scene sync abuse (AutomaticallySyncScene).
- Session spoofing, replay attacks.

Layer 4: Account and session
- Identity spoofing (Oculus ID without proof).
- Session token theft/replay.
- Ban evasion (client-side kick, new account).
- Duplicate sessions.
- Moderator self-promotion (PlayFab UserData).

Layer 5: Economy and progression
- Currency minting (AddCurrency client-specified amount).
- Cosmetic spoof (Photon props without inventory check).
- Leaderboard faking (client-submitted scores).
- IAP bypass (receipt validation unverified).
- Progression manipulation (level completion, stat updates).

Layer 6: Anti-cheat telemetry
- Heartbeat replay/forgery.
- Client-reported mod signals (untrusted).
- Anomaly records (client-reported).
- Evidence tampering (client can fake telemetry).

Layer 7: Administration
- Dashboard unauthorized access.
- Privilege escalation.
- Webhook abuse (hardcoded URLs in original code).
- Secret exposure (no secrets in client, but PlayFab UserData may be client-writable).

Layer 8: Infrastructure
- Backend outages (fail closed for auth, fail open for gameplay).
- Quota exhaustion (429, fail closed).
- Rate limit bypass.
- Database attacks (parameterized queries prevent SQL injection).
- Secret exposure (env vars, encrypted at rest).

================================================================================
28. THREAT MODEL MATRIX
================================================================================

(See research/ANTI_CHEAT_PREVENTION_DETECTION_MATRIX.md for full 18-row matrix.)

Key threats and defenses (from prior research, verified against project):
1. Modified APK -> Meta entitlement + version enforcement + server-side ban check.
2. Client-trusted currency -> Move grants to server-side (worker/CloudScript). CONDITIONAL.
3. Moderator spoof -> Server-side role verification (PlayFab server data). CONDITIONAL.
4. Ban evasion -> Photon custom auth ban check on connect + KickIfBanned (supplementary).
5. Movement exploits -> Heuristic detection (speed/teleport flags) + manual review. NOT auto-ban.
6. Cosmetic spoof -> Backend inventory verification + flag mismatch.
7. Leaderboard faking -> Server-side score validation or remove from leaderboard.
8. IAP bypass -> PlayFab PurchaseItem validates price server-side + server-side balance check.
9. Tag/Infection spoof -> Rate limit + ownership check + flag non-tagger RPCs.
10. Master client abuse -> Minimize master authority, move room state to backend.
11. RPC flood -> Per-player rate limits + flag.
12. Null crashes -> Guard null refs + server-side crash detection.
13. Duplicate session -> Heartbeat-based detection + kick older.
14. Version spoof -> Title data + custom auth version check.
15. Alt account ban evasion -> Hardware + IP overlap detection.
16. Attestation failure -> Flag + manual review. Do not auto-ban.
17. Frida/injection -> Server-side enforcement limits blast radius. Client detection = low-conf flag.
18. Memory modification -> Server-side validation of all valuable state.

================================================================================
29. CAPACITY, RELIABILITY AND PRICING CALCULATIONS
================================================================================

See section 8 (Backend and database cost correction) for full calculations.

Summary:
- 5-min heartbeat: 288 req/player/day. At 20 CCU = 5,760, 50 CCU = 14,400, 100 CCU = 28,800 (all within 100k free tier).
- D1 writes: 288 writes/player/day. At 100 CCU = 28,800 (within 100k free tier). At 1000 CCU = 288,000 (exceeds).
- Photon is cost bottleneck: $95/12mo for 100 CCU, $95/mo for 500 CCU, $185/mo for 1000 CCU.
- Cloudflare scales cheaply: free tier covers 100 CCU (with 5-min heartbeat).
- Total initial cost: $1-2/mo (domain only). No paid services required.

================================================================================
30. TESTING AND REGRESSION MATRIX
================================================================================

See section 15 (Security test register) for full test list.

All tests are PLANNED, not executed. No fabricated results.

Test categories: Authentication, Authorization, Economy, Multiplayer, Reliability.
Total tests: 32 planned, 0 executed.

False-positive validation scenarios:
- High latency (200ms RTT): movement should not trigger speed flag.
- Packet loss (10%): position jitter should not trigger teleport flag.
- VR movement edge cases: jumping, climbing, bouncing, TP_YA.
- Network jitter: intermittent position spikes should not trigger flags.
- Legitimate moderator access should not trigger flags.

Performance testing:
- Client telemetry < 1ms/frame.
- Backend validation < 50ms p99 at low scale.
- Dashboard load < 2s.
- Load test: k6 at 100/500/1000 concurrent, target p99 < 200ms.

Recovery testing:
- DB restore from backup: verify data integrity.
- Worker restart: verify session continuity.
- Kill switch: disable rule, verify no auto-action.
- Emergency rollback: unban all from specific rule.

================================================================================
31. PRIORITIZED IMPLEMENTATION ROADMAP
================================================================================

Stage 0: Close research gaps (1 week)
- Verify PlayFab UserData "Moderator" writability.
- Verify CloudScript/Azure Functions deployment.
- Verify PlayFab PurchaseItem price validation.
- Verify Meta attestation availability (if possible).
- Verify Photon custom auth configuration.
- Effort: 1 week. Risk: low.

Stage 1: Backend foundation (2-3 weeks)
- Cloudflare worker extensions: /validate-session, /heartbeat, /report-flag, /ban-check.
- D1 database schema.
- Photon custom auth integration.
- PlayFab integration: validate session tickets, check bans.
- Acceptance: Photon connection fails for banned/invalid sessions; heartbeat tracks CCU.

Stage 2: Detection (2-3 weeks)
- Movement telemetry collection.
- Rules S-001, S-002, S-005, S-006, S-008.
- Flag creation with confidence + evidence storage.
- Review queue API.
- Acceptance: flags for synthetic cheats; no false positives on clean sessions.

Stage 3: Dashboard (2-3 weeks)
- Auth (email+password+TOTP), JWT, RBAC.
- Overview, players, flags, bans, audit log pages.
- Ban issue/revoke with Discord webhook.
- Acceptance: owner can log in, view flags, issue ban, ban appears in PlayFab.

Stage 4: Currency/cosmetic protection (1-2 weeks)
- Move currency grants to worker/CloudScript.
- Backend inventory verification for cosmetics.
- Acceptance: client cannot grant itself currency; cosmetic spoof flagged.

Stage 5: Testing & hardening (1-2 weeks)
- Pen test, load test (k6), false-positive regression, backup restore.
- Acceptance: all tests pass, no critical findings.

Stage 6: Controlled rollout (1 week)
- Staging with PCDEBUG (two-editor test).
- Limited QA rollout, monitoring, gradual expansion.

Total: ~9-14 weeks solo, part-time. Depends on Stage 0 findings.

================================================================================
32. FAILURE MODES AND RECOVERY
================================================================================

PlayFab down: fail closed for auth (deny new connections), fail open for gameplay (existing sessions continue), bans still enforced from cache.

Worker down: Photon custom auth fails -> Photon denies connections (fail closed). Existing sessions continue.

D1 down: audit log/flags delayed, core auth still works (worker validates via PlayFab directly).

Photon down: game unplayable (no multiplayer). Single-player not affected.

Owner PC off: dashboard unavailable. Game backend remains online independently.

Quota exhaustion: 429 Too Many Requests. Backend auth fails closed (deny connections). No silent allow-through.

Service degradation: If attestation unavailable, allow with flag (service failure, not user's fault). Do not block.

================================================================================
33. SOURCE RELIABILITY AND UNRESOLVED QUESTIONS
================================================================================

See section 17 (Unresolved questions) for full list of 22 items.

Key unresolved items requiring dashboard access:
1. PlayFab UserData "Moderator" key writability (CRITICAL).
2. CloudScript/Azure Functions deployment status.
3. PlayFab PurchaseItem price validation.
4. PlayFab bans server-side enforcement.
5. Meta attestation availability.
6. Photon custom auth configuration.
7. "Allow anonymous clients" disabled?
8. Dev/prod app IDs separate?

Key unresolved items requiring code inspection:
9. SpokesSigmaIAP receipt validation.
10. GDH leaderboard anti-cheat.
11. ATM_TAB currency flow.

Key unresolved items requiring testing:
12. D1 write throughput (k6 load test).
13. Free tier limits (monitoring post-launch).
14. AppEntitlementCheck intended behavior.
15. Meta User Verification SDK compatibility.

Key unresolved items requiring user decision:
16. Data retention policy preferences.
17. Budget ceiling and solo-dev time availability.
18. Evidence storage needs (telemetry vs screenshots/video).
19. Existing server infrastructure (can it run trusted game logic? No.)
20. Photon PUN 2 maintenance status (LTS/maintenance mode).

================================================================================
34. FINAL FINDINGS AND LIMITATIONS
================================================================================

Key findings:
- ScreechVR has 13 confirmed vulnerabilities (V1-V13) with exact file:line evidence.
- Client-trusted currency, moderator status, ban enforcement, cosmetics, leaderboards.
- No movement validation, no server-side game state authority.
- Master client is a player, not a trusted server.
- Meta attestation docs now accessible (previously 404). Token valid 24h, nonce one-time, timestamp freshness, rate limits 100/hr 200/day.
- Photon pricing verified: free tier 20 CCU (dev only), 100 CCU $95/12mo, 500 CCU $95/mo, 1000 CCU $185/mo. PUN 2 in maintenance/LTS mode.
- Recommended: Cloudflare Workers + D1 + PlayFab + Photon PUN2 (v1), €0 additional spend. Dashboard local-only. No dedicated server for v1.
- Movement exploits can only be detected, not prevented, without dedicated server.
- All tests are planned, not executed. No implementation performed.

Limitations:
- Meta attestation eligibility unverified (docs accessible, but app-specific permissions unknown).
- PlayFab dashboard not inspected (UserData writability, CloudScript, PurchaseItem config, ban enforcement).
- Photon dashboard not inspected (custom auth config, anonymous client setting, dev/prod app IDs).
- No hands-on testing performed (all tests planned, not executed).
- Cost estimates from public pricing pages (verify before committing).
- No peer-reviewed papers accessible in this environment.
- Web search tool returned 404; research relied on direct fetches and local files.

================================================================================
35. REFERENCES
================================================================================

Official documentation:
- Meta Quest Attestation API: https://developers.meta.com/vr/documentation/native/ps-attestation-api/ (ACCESSIBLE 2026-10-29)
- Meta User Verification: https://developers.meta.com/vr/documentation/spatial-sdk/ps-ownership/ (GATED - 404)
- PlayFab login best practices: https://learn.microsoft.com/gaming/playfab/identity/player-identity/login/login-basics-best-practices
- Photon PUN custom authentication: https://doc.photonengine.com/pun/current/connection-and-authentication/authentication/custom-authentication
- Photon PUN host migration: https://doc.photonengine.com/pun/current/gameplay/hostmigration
- Photon pricing: https://www.photonengine.com/realtime/pricing (ACCESSIBLE 2026-10-29)
- Cloudflare Workers pricing: https://developers.cloudflare.com/workers/platform/pricing/
- Cloudflare D1 limits: https://developers.cloudflare.com/d1/platform/limits/
- Cloudflare D1 pricing: https://developers.cloudflare.com/d1/platform/pricing/
- Cloudflare Durable Objects + WebSockets: https://developers.cloudflare.com/durable-objects/best-practices/websockets/
- Nakama authoritative multiplayer: https://heroiclabs.com/docs/nakama/concepts/multiplayer/authoritative/
- Unity upgrade guide: https://docs.unity.com/en-us/engine/7000.0/manual/upgrade-guides/upgrade-guide-unity63
- OWASP MASVS: https://mas.owasp.org/MASVS/
- OWASP API Security Top 10 2023: https://owasp.org/API-Security/editions/2023/en/0x11-t10/
- OWASP Cryptographic Storage Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html

Local research files:
- C:\Users\Void\Downloads\tomahawk stuff\ (all files, read-only)
- libTomahawkCore.so (5.3MB, SHA-256: 150710A0ED22048DDD3B18C49D7837EA60803B67DE768A6160DFF6A96ADD2B85)

Project files:
- E:\! Project Screech\! Screech VR\Screech VR\ (Unity project, read-only during research)

Confidence levels:
- Confirmed: verified against source code or official docs.
- Strong evidence: multiple sources agree, code partially verified.
- Plausible: reasonable inference, not verified.
- Historical: was true in the past, current status unknown.
- Unverified: cannot confirm, needs additional access/testing.

================================================================================
36. FINAL VERIFICATION
================================================================================

File: research/SCREECHVR_SECURITY_RESEARCH_V10_2026-10-29.txt
Size: 50,510 bytes (50,510 characters)
Lines: 954
Sections: 36 (all present)
Ends with: END OF REPORT
Credentials: none reproduced
Implementation performed: none
Production changes: none
Tests executed: none (all planned)
Previous files: untouched

Research coverage checklist:
- [x] Project inspection (Unity project, scripts, scenes, prefabs)
- [x] Threat model (14 threats, prioritized)
- [x] Unity/Quest modding threats (APK, assets, IL2CPP, runtime, network)
- [x] Frida/runtime tampering (detection limitations, false positives)
- [x] Device integrity/attestation (Meta API, unverified eligibility)
- [x] Anti-RE/anti-tamper (IL2CPP, version enforcement, server-side)
- [x] Trust boundaries (client untrusted, backend trusted)
- [x] Network abuse/gameplay validation (movement, RPCs, ownership)
- [x] Detection engine (risk scoring, graduated response)
- [x] Bans/moderation/appeals (PlayFab bans, graduated enforcement)
- [x] Owner dashboard (pages, auth, security, test plan)
- [x] Backend architecture (Cloudflare + D1 + PlayFab + Photon)
- [x] Tool security (Ghidra, Rizin approved; 8 not reviewed)
- [x] Dependency/supply chain (packages, obfuscator, ParrelSync)
- [x] Build/release security (IL2CPP, version enforcement, IP whitelist)
- [x] Privacy/data retention (minimization, retention periods, access control)
- [x] Incident response/monitoring (alerts, kill switch, procedures)
- [x] Security test plan (auth, authz, economy, multiplayer, reliability)
- [x] Costs/scalability/operations (free tier, paid scenarios, bottlenecks)
- [x] Architecture options/recommendation (3 options, Option 1 recommended)
- [x] Implementation roadmap (6 stages, 9-14 weeks)
- [x] Open questions/risks (22 items)
- [x] Deferred tasks (12 items)
- [x] Research log (chronological)
- [x] Decisions/assumptions (10 decisions, 8 assumptions)
- [x] Final summary (executive summary, key findings, architecture, risks)
- [x] Tomahawk research (public site + local files + Ghidra binary)
- [x] Critical review (Ghidra audit, Meta attestation, Photon, costs, MVP, checklist)
- [x] Consolidated ScreechVR architecture (vulnerabilities, architecture, MVP, decisions)
- [x] Quest modification threat catalog (exhaustive, 14 categories)
- [x] Ghidra binary analysis (libTomahawkCore.so, 35.1-35.11)
- [x] Multi-layer zero-trust architecture (13 layers, common-mode failures)
- [x] Free-tier cost model (verified pricing, workload calculations)
- [x] Source register (official docs, local files, confidence levels)
- [x] Corrections index (10 corrections documented)

Unresolved (requires dashboard access or testing):
- PlayFab UserData "Moderator" writability
- CloudScript deployment status
- PlayFab PurchaseItem price validation
- Meta attestation eligibility
- Photon custom auth configuration
- D1 write throughput
- Free tier limits
- SpokesSigmaIAP receipt validation
- GDH leaderboard anti-cheat
- ATM_TAB currency flow
- AppEntitlementCheck intended behavior
- Meta User Verification SDK compatibility

================================================================================
END OF REPORT
================================================================================