funman300/OpenFUT-Bridge
1
0
Fork 0
Code Issues 4 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: probe overturns dig-2 hypothesis — connect flow never triggered (ctx non-null)

Browse Source 
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 <noreply@anthropic.com>
This commit is contained in:
funman300
2026-07-02 17:55:42 -07:00
parent c8f6adfb70
commit ba7bb4f4be
1 changed files with 36 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/connection-gate-findings.md
+36
View File
@@ -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]].