# FIFA 17 Blaze `Util::preAuth` — reflection-reversed schema

**Date:** 2026-07-30 · **Method:** live `/proc/<pid>/mem` reflection walk of `FIFA17.exe` (PID 7618, alive throughout) + targeted disassembly of the response handler.

## Clean-room provenance

Everything below came from one of three sources, all allowed:

1. **The client's own runtime reflection metadata**, read out of the process we own. FIFA 17's BlazeSDK ships full TDF type descriptors (class names, member names, wire tags, struct offsets) in `.data`. This is the bulk of the findings.
2. **Disassembly of code in the binary we own** (`ConnectionManager::onPreAuthResponse` and the Util component's `getCommandName` switch).
3. **Our own captured wire bytes** (`fifa17-recon/captures/blaze/*.bin`).

One item — the Fire2 header field layout — was **cross-checked** against three independent third-party clean-room BlazeSDK-15.x reimplementations cloned in the scratchpad (`pamplona-future`, `catalyst-mitm`, `grid-blaze`, all Mirror's Edge Catalyst / Mass Effect era). That is flagged inline. **No EA/FIFA leaked source was consulted at any point.**

---

## 0. Correction: the Fire2 header layout we were using is wrong

Our working assumption was `[10:12]=u16 error/msgId, [12]=u8 msgType`. That is **incorrect**, and it matters: a reply built with it would put the message type in the wrong byte and drop the sequence number, so the client would never match the reply to its pending request.

Correct 16-byte header (all big-endian):

| Bytes | Field |
|---|---|
| `[0:4]` | u32 payload length |
| `[4:6]` | u16 metadata length (always 0 observed) |
| `[6:8]` | u16 component |
| `[8:10]` | u16 command |
| `[10:13]` | **u24 msgNum** (3 bytes, not 2) |
| `[13]` | **msgType << 5** |
| `[14]` | options |
| `[15]` | reserved |

`msgType`: `0=MESSAGE 1=REPLY 2=NOTIFICATION 3=ERROR_REPLY 4=PING 5=PING_REPLY`.

**Evidence this is right, independent of the reference repos:** byte `[12]` across our 8 captured frames takes the values `0,1,2,3,4,5,6,7` — a monotonic counter, alternating `preAuth`(even) / `ping`(odd). Under the old reading that would be eight different "message types", which is nonsense. Under the new reading every captured frame is `msgNum = 0..7, msgType = 0 (MESSAGE)` — i.e. all eight are client *requests*, which is exactly what we expect since we never replied. This also retires the earlier "ping/pong msgType 0x01/0x03" note: both 16-byte frames are plain `Util::ping` **requests** (command 0x0002, see §2), not a ping/pong pair.

`heat2.py`'s `build_fire2_frame` / `parse_fire2_frame` still encode the old layout and should be replaced by the versions in `build_preauth_response.py`. Its **TDF value encoding is fine** — it round-trips the 219-byte capture byte-for-byte.

---

## 1. `Blaze::Util::PreAuthResponse` — 14 members

Descriptor at VA `0x144875600`, member table `0x144874a90`, count 14. Members are listed and must be **serialized in ascending packed-tag order** (which is what the table itself is sorted by, and what the captured request does).

| Tag | Member name | TDF type | Wire type | Struct offset | Confidence |
|---|---|---|---|---|---|
| `ASRC` | `authenticationSource` | string | `0x01` | +0x1d8 | certain |
| `CIDS` | `componentIds` | list\<uint16\> | `0x04` | +0x070 | certain |
| `CLID` | `clientId` | string | `0x01` | +0x058 | certain |
| `CONF` | `config` | `Blaze::Util::FetchConfigResponse` | `0x03` | +0x0b8 | certain |
| `ESRC` | `entitlementSource` | string | `0x01` | +0x228 | certain |
| `INST` | `serviceName` | string | `0x01` | +0x040 | certain |
| `MAID` | `machineId` | uint32 | `0x00` | +0x240 | certain |
| `MINR` | `underageSupported` | bool | `0x00` | +0x220 | certain |
| `NASP` | `personaNamespace` | string | `0x01` | +0x1c0 | certain |
| `PILD` | `legalDocGameIdentifier` | string | `0x01` | +0x208 | certain |
| `PLAT` | `platform` | string | `0x01` | +0x028 | certain |
| `QOSS` | `qosSettings` | `Blaze::QosConfigInfo` | `0x03` | +0x120 | certain |
| `RSRC` | `registrationSource` | string | `0x01` | +0x1f0 | certain |
| `SVER` | `serverVersion` | string | `0x01` | +0x010 | certain |

Tag decoding is validated: the request's four member tags round-trip exactly (`0x8e4874`→`CDAT`, `0x8e9ba6`→`CINF`, `0x9a38f2`→`FCCR`, `0xb21924`→`LADD`), matching the capture.

### Nested types

```
Blaze::Util::FetchConfigResponse            (CONF, 1 member)
  CONF  config                 map<string,string>

Blaze::QosConfigInfo                        (QOSS, 4 members)
  BWPS  bandwidthPingSiteInfo  Blaze::QosPingSiteInfo (struct)
  LNP   numLatencyProbes       uint16
  LTPS  pingSiteInfoByAliasMap map<string, Blaze::QosPingSiteInfo>
  TIME  timeout                TimeValue (int, microseconds)

Blaze::QosPingSiteInfo                      (2 members)
  PSA   address                string
  PSP   port                   uint16
```

Note `CONF` nests a struct whose single member is *also* tagged `CONF` — the outer is the `FetchConfigResponse` struct, the inner is the map. Easy to get wrong.

**Map key/value order:** the key descriptor is at `+0x28`, the value at `+0x30`. The binary's own `map<A,B>` *name string* is written **value-first**, so it reads backwards — don't trust it. Confirmed against two maps whose semantics are unambiguous: `pingSiteLatencyByAliasMap` is named `map<int32_t,string>` but is really `map<string alias, int32 latency>`; `permissionsByComponent` is named `map<list<string>,string>` but is really `map<string component, list<string> permissions>`. So `LTPS` = `map<string, QosPingSiteInfo>`.

### Request side, for reference

`Blaze::Util::PreAuthRequest` (4 members) — matches our capture exactly, which is what validated the whole descriptor-walking method:

| Tag | Member | Type |
|---|---|---|
| `CDAT` | `clientData` | `Blaze::Util::ClientData` |
| `CINF` | `clientInfo` | `Blaze::ClientInfo` (10 members) |
| `FCCR` | `fetchClientConfig` | `Blaze::Util::FetchClientConfigRequest` { `CFID` configSection: string } |
| `LADD` | `localAddress` | uint32 |

`Blaze::Util::ClientData` = { `IITO` ignoreInactivityTimeout: bool, `LANG` locale: uint32, `SVCN` serviceName: string, `TYPE` clientType: enum }.

---

## 2. Util component RPC table — **complete**

Component id **0x0009**, confirmed directly in the binary: the Util notification dispatcher compares against `0x00c80009`, `0x00980009`, `0x00640009`, `0x00960009`, `0x00970009` — i.e. `(notificationId << 16) | 9`.

Recovered by locating the compiler-generated `getCommandName(commandId)` switch: 21 `lea rax,[rip+name]; ret` stubs emitted in alphabetical order at RVA `0x1b17a43 + 8k`, plus a jump table of 28 entries at VA `0x146df72f4` indexed by `commandId - 1`.

| Command | RPC | Command | RPC |
|---|---|---|---|
| `0x0001` | `fetchClientConfig` | `0x000f` | `userSettingsLoadMultiple` |
| `0x0002` | **`ping`** ✅ | `0x0010`–`0x0013` | *(unused)* |
| `0x0003` | `setClientData` | `0x0014` | `filterForProfanity` |
| `0x0004` | `localizeStrings` | `0x0015` | `fetchQosConfig` |
| `0x0005` | `getTelemetryServer` | `0x0016` | `setClientMetrics` |
| `0x0006` | `getTickerServer` | `0x0017` | `setConnectionState` |
| `0x0007` | **`preAuth`** ✅ | `0x0018` | *(unused)* |
| `0x0008` | `postAuth` | `0x0019` | `getUserOptions` |
| `0x0009` | *(unused)* | `0x001a` | `setUserOptions` |
| `0x000a` | `userSettingsLoad` | `0x001b` | `suspendUserPing` |
| `0x000b` | `userSettingsSave` | `0x001c` | `setClientState` |
| `0x000c` | `userSettingsLoadAll` | | |
| `0x000d` | *(unused)* | | |
| `0x000e` | `deleteUserSettings` | | |

**This table is self-validating**: it independently reproduces both values we observed on the wire — `ping = 0x0002` and `preAuth = 0x0007`. Confidence: high.

### Request/response type mapping (from the reflection type index)

| Command | Request | Response |
|---|---|---|
| `0x0002` ping | *(empty)* | `Blaze::Util::PingResponse` { `STIM` serverTime } |
| `0x0007` preAuth | `PreAuthRequest` | `PreAuthResponse` |
| `0x0008` postAuth | `PostAuthRequest` { `DSUI` dirtySockUserIndex: int32, `UDID` uniqueDeviceId: string } | `PostAuthResponse` |
| `0x0001` fetchClientConfig | `FetchClientConfigRequest` { `CFID` } | `FetchConfigResponse` { `CONF` map } |
| `0x0015` fetchQosConfig | *(empty)* | `QosConfigInfo` |

`Blaze::Util::PostAuthResponse` (3 members) — **the next thing we'll need**:

```
TELE  telemetryServer  Blaze::Util::GetTelemetryServerResponse  (15 members)
        ADRS address:string   ANON isAnonymous:bool   DISA disable:string
        EDCT enableDisconnectTelemetry:bool           FILT filter:string
        LOC  locale:uint32    MINR underage:bool      NOOK noToggleOk:string
        PORT port:uint32      SDLY sendDelay:uint32   SESS sessionID:string
        SKEY key:string       SPCT sendPercentage:uint32
        STIM useServerTime:string                     SVNM telemetryServiceName:string
TICK  tickerServer     Blaze::Util::GetTickerServerResponse
        ADRS address:string   PORT port:uint32        SKEY key:string
UROP  userOptions      Blaze::Util::UserOptions
        TMOP telemetryOpt:enum                        UID  userId:int64
```

### Component ids (recovered from each component's notification dispatcher)

`Authentication=1`, `GameManager=4`, `Redirector=5`, `Util=9`, `GameReporting=28`, `UserSessions=30722`. FIFA-custom components (`CoopSeason`, `EaAccess`, `Easfc`, `FifaCups`, `SponsoredEvents`, `VProSPManagement`, `OSDKSettings`, `OSDKTournaments`, `OsdkArena`) live in the `2069/2070/2077`… range; I did not separate them individually (their dispatchers are adjacent and my scan window overlapped). `Stats`, `Clubs`, `Messaging`, `Mail`, `AssociationLists`, `GpsContentController`, `CensusData` are also linked in.

---

## 3. What the client actually *does* with the response

`ConnectionManager::onPreAuthResponse(this, PreAuthResponse* r /*rdx*/, errorCode /*r8d*/)` at **VA `0x146e1cf10`**. Signature confirmed because every `[r14+offset]` it touches matches a `PreAuthResponse` member offset from §1.

The function performs **no validation whatsoever** — on the success path it only copies fields out and then advances. So the practical requirement is: *reply with a well-formed `REPLY` frame carrying the right `msgNum`.* Nothing in the body is checked for a specific value.

Field-by-field:

| Field | What happens | Mandatory? |
|---|---|---|
| `CONF` config | whole map copied into ConnectionManager `+0x11b8` | **effectively yes** — see the tunables below |
| `CIDS` componentIds | list copied to `+0x1240`; this is the client's view of which components the server has | **yes, practically** — later components look themselves up here |
| `SVER` serverVersion | `memcpy` → `+0x1288` (512-byte buf) | no, free-form |
| `PLAT` platform | `memcpy` → `+0x1488` (512-byte buf) | no, free-form |
| `INST` serviceName | `memcpy` → `+0x1688` (512-byte buf) | no — echo the request's `SVCN` (`fifa-2017-pc`) |
| `CLID` clientId | `memcpy` → `+0x1888` (512-byte buf) | no |
| `NASP` personaNamespace | `memcpy` → `+0x1a88`, **capped at 32 bytes** | no here, but auth will care |
| `RSRC` registrationSource | `memcpy` → `+0x1a?8` | no |
| `ASRC` authenticationSource | `memcpy` → `+0x1ae8` | no |
| `PILD` legalDocGameIdentifier | `memcpy` → `+0x1b28` | no |
| `MINR` underageSupported | byte → `+0x1b6c` | no |
| `ESRC` entitlementSource | `memcpy` → `+0x1b6d` | no |
| `MAID` machineId | passed to `0x146124610` | no |
| `QOSS` qosSettings | passed to QoS manager init `0x146e1c3f0` | see below |

Then it calls `0x146e1e460` and `0x146e1c3f0` (QoS start) and returns.

### The `CONF` map keys the client reads

Read at `0x146e1d0a5`–`0x146e1d1a2`, all via `ConnectionManager` vtable getters (`+0x50` = uint32, `+0x58` = TimeValue/int64, both returning "found"):

| Key | Parsing | Behaviour if absent |
|---|---|---|
| `pingPeriod` | value ÷ 1000 (so the config value is in **microseconds** → stored as ms); if result < 1000 ms, clamped to 15000 | **defaults to 15000 ms** (`0x3a98`) |
| `defaultRequestTimeout` | ÷1000 → ms, stored `+0x278` | left unchanged |
| `connIdleTimeout` | ÷1000 → ms, stored `+0xd28` | left unchanged |
| `autoReconnectEnabled` | `!= 0` → bool `+0x11b7` | left unchanged |
| `maxReconnectAttempts` | uint32 → `+0xc5c` | left unchanged |

**None of these are strictly required** — every one has a fallback. But `pingPeriod` decides how fast the client starts hammering `Util::ping` (cmd `0x0002`), so set it deliberately.

### Turning off the QoS probes — important for an offline emulator

Separate helper at `0x146e1bbc0` reads two more keys and starts from flags `= 3` (both tests on):

| Key | Effect |
|---|---|
| `enableQosFirewallTest` | if the value string equals **`"false"`** exactly (string at VA `0x14354be74`), clears bit 0 |
| `enableQosBandwidthTest` | same → clears bit 1 |

So putting `enableQosFirewallTest=false` and `enableQosBandwidthTest=false` in `CONF` stops the client trying to reach real QoS ping servers. Combined with an **empty `LTPS` map**, the QoS manager has nothing to probe. Recommended for our first working response.

---

## 4. Practical recipe

`build_preauth_response.py` implements this and self-verifies (correct header layout, all 14 fields present in tag order, decode round-trip). It reuses `heat2.py`'s validated TDF value encoders and **overrides** its Fire2 framing.

```
reply = fire2(component=0x0009, command=0x0007,
              msg_num=<echo from the request>, msg_type=REPLY(1),
              payload=preauth_response(...))
```

Produced frame for `msgNum=2`: 344 bytes, header `00 00 01 48 | 00 00 | 00 09 | 00 07 | 00 00 02 | 20 | 00 | 00`. Note byte 13 = `0x20` = `REPLY << 5`.

Body sent (all fields present; strings the client only stores are left empty or placeholder):

- `CIDS` = `[1, 4, 5, 7, 9, 15, 25, 28, 30722]`
- `CONF.CONF` = `pingPeriod=20000000`, `defaultRequestTimeout=30000000`, `connIdleTimeout=90000000`, `enableQosFirewallTest=false`, `enableQosBandwidthTest=false`
- `INST` = `fifa-2017-pc` (echo of the request's `CDAT/SVCN`)
- `QOSS` = `{ BWPS:{PSA:"127.0.0.1", PSP:17502}, LNP:10, LTPS:{}, TIME:5000000 }`
- `MAID=0`, `MINR=0`, remaining strings empty / placeholder

Right after this the client will start sending `Util::ping` (`0x0009/0x0002`) on `pingPeriod`; reply with `msgType=REPLY` and a `PingResponse { STIM: serverTime }`. `ping_reply_frame()` in the same module does that.

### Residual uncertainty

- **`NASP` / `PLAT` / `SVER` values are placeholders, not reverse-engineered.** `onPreAuthResponse` doesn't validate them, but `Authentication` (component 1) almost certainly will care about `NASP`. Expect to revisit.
- **Group-inside-list/map framing is unverified.** Our capture never exercises it, and the third-party crates disagree with some Blaze versions about a `0x02` group-start marker. This is why the recommended `LTPS` is empty — it sidesteps the question. If we later need populated `LTPS`, verify that encoding first.
- The `2069/2070/2077` FIFA-custom component ids were not individually attributed to component names.
- Varint sign convention (bit `0x40` of the first byte) is unverified; nothing in `PreAuthResponse` is signed, so it doesn't bite here.

## Tooling produced

| File | Purpose |
|---|---|
| `reflect2.py` | recursive TDF type-descriptor walker (`raw` / `walk` / `byname` / `index`) |
| `build_preauth_response.py` | corrected Fire2 framer + PreAuthResponse/PingResponse builders, self-testing |

### Reflection metadata layout (for reuse)

Type descriptor, 64 bytes:

```
+0x00 u32 typeEnum      +0x04 u32 nameHash
+0x08 ptr fullName      +0x10 ptr shortName (interior)
+0x18 ptr auxTypeInfo   +0x20 ptr runtimeInstance
+0x28 ptr shortName2    +0x30 ptr memberTable    +0x38 u64 memberCount
```

Member entry, 48 bytes: `+0x00` member type descriptor · `+0x08` member name string · `+0x20` **u32 wire tag, 6-bit-packed in the top 3 bytes** · `+0x28` u64 byte offset within the C++ struct.

`typeEnum`: `2`=map `3`=list `4`=float `5`=enum `6`=string `7`=variable `9`=blob `10`=union `11`=**struct/class** `12`=ObjectType `13`=ObjectId `14`=TimeValue `15`=bool `16`=int8 `17`=uint8 `19`=uint16 `20`=int32 `21`=uint32 `22`=int64 `23`=uint64.

Containers keep their element types at `+0x28` (list elem / map key) and `+0x30` (map value).

Blaze reflection strings live around VA `0x143888000`–`0x1438a1000`; descriptors around `0x144860000`–`0x144890000`.