# The pack opening system, end to end

Written 2026-08-05, after six parallel reversing passes over the store, the pack
reveal and the card-disposition path, plus two adversarial verification rounds
that overturned five of the original claims. FIFA 17 was running throughout as
pid 4048 and was read strictly read-only. Nothing proposed here has been in
front of the game yet.

Slide used for every live read, re-derived and re-proven in this document's own
final check: `live = static - 0x180000000 + 0x6ffffc140000`. Controls were the
FNV hasher prologue at `0x180180d00` and the 64-byte `RS4:FutSquadSaveServerResponse`
literal at `0x18022c618`, both taken from the on-disk PE rather than asserted.
Both matched. These bases die with the process; the static addresses do not.

---

## 1. What we now know that we did not know this morning

**There is no pack-inventory endpoint in FIFA 17, and there never was.** The
client cannot list, claim or open an already-owned pack over HTTP, because no
route exists for it and no client action composes one. Three independent proofs:

- The UTAS API template array in `.rdata` at `0x18021df80..0x18021e280` holds 48
  `(path, token)` pairs. The only pack-relevant entries are `ut/%s/store`,
  `ut/v2/%s/store`, `ut/%s/purchased` and `ut/%s/item`. A regex for `ut/` over
  all 3,179,952 bytes of the PE returns 59 literals and adds nothing.
- The client action table at `0x1802caa20` (125 populated rows of 0x30 bytes,
  `{name, urlIndex, TAG, ...}`) is the complete set of requests the client can
  originate. Its pack rows are `PurchasePack` (urlIndex 0x1a), `PurchasedItems`
  (0x1a), `PurchaseItems` (0x1b), `StorePackTypes` (0x1b) and
  `StorePackQuantities` (0x1b). No claim, no list, no open.
- The pending-pack surface that *does* exist is entirely inside responses we
  already serve. `userInfo.unopenedPacks` is a counter pair that lights a game-hub
  tile, and "My Packs" is a filter over the ordinary store catalogue: entries
  whose `displayGroup.value` string equals `mypacks` (`FUN_1800150d0`, literal at
  `0x1801ec008`). Neither issues a request.

That is a negative result and it is the most valuable thing in this document,
because it deletes work rather than creating it. "Serve the pack inventory" has
been an implicit item behind the unclaimed-pack tile and the My Packs screen for
two rounds. It is not an endpoint we are missing. It is two fields on responses
we already build. The whole pack system reduces to four routes, all of which are
live today.

Four other findings change what we should do next, in descending order:

**`packOpeningAnimationEnabled` is already ON, and this contaminates yesterday's
settings-gate plan.** One reversing pass traced the flag from settings switch arm
`0x20e` through `FUN_18011dc50` to `FutDataManagerImpl+0x1fd45`, concluded the byte
defaults to zero, and recommended shipping a `/settings` row to turn it on. I read
the byte out of pid 4048 myself, at a moment when `/proc/3740/environ` carries no
`FUT_*` variables and `/tmp/utas.log` records `GET /ut/game/fifa17/settings` at
14:39:21 answered with `{"configs": []}`:

```
slot +0x2b0 -> 0x18011c500  disp 0x1fd3a (friendlySeasonsEnabled)      value = 1
slot +0x2c8 -> 0x18011c4b0  disp 0x1fd3d (enableDraftMode)             value = 1
slot +0x2e0 -> 0x18011c590  disp 0x1fd45 (packOpeningAnimationEnabled) value = 1
```

A whole-`.text` disassembly scan shows `FUN_18011dc50` is the only writer of any
byte in `0x1fd28..0x1fd50`, so the applier ran and the settings struct it was
handed simply defaults those fields to 1. Two consequences. The proposed
`packOpeningAnimationEnabled` row is a no-op, so if the reveal animation is not
playing the cause is one of the other four terms of the gate. And
`docs/plan-2026-08-05-settings-gate.md` section 1 asserts that
`IS_FRIENDLY_SEASON_ENABLED` and `IS_DRAFT_MODE_ENABLED` "have never been set to
true by anything, on any run". Measured, both are 1. That premise is false for
this struct, and the Seasons diagnosis built on it needs redoing before that
launch is spent.

**`duplicateItemIdList` is an array of objects, and both places the docs describe
it are wrong in a freeze-risky direction.** Element parser `0x180138e10` reads
`itemId` (0x16d), `duplicateItemId` (0xeb), `itemLoans` (0x16f) and
`duplicateItemLoans` (0xed) into 0x20-byte records. `ENDPOINT_MAP.md:1095` and
`:218` both call it an int list. The same binary provides the control that this is
not a misread: `dreamSquads` (0xe9) in `FutMoveCard` genuinely is a bare int array,
parsed by a `while (tok != 0xd)` loop calling the int getter directly, with no
inner object loop. We currently serve `[]`, which is safe, so this is a documentation
bug rather than a live bug. It becomes a live bug the moment somebody implements
duplicates from the map as written.

**`FutDiscardCardServerResponse` is `{"items":[{"id":N}], "totalCredits":N}`, and
quick sell currently pays nothing.** `items` (0x171) is an array of OBJECTS; there
is no top-level `id` key. `ENDPOINT_MAP.md:968-971` documents
`{"items":[123456789], "totalCredits":15000, "id":123456789}`, which is the wrong
shape twice over. Separately, the client sends a bulk discard as
`{"itemId":[id, id, ...]}` (atom 0x16d) and a single discard with the id in the URL
as `/%llu`, and `quick_sell_route()` in `utas_server.py` parses neither: it looks
for `itemData` and `itemIds`. The route regex `/ut/delete/game/[^/]+/item` is
unanchored, so a URL-suffix discard still *matches* the route; the id is simply
never extracted. `ids` comes out empty, `STORE.quick_sell([])` sells nothing, and
the response is a bare `{}` with no `items` array, so the client's own local removal
(model slot +0xa30, driven by the ids it parses back) never fires either.

**Two readings collide here and I am not going to smooth it over.** The static
reading above says a quick sell today is a complete no-op. The docstring on
`quick_sell_route()` records a *live observation* from 2026-08-04 saying the
opposite: "nothing was credited, so a quick sell destroyed the cards for 0 coins."
Both cannot be true of the code as it now stands. I would bet on the static reading,
for two reasons: the code path is short enough to read end to end and it cannot
remove a card it has no id for, and the docstring is describing the state that
*prompted* the handler to be written, when the path was unmapped and answered with a
generic body. But "the cards visibly disappeared from the reveal screen" is also
exactly what a client-side removal looks like before a reload puts them back, and
nobody has checked the save file after a quick sell. Section 7 step 4 settles it for
the cost of one menu action, and until it does, treat "quick sell destroys nothing"
as the more likely of two live possibilities rather than as established.

**The FIFA 17 retail pack catalogue is recoverable from the running client and
nowhere else.** 41 complete `<consumable serverId="N">` records from
`data/store/storecfg.xml` are sitting in the heap at `0x3dabe000..0x3dac7000`,
each with a numeric server id, a display name, an Origin offer id and an
entitlement id of the form `FIFA17FUTPACKnnn`. The text is not in CardsDLL, not in
the packed exe, not in `stp-origin_emu.dll`, and not in any of 256 files totalling
3.24 GiB scanned under the game install. It will be unrecoverable when this process
exits. The full table is in section 5.

---

## 2. The pack opening system, end to end

Everything below is graded CONFIRMED (read from the binary or observed on the
wire), INFERRED (a chain of reasoning with no single decisive observation), or
UNKNOWN. Addresses are static CardsDLL VAs at base `0x180000000`.

### 2.1 Catalogue

**CONFIRMED.** `GET ut/%s/store/purchasegroup/all?ppInfo=true`, built by
`FUN_180123430` from three literal appends. Response class
`FutStoreGetPackTypesServerResponse`, root deser `0x1801234e0`, which reads
`purchase` (0x260, array) and `timestamp` (0x31b, int).

Each element goes to the pack deser `0x18013af30`, which fills a 0x158-byte record.
**Only the first 100 elements survive**: at `0x18013bb02` a `CMP EDX,0x64` after
dividing the vector span by 0x158 jumps past both push_back paths straight to the
record destructor at `0x18013bb49`. Elements 101 and up are fully parsed and thrown
away, silently.

The dispatch is a pre-table ladder plus an MSVC jump table at `0x18013b792`
(`LEA EAX,[R15-0x20f]` / `CMP EAX,0x89`, byte index table at `0x18013bcb4`, seven
targets at `0x18013bc98`). Decoding that table settles the "these atoms are skipped"
question independently of any decompiler. Field map, all offsets relative to the
0x158-byte record:

| key | atom | getter | offset | note |
|---|---|---|---|---|
| `assetId` | 0x23 | INT | +0x74 | the real pack identity |
| `id` | 0x15c | INT via `0x1800d7b10` | +0x70 | **u16 store**, values above 65535 truncate |
| `description` | 0xd1 | STR | | tile caption |
| `sortPriority` | 0x2cb | INT | +0x7c | |
| `firstPartyStoreId` | 0x127 | **STR then `atoi()`** | +0x78 | int here is the documented freeze |
| `displayGroup` | 0xd9 | **flat OBJECT** | | `value` (0x377, STR) to +0x00, `priority` (0x250, INT) to +0x34 |
| `currencies` | 0xc5 | ARRAY | +0x40..+0x48 | 0x30-byte records via `0x180138bd0` |
| `extPrice` | 0x119 | OBJECT | | see below |
| `packContentInfo` | 0x20c | flat OBJECT | +0x144..+0x154 | exactly five children |
| `state` | 0x2eb | STR vs `"active"` | +0xb0 | ctor default 0, i.e. not active |
| `start` | 0x2e3 | INT, non-negative clamp | +0xb4 | **top level, not in packContentInfo** |
| `end` | 0x102 | INT | +0xb8 | |
| `quantity` | 0x26b | INT | +0xbc | a sent 0 is rewritten to -1 |
| `purchaseLimit` | 0x265 | INT | +0xc0 | |
| `purchaseCount` | 0x261 | INT | +0xc4 | |
| `saleType` | 0x298 | STR to enum | +0xc8 | `NONE` 0, `QUANTITY` 1, `TIME` 2, `TIME_QUANTITY` 5, anything else 0 |
| `dealType` | 0xcc | STR, lowercased | +0xcf/+0xd0 | compared against `promo` and a 4-char literal |
| `useDefaultImage` | 0x36a | BOOL, **stored inverted** | +0xcc | |
| `unopened` | 0x35d | BOOL, raw | +0xcd | **top level, not in packContentInfo** |
| `isPremium` | 0x176 | BOOL | +0xce | |
| `packType` | 0x20f | STR | +0x108 | ctor default `"INVALID"` |
| `visible` | 0x37d | **no getter at all** | +0x138 | one instruction, `MOV byte [RBP+0x88],1`; presence sets it, the value is never read |
| `points` | 0x240 | INT | +0x140 | |

`packContentInfo` has exactly five children and nothing else:
`itemQuantity` 0x170 to +0x144, `goldQuantity` 0x149 to +0x148, `silverQuantity`
0x2c6 to +0x14c, `bronzeQuantity` 0x63 to +0x150, `rareQuantity` 0x273 to +0x154.
Any other key inside it reaches the safe SKIP at `0x180135ff0`. Our
`_pack_body()` sends `"unopened": false` inside it, which is therefore inert.

`extPrice` is documented wrong. `finalPrice` (`0x180139070`) and `originalPrice`
(`0x18013aae0`) are 152 instructions each and contain exactly one atom comparison
apiece, `CMP r,0x11a`. Neither reads `amount` (0x1b) or `currency` (0xc4). The one
key each reads is `externalPriceId` (0x11a, INT). `finalPrice` also writes its value
straight into the pack's `firstPartyStoreId` slot at +0x78, so `extPrice.finalPrice`
and the top-level `firstPartyStoreId` are the same slot reached two ways.

Currency elements (`0x180138bd0`, stride 0x30): `name` 0x1d0 STR, `funds` 0x134 INT,
`finalFunds` 0x124 INT, both ints through the non-negative clamp `0x1800d7b30` (a
negative price silently becomes 0). The tile adapter takes the **coin** price from
`finalFunds` and ignores `funds`; it takes the mtx price from `funds` and then
overwrites it with the platform-store price anyway.

**Consumer, and the verdict on packContentInfo: DECORATIVE. CONFIRMED.**
Exactly one function in CardsDLL reads those five slots, `FUN_18002c3c0`, a
record-to-tile adapter with a single code caller, `FUN_1800150d0`. It is a straight
MOV-to-MOV copy into view model +0xc0..+0xd0 with no arithmetic and no comparison.
An operand-text census over 13,308 functions and 469,335 instructions finds exactly
three functions carrying all five offsets: that adapter, the vector copy
`0x180133210` and the copy-assign `0x1801340e0`. Nothing anywhere compares the
declared quantities against a delivered item list. `open_pack()` does not have to
honour the declared distribution. It should eventually, because the numbers are
rendered on the tile, but it is cosmetic and can be parked.

### 2.2 Purchase

This is the part where the static reports and the wire disagreed, and the wire wins.

**CONFIRMED, observed live this session.** At 14:39:28 on every boot the client
sends:

```
PUT /ut/v2/game/fifa17/store/transaction/0
body: {"state":"TRANSACTIONCANCEL"}
```

That is unmistakably the `PurchaseItems` request serializer `FUN_180126440`: it
always emits `state` (0x2eb) from the 9-entry table at `0x1802d02c0`, and the URL
builder `FUN_180126720` appends `/transaction` and then `/<transactionId>` as `%lld`
whenever the state enum exceeds 1 (`TRANSACTIONCANCEL` is 7, the transaction id is
0). One reversing pass concluded that this first-party checkout path "an offline
emulator with no platform store will never see". It fires on every boot. The
`state == "TRANSACTIONCANCEL"` branch in `store_buy()` is live code, not dead code,
and it is the reason no phantom pack opens at startup.

**Two distinct classes, chosen client-side. CONFIRMED.** `CreatePack` (ctor
`0x1801623d0`, call id 0x4b, vtable `0x180228270`) and `PurchaseItems` (ctor
`0x1801263a0`, call id 0x4c, vtable `0x1802202f8`) are separate ServerCall classes
with separate response factories and deserializers. The two vtables differ at slots
6, 9, 12 and 16. Nothing in any server response selects between them; there is no
fork for us to drive.

The `CreatePack` body is produced by `FUN_180162530` and has exactly four keys, all
derived from one mode integer at `this+0x20`:

```
packId (0x20b) = int
useCredits (0x369) = (mode == 0)
usePreOrder (0x36b) = (mode == 4)
currency (0xc4) = "MTX" if mode==1, "POINTS" if mode==2, else "COINS"; omitted entirely when mode==4
```

**Where the coin buy goes: INFERRED, high.** No static pass could find the URL
builder for `CreatePack`. Two independent sources agree that it is
`POST ut/%s/purchased`: the action table row `PurchasePack` carries urlIndex 0x1a,
which resolves to `ut/%s/purchased`, and the live ground truth recorded in
`utas_server.py:2557` is that FIFA sends `{"packId":1,"useCredits":1,"usePreOrder":0,
"currency":"COINS"}` and then immediately polls `GET /purchased`. So the coin buy is
`POST /purchased` with a `CreatePack` body, and `store/transaction` is the
first-party path.

**Consequence, and this one matters: the `createPackResponse` envelope has never
actually been parsed by the client. INFERRED, high.** `store_buy()` only builds it
when the body carries an integer `packId`, and the only bodies the client sends to
`store/transaction` are state bodies, so that branch never fires. Meanwhile
`POST /purchased` answers with the *request* shape (`packId`, `firstPartyStoreId`,
`groupName`, `productId`, `purchasePackType`), and `FutCreatePackServerResponse`'s
deser `0x180162880` recognises only four atoms (`duplicateItemIdList` 0xec,
`itemList` 0x16e, `numberItems` 0x1dd, `purchasedPackId` 0x264), so all of it is
skipped. The reveal gets its cards from the follow-up `GET /purchased` instead.
That works because **both responses write the same container**: the shared item
manager reached as `FUN_18011a830()` then vtable slot +0x160. `FutCreatePack`
fills it and `FutGetPurchasedItems` fills it, and we happen to be using the second.

`ENDPOINT_MAP.md` calls the `createPackResponse` body "already handled, VERIFIED
byte-exact". It is verified against `store_buy()`, not against the client. Nothing
has ever read it.

> **SUPERSEDED. Read the correction immediately below this box before using anything
> in it. The token enum in the table is right; the conclusion drawn from it is wrong.**
>
> ---
>
> ### CORRECTION, same evening, after a live test
>
> **The three tokens are `BOF`, `{`, and the FIRST FIELD NAME. Every key of a flat body
> is dispatched, including the first. Nothing is silently eaten, and key order is not
> load-bearing.**
>
> The first call to `FUN_1801c7f10` returns token **7** and consumes **no input**. It is
> a once-only start-of-document freebie, guarded by the flag at `parser+0xda` together
> with the zero character counter at `parser+0x30`:
>
> ```c
> if ((*(longlong *)(param_1 + 0x30) == 0) && (*(char *)((longlong)param_1 + 0xda) == '\0')) {
>   *(undefined1 *)((longlong)param_1 + 0xda) = 1;
>   param_1[0x34] = 7;
>   return 7;
> }
> ```
>
> So the sequence is 7 (BOF, nothing consumed), 9 (`{`), 11 (the first FIELD_NAME), and
> the key loop then dispatches starting from that first key. The `== 10` test on the
> third token is not an envelope check at all, it is the empty-object early-out: for a
> body of `{}` the third token is END_OBJECT and the function exits cleanly with its
> constructor defaults intact, which is exactly why answering `{}` has always been safe.
>
> **How it was caught.** Not by more decompiling. `GET /hub` is served as a flat two-key
> body and the superseded reading predicted its first key would be discarded. Reading
> the client's own memory settled it: `clubPlayers` came back as **205**, the value the
> server sent, at `model+0x1fd70+0x3c` (slide proven against the FNV prologue first).
> It reached its arm. The model was wrong.
>
> **Consequences of the correction.**
> * `POST /user` is fine as it stands. `login` is NOT being discarded. The claim that it
>   was, and the claim that the key order of that dict is load-bearing, are both
>   withdrawn.
> * A wrapper is not merely unnecessary for these roots, it would be actively harmful.
>   `FutCreateUser`'s ladder has arms for exactly its five atoms, so a wrapper key would
>   hash to an atom with no arm and the entire object would be skipped.
> * `createPackResponse` is now DOUBTFUL rather than confirmed. Atom `0xbe` has no arm
>   in `FUN_180162880`, and under the corrected rule the first FIELD_NAME is dispatched,
>   so wrapping would get the whole payload skipped. There is no live evidence either
>   way, because nothing has ever parsed that body (the coin buy goes through
>   `POST /purchased`). Do not "fix" the buy path on the strength of this until it can
>   be tested.
>
> **The methodological lesson, which is the reusable part.** The superseded reading was
> derived from a correct token enum and a correct call census, and it was still wrong,
> because it assumed the first tokenizer call consumed input. One live read refuted a
> chain of otherwise sound static reasoning in about a minute. Static structure tells
> you what the code can do; only the running client tells you what it did.
>
> ---
>
> **SUPERSEDED TEXT FOLLOWS, kept for the record:**
>
> **RESOLVED, 2026-08-05 evening, by `tools/ghidra_queries/q_envelope_{1,2,3}.py`.
> Reading A is correct. The envelope is structurally required. Its name is never
> checked. Reading B rested on a factual error, corrected below.**
>
> The token enum, decoded from the class table at `DAT_18023dd40` and the switch in
> the classifier `FUN_1801c67a0` (container state 2 = object, 3 = array, which is what
> the push/pop arms key off):
>
> | token | meaning | set by |
> |---|---|---|
> | 9 | START_OBJECT | case 0x64, pushes state 2 |
> | 10 | END_OBJECT | case 0x65, pops state 2 |
> | 11 | FIELD_NAME | confirmed independently by `FUN_18013bd40`, which tests `+0xd0 == 0xb` then atom-hashes `+0xf8` |
> | 12 | START_ARRAY | case 0x66, pushes state 3 |
> | 13 | END_ARRAY | case 0x67, pops state 3 |
> | 1 | error | the `caseD_78` sink |
>
> So the three unconditional tokens are **`{`, the first FIELD_NAME, and the token that
> opens that field's value**. For `{"createPackResponse":{...}}` that is 9, 11, 9, and
> the loop then reads the inner object's keys and exits on 10. The wrapper key's name is
> consumed as token 2 and never hashed, which is why the ladder has no arm for atom
> `0xbe` and does not need one. Coverage for that absence: the ladder has exactly four
> arms (`0xec`, `0x16e`, `0x1dd`, `0x264`) and `0xbe` does not occur anywhere in the
> full 4702-char decompile, printed in full.
>
> **The error in reading B.** It claimed the `/purchased` root "spends the same three
> tokens". `FUN_180124ee0` spends **two**, then hands off to `FUN_18013bd40`, which
> spends the third. The count is the same in total but it is split across two functions,
> and the sub-parser is the one that loops on FIELD_NAME. So `/purchased` never was a
> counterexample. It is `{"itemData":[...]}`, whose three tokens are 9, 11, 12, and the
> array case is handled by the sub-parser rather than by the key ladder.
>
> **The general rule, and the thing to be careful about.** A census over all 86
> begin-object callers puts 67 at exactly three tokens before the first key read. For
> those roots the first key/value pair of the body is consumed **blind**: the key is not
> hashed and not dispatched. That is harmless when the first value is an object, because
> the loop then walks that object. It silently discards data when the first value is a
> scalar. Any flat multi-key body served to a three-token root therefore loses its first
> key. `GET /hub` returns `{"clubPlayers":205,"auctionCount":0}` and is the obvious thing
> to check against this, but I could not close it here: there is no
> `RS4:FutGetHubServerResponse` literal in the image, and `clubPlayers` and
> `auctionCount` appear only as atom-table entries with no code xref, so `/hub` is not
> parsed by a generated root at all and the rule above may simply not apply to it.
> That is the next thing to look at, and it is UNKNOWN, not "fine".

**The envelope rule itself, as it stood before the resolution above: UNKNOWN, and two readings were live.** `FUN_180162880`
calls the next-token primitive three times unconditionally at `0x180162942`,
`0x18016294b` and `0x180162954`, tests only the third against token 10, and has no
arm for `createPackResponse` (atom 0xbe) anywhere in its ladder. So it descends
exactly one wrapper level without ever checking the wrapper key's name: the envelope
is structurally required and its *name* is irrelevant. The competing reading is the
verifier's, that the token count decides nothing, because `FutCreateUser`
(`0x18014cc60`), `FutDiscardCard`, `FutMoveCard` and the `/purchased` root
(`0x180124ee0` plus `0x18013bd40`) all spend the same three tokens, and we serve
`POST /user` and `GET /purchased` unwrapped and both work. I would bet on the first
reading for `CreatePack` specifically, because the three calls there are
unconditional and only the third is tested, which is a descend and not a probe. But
the two readings cannot both be right for `/purchased`, and I am not going to
pretend the contradiction is settled. Section 4 gives the one decompile that
settles it.

Incidental but useful: `200` with `{}` is genuinely safe on the buy, not
accidentally safe. For a body of `{}` the three unconditional tokens see `{`, `}`,
end-of-input, the third returns 10 and the function jumps straight to its exit with
the constructor's zeroed vectors intact.

**HTTP status. CONFIRMED.** `FUN_1801844c0` is a single status-to-error table
reached through ServerCall vtable slot 12. Only 200 maps to success. 204 maps to 99.
**Any other 2xx, including 201 and 202, falls through to 999.** 461 maps to 3, which
is what our insufficient-coins refusal already uses; most 4xx and 5xx map to 998.
`PurchaseItems` alone overrides slot 12 with `FUN_1801267b0`, which turns HTTP 409
plus a body containing the exact substring `User already has a transaction` into
code 0x70, a pending code the transaction state machine re-polls rather than
failing. Audit result: `utas_server.py` returns only 200, 404 and 461 anywhere, so
this is already clean.

**FIFA Points: out of scope, CONFIRMED.** The tile price formatter `FUN_18002cc90`
opens with `if (*(int *)(param_1 + 0x6c) == -1) return;` and then queries the
platform store catalogue for the real-money price. `tile+0x6c` is the pack's
`firstPartyStoreId`, whose constructor default is -1. Offline there is no platform
catalogue, so the points path is dead by construction and needs nothing from us.

### 2.3 Reveal

**CONFIRMED.** `FUN_1800aa440` is the whole reveal brain, registered as the handler
for UI message 9 on the pack-open sublevel (`FUN_18001eb90` loads
`gmLoadFUTPackOpenSublevel`); message `0x2742` is the teardown that broadcasts
`gmUnloadFUTPackOpenAnimation`. It walks the shared item container (model vtable
+0x160), keeps only items whose `cardtype` is 1, and picks a headline. **Neither
branch issues any HTTP request**: the whole 17,996-character decompile contains no
URL builder and no request enqueue.

The five-way AND that chooses flow transition 0x33 (play the reveal) over 0x34
(skip it):

1. a best item was found,
2. `(item->resourceId & 0xffffff) != 0`,
3. `item->cardtype == 1`,
4. the data provider has an `ASSET_ID`,
5. `FutDataManagerImpl+0x1fd45` (`packOpeningAnimationEnabled`) is non-zero.

Term 5 is measured at 1 right now. If the animation is not playing, look at terms
2 to 4. Term 2 is satisfied by what `open_pack()` already sends, since our
`resourceId` is `(version << 24) | asset`.

Selection, all client-side arithmetic over fields we already control:

- **Ranking key is `discardValue` (item+0x38, atom 0xd7), not rating.** When it is
  zero or absent the client computes its own quick-sell price into item+0x3c from
  the local `fcc_discardcoins` table keyed on `cardtype`, `level` and `rare`, scaled
  by rating and divided by 100 with round-half-up. Sending a non-zero `discardValue`
  therefore overrides EA's own economy table and directly dictates which card gets
  the walkout. `level` (item+0x54) has no JSON arm at all and is always 0.
- **Presentation tier** is `FUN_1800a9fe0(rareflag, rating)` returning 1, 2 or 3
  from a hardcoded table: rareflag 5 or 6 always 3; rareflag 0xb, 0xc and 0x15 have
  their own thresholds; everything else is rating > 89 for 3, and rating > 83 or
  exactly 74 or exactly 64 for 2. The 74 and 64 cases are the tops of the silver and
  bronze bands.
- **A special headline predicate outranks discardValue.** `FUN_1800aa330` returns
  true when `loans < 1` and (`rating > 87` or the playerid appears in the local
  `fcc_GrandStandPlayers` table). The first predicate-true item takes the headline
  regardless of value, and only another predicate-true item with a strictly greater
  value can displace it.
- **Wire order is a tiebreak only, for the summary strip.** `FUN_1800a96a0` is a
  stable descending sort on `discardValue`; the best-item scan uses strict
  greater-than so the earliest item wins ties. The underlying vector keeps wire
  order, so `random.shuffle()` in `open_pack()` is a real ordering decision for any
  screen that renders the vector directly, and a tiebreak for the strip.

`NUM_ITEMS_IN_PACK` and its four siblings are pushed to the data provider by
`FUN_180015d80` from the pack **definition** at +0xc0..+0xd0, not from the opened
item list. Whether those definition fields come off the wire is **UNKNOWN**: the
read offsets are confirmed but the sole caller `FUN_1800147f0` was not traced, and
nine unrelated functions write the same displacement group.

The community term "walkout" does not exist in this client. The single `Walkout`
string in 3.5 GiB of process memory sits between `Lineup` and `Handshake` in a
match-presentation cutscene enum.

### 2.4 Disposition

**CONFIRMED.** `duplicateItemIdList` is not inert. At the end of the createPack
parse, `FUN_180162880` runs a post-pass that walks the reveal collection and, for
every card whose id matches an entry's `itemId`, writes that entry's
`duplicateItemId` into the card object at +0x10. The reveal controller
`FUN_18009bc40` reads exactly that field: non-zero means duplicate, and the screen
fires the UI event `GotoNewItems` and issues **no request**. Zero means the normal
path, which builds a one-element `{id, pile=7, swap=0, tradeId=0}` record and submits
it through model vtable slot +0xc0. The swap flow behind the duplicate branch is
`FutMoveCard` with a per-item `swap` key (atom 0x2fe) carrying the second id.

**Quick Sell is called Discard.** There is no `quickSell` byte sequence anywhere in
CardsDLL, in any casing. Two shapes:

- single: `ut/delete/%s/item` plus `/%llu` appended by `FUN_180127570`, no body;
- bulk: `ut/delete/%s/item` with `{"itemId":[id, id, ...]}` (atom 0x16d) built by
  `FUN_180126f40`, one request for the whole batch, clamped client-side at 64.

Response `FutDiscardCardServerResponse` (deser `0x180127300`, also reachable as slot
+0x08 of the response vtable `0x180220488`): `items` (0x171) is an array of objects
each carrying `id` (0x15c), and `totalCredits` (0x326) is an int. Each parsed id is
also passed to model slot +0xa30, which removes the item from the client's local
model. There is no top-level `id`. Nothing in CardsDLL reads `totalCredits` back out
of +0x28: the response vtable's apply slot `0x180122420` is literally `return;` and
the only two xrefs to the vtable are its own constructors. So the coin figure is
server-authored and parsed, but the balance almost certainly moves via a
`GET ut/%s/user` refresh, which we already serve correctly.

**Send to Transfer List is the same route as Send to Club.** `PUT ut/%s/item`,
`FutMoveCard`, with `pile` set to `trade` instead of `club`. The pile vocabulary is
exactly three strings, decoded by `FUN_180142650`: `club` 7, `purchased` 6, `trade`
5, anything else 0.

`FutMoveCard` (`0x180128600`, 6193 characters, whole function read) parses only
`itemData` at the top level. Element keys are `id`, `pile`, `success`, `reason` and
`dreamSquads`. **It does not parse `chemistry` (0x81), and neither does
`FutMoveCardByRes` (`0x180128e30`).** The `"chemistry": true` in ENDPOINT_MAP rows 10
and 11 is a no-op on both. The string `Destination Full` under `reason` is
special-cased to error code 0xf.

The three `ByRes` actions (`ApplyCardByRes`, `DiscardCardByRes`, `MoveCardByRes`) all
carry urlIndex 0x0e, which resolves to `ut/%s/item/resource`, not to `ut/%s/item`.

### 2.5 Inventory counters

**CONFIRMED.** `userInfo.unopenedPacks` (0x35e) is an object whose only recognised
children are `preOrderPacks` (0x24b) and `recoveredPacks` (0x27b). `count` (0xbc) is
not read there, though the same class does read it under a different parent (atom
0x59). The two are summed and passed to model vtable slot +0x4e0 (`0x18011e120`),
which stores the total at `model+0x20950` and broadcasts message `0x273d`, registered
as the string `RELOAD_CENTRAL_PANEL`. That rebuilds the FUT game hub central panel,
where tile type 0x1c renders `CentralUnclaimedPack` with destination
`GOTO_STORE_MYPACK`.

Measured live in pid 4048: `model+0x20950 = 0`, consistent with never having served
the field.

`FutUserCreditsServerResponse` (`0x180122c50`) also carries `unopenedPacks` with the
same two children nested inside it, and `FutSBCSubmitChallengeServerResponse`
(`0x180161b00`) carries `preOrderPacks` and `recoveredPacks` at the top level. So an
SBC that awards a pack reports it by bumping counters, not by returning a pack object.

Atom 0x20d `packList` is **not** a wire key: the only parser that dispatches on it
reads the local file `packs/dreamsquad/dreamsquadpacklist.json`. Graded MEDIUM,
because the uniqueness half was not independently reproduced (see section 4).

---

## 3. Server-authoritative versus client-side

Strict reading: a thing is server-authoritative only if the response we send
determines it. "The client parses it" is not enough; "the client renders it" is not
enough either if the client would compute the same thing from something else.

| Mechanism | Owner | Emulator has to reimplement? |
|---|---|---|
| Pack catalogue: which packs exist, ids, captions, sort order | SERVER | Yes, done |
| Coin price of a pack (`currencies[].finalFunds`) | SERVER | Yes, done |
| Coin balance and the debit | SERVER | Yes, done |
| Which cards a pack contains (`itemList`) | SERVER | Yes, done |
| Number of cards revealed | SERVER (the list length; `numberItems` is written and never read) | No extra work: send the list |
| Duplicate detection (`duplicateItemIdList`) | SERVER | Yes, not built. Requires the createPack envelope path |
| Quick-sell payout on the wire (`totalCredits`) | SERVER | Yes, not built. Currently pays nothing |
| Which items a discard removes | SERVER | Yes, partly: our accounting works, our request parsing does not |
| Move verdicts (`itemData[].success`, `reason`) | SERVER | Yes, done for `club`; `trade` and `purchased` untested |
| Pile vocabulary (`club`/`purchased`/`trade`) | SERVER (we choose the string, client maps it) | Already correct |
| `unopenedPacks` counters and the unclaimed-pack tile | SERVER | Yes, one field. Zero today |
| "My Packs" grouping (`displayGroup.value == "mypacks"`) | SERVER | Yes, one string. Not sent today |
| Pack availability: `state`, `saleType`, `quantity`, `purchaseLimit`, `purchaseCount`, `start`, `end` | SERVER (all parsed and copied to the tile) | Optional. The predicate that greys a tile is in the packed exe and unread |
| HTTP status to FUT error code | SERVER | Yes, done: only ever answer 200 |
| Transaction state machine (`state`, `transactionId`, 409 pending) | SERVER, on the first-party path only | Only the cancel, which we already answer with 200 `{}` |
| `packContentInfo` tier quantities | SERVER, but purely decorative | Cosmetic only. Nothing compares them to delivery |
| Reveal animation on/off (`packOpeningAnimationEnabled`) | SERVER in principle, via `/settings` | No. The byte is already 1 |
| Which card gets the walkout | CLIENT, from `discardValue` we send | No logic. Only field values |
| Presentation tier / card colours (`FUN_1800a9fe0`, `FUN_1800aa060`) | CLIENT, from `rareflag` and `rating` | No |
| Grandstand headline override | CLIENT, from `loans`, `rating`, local table | No |
| Summary strip ordering | CLIENT, stable sort on `discardValue` | No |
| Quick-sell price shown on a card when `discardValue` is 0 | CLIENT, from `fcc_discardcoins` | No. Omitting the field is the EA-authentic behaviour |
| `cardtype` from `cardsubtypeid` (`FUN_1800d8330`) | CLIENT | No |
| Store tile rendering, grouping, backgrounds | CLIENT | No |
| Game-hub tile types and captions (`FUN_1800b2680`) | CLIENT | No |
| FIFA Points pricing | CLIENT plus platform store | No. Out of scope offline |
| 64-item clamp on bulk operations | CLIENT | No, but accept a list of up to 64 |
| 100-pack cap on the catalogue | CLIENT | No, but never send a 101st pack |
| DIME entitlement mapping (`FIFA17FUTPACKnnn`) | CLIENT plus Origin | No. UTAS never serves it |

The row that decides how much work exists: almost everything expensive-looking about
pack opening (the walkout, the tiering, the colours, the ordering, the animation) is
client-side arithmetic over fields we already send. The genuine outstanding
server-side work is three items: duplicates, quick-sell credit, and the
`unopenedPacks` counter.

---

## 4. What is still unknown, and the cheapest way to settle it

### Needs more decompiling (cheap, no launch, no risk)

1. ~~**The envelope rule.**~~ **DONE 2026-08-05 evening.** See the resolution box in
   section 2. Token enum decoded, reading A confirmed, `/purchased` shown not to be a
   counterexample. `POST /user` and `GET /purchased` are already correctly wrapped and
   need no change. The follow-up it opened, which is now the live question: **does the
   three-token blind-first-pair rule apply to `GET /hub`, which we answer with a flat
   two-key body?** There is no `FutGetHubServerResponse` class and no code xref to
   either atom, so `/hub` may not go through a generated root at all. UNKNOWN, and
   worth one query.
2. **`NUM_*_IN_PACK` authority.** Decompile `FUN_1800147f0`, the sole caller of
   `FUN_180015d80`, and see whether its `param_4` is the JSON-filled pack record. One
   function. Until then those five numbers are UNKNOWN, not SERVER.
3. **Whether anything reads `FutCreatePackServerResponse+0x28` (`numberItems`).**
   The original evidence was a misread of an adjacent vtable: `0x180228260` is a
   two-slot response vtable, `{0x1801624e0 dtor, 0x180162880 deser}`, and
   `0x180228270` is the separate ServerCall vtable. The conclusion survives trivially
   (a two-slot vtable has no accessor) but the non-virtual path is unproven and the
   offset is disp8-encodable, so no byte scan bounds it.
4. **The three unread consumers of the `mypacks` literal**, `FUN_180014df0`,
   `FUN_180014580` and `FUN_1800147f0`. Only `FUN_1800150d0` was read.
5. **Atom 0x20d uniqueness.** The dream-squad identification is solid; the "only
   parser" half was not independently reproduced, because a raw immediate scan cannot
   see running-sum ladder dispatch and its own controls failed.
6. **`class_deser()` is currently broken** in the rebuilt Ghidra projects: it returns
   `[]` for all three documented control classes, because it searches for
   `"<shortname>\0"` while the only literal is `"RS4:<Fullname>ServerResponse"`. Fix
   it to take the full name or delete it. Until then, any absence claim resting on an
   empty result from it is worthless.

### Needs a live memory probe (cheap, read-only, no launch)

7. **Nothing about pack records can be checked live until the store screen is
   opened.** Two independent signatures found zero resident pack records this
   session: a scan of 3.2 GiB of writable memory for the constructor's own
   `CREATEPACK` literal, and a scan for the `FUT Vector` / `FUT String` pointer
   triple. So every runtime offset in section 2.1 is static-only. Re-running the
   probe with the store open would confirm the whole tile field map in one pass.
8. **`data/store/dimecfg.xml`.** The `file://` path string is live at `0x79049a0`
   but the parsed content was not located. It is the sibling of `storecfg.xml` and
   probably carries the group/category structure that `displayGroup` maps onto, which
   is exactly the field that froze the store once. Worth a targeted hunt before this
   process exits.
9. **The `FIFA17.exe` side of the reveal gate.** CardsDLL exposes
   `packOpeningAnimationEnabled` as a vtable slot; whether the packed exe also reads
   it is unknown, and would need a sweep of the decrypted arena at
   `0x1450f3000..0x14b1a3000`. Low value now that the byte is known to be 1.

### Needs a live in-game test the user has to drive (expensive, keep short)

Ordered by value. Only the first three are worth a launch.

10. **What request the reveal's Quick Sell actually sends.** Single or bulk, URL
    suffix or body, and what the body looks like. This costs one menu action, needs
    **no server change at all**, and it is the difference between a quick sell that
    pays and one that silently pays zero.
11. **Whether `finalFunds` or `funds` is the tile price.** Two ints we already send,
    given different values. Settles a documented ambiguity and doubles as the
    positive control for everything else in the run. Zero freeze risk.
12. **Whether the reveal animation plays at all.** The gate byte is 1, so this
    observation now tests terms 2 to 4 of the AND rather than the flag.
13. Lower value, do not spend a launch on these alone: whether a populated
    `displayGroup` is safe; whether `unopenedPacks` alone lights the unclaimed-pack
    tile or whether the store must also return a `mypacks` group; whether
    `purchaseLimit` plus `purchaseCount` is what greys a tile out.

### Coverage, stated honestly

- The live string sweep covered roughly 98% of the anonymous and W+X scope. Between
  the two passes, 64 MiB and 88 MiB respectively came back short on `pread` and were
  never retried or identified. The 549 MiB of readable file-backed non-W+X mappings
  were deliberately not swept. Any absence claim over live memory carries that hole,
  including "walkout does not exist".
- The provenance of the `storecfg.xml` content is unresolved. It is not in CardsDLL,
  not in the packed exe, not in `stp-origin_emu.dll`, not in the repo, and not in 256
  files totalling 3.24 GiB under the install. But `Data/` is 30 GiB of compressed
  archives that a raw grep cannot see into, and the file-scan skipped everything over
  512 MiB. It is client-owned commerce data, not something UTAS sends; which channel
  delivered it is unknown.
- The terminal consumer of every store-tile field lives in Denuvo-packed
  `FIFA17.exe`. We can prove data reaches the tile; we cannot read the predicate that
  turns it into a greyed-out tile. Every "how to make a pack sold out" statement in
  this document is a ranked candidate, not a recipe.
- The absence proof for "nothing compares packContentInfo against itemList" has one
  hole that no byte scan or operand census can close: a pre-biased pointer, for
  example `LEA rax,[rcx+0x140]` then `MOV edx,[rax+4]`. Closing it needs symbolic
  data-flow, which nobody attempted.
- One reversing pass reported the retail catalogue's heap-pool table with
  `FIFA17FUTPACK1100 -> Origin.OFR.50.0001484`. The XML records disagree and give
  that offer id to 1101. My own re-parse of the artifact initially reproduced the
  same class of skew, because the dumped XML contains `<<GAP>>` markers where pages
  were not resident and a naive regex spans them. The table in section 5 is the
  gap-aware parse and is the one to trust; the eleven earliest SKUs, which survive
  only in the pool and not as XML records, have not been paired to that standard.

---

## 5. Proposed changes to ENDPOINT_MAP.md

Do not apply these blind. They are correct about what the parser reads, which this
project has learned twice is not the same statement as "safe to send". Everything
below is a documentation change only; the server changes it implies are in section 6.

One formatting note. The removal lines in these diffs are quoted from
`ENDPOINT_MAP.md` character for character, and the new subsection headers follow its
existing `### N. Name  - confidence: X` convention. That file uses em dashes, so the
quoted and paste-ready blocks below contain them. They are reproduced deliberately,
so the diffs apply cleanly and the pasted sections match their neighbours. The prose
in this document does not use them.

### 5.1 Line 1042, `displayGroup` is an object, not an array

```diff
-  | `displayGroup` | 0xd9 | **ARRAY** | nested (freeze-risk) |
+  | `displayGroup` | 0xd9 | **flat OBJECT** | `value`(0x377,STR)→rec+0x00, `priority`(0x250,INT)→rec+0x34. NOT recursive, NOT an array. Case 0xd9 loops on `tok != 10` (object end); the neighbouring `currencies` case loops on `tok != 0xd` (array end), which is the in-function control. An array here is the 2026-08-04 store freeze. |
```

### 5.2 Line 1046, `extPrice` reads neither `amount` nor `currency`

```diff
-  | `extPrice` | 0x119 | **OBJECT** | → `finalPrice`(0x125,obj `0x180139070`) + `originalPrice`(0x205,obj `0x18013aae0`); inner uses `amount`(0x1b)/`currency`(0xc4) (freeze-risk) |
+  | `extPrice` | 0x119 | **OBJECT** | → `finalPrice`(0x125,obj `0x180139070`) + `originalPrice`(0x205,obj `0x18013aae0`). Each inner object reads **exactly one key, `externalPriceId`(0x11a,INT)**; `amount`(0x1b) and `currency`(0xc4) appear nowhere in either function (152 instructions each, one atom compare apiece at `0x180139245` / `0x18013acb4`). `finalPrice` also writes pack+0x78, i.e. **it is the same slot as top-level `firstPartyStoreId`** (freeze-risk) |
```

### 5.3 Line 1047, `start` and `unopened` are not children of `packContentInfo`

```diff
-  | `packContentInfo` | 0x20c | **OBJECT** | → `bronzeQuantity`(0x63), `silverQuantity`(0x2c6), `goldQuantity`(0x149), `rareQuantity`(0x273), `itemQuantity`(0x170), `start`(0x2e3), `unopened`(0x35d,bool) (freeze-risk) |
+  | `packContentInfo` | 0x20c | **flat OBJECT, exactly five children** | `itemQuantity`(0x170)→+0x144, `goldQuantity`(0x149)→+0x148, `silverQuantity`(0x2c6)→+0x14c, `bronzeQuantity`(0x63)→+0x150, `rareQuantity`(0x273)→+0x154. Anything else inside reaches SKIP `0x180135ff0`. **`start`(0x2e3) and `unopened`(0x35d) are TOP-LEVEL siblings, not children** (freeze-risk) |
+  | `start` | 0x2e3 | INT | rec+0xb4, non-negative clamp `0x1800d7b30` |
+  | `end` | 0x102 | INT | rec+0xb8 |
+  | `unopened` | 0x35d | BOOL | rec+0xcd, stored raw (contrast `useDefaultImage` 0x36a → rec+0xcc, stored **inverted**) |
+  | `state` | 0x2eb | STR | compared against `"active"` → rec+0xb0. Constructor default is 0, i.e. **not active** |
+  | `quantity` | 0x26b | INT | rec+0xbc. A sent **0 is rewritten to -1** |
+  | `purchaseLimit` | 0x265 | INT | rec+0xc0 |
+  | `purchaseCount` | 0x261 | INT | rec+0xc4 |
+  | `saleType` | 0x298 | STR→enum | `NONE`0, `QUANTITY`1, `TIME`2, `TIME_QUANTITY`5, **anything else 0**. `"promo"` is not in the enum |
+  | `packType` | 0x20f | STR | rec+0x108, ctor default `"INVALID"` |
+  | `isPremium` | 0x176 | BOOL | rec+0xce |
+  | `id` | 0x15c | INT | rec+0x70 as a **u16**; values above 65535 truncate |
+  | `points` | 0x240 | INT | rec+0x140 |
+  | `visible` | 0x37d | **no getter** | one instruction, `MOV byte,1`. Presence sets it; the value is never read, so `false` reads as `true` |
+  | `firstPartyStoreId` | 0x127 | **STR then `atoi()`** | rec+0x78. Sending a JSON int here is a documented freeze |
```

### 5.4 Line 1051, delete the "none of these atoms exist" paragraph

```diff
-  - `store_catalog()` currently emits `id, packType, quantity, purchaseLimit, purchaseCount, isPremium, saleType` — **none of these atoms exist in the pack deser** (`id`=0x15c, `quantity`=0x26b, `saleType`=0x298, `packType`=0x20f, `isPremium`=0x176 are all routed to SKIP `0x180135ff0`). They are harmless no-ops but do nothing.
+  - **CORRECTION 2026-08-05.** Every one of `id`, `quantity`, `saleType`, `packType`, `isPremium`, `purchaseLimit` and `purchaseCount` has a real dispatch arm and a real store. Proven three ways: the decompile, the raw sub-ladder at `0x18013b62e`, and a decode of the MSVC jump table at `0x18013b792` (byte index table `0x18013bcb4`, seven targets `0x18013bc98`), which shows six atoms getting real arms and the other 132 indices falling to the shared SKIP. They are not no-ops. Being parsed is still not the same as being safe to change.
+  - The catalogue is **capped at 100 packs**. `CMP EDX,0x64` at `0x18013bb02` jumps past both push_back paths to the record destructor. Elements 101 and up are parsed and silently discarded.
+  - **`packContentInfo` is DECORATIVE.** Exactly one function reads the five quantity slots (`FUN_18002c3c0`, single code caller `FUN_1800150d0`) and it is a MOV-to-MOV copy into the tile view model with no arithmetic and no comparison. An operand-text census over 13,308 functions finds no code anywhere that compares the declared counts against the delivered `itemList`. `open_pack()` does not have to honour the declared distribution; the numbers are rendered, so agreement is cosmetic.
+  - **The coin price the tile shows is `finalFunds`, not `funds`** (`FUN_18002c3c0`: `tile+0xa0 = currencyRecord+0x24`). `funds` feeds the mtx slot and is then overwritten by the platform-store lookup. Both ints pass the non-negative clamp `0x1800d7b30`, so a negative price silently becomes 0. UNTESTED live; see the plan's §7 control.
```

### 5.5 Lines 920 to 923, the item-lifecycle rows

```diff
-| 8 | FutDiscardCard | `0x180127300` | DELETE `ut/delete/%s/item` (CardsDiscardCard) | `items`(0x171) → **array[int ids]** [FREEZE-RISK]; `totalCredits`(0x326) → int; `id`(0x15c) → int | GAP | HIGH |
+| 8 | FutDiscardCard | `0x180127300` | POST-tunnelled DELETE `ut/delete/%s/item` (single: id in URL as `/%llu`; bulk: body `{"itemId":[…]}`, atom 0x16d) | `items`(0x171) → **array of OBJECTS**, each `{id:(0x15c,int)}` [FREEZE-RISK]; `totalCredits`(0x326) → int. **No top-level `id`.** Each parsed id is also passed to model slot +0xa30 (local removal) | GAP | HIGH |
-| 9 | FutDiscardCardByRes | `0x1801279c0` | DELETE `ut/delete/%s/item` (by res) | `totalCredits`(0x326) → int | GAP | HIGH |
+| 9 | FutDiscardCardByRes | `0x1801279c0` | DELETE `ut/%s/item/resource` (urlIndex 0x0e) | `totalCredits`(0x326) → int, and nothing else | GAP | HIGH |
-| 10 | FutMoveCard | `0x180128600` | PUT `ut/%s/item` (move) | `itemData`(0x16b) → **array** [FREEZE-RISK]; `chemistry`(0x81) → bool | GAP | HIGH |
+| 10 | FutMoveCard | `0x180128600` | PUT `ut/%s/item` (move) | `itemData`(0x16b) → **array** [FREEZE-RISK], elements `id`(0x15c,int64) · `pile`(0x226,STR: club/purchased/trade only) · `success`(0x2fa,bool) · `reason`(0x279,STR; `"Destination Full"` → code 0xf) · `dreamSquads`(0xe9, genuine **array of bare ints**). **`chemistry`(0x81) is NOT parsed** (whole 6193-char function read) | ack live-proven | HIGH |
-| 11 | FutMoveCardByRes | `0x180128e30` | PUT `ut/%s/item` (move by res) | `itemData`(0x16b) → **array** [FREEZE-RISK]; `chemistry`(0x81) → bool (+ 2 str/1 int minor) | GAP | HIGH |
+| 11 | FutMoveCardByRes | `0x180128e30` | PUT `ut/%s/item/resource` (urlIndex 0x0e) | atoms are exactly `id`, `itemData`, `pile`, `reason`, `success`. **`chemistry`(0x81) is NOT parsed here either** (3040-char function read in full) | GAP | HIGH |
```

### 5.6 Lines 968 to 975, the minimal known-good bodies

```diff
 // 8 DiscardCard - DELETE ut/delete/game/fifa17/item
-{ "items": [ 123456789 ], "totalCredits": 15000, "id": 123456789 }
+{ "items": [ { "id": 123456789 } ], "totalCredits": 15000 }
 
 // 9 DiscardCardByRes - DELETE ut/delete/game/fifa17/item
 { "totalCredits": 15000 }
 
 // 10 MoveCard / 11 MoveCardByRes - PUT ut/game/fifa17/item
-{ "itemData": [ /* moved item */ ], "chemistry": true }
+{ "itemData": [ { "id": 123456789, "pile": "club", "success": true } ] }
```

### 5.7 Line 1095 and line 218, `duplicateItemIdList`

```diff
-  | `duplicateItemIdList` | 0xec | **ARRAY** (int list) | freeze-risk |
+  | `duplicateItemIdList` | 0xec | **ARRAY of OBJECTS** (element deser `0x180138e10`) | `itemId`(0x16d,int64) · `duplicateItemId`(0xeb,int64) · `itemLoans`(0x16f,int32) · `duplicateItemLoans`(0xed,int32). NOT a list of ints (freeze-risk). Post-pass in `0x180162880` writes `duplicateItemId` into the matched card at +0x10; the reveal controller `0x18009bc40` reads it as "is duplicate" and diverts to `GotoNewItems` **without issuing any request** |
```

At line 218 change `duplicateItemIdList` → **array** to `duplicateItemIdList` →
**array of objects**, and note the contrast with `dreamSquads` (0xe9), which really
is an array of bare ints.

### 5.8 New subsection, ready to paste after Store §5

```markdown
### 5a. Where the coin buy actually goes  - confidence: HIGH (request), MEDIUM-HIGH (response binding)

Two distinct ServerCall classes post into the store area and they are chosen
client-side, before any request is sent. Nothing in a server response selects
between them.

| Call | id | Request builder | URL | Body |
|---|---|---|---|---|
| CreatePack (`PurchasePack`) | 0x4b | `0x180162530` | `ut/%s/purchased`, urlIndex 0x1a | `packId`(0x20b) · `useCredits`(0x369) · `usePreOrder`(0x36b) · `currency`(0xc4: COINS/MTX/POINTS, omitted when usePreOrder) |
| PurchaseItems | 0x4c | `0x180126440` | `ut/v2/%s/store` + `/transaction` + `/<transactionId>` when state > 1 | always `state`(0x2eb) from the 9-entry table at `0x1802d02c0`, plus per-state extras |

`ut/v2/%s/store/transaction/0` with `{"state":"TRANSACTIONCANCEL"}` is **observed on
every boot** (2026-08-05 14:39:28). The PurchaseItems state machine is not
first-party-only from our point of view; the cancel reaches us and must be answered
`200 {}`.

State table (`0x1802d02c0`, read from the image and live, nine entries, no tenth):
`NOTRANSACTION` -1, `TRANSACTIONCREATED` 1, `PURCHASESTARTED` 2, `PURCHASECOMPLETE` 3,
`PURCHASECONSUMABLECOUNT` 4, `PURCHASECONSUME` 5, `TRANSACTIONCOMPLETE` 6,
`TRANSACTIONCANCEL` 7, `NONE` -1. The out-of-band refusal is the literal
`PURCHASEERROR`, which sets error 998 at response+0x1c before the enum map runs, and
it exists only on PurchaseItems. `FutCreatePackServerResponse` has no `state` and no
`reason`.

**HTTP status is a single table, `FUN_1801844c0`, reached through ServerCall vtable
slot 12.** Only 200 is success. 204 → 99. **Any other 2xx, 201 and 202 included,
falls through to 999.** 461 → 3. Most other 4xx/5xx → 998. PurchaseItems alone
overrides slot 12 (`0x1801267b0`) so that 409 plus the body substring
`User already has a transaction` becomes 0x70, a pending code the client re-polls.

**`FutPurchaseItemsServerResponse` field corrections** (deser `0x1801269f0`):
`transactionId`(0x33a) is an 8-byte store at +0x28; `firstPartyStoreId`(0x127) is read
with the **INT** getter here (contrast the pack element, which uses STR + `atoi`);
`packId`(0x20b) is stored as a **u16** at +0x98; and +0xa0/+0xa4/+0xa8 are not credit
fields, they are `useCount`(0x368), `useTime`(0x375) and `useAuth`(0x367).
**`useAuth` is read with the INT getter `0x1801c79d0` and then coerced by
`TEST/SETNZ`, not with the BOOL getter.** If we ever serve it, it must be a JSON
number, never `true`/`false`.
```

### 5.9 New subsection, the recovered retail catalogue

```markdown
### 5b. The real FIFA 17 pack SKUs  - confidence: HIGH, source is perishable

Recovered 2026-08-05 from the live client heap of pid 4048 (parsed copy of
`data/store/storecfg.xml`, buffer `0x3dabe000..0x3dac7000`). Not present in
CardsDLL, in the packed exe, or in any readable file under the install. This is the
id space the FIFA 17 store was built around. Our catalogue uses assetId 1, 5 and 6,
which are not members of it; see the plan's risk register for why that is a lead and
not an instruction.

| serverId | name | Origin offer | entitlement | uniqueId |
|---|---|---|---|---|
| 504 | SILVER PLAYERS PACK | Origin.OFR.50.0001350 | FIFA17FUTPACK504 | 0f17f013 |
| 506 | SILVER PLAYERS PREMIUM | Origin.OFR.50.0001351 | FIFA17FUTPACK506 | 0f17f03b |
| 600-608 | FIFA Points 100 / 250 / 500 / 750 / 1050 / 1600 / 2200 / 4600 / 12000 | none | FP0600-FP0608 | 0f17f000-008 |
| 809 | Draft Entry | Origin.OFR.50.0001335 | FIFA17FUTPACK809 | 0f17f809 |
| 900 | Gold 13 PACK | Origin.OFR.50.0001359 | FIFA17FUTPACK900 | 0f17f042 |
| 901 | Premium Gold 13 Pack | Origin.OFR.50.0001362 | FIFA17FUTPACK901 | 0f17f043 |
| 902 | Jumbo Gold 26 Pack | Origin.OFR.50.0001360 | FIFA17FUTPACK902 | 0f17f044 |
| 903 | Jumbo Premium Gold 26 Pack | Origin.OFR.50.0001361 | FIFA17FUTPACK903 | 0f17f045 |
| 904 | VALUE PACK 5 | Origin.OFR.50.0001363 | FIFA17FUTPACK904 | 0f17f046 |
| 1101 | LIGUE 1 PREMIUM GOLD PACK | Origin.OFR.50.0001484 | FIFA17FUTPACK1101 | 0f17f04E |
| 1102 | SERIE A PREMIUM GOLD PACK | Origin.OFR.50.0001485 | FIFA17FUTPACK1102 | 0f17f04F |
| 1103 | LIGA BBVA PREMIUM GOLD PACK | Origin.OFR.50.0001486 | FIFA17FUTPACK1103 | 0f17f050 |
| 1104 | BUNDESLIGA PREMIUM GOLD PACK | Origin.OFR.50.0001487 | FIFA17FUTPACK1104 | 0f17f051 |
| 1110 | BPL PREMIUM PLAYERS PACK | Origin.OFR.50.0001488 | FIFA17FUTPACK1110 | 0f17f052 |
| 1111 | LIGUE 1 PREMIUM PLAYERS PACK | Origin.OFR.50.0001489 | FIFA17FUTPACK1111 | 0f17f053 |
| 1112 | SERIE A PREMIUM PLAYERS PACK | Origin.OFR.50.0001490 | FIFA17FUTPACK1112 | 0f17f054 |
| 1113 | LIGA BBVA PREMIUM PLAYERS PACK | Origin.OFR.50.0001491 | FIFA17FUTPACK1113 | 0f17f055 |
| 1114 | BUNDESLIGA PREMIUM PLAYERS PACK | (record truncated by a page gap) | | 0f17f056 |
| 1120 | BPL PRIME PLAYERS PACK | Origin.OFR.50.0001493 | FIFA17FUTPACK1120 | 0f17f057 |
| 1121 | LIGUE 1 PRIME PLAYERS PACK | Origin.OFR.50.0001494 | FIFA17FUTPACK1121 | 0f17f058 |
| 1122 | SERIE A PRIME PLAYERS PACK | Origin.OFR.50.0001495 | FIFA17FUTPACK1122 | 0f17f059 |
| 1123 | LIGA BBVA PRIME PLAYERS PACK | Origin.OFR.50.0001496 | FIFA17FUTPACK1123 | 0f17f05A |
| 1124 | BUNDESLIGA PRIME PLAYERS PACK | Origin.OFR.50.0001497 | FIFA17FUTPACK1124 | 0f17f05B |
| 1200 | BPL SQUAD PACK | Origin.OFR.50.0001498 | FIFA17FUTPACK1200 | 0f17f05C |
| 1201 | LIGUE 1 SQUAD PACK | Origin.OFR.50.0001499 | FIFA17FUTPACK1201 | 0f17f05D |
| 1202 | SERIE A SQUAD PACK | Origin.OFR.50.0001500 | FIFA17FUTPACK1202 | 0f17f05E |
| 1203 | LIGA BBVA SQUAD PACK | Origin.OFR.50.0001501 | FIFA17FUTPACK1203 | 0f17f05F |
| 1204 | BUNDESLIGA SQUAD PACK | Origin.OFR.50.0001502 | FIFA17FUTPACK1204 | 0f17f060 |
| 1210 | BPL TRIAL PACK | Origin.OFR.50.0001503 | FIFA17FUTPACK1210 | 0f17f061 |
| 1211 | LIGUE 1 TRIAL PACK | Origin.OFR.50.0001504 | FIFA17FUTPACK1211 | 0f17f062 |
| 1212 | SERIE A TRIAL PACK | Origin.OFR.50.0001505 | FIFA17FUTPACK1212 | 0f17f063 |
| 1213 | LIGA BBVA TRIAL PACK | Origin.OFR.50.0001507 | FIFA17FUTPACK1213 | 0f17f064 |
| 1214 | BUNDESLIGA TRIAL PACK | Origin.OFR.50.0001506 | FIFA17FUTPACK1214 | 0f17f065 |

A second heap pool adds eleven earlier SKUs whose XML records did not survive:
102, 105, 200, 202, 203, 205, 300, 302, 304, 306, 400, plus names including
PREMIUM GOLD JUMBO, PREMIUM SILVER JUMBO, PREMIUM SILVER PACK, JUMBO SILVER PACK,
PREMIUM BRONZE JUMBO and JUMBO BRONZE PACK. Their SKU-to-offer pairing is **not**
established to the same standard and one published pairing for 1100/1101 was
off by one, so treat those eleven as names without ids.

`CARDS_CB_ERR_PACK_NOT_IN_DIME` is **not** evidence of a client-side DIME lookup: it
is `case 0x22` of `FUN_1800d7b70`, a pure error-code-to-display-name table of 57
`CARDS_*` strings. It is a code the server can return.
```

### 5.10 New subsection, the inventory counters

```markdown
### 5c. unopenedPacks and the unclaimed-pack tile  - confidence: HIGH

`userInfo.unopenedPacks` (0x35e) is an OBJECT whose only recognised children are
`preOrderPacks`(0x24b, INT) and `recoveredPacks`(0x27b, INT). `count`(0xbc) is
**not** read there. The two are summed and stored at `model+0x20950` through model
vtable slot +0x4e0 (`0x18011e120`), which then broadcasts message `0x273d`,
registered as `RELOAD_CENTRAL_PANEL`. That rebuild is what can produce game-hub tile
type 0x1c, `CentralUnclaimedPack`, caption `FUT_GH_UNCLAIMED_PACK_0`, destination
`GOTO_STORE_MYPACK`. Nothing in the chain issues a request, and no request could
exist: the 48-entry template table has no pack-inventory route.

The **My Packs** screen is a filter over the ordinary store catalogue.
`FUN_1800150d0` walks the same 0x158-byte pack array the store deserializer fills and
selects entries whose `displayGroup.value` equals the literal `"mypacks"`
(`0x1801ec008`), ordering them by `displayGroup.priority`.

The same two counters also appear in `FutUserCreditsServerResponse`
(`0x180122c50`, nested inside `unopenedPacks`) and in
`FutSBCSubmitChallengeServerResponse` (`0x180161b00`, at the top level). An SBC that
awards a pack reports it by bumping counters, not by returning a pack object.

**Minimal known-good** (inside `userInfo`):
`"unopenedPacks": {"preOrderPacks": 0, "recoveredPacks": 1}`
UNTESTED. Live value of `model+0x20950` measured at 0 on 2026-08-05.
```

---

## 6. Risk register

House rule applies to all of it: default off behind an env flag until it has been in
front of the game once. The two worst regressions this project has had, the frozen
store and packs failing to open, both came from technically correct field
corrections shipped without a live test.

| Change | Freeze risk | Type fidelity requirement | Default |
|---|---|---|---|
| **(A)** `quick_sell_route()` parses `{"itemId":[…]}` and the trailing `/%llu` in the URL | None on the wire (request parsing only) | n/a | **off**. It is not risk-free: today the handler matches nothing, so a quick sell destroys no cards and writes no save. With (A) it will delete cards and credit coins. A wrong id parse destroys real cards |
| **(B)** discard response becomes `{"items":[{"id":N}],"totalCredits":C}` | Low. `items` must be an array of OBJECTS; the currently documented array of bare ints would feed the int getter an object token and spin `0x1801c7f1a` | `items` array of objects, `id` and `totalCredits` plain ints | off |
| **(C)** move the `createPackResponse` envelope onto the `POST /purchased` response | Medium, and the danger is not a freeze. Both `FutCreatePack` and `FutGetPurchasedItems` write the **same** container (model vtable +0x160). Serving both could double-populate the reveal | `itemList` array, `numberItems` int, `purchasedPackId` int, `duplicateItemIdList` array of objects | off. Do not ship in the same round as anything else |
| **(D)** serve `duplicateItemIdList` with real entries | High if (C) is not in place, because the field only reaches the client through the createPack path. Array of OBJECTS or nothing | `itemId`/`duplicateItemId` int64, `itemLoans`/`duplicateItemLoans` int32 | off, and blocked on (C) |
| **(E)** serve `userInfo.unopenedPacks` with a non-zero pair | Low. Two ints inside an object; unknown keys inside it SKIP safely | object with two int children. `count` is not read there | off |
| **(F)** send `displayGroup` as `{"value":"mypacks"}` on some packs | Medium and **unquantified**. This is the first field we would send that selects a render path rather than a value, and the tile builder is in the packed exe. `FUT_STORE_DISPLAYGROUP` already exists for exactly this and is documented as untested | flat object; `value` STR, `priority` INT. An array here is the 2026-08-04 freeze | off, existing flag |
| **(G)** move `unopened` from inside `packContentInfo` to the top level | Low. It becomes a real BOOL at rec+0xcd, copied to tile+0x69. What the tile does with it is unread | JSON `true`/`false`; it is a genuine BOOL getter | off. Low value: today it is inert, tomorrow it does something unknown |
| **(H)** accept `pile` values `trade` and `purchased` in `move_items()` | Low. Same route, same verdict body that is already live-proven for `club` | `pile` must be one of exactly three strings; anything else maps to enum 0 client-side | on is defensible, since the handler already stamps whatever pile it is given |
| **(I)** set a pack's `finalFunds` different from `funds` | **None.** Both are plain ints we already send | ints, and negatives silently clamp to 0 | this is the §7 control, ship it for the test only |
| **(J)** change `assetId` to a real DIME serverId | **Do not.** Packs open today with 1/5/6, so nothing on the coin path validates against DIME, and the one string that suggested otherwise turned out to be an error-code table entry | n/a | never, until somebody decompiles the DIME consumable lookup and shows the coin path reaches it |
| **(K)** send `extPrice.finalPrice.externalPriceId` | **Do not.** It writes the same slot as `firstPartyStoreId`, and a non-negative value there sends the tile into a platform-store lookup that cannot succeed offline | int, but the correct action is to leave the current inert `{"amount":…,"currency":"mtx"}` alone or delete it | never for now |

Things that are inert and should be left alone rather than "fixed": `saleType:
"promo"` (not in the client enum, lands on NONE), `limitType` (not an atom at all),
`visible` (the value is never read), `useDefaultImage` (stored inverted, so `true`
sets false). Churning accurate-but-inert fields costs a live test and buys nothing.

---

## 7. The one-launch live test script

Budget: **one server restart, one FIFA launch.** Steps 1 and 2 are the control and
they go first. Steps 3 and 4 need no server change at all and are the highest value
per unit of risk in the whole plan, because they read the client's own requests off
the wire.

### Pre-flight, terminal, no launch

```bash
cd fifa17-recon/tools
grep -nE '\breturn 2(01|02|04|06)\b' utas_server.py     # expect: no matches
python3 -c "import fut_store as s; print([p['price'] for p in s.PACK_CATALOG])"
env | grep FUT_PACK_AUTOCLUB                            # expect: nothing
```

Only 200, 404 and 461 may ever be returned. Anything else in the 2xx range maps to
FUT error 999. Audited: the file returns only 200 (59 sites), 404 (once) and 461
(three times), so this check is already clean and is here as a guard against
regression.

**`FUT_PACK_AUTOCLUB` must be off, and the file lies about its own default.**
Line 728 reads `os.environ.get("FUT_PACK_AUTOCLUB", "0") == "1"`, so the code
default is off, but the comment at line 864 asserts "`FUT_PACK_AUTOCLUB=1` (the
default)". The comment is stale and the code is right. This matters more than a
stale comment normally would, because autoclub deposits a pack's cards into the club
before the reveal screen ever asks, and the file's own history at lines 725 to 727
records the consequence: "the first live attempt at the correct response shape
produced no PUT /item at all because autoclub had already emptied the pile." If it
is on, steps 3 through 6 below produce no requests and the entire run reads as a
false negative. Check the environment, not the comment.

Optionally re-read the gate byte on the client that is running right now, read-only,
no restart needed:

```bash
python3 /tmp/.../packres/synth_check.py     # expect: FNV control MATCH, +0x1fd45 value = 1
```

### The change to ship

**One variable.** Gold Pack only: set its price to `4321` and serve
`"currencies":[{"name":"coins","funds":5000,"finalFunds":4321}]`. Nothing else
changes. Two ints we already send, given different values, and the server debits the
same number the tile should show, so the state stays internally consistent.

### In the GUI, in this order

1. **Store. THE CONTROL.** Open it and read the Gold Pack price.
2. **Buy the Gold Pack.** Note the coin balance before and after.
3. **The reveal.** Record three things: whether an animation plays at all, how many
   cards appear, and whether one card is singled out as the headline.
4. **Quick Sell exactly one card** from the reveal, then leave the rest.
5. **Send to Transfer List** exactly one card, if the option is offered.
6. **Send to Club** the remainder, which is the live-proven path and doubles as the
   regression check.
7. Regression sweep: MY CLUB still 205 players, 189 gold, 8 silver, 8 bronze;
   managers still 34 staff cards with no DB Error; store still lists three packs.

Then, and this is the part that carries the round:

```bash
grep -nE 'delete/game/[^/]+/item|store/transaction|POST /ut/game/[^/]+/purchased' -A6 /tmp/utas.log
```

### Reading the result

| Step 1 price | Meaning |
|---|---|
| **4321** | The store body reached the tile **and** `finalFunds` is the coin price. Everything below is readable. Land the ENDPOINT_MAP correction at §5.4 as CONFIRMED-LIVE |
| **5000** | The body reached the tile but `funds` wins. Also readable, and it inverts the §5.4 correction. Record it and fix the map the other way |
| **unchanged from today, or blank** | The store body did not reach the tile. **Stop reading here.** Nothing in steps 2 to 6 is interpretable, and the failure is in delivery, not in any field |
| **store fails to open** | Two ints broke it, which would be new information of a very unwelcome kind. Revert the price, restart, and treat the currency record as far more fragile than believed |

| Observation | Meaning |
|---|---|
| Step 3, animation plays | The five-way AND is fully satisfied today. Delete `packOpeningAnimationEnabled` from the backlog and from yesterday's settings plan |
| Step 3, no animation, byte is 1 | The blocker is term 2, 3 or 4: `resourceId & 0xffffff`, `cardtype == 1`, or `ASSET_ID` missing from the data provider. That is a card-field problem, not a settings problem, and it is cheap to bisect |
| Step 3, one card visibly singled out | Confirms the headline selector runs on the client-computed quick-sell value, since we send no `discardValue`. No server work |
| Step 4, log shows `ut/delete/.../item/<number>` with no body | Single discard is URL-form. Ship (A) parsing the URL suffix |
| Step 4, log shows a body `{"itemId":[…]}` | Bulk form even for one card. Ship (A) parsing `itemId` |
| Step 4, log shows `itemData` or `itemIds` | The current handler was right all along and the static reading is wrong. Do not ship (A) |
| Step 4, no request at all | Quick Sell is client-only until a batch is confirmed elsewhere. Re-run with "Quick Sell All" |
| Step 4, coins increase | Impossible today, since the handler matches nothing. If it happens, our understanding of the route is wrong |
| Step 5, `PUT /item` with `"pile":"trade"` | Confirms transfer-list send is the same route. Ship (H) |
| Step 5, some other path | New route, capture it and stop guessing |
| Step 6 fails while it worked yesterday | Regression from the price change. Revert first, analyse second |

The control is doing real work here. Without step 1 a silent step 4 is ambiguous
between "Quick Sell sends nothing" and "our store response never arrived, so the
buy never happened the way we think". With it, a silent step 4 is a fact.

### What would make this whole plan wrong

The reveal path could be fed by something we have not found. The argument that
`GET /purchased` is what populates the reveal container rests on the fact that
`FutGetPurchasedItems` writes model vtable slot +0x160 and that `POST /purchased`
currently answers with a body the createPack deserializer skips entirely. If the
cards actually arrive some third way, then section 2.2's account of the buy is wrong
and (C) is not just risky, it is pointless.

`finalFunds` versus `funds` could be moot if the tile price comes from somewhere
else entirely, for instance the platform catalogue path when `firstPartyStoreId` is
not -1. We do not send `firstPartyStoreId`, so that should not apply, but the
formatter's early-return is the only thing standing between us and that branch.

---

## Next

**DONE. The envelope rule is settled, and it found the bug it was looking for, though
not the one that was predicted.** Full account in the resolution box in section 2.
Queries: `tools/ghidra_queries/q_envelope_{1,2,3}.py`.

The prediction in the earlier draft of this section was that `starterPack`, `squad` and
`userData` were being swallowed on `POST /user`. **They are not.** The opposite is true,
and it is narrower and more interesting.

`FutCreateUser` (`0x18014cc60`) is a three-token root with ladder arms for exactly the
five keys we send: `login` 0x1a5, `userData` 0x36d, `squad` 0x2cd, `starterPack` 0x2e5,
`bonusPacks` 0x5d. We serve them flat, in that order. The three tokens consume `{`, the
FIELD_NAME `login`, and the scalar `true`. The loop then dispatches `userData`, `squad`,
`starterPack` and `bonusPacks` normally at the outer level, which is exactly where the
ladder wants them.

So four of the five keys are read, and **`login` is the single key that is silently
discarded**. Its name is eaten as the anonymous envelope and its value as the third
token. It has an arm, so the client does want it. It has never once been delivered.

Two consequences, and the second is the one that matters more:

1. `login: true` has never reached the client. Whether that is harmful is UNKNOWN, since
   FUT plainly works without it.
2. **The key order of that dict is load-bearing and nothing in the code says so.** Any
   reordering that puts `userData` first would swallow `userData` instead, which would be
   a spectacular and very hard to diagnose failure. This is a landmine sitting in
   `utas_server.py` right now.

The likely correct shape is `{"<anything>": {login, userData, squad, starterPack,
bonusPacks}}`, wrapping all five one level down, since that is what the identical
three-token preamble means for `FutCreatePack`. That is a hypothesis with a mechanism,
not a proven fix, and it touches the login path, so it goes behind a flag defaulting to
off per the house rule. If it is right, `login` starts being read and nothing else
changes. If it is wrong, login desyncs and the game cannot enter FUT, so it is not a
change to make casually or to bundle with anything else.

**`GET /hub`: DONE, and it is the thing that overturned the section above.** It is
served flat and it parses correctly. `clubPlayers` reached its arm, read as 205 out of
the running client at `model+0x1fd70+0x3c`. See the correction box in section 2.

Two errors of mine were exposed getting there, both cheap to repeat and worth recording:

1. I searched for `RS4:FutGetHubServerResponse` and reported that no hub class existed.
   The class is `FutGetHubDataServerResponse` (literal `0x18022ce40`, vtable
   `0x18022cd48`, deserializer `0x1801738b0`, resolved with `FutSquadSave ->
   0x180171a60` matching as the control in the same run). An absence found by guessing
   a name is not an absence.
2. I then scanned 152 deserializers for `clubPlayers`, found zero hits, and had a
   control pass. The guard is `if (iVar6 != 0x90)` and my pattern only matched `== 0x`.
   The control passed only because `auctionCount` happens to use `==`. A control that
   does not exercise the same code shape as the target is not a control.

The pre-existing comment at `utas_server.py:1076` had the hub chain right all along, and
reading it first would have saved both queries.

**The next thing worth doing is the one-launch test in section 7**, now that the
no-launch work is exhausted. The remaining static questions in this list are small; the
open items with real value all need either the game in front of a human, or a live probe
of one specific field in the pattern that just worked here.
