1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
SCREECHVR VOIDERATION ANTI-CHEAT ARCHITECTURE PLAN V14
Date: 2026-10-30
Status: Research and planning only. No implementation or production changes.
Source bundle: https://pste.us/raw/PPmg0Gvt
Prior V13 remains untouched. V08 is a draft, not verified as deployed.
EXECUTIVE SUMMARY
This plan prioritizes server-enforced identity and economy boundaries, Photon
authentication, gameplay abuse reduction, and measured moderation. ScreechVR
uses Unity/Photon PUN, PlayFab, Meta SDK, and a Cloudflare Worker; it has no
dedicated authoritative game server. Consequently, client-side movement and
gameplay checks cannot be treated as proof. Weak or client-reported signals
must never cause an automatic ban.
Evidence scope: the local project and selected source files were checked against
the published bundle. The 82-file bundle was not independently audited file by
file. Claims below distinguish checked source from configuration-dependent
questions.
CONFIRMED SOURCE FINDINGS
1. Identity: Oculus_Login uses LoginWithCustomID, with CreateAccount enabled,
and does not verify the claimed Oculus ID with a server-side proof
(Oculus_Login.cs:164-175). This does not establish whether a particular
exploit is usable in production.
2. Photon auth: PhotonVRManager.ConnectAuthenticated supplies the PlayFab
Photon token, while Connect() clears AuthValues and connects without them
(PhotonVRManager.cs:181-224). Whether anonymous connections are accepted is
dashboard-dependent.
3. Currency: Oculus_Login calls AddUserVirtualCurrency with a client-provided
amount and optimistically updates the local balance (Oculus_Login.cs:269-301).
The impact depends on PlayFab title/API permissions and deployed backend.
4. Moderator: client code reads/writes UserData key Moderator and defaults it
to FALSE (Oculus_Login.cs:373-428). Self-promotion impact depends on deployed
permissions and any server-side checks.
5. IAP: SpokesSigmaIAP treats local Oculus checkout success as a grant signal;
OWNED_IAP dedupe uses client UserData, and optional gold goes through the
client currency method (SpokesSigmaIAP.cs:59-97, 122-155, 197-214). Server
receipt validation and actual product configuration remain unverified.
6. Tag RPCs: TagManager invokes RPC_Infect, RPC_Cure, and RPC_SetTagger to All;
handlers update client state. Do not assert self-tag is conclusively exploitable
without validating sender, target PhotonView, and runtime call paths.
7. Worker /updateplayers returns {ok:true, ignored:true} at worker.js:457-459.
It ignores input; this is not evidence of a player-count injection flaw.
8. V08 draft ServerGrantCurrency checks amount/reason and caps amount, but has
no authorization check in the handler (V08:515-540). OnPurchaseItem uses
args.Price and has catalog lookup TODOs (V08:302-380). ReportPlayer trusts
Args.ReporterId for its mod allowlist and contains a hardcoded webhook
(V08:382-410). These are draft-source findings only, not claims about a
deployed revision. V08 explicitly says DRAFT - NOT DEPLOYED.
9. V08 Heartbeat uses client sequence/timestamp checks; it has no implemented
server-issued challenge validation (V08:447-506). No Worker heartbeat route
is registered in worker.js:617-629.
RISKS AND OPEN QUESTIONS
- PlayFab client API permissions for currency and UserData; deployed CloudScript/
Functions and their caller restrictions; catalog configuration and live code.
- Photon anonymous-auth and custom-auth dashboard settings, app IDs, and whether
production actually reaches the unauthenticated Connect() fallback.
- Meta User Verification availability/SDK compatibility and server validation.
- IAP receipt validation, GDH leaderboard validation, and ATM currency paths.
- A PUN Cloud client/master is not an authoritative server. Movement, RPC,
scene, and room properties remain client-influenced absent server authority.
- Do not claim that every bundle file or all Photon RPCs were exhaustively audited.
TARGET ARCHITECTURE
Identity and session:
- Bind PlayFab identity to verified Meta proof where supported; use one-time
nonce, server verification, replay protection, and explicit unavailable state.
- Authenticate Photon through a backend that validates the PlayFab session
ticket and ban state. Remove anonymous fallback from production; keep any
development bypass isolated to development credentials/builds.
- Fail closed for authorization decisions, but degrade gracefully for temporary
service outages rather than falsely banning or corrupting player data.
Permissions and economy:
- Move moderator authority to server-only data/roles. Never accept a client
Moderator flag, ReporterId, price, grant amount, or role claim as authority.
- Make grants backend-only with authenticated operator/action authorization,
bounded amounts, reason codes, idempotency keys, audit log, and returned
authoritative balance. Remove optimistic balance as the source of truth.
- Purchases must use server-side catalog price and provider receipt validation,
idempotency, and duplicate/rollback handling. Preserve existing products and
flows through migration tests.
- Validate progression and cosmetic ownership server-side where feasible;
client UI checks are not security controls.
Photon/gameplay:
- Inventory every RPC/event and validate sender, ownership, target, parameters,
rate, and legal state transitions. Use PhotonMessageInfo.Sender for sender
identity; do not treat client photonView.IsMine as authoritative proof.
- Fix known event floods (buffered per-frame thruster updates; held-button
flashlight calls) with state/edge replication, unbuffered updates where safe,
and per-actor rate limits. Preserve legitimate gameplay and test all modes.
- PUN Cloud cannot securely validate movement or gameplay outcomes. Use telemetry
only for anomaly review unless an authoritative server is introduced.
Worker, evidence, and review:
- Keep existing /updateplayers behavior documented or remove it; it currently
ignores input. Add authentication, schema validation, replay protection, and
rate limits to any future state-changing route.
- Store minimal session/flag evidence with retention limits and access controls.
Redact secrets; move webhook credentials to secret storage and rotate if exposed.
- Detection produces review flags with source, timestamp, confidence, and
supporting samples. Human review is required for bans. Integrity-token failure,
movement anomalies, or client reports alone are not ban proof.
- Keep immutable audit events for moderator actions and provide an appeal/revoke
process. Do not introduce a public dashboard without an explicit security plan.
HEARTBEAT (PROPOSED, NOT IMPLEMENTED)
If session liveness is needed, have an authenticated backend issue a random,
short-lived, one-use nonce and track monotonic sequence/session identity. Verify
nonce consumption server-side, apply per-session rate limits, tolerate missed
requests and connectivity outages, and mark stale rather than auto-ban. A client
HMAC key derived from a client-held/session ticket is not automatically secret
from a modified client; heartbeat proves liveness/protocol compliance, not game
integrity. Size storage and cost from actual expected concurrency and current
Cloudflare plan limits before implementation.
IMPLEMENTATION PHASES (PROPOSED)
0. Read-only verification: confirm live PlayFab/Photon settings, deployed
revisions, IAP/leaderboard/currency callers, and test/dev separation.
1. Economy/permission safety: server-authorized currency/moderation; server-side
purchase pricing and receipt validation; migrate and regression-test existing
users/items before disabling old paths.
2. Identity/connection: verified identity where supported; validated Photon
custom auth and ban check; remove production anonymous fallback only after
staging proves compatibility.
3. Photon abuse reduction: RPC inventory, sender/state/rate checks; repair floods;
test voice, rooms, PVP, Tag/Infection, hub, and all horror levels.
4. Evidence/review: minimal telemetry, privacy/retention policy, review queue,
audit trail, false-positive review, appeal and rollback procedures.
5. Optional integrity/heartbeat: only after vendor eligibility, costs, outages,
nonces, retention, and failure modes are verified.
TEST / RELEASE GATES
- Staging tests: login and recovery; authenticated and rejected Photon sessions;
banned/revoked account; currency grant authorization; forged moderator;
duplicate/incorrect-price purchase; invalid receipt; replayed nonce; rate limit.
- Gameplay regression: cosmetics, voice, rooms, tag/infection, PVP, hub, all
seven horror levels, /link, MOTD, CCU, and existing IAP entitlements.
- Security tests must use test accounts/title only. Compare balances and inventory
server-side. Verify no credentials are logged or included in client builds.
- Roll out gradually with monitoring and a tested rollback. Do not deploy or
change dashboard settings as part of this research plan.
DECISIONS REQUIRED BEFORE IMPLEMENTATION
1. Confirm live PlayFab permissions and deployed server code.
2. Confirm Photon custom/anonymous auth configuration and production call paths.
3. Decide whether Meta proof is a requirement or optional signal.
4. Decide evidence retention, human-review ownership, appeals, and privacy scope.
5. Decide whether PUN's client-authoritative limits are acceptable or whether a
dedicated authoritative game server is justified.
6. Verify cost/limits against current provider plans; prior draft cost estimates
are not validated and must not be treated as commitments.
SCOPE / INTEGRITY
Research only. No code, revisions, settings, or production services changed.
Previous plans remain untouched. V08 is a draft. The preceding plan draft's
unsupported claims (including blanket assertions about PlayFab price validation,
all RPC ownership gaps, exact costs, and exhaustive bundle review) are not
carried forward as verified facts.
END OF REPORT
|
Pastebin