From c8f6adfb70f060d32bb4c1d43b8d964d5ea43ce7 Mon Sep 17 00:00:00 2001
From: funman300 <funman300@gmail.com>
Date: Thu, 2 Jul 2026 17:34:44 -0700
Subject: [PATCH] docs: pin online gate to the Nucleus session context
 [mgr+0x778]

Dig 2: traced the GetAuthCode send path up to FIFA's game-side
nucleusConnectREST (+0x2861910) / nucleusConnectTrusted (+0x5078370).
Both null-check the same Nucleus session context [NucleusManager+0x778]
and short-circuit when null (REST returns 0/sends nothing; Trusted returns
HRESULT 0x80060000 not-ready). So the online->auth gate is that +0x778 is
never instantiated -- consistent with the no-op-listener finding (event
updates stored state but doesn't drive the login state machine to create
the context). Next: a targeted dynamic probe on REST + the +0x778 read.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---
 docs/connection-gate-findings.md | 48 ++++++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/docs/connection-gate-findings.md b/docs/connection-gate-findings.md
index 2a77dbe..8ebb55b 100644
--- a/docs/connection-gate-findings.md
+++ b/docs/connection-gate-findings.md
@@ -848,3 +848,51 @@ mechanism (EASFC job-enqueue poll, not LSX/events). This closes the "is it the e
 question — it is not. The remaining work is FIFA-internal EASFC state-machine RE, which
 sits directly against the [[project_direction_pivot]] (FLE career mode is the stated
 primary plan) as a cost/priority decision, not a technical unknown on the LSX side.
+
+---
+
+## Gate pinned to a concrete object: the Nucleus session context `[mgr+0x778]` (2026-07-02, dig 2)
+
+Traced the send path all the way up to FIFA's game-side Nucleus-connect layer and
+found the exact null-check that stops the auth chain. Clean-room (FIFA's own code +
+its embedded source-path strings are the oracle).
+
+**Send path (confirmed, top to bottom):**
+- `GetAuthCodeT::Serialize` @ FIFA23.exe+0x278d2c0 → request
+  `<GetAuthCode UserId ClientId Scope AppendAuthSource/>`.
+- Sent by `Origin::OriginSDK::SendXml` (embedded path
+  `E:\packages\OriginSDK\10.6.2.19-fb-fifagame_11164847\src\impl\OriginSDKimpl.cpp`),
+  internal senders FIFA23.exe+0x2732f50 / dispatch +0x2737df0. Statically linked into
+  FIFA23.exe (not a DLL) — anadius does not emulate this layer.
+- Requested by FIFA's **game-side Nucleus-connect layer**: `nucleusConnectREST`
+  @ FIFA23.exe+0x2861910 and `nucleusConnectTrusted` @ FIFA23.exe+0x5078370
+  (found via the log-tag strings `nucleusConnectREST` 0x1480db550 /
+  `nucleusConnectTrusted` 0x148441c18).
+
+**THE GATE (sharp).** Both connect paths **null-check the same object** — the Nucleus
+session/context at **`[NucleusManager+0x778]`** — and short-circuit when it is null:
+- `nucleusConnectREST` (+0x2861910): loads `mgr = (*GetMgr())->vt[0x178]()`, reads
+  `[mgr+0x778]`; **if null → returns 0, builds/sends nothing** (no GetAuthCode).
+- `nucleusConnectTrusted` (+0x5078370): if `[[this+0x10]+0x778]` is null → returns
+  HRESULT **0x80060000** ("not ready"); its caller state (+0x507d660, part of the
+  online-login state machine — state handlers are vtable slots dispatched via
+  `[rax+0xb8]`) then waits/retries instead of advancing.
+
+So the online→auth transition is gated on **the Nucleus session context `+0x778` being
+instantiated**, and in our setup it never is. This is fully consistent with the earlier
+no-op-listener finding: pushing `OnlineStatusEvent` updates FIFA's *stored* online bool
+but does not drive the login state machine to the step that creates the `+0x778` context,
+so both auth-code paths keep null-checking it and bailing. Event-push cannot create it.
+
+**Why static tracing stops here:** `nucleusConnectREST` is a virtual (vtable slot
+0x1480db478) and the manager-getter (+0x27d9970) is a ubiquitous singleton (hundreds of
+callers), so the exact state that *would* call REST — and the predicate that instantiates
+`+0x778` — are not pinnable by call-xref alone.
+
+**Concrete next step (dynamic, cheap, ready to build):** with FIFA at "connecting to EA
+servers," probe (hook DLL, existing `probe` feature) **nucleusConnectREST @ +0x2861910**
+and the **`[mgr+0x778]` read** to observe: (a) is REST even called on our path? (b) what
+does the manager hold at +0x778, and (c) if REST is never called, which online-login state
+FIFA is parked in (log the state object's vtable). That directly reveals what instantiates
+`+0x778`. This replaces "months-long unknown" with a single targeted probe against a named
+object. Still a cost/priority call against [[project_direction_pivot]] (FLE career primary).