OpenFUT/fifa17-recon/tools/acct_retrieval.md

# FIFA 17 — "account information" retrieval path, end to end

**Date:** 2026-07-30 · **Target:** live `FIFA17.exe` (base `0x140000000`, Wine flat PE map),
plus the saved live-string dump `modstrings.txt` after the process exited mid-analysis.

**Clean-room provenance:** every fact below comes from (a) static/dynamic analysis of binaries we
own (`FIFA17.exe` as mapped in our own process, `stp-origin_emu.dll`), (b) our own client's observed
LSX/Blaze wire traffic (`/tmp/lsx.log`, `/tmp/blaze_responder.log`), and (c) the client's own
runtime reflection/metadata. **No 2021 EA/FIFA leak material was used or consulted.**

Builds on `auth_schema_reflection.md`, `auth_statemachine.md`, `origin_nucleus.md`.

---

## 0. Verdict (short)

**Account information is carried on the Blaze channel, but it is *gated* by the LSX/Origin channel.
The Nucleus/account HTTP channel is not part of the PC login path at all.**

* **LSX/Origin (`127.0.0.1:4216`)** supplies the *identity* and the *credential*:
  `GetProfile` → the OriginSDK's default **user id / persona id**; `QueryEntitlements` →
  `ONLINE_ACCESS`; **`GetAuthCode` → the one-time Origin auth code**.
* **Blaze (Fire2, `:42130`)** supplies the *account record*: `Authentication::login (1/0x0A)` takes
  the auth code in `LoginRequest.AUTH` and returns `LoginResponse.SESS` (session key, blazeUserId,
  userId, email, persona details) — this **is** "account information" for the login flow. The
  explicit account RPCs (`getAccount 1/0x1E → AccountInfo`, `getPersona 1/0x5A`,
  `listPersonas 1/0x64`, `listUserEntitlements2 1/0x1D`) all live *behind* that login.
* **Nucleus/account HTTP (`:42131`)** is unused **by design of this code path**, for two independent
  reasons proven below (§4). It is not a missing piece; it is a dead end for PC/Origin login.

**The exact missing piece:** `LoginRequest.AUTH` (`authCode`, a plain string) can only be filled by
LSX `GetAuthCode`, and the client never issues it. No auth code → no `Authentication::login` → no
`LoginResponse` → nothing that can answer "account information" → popup. Everything downstream
(`getAccount`, `listPersonas`, FUT `user/accountinfo`) is unreachable.

---

## 1. Channel 1 — LSX / Origin on `127.0.0.1:4216`

### 1.1 Complete OriginSDK LSX surface (from the client's own template instantiations)

`Origin::LSXRequest<>` / `LSXEnumeration<>` instantiations present in the image:

| Request | Response | Notes |
|---|---|---|
| `GetConfigT` | `GetConfigResponseT` | |
| `GetProfileT` | `GetProfileResponseT` | **sets the default user/persona — see §1.2** |
| `GetSettingT` | `GetSettingResponseT` | |
| `GetGameInfoT` | `GetGameInfoResponseT` | `UPTODATE` gate |
| `GetInternetConnectedStateT` | `InternetConnectedStateT` | the online gate |
| **`GetAuthCodeT`** | **`AuthCodeT`** | handler `0x1439385b0`, callback `0x143938660` |
| `QueryEntitlementsT` | `QueryEntitlementsResponseT` → `OriginItemT` | enumeration, `0x1439484e0` |
| `GetUserProfileByEmailorEAIDT` | `…ResponseT` → `OriginFriendT` | |
| `IsProgressiveInstallationAvailableT`, `AreChunksInstalledT`, `QueryChunkStatusT`, `SetDownloaderUtilizationT`, `QueryOffersT`, `GetWalletBalanceT`, `CheckoutT`, `ConsumeEntitlementT`, `GetPresenceT`, `SetPresenceT`, `QueryFriendsT`, `GetBlockListT`, `SendInviteT`, `ShowIGOT`, `GrantAchievementT`, `ExtendTrialT`, `SelectStoreT` | | not on the login path |

### 1.2 `GetProfile` is what defines "who is logged in" — **proven**

`OriginGetDefaultUser()` @ `0x1470da6d0` and `OriginGetDefaultPersona()` @ `0x1470da680` are bare
field reads:

```
1470da6d0  call 0x1470e2840        ; SDK-ready predicate
1470da6f4  call 0x1470e3560        ; get impl singleton
1470da6f9  mov  rax,[rax+0x3a0]    ; <<< default USER id
1470da680  ... mov rax,[rax+0x3a8] ; <<< default PERSONA id
```

Both fields are zeroed in the SDK constructor (`0x1470deb2f` / `0x1470deb36`, `rsi = 0`) and are
written in exactly **one** place — `Origin::OriginSDK::Initialize` @ ~`0x1470e5a30`:

```
1470e5ac7  call 0x147118d80        ; sync GetProfile(index=0), 15000 ms timeout (0x3a98)
1470e5acc  test eax,eax
1470e5ace  jne  ...                ; on failure, leave 0
1470e5ad0  mov  rax,[rsp+0x70]
1470e5ad5  mov  [rdi+0x3a0],rax    ; <<< userId   from GetProfileResponse
1470e5adc  mov  rax,[rsp+0x78]
1470e5ae1  mov  [rdi+0x3a8],rax    ; <<< personaId from GetProfileResponse
```

`0x147118d80` builds the request through `0x147117fe0` with `index = 0` and waits via `0x1471186f0`.
The service name used is **`"EbisuSDK"`** (`0x143937d58`), which is why our responder must answer
`GetProfile` with `sender="EbisuSDK"` — it already does.

> **Consequence:** our `GetProfileResponse` with `UserId="33068179" PersonaId="33068179"` *is* the
> mechanism that populates the SDK's identity. That part is working; the client asked `GetProfile`
> three times (ids 3, 10, 17) and we answered correctly each time.

### 1.3 The auth-code request path — fully mapped

`FifaOnline::FirstPartyAuthTokenRetriever::DoTick` @ **`0x146f199c0`**:

```
  rbx = this+8 ; rbp = 2                      ; two request slots: this+0x08, this+0x10
loop:
  rsi = [rbx];  if (!rsi) goto next            ; nothing pending -> nothing happens, silently
  [rsp+0x60] = 0                               ; out: auth-code buffer
  [rsp+0x58] = 0                               ; out: auth-code length
  rax = call 0x1470da6d0                       ; OriginGetDefaultUser()   -> sdk[+0x3a0]
  r9  = &len ; r8 = &buf ; rdx = rsi+0x18      ; rdx = ClientId string from the request object
  rcx = rax                                    ; user handle
  eax = call 0x1470db3c0                       ; Origin::OriginSDK::RequestAuthCodeSync
  if (eax != 0) -> 0x146f19aab                 ; log "[%s] Origin Error(%d)"      (0x1438f5e18)
  if (buf == 0 || len == 0) -> 0x146f19a7e     ; log "[%s] Invalid authcode"      (0x1438f5e00)
  ; success: store the code at rsi+0xd8, set rsi+0xe8 = 1
```

`Origin::OriginSDK::RequestAuthCodeSync` @ **`0x1470db3c0`**:

```
1470db3da  lea rdx,[0x143936158]   ; trace "OriginRequestAuthCodeSync entered"
1470db3f2  call 0x1470dbf30        ; trace
1470db3f7  call 0x1470e2840        ; <<< SDK-ready predicate
1470db3fe  je   0x1470db424        ; NOT ready -> error 0xa0010000, NO LSX TRAFFIC AT ALL
1470db400  call 0x1470e3560        ; impl
1470db41d  call 0x1470e67f0        ; impl->RequestAuthCodeSync(user, clientId, &buf, &len, 0)
```

**Signature (recovered):** `OriginRequestAuthCodeSync(OriginUserT user, const char* clientId,
char** outBuf, size_t* outLen, ...)`. `clientId` comes from the request object at `+0x18` and is
what lands in the LSX `<GetAuthCode ClientId="…"/>` attribute (attribute name `ClientId`
@ `0x14394e098`).

**Note the wire-silent failure path:** if `0x1470e2840` returns false, `RequestAuthCodeSync` logs and
returns `0xa0010000` **without ever touching the socket**. That is a failure mode that looks exactly
like our symptom (nothing in the LSX log). It is, however, unlikely here, because the same predicate
guards `OriginGetDefaultUser`, `OriginCheckOnline`, `OriginGetProfile` etc., all of which demonstrably
worked. Ranked below in §5.

### 1.4 Pushed LSX **Events** — the SDK does support them, including `<Login>`

Our responder is request-driven only and never pushes. The client's OriginSDK *does* register
event handlers. Complete inventory of `Origin::EventHandler<lsx::…T, X>::HandleMessage`:

| Element (name table `0x14393cfd8`–`0x14393d208`) | Payload type |
|---|---|
| **`Login`** @ `0x14393d0ac` | `unsigned int` |
| `OnlineStatusEvent` @ `0x14393d120` | `bool` |
| `ProfileEvent` @ `0x14393d0b8` | `OriginProfileChangeT` |
| `CurrentUserPresenceEvent`, `PresenceVisibilityEvent`, `BroadcastEvent`, `IGOEvent`, `IGOUnavailable`, `MinimizeRequest`, `RestoreRequest`, `MultiplayerInvite`, `MultiplayerInvitePending`, `UserInvitedEvent`, `PurchaseEvent`, `ChatMessageEvent`, `GameMessageEvent`, `CoreContentUpdated`, `BlockListUpdated`, `AchievementSets`, `ChunkStatus`, `GroupEvent`, `GroupEnterEvent`, `GroupLeaveEvent`, `GroupInviteEvent`, `VoipStatusEvent` | various |

`Origin::LSXEvent<>` (the *handshake* event path) is instantiated for `ChallengeT` **only** — that
is the `<Event sender="EALS"><Challenge …/></Event>` we already send. Everything in the table above
goes through the `EventHandler`/`EventEnumerator` dispatch, whose element-name match is at
`0x1471028ee` (it first compares the `sender` attribute — `sender` @ `0x143938028` — then the element
name).

**Relevant attribute names in the pool** (`0x14394de00`+) that belong to this family:
`SessionInformation` `0x14394e0d8`, `IsLoggedIn` `0x14394e0f0`, `Changed` `0x14394e100`,
`userid` `0x14394e108`, `isOnline` `0x14394e180`, `initial` `0x14394e0c8`, `from` `0x14394e0d0`.

So hypothesis (a) from the brief is **structurally possible** — a `<Login>` event exists and the
client can consume it. It is *not* proven to be required (see §5).

---

## 2. Channel 2 — Blaze (Fire2 on `:42130`) — **this is where account info actually lives**

Schemas already reflected out in `auth_schema_reflection.md`; the load-bearing parts:

```
Authentication::LoginRequest   (0x14487ca10, 3)   AUTH authCode:string   EXTB externalBlob:blob
                                                  EXTI externalId:uint64
Authentication::LoginResponse  (0x14487d170, 5)   ANON NTOS SESS SPAM UNDR
  SESS = UserLoginInfo (0x14487cb00, 8)           KEY_ sessionKey  BUID blazeUserId  UID_ userId
                                                  MAIL email  PDTL personaDetails  LLOG FRST 1CON
Authentication::AccountInfo    (0x14487c810, 16)  <- reply of getAccount (1/0x1E), request is EMPTY
  AMU anonymousUser:bool   ASRC authenticationSource:string   CO country:string   DOB dOB:string
  DTCR dateCreated:string  GOPT globalOptin:int8              LATH lastAuth:string
  LN language:string       MAIL email:string      PML parentalEmail:string   RC reasonCode:enum
  STAS status:enum         STAT emailStatus:enum  TPOT thirdPartyOptin:int8
  UDU underageUser:bool    UID userId:int64
Authentication::Entitlements   (0x14487d4e0, 1)   NLST list<Entitlement>   <- listUserEntitlements2 (1/0x1D)
Authentication::Entitlement    (0x14487d490, 16)  TAG entitlementTag  PRID productId  STAT status
                                                  PID personaId  GDAY grantDate  UCNT useCount …
```

Command ids (recovered by calling the client's own `getCommandName`, cross-checked against the
static REST binding at `0x143896a80` → `trustedLogin = 0x0B`):
`login 0x0A · trustedLogin 0x0B · listUserEntitlements2 0x1D · getAccount 0x1E · getAuthToken 0x24 ·
listPersonaEntitlements2 0x30 · expressLogin 0x3C · logout 0x46 · getPersona 0x5A · listPersonas 0x64 ·
getOriginPersona 0x104`.

**Observed wire behaviour (14:46 session):**
`Util::preAuth (9/0x07)` ✓ → `Util::ping` ✓ → 6× `Util::fetchClientConfig` (`OSDK_CORE`,
`OSDK_CLIENT`, `OSDK_NUCLEUS`, `OSDK_WEBOFFER`, `OSDK_ABUSE_REPORTING`, `OSDK_XMS_ABUSE_REPORTING`) ✓
→ **`Authentication::logout (1/0x46)`, empty payload** → disconnect → 3-second transport-ping
reconnect loop forever.

`logout` has no request and no response TDF (confirmed by absence of `LogoutRequest`/`LogoutResponse`
anywhere in the client's type index). It is the OSDK `LoginStateLogout` state — i.e. **the login state
machine aborted between `LoadConfig` and `Login`.**

### 2.1 The OSDK login state machine (recovered state list)

`LoginStateMachineImpl` states, from the client's `GetStateName` thunks at `0x14719b360`+:

```
LoginStateShowMaintenance  LoginStateIsp            LoginStateLoadIspAccountInfo
LoginStateConnect          LoginStateLoadConfig     LoginStateVersionCheck
LoginStateLogin            LoginStatePCLogin        LoginStateVerifyAccount
LoginStateUpgradeAccount   LoginStateLoginComplete  LoginStateUnsuspend
LoginStateCheckUser        LoginStateRecheckUser    LoginStateWebOffer
LoginStateLogout
```

Mapped to observed traffic: `Connect` = `preAuth`; `LoadConfig` = the 6 `fetchClientConfig` calls;
then it should proceed `VersionCheck → PCLogin → Login → VerifyAccount → LoadIspAccountInfo →
LoginComplete`. It went to `Logout` instead.

Associated OSDK events (`0x143984000`+): `EVENT_LOGIN_FETCH_ACCOUNT_INFO_FAILURE` /
`…_SUCCESS`, `EVENT_LOGIN_FAILURE`, `EVENT_LOGIN_ABORTED`, `EVENT_LOGIN_QUEUED`,
`EVENT_LOGIN_TOS_NOT_ACCEPTED`, `EVENT_LOGIN_TOLLBOOTH`, …
Associated operation names (`0x1439623c0`+): **`FetchAccountInfo`**, `UpdateAccountInfo`,
`LookupOriginPersona`, `FetchOriginPersona`, `CreateOriginPersona`.

`LoginStateVersionCheck` reads three keys out of the Blaze client config —
`SV_ENABLE_SERVER_VERSIONING` `0x14395d148`, `SV_CLIENT_CHANGELIST` `0x14395d168`,
`SV_SERVER_VERSION` `0x14395d180` — and on mismatch emits
`"Client/server version mismatch!  Client is at version (%08d).  Server is at version (%08d).%s"`
(`0x14395d1d0`). **We currently return none of these keys.** Absent ⇒ almost certainly treated as
disabled, but see §6 for the cheap belt-and-braces fix.

---

## 3. Channel 3 — the FUT web API (UTAS) — real, but strictly post-login

This is a *fourth* surface the brief did not list, and it is the one that literally serves a thing
called "account info". It is **not** the current blocker (it is unreachable without a Blaze session),
but it *will* be the next wall, so it is documented here.

```
0x1438dbe88  FUT_RS4_BASE_URL          <- config key; NO hardcoded host anywhere in the image
0x1438dbe58  ut/game/%s/               <- path prefix, %s = sku ("fifa17", 0x1438dac20)
0x1438db6c0  user/accountinfo          <- THE FUT account-info endpoint
0x1438db810  users/club?sku=           <- POST body {"idList":[%I64d,…]}
0x1438db8f8  utStats?sku=
0x1438dbe48  FutServerCall / FutServerCall::RequestBuffer
0x1438dc378  FutGetUserAccountInfoServerCallConfig
0x1438dc3a0  FutGetUtStatsServerCallConfig
0x1438dc3c0  FutGetUsersClubInfoServerCallConfig
```

Request headers for `user/accountinfo` (contiguous at `0x1438db6e0`–`0x1438db731`):

```
Accept: application/json
Content-Type: application/json
Accept-Encoding: gzip
Easw-Session-Data-Nucleus-Id: %lld          <- the nucleus/user id, i.e. 33068179
```

Response JSON keys the client parses (contiguous at `0x1438db760`–`0x1438db8b0`):
`userAccountInfo` · `personas` · `userClubList` · `clubName` · `established` · `assetId` ·
`returningUser` · `userPersonaInfos` · `divisionOnline`.

A separate OSDK "SportsWorld"/EASFC HTTP module uses its own header set
(`0x14396f8b0`+): `EASW-Version: 2.0.5.0`, `EASW-Token:`, `EASW-Session:`,
`EASW-Nucleus-Persona:`, `EASW-Userid:`, `EASW-Request-Signature:`, `EASW-Content-Signature:`.

Because `FUT_RS4_BASE_URL` has no hardcoded default, **we can point the entire FUT web API at our own
HTTP server purely by serving that config key** — no DNS/DNAT needed. Worth banking now.

---

## 4. Why the `nucleusConnect` stub on `127.0.0.1:42131` is unused — answered

Two independent reasons, both proven.

### 4.1 `nucleusConnect` / `nucleusConnectTrusted` are **server-supplied config keys**, and we never send them

`0x14389fef8 = "nucleusConnect"` has exactly one reader, `0x147237862`:

```
147237830  sub rsp,0x28
147237834  call 0x1471995b0            ; get service locator
14723783f  call [rdx+0x188]            ; -> Blaze connection/config object
147237845  mov rcx,[rax+0x750]
147237855  test rcx,rcx ; je -> return 0
147237862  lea rdx,[0x14389fef8]       ; "nucleusConnect"
147237869  call [rax+0x48]             ; getConfigString(key, &out)
14723786c  mov rax,[rsp+0x38]          ; return the string
```

`[vtbl+0x48]` is the Blaze config-string getter. The value therefore comes from the **server** —
the `CONF` map in our `PreAuthResponse`, or a `fetchClientConfig` section. Our `PreAuthResponse`
`CONF` map contains only timing values (`pingPeriod` etc.) and our six `fetchClientConfig` replies
are fabricated key sets that contain no `nucleusConnect*`. **The client therefore gets an empty
string and never dials anything.** Zero requests on `:42131` is the expected, correct outcome of
what we are currently serving.

### 4.2 The Nucleus path that *does* exist is S2S/client-cert-only, and belongs to `trustedLogin`

`nucleusConnectTrusted` (`0x14389fdf8`) is read at `0x146e1658b` and immediately feeds a URL builder:

```
146e1658b  lea rdx,[0x14389fdf8]       ; "nucleusConnectTrusted"
146e16595  call [rax+0x48]             ; getConfigString
14e1659d   lea r8,[0x14389fe10]        ; "%s/connect/token"
146e165ae  call 0x146dc0950            ; snprintf(buf, 0x400, "%s/connect/token", url)
146e165db  movups xmm0,[0x14389fe28]   ; "grant_type=client_credentials"
```

Surrounding literals, contiguous, all in the BlazeSDK `LoginStateMachine` block:

```
0x14389fd90  Content-Type: application/x-www-form-urlencoded
0x14389fdc1  enable-client-cert-auth: true
0x14389fde0  LoginStateMachine
0x14389fdf8  nucleusConnectTrusted
0x14389fe10  %s/connect/token
0x14389fe28  grant_type=client_credentials
0x14389fe50  NEXUS_S2S 
0x14389fe60  "access_token" : "
0x14389fef8  nucleusConnect
```

So the shape, if it were ever used, is:

```
POST {nucleusConnectTrusted}/connect/token
Content-Type: application/x-www-form-urlencoded
enable-client-cert-auth: true
Authorization: NEXUS_S2S <credential>

grant_type=client_credentials
→ 200 {"access_token" : "…"}
```

…and the token then goes into `TrustedLoginRequest {ID_ id, ITYP idType, TOKN accessToken}` =
**`Authentication::trustedLogin (1/0x0B)`**, whose REST binding at `0x143896a80` confirms the shape
(`GET`, headers `Authorization: accessToken`, `X-Forwarded-UserType: idType`,
`X-Forwarded-UserId: id`).

**This is the console/dedicated-server trusted path. It requires a client certificate
(`enable-client-cert-auth: true`) and is not what the PC/Origin build uses.** The PC build uses
`login (1/0x0A)` with `AUTH = <Origin auth code>`.

### 4.3 The hardcoded EA account hosts are for the web UI, not for login

```
0x143b8b528  https://accounts.int.ea.com/     0x143b8b588  https://accounts.ea.com/
0x143b8b548  https://gateway.int.ea.com/      0x143b8b5a8  https://gateway.ea.com/
0x143b8b568  https://signin.int.ea.com/       0x143b8b5c0  https://signin.ea.com/
0x143b8b700  Nucleus::gNucleusLocale          0x143b8b718  Nucleus::gNucleusBaseUrl
0x143b8b738  Nucleus::gNucleusBaseProxyUrl    0x143b8b758  Nucleus::gNucleusBasePortalUrl
0x143b8b778  Nucleus::gNucleusClientSideRedirectUri
```

These back the EAWebKit account-management pages, reached through the OSDK WebOffer config keys
`NUCLEUS_CREATE_URL` / `NUCLEUS_ADDED_URL` / `NUCLEUS_INCOMPLETE_URL` / `NUCLEUS_CREATE_INFO_URL` /
`NUCLEUS_DUPACCT_INFO_URL` / `NUCLEUS_DEACTIVATED_INFO_URL` (`0x14395eb60`–`0x14395ec18`, sitting in
the middle of the `WEB_OFFER_URL` / `NEWS_URL` / `FAQ_URL` / `TOSA_URL` block) — i.e. the
`OSDK_NUCLEUS` `fetchClientConfig` section is **a set of account-web-page URLs**, not login plumbing.
That the game does not dial `accounts.ea.com` is therefore *correct behaviour*, not a symptom.

> **Bottom line on channel 3:** do not build a Nucleus HTTP server. If you want the `:42131` stub to
> ever receive traffic you would have to (a) advertise `nucleusConnectTrusted` in the Blaze config
> and (b) satisfy `enable-client-cert-auth` over TLS — and that would put you on the `trustedLogin`
> path, which is *not* the path this build's login state machine takes. Serve the auth code instead.

---

## 5. The dependency chain, and where it actually breaks

```
 LSX GetInternetConnectedState connected="1"        ✅ done
   -> g_originOnline @0x1443337f8 (writer 0x146f1e6b0) + FE::FIFA::OriginOnlineEvent
   -> origin.nav emits OriginIsOnlineTrue -> startFutBlazeLogin
 LSX GetGameInfo UPTODATE="true"                    ✅ done
 LSX GetConfig / GetProfile                         ✅ done -> sdk[+0x3a0]=UserId, [+0x3a8]=PersonaId
 --------------------------------------------------------------------------------
 OSDK LoginStateConnect   -> Blaze Util::preAuth                       ✅ answered
 OSDK LoginStateLoadConfig-> Blaze Util::fetchClientConfig × 6         ✅ answered (fabricated data)
 OSDK LoginStateVersionCheck -> SV_* keys from config                  ⚠️ keys absent
 OSDK LoginStatePCLogin   -> FirstPartyAuthTokenRetriever::DoTick
                             -> OriginGetDefaultUser()
                             -> LSX GetAuthCode(ClientId)              ❌ NEVER SENT   <<< BREAK
                          -> Blaze Authentication::login AUTH=<code>   ❌ never sent
 OSDK LoginStateVerifyAccount / LoadIspAccountInfo
                          -> Blaze getAccount 1/0x1E -> AccountInfo    ❌ unreachable
                          -> QueryEntitlements / listUserEntitlements2 ❌ unreachable
 OSDK LoginStateLoginComplete                                          ❌ unreachable
 --------------------------------------------------------------------------------
 FUT: CheckFUTRosters -> {FUT_RS4_BASE_URL}ut/game/fifa17/user/accountinfo   ❌ unreachable
```

Observed instead: `LoadConfig` → **`LoginStateLogout`** → `Authentication::logout (1/0x46)` →
disconnect → reconnect ping loop. In the most recent run the client did not even re-reach `preAuth`;
it sat in a bare PING/close loop every 3 s, i.e. the connection manager gave up.

### Ranked hypotheses for "no `GetAuthCode`", with the discriminating test for each

| # | Hypothesis | Evidence for | Evidence against | Discriminating probe |
|---|---|---|---|---|
| **H1** | The login state machine aborts *before* `LoginStatePCLogin` — i.e. nothing is ever enqueued into `DoTick`'s two slots, so `RequestAuthCodeSync` is never called. | `logout` arrives immediately after the last `fetchClientConfig`, with **no** intervening RPC and no LSX traffic. `QueryEntitlements` is *also* never issued — consistent with "the whole PC-login step never ran", not with "the auth-code call failed". | — | Breakpoint `0x146f199c0` (`DoTick`) and `0x1470db3c0`. If `DoTick` runs but both slots are null → H1 confirmed. **Do this first.** |
| **H2** | Our fabricated `fetchClientConfig` payloads are wrong/insufficient, so `LoadConfig` "succeeds" but a required key is missing and the next state fails. | All six replies contain keys we invented. `SV_ENABLE_SERVER_VERSIONING` / `SV_CLIENT_CHANGELIST` / `SV_SERVER_VERSION` are read by `LoginStateVersionCheck` and we send none. `OSDK_NUCLEUS` should be six `NUCLEUS_*_URL` keys; we send four invented `OSDK_NUCLEUS_*` keys. | Missing keys usually degrade to `""`/0 in OSDK. | Serve the corrected config (§6.1) and re-run; watch whether the client advances past `LoadConfig`. Cheap, no RE needed. |
| **H3** | The OriginSDK needs a *pushed* `<Login>` / `<OnlineStatusEvent>` event before it considers a user authenticated. | `Origin::EventHandler<lsx::LoginT, unsigned int>` exists (`0x14393f900`), element `Login` @ `0x14393d0ac`; attributes `IsLoggedIn` / `SessionInformation` / `userid` exist in the pool. Our responder never pushes anything. | The Steampunks emu never pushed events either, yet the game still got as far as `preAuth`. `OriginGetDefaultUser` is fed by `GetProfile`, *not* by the Login event (§1.2) — so the SDK's notion of "who" does not depend on it. | Push `<LSX><Event sender="EbisuSDK"><Login userid="33068179" IsLoggedIn="1"/></Event></LSX>` (encrypted, right after `ChallengeAccepted`) and see whether behaviour changes. Cheap; try alongside H2. |
| **H4** | `RequestAuthCodeSync` early-outs at the SDK-ready predicate `0x1470e2840` and returns `0xa0010000` without wire traffic. | It is the only *silent* failure path inside the auth-code call. | The same predicate guards `OriginGetDefaultUser` / `OriginGetProfile` / `OriginCheckOnline`, all of which demonstrably worked in this session. | Breakpoint `0x1470db3f7`; check `al` after `0x1470e2840`. Only worth doing if H1's `DoTick` probe shows the call *is* being made. |

H1 is by far the most likely. H2 is the cheapest thing that could plausibly cause H1.

---

## 6. What we must serve

### 6.1 Blaze `Util::fetchClientConfig` — replace the invented keys

Serve authentic key *names* (values can be conservative). Recovered key names, by section:

* **`OSDK_CORE`** — include the version-check trio explicitly so nothing is ambiguous:
  `SV_ENABLE_SERVER_VERSIONING = 0`, `SV_CLIENT_CHANGELIST = 0`, `SV_SERVER_VERSION = 0`.
  Keep `OSDK_PRESENCE_DELAY = 5`, `OSDK_PRESENCE_POLL = 60` (real key names, `0x143962848`/`0x143962860`).
* **`OSDK_NUCLEUS`** — the *real* keys are web-page URLs, not the `OSDK_NUCLEUS_*` we invented:
  `NUCLEUS_CREATE_URL`, `NUCLEUS_ADDED_URL`, `NUCLEUS_INCOMPLETE_URL`, `NUCLEUS_CREATE_INFO_URL`,
  `NUCLEUS_DUPACCT_INFO_URL`, `NUCLEUS_DEACTIVATED_INFO_URL` (`0x14395eb60`–`0x14395ec18`).
  Empty strings are fine and honest; invented `OSDK_NUCLEUS_ENABLED=1` is not.
* **`OSDK_WEBOFFER`** — real keys: `WEB_OFFER_URL`, `NEWS_URL`, `NEWS_TIME_STAMP_URL`, `FAQ_URL`,
  `TOSA_URL`, `TOSAC_URL`, `MENU_ESPN_URL`, `MENU_WEBGM0_URL`…`MENU_WEBGM2_URL`.
* **`OSDK_ABUSE_REPORTING` / `OSDK_XMS_ABUSE_REPORTING`** — `OSDK_ABUSE_REPORTING_ENABLED = 0`,
  `OSDK_ABUSE_NUM_TYPES = 0` (already correct).
* **`OSDK_CLIENT`** — the `OSDK_CLUBS_*` limits we already send are real key names.
* Consider adding **`FUT_RS4_BASE_URL = http://127.0.0.1:<port>/`** — see §6.4.

### 6.2 LSX `GetAuthCode` — be ready the instant it is asked

```xml
<LSX><Response id="N" sender="EbisuSDK">
  <AuthCode Code="QUXbLm3…opaque…" Return="QUXbLm3…opaque…"/>
</Response></LSX>
```

Emit **both** `Code` and `Return` until the log shows which one the client consumes (the attribute
pool position between `ClientId` and `connected` is suffix-shared, so `Code` is the strong
candidate). The code is opaque — we author both ends — but it **must be echoed verbatim into
`LoginRequest.AUTH`** and accepted there. Log the incoming `ClientId` value; that tells us which EA
client id FIFA 17 presents and is worth recording.

### 6.3 LSX `QueryEntitlements` — pre-stage the answer

```xml
<LSX><Response id="N" sender="EbisuSDK"><QueryEntitlementsResponse>
  <OriginItem ItemId="ONLINE_ACCESS" EntitlementId="1" ResourceId="1027460" OfferId="1027460"
              GrantDate="2016-09-01T00:00:00Z" bIsOwned="true" Uses="0"/>
</QueryEntitlementsResponse></Response></LSX>
```

### 6.4 Blaze `Authentication` — the account-info replies to have ready

| Cmd | Reply | Must contain |
|---|---|---|
| `login 0x0A` | `LoginResponse` | `ANON=0 NTOS=0 UNDR=0 SPAM=1`; `SESS.KEY_` non-empty; `SESS.BUID = SESS.UID_ = 33068179`; `SESS.PDTL.PID_ = 33068179`; `SESS.PDTL.DSNM = "CAGE"`; `SESS.PDTL.STAS = 0`; `SESS.PDTL.PLAT` = the `PLAT` from `PreAuthResponse` |
| `getAccount 0x1E` | `AccountInfo` (empty request) | `UID = 33068179`, `CO = "US"`, `LN = "en_US"`, `MAIL` = any well-formed address, `STAS` = active, `STAT` = verified, `UDU = false`, `AMU = false`, `ASRC = "cem_ea_id"` (matches the `NASP` we already return in `PreAuthResponse`), `DTCR` / `LATH` ISO-8601 |
| `listPersonas 0x64` | `ListPersonasResponse` | one persona: id `33068179`, name `CAGE`, status active |
| `getPersona 0x5A` | `GetPersonaResponse` | same single persona |
| `listUserEntitlements2 0x1D` | `Entitlements` | one `Entitlement`: `TAG = "ONLINE_ACCESS"`, `PRID` tied to offer `1027460`, `PID = 33068179`, `STAT` active |
| `logout 0x46` | empty REPLY | already correct — but treat its arrival as the failure signal it is |

Also serve `UserSessions` notification `UserAuthenticated (0x08)` after login (notification ids
already decoded: `0x141b03f70`).

### 6.5 FUT web (`{FUT_RS4_BASE_URL}ut/game/fifa17/user/accountinfo`) — the next wall, pre-built

```
GET  {FUT_RS4_BASE_URL}ut/game/fifa17/user/accountinfo
     Accept: application/json
     Content-Type: application/json
     Accept-Encoding: gzip
     Easw-Session-Data-Nucleus-Id: 33068179

200 {"userAccountInfo": {
       "personas": [{
         "personaId": 33068179, "personaName": "CAGE",
         "returningUser": 0,
         "userClubList": [{"clubName":"…","established":<epoch>,"assetId":<id>}],
         "userPersonaInfos": [], "divisionOnline": 0
       }]
    }}
```

Because `FUT_RS4_BASE_URL` has no hardcoded default, serving it as a config key is enough to point
the whole FUT web API at us — plain HTTP on `127.0.0.1` is fine, no TLS or DNAT needed.

---

## 7. Immediate next actions (ordered)

1. **Probe H1.** Relaunch, breakpoint `0x146f199c0` (`FirstPartyAuthTokenRetriever::DoTick`) and
   `0x1470db3c0` (`RequestAuthCodeSync`). Whether `DoTick` runs at all, and whether its two slots are
   null, decides H1 vs H4 in one shot.
2. **Ship the corrected `fetchClientConfig` (§6.1)** — real key names, explicit `SV_*` trio. Cheapest
   possible fix for H2 and it removes a class of ambiguity permanently.
3. **Add `GetAuthCode` + `QueryEntitlements` responses (§6.2/6.3)** to `lsx_responder.py` so the
   moment the client asks, it is answered — and log the `ClientId` it presents.
4. **Try the pushed `<Login>` event (§H3)** — one extra encrypted frame after `ChallengeAccepted`.
   Low cost, and it is the only untested structural difference between us and a real Origin client.
5. Keep the Nucleus HTTP stub on `:42131` parked. It is on the `trustedLogin`/client-cert path and is
   not what this build uses.

---

## Appendix — addresses

| What | VA |
|---|---|
| `FifaOnline::FirstPartyAuthTokenRetriever::DoTick` | `0x146f199c0` |
| `Origin::OriginSDK::RequestAuthCodeSync` | `0x1470db3c0` |
| … its SDK-ready predicate (wire-silent bail) | `call 0x1470e2840` @ `0x1470db3f7` |
| … its impl call | `call 0x1470e67f0` @ `0x1470db41d` |
| `OriginGetDefaultUser()` → `sdk[+0x3a0]` | `0x1470da6d0` |
| `OriginGetDefaultPersona()` → `sdk[+0x3a8]` | `0x1470da680` |
| `Origin::OriginSDK::Initialize` — writes `+0x3a0`/`+0x3a8` from `GetProfile` | `0x1470e5ad5` / `0x1470e5ae1` |
| sync `GetProfile(index=0)` helper (timeout `0x3a98` = 15 s) | `0x147118d80` |
| OriginSDK ctor zeroing `+0x3a0`/`+0x3a8` | `0x1470deb2f` / `0x1470deb36` |
| `"[%s] Invalid authcode"` / `"[%s] Origin Error(%d)"` | `0x1438f5e00` / `0x1438f5e18` |
| `"OriginRequestAuthCodeSync entered"` | `0x143936158` |
| `nucleusConnect` (config key) / its only reader | `0x14389fef8` / `0x147237862` |
| `nucleusConnectTrusted` / its reader | `0x14389fdf8` / `0x146e1658b` |
| `%s/connect/token` · `grant_type=client_credentials` · `enable-client-cert-auth: true` · `NEXUS_S2S ` | `0x14389fe10` · `0x14389fe28` · `0x14389fdc1` · `0x14389fe50` |
| `trustedLogin` REST binding (`GET`, `Authorization`/`X-Forwarded-*`) | `0x143896a80` |
| LSX **event** element-name table (incl. `Login` @ `0x14393d0ac`) | `0x14393cfd8`–`0x14393d208` |
| `Origin::EventHandler<lsx::LoginT,unsigned int>::HandleMessage` | `0x14393f900` |
| `Origin::EventHandler<lsx::OnlineStatusEventT,bool>::HandleMessage` | `0x143940050` |
| LSX event dispatch / element-name compare | `0x1471028ee` |
| LSX request element table / attribute pool | `0x14394dc00` / `0x14394de00` |
| `"EbisuSDK"` / `"EALS"` service names | `0x143937d58` / `0x143937c60` |
| OSDK login-state name thunks | `0x14719b360`+ |
| `SV_ENABLE_SERVER_VERSIONING` / `SV_CLIENT_CHANGELIST` / `SV_SERVER_VERSION` | `0x14395d148` / `0x14395d168` / `0x14395d180` |
| version-mismatch message | `0x14395d1d0` |
| OSDK config section names (`OSDK_CORE`…`OSDK_TICKER`) | `0x143962be8`–`0x143962c40` |
| OSDK operations `FetchAccountInfo` / `UpdateAccountInfo` | `0x1439623c0` / `0x1439623d8` |
| `EVENT_LOGIN_FETCH_ACCOUNT_INFO_FAILURE` / `_SUCCESS` | `0x1439840b8` / `0x1439840e0` |
| `NUCLEUS_*_URL` config keys (OSDK_NUCLEUS section) | `0x14395eb60`–`0x14395ec18` |
| FUT `FUT_RS4_BASE_URL` / `ut/game/%s/` / `user/accountinfo` | `0x1438dbe88` / `0x1438dbe58` / `0x1438db6c0` |
| FUT `Easw-Session-Data-Nucleus-Id: %lld` | `0x1438db731` |
| FUT response JSON keys (`userAccountInfo`…`divisionOnline`) | `0x1438db760`–`0x1438db8b0` |
| EASW/SportsWorld header block | `0x14396f8b0`–`0x14396fa50` |
| hardcoded `accounts/gateway/signin.ea.com` (web UI only) | `0x143b8b528`–`0x143b8b5c0` |
| `Nucleus::gNucleusBaseUrl` & friends | `0x143b8b700`–`0x143b8b778` |
| Blaze `AccountInfo` / `LoginRequest` / `LoginResponse` descriptors | `0x14487c810` / `0x14487ca10` / `0x14487d170` |

Tools written this pass (all in `…/scratchpad/`): `acct_probe1.py` (CommandInfo neighbourhood dump),
`strdump.py` (string run at a VA), `wsearch.py` (ASCII+UTF-16 phrase search), `navdump.py`
(nav-flow JSON extractor). Reused: `memtool.py`, `strsearch.py`, `xref.py`, `dis.sh`, `cmdinfo.py`.