OpenFUT-Bridge/docs/blaze-handshake.md

Blaze Handshake — Reference & Milestone Map

This is the reference for the blaze_brain arc: emulating the EA Blaze backend well enough for FIFA 23 FUT to get past "FUT is connecting to the EA Servers…". It replaces the earlier in-process forcing arc, which concluded that the game's online dispatch scaffold cannot be filled by forcing local state — it fills only when a real Blaze exchange happens.

Every claim below is tagged so that on a re-read you can see instantly what is grounded in our own reverse engineering versus what is general public knowledge of Blaze's protocol shape versus what still needs a capture:

• CONFIRMED — established by our own RE in this project (live memory reads, objdump, hook logs).
• SHAPE — the general shape of EA's Blaze protocol from public community knowledge. The ordering and purpose are reliable; exact numeric IDs and field tags for FIFA 23's specific Blaze version are not implied by a SHAPE tag.
• UNKNOWN — must be captured from the live client before it can be implemented.

Clean-room discipline: nothing here derives from leaked EA source. The Blaze protocol shape is reconstructed from public community reverse-engineering of EA titles and our own observations of this client.

---

The three layers that all say "connecting to EA"

"Connecting to EA" is not one thing. Three distinct systems wear that label, stacked on top of each other, and it is easy to confuse a stall in one for a stall in another. Understanding which layer the FUT spinner belongs to is the whole point of this document.

Layer 0 — LSX (Local Socket eXchange). CONFIRMED working. This is the Origin/EA-App desktop-client local API: entitlements, the local login handshake, and GetAuthCode. It is not Blaze — it is a localhost protocol the game uses to talk to whatever is standing in for the EA App. Our native bridge answers it on ports 3216/3217, and answering it is what got the client to the main menu with a working first-party login. Layer 0's output that matters to Blaze is a Nucleus auth code / access token: the credential the client will later present to the Blaze authentication component.

Layer 1 — the Blaze core session. This is the wall. Blaze is EA's online backend framework. Reaching it is a multi-step handshake (detailed below) that starts by asking a redirector where the real server is, connecting there over TLS, then negotiating configuration, authenticating with the Layer-0 auth code, and finally bringing the session fully online. Until this completes, nothing above it can work. Everything we have observed says the client currently never even starts this — see the transport finding below.

Layer 2 — FUT / UTAS. SHAPE. FIFA Ultimate Team specifically is served by the EASFC Blaze component and by UTAS, a separate HTTPS REST service (utas.*.fut.ea.com). Once a Blaze session exists, the FUT client authenticates to UTAS (POST /ut/auth) with the session credential to obtain a FUT session id, and only then does it load squad/club data. The FUT spinner in the screenshot lives at the top of this stack, but it cannot clear until Layer 1 is answered — so "minimal Blaze handshake" means Layer 1, and Layer 2 is a second, HTTP-shaped project that comes after.

---

Where the client currently stalls — the transport finding

CONFIRMED. Across a full menu-plus-FUT-attempt session we observed zero getaddrinfo calls and zero outbound sockets, and — via the ELEM_WATCH probe — the game's per-connection message-handler dispatch container at element[0]+0x40 stayed a clean, empty, default-constructed vector the entire time, including while the FUT spinner was on screen. connectState.ctor fired (the client builds connect-state objects) but registered nothing into that container.

The mechanical reading: that container is populated by an actual Blaze message exchange — handlers register as component notifications arrive during session bring-up (Layer-1 step 6 below). No Blaze reply → no handler registration → empty container → spinner spins forever. The spinner is the Layer-1 wall.

This leaves two possible transport situations, and Milestone 0 exists solely to decide which one we are in (see the Milestones section):

• (a) the client expects Blaze on a hardcoded local endpoint and would dial it if a listener were there, or
• (b) the client only dials the Blaze redirector after an in-process bootstrap (the dial handler 0x144f4d360 CONFIRMED) fires — in which case the transport wall and the bootstrap wall are the same wall.

---

Layer 1 — the minimal Blaze handshake ordering

Blaze is a framed binary protocol. Each message is a header — length, component id, command id, message type (request / response / notification / error), error code, and a message/sequence id — followed by a TDF-encoded body (EA's tag/type/value binary serialization). SHAPE. The exact numeric component/command ids and TDF field tags for FIFA 23's Blaze version are UNKNOWN until captured.

These are the six steps a responder must satisfy, in order, to bring a session online:

1. Redirector::getServerInstance SHAPE — the client asks the redirector for the address of the real Blaze server, naming the FIFA 23 service/SKU. The responder returns a ServerInstanceInfo TDF containing a host:port (point it at ourselves) plus an SSL flag. Without a valid address the client has nowhere to go.
2. connect + TLS CONFIRMED (bypass) — the client opens a TLS connection to the returned address. Our ProtoSSL/cert-verify bypass is already in place, so our listener can terminate TLS.
3. Util::preAuth SHAPE — the client sends its config/version/locale; the responder returns server config: the component list, ping-site list, telemetry settings (disable), and a misc config bundle. The client uses the component list to know what exists; an empty or malformed response here stalls it.
4. Authentication::login CONFIRMED (GetAuthCode feeds here) + SHAPE — the client authenticates, presenting the Nucleus auth code from Layer 0 (SSO). The responder returns the session: BlazeId, session key, persona, entitlements. A failure here is what surfaces as "EA Servers are down."
5. Util::postAuth SHAPE — after auth, the client finalizes the session; the responder returns post-auth config (UserManager, association lists, telemetry, ticker/PIN).
6. UserSessions::updateNetworkInfo / updateHardwareFlags, then a UserSessionExtendedDataUpdate notification CONFIRMED (container is Blaze-downstream) + SHAPE (which command) — the client publishes its network/ hardware info and the server pushes extended session data. The client flips to "online" on receipt of the extended-data notification — and this is the exact moment the element[0]+0x40 container we watched would begin filling, as handlers register for the arriving component notifications.

At step 6 the top-level "connected to EA" clears, and Layer 2 (UTAS) can begin.

Why step 6 is the Milestone-1 success signal

The container-fill and the "online" flip are the same event: handlers register because Blaze notifications arrived. That gives blaze_brain a precise, already-built success detector. The first real win is not "full FUT works" — it is a single line in the hook log:

ELEM_WATCH: [elem+0x40] CHANGED! …

That line means the client accepted our Blaze replies and started registering handlers — i.e. steps 1–6 were convincing enough to bring the session online. The ELEM_WATCH probe that emits it is already written and deployed; it is our instrumentation for blaze_brain regardless of anything else.

---

Milestones

• M0 — transport reachability (this task). Read-only. Confirm whether the client attempts any Blaze-flavored transport (situation a) or none at all (situation b). Gates every decision below. See the M0 section in the hook docs / launch notes.
• M1 — minimal session bring-up. Stand up a listener at the M0-observed endpoint; answer getServerInstance (redirect to ourselves), then preAuth / login / postAuth with minimal valid TDFs and a single hardcoded persona. Success signal: ELEM_WATCH: CHANGED fires and the spinner advances.
• M2 — session online. Handle the step-6 session notifications until the top-level "connected to EA" state is reached and stays.
• M3 — FUT / UTAS. Implement the UTAS REST layer (POST /ut/auth and the /ut/game/... endpoints already sketched in endpoint-map.md) so FUT itself loads.

M1 is only reachable if M0 says the client actually dials a listener. If M0 comes back "no traffic" (situation b), M1 in its "answer over a wire" shape is blocked until the dial trigger is solved, and the strategic options are re-opened rather than a next task being obvious.

---

Honest UNKNOWNs (capture before implementing)

• Numeric component and command ids for FIFA 23's Blaze version. The names and ordering above are SHAPE-reliable; the wire ids are UNKNOWN.
• TDF field tags and body layouts for each request/response. UNKNOWN — every response body must be shaped from a real capture (or careful trial against the client's parser).
• The redirector/Blaze transport itself — host, port, and whether it is remote, loopback, or a pipe. This is exactly M0's question and is UNKNOWN until M0 runs.
• Whether the client dials at all without the in-process bootstrap firing — the situation (a) vs (b) question. UNKNOWN until M0.

Until M0 answers the transport question, the ordering above is designable but untestable: there is nothing to answer to.