Radicade/docs/QUEST-20230907-TEST.md

Quest 20230907 server test

Current investigation: post-login doll and saved-account fallback (2026-10-07)

After the user supplied a valid birthday, login proceeded further. At 19:18:22 client emitted fatal quit 1550502249 after a Hile report; VPS message was 33489407,7. Exact September disassembly locates the comma-pair formatter in HGEONHBDDLK.PLGOEDKHHBI (0x4f91ffc), gated by AntiHile.QD, reporting type 701. Live config verified that key=true. GameConfigAPI now overrides only that key=false; two focused tests pass for seeded true and missing-key cases, including preservation of unrelated values and stored data. Default Debug test build hit a locked DLL; isolated QuestConfigTest build passed. Commit 04826ca pushed to origin/2023 after cherry-picking the tested local 0b7894b onto remote 2a2df52 in artifacts/quest-config-integration. Primary dirty workspace preserved. VPS deployment and gameplay retest pending. Separate crm/me/config exception observed; not established as the cause of this shutdown.

FreshHTTP test at 19:07 passed the formerly failing current-saves response, outfits, and image verification (placeholder acceptance logged 19:07:54.993). No fatal quit or hex parsing error appeared through 19:09; heartbeats continued. Unity explicitly logged Junior: False at 19:07:38.968 but meta junior login error at 19:07:50.632. User screenshot confirms false database flags, JuniorState=0, and an unset birthday (year 0001). BuildSelfAccount recalculates juniorState=PendingOverride (2) when birthday is absent/year<=1900 regardless of stored zero. Client TitleScreenFlowModel.EJKBHHGALEH -> HBGNIICMAMG -> BKJMLBBNEFL.FBOEAHDMPJF checks the self-account state at +0xa8 for 2 before falling back to its Junior boolean, then checks Meta hardware. This supports incomplete birthday onboarding as the remaining restriction, not an actual true Junior flag. No birthday, Junior flag, or restriction check has been modified.

ImageCompat login at 19:02:38 authenticated successfully (token 200 and self-account 200), but failed before image loading. At 19:02:42.494 the custom-avatar-current-saves response began (200) without a matching chunk end. At 19:02:42.635 Unity reported Can't parse '' as a hex number!; manual login returned doll at 19:02:43.596. A later matchmaking heartbeat hit the same parsing error. No image-placeholder acceptance or fatal-quit event occurred during this attempt, so the image fix remains unverified. Filtered capture: image-compat-events.log.

FreshHTTP.apk is a one-variable transport experiment on top of ImageCompat: HTTPManager.SendRequest sets IsKeepAlive=false via its runtime setter only for https://ns.radicade.app/ requests. This tests connection reuse as a cause; it does not establish the root cause or suppress parser errors. TLS and response validation are unchanged. Native compilation and APK signature verification passed. Device login test pending.

ImageKey test at 18:52 confirmed the request hint reached the VPS and changed the failure from Signature malformed to Signature verification failed. Headset log image-key-events.log records this failure followed by fatal quit code 1550502249. User supplied matching VPS reports. The server's SignatureData is a fixed 256-byte placeholder, not a signature of the returned image.

Built, apksigner-verified, and installed ImageCompat.apk in place, preserving data. Exact-build image verifier HFFEEGBKKFK.DGDJIHJHHBN at RVA 0x6deb934 is reached after header/key-id parsing. The hook recognizes only the exact server placeholder byte array and accepts it in this image-only path; all other signatures call the original verifier. This intentionally relaxes image authenticity checking for that placeholder, does not provide cryptographic image authentication, and does not alter TLS certificate validation or fatal-quit behavior. Source: tools/quest-http-inspect.c and tools/quest-image-placeholder.h. Prologue verified against original ELF and compilation passed -Wall -Wextra -Werror. First alignment attempt failed in sandbox; elevated alignment succeeded. Login outcome pending. No server update required for this test.

Confirmed next trigger from user-provided VPS reports: two Obcured reports say Signature malformed for the same image URL with sig=p1. QuitInspect captured two fatal quits with code 1550502249 and a delegate-invocation caller; shutdown's SpeedHackDetector exception follows them. Live /images/{name} returned key-id KEY:RSA:p1.rec.net, whereas patched Quest metadata expects .radicade.internal. This is an image-signature key-ID mismatch, not proof of a Junior account restriction or TLS certificate-pin failure. Existing PC ImageSignatureRequest.AddKeyId already solves that header selection mismatch with rcsig.

Built, verified and installed ImageKey.apk in place. Added an exact-prologue-checked HTTPManager.SendRequest hook (RVA 0x688e200) that adds the expected rcsig only to https://ns.radicade.app/images/ requests, preserves resize/signature query parameters, and uses the IL2CPP write barrier when replacing the URI. Existing hinted/fragment URLs are left unchanged. Original TLS and RSA verification remain active; the hook activates after the diagnostic 30-second delay. A live request with that parameter returned HTTP 200 and the correct .radicade.internal key ID. Headset acceptance remains pending; the server still supplies static signature bytes, so successful signature cryptographic verification is not established. Capture: artifacts/quest-tls-diagnostic/image-key-events.log.

After deployment, PID 21799 received /outfits/me HTTP 200 at 14:21:37 and progressed to version check and additional startup requests. The user saw “Account not supported” before exit. Two /api/PlayerReporting/v1/hile requests preceded exit; Android recorded signal 9 after the activity stopped at 14:21:48. A public account-2 probe returned isJunior=false, which does not establish private self-account state. The client's SessionManager message table maps error 83 to the Meta Junior restriction text, but the triggering code has not yet been captured.

At the user's request, inspected https://github.com/recflare/quest at 43efb7b9f46a335e978af5520979d8a4d65e81f2 in artifacts/recflare-quest-reference. It targets April 2023, not this September build. Its certificate-pinning and fatal-quit diagnostics suggest a separate post-TLS integrity check worth testing; they do not establish our cause. No repository build scripts or bypass hooks were run. Added an independently implemented exact-prologue-checked trace at this client's SessionManager.FatalApplicationQuit RVA 0x3a1c0b4, logging code/caller/reason length only and preserving behavior. Signed/verified QuitInspect.apk installed in place. Activation is not yet confirmed because the app exited before diagnostic output; user asked to keep headset awake at the password page. No new server changes or account edits made.

The user reported the VPS updated after a808239. An unauthenticated live check of /outfits/me now returns 401 instead of 404, consistent with the new protected route being deployed. Reopened HttpInspect-v3 on the connected Quest as PID 21799; filtered capture is artifacts/quest-tls-diagnostic/http-after-outfit-deploy.log. Authenticated response/client acceptance is still pending a manual login.

Server fix committed and pushed to origin/2023 as a808239: authenticated GET /outfits/me now wraps the existing account avatar in the September current-outfit DTO. Exact-client metadata resolved the request state machine MOEENPJECCH returning FMLIPOPOKDJ; generated formatter JOJEHOPNNIN defines DataVersion, LegacyData, CustomizationSettings, Selections, Slot, Name, Accessibility and ThumbnailFileName. Legacy formatter DEAAHJJLAAE defines SelectionsV1, SelectionsV2, FaceFeatures, SkinColor and HairColor. The initial adapter uses version 0 legacy data, current slot 0 and an empty modern selections list. Client acceptance of the response remains pending VPS deployment and a headset test. All three QuestOutfitsTests passed, covering account isolation, auth rejection, JSON shape and missing-avatar initialization.

Later capture at 14:04:24–26 reproduced empty chunk-length errors on /datacollection/data/event and /matchmaking/player/heartbeat, after the 14:02:29 login failure. The intermittent transport issue is therefore not proven fixed. Avatar descriptor warnings also remain unresolved. The field inspector now supports secondary Android users (active user 10) and records RecNet interface fields as well as runtime fields; it reads type metadata only.

HttpInspect-v3 captured a complete manual login attempt at 14:02:21–29. Password token, account/me and matchmaking login all returned HTTP 200. Every observed chunked response completed, including the avatar catalog. /outfits/me returned HTTP 404 at 14:02:24; the client reported AMIIDJOEAMH: HTTP Error 404 and manual-login doll at 14:02:29. This attempt did not reproduce the earlier empty chunk-length parse error. The client also logged invalid legacy avatar-item descriptors, a separate compatibility concern. The missing outfit route is the current concrete server lead; its response contract is being inspected before implementation.

Follow-up: the user confirmed the password page but signing in exited PID 14518 with signal 11 at 13:57:06. The v2 diagnostic was unsafe: optimized call sites for ReadChunkLength do not preserve its unused receiver argument, so interpreting that argument as an HTTPResponse can dereference invalid memory. Do not reuse HttpInspect or HttpInspect-v2. Updated the hook to ReadChunked (RVA 0x6d941e0), whose receiver is actually consumed, and verified its four copied prologue instructions against the original binary. Built and signature-verified HttpInspect-v3.apk, installed in place, and launched PID 16445. This corrects the identified diagnostic defect; the original post-login doll issue remains unresolved pending a captured attempt. Filtered continuous capture is saved locally in artifacts/quest-tls-diagnostic/http-v3-events.log.

The user successfully interacted with the v3 password form using Touch controllers. Supplied server logs show the headset password grant accepted, followed by authenticated account and matchmaking requests. Password authentication itself succeeded; gameplay has not been reached. At 01:26:07 the client reported doll with BestHTTP ReadChunkLength failing to parse an empty string as hexadecimal. Successful server request logs do not identify which response failed in the client.

Added tools/quest-http-inspect.c, an exact-prologue-checked experimental native hook that logs HTTP chunk reads using response identity, status and URL path only. It does not log passwords, authorization headers, query strings or response bodies. The diagnostic activates after 30 seconds; this timing remains a diagnostic workaround.

A subsequent saved-account auto-login followed TitleScreenFlowModel.MNKODPJLNDD, a different error callback from the initial cached-login path, and showed error 3 before exit. The client patch now redirects that callback at RVA 0x39c67e0 to the existing password page (GoToLogin, 0x39bbd80) as well. Server cached-login rejection remains intact.

Built, signed, verified and installed artifacts/quest-tls-diagnostic/HttpInspect-v2.apk as an in-place update to com.radicade.questtls. No uninstall or data clearing occurred. Quest PID 14518 logged cached-login error 3 at 13:55:58, then activated the chunk diagnostic at 13:56:11 and remained running. Visual confirmation of the password fallback and a fresh manual login with the diagnostic active are pending. No additional server change or deployment was made for this diagnostic.

v3 controller dispatch test (2026-10-07)

The user confirmed v2 displays the password form but physical Touch controllers do not interact, although they work in the Meta menu. Static analysis resolved InputManager.FMJDLCGGGKP's virtual call at 0x460a254 as CurrentPlatform (same vtable slot used by get_CurrentPlatformIsOculusType). Its dispatch table at RVA 0xc35a550 maps Standalone=7 to return no VR input (0x460a2b0). Oculus=1 dispatches to 0x460a2c0, which selects the existing Quest input handler for hardware type 5.

The v3 script changes only that table entry in addition to v2 changes. It preserves password-based platform-7 server authentication and selects Oculus input using the original hardware check. Installed signed StandaloneLogin-v3.apk in the separate diagnostic package without uninstalling. Patched IL2CPP SHA-256 is 1a646b3c85ecf8101e7c131cd87012ab6a9764d01685addee03d2251a811243b. Signature verification passed; controller interaction and end-to-end password login require headset testing. No additional server changes were made.

v2 prototype reaches password page (2026-10-07)

Server commit 835534b was pushed to origin/2023 and the user deployed it. A credential-free live probe returned the specific standalone password-required response, confirming the new guard is active. Those two deployment-probe cached-login 401s were not headset password attempts.

The expanded read-only inspector saved artifacts/quest-tls-diagnostic/quest-method-map.tsv. Runtime method names resolve the Quest-specific original initialization call at 0x3d09f14 to RecRoom.LocalPlayerController.SetVRDisplayMode; v1 skipped it. The v2 patch preserves original initialization through that call, then invokes standalone account initialization with the original stack frame correctly restored. It also redirects TitleScreenFlowModel.DALDIFKKDDA to its existing GoToLogin method. This error redirect is currently broad (all title-screen errors), so this remains an experimental build.

Installed StandaloneLogin-v2.apk into com.radicade.questtls without uninstalling. PID 15954 reported Standalone/OculusQuest, received the expected cached-login 401, and stayed running. An ADB screenshot visually confirmed the username/password page, rather than the error screen. Controller interaction and successful password authentication remain pending user testing. No password was supplied or logged. The original-package TLS-fixed APK and both OBBs remain available. Signature verification, ARM64 stub disassembly, 16 KiB alignment, and Python syntax checks passed.

Independent-login prototype: not playable; rolled back (2026-10-07)

Added local server support for wire platform 7 (Standalone) with password-only login. It clears caller-supplied account identity before resolving the username, generates a local radicade-quest: device namespace, ignores bearer headers for this password grant, rejects cached-login/refresh/signup grants, and suppresses unauthenticated standalone cached-account discovery. Existing whitelist and anti-cheat checks remain active. These are experimental server changes, not deployed or pushed. Refresh and new-account onboarding are not implemented; an existing Radicade account with a password is required. With whitelist enabled, the derived local identity must currently be explicitly allowed.

All 26 AuthOnboardingFlowTests passed, including five standalone cases covering correct/incorrect passwords, correct token identity, hidden cached accounts, and rejection of device-only cached/refresh/signup requests.

tools/patch-quest-standalone-login.py reproduces a failed client experiment: three exact-build checked branches redirect Oculus initialization/auth parameters/platform enum to existing standalone implementations. Only 12 bytes in libil2cpp.so differ from the TLS-fixed clone. The signed APK artifacts/quest-tls-diagnostic/StandaloneLogin.apk passed v2/v3 verification and 16 KiB alignment. On Quest (PID 12596), it passed platform initialization and logged Platform: Standalone, Hardware: OculusQuest, but then attempted cached login, received HTTP 401, and displayed error code 3. The user reported no usable hands. A screenshot confirmed the error screen; the cause of missing interaction is not established. This is NOT a working Quest login implementation, and the initialization replacement must not be promoted to a release.

Restored RadicadeQuest-ScopedTLS-Test.apk over the separate diagnostic package without uninstalling (ADB Success), then launched the unchanged original-package TLS-fixed app. Both OBBs and private data were retained. Before another client test, trace Quest input initialization and the title-screen transition to password login separately; do not simply replace the full initialization method again. The user reports deploying by pushing Git and gives C:\radicade-server as the server folder. No deployment workflow was found in this checkout; production update/restart mechanics are not yet verified.

Latest result: TLS fixed; Meta account initialization remains blocked (2026-10-07)

The currently installed original-package APK is artifacts/quest-tls-diagnostic/RecRoomQuest-ScopedTLS-Test.apk, SHA-256 064fbf29f4c3340abf45863664fd84af1404a74b46c64fa08d733f40654bdffa. It retains package com.AgainstGravity.RecRoom, versionCode 2378787, and the original patched metadata. The only changed APK payload is lib/arm64-v8a/libunity.so; signing metadata also changes. The user explicitly approved replacing the previous differently signed test app and its resulting private-data deletion. The OBB was restored and its SHA-256 again matched ef856a56bfe1667f00435c2b07fb465766196c02bac8b220c7cc36db926998fc.

Native instrumentation found that platform-root X509 validation of ns.radicade.app succeeded (result=0, raw_flags=0, unity_flags=0), but the configured managed verification callback subsequently returned 0x8. This demonstrates an additional client-side rejection; its managed implementation/pinning policy has not been identified. Changing server TLS versions or certificate issuers did not address it.

tools/diagnose-quest-tls.py --radicade-system-trust routes only the exact hostname ns.radicade.app through Unity's existing default verifier (including platform CA chain and hostname validation), preserving the configured callback for all other hosts. It does not return unconditional verification success. The script accepts only the exact known Unity library SHA-256, uses checked empty RX-segment padding, and preserves existing native instructions outside the three hook sites and RX segment length fields. Without that option it only adds diagnostic logging. The native library SHA-256 for the scoped variant is 37c5709cca6b5dff019e16685a819d50d064d3a4c19f45d642cb5383011e23d7.

Both the separate diagnostic package (com.radicade.questtls) and the original-package scoped build passed TLS and loaded game configuration. The original-package run (PID 6353) remained running past the former exit point, but logged GetLoggedInUser failed: The user isn't signed in or their account state wasn't in a recoverable state. (2|-1), followed by Unable to load Oculus user account. Meta's platform logs also show OBTAIN_TOKEN_3P failing with HTTP 400 for this package. No account proof, platform identity, entitlement result, or server authentication policy was forged or changed. Gameplay/login is not yet working.

The original signing password was unavailable. The new local diagnostic signing key and password file are in artifacts/quest-tls-diagnostic/diagnostic.p12 and diagnostic.password, excluded by that directory's .gitignore; retain these for non-destructive future updates. A separate diagnostic app and its OBB remain installed. Signed v2/v3 verification, 16 KiB alignment, original-package payload comparison, checked ARM64 disassembly, and on-device positive TLS tests passed. Rejection-path behavior has not yet been independently exercised with an invalid server certificate.

The VPS currently serves ZeroSSL and has Caddy debug enabled. It is running in the user's foreground PowerShell window. The older sections below describe the investigation history, not the current installed build.

Platform integration investigation (2026-10-07)

Added tools/quest-platform-inspect.c, a read-only JNI diagnostic which enumerates selected runtime class methods and field offsets without reading account values or invoking authentication methods. Installed it only in the separate com.radicade.questtls diagnostic app as artifacts/quest-tls-diagnostic/PlatformInspect.apk. The original-package TLS-fixed APK and both OBBs were retained. The first inspector run raced Unity initialization and aborted; delaying inspection by 30 seconds allowed the second run (PID 10871) to complete. This delay is a diagnostic workaround, not a general initialization synchronization guarantee.

The complete successful method inventory is artifacts/quest-tls-diagnostic/platform-methods.txt; selected ARM64 disassembly is platform-disassembly.txt. Confirmed actual Quest RVAs: OculusPlatformManager.Initialize = 0x3d09d8c, OculusPlatformManager.GetAuthParams = 0x3d0a930, StandalonePlatformManager.Initialize = 0x43d6f0c, and PlatformManager.GetAuthParams = 0x396ad48. The standalone manager exists in the Android build; its platform getter returns enum value 7 and its PC-platform getter returns true. Therefore simply swapping the entire manager would change device behavior and is not yet a validated Quest integration. The server's current Platforms enum does not define value 7. No platform methods or server authentication behavior were changed by this diagnostic.

Next implementation work must preserve Quest hardware behavior and add authenticated Radicade account credentials/session validation before enabling an independent login path. The existing server device-code implementation auto-approves a configured Studio account; it must not be reused as Quest account authorization. A successful metadata inspection does not establish gameplay compatibility or successful login.

Confirmed remaining Meta failure

The user confirmed their Meta profile and other online apps work. Correlated platform logs for the original-package fixed build show https://graph.oculus.com/authenticate_application returning HTTP 400, OAuth error code 27, subcode 1891543, title Unofficial Application. The response explicitly identifies the app as modified and disables platform functionality. This is an app-authorization rejection, not evidence that the user's headset account needs resetting. Changing Caddy or reinstalling the same modified APK cannot supply the original publisher's signing identity. Remaining work requires a separately designed Radicade sign-in integration (for example, server-validated account login/device pairing or an appropriately registered Meta app), preserving account authentication rather than fabricating a Meta user/proof or accepting arbitrary platform IDs.

The supplied folder is an apktool-decoded Android package plus an OBB asset tree. Its APK manifest is com.AgainstGravity.RecRoom, Quest/Quest 2 6DoF, ARM64, and the loaded Unity version literal is 20230907 (not the desktop 20230831 build).

What is ready

tools/patch-quest-client-metadata.py recognizes this exact Quest metadata layout, resolves its live IL2CPP string-literal table, and redirects its bootstrap/auth/site/image URLs to https://ns.radicade.app. It keeps the image-signature tail .radicade.internal. It is dry-run by default, verifies the rebuilt table against every original literal, writes a .orig backup and a patch marker only with --apply, and refuses unknown/mismatched builds.

From the repository root, first preview the changes:

python tools/patch-quest-client-metadata.py 'C:\RecRoom\RecRoom-Quest-20230907' --server https://ns.radicade.app

The image rule targets the server's signed /images/img/{name} route; the domain's /images/avatar/ is not the image endpoint and returns a large generic response. The account's GET / nameserver advertises all other service URLs under the same server.

Earlier state: NSC test APK installed and launched on Quest 3

The Quest 3 is connected via ADB. The local test-signed build was installed after uninstalling the prior test-signed package (the original Store app had already been removed earlier). The app was launched as a VR activity on-device; Unity initialized the OpenXR/Oculus runtime and reached Connecting to RecNet. Its TLS request still fails with Mono.Security.Interface.TlsException: Handshake failed - error code: UNITYTLS_INTERNAL_ERROR, verify result: 4294957312, then the RecNet nameserver query reports summer and the app exits around 17 seconds after start.

A second APK variant adds the official Let’s Encrypt Root YR cross-signed-by-ISRG-Root-X1 certificate as a raw resource and trusts it only for ns.radicade.app, while retaining Android system trust and disallowing cleartext. It was aligned for 16 KiB pages and signed with a separate local test key; Apktool build, apksigner v2/v3 verification, zipalign, package/version/ARM64 checks and inspection of the packaged NSC all passed. Installing it required uninstalling the previous local test package because its signing certificate differed; the user's consent was obtained. The matching OBB was restored from the PC copy and SHA-256 verified identical (ef856a56bfe1667f00435c2b07fb465766196c02bac8b220c7cc36db926998fc). This certificate-resource experiment did not change the TLS error or startup exit.

The currently installed APK is C:\\Users\\user\\Downloads\\RadicadeQuest20230907\\RecRoomQuest-radicade-nsc-test.apk (package com.AgainstGravity.RecRoom, version 20230907, versionCode 2378787). Its narrow Android trust config is apk/res/xml/network_sec_config.xml, and the cross-signed CA resource is apk/res/raw/isrg_root_yr_by_x1.pem. This test shows that adding an Android Network Security Config trust anchor does not fix this Unity MobileAuthenticatedStream TLS handshake, so do not keep changing Android trust settings or weaken TLS validation; investigate the TLS chain/protocol at UnityTLS or server-side and keep certificate validation enabled.

The headset OBB at /sdcard/Android/obb/com.AgainstGravity.RecRoom/main.2378787.com.AgainstGravity.RecRoom.obb is present and hash-matches the local build. Uninstalling the test app removed the on-headset OBB directory, so the local copy was pushed back and verified after install.

Earlier APK/OBB build notes

The pre-existing working tree had a decoded Quest APK (apk/) and separately decoded OBB asset tree (obb/), not the original archives or publisher signing key. The untouched source under C:\\Users\\user\\Downloads\\RecRoom-Quest-20230907 was not modified. A separate working copy under C:\\Users\\user\\Downloads\\RadicadeQuest20230907 has the metadata patch applied; Apktool 3.0.3 built its APK, which was page-aligned and signed with local-only debug keys. Package, version, min SDK 25, target SDK 32 and ARM64 native code were validated. A new tools/package-quest-obb.py validated all 22,199 OBB entries and built the matching expansion-file name (1,394,848,868 bytes); the on-headset copy now has a verified matching hash. Android platform-tools 37.0.1, build-tools 36.1.0 and Apktool were downloaded into %LOCALAPPDATA%\\Radicade\\QuestToolchain.

The remaining significant functional blocker is identity: this APK is built for Oculus/Meta and its IL2CPP metadata contains Oculus Platform APIs (GetUserProof/GetLoggedInUser-related flows), but the server currently only verifies Steam tickets when platform == Steam. Account creation also accepts only platform IDs prefixed 75 or 76, and the existing allowlist is named/configured as a Steam ID list. The server version-check route currently allows all versions, but 20230907 is not in DBConfig.SupportedGameVersions; this does not prove the rest of the server protocol works. The endpoint patch does not add Meta identity verification, change server authentication policy, or port the Windows BepInEx/Harmony plugin to Android.

The metadata patch remains reproducible with the dry-run command above. The current test APK and matching expansion file are installed and have been run on the Quest 3; the app still exits after UnityTLS handshake failure during nameserver discovery. New Meta account onboarding is not supported/verified; existing linked-user login is unknown.

Safe next steps

1. Keep this test APK/OBB and current headset install available for controlled TLS investigation. Do not uninstall/reinstall again without a reason: that deletes app-private data and Android also removes the OBB directory.
2. Investigate the failure within Unity's MobileAuthenticatedStream/UnityTLS against the exact chain served by Caddy (leaf ns.radicade.app → YR1 → Root YR cross-signed by ISRG Root X1). Do not disable certificate or hostname validation; the domain-scoped Android NSC root addition had no effect.
3. If the TLS request succeeds, resolve and test Meta/Oculus identity support with the Radicade server before attempting account creation. Do not weaken authentication based on an assumed Oculus ID shape.

TLS 1.2-only test (2026-10-06 Pacific)

The user identified the server as a netcup Windows VPS, running C:\Caddy\caddy.exe v2.11.4 with C:\Caddy\Caddyfile. The live Radicade site already used key_type rsa2048. The user added protocols tls1.2 tls1.2. Reload initially failed because Caddy was no longer running; the user started it in a foreground PowerShell window.

External OpenSSL checks confirmed that TLS 1.2 succeeded with certificate verification OK and TLS 1.3 was rejected with protocol-version alert 70. A fresh launch of the existing Quest APK (PID 29072) still produced UNITYTLS_INTERNAL_ERROR, verify result 4294957312, followed by nameserver error summer and OnApplicationQuit at approximately 15.2 seconds. The process was absent afterward. TLS 1.2-only did not resolve startup; certificate-chain compatibility remains unproven. No APK reinstall or OBB change was performed. The temporary TLS restriction should be reverted on the VPS; rollback has not yet been confirmed. Caddy currently depends on the user's foreground PowerShell process remaining running.

Rollback confirmed: the user successfully reloaded via 127.0.0.1:2019, and an external TLS 1.3 handshake subsequently succeeded with certificate verification OK. The TLS 1.2-only restriction is no longer active.

ZeroSSL chain test

After the user changed the Radicade site's ACME issuer to ZeroSSL and reloaded successfully, an external OpenSSL probe confirmed the served chain changed to ns.radicade.app -> ZeroSSL RSA DV SSL CA 2 -> Sectigo Public Server Authentication Root R46 -> USERTrust RSA Certification Authority, with verification OK. The new chain was active before the Quest launch.

The existing Quest APK was launched again (PID 30187). It reached Connecting to RecNet at 9.44 seconds, reported the identical UNITYTLS_INTERNAL_ERROR / verify result 4294957312 at 13.16 seconds, then nameserver error summer and OnApplicationQuit at 15.14 seconds. The process exited. Changing issuer did not fix startup. This weakens a Let's Encrypt-specific explanation but does not establish the exact validation failure. ZeroSSL remains configured on the VPS; no rollback has been performed.

Read-only inspection confirmed that the test APK's live metadata literals 41405 (auth) and 41411 (nameserver) both resolve to https://ns.radicade.app. The headset reports Android 14, and both /system/etc/security/cacerts and /apex/com.android.conscrypt/cacerts contain certificate files. This does not establish that Unity successfully loads or trusts those files. Further diagnosis should correlate Caddy TLS handshake errors with a fresh Quest launch before making additional certificate or client changes.

Correlated Caddy debug and headset trust-store checks (2026-10-07 Pacific)

Quest PID 31620 again failed at about 13.29 seconds and quit at 15.27 seconds. The user supplied Caddy debug lines at 07:06:07 UTC showing SNI ns.radicade.app, supported protocol versions [771,770,769] (maximum TLS 1.2), successful selection of the ZeroSSL certificate, and handshake EOF. EOF alone does not identify the client's reason for closing.

The numeric Unity verify result 4294957312 is signed -9984 (-0x2700), matching Mbed TLS's certificate verification failed code; this correspondence suggests certificate validation failure but does not identify the precise Unity verification flag or callback.

Pulled the headset's 134 public system CA certificates to artifacts/quest-system-cacerts and built artifacts/quest-system-ca-bundle.pem. OpenSSL TLS 1.2 verification of the live Radicade server succeeded with this CAfile, -no-CApath, -no-CAstore, -verify_return_error, and -verify_hostname ns.radicade.app. This establishes that the served chain can validate with the headset's public system roots using OpenSSL, not that Unity loads these roots or validates identically. Investigation should focus on Unity's trust loading/custom validation and chain-building behavior rather than assume a missing system root or TLS version mismatch. Caddy debug remains enabled; ZeroSSL remains active.