OpenFUT-Bridge/docs/closure-and-preservation.md

# OpenFUT — Closure & Preservation Record

*A clean-room reverse-engineering effort to restore FIFA 23 Ultimate Team offline after
EA's server shutdown (October 2025). This document records what was built, what was
achieved, and the precise technical wall at which the effort concludes.*

**Status: the online/FUT route is closed at a characterized wall. The offline-menu /
EA-App-emulation layer works and is preserved.**

**Provenance:** everything here derives from observing the running client's own behaviour —
live memory reads, static disassembly of the shipped binary, and the game's responses to
our synthesized inputs. No leaked EA source was used or referenced at any point. That
clean-room discipline is the legal foundation of the work and is the reason this record can
exist.

---

## 1. What OpenFUT set out to do

FIFA 23's online services were permanently shut down in October 2025, which removed FIFA
Ultimate Team — the mode is backed by EA's online infrastructure and simply cannot start
without it. OpenFUT's goal was game preservation: let a legitimately-owned copy run FUT
against a **local, emulated backend** instead of EA's dead servers.

The intended shape was three cooperating pieces:

```
FIFA 23 client (offline, under Proton/Wine or native Windows)
      │  EA-App / Blaze / FUT protocols
openfut_hook.dll   — injected; redirects EA traffic, bypasses cert pinning, observes
      │  localhost
openfut-bridge     — answers the EA-App (LSX) protocol; was to answer Blaze + FUT
      │
openfut-core       — the game-independent FUT economy backend (cards, packs, SBCs…)
```

The entry sequence the client runs, in order, each gating the next:

1. **LSX** — the EA App ↔ game local handshake (login, entitlements, config).
2. **Blaze redirector** — "where is my game server?"
3. **Blaze preauth / login / postauth** — establish the online session.
4. **FUT entry** — eligibility, then the FUT hub loads over REST.

The plan was to walk these gates one at a time, synthesizing each response and verifying it
against the live client (the client is the oracle — a gate is "done" when the game advances).

---

## 2. What was achieved

This is preservation documentation, so the wins are recorded first and plainly. They are
real, and they stand independent of the wall reached later.

### 2.1 Clean-room injection and TLS neutralization

- A `version.dll` / FLE-loaded hook that injects into FIFA 23 under Proton/Wine without
  tripping the (neutralized) anti-cheat, writing a durable log for observation.
- ProtoSSL / cert-verify bypass sufficient to let the game accept our substituted
  endpoints at the layers we terminate.
- Winsock interception (`getaddrinfo`, `connect`, `WSAConnect`, `ConnectEx`) with EA-host
  and EA-port redirection to the local bridge — including, by the end, **IPv6 (IPv4-mapped)
  redirection**, which closed a real leak the earlier IPv4-only path had missed.

### 2.2 The LSX / EA-App layer works — the game reaches a fully-authenticated menu offline

This is the substantive achievement. The bridge's native LSX server (port 3217) emulates
the EA App / EbisuSDK local protocol completely enough that FIFA 23, with EA's servers gone,
**boots to its main menu believing it is logged in and online.** Confirmed working, from the
bridge's own logs of a live session:

- `EALS ChallengeResponse` — the EA login-service challenge/response handshake completes
  (`handshake complete`).
- `EbisuSDK GetConfig / GetProfile / GetGameInfo / GetSetting` — all answered; the game gets
  its service list, profile, and configuration.
- `Utility GetInternetConnectedState → connected=1` — the connectivity check passes.
- `XMPP SetPresence → INGAME` — presence is set.
- `Login IsLoggedIn=true` and `OnlineStatusEvent isOnline=true` — pushed continuously; the
  game's own online-status state flips to "online."

Everything the EA-App layer is asked for, it receives. This is a genuine, reusable
clean-room EA-App/EbisuSDK emulator.

### 2.3 Reverse-engineering infrastructure

The effort produced durable tooling and knowledge, all clean-room:

- Live memory inspection via `/proc/<pid>/mem` (Wine maps `FIFA23.exe` flat at ImageBase
  `0x140000000`), including a stable algorithm to resolve the live Blaze connection manager
  (`G = *[0x14acd02c0]` → `M = *[G+0x360]` → `ctx = *[M+0x778]`; then a heap scan for the
  object `P` with `[P+0] == base+0x80200b8` and `[P+8] == M`).
- Read-only in-process probes (menu-time snapshots, a write-watchpoint on the dispatch
  container, transport observation) — all env-gated, none altering game state.
- Handshake-independent TLS **SNI capture** on the bridge (peek the ClientHello, parse SNI
  before the handshake, so the hostname is learned even when the client rejects our cert).
- A documented **Blaze handshake reference** (`docs/blaze-handshake.md`) mapping the
  three-layer LSX / Blaze-core / UTAS model and the six-step Blaze session ordering.

---

## 3. The wall — reached from three independent directions

FUT never loaded. The reason is a single wall, and the strongest evidence for it is that
three unrelated lines of investigation arrived at the same place.

### 3.1 The forcing arc (memory side)

We confirmed the live Blaze connection manager and the in-process "dial" handler
(`0x144f4d360`) that begins the Blaze connection when the network comes online. Both exist at
the menu. But:

- **Forcing the dial with the connection scaffold empty crashes** in normal `.text` (not the
  VM) at `0x144fd6b6c`: a binary search over a per-connection message-handler table whose
  `begin` pointer is an uninitialized sentinel (`1`). The table is empty because nothing has
  populated it.
- **Forcing the online state machine to "fully online" (state 2) crashes the anti-tamper
  VM** deterministically — the game's own protected online code runs against a forced-but-
  absent session and faults. A forced state cannot substitute for a real session.

Conclusion of the arc: the dial and the online state are *primed but unpumped* — real
infrastructure that only a genuine connection flow drives, and that cannot be safely forced.

### 3.2 The network / transport arc

With the entire EA-App layer satisfied (§2.2) and the network path fully instrumented
(including IPv6 and SNI capture), we watched a complete FUT "connecting to EA Servers"
attempt. The complete outbound inventory:

| Traffic | Identity | Fate |
|---|---|---|
| 2× IPv6 `:443` → `rl.data.ea.com`, `pin-river.data.ea.com` | EA **PIN/River telemetry** (fire-and-forget) | reached the bridge, **cert-rejected by ProtoSSL** |
| 6× IPv6 UPnP (`:1900`, `:80`, LAN) | NAT traversal | — |
| LSX (`:3217`) | EA-App layer | fully answered |

**No `gosredirector` / `redirector.ea.com`. No Blaze-port (`:42127` / `:10041`) connect. On
any transport.** Starting FUT added *zero* new dials. The game is satisfied enough by the
EA-App layer that it never attempts a Blaze connection at all. (This also corrected an
earlier false belief — "zero outbound sockets" — which turned out to be undecoded IPv6
traffic.)

Conclusion of the arc: the wall is **not** transport, **not** an unanswered LSX request,
**not** the cert. The game simply never initiates Blaze.

### 3.3 The two arcs meet

The forcing arc found, from memory, that the connection scaffold is never populated. The
network arc found, from the wire, that no connection is ever attempted. Same wall, two sides.
The final chapter explains *why*, from the binary itself.

---

## 4. Final chapter — the dial-initiation gate (why it is circular)

This is the concluding technical result: a static reverse-engineering pass answering the one
question both arcs left open — *beyond "online," what does the code check before it fires the
Blaze dial, and is that condition reachable offline?*

### 4.1 Method

Read-only static analysis of the shipped `FIFA23.exe` (`objdump`), two cross-reference
techniques: an 8-byte absolute-address search across the whole file (finds function pointers
stored in data — vtables, tables) and a disassembly grep for `call`/`jmp`/`lea` targets
(finds code references; a `lea reg,[…] # 0x…` is an address being *taken* for registration, a
`call 0x…` is a direct invocation). Addresses below are `FIFA23.exe` virtual addresses
(ImageBase `0x140000000`). The anti-tamper VM region `[0x14c1cd000, 0x160eb1000)` is
unreadable; everything traced here is in normal `.text`.

### 4.2 The caller graph

```
dial handler  0x144f4d360
   ▲  address-taken only (lea r9,[dial]) — NEVER called directly, NEVER in a vtable
   │  inserted into the container [connMgr+0xc38] by:
F1 registrar  0x144f4b7b0          (exactly ONE caller)
   ▲
F2            0x144f4b960          (builds a callback, calls F1 with rcx = connMgr)
   ▲  TWO callers, identical guard:  cmp bpl,[this+0x42] ; cmp bp,[this+0x142]
   ├── F3a   0x144f44770
   └── F3b   0x144f4bbf0
```

Every reference is a normal-`.text` `lea` — the dial handler is *registered as a callback*,
never called by address. The registrar `F1` is a "get-or-create into the message-handler
container": on a miss it allocates a handler and copies a caller-supplied callback into it.
Its sole caller `F2` supplies the callback and resolves the connection manager
(`rcx = [[this+8]+0xca0]`).

### 4.3 The decisive structural fact

`F3a` and `F3b` — the two functions that actually decide to register the dial — are, from the
whole-binary sweep, **in zero vtables and never directly called.** They are `lea`'d at four
sites and **registered into `[connMgr+0xc38]`, each keyed by a `.rdata` message-type
descriptor** (`0x1483fcf98`, `0x14808d7d0`). In other words they are themselves **message
handlers**, dispatched indirectly by the connection manager when a matching Blaze message
arrives — not methods invoked by a state machine you can drive locally. (In Rust terms: not
methods on a trait object, but closures inserted into a `HashMap<MessageType, Handler>` and
called by a dispatcher.) The functions that register *them* (`G_a 0x144f4a350`,
`G_b 0x144f45220`) are ordinary helpers inside the same cluster, and the entire cluster
`F1…G_b` is vtable-free.

So the whole thing is one **self-registering, message-driven state machine on
`[connMgr+0xc38]`:** each handler fires when its Blaze message arrives, checks connection
state, and registers the next handler — until `F3a`/`F3b` register the dial. The state each
step checks (`[this+0x42]`, `[this+0x142]`, …) is connection-lifecycle state, advanced only
as messages are processed.

### 4.4 Reachability, and why it is circular

Offline, the container `[connMgr+0xc38]` is **empty** (measured directly: the crashing table's
`begin` is `0`/garbage; the network arc saw zero Blaze messages). Nothing ever dispatches
`F3a`/`F3b`, so their guards never even execute — the wall sits *upstream* of them. The one
thing that does fire offline is the connection-state constructor (on the online-status event),
so the machine's entrance is *partially* reached and then stalls immediately, because no
Blaze message follows to drive the first dispatch.

**Outcome: circular gate.** The trigger is *found* — we can see precisely how the dial gets
registered and fired. But its precondition is *prior Blaze connection-lifecycle messages
having populated and dispatched the handler container* — i.e. the very network exchange the
connection is meant to produce. The state that gates the dial requires the dial's own earlier
connection steps to have already run. It is not a settable flag (there is none between
"online" and "dial"); it is an entire message exchange that never begins.

This is the exact mechanical explanation of both arcs: the container is empty because no
messages flow (network arc), and forcing the dial into that empty container crashes (memory
arc).

---

## 5. What this means — the boundary, stated plainly

**OpenFUT can take FIFA 23 to a fully-authenticated main menu, offline, believing it is
logged in and online — but it cannot take it into FUT.** FUT requires a Blaze session, and on
this build the Blaze connection is never initiated. The bootstrap is circular: the client
will only walk its connection state machine as real Blaze messages arrive, and no messages
arrive because no connection is begun. "Online," at the EA-App level, is genuinely
disconnected from "reach out to Blaze," and the gap between them is not a flag we failed to
set — it is a live protocol exchange that has no counterpart to talk to.

Two secondary walls sit behind the first, and would matter only if it were solved:

- **ProtoSSL cert pinning** (`CertificateUnknown`) rejects our self-signed cert on the
  DirtySDK path — so even redirected EA HTTPS cannot complete a handshake as-is.
- **The anti-tamper VM** faults deterministically whenever forced state is used by the game's
  own protected online code — so "force the state and let the game run" is not viable.

---

## 6. Paths not taken, scoped honestly

Only one route could still reach FUT, and this record scopes it so the decision is clear-eyed
rather than reopened casually.

**In-process Blaze state-machine injection.** Rather than answer Blaze over a wire (there is
no wire — the game never dials), blaze_brain would **drive the game's in-process connection
state machine by injecting synthesized Blaze response frames into its dispatch layer.** From
the final-chapter RE, that requires:

1. Making the connection appear *initiated*, so the game registers its first response handler.
2. Feeding synthesized Blaze responses **in order and keyed to the same `.rdata` message-type
   descriptors**, so each registered handler fires, advances the connection-state flags, and
   registers its successor — walking the machine forward until the dial is registered and
   fires.

This is a weeks-scale build requiring per-message protocol RE done from the *receive* side,
against a client that is the only available oracle (the servers are dead, so every frame must
be synthesized and validated by whether the client advances). It also inherits an unsolved
sub-problem: the initial "connection initiated" state must itself be synthesized or forced,
since the game does not produce it offline. It is possible in principle; it is not a small
task, and its scope should be understood before it is begun.

The alternative — the one this document records — is to treat the fully-authenticated offline
menu as the achieved preservation state and close the online/FUT route here.

---

## 7. Preservation value

Even without FUT, the effort produced things worth keeping:

- **A working clean-room EA-App / EbisuSDK (LSX) emulator** that boots FIFA 23 to an
  authenticated main menu with no live EA servers — a genuine preservation artifact for the
  offline single-player state.
- **A documented map of exactly where and why online play is unreachable** on this build,
  grounded in the binary: the dial caller graph, the message-driven container mechanism, and
  the circular bootstrap. Future work (on this title or the engine family) starts from a
  known wall, not a blank page.
- **Reusable RE tooling and references** — live-memory resolution of the connection manager,
  the transport/SNI instrumentation, and the Blaze handshake reference doc.
- **A clean provenance record** — nothing derived from leaked source, so the work remains
  usable and shareable.

---

## 8. Closing note

OpenFUT reached the last gate it could reach without a live server to talk to, and then
proved — from memory, from the wire, and from the binary — that the next gate is not a lock
we failed to pick but a door that only opens from the far side. That is a complete and honest
result. The offline menu stands; the map is drawn; the wall is named.

*This record is the concluding chapter of the OpenFUT reverse-engineering arc.*