From ba7bb4f4be05dff8fb0a67f80ef8d9b4135ab27f Mon Sep 17 00:00:00 2001 From: funman300 Date: Thu, 2 Jul 2026 17:55:42 -0700 Subject: [PATCH] =?UTF-8?q?docs:=20probe=20overturns=20dig-2=20hypothesis?= =?UTF-8?q?=20=E2=80=94=20connect=20flow=20never=20triggered=20(ctx=20non-?= =?UTF-8?q?null)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Live probe result: the Nucleus session context [M+0x778] is non-null (0xba8315a0), but nucleusConnectREST/Trusted and the connect-state tick are NEVER called. FIFA completes LSX bootstrap, parks at 'connecting', and never starts the EASFC online connect. So the gate is an upstream trigger, not the null-check the static analysis suggested. Also documents the FLE hook-injection path (deploys must target the FLE dir). Co-Authored-By: Claude Fable 5 --- docs/connection-gate-findings.md | 36 ++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/docs/connection-gate-findings.md b/docs/connection-gate-findings.md index 8ebb55b..01bc5d9 100644 --- a/docs/connection-gate-findings.md +++ b/docs/connection-gate-findings.md @@ -896,3 +896,39 @@ does the manager hold at +0x778, and (c) if REST is never called, which online-l 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). + +--- + +## DYNAMIC PROBE RESULT — hypothesis overturned: connect flow is never triggered (2026-07-02, run 3) + +Built a probe (openfut-hook `probe` feature) with entry detours on the game-side connect +functions + a guarded sampler that reads the session-context chain directly. Ran it live at +"connecting to EA Servers". **Deploy note:** FIFA is launched via **FLE**, which injects +`openfut_hook.dll` from the FLE dir — NOT the game-dir `version.dll`; earlier redeploys to +version.dll were never loaded (see [[reference_hook_deploy_path]]). + +**Results (decisive):** +- Sampler: `X=[0x14acd02c0]` (OriginSDK singleton), `M=[X+0x360]`, `ctx=[M+0x778]` → + **`ctx = 0xba8315a0`, non-null and stable** the entire time. +- `nucleusConnectREST` enter=**0**, `nucleusConnectTrusted` enter=**0**, + `connectState.tick` (+0x507d660) enter=**0**. +- Bridge LSX log: FIFA does its full bootstrap (GetConfig, GetProfile, GetGameInfo, + GetSetting, GetInternetConnectedState, IsProgressiveInstallationAvailable, SetPresence, + SetDownloaderUtilization) then **goes silent** — only receiving our 2 s event pushes. Over + the whole session it **never** sends QueryEntitlements, RequestLicense, or GetAuthCode. + +**Conclusion — the dig-2 static hypothesis was WRONG.** The Nucleus session context `[M+0x778]` +is NOT null; it exists. The connect functions would pass their null-check — but they are +**never called**. The blocker is not a missing object; it is that FIFA's EASFC/Nucleus +**online-connect flow is never triggered at all**. FIFA completes LSX bootstrap, parks at +"connecting", and never advances to the connect state (whose objects are created at init — +loop @ +0x4f47920 building the array [ctrl+0x780], count [ctrl+0x298] — but never driven). + +**This is exactly why we probe:** the static call-graph looked like a null-check gate; the live +client showed the gate is upstream — a *trigger*, not a precondition. Event-push (OnlineStatus/ +Login) parses fine and even sets FIFA's stored online bool (via the no-op listener's map store), +but does not kick the online controller into starting the connect. **Next question: what +transition starts the EASFC connect** (idle connect-state → nucleusConnectREST). Candidates to +probe next: the connect-state's earlier vtable steps (+0xa8/+0xb0 = +0x507cd60/+0x507cf90) to +see if the state is entered-but-stalls vs never-entered, and the online-controller update that +would advance it. Still a cost/priority call vs [[project_direction_pivot]].