d929efdffe8c104f413dd6aabb0d7295ca76fe5b
12 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 funman300
|
3bb6b4fc9d |
fix(fifa17): subtypes 57/67 are the rare all-six training card
They were failing closed as "squad fitness". Four facts say otherwise: each family holds exactly 21 rows = 7 types x 3 levels matching the published "6 single attributes + 1 ALL" list; those six rows are the ONLY ones with weightrare=2 while all 36 single-attribute rows are 0, and the published list marks ALL rare; their amounts are exactly 3/6/10 against the documented ALL card's +3/+6/+10; and bc=6 is one past the six real slots, an "all" sentinel, with c0=0 reading as "not single-ATTRIBUTE" rather than "not single-target". The misreading came from consumables.json's FUT_FITNESS_UC/MC label, which is tool-authored -- build_consumables.py names the 7th element of its attribute array -- and has no documented provenance. The bc/c0 values beside it ARE reversed; only the name was not. The genuine squad-fitness card is subtype 220 in fcc_healingcards (10/20/30) and player fitness is 219; that family stays unsupported. The two families carry different authored ceilings, 15 single-attribute and 10 all-six, so ceiling_for() reports the right one per effect -- sending the single-attribute ceiling for an all-six card would let a +15 all-six boost through, granting 90 attribute points from a card worth 60. Also corrects ENDPOINT_MAP row 7: ApplyCardByRes carries urlIndex 0x0e, which resolves to ut/%s/item/resource, and the live verb is POST. The row claimed PUT ut/%s/item for both apply RPCs, and that conflation is what kept the "apply must ride PUT ut/%s/item" hypothesis alive until the POST capture settled it -- every observed PUT ut/%s/item is a pile move. |
||
|
funman300
|
274838cc2e |
test(host): pin the ?type= vocabulary to the client's own 30 arms
Decoded the vocabulary from the binary rather than trusting a case count: FUN_18012ec50 is `cmp ecx,0x1d` plus a 30-entry jump table at 0x18012ed9c, each case `mov ecx,<atom>; jmp <atom->string>`. Resolving those atoms against fut_atoms.tsv yields the exact token list, and it matches club_type_filter one-for-one — 30 implemented, none missing, none invented. That is worth a test rather than a note. A MISSING arm answers a real tab with unsupported_type and an empty screen; an INVENTED arm is worse, because it is dead code that looks like coverage. Mutation-checked: renaming the leaguelogos arm fails the test. Two facts fall out that were previously guesswork. There is no `playergoalkeeper` token — the client has only DEF/MID/FWD tabs — so a goalkeeper appearing under playerdefender is CORRECT and not a filter bug, which I had flagged as suspicious while sweeping. And `healing`/`contract`/`training` exist as ?type= arms even though consumables have their own route. Also completes the last unapplied item of plan section 7: the full vocabulary is now written into ENDPOINT_MAP.md with how it was derived. |
||
|
funman300
|
52df78d24a |
docs(fifa17): correct ENDPOINT_MAP club routes, and close plan section 7
Rows 12, 13 and 16 carried guessed or placeholder URLs (`ut/%s/item?type=…`, `ut/%s/…`). The real binding is a table, not an inference: the 125-row action table at 0x1802caa20 indexes the 48-entry URL-base table at 0x18021df80 through column 1, and base index 3 = ut/%s/club is carried by exactly four rows. So the client can emit exactly four families on that base: ClubSearch, ClubStats, StaffStats, ConsumablesSearch — which also corrects those three rows to /club?<query>, /club/stats/staff and /club/consumables/<cat>, and updates their status now that the Rust host serves them. Added the complete club query grammar (ordered, with its suppression rules and sub-vocabularies, including that the request spells it onSale where the response says forSale), the seven /club/stats forms, the fact that /club/stats/team does NOT exist, and the two base-table holes that are composed outside CardsDLL so nobody re-derives them as findings. Section 7 of the plan is now marked APPLIED and kept as the audit trail. |
||
|
funman300
|
89dc1b1d85 |
sbc: document reversed elgReq ordinal finding; elgReq stays empty
Reversed from the pinned CardsDLL (4706a881): eligibilityKey and eligibilityOperation are localization ordinals (LOC_SBC_ELG_KEY_%d), not the atom hex ids. The client's only consumer is the requirement- display string builder at ~0x1800ef900 (formats via indexed locale keys, no comparison/gate). The ordinal->string map lives only in the packed locale (absent from all assets we hold), so any emitted value would render the WRONG requirement text. Submission stays fully validated server-side by Core; the empty elgReq is display-only. Correct ENDPOINT_MAP.md's implied atom-id==ordinal assumption and pin the exact remaining blocker at the emit site. |
||
|
funman300
|
31fc590b99 |
fifa17-recon: the FUT-hub Transfer List tile counts, and the hub parser is NOT reflection
The Transfer List hub tile read "0 items / Selling 0" while a card was actively
listed. Enumerating the /hub parser FUN_180139610 straight from the on-disk
CardsDLL (objdump) refutes the old ENDPOINT_MAP claim that it uses C++ reflection
with "no atom ladder, nothing to enumerate": it has an ordinary running-sum atom
ladder reading 18 atoms. The tile is fed by hub.tradePile (0x333), a nested object
(sub-deser 0x18013ead0) reading count/selling/sold as scalar ints -- the same
scheme as GetAuctionCount, so serving it in the hub body is freeze-safe. The tile
never re-polls the standalone /tradePile/counts, which is why fixing that endpoint
alone did not move the tile.
Also: the hub tile polls LOWERCASE tradepile/counts while the Transfer List screen
uses camelCase tradePile; our case-sensitive routes matched only the screen, so the
tile's counts call fell through to /trade and got a shape the counts deser skips.
Made the tradePile routes case-insensitive.
And bake the proven transfer-market flags (FUT_TRADING/PILESIZES/TRADEABLE/
DISCARD_TABLE/DISCARD_SEND) into openfut-fut.sh so a plain `start` brings up the
working state instead of regressing trading to greyed-out.
- tools/utas_server.py: hub_data() serves tradePile:{count,selling,sold};
tradePile routes now re.I
- tools/openfut-fut.sh: utas launched with the working flag set
- docs/ENDPOINT_MAP.md: full 18-atom hub map + tile map, correction of the
reflection claim
- tools/ghidra_queries/objdump_atom_ladder.py: the objdump-based atom-ladder
decoder used to derive the above
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Lrx9to3pihN6Sm9sXgc8np
|
||
|
funman300
|
3f3d5704a7 |
fifa17-recon: quick sell has never been reachable, and finalFunds is the rendered price
Live run, 2026-08-05 evening. Three results, one of them a route that has been dead for
the whole life of the project.
QUICK SELL WAS NEVER SERVED. Captured on the wire:
DELETE /ut/game/fifa17/item/100000240 (single card, id in the URL, no body)
ENDPOINT_MAP documented the path as `ut/delete/game/%s/item`, ROUTES was built from the
doc, and the regex therefore never matched a real quick sell. Every quick sell fell
through to the catch-all, so quick_sell_route() and STORE.quick_sell() behind it had
never once been called.
The empty response was not a harmless no-op. This body is BALANCE-BEARING: the client
takes its coin total from it, so with totalCredits absent it rendered an uninitialised
value. A real session showed 1,133,686,384 coins against a true balance of 9,889,600.
Display artifact only, corrected by the next GET /user/credits, and the save was never
touched, but it is the reason a stub is not acceptable here.
quick_sell_url_route() serves the real form and returns the corrected shape,
{"items":[{"id":N}],"totalCredits":N}. DEFAULT ON, which the house rule now permits:
two quick sells fired through it in one session, each credited 150 and removed the
card, and the coin arithmetic reconciled exactly against the 15,000 pack purchases
either side of them. An unknown id returns {"items": []} rather than claiming a sale we
cannot account for.
Still UNKNOWN and deliberately not chased: whether the client ASSIGNS totalCredits as
the new balance or ADDS it as a delta. We send the new balance. The discriminating
window is about five seconds wide, because the client refetches GET /user/credits
straight afterwards, so either reading self-corrects and the practical impact is a brief
wrong number. It mattered only while we answered {}, because that garbage persisted.
The credit amount is STORE.quick_sell()'s invented rating tier, not FUT's real discard
table, which remains unknown.
finalFunds IS THE RENDERED COIN PRICE. Served funds=15000 / finalFunds=4321 on one pack
and the tile read 4,321. funds is not displayed. ENDPOINT_MAP updated to CONFIRMED LIVE
with the method recorded. FUT_PRICE_PROBE, the flag that produced it, stays default off
and is disarmed: it puts a price on a tile that the buy path does not charge.
TWO UNPLANNED FINDINGS, both recorded for the next round rather than fixed here:
* The store grouping is broken and it is NOT cosmetic. All three packs collapse into
one display group, and the Bronze, Gold and Premium group tiles all drill into the
same single Premium Gold pack, so TWO OF THREE PACKS CANNOT BE BOUGHT. We send
displayGroup {"value": name} but never displayGroupAssetId (0xda), so everything
lands in group 0. The docs had this parked as a cosmetic "tiles read unknown"
issue; it is an availability bug.
* The FIFA Points price renders as the literal "or %1s", an unsubstituted printf
placeholder. extPrice.finalPrice is served as {"amount":N,"currency":"mtx"} and
"mtx" is evidently not a currency token the client resolves. Cosmetic.
Corrected in passing: packContentInfo DOES reach the tile (11 ITEMS / 11 GOLD /
11 RARES against exactly what we serve). An earlier screen showing zeros was the
display-GROUP level, which carries no content info. D3 was right.
Live: 439 contract checks pass, both probe flags off, store prices back to honest.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
funman300
|
89da7b7609 |
fifa17-recon: /hub refutes yesterday's envelope conclusion, and two ENDPOINT_MAP freezes
Three things: the envelope rule was wrong and is corrected, /hub is settled, and two
documented response shapes that would freeze the client are fixed.
THE CORRECTION. The previous commit concluded that a three-token root consumes `{`, the
first field name and that field's value without dispatching them, so the first key of a
flat body was silently eaten, and that `login` had therefore never been delivered on
POST /user. That is WRONG and is withdrawn, along with the claim that the key order of
the auth dict is load-bearing.
The first call to FUN_1801c7f10 returns token 7 and consumes NO input. It is a
once-only start-of-document token, guarded by the flag at parser+0xda together with the
zero character counter at parser+0x30. So the three tokens are BOF, `{`, and the FIRST
FIELD NAME, and the key loop dispatches from that first key onward. The `== 10` test on
the third token is not an envelope check, it is the empty-object early-out: for `{}` the
third token is END_OBJECT and the root exits with its constructor defaults intact, which
is why answering `{}` has always been safe.
Corrected enum: 7=BOF 9=START_OBJECT 10=END_OBJECT 11=FIELD_NAME 12=START_ARRAY
13=END_ARRAY. The enum itself was right before; the inference from it was not.
HOW IT WAS CAUGHT, which is the part worth keeping. Not by more decompiling. /hub is
served flat and the wrong model predicted its first key would be discarded, so the
prediction was checked against the client's own memory: clubPlayers read back as 205,
the value the server sent, at model+0x1fd70+0x3c with the slide proven against the FNV
prologue first. One live read refuted a chain of otherwise sound static reasoning in
about a minute. tools/hub_counter_probe.py keeps it repeatable.
Consequence worth flagging: a wrapper is not just unnecessary for these roots, it would
be harmful, since a wrapper key hashes to an atom with no arm and the whole object is
skipped. That makes the createPackResponse envelope DOUBTFUL rather than confirmed.
Atom 0xbe has no arm in FUN_180162880. There is no live evidence either way because
nothing has ever parsed that body, so the buy path is left exactly as it is.
TWO ERRORS OF MINE ON THE WAY, both recorded in the doc because both are cheap to
repeat. I searched for RS4:FutGetHubServerResponse, found nothing and reported that no
hub class existed; the class is FutGetHubDataServerResponse (literal 0x18022ce40,
vtable 0x18022cd48, deser 0x1801738b0, control FutSquadSave -> 0x180171a60 matched in
the same run). Then I scanned 152 deserializers for clubPlayers, got zero hits and a
passing control, because the guard is `!= 0x90` and my pattern only matched `== 0x`.
The control passed only because auctionCount happens to use `==`. A control that does
not exercise the same code shape as the target is not a control. The comment already at
utas_server.py:1076 had the hub chain right the whole time.
ENDPOINT_MAP corrections, both freeze-risky as written, neither affecting what we serve
today:
* duplicateItemIdList is an ARRAY OF OBJECTS (element deser 0x180138e10), not the int
list at :1095. Bare ints where the element parser expects objects is a tokenizer
desync, i.e. a hard freeze at 0x1801c7f1a. Control that this is not a misread:
dreamSquads 0xe9 in FutMoveCard genuinely is a bare int array.
* FutDiscardCardServerResponse is {"items":[{"id":N}],"totalCredits":N}. There is no
top-level id.
No behaviour change. utas_server.py is comment-only. 439 contract checks pass.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
funman300
|
897259c8fb |
fifa17-recon: the /settings 42-flag gate, and why Seasons never asks
ENDPOINT_MAP said this class reads one key, `configs`, and that was true and useless. What it missed is what happens after each element closes: the client feeds the STRING VALUE of `type` back through the atom hasher and switches on the result, 42 arms wide. A flag is a row, not a key, and the client hashes our string itself. Followed it to the end. FUN_18011dc50 is the only writer of the IS_* UI gate bytes inside FutDataManagerImpl, every line is `byte = (field == 1)`, and the constructor never touches those bytes. So a flag nobody sends is a gate nobody opens. friendlySeasonsEnabled and enableDraftMode have never been sent by anything, which is a mechanism for Seasons refusing while making zero requests to any of the four servers. The store is the control that makes this readable: IS_STORE_ENABLED is the same kind of byte and its screen works, because storeEnabled and friends already ship through the Blaze config store. That list has no seasons or draft flag. Ship the gates behind FUT_SETTINGS (off/keep/gates, default gates), and re-assert the working store flags in the same array on purpose: once a populated array makes the applier run, it writes EVERY gate byte, so omitting them could switch off a screen that works today. maximumTradePileSize=100 rides along as a positive control, because a boolean that changes nothing cannot distinguish "the flag did not help" from "the array never reached the consumer". check_settings_flags.py asserts each shipped name against the atom table AND the recovered switch, since a misnamed flag is silently inert and looks exactly like a failed fix. enableSquadBuildingSetsFeature is the reason both checks are needed: a real atom with no arm here. Live: 439 contract checks pass, market unit suite passes. Not yet tested in game. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
funman300
|
1e9cfb6da9 |
fifa17-recon: ENDPOINT_MAP -- remove two documented hang recipes, fix five entries
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 |
||
|
funman300
|
59934b4ef0 |
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
|
||
|
funman300
|
b05ccd7ce5 |
fifa17-recon: record market-implemented status + SBC config-flag leads
enableSquadBuildingSetsFeature / FUT/SBC_USE_STUBS (client-side stub SBCs) / SBC_ELG_KEY_ found in CardsDLL -- the next lead for SBCs, to validate live. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o |
||
|
funman300
|
4e89cce37d |
fifa17-recon: store fix (v2/store gate + flags) + full FUT endpoint map
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
|