fifa17-recon: FUT squad blocker solved + userInfo delivered

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
This commit is contained in:
funman300
2026-08-03 20:47:16 -07:00
parent 6270c37208
commit 59934b4ef0
16 changed files with 1811 additions and 94 deletions
+35
View File
@@ -152,6 +152,41 @@ def make_squad(step="s1"):
return squad, {"itemData": club_items}
def squad_rating(squad):
"""Squad rating = mean of the rated players actually placed (0 when the squad
is empty, e.g. the s1 zero-resolve ladder step)."""
ratings = [(pl.get("itemData") or {}).get("rating", 0)
for pl in squad.get("players", [])]
ratings = [r for r in ratings if isinstance(r, int) and r > 0]
return sum(ratings) // len(ratings) if ratings else 0
def squad_summary(squad):
"""One FutSquadList element (deser 0x180141fc0, verified 2026-08-03).
Exactly six atoms are recognised; everything else is SKIP'd:
rating 0x274 int (scalar getter 0x1801c79d0)
chemistry 0x81 int (scalar getter 0x1801c79d0)
formation 0x12b STRING (string getter 0x1801c7aa0 -> enum conv 0x180166590)
id 0x15c int
squadName 0x2d3 STRING
squadType 0x2d6 STRING (string getter 0x1801c7aa0 -> enum conv 0x1801668e0)
NOTE: formation/squadType are STRINGS here, exactly as in the full-squad parser
0x18013d1f0 -- they go through the same 0x1801c7aa0 + converter pair. (The
rebuild plan's "<int>" for those two was wrong; feeding ints to a string getter
is the classic type-mismatch freeze at 0x1801c7f1a.)
"""
return {
"rating": squad_rating(squad),
"chemistry": int(squad.get("chemistry", 0)),
"formation": squad.get("formation", "f442"),
"id": int(squad.get("id", 0)),
"squadName": squad.get("squadName", "OpenFUT"),
"squadType": squad.get("squadType", "REGULAR_SQUAD"),
}
# Selected at import time from the environment (default s1 = the zero-resolve test).
STEP = os.environ.get("FUT_SQUAD_STEP", "s1")
SQUAD, CLUB = make_squad(STEP)