OpenFUT/fifa17-recon/docs/REBUILD_RESEARCH.md

FUT Rebuild — research notes (2026-08-03, overnight pass)

Research toward rebuilding FUT end-to-end and standing up the online resources. Everything here is static RE unless it says "live". Read §0 before trusting a row: one bulk technique in this pass failed its own control and was discarded.

0. Confidence / what failed

finding	confidence	basis
§1 complete FUT URL table (45 templates)	HIGH	read straight out of the table at 0x18021df80; two entries independently confirmed live (ut/%s/squad, ut/v2/%s/store)
§2 routing gap analysis	HIGH	mechanical diff of §1 against utas_server.ROUTES
§3 POW/EASFC map	HIGH	58 path templates extracted; 16 of them observed live in /tmp/pow_server.log
§4 POW field vocabulary	MEDIUM	literal key strings + name-table functions; envelope still unknown (live-refuted once)
§5 endpoint→cache pairings	HIGH	each issuer function references exactly one path literal + one cache class
bulk FutXServerResponse → deserializer walk	DISCARDED	three attempts; the last "resolved" 18 classes but mismatched its known-good control (FutSquadSave → 0x1801631e0, actual 0x180171a60) and collapsed several classes onto one address. Not written up. See §6 for why and how to fix.

1. The complete FUT request surface

Table of {char* template, char* NAME} pairs at 0x18021df80, 45 rows. This is the whole UTAS API the client can call:

ut/%s/auctionhouse            AUCTIONHOUSE    ut/%s/purchased            PURCHASED
ut/%s/clubUser                CLUB_USER       ut/%s/store                STORE
ut/%s/user/list               CLUB_INFO       ut/%s/watchList            WATCHLIST
ut/%s/club                    CLUB            ut/delete/%s/watchList     DELETEWATCHLIST
ut/%s/defid                   DREAM           ut/%s/tradePile            TRADEPILE
ut/%s/squad                   SQUAD           ut/%s/trade                TRADE
ut/delete/%s/squad            DELETE_SQUAD    ut/delete/%s/trade         DELETETRADE
ut/%s/leaderboards/options    LBOPTIONS       ut/%s/marketdata           MARKETDATA
ut/%s/leaderboards            LBDEFAULT       ut/%s/clientdata           CLIENTDATA
ut/%s/activeMessage           PAFPRACTICE     ut/auth                    AUTH
ut/%s                         UT              ut/delete/auth             DELETE_AUTH
ut/%s/user                    USER            ut/%s/phishing             PHISHING
ut/delete/%s/user             DELETEUSER      ut/%s/captcha              CAPTCHA
ut/%s/item                    ITEMS           ut/%s/tfa                  TFA
ut/%s/item/resource           ITEMS_BY_RES    ut/%s/squad/mode           SQUADMODE
ut/delete/%s/item             DELETEITEMS     ut/%s/draft/mode           DRAFT
ut/%s/match                   MATCH           ut/%s/champion             CHAMPIONS
ut/%s/sbs                     SBC             ut/v2/%s/store             V2STORE
ut/%s/tournament              TOURNAMENT      ut/%s/livemessage          LIVEMESSAGE
ut/%s/tournament/user         TOURNAMENTUSER  ut/%s/season               SEASON
ut/delete/%s/tournament/user  TOURNAMENTQUIT  ut/%s/season/user          SEASONUSER
ut/%s/season/%%s/user         SEASONUSER_ALTER
ut/%s/season/%%s/reset        SEASONRESET     ut/%s/season/friendly      FRIENDLYSEASON

%s expands to game/<sku> (i.e. game/fifa17).

⚠ A template is not the whole URL. Callers append suffixes that never appear in this table — ut/%s/squad + /list is a real, live-observed endpoint that cost us a whole debugging cycle (REBUILD_PLAN §10g), and ut/%s/user + /club is the club-rename URL. So treat this table as the base set and keep watching the log for suffixed variants.

2. Routing gaps (what currently falls through to the catch-all 200 {})

15 of the 45 have no route at all:

template	NAME	why it matters
ut/%s/sbs	SBC	Squad Building Challenges — a whole game mode
ut/%s/champion	CHAMPIONS	FUT Champions (the hub tile exists)
ut/%s/draft/mode	DRAFT	FUT Draft
ut/%s/tournament, /user, delete	TOURNAMENT*	offline cups
ut/%s/leaderboards, /options	LB*	leaderboards
ut/%s/livemessage, ut/%s/activeMessage	LIVEMESSAGE/PAFPRACTICE	in-hub messaging
ut/%s/clientdata	CLIENTDATA	client blob storage
ut/%s/captcha, ut/%s/tfa	CAPTCHA/TFA	anti-bot + 2FA gates
ut/%s	UT	API root
ut/v2/%s/store	V2STORE	routed by regex today, but only the bare form

Also ut/%s/match is only partially routed — we answer match/keepalive and match/reset; the base MATCH endpoint (create/destroy, i.e. where match rewards are delivered) falls through. That is the single biggest hole in the core loop: without it, playing a match awards nothing.

3. POW / EASFC — the online layer

See REBUILD_PLAN §11 for the reversed gate. Live-confirmed working: the client honours FIFA_POW_URL from the merged client-config store, connects to our server, and the "servers unreachable" banner disappears without touching /etc/hosts.

16 endpoints observed live, in call order:

POST pow/auth                      GET pow/lvl/user/tiergp/businessunit/tiertp/fifa
GET  pow/healthcheck/system/all    GET pow/lvl/weight/tiergp/businessunit/tiertp/fifa
GET  pow/bank/user/account         GET pow/store/game/fifa17/catalog/list
GET  pow/bank/currency/pow_funds/cap/info
GET  pow/store/game/fifa17/catalog/0/item/list?offset=0&count=49   <-- pager
GET  pow/inventory/item/list       GET pow/store/gift/list
POST pow/user/friends              GET pow/pfyc/user
POST pow/pfyc/user/club            PUT pow/pfyc/user/prefs/shareinfo
GET  pow/mm/game/fifa17/message/list                POST pow/v2/activity

pow/auth request body (live): {isReadOnly, sku:"FFA17PCC", clientVersion, nuc, nucleusPersonaId, nucleusPersonaDisplayName, locale, priorityLevel} — the client asserts its own identity, same pattern as UTAS auth.

Debug facility found: POW/POW_FORCE_ERROR, POW_FORCE_ERROR_CODE and test-http-status-codes.asp?code=%d (in FUN_180066410) — the client can be told to synthesise POW HTTP errors. Useful for testing our error paths.

4. POW field vocabulary (names certain, envelope not)

Literal key strings in powdll, i.e. names its parsers compare against:

• level (name table FUN_180094700): level, exp, currLevelExpMin, currLevelExpMax, isMaxLevel, dailyXpCap, currency
• bank (contiguous field table 0x1800c96b8–0x1800c9928): currencies, currency, currencyName, funds, fundsBalance, fundsCap, fundsCapInfo, fundsEarned, accountBalance, balance, numCurrency
• list envelope (FUN_180094560): numItems, numOwnedItems, numLockedItems, numCurrency
• catalog item (FUN_1800945c0, 21 fields): category, name, description, type, subtype, price, level, isConsumable, isPurchased, isPromotion, isGiftable, isLocked, ownedQuantity, maximumQuantity, assetPath, smallAssetPath, fccAvailable, itemCount, itemsTotal, itemsOwned, error

NOT present in powdll (do not send — they parse as nothing): personaId, personaName, userId, sessionId, displayName, personaList.

Open: the top-level envelope. Serving the level record at the JSON root was live-tested and ignored (hub still read LVL: 0/0). A one-launch probe is armed (record at root + under data/result/content + as a 1-element array).

5. Endpoint → cache-class pairings (powdll)

endpoint	issuer	cache class
pow/lvl/user/tiergp/%s/tiertp/%s	FUN_180020250	UserLevelCacheData
pow/bank/user/account	FUN_18001aeb0	CurrencyCacheData
pow/nucleus/entitlements	FUN_180066410	— (+ error-injection)
pow/auth	FUN_180068dd0	— (Post, %s/%s)
pow/healthcheck/system/all	FUN_18005cb40	sets POWmgr[0x6ac] 1=on/3=off

Other cache classes seen, not yet paired: CatalogListCacheData, CatalogCacheData, LevelWeightCacheData, FriendsLevelCacheData, CurrencyCapCacheData, ChallengeProgressCacheData.

6. Next research steps (in priority order)

1. ut/%s/match — create/destroy and the reward payload. Biggest core-loop hole; without it matches award nothing. Needs the response schema.
2. Fix the class→deserializer walk. The three failed attempts assumed MSVC RTTI (TypeDescriptor→COL→vtable); EA's layout is its own: the class-name literal sits after the vtable (FutSquadSave: vtable 0x18022c560, name 0x18022c61c), with a descriptor block before it containing 32-bit RVAs and the 0x19930522 signature. The reliable path is the one used successfully for the squad family: locate the factory function first, then its vtable. Do that per class rather than by scanning, and always keep a known-good control in the batch — that control is what caught the bad results here.
3. POW envelope — settled by the armed probe on the next launch.
4. dbdata.dll — imported and analysed at /tmp/fifadb/dbproj (2.6 MB, loose). This is the player database: real names/ratings/clubs for the club, market and packs, replacing fut_store.PACK_POOL's 18 hand-entered players.
5. Objectives / Manager Tasks — the hub tile reads 0/0; no FutGetObjectives RTTI string exists, so the feed is something else (possibly clientdata or a POW challenge endpoint: pow/chal/user/prog, ChallengeProgressCacheData).

7. Core loop IMPLEMENTED — match lifecycle + rewards (2026-08-04)

The ut/%s/match hole from §2 is closed. The schemas did not need re-reversing: ENDPOINT_MAP.md already carried them at CONFIDENCE: HIGH from an earlier pass — checking the docs first saved a full reversing cycle, and is worth doing before any "unrouted endpoint" is treated as unknown.

verb + path	response class	deser	what we serve
POST ut/%s/match	FutCreateMatch	0x180120380	{startDateTime, reportIdEnabled, id}
PUT ut/%s/match/{id}	FutMatchReady	none	{}
POST ut/%s/match/{id}	FutPlayGame	none	{} (client SENDS the result here)
DELETE ut/%s/match/{id}	FutDestroyMatch	0x180121b60	the rewards

ut/delete/game/<sku>/match/... is routed too — UTAS tunnels DELETE through a /ut/delete/ path prefix (same as trade/watchList/squad).

Reward body — every field a top-level scalar, so zero freeze risk: coins(149) allCoins(20) matchCoins(436) seasonCoins(670) tournamentCoins(809) boostConis(96 — EA's typo, exact key) participationAward(529) qualifiedChampionEventId(617) teamOfTournamentWinner(776,bool). The nested members gameModeAward(310), matchCoinMultipliers(437) and userData(877) are deliberately omitted: all three are SKIP-safe, and userData is a documented freeze-risk (must be an object if present), so not sending it is strictly safer.

Verified offline, full lifecycle: create → ready → play(2-1) → destroy gave +400 coins, balance 12600 → 13000, hub record 0-0-0 → 1-0-0. Profile then restored to its pre-test state; 380 contract checks still green.

Payout amounts are OURS, not reversed — the server decides. Defaults win/draw/loss = 400/200/100, tunable via FUT_MATCH_COINS_WIN|DRAW|LOSS and FUT_MATCH_PARTICIPATION.

Known gap: the request shape for PlayGame/DestroyMatch is not reversed — only the response side is. _match_result() probes the plausible spellings (goals/opponentGoals, score/opponentScore, nested match/stats, textual result) and falls back to a draw, the neutral outcome — it credits and records without inventing a win. Every request body is logged, so the first real in-game match reveals the true shape and the fallback can be replaced with the actual field.

Not added to the contract suite: the loop is inherently mutating (it credits coins and bumps the record), and that suite is meant to stay read-only. Verified by hand instead; if it needs regression cover, extract the reward body into a pure function and unit-test that rather than making the HTTP suite stateful.

8. Game-mode gaps implemented (2026-08-04, loop iteration 1)

The remaining 15 unrouted templates from §2 are now routed. Again no new reversing was needed — ENDPOINT_MAP.md already carried the schemas. That is twice in a row; treat "unrouted" as "check the docs" before "reverse it".

endpoint	class	deser	confidence	body
GET /season	FutSeasonList	0x180167740	HIGH	ARRAY root of season descriptors
GET /season/user	FutSeasonLoadData	0x180131450	HIGH (switch traced)	{seasonId, divisionId, round, userPoints, dataVersion, data}
/season/{id}/reset	FutResetMatch	0x18016fd10	HIGH	{"reset": true}
GET /tournament	FutTournamentList	0x180169ef0	MEDIUM	ARRAY root
GET /tournament/user	FutTournamentLoadData	0x180147cb0	MEDIUM	{round, dataVersion, tournamentData}
GET /leaderboards	FutGetLBEntries	0x180144c8d	MEDIUM	{"entries": []}
GET /leaderboards/options	FutGetLBOptions	0x18014351c	MEDIUM	{category, id, period, view, url}
POST /champion	FutChampionsRegistration	0x18014980d	MEDIUM	{} (no atoms)
GET /champion	FutGetChampionsTopX	0x18014a09d	MEDIUM	{"entries": []}
GET /captcha	FutGetCaptcha	0x18014e78d	MEDIUM	{encodedImg, sequence, sizeBeforeEncode}

Plus plain acks now routed instead of falling through: /tfa, /clientdata, /livemessage, /activeMessage, ut/delete/.../tournament.

Gated behind FUT_MODES=1, default OFF. Every one of these is documented-but-never-live-tested, and both of today's regressions were "serve a new body the client has never parsed". FutSeasonList in particular wants an array root where we currently send {} on a boot-adjacent path — precisely the shape class that busy-loops at 0x1801c7f1a when wrong. Verified both ways offline: default is byte-identical {} everywhere, FUT_MODES=1 serves the documented bodies, 380 checks green in both. /captcha is served unconditionally (three scalars, strictly better than {}).

Nested members are omitted throughout — prizeSet, elgReq, friendlySeasonHistory, tournament rounds/staff/kit are all SKIP-safe and all FREEZE-RISK if wrong.

Remaining gaps, ranked

1. POW envelope — blocks LVL/credits; the armed probe settles it in one launch.
2. Match request shape — response side done; the request (score/result) is unreversed, _match_result() falls back to a draw until a real match is logged.
3. SBC / Draft — the only families with NO documented schema. FutSBC* and FutGetDraft* still need a deserializer walk, and all four attempts at a generic walk have now failed (see §6.2 — the last one, via factory name-LEAs, got cands=0 because Ghidra creates no references from those LEAs: the name strings are not defined data). Next idea: define the strings as data first (or scan .text for the RIP-relative LEA encoding directly), then re-run the factory walk.
4. dbdata.dll — imported at /tmp/fifadb/dbproj, untouched: real player names/ ratings to replace the 18 hand-entered PACK_POOL entries.

9. Class → deserializer SOLVED: the -4 rule (loop iteration 2)

Six attempts. The fix is one subtraction.

A response class's name literal is preceded by a 4-BYTE HEADER, and the factory's lea r8,[rip+...] points at THAT header — not at the text. Ground truth:

0x18012170c  LEA R8,[0x18021d690]      <- the factory's reference
0x18021d694  "FutDestroyMatchServerResponse"   <- the string, 4 bytes later

Every earlier attempt looked up the string address itself and got zero candidates — which four times looked like "this class has no deserializer" rather than "my lookup is off by four". Ghidra had the reference all along; the manual RIP-relative LEA decoding in attempt 5 was unnecessary.

Now ghidra_env.class_deser(cls) implements it: xrefs_to(name-4) → factory → the .rdata vtable it references → deserializer at slot +0x08.

Reliability, measured: 3/3 correct whenever it resolves (controls FutSquadSave 0x180171a60, FutSquadList 0x180172140, FutCreateMatch 0x180120380), but it produces false negatives — FutDestroyMatch and FutSeasonLoadData resolve to nothing despite having known deserializers. So an empty result means "unknown", never "no deserializer". Always batch with a control.

SBC + Draft schemas (11/15 resolved — the last families with no docs)

class	deser	parsed keys
FutGetDraftCurrentState	0x180147070	roundsInfo(0x293) + the draft state enum: CAPTAIN_DRAFT, FORMATION_DRAFT, PLAYER_DRAFT, MANAGER_DRAFT, COMPLETED_DRAFT, READY_FOR_MATCH, READY_FOR_REWARDS, PICK_DIFFICULTY, INVALID
FutSBCSubmitChallenge	0x180161b00	active(0xa), grantedChallengeAwards(0x14a) — the SBC reward key
FutGetDraftStats	0x1801508c0	active, draftsCompleted(0xe2), scoredGoals(0x29b)
FutLoadSetTypes	0x180154990	active(0xa)
FutSBCLoadCategoryDetails	0x18017b2b0	(no named atoms recovered)
FutSBCSetData, FutPickDraftChoice	0x1801642c0	shared no-op (return 1) → {} is complete
FutSBCTagSets, FutSBCSaveSquadChallenge, FutPickDraftAutoChoice, FutPurchaseDraftMode	various	no atoms → {} is complete

Unresolved (false negatives): FutGetDraftChoices, FutGetDraftAward, FutGetObjectives (no RTTI string at all — the Manager Tasks feed is something else), FutStickerBookSearch.

Practical upshot: most SBC/Draft responses are genuine acks, so the catch-all {} is already correct for them — the families were never as blocked as they looked. The two that carry real data are FutGetDraftCurrentState (a state machine) and FutSBCSubmitChallenge (grantedChallengeAwards, the SBC payout).

0x1801642c0 recurring is not a collision: it is the shared no-op deserializer, the same one FutSquadRename/FutSquadDelete/FutChangeClubName use.

10. Traffic-replay coverage audit (loop iteration 3)

dbdata.dll was the planned target but is a poor investment: it carries no table or column name strings at all (7,960 identifiers, zero matching player/team/league or overall/firstname/commonname), so the schema is not in the DLL and extraction would be a large effort for cosmetic gain. Earlier work got real assetIds from the live InGameDB instead — that remains the cheaper route. Deprioritised.

Instead: extracted every distinct (method, path) the client has ever sent across all sessions in /tmp/utas_server.log — 48 pairs — and diffed them against the route table. That surfaced three live paths nobody knew about, none of which appear in the request-template table (§1):

PUT ut/game/fifa17/clientdata/userHubData        (FUT hub, 20:40 session)
GET ut/game/fifa17/club/stats/consumables        (MY CLUB screen)
GET ut/game/fifa17/club/stats/staff
GET ut/game/fifa17/club/stats/year

This is the third time a suffix endpoint has been invisible to static analysis (/squad/list, /user/club, now these). The request-template table is a floor, not a ceiling — the log is the only ground truth for what the client actually calls.

Fixed

club/stats/* was answering with the wrong body. It fell through to the generic /club route, which returns the FULL 28-item club item list — where the client asked for stats, and re-sent on every poll. Now routed ahead of /club and answered {} (no schema is documented; {} is the proven-safe default). /club itself unchanged.

clientdata/<key> now persists. The client PUTs its own hub state; we store the blob and hand back exactly what it gave us. Zero-risk by construction — we never synthesise a shape, only echo the client's own bytes. This is also the most plausible route to the hub's MANAGER TASKS 0/0 tile persisting, since §9 established there is no FutGetObjectives class in the binary at all — the tile state may simply live in this blob rather than in a server response.

Verified: PUT then GET round-trips the blob byte-for-byte; club/stats/* returns {}; /club still returns the item list; 380 checks green. Test blob removed from the profile afterwards.

11. Pre-test regression proof + match unit tests (loop iteration 4)

Before the morning live test, the useful work was proving that everything added overnight (match loop, game-mode ladder, clientdata, club/stats, POW) did not change what the client sees.

Regression diff against the last fully-good session

Extracted what we actually SENT during the 20:40 session — the one that was good in every respect (hub, coins, record, active squad, MY SQUADS: 1, PUT /squad/0) — and replayed every non-mutating request against the current defaults:

identical: 19   differing: 0   errors: 0

PUT /squad/0 was re-checked separately against a scratch profile (never the real save) and still answers {"id": 0}. So the morning test starts from a state byte-identical to the last known-good one, with the new routes reachable only via their env flags.

This diff is worth re-running after any batch of route changes: extract (verb, path) -> response from a known-good window in /tmp/utas_server.log, replay the GETs, compare prefixes.

tools/test_match_rewards.py — 51 checks, pure

The match loop mutates (credits coins, bumps W/D/L), so it cannot go in the read-only HTTP contract suite. destroy_match_body() is now split out of match_route() as a pure function and tested with no server, no state, no profile:

• _match_result() — 14 scorelines including nested match/stats bodies, textual WIN/defeat/tie, and the two fallback cases ({} and None → draw). Also pins that 0-0 is a draw WITH a score, not "no data" — the one case where a sloppy truth-test would silently reclassify a real result as unknown.
• destroy_match_body() — every field scalar (a non-scalar here is the freeze class at 0x1801c7f1a), allCoins is the NEW balance, the nested userData/gameModeAward/matchCoinMultipliers stay omitted, and — load-bearing — the key is EA's misspelled boostConis (atom 96), not boostCoins. A renamed key is SKIP'd silently, i.e. the reward would vanish with no error anywhere.

Suites now: test_fut_contract.py 380 (live, read-only) + test_match_rewards.py 51 (pure). Both green.

12. The pack→club hand-off is unverified (loop iteration 5)

Noticed in the save: 12 cards sitting in the PENDING pile (profile["purchased"]) with 6 packs opened, and PUT ut/%s/item (FutMoveCard) fired zero times across every logged session.

Corrected reading before drawing a conclusion: all the store traffic in the logs is PUT /ut/v2/game/fifa17/store/transaction/0 with body {"state":"TRANSACTIONCANCEL"} — that is the boot-time cancel of a pending transaction, not a purchase. So no pack has been bought in-game in any logged session, and the 12 pending cards are leftovers from earlier work. The correct conclusion is therefore "the pack→club loop is UNVERIFIED", not "it is broken" — the evidence does not support the stronger claim.

It remains a real gap: cards from an opened pack only reach the club when the client sends PUT ut/%s/item from the reveal screen's "send to club", and that request has never been observed. Structurally this is the same shape as the squad blocker — an assumed client request that may simply never arrive.

tools/fut_admin.py — offline save maintenance

• --show (default): full profile summary incl. the pending pile
• --flush-purchased [-n]: move pending cards into the club, -n = dry run
• --backup: timestamped copy

Safety: the client desyncs fatally (logout) if a card exists in BOTH the pending pile and the club (docs/CARD_SYSTEM.md). So the flush moves, never copies — it reuses Store.move_items(), which deletes from purchased inside the same locked transaction that appends to items, keeping that invariant in exactly one place. It takes a backup first and must be run with FIFA closed.

Not run. Only --show and a dry run were executed; the save is untouched (coins 12600, 28 club items, 12 still pending, no backup file written). Flushing changes the user's save, so it is their call — and if a live pack-open turns out to issue PUT /item correctly, the flush is unnecessary.

Live test worth adding to the morning list

Buy a pack in-game and watch /tmp/utas_server.log for PUT /ut/game/fifa17/item. If it appears, the loop works and fut_admin.py is just a repair tool. If it does not, the reveal screen is another client-side gate to reverse — and the log will show what it sends instead.

13. Response audit: market schema + unparseable-key sweep (loop iteration 6)

Market/trade responses are already exact. The core auction record (auctionInfo[] element, deser 0x18013e410) documents 12 atoms — tradeId, itemData, tradeState, bidState, buyNowPrice, startingBid, currentBid, expires, sellerName, sellerEstablished, watched, coinsProcessed — and _auction_record() serves exactly that set, with the right types throughout (expires as SECONDS not epoch, sellerName inside the 30-char bound, itemData an object, the two enums as strings). The list bodies ({auctionInfo, credits, total, duplicateItemIdList}), FutISStart ({id}) and FutISViewTrade ({auctionInfo, credits}) all match too. Nothing to fix.

Unparseable-key sweep. Walked every key we serve across 15 endpoints (nested, to depth 4) and checked each against fut_atoms.tsv. Anything absent from that table can never be read: the key hash misses and it routes to the value-SKIP handler 0x180135ff0.

Result — only 2 inert keys in the entire response surface:

key	where	verdict
definitionId	every card item	INERT — not an atom. The live key is resourceId.
limitType	store catalog entry	INERT — not an atom.

Both are harmless (SKIP'd, no freeze risk) and are kept — other FIFA versions do use definitionId. But fut_seed.player_item carried a comment claiming "some FUT APIs key on definitionId", which is wrong for FIFA 17 and would mislead the next reader into treating it as load-bearing. Corrected in place, citing the same phantom-key precedent as itemDbVersion/checkServerDbVersion in blaze_responder.

That 2-out-of-everything ratio is the useful headline: the response surface is clean, so any remaining live misbehaviour is about shape/envelope or missing endpoints, not stray fields.

14. Live morning session (2026-08-04) — store fixed, move path unsolved

14a. Store "unknown" packs — SOLVED

The store rendered every tile as unknown with 0 ITEMS / 0 BRONZE / 0 RARES.

"unknown" is not an error string: FUN_180133f60 constructs a FUT String with that literal unconditionally — it is the DEFAULT, shown whenever nothing overwrites it.

What overwrites it is displayGroup(0xd9), and the structural point is that it is parsed by the SAME element parser 0x18013af30 recursively: a display group is itself a pack-shaped object carrying the tile's name and aggregate counts. The store screen renders GROUPS, not raw packs. We never sent displayGroup, so the client built a default group → unknown / zeroes.

Fix: every pack now carries a single-entry displayGroup array (freeze-risk if scalar) plus displayGroupAssetId(0xda) and displayGroupUseDefaultImage(0xdb).

Two ENDPOINT_MAP corrections from re-extracting 0x18013af30:

• It claims id/packType/isPremium/quantity/saleType/purchaseLimit/ purchaseCount are skipped no-ops. They are all parsed (0x15c, 0x20f, 0x176, 0x26b, 0x298, 0x265, 0x261).
• It claims extPrice.finalPrice/originalPrice take amount/currency. The inner parsers 0x180139070/0x18013aae0 read externalPriceId(0x11a) + active; our {"amount":N,"currency":"mtx"} was discarded wholesale.

14b. Quick Sell — was silently free

Quick Sell All sends POST ut/delete/%s/item, which was UNMAPPED. The catch-all {} is ACCEPTED by the client (no error, session survives) but nothing was credited: six cards destroyed for 0 coins. Now routed to quick_sell_route(), crediting discardValue with a rating-based fallback (600/300/150/50) since seeded cards have none. Verified: +600 for an 86-rated card.

14c. "Send to Club" — UNSOLVED after 7 attempts

PUT ut/%s/item moves the cards server-side every time, then the client shows "We are sorry but there has been an error connecting to FIFA 17 Ultimate Team" and POSTs ut/delete/auth. Eliminated, each by live test:

hypothesis	result
missing chemistry(0x81)	failed without it too
unknown keys + no skip handler in 0x180128600	real finding (it genuinely has none), but dreamSquads-only still failed
POW saturating the HTTP layer (109k reqs)	same failure with POW off
missing FUT_RS4_URL_<CALL> keys	netwatch logged ZERO non-loopback dials; 146 were genuinely missing and are now served, but they were not the cause
the response body at all	{} fails too
the reveal screen's exit path	Quick Sell works from the same screen

So the move endpoint rejects every possible response while its sibling accepts a bare {}. "error connecting" is FIFA's GENERIC FUT-session failure text, not a network event — do not read it literally (that inference cost two wasted attempts).

Workaround shipped: FUT_PACK_AUTOCLUB=1 (default) deposits pack contents straight into the club at open time and keeps the pending pile empty, so the client is never offered a move. Packs are fully usable. FUT_MOVE_BODY=empty|dreamsquads|full switches the response shape for future bisects without a code edit.

Next idea, untested: single-card S (Send to Club) vs batch W (Send All) — if single works, it is a batch/count issue, a completely different target.

14d. Process note

Four of six failed hypotheses were things testable before proposing them. The two findings that actually moved this forward were the USER's: the screenshot with the error text, and the Quick Sell result. Ask for the on-screen text and try the neighbouring action FIRST — both were cheaper than any decompile done here.