This file has been handing out bodies that freeze the client, under the heading
"MINIMAL known-good".
1. FutGetDraftCurrentState. The root container is a JSON ARRAY. The documented body was
object-root, used the spelling DRAFTSQUAD_ON which is NOT an accepted squadState
value, and embedded a full squad object. Anyone serving it would have reproduced the
exact hang the entry existed to prevent, which is what happened live on 2026-08-03
when our generic /squad route answered this endpoint with a squad object.
Path corrected too: it is ut/%s/squad/mode + /draft/state, not ut/%s/draft/state.
The `squad/mode` segment was missing, which is why the URL is invisible to the
request-template table. Established by live capture, not statically: FUN_180146ac0
appends the suffix to a caller-supplied buffer and has no resolvable callers.
2. FutGetDraftAward (0x1801510c0) has the same array-root prologue, and its documented
object-root body would hang identically. Corrected, and marked TODO/CONFIRM on the
member list, which was not re-verified this pass.
Both of these survived because a census claimed only three array-root readers
existed in the DLL. It missed one. The census run to check it was wrong in the other
direction. ~23 of 86 top-level readers are still unclassified, so the file now says:
do not serve any endpoint here until its root container is classified by reading the
actual prologue, not by regex.
3. roundsInfo element: `score` and `penaltyScore` offsets were swapped (+0x10 / +0x18).
4. FutSeasonList: deserializer is 0x1801683f0, not 0x180167740 (that is the ELEMENT
parser), and the root is an OBJECT with one key `seasons`(0x2ad), not an array.
Someone documented the element parser's key set at the document level, and
utas_server.py served that shape for months on the strength of this row. Three of
the listed element keys are inner members of elgReq and inert at element level.
Added: element ordering (type before divisionId), stride 0x318, the (0xb-divisionId)
short, and the three array-loop members that must stay omitted.
5. Recorded on the season entry that the client has NEVER requested /season across 486
real requests, so no body there is observable yet.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
The client now issues PUT /squad and the hub renders coins, record and the
squad roster. Three separate root causes, all verified live.
Squad blocker (the long-standing "client never sends PUT /squad"):
AddPlayerToSquad, GetSquads and SelectSquadById issue ZERO network requests
(pure local model reads/mutations, FutSquadServiceImpl vtable 0x180233ff0);
only SaveCurrentSquad writes, and it is unguarded. The client simply needed a
populated ACTIVE squad model, which arrives via the massinfo `squad` member.
No response of ours was ever being rejected.
userMassInfo is NOT required to be {}:
0x180174630 is a FLAT {userInfo, squad, settings, userData} body -- the old
"wrapper key is user" note was wrong, and the historical freeze was the
malformed squad member, not the envelope.
clubNameChangeAllowed must be false:
sending true advertises a club-rename flow whose UI model is never populated;
the client shows a naming prompt and dies confirming it (ACCESS_VIOLATION
reading 0x0 at FIFA17.exe+0x71b8651, 4/4 runs, no CardsDLL frame and no request
in flight). Isolated by a single-variable run; guarded by a contract check.
Endpoint/schema corrections found in live traffic, invisible to static analysis:
* GET ut/%s/squad/list is a real endpoint and must return {"squad":[...]},
not the active-squad object (the /list suffix is appended by the caller, so
it never appeared in the request table)
* PUT lands on ut/%s/squad/<id>, not a bare ut/%s/squad
* userInfo currencies are read as name/funds/finalFunds/active -- there is no
"value" key, so coins always rendered 0
* squad-list elements take STRING formation/squadType, not ints
* the CardsDLL script-API thunk<->name table was off by one (AddPlayerToSquad
is 0x18004aa70; 0x18004aff0 is GetPotentialChemistry_Club)
FUT_MASSINFO / FUT_USERINFO ladders keep every step of the bisect reproducible.
Contract suite 311 -> 358 checks. Tooling added: PyGhidra harness (Ghidra's
Java/OSGi script path is broken on this box), minidump reader, live code grabber.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Store "not available" root cause reversed from CardsDLL:
- ut/v2/game/fifa17/store is an ELIGIBILITY gate (FutStorePackQuantities
deser 0x1801758c0), not a quantity list. It reads one key "result"
(atom 0x288); the store screen refuses to open unless SUCCESS. Was
unhandled -> catch-all {} -> "not available". Now returns {"result":"SUCCESS"}.
- Store-screen entitlement checks (0x18001749d/0x1800175a2) read IS_*/
*_PURCHASE_ENABLED Blaze flags, separate from storeEnabled. Added the full
confirmed set (14 flags) to FUT_RS4_CONFIG.
- Catalog: assetId (0x23) is the real pack identity; extPrice inner keys are
amount/currency (not mtx). (Also gated client-side by GetSystemMetrics>1024x768.)
Full FUT API reversed (clean-room, CardsDLL only) into docs/ENDPOINT_MAP.md:
~100 FutXServerResponse types across 7 feature groups (market, SBC, draft,
seasons/match, club, store, user/hub), each with deserializer VA, atom-mapped
field schema + types, freeze-risk flags, and minimal known-good JSON.
Tooling kept: tools/atomdump.py (dumps the 907-atom key table at 0x1802d2760)
-> docs/fut_atoms.tsv. Research prompt: docs/OPENCODE_ENDPOINT_PROMPT.md.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
funman300