Two experiments, both negative, and the negative has a mechanism behind it rather than
being another failed guess.
FUT_CLUB_PAGE served 114 items to /club?...count=11 tile still 0 TOTAL PLAYERS
FUT_CLUBSTATS full stat set, players=114, all modes panel still Players 0
The bodies went out: four "CLUBSTATS: 11 stat rows (players=114)" responses in the log,
panel re-entered afterwards.
FUN_18012fbe0 store+0x78 = request+0xc4 the mode tag is copied from the
REQUEST that just completed
FUN_180043b90 switch (store+0x78)
case 1 +0x800(1)->PLAYERS_EMPLOYED, (0x1e)->BALLS_EARNED, (0x28)->KITS_AVAILABLE,
(0x14)->STADIA_OWNED, (10)->STAFF_EMPLOYED, (0x32)->TROPHIES_WON
case 6 CARDS_NO_TRAINING_*, CARDS_NO_CONTRACT_*, CARDS_NO_FITNESS_*
The MY CLUB summary is case 1, which needs mode 1 (club). The client requests staff,
year and consumables and NEVER club, so the tag settles at 6 and case 1 is never
selected. Our values are stored correctly (contextId 1 forces contextValue 0, the
global bucket the +0x800 getter reads) and case 1 reads exactly the six ids we set.
Nothing ever asks for them.
THE MODE IS CHOSEN CLIENT-SIDE FROM THE REQUEST URL. No response body can change it,
so there is no body that fixes this and generating more of them is wasted work.
Two independent corroborations rather than one story that merely fits:
- case 6 reads 0x3d CONTRACTS, 0x3e TRAINING, 0x40 FITNESS, exactly the three ids
FUN_18012fd40 cannot produce from any type string. The consumables view is
unsettable from this endpoint by construction.
- FUT_CLUB_PAGE eliminated the only other candidate: the tile is not a count of the
list we return.
Both flags stay implemented and default OFF. FUT_CLUBSTATS is correct against the
verified schema and would populate the moment a club-mode request occurred; deleting it
would throw away the schema work for no gain.
Recorded against myself: I argued from the matching labels (tile "TOTAL PLAYERS", panel
"Players", both zero while we served {}) that the two read the same store and one body
would fix both. The store IS shared. The SELECTION is not, and that is what decides it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
LIVE 2026-08-04: the draft-state array fix WORKED. The screen rendered instead of
hanging and the client advanced to the entry-fee screen, then crashed on the next
call, which we had never implemented:
GET /squad/mode/draft/state?mode=ONLINE -> our array body screen RENDERED
GET /user/credits -> 7200
GET /store/purchasegroup/all -> the entry-fee screen
POST /purchase/mode/0/draft {"currency":"COINS","usePreOrder":0}
-> {} UNMAPPED, then the crash
Advancing the failure to the next unimplemented call is what a correct fix looks like.
ENVELOPE AMBIGUITY RESOLVED, and ENDPOINT_MAP's note about it is wrong. Two structures
reference RS4:FutPurchaseDraftModeServerResponse:
0x18014c260 vtable 0x180224ef8, factory 0x18014c090. 3188 chars, OBJECT root
(prologue tests != 10 = END_OBJECT), 1 skip handler, exactly the seven
scalar ints. THIS IS THE RESPONSE PARSER.
0x180150310 vtable 0x1802262f0, factory 0x180150260. 1836 chars, ARRAY root
(loops until 0xd), ZERO skip handlers -- and NOT a response root at
all. It parses ENTRANCE CRITERIA: each element's name is strcmp'd
against the literals "COINS", "POINTS", "DRAFT_TOKEN" and stored at
+0x28/+0x2c/+0x30. It shares the class-name string because it is the
fee sub-object, not an "alternate/summary envelope" as documented.
THE CRASH ITSELF DISCRIMINATED, which is worth keeping as a technique. An object-root
parser handed {} parses benignly and leaves defaults; an array-root parser handed {}
desyncs and HANGS, which is exactly what draft/state did before the fix. We observed a
CRASH, not a hang, so the object-root parser is what ran and the failure is downstream
of an empty-but-valid parse. Consistent with 0x18014c260, inconsistent with the other.
Coins are NOT deducted. The client posts the price in the URL and it sent 0, because we
omit entranceCriteria from draft/state so there is no fee to charge. Charging a guessed
amount would be inventing an economy rule.
ALSO FIXED, before it reached the game: the route table hands handlers the compiled
PATTERN, not a match object (the dispatcher calls fn(rx, self)), so calling .group() on
the first argument raised AttributeError and killed the connection outright. That is
strictly worse than the {} it was replacing. Caught by verifying the response actually
changed after the restart rather than assuming the route worked.
Default ON: the behaviour it replaces is a confirmed crash, so no working state is at
risk. FUT_DRAFT_PURCHASE=0 reverts.
392 + 61 checks green, zero tracebacks on a clean boot.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Live 2026-08-04: the CLUB STATS panel shows eight zeros (Rare Players, Players, Staff
Employed, Stadia Owned, Trophies Won, Kits, Badges, Balls Earned) while the client
fetches /club/stats/{staff,year,consumables} and we answer {} to all three. Those
zeros are ours. Every row name maps to a type string in the recovered map.
Wire schema, fully verified from deser 0x180130150 (7,870 chars, read end to end):
{"stat":[{contextId:int, contextValue:int, type:string, typeValue:int}]}
Unknown keys route to FUN_180135ff0 at BOTH levels, so extras are inert.
FIVE THINGS THAT DECIDE WHETHER IT WORKS:
1. EVERY RESPONSE WIPES THE WHOLE MAP FIRST. Nothing accumulates, so a good body on
one mode followed by a thin one on another ERASES the first and request ordering
decides what survives. Handled by serving the SAME COMPLETE SET on every Stats2
mode: whichever lands last leaves the map correct. (One investigator reported this
factory does not wipe; a reviewer re-read it and refuted that. The wipe is real,
and this is the second negative claim from that batch to fail.)
2. /club/stats/staff IS A DIFFERENT CLASS: FutStaffBonus, {"bonus":[{type,value}]},
not Stats2. Its type strings are undecoded so it keeps {}, which is safe and also
means it does not disturb the Stats2 map.
3. ELEMENT-LOCAL VARIABLES ARE NOT RESET BETWEEN ELEMENTS -- the clears sit before
the array loop, not inside it -- so omitting a key in element N inherits element
N-1's value. All four keys are emitted in every element.
4. The storage key is contextValue ALONE; contextId is only a guard (1, or 5..9,
forces contextValue to 0, the global bucket the +0x800 getter reads). contextId 1
throughout.
5. 0x3d CONTRACTS, 0x3e TRAINING and 0x40 FITNESS are READ by the panel but cannot
be SET from here. No type string produces them.
THIS IS ALSO NOW THE HUB-TILE CANDIDATE. The investigation concluded the MY CLUB tile
does not read this store, but flagged that negative as BOUNDED: the interface comes
through a QueryInterface adapter, so the vtable is assembled at runtime and cannot be
read statically. Live evidence points the other way. The tile reads "0 TOTAL PLAYERS"
and the panel reads "Players 0" -- same quantity, both zero, both while we answer {}.
And FUT_CLUB_PAGE ruled out the alternative: 114 items served to /club, tile still 0,
so it is not a count of the list. Strong inference, not proof; this flag is the test.
The test is unusually clean: the club holds 114 items and all of them are players, so
every other row is an honest zero. If it works, exactly two numbers move (Players and
Rare Players, 0 -> 114) and nothing else changes.
Gold/silver/bronze thresholds are FIFA's rating convention (75+/65-74/under), not
something read out of the binary, and the code says so.
Default OFF. 392 + 61 checks green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Five parallel Ghidra investigations, one adversarial reviewer each, one synthesis.
Kept in the repo because the reviewer corrections are load-bearing: they refuted claims
in four of the five reports, two of which would have shipped wrong behaviour (a
speculative /season body justified by our own curl traffic in the log, and a store
field block that was a freeze rather than a regression).
Carries the next live session (one launch, three flags, four menu actions, one
read-only memory probe), the implementation queue, what is genuinely blocked and why,
and a what-could-make-this-plan-wrong section that names the store change as the
concrete regression risk.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
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
ZERO-LAUNCH FIXES from the multi-agent pass over 0x18013af30 and 0x1801683f0.
FUT_STORE_FIELDS IS DELETED, AND IT WAS A FREEZE, NOT A REGRESSION. It sent
"actionType": 0 and "firstPartyStoreId": 0 as JSON INTEGERS. Both atoms (0x8, 0x127)
are read with the STRING getter 0x1801c7aa0. That is the exact type-desync class this
project exists to avoid. So "the corrections stopped packs opening" was never bad luck
or an unrelated field: two of them were the documented freeze mechanism, shipped by a
change whose own comment claimed it was correct about what the parser reads. Knowing
WHICH atoms a parser reads tells you nothing about which TYPES it demands. Read the
getter, every time. (Two other fields in that block were no-ops anyway: useDefaultImage
0x36a stores inverted, and visible 0x37d never reads its value at all.)
FUT_STORE_GROUPS IS DELETED and its freeze is now traced end to end. It sent
displayGroup as an ARRAY of pack-shaped objects on the belief that the key was parsed
recursively by the same element parser. It is not recursive at all: case 0xd9 never
re-enters 0x18013af30. It is a FLAT OBJECT with exactly two members. An array desyncs
the reader, the parser runs off the end of the document, and the tokenizer returns the
same token forever with nothing consumed, spinning inside FUN_1801c7f10 whose body
contains the observed PC 0x1801c7f1a.
Both were being kept as togglable "maybe nearly right" experiments. Each is a loaded
gun; neither survives contact with the decompile. Deleted rather than left switched off.
NEW FUT_STORE_DISPLAYGROUP (default 0): send the one key that actually names a tile,
displayGroup = {"value": "<pack name>"}. `value` (0x377, STRING) writes record offset
+0x00, the same slot whose constructor default is the literal "unknown" (the only such
literal in the DLL, 0x180223108). The tiles say "unknown" because nobody ever sent the
field. Distinct values per pack so grouping stays 1:1. priority/displayGroupAssetId/
displayGroupUseDefaultImage all omitted as second variables.
Default OFF for a reason the token-balance proof does not cover: this may be the first
field we have sent that selects a RENDER PATH rather than a value, and that code is
packed.
SEASON ROOT SHAPE CORRECTED. season_list() and its docstring were both wrong in the
same way: the deserializer is 0x1801683f0 (object root, one key seasons=0x2ad, array
inside), not 0x180167740, which is the per-ELEMENT parser. Someone read the element
parser and served its key set at the document root, so a bare array populated nothing.
Three of the keys served (eligibilityKey/Slot/Value) are inner members of elgReq and
inert even at element level. Also recorded: `type` must precede `divisionId` because
the divisionId branch reads the parsed type at elem+0x1b4.
Still behind FUT_MODES and still pointless to serve: across 486 real client requests
the game has NEVER asked for /season. Every /season line in our log is our own curl.
NEW FUT_CLUB_PAGE (default 0): an experiment, not a fix. The MY CLUB counter's
renderer is not in cardsdll (no two-number formatter of any spelling exists) and
FutStickerBookSearch has no count atom, so there is no field we can send that IS the
number. What is still testable is whether the counter is a Flash-side count over the
returned list, which a pure length change discriminates. A NULL RESULT IS THE VALUABLE
ONE: if the counter does not move, there is no server-side lever for this symptom and
the right outcome is to prove that and stop.
392 + 61 checks green, defaults byte-identical.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
The "4-byte header" that precedes every response class name in .rdata, which cost six
failed class-to-deserializer resolutions before anyone noticed the offset, is not a
length prefix or a refcount. It is the string RS4:. The full literal is
RS4:FutXServerResponse, and searching for the bare class name lands four bytes in.
Verified directly on three classes:
FutDestroyMatchServerResponse name@0x18021d694 header = b'RS4:'
FutGetDraftCurrentStateServerResponse name@0x180224204 header = b'RS4:'
FutStickerBookStats2ServerResponse name@0x1802220cc header = b'RS4:'
Found by a verification agent that had been instructed to distrust the rule. It did,
and came back with the reason rather than the offset. A magic constant you have to
remember is a rule you will eventually get wrong; a prefix you can read is not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
The whole match family is one RPC descriptor block (rows 49-54, every row using URL
template index 16 = `ut/%s/match`) with a fixed suffix appended per call:
CREATEMATCH ut/game/fifa17/match PLAYGAME ut/game/fifa17/match
MATCHREADY ut/game/fifa17/match/ready DESTROYMATCH ut/game/fifa17/match/end
RESETMATCH ut/game/fifa17/match/reset KEEPALIVE ut/game/fifa17/match/keepalive
THERE IS NO /match/{id} URL. The id travels in the body. Our reward path was gated on
`h.command == "DELETE" or "/ut/delete/" in h.path` and extracted the id with
re.search(r"/match/(\d+)"), so it was waiting for a request the client does not make.
The gate is now widened to include a /match/end path with ANY verb, because the verb
genuinely cannot be determined statically: the strings "PUT" and "DELETE" do not exist
anywhere in cardsdll.dll (0 hits each), so verb selection happens outside this DLL. A
reviewer flagged "the reward path can never fire" as overreach on exactly that point;
widening rather than replacing the gate is the response.
THE RESULT SIGNAL IS `endReason` (atom 260), a STRING enum with nine values: WIN DRAW
LOSS DNF QUIT NO_CONTEST DNF_WIN DNF_DRAW DNF_LOSS. Not a score comparison. The score
lives in `myMatchStats.goals` / `opponentMatchStats.goals`, two literal-keyed objects
of 15 int fields each, and the client OMITS both when endReason is DNF or QUIT, so
nothing may require them. _match_result() now reads endReason first and keeps the old
spelling probe only as a fallback, because request-side static findings are a floor:
PUT /item's swap/tradeId appeared in no static listing either.
THREE CORRECTIONS TO THE RESPONSE, all of which were shipping wrong:
1. `coins` (atom 149) is NOT a top-level key. It is read only inside `gameModeAward`.
The one field most obviously named "the reward" was being silently skipped.
2. `qualifiedChampionEventId` (0x269) has a SIDE EFFECT: its branch calls through a
manager vtable after storing. Sending a habitual zero poked champion-event
machinery for no benefit. Removed.
3. `bidTokens` (atom 89) inside gameModeAward is MATCHED and then handled by nothing,
so its value token is left unconsumed. That is the precondition for the desync
spin. A freeze trap dressed as an ordinary field; now guarded by a unit check.
test_match_rewards.py rewrote its expectations. The old version asserted a top-level
`coins` and passed happily while the server shipped a body whose reward field the
client never read. A test that encodes the wrong schema converts a bug into a
guarantee. New test_end_reason_is_authoritative covers all nine enum values, the
stats-less DNF case, and that endReason beats a contradictory score probe.
DEFAULT ON (FUT_MATCH_END=0 reverts), a reasoned exception to the flag convention:
nothing here is live-proven because no match has ever been played, and the old
behaviour is not a working screen but a path that provably could not fire.
61 unit checks (58 with the flag off), 392 contract checks green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Deser 0x180147070 (FutGetDraftCurrentStateServerResponse) discards tokens until it
sees START_ARRAY. Handed a top-level OBJECT it never reaches its exit condition and
spins in the inner `while (tok != END_OBJECT)` loop while the tokenizer returns EOF
forever. Process alive, no crash dump, no dialog: exactly the signature observed live
on 2026-08-03, when our generic /squad route answered this endpoint with a full
active-squad object.
The suffix composition `ut/%s/squad/mode` + `/draft/state?mode=...` makes the URL
invisible to the request-template table, which is why /squad swallowed it. Fourth time
a suffix endpoint has been invisible to that table, second time the generic /squad
route has eaten one (/squad/list was the first).
Verified at instruction level rather than by regex: 7 top-level atoms (4 int-getter
calls, 3 string-getter, 0 bool, 2 skip) across the whole body [0x180147070,
0x1801475a3]. FUN_180135ff0 IS present, twice, so unknown keys are inert. NO ATOM
COLLIDES with the squad object we were serving, which means the hang was purely the
container level and not a per-field type desync.
entranceCriteria(0x108) is now known to be an object of three int keys
COINS/DRAFT_TOKEN/POINTS. It is OMITTED anyway: knowing a shape is not a reason to
send it.
A second agent independently simulated this exact body through the deserializer line
by line and got a clean exit in 16 token reads, and separately refuted four claims in
the first agent's report (a census undercount, a wrong .rdata address where
0x18021e7f4 is 'TFA' not the squad template, an incorrect stateParam2 typing argument,
and a dangerous aside about a second array-root envelope). The body survived all of it.
DEFAULT ON, a deliberate exception to "default to the live-proven value": the
live-proven value here HANGS THE GAME, and there is no working screen to protect
because Draft cannot be entered at all today. FUT_DRAFT_STATE=0 restores the old
routing.
392 + 51 checks green; /squad/0 and /squad/list verified unchanged.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
User-Agent filter: implemented as the default in futlog.py.
The two wrong .rdata addresses: verified they never reached any document. They existed
only in an agent recon report, so there was nothing to correct. Kept the reviewer's
corrected values because they are verified and useful:
RS4:FutGetClubInfoServerResponse 0x180221a38 (not 0x180220e38)
RS4:FutStickerBookSearchServerResponse 0x180221e48 (not 0x180221248)
Closing an item by checking it was never a problem counts as closing it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
/leaderboards/options is the ONLY mode-related endpoint the real client has ever
requested, and we answer {} because FUT_MODES is off. Three of its seven occurrences
are followed within ~2 minutes by /user/accountinfo and a fresh /ut/auth, which is the
signature of hitting an error, returning to the main menu, and re-entering FUT.
Hypothesis: the client fetches mode options on entering the play area, caches them, and
later refuses Seasons from that cached EMPTY body without issuing another request. That
would explain the zero-requests-at-failure observation, which no response-shape theory
has been able to account for: the deciding fetch happened minutes earlier.
Stated as a hypothesis, not a finding. The correlation is real; the causation is not
established. Cheap to test: leaderboard_route already implements an options body behind
FUT_MODES=1.
Risk noted in advance: FUT_MODES=1 also enables /season, whose array-root shape is a
flagged freeze candidate. That risk cannot fire while the client never asks. If this
hypothesis is right, a populated options body is precisely what would make it ask for
the first time, so succeeding at step one arms step two.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
The bug we just closed was invisible to every existing check: PUT /item answered 200
with a well-formed JSON body, and the body told the client the move had FAILED. Seven
attempts, weeks of investigation, and nothing in the suite would have noticed a
regression back to {}.
test_move_verdict_shape asserts the record vector exists, has ONE RECORD PER REQUESTED
ITEM (an empty vector fails the client exactly as hard as a wrong field), and that
id/pile/success carry the number/string/bool types their getters require.
Non-mutating: it asks to move ids that cannot exist, so nothing changes pile. The
verdicts come back success=false, which is honest and is not what is asserted.
Verified it actually catches the regression rather than just passing:
default (ack) 392 checks passed, 0 failed
FUT_MOVE_BODY=empty 382 passed, 1 FAILED -- "returns itemData array"
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
REBUILD_RESEARCH S18, from running futlog.py over the full 3044-request history.
The client has requested /club six times and EVERY ONE carried a query string
(year/type/count/position/level/nation/league/team/sort). The bare path has never
been requested. ENDPOINT_MAP says GET ut/%s/club is FutGetClubInfo, whose only
recognised member is user(0x36c), and concludes our itemData body is skipped and the
club list must therefore be empty. The club list is NOT empty; every card renders. So
either the query form dispatches elsewhere or the row is wrong. TODO/CONFIRM.
Relevant to the MY CLUB counter: we ignore the query string completely and return all
109 items to a request asking for count=11 with position and sort filters, and our
response carries no result total. A paged search response is exactly where a tab
counter would read its number from.
Also recorded: the unmapped view is a standing detector for suffix endpoints the URL
template table cannot show. It has caught four so far.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Implements the standing requirement recorded in priority-2026-08 S5: the User-Agent
filter is now the DEFAULT in the log tooling, not an option. The real client sends
ProtoHttp; our own probes send curl/* or Python-urllib/*. Reading the log unfiltered
gave this project a materially wrong picture of itself (/clubUser and /user/list had 93
and 180 hits, none from the game).
The old futlog.py was a one-off with a hardcoded path and no notion of who made the
request. Replaced with a real tool: timeline or summary, body/response display, path
regex, time window, status filter, and an --unmapped view that lists the endpoints the
client wants and we catch-all. --all and --probes exist for when you deliberately want
our own traffic.
Over the full 3044-request history: 486 requests came from the game.
IT IMMEDIATELY CAUGHT ME OVERSTATING SOMETHING. Yesterday's commit called the PUT /item
request shape "captured for the first time (the client had never successfully reached
this path)". False. There are NINE client PUT /item requests in the log, eight of them
during the failed attempts, every one carrying swap and tradeId:
08:45:11 08:51:13 08:55:21 08:58:19 09:10:52 09:15:26 09:22:31 09:37:12 | 11:15:48
The request was on the wire and in the log the whole time. What was new was reading it.
Same class of error as the truncated decompile in S16: evidence already collected and
not looked at. REBUILD_RESEARCH S17 corrected.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Live 2026-08-04 with FUT_MOVE_BODY=ack and FUT_PACK_AUTOCLUB=0. Bought a bronze pack,
opened it, chose Send to Club. The session SURVIVED, the five cards persisted into the
club pile, and there was no ut/delete/auth logout -- the logout that accompanied all
seven previous attempts.
11:15:48 PUT /item
req {"itemData":[{"id":100000125,"pile":"club","swap":0,"tradeId":0}, ... x5]}
res {"itemData":[{"id":100000125,"pile":"club","success":true}, ... x5]}
11:15:49 GET /user/credits session alive
11:15:51 GET /hub no error dialog
11:16:06 GET /club?year=2017... MY CLUB opened
PUT ut/%s/item never was an ack endpoint. It builds per-item VERDICT records, and the
completion handler raises EVENT_CARDS_MOVE_CARD_FAILURE when the vector is empty or
success != 1. Every body this project ever returned, {} included, told the client the
move had FAILED, and the client ended the FUT session because that is what that event
does. We were failing our own move.
Defaults flipped: FUT_MOVE_BODY empty -> ack, FUT_PACK_AUTOCLUB 1 -> 0. The autoclub
workaround is retired.
New intel, captured for the first time because the client had never got this far: the
request carries `swap` and `tradeId` beside id/pile. We ignore both and the move
succeeded, so neither is load-bearing for a pending-to-club move.
PROCESS, and this is the part worth keeping. The FIRST attempt at this test produced
no PUT /item at all: FUT_PACK_AUTOCLUB=1 had already emptied the pending pile at
purchase time, so the reveal screen had nothing to assign and the client never issued
the request. The workaround for the bug was hiding the bug. Before testing a fix,
check the configuration still lets the client make the call the fix is for.
Two self-inflicted incidents, both recorded in REBUILD_RESEARCH S17:
- Restarting the server to inject a flag WHILE FIFA was running produced the exact
"error connecting to FIFA 17 Ultimate Team" dialog this project spent weeks chasing,
from a plain connection refusal during the ~30s window. Restart only at the main
menu, and check the log for ProtoHttp requests before blaming a response.
- pgrep -f matched the invoking shell twice, killing it before the restart, because
the same command contained the literal script name in a later clause.
Docs updated: REBUILD_RESEARCH S17 (the solve), priority-2026-08 S2/S3.1/S6 (next task
is now the MY CLUB counter), PROJECT_REPORT 6a, HANDOFF 5a plus the stale "FutMoveCard
has no skip handler" claim in S3 and a new 5d for Seasons/Draft.
380 + 51 checks green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
The deliverable owed from the assessment brief. Ordered by cost of the measurement
that would settle each item, not by how important the outcome feels.
Headline reordering: the observation session ran and did NOT produce the match
shape. Seasons refuses with zero requests to any layer and Draft hangs, so both
routes into a match are blocked and /match is now behind a fix rather than in front
of one. The next task is instead one launch with FUT_MOVE_BODY=ack, which is the
only open problem where the decompiler has produced a verified necessary condition
that has never been satisfied.
Also recorded:
- The User-Agent split. Real client (ProtoHttp) vs our own probes. /clubUser and
/user/list have 93 and 180 recorded hits and not one came from the game. Every
"the client asks for X" claim predating the split is unsupported until rechecked.
- The narrowed-core measurement. The proposed boundary ("ownership and economy keyed
by opaque integer item ids") is correct and every per-item prediction held, but
narrowing is not what guts core: FIFA 17 relevance is. Six services totalling 869
lines model features with no FIFA 17 endpoint at all, survive narrowing perfectly,
and are worth nothing here. Suite: 61 of 101, not the 81 previously claimed.
Recommendation is to reuse the scaffolding and the 61 tests, not the service layer.
- Port timing stays "after", led by the match-result-shape argument: three of the
four queued items will change a response schema, and porting a placeholder schema
means porting the correction too.
- test_fut_contract.py is now implementation-independent (380 checks over HTTP), so
it can certify a Rust port. That is the port's main de-risking asset and it exists.
- A "What could make this plan wrong" section, including that a negative ack result
is not a refutation, and that every negative claim in ENDPOINT_MAP.md is weaker
than the corresponding positive one after the FutMoveCard retraction.
Standing requirements recorded, including the User-Agent filter default (required,
not yet implemented) and two wrong .rdata addresses still to correct.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
RETRACTION. This repo claimed, in REBUILD_RESEARCH S14c and in utas_server's
item_route comment, that FutMoveCard 0x180128600 "HAS NO SKIP HANDLER
(FUN_180135ff0 appears zero times, unique among FUT deserializers)" and "parses
only itemData -> dreamSquads". Every part of that is false. Full decompile:
FUN_180135ff0 call sites : 2 (offsets 5006, 6080)
atoms parsed : 7 active dreamSquads id itemData pile reason success
Cause: the decompile was written out as src[:4000] and then searched. The function
is 6193 chars, so BOTH skip-handler call sites and four of the seven atoms lay past
the cut. An absence was reported from a truncated listing -- the same failure mode
as the Memory.getBytes bytearray scan that silently returned zero hits. Never
conclude an absence without asserting the searched region covers the function.
Cost: the false claim implied "any extra key desyncs this parser", which sent the
investigation after client-side state for seven attempts, and the derived premise
"the deciding factor is client-side state, not the wire" was wrong too.
VERIFIED SHAPE. PUT ut/%s/item is not an ack endpoint; it returns per-item VERDICT
records:
id(0x15c) INT 0x1801c79d0 -> record+0x00
pile(0x226) STRING 0x1801c7aa0 -> enum 0x180142650 (club=7 purchased=6 trade=5)
success(0x2fa) BOOL 0x1801c7620 -> record+0x0c
reason(0x279) STRING -> "Destination Full" = 0xf
dreamSquads(0xe9) INT array; else -> FUN_180135ff0 (skip)
The completion handler raises EVENT_CARDS_MOVE_CARD_FAILURE when the record vector
is EMPTY or record+0x0c != 1, and success is initialised to '\0' per element. So
every body ever returned reported the move as FAILED, {} included. Quick sell
survives an identical {} because its callbacks read only the transport code and
ignore the body -- that is the whole asymmetry, and it was on the wire after all.
STAGED, NOT DEFAULTED. FUT_MOVE_BODY=ack emits the correct shape; the default stays
`empty` because sufficiency is untested. One launch settles it.
The ack is answered BEFORE the `if moved:` gate: under FUT_PACK_AUTOCLUB=1 the
cards are already in the club when the reveal asks to move them, so move_items()
returns nothing and a moved-derived body would be zero-record -- failing in exactly
the configuration ack exists to fix. Caught in review before it ran. success is
asserted only for ids that were moved now or are already in the club; anything else
gets an honest success:false rather than an invented verdict.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
test_fut_contract.py no longer imports ACCOUNT from fut_account. The expected
persona comes from FUT_TEST_PERSONA_ID and the target from FUT_TEST_BASE, so the
suite now imports nothing but stdlib and talks to a server at a URL.
That is what lets these 380 checks certify ANY implementation of the reversed
spec, a future Rust openfut-core included, without replaying the reverse
engineering. The original reason for reading ACCOUNT still holds and is preserved
in the comment: suite and server must not each hold a private copy of the
constant, or the identity-consistency checks would only prove two copies matched.
Also adds pileSizeClientData(0x227) behind FUT_PILESIZES (default off). A probe
run with 16 uniquely-valued entries did NOT move the MY CLUB counter, so that
member is eliminated as its source; the code is kept for the record and flagged
off.
Docs: OPENFUT_PROJECT_REPORT.md and OPENFUT_HANDOFF.md. The report now separates
"built but untested" from "never requested by the client" -- the server log records
User-Agent, and splitting real client traffic (ProtoHttp) from this project's own
probes shows /season, /tournament, /champion, /match, /clubUser and /user/list are
at ZERO client requests. /clubUser (0 client, 93 probe) and /user/list (0 client,
180 probe) are the starkest: work was done on both assuming the client wanted them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
Second session. FUT core loop, the EASFC/POW online layer, a central account
backend, and a lot of corrections. Everything risky is behind an env flag with
the default set to whatever was live-proven.
WORKING END TO END (live-verified this session):
* match loop -- POST/PUT/POST/DELETE ut/%s/match, rewards via FutDestroyMatch
(0x180121b60). Play a match, get coins, W/D/L updates.
* packs -- buy, cards land in the club, session survives (FUT_PACK_AUTOCLUB=1)
* quick sell -- POST ut/delete/%s/item was UNMAPPED and paid NOTHING; six cards
were destroyed for 0 coins. Now credits discardValue.
* POW/EASFC online -- the "EA FC servers unreachable" banner is powdll's layer,
a THIRD http api on :8094 nobody had served. Redirect needs no root: powdll
FUN_18005a460 reads FIFA_POW_URL from the same client-config store as
ROSTERUPDATE_URL. FUT_POW=1.
* account backend -- fut_account.py replaces 7 hardcoded copies of the persona
across 5 files; club/persona/online-profile editable via CLI.
CORRECTIONS TO ENDPOINT_MAP (all re-extracted from the deserializers):
* FutStoreGetPackTypes: id/packType/isPremium/quantity/saleType/purchaseLimit/
purchaseCount are NOT skipped no-ops -- all are parsed. extPrice inner objects
take externalPriceId(0x11a), not amount/currency.
* FutMoveCard 0x180128600 has NO skip handler (FUN_180135ff0 appears zero times,
unique among FUT deserializers) and parses only itemData -> dreamSquads.
* class -> deserializer resolution: the name literal is preceded by a 4-BYTE
HEADER and the factory LEA points at the header, so look up name_addr - 4.
Six attempts failed on this; now ghidra_env.class_deser(). Unlocked 11 SBC/
Draft schemas.
* live-only endpoints the request table never lists: ut/%s/squad/list,
ut/%s/user/club, ut/%s/club/stats/*, ut/%s/clientdata/<key>. The template
table is a floor, not a ceiling -- the log is the only ground truth.
* 163 RS4 call names exist; we served 17. All now served.
FIXED: club/stats/* was answering with the entire 28-item club inventory on every
poll (it fell through to the generic /club route).
UNSOLVED: the pack reveal's "Send to Club" (PUT ut/%s/item) kills the FUT session
whatever we answer -- {} included -- while its sibling quick-sell endpoint accepts
a bare {}. Seven hypotheses eliminated by live test, documented in
REBUILD_RESEARCH.md S14c so none get re-walked. FUT_PACK_AUTOCLUB routes around it.
Also unfixed: store tiles render "unknown" (displayGroup is parsed RECURSIVELY by
the same element parser; sending it FROZE the store, so FUT_STORE_GROUPS=1 is
default off).
Tests: test_fut_contract.py 380 (live, read-only) + test_match_rewards.py 51 (pure).
Note: fut_store.py carries some pre-existing uncommitted changes from before this
session (pack catalogue ids, pending-pile behaviour) that could not be separated
from this session's additions in the same file.
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
The FUT store 'not available' is FIFA's online-mode readiness gate
(FUT::CompetitionManager), not a config flag. tools/store_enable_poke.py finds
CardsDLL's live base and patches the 3 gate methods (0x1800f7fb0
IS_EASTORE_SERVICE_READY, 0x1800fb850 IS_STORE_ENABLED, 0x180100500
IS_COIN_PURCHASABLE) to 'mov eax,1; ret'. Reversible (saves originals; 'restore'
subcommand; FIFA restart clears it). Needs ptrace_scope=0 + FIFA running.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Live log ground-truth: FIFA's transfer-market SEARCH hits
GET /ut/game/fifa17/transfermarket?type=player&start=0&num=12 (was UNMAPPED ->
catch-all {} => empty market), NOT /auctionhouse as the struct name suggested.
Route it to the same listings handler. Market now serves 18 listings on the
endpoint FIFA actually calls.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Add enableSquadBuildingSetsFeature + FUT/SBC_USE_STUBS to the Blaze FUT config,
gated on env FUT_SBC (default OFF -> baseline unchanged, no restart needed). The
SBC set-list deser (0x180154990) checks FUT/SBC_USE_STUBS -- FIFA may render
built-in stub SBCs with zero server content. A concrete, safe lever to try SBCs
in the next live session without shipping complex (freeze-risky) SBC JSON blind.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Complete the market loop (browse + buy + sell). POST auctionhouse (FutISStart)
lists an owned club item -> profile.listings + returns {id:tradeId}. tradePile
builds a validated auction record per listing from the owned item + prices
(freeze-safe, same 0x18013e410 shape). DELETE trade/{id} removes the listing.
fut_store gains list_for_sale/listings/remove_listing (tradeId space 900500000+).
test_market_buy.py extended with sell/delist checks (temp profile, no real-save
mutation): list -> tradePile shows it with prices -> delist empties it. All pass.
Read-only contract suite still 311/311. Functional (FIFA's exact sell params)
pending live test; freeze-safe by construction.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
trade_route now resolves the auction from its tradeId and, on buy-now
(bid >= buyNowPrice), spends coins + grants the won card to the club + echoes
the CLOSED auction (FutISOfferTrade shape). Reuses the validated auction record
(0x18013e410) so it stays freeze-safe; whether FIFA surfaces the won item
post-buy is functional (needs live test). Insufficient funds -> 461.
tools/test_market_buy.py: offline unit test on a TEMP profile (never touches the
real save) -- verifies coin deduction, card grant, closed-auction shape, and the
461 path. PASS. Read-only contract suite still 311/311.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Serve 18 real-player auctions on GET auctionhouse (search) built to the reversed
auction record schema (deser 0x18013e410) field-for-field: itemData reuses
fut_store._item (the proven club/squad card parser 0x18013fe00), scalar fields
all HIGH-confidence reversed. Rating-based buy-now pricing; tradeId space
900000000+. tradePile/watchList stay empty (no live sell/watch flow yet). Toggle
off with FUT_MARKET=empty.
Extend test_fut_contract.py to validate EVERY populated record field type
(numbers/strings/bool/object) so the listings are proven freeze-safe OFFLINE
before the game parses them. 311 checks, all passing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Add tools/test_fut_contract.py -- stdlib-only, read-only tests that hit the live
utas_server and assert each response matches the shape reversed from CardsDLL
(docs/ENDPOINT_MAP.md). Encodes freeze-safety invariants (auctionInfo/players/
itemData/currencies/purchase must be array/object per the SAX deserializers;
scalar-where-container = busy-loop freeze at 0x1801c7f1a) plus the specific
contracts: v2/store gate == SUCCESS, coin counter binds currencies[coins].funds,
userMassInfo stays {}, empty squad slots carry itemData=null (proven-safe).
Catches the regression class that previously bit us (phantom packs, coins-0,
squad reset). 58 checks, all passing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Add auctionhouse/trade/tradePile/watchList/marketdata routes per ENDPOINT_MAP
market §. All share the reversed IS-list body {auctionInfo:[], credits, total,
duplicateItemIdList} (shared deser 0x18013e7f0). Served EMPTY (no live listings
yet) -- empty arrays never desync the SAX reader, so freeze-safe; unlocks the
market screens vs the prior catch-all {}. GET auctionhouse merges the
FutGetAuctionCount ints (extra keys skip). POST auctionhouse = FutISStart new
tradeId; PUT relist / watch add-remove / delete = acks. tradePile precedes
/trade (prefix collision). Populating real auctions deferred to in-game test.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
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
Reverse-engineered the exact FIFA17 store/purchase/credits response
shapes (wf a245577b + wf_76fcf89b) and applied them:
- Store catalog: root key MUST be "purchase" (atom 608) not
"purchaseGroups"; packs keyed by "id" (int16) not packId; price is a
"currencies":[{name,funds,finalFunds}] array; name is "description".
Our old {purchaseGroups:...} hashed to unknown atoms -> empty -> "store
not available". Now the store displays.
- Pack buy: gate open_pack on a transaction with "packId" and state !=
TRANSACTIONCANCEL (the TRANSACTIONCREATED create step) -- fixes the
phantom-buy. Reveal response = {"createPackResponse":{itemList,
numberItems,purchasedPackId,duplicateItemIdList}}
(FutCreatePackServerResponse).
- Coins: /user/credits must return currencies[name=="coins"].funds, not
{"credits":N} (the hub/store read currencies). squad_route also
reconstructs the active squad from club item-id references.
Verified via curl: store shows 3 packs; cancel spends nothing; Bronze
buy awards 5 real players and deducts 400 coins. NOTE: the FUT HUB coin
counter reads from userMassInfo (not /user/credits) -- still blocked on
the userMassInfo-freeze wall (separate reverse in progress).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
FIFA's updateActiveSquad PUT stores each slot as itemData={id:<clubItemId>}
(a reference), not the full player. We saved the bare references, so the
squad reloaded empty ("active squad resets"). Add Store.reconstruct_squad()
to re-embed the full club item by id on GET /squad/0, so the saved squad
reloads with its real players.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
store/transaction receives {"state":"TRANSACTIONCANCEL"} (cancel/close)
and {"packId":N} (pack-details fetch on store load) -- neither is a
confirmed purchase. The handler treated packId as a buy and even
defaulted to opening a Gold Pack on cancels, silently spending coins.
Make store_buy a safe no-op that logs every body, so the real
purchase-CONFIRM signal can be identified from a deliberate in-game buy
and open_pack() gated on exactly that. Save restored on next fresh run.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Add a first-cut FUT store on top of the persistent profile:
- fut_store: PACK_CATALOG (Bronze/Gold/Premium), a curated real-player
PACK_POOL, and open_pack() (deduct coins -> generate items -> add to
club -> persist).
- utas_server routes: GET store/purchasegroup/all (catalog), PUT
(v2) store/transaction (buy + open, returns awarded itemData +
updated coins), GET purchased (last pack). Matches both /ut/game and
/ut/v2/game prefixes.
Verified via curl: buy Gold Pack -> 7 real players awarded, coins
15000->10000, club 10->17, persisted. Wire format is a best-guess
grounded in the CardsDLL store keys (packId/price/itemData/coins);
iterate against the in-game store next. Pool is curated for now --
replace with a full dbdata.dll extract later.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Add fut_store.py: a JSON-backed profile store (coins, owned club items,
saved squads, record). First run grants a starter pack -- 15000 coins +
a 10-player starter club (real assetIds; identity resolves locally
in-game per docs/CARD_SYSTEM.md).
Wire utas_server to the store: /user/credits -> persisted coins,
/club -> persisted owned items, PUT /squad -> persists the squad the
user builds so it survives relaunches. Profile save file is gitignored.
Foundation for pack-opening (store/purchasegroup + transaction) next.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
A full 88-rated real FUT squad (Ronaldo/Messi/Suárez/Ramos/Kroos/Alba/
Hazard/Oblak/Alaba/Boateng) renders 100% offline, no EA servers.
Mechanism: the definition fetch was unnecessary — FIFA has all player
identity locally in dbdata.dll. The CLUB-SEARCH / Add-Player flow
(GET /club?type=player&count=N, served by our /club route) makes FIFA
resolve each item's assetId against its own local DB (real name/photo/
club/nation) and merge the rating/attributes our /club item carries,
caching a real record in the CardsDb store. No idList fetch, no leaked
data.
Recipe: utas FUT_SQUAD_STEP=s3v0 -> /club serves the full XI; in FUT,
Squads -> Add Player/search -> results render real -> add to slots.
docs/CARD_SYSTEM.md updated with the SOLVED mechanism + recipe.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Milestone: FIFA 17 Ultimate Team boots end-to-end on our offline backend
past every EA gate into the hub and a live Squads editor (correct 4-4-2,
5-star squad, no freezes).
Key findings this session:
- userMassInfo MUST stay {} (any content desyncs the massinfo parser
0x180174630 -> tokenizer busy-loop freeze). Deliver the squad via
GET /squad/0 (fetched on Squads-tab entry) instead.
- Player cards render generic because the card view-model (0x1800d7920)
reads identity/rating/face from a resolved record at item+0x10, filled
by a lookup (0x18011cca0) in the FUT item-definition std::map at
CardsDb+0x160c0 -- which is EMPTY offline -> default blank record.
- Version advertising (itemDbVersion/checkServerDbVersion) is proven inert
(JSON fields routed to the skip handler). Owned items don't auto-trigger
a definition fetch. In-place map overwrite is dead (map stays empty).
- Definition-serving endpoints (item/resource, defid, item?idList) built +
ready; the fetch trigger lives in the packed FIFA17.exe.
New: docs/CARD_SYSTEM.md (findings + ordered next-steps plan for real
player cards: patch-POC, dbdata extractor, drive FIFA17.exe fetch, or
live-memory store injection). Plus tools: fut_seed.py (squad ladder +
definition serving), fifadrive.sh, vgamepad.py, and the login-RE toolset.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Emulates FIFA 17's full online + Ultimate Team stack against an offline,
clean-room backend (no EA servers). Proven end-to-end 2026-08-01:
Origin login -> Blaze login -> device-trust -> the FUT hub.
Package:
- tools/openfut-fut.sh one-command orchestrator (start/stop/status/restart)
- tools/root_arm.sh idempotent host arm (sysctls, DNAT, /etc/hosts easw)
- tools/{lsx_responder_v2,blaze_responder_v3b,roster_server,utas_server,autopatch}.py
the 5 servers (Origin LSX :4216, Blaze :42127/42130/42131, roster :8081,
FUT/UTAS :8099) + heat2.py (Fire2/Heat2 TDF codec)
- FUT-RUNBOOK.md runbook + gate-ladder troubleshooting
- docs/, tools/login_dump/*.md the reverse-engineering write-ups
All findings are clean-room, from binaries we own; nothing from any leak.
The wire protocol maps 1:1 to FIFA 23.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
Adds the app-centric FLE bridge direction (direction.md) replacing the
Blaze-backend route as primary plan, plus a corrected foundational test
procedure and snapshot/diff/apply tooling for reverse-engineering FLE's
Freeze Lineup write mechanism. Also picks up prior untracked research docs
(status-review, fut-integration-options, fifa23-startup-flow, track-c) and
existing capture/export tooling that hadn't been committed yet.
- Remove the openfut-launcher submodule: its recorded commit was never
pushed and its remote held a mispushed copy of the superproject. The
hook work now lives in openfut-bridge/openfut-hook instead.
- Update openfut-bridge pointer to include the ProtoSSL RE tooling
(tools/protossl-scan), the FIFA 23 version.dll hook (openfut-hook),
and the bridge CLAUDE.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
funman300