funman300/OpenFUT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: funman300/OpenFUT:750d6c2e180951d0174705a89d7513dee57b1bc8
Branches Tags
funman300/OpenFUT:main funman300/OpenFUT:fifa17-fut-squad-and-userinfo funman300/OpenFUT:retained/20260819-staging/e8d1c1d-seasons-draft-wip funman300/OpenFUT:rust-migration/protocol-blaze-foundation
funman300/OpenFUT:python-fifa17-baseline-2026-08-10
...
compare: funman300/OpenFUT:main
Branches Tags
funman300/OpenFUT:main funman300/OpenFUT:fifa17-fut-squad-and-userinfo funman300/OpenFUT:retained/20260819-staging/e8d1c1d-seasons-draft-wip funman300/OpenFUT:rust-migration/protocol-blaze-foundation
funman300/OpenFUT:python-fifa17-baseline-2026-08-10

177 Commits
750d6c2e18 ... main

Author SHA1 Message Date
funman300 e14d3cd063 Trace FIFA17 command 0x128 lifecycle 2026-08-28 01:12:37 +00:00
funman300 f4fc832ace Trace FIFA17 PMA producer lifecycle 2026-08-27 23:27:52 +00:00
funman300 6aab279244 Wire FIFA17 PMA repair candidate 2026-08-27 22:40:04 +00:00
funman300 d3451be17b Trace FIFA17 PMA completion divergence 2026-08-27 21:43:48 +00:00
funman300 0300af3333 Add FIFA17 Kick Off control trace profile 2026-08-26 17:34:43 +00:00
funman300 2c572e918f tools: trace FIFA17 scenario start source chain 2026-08-26 04:46:42 +00:00
funman300 f608dbc438 Add post-kit gameplay transition tracers 2026-08-26 01:40:41 +00:00
funman300 43c460741b trace FIFA17 provider lifecycle 2026-08-25 23:18:08 +00:00
funman300 5eed124b85 Add FIFA17 match transition tracers 2026-08-25 21:37:59 +00:00
funman300 e3ed8c298e fix(fifa17): advance season team compatibility 2026-08-25 20:14:57 +00:00
funman300 5181e103dc Add FIFA17 game-setup context tracers 2026-08-25 18:29:55 +00:00
funman300 433a9b22dd tool(fifa17-recon): trace Offline Seasons team assignment hardware-only 
Add a fail-closed, fresh-process native trace workflow for the Offline Seasons
fixture-to-match-team boundary. The supervisor ignores UMU's short-lived
FIFA17.exe process, requires CardsDLL, verifies TracerPid and hardware arming,
rejects pre-existing records, structurally locates fixtures/final records, and
detaches cleanly after capture.

The four payloads reproduce the measured chain without client writes:

  FUN_1800fc500
    -> actual season vector, fixture index 0 / team 73
    -> temporary [73,130000] pair (not the final record)

  CardsDLL service -> engine 0x147c652ce
    -> live final +0x14 writes at the 0x45c side stride
    -> correct [73,130000], then local overwrite [130000,130000]

  engine wrapper 0x147ce47e0
    <- CardsDLL 0x180031861
    <- CardsGameSetupAdapter local `teams` query result already 130000

All execute breakpoints and watchpoints are hardware-only. /proc/PID/mem is
opened rb. No INT3, write_memory, patch, game input, server behavior, or Rust
code. Locator uses zero-based --fixture-index (the live selector is 0 when
season/user.round is 1) and never filters on transient +0x18 handles.
 2026-08-25 17:25:41 +00:00
funman300 0701ac94e1 tool(fifa17-recon): live native-RE toolkit (disasm, xref, immediate-store, vtable) 
Read-only probes for resolving FIFA17 code paths against a running client
without Ghidra, per the live-disassembly method (/proc/<pid>/mem + objdump).
All open /proc/<pid>/mem 'rb' only.

  ldis.py           image-VA disassembler/hexdump for CardsDLL and FIFA17.exe;
                    recomputes the module base from the NAMED PE-header mapping
                    every run, because Wine maps PE sections anonymously and the
                    mapping that merely CONTAINS an address is not the module.
  xref.py           references to an image VA: call/jmp rel32, rip-relative lea,
                    and absolute pointer slots. An absolute-only hit means the
                    function is virtual and reachable solely via its vtable.
  immstore.py       immediate stores (C7 /0) of a constant to a struct offset.
                    Only an immediate store can INTRODUCE a constant; a register
                    store merely propagates one. Zero hits is a real result: it
                    proves the constant arrives from a call, not a literal.
  classify_calls.py splits call sites of a constant-returning stub into STORE
                    (can assign) vs compare (predicate). Turned 81 call sites of
                    the 130000 provider into 17 assignments.
  vtab.py           dumps a vtable as image VAs and looks for sibling vtables
                    holding a different function in the same slot, which is how
                    a type/mode dispatch shows up.
  scan_mt.py        match-team records by the invariant header (11,7,0,0,76).
                    Never filters on +0x18: that word is a per-session handle
                    (-1 on 2026-08-24, 0x54001/0x54000 on 2026-08-25) and
                    filtering on it previously produced a false negative.

Workflow note: dump .text once and cache the objdump output, then query the
cached listing; a full CardsDLL .text linear disassembly is ~563k lines and
re-disassembling per question is wasteful.
 2026-08-25 04:23:22 +00:00
funman300 025122ec9a tool(fifa17-recon): manager_coldproof.py -- read-only manager registration probe 
Promotes the throwaway probe used to close the manager cold-load milestone into
fifa17-recon/tools. Read-only (/proc/<pid>/mem opened 'rb', never 'r+b'), pid
optional and overridable, controls overridable via --control WIRE:RESOURCE.

Fail-closed: absent player positive controls exit 3 (INCONCLUSIVE, squad not
loaded) rather than 0, so 'no manager found' can never be reported from a
session that never loaded a squad. Distinguishes real item records from
incidental integer matches by requiring resourceId 0x20 bytes before the wire
id, the layout the player controls exhibit.

Documents the manager wire control, the resourceId control (the actual
verdict), the player positive controls, and what counts as a resident hit.
 2026-08-25 02:58:16 +00:00
funman300 b91e707a7e fix(fifa17): squad.manager elements are bare item objects, not itemData wrappers 
An owned manager assigned in Core was present everywhere on the server -- in
/club/manager, in club?type=staff, and in userMassInfo -- but the squad UI
showed no manager after a cold client load.

The squad parser FUN_18013d1f0 reaches the item parser FUN_18013fe00 by two
different routes:

  players: atom 568 -> per-element atoms 355 `index`, 363 `itemData`,
           378 `kitNumber`; the 363 arm at 0x18013d8d9 calls the item parser
           on the NESTED itemData object.
  manager: atom 424 -> array loop at 0x18013da29 calls that same item parser
           DIRECTLY on the array ELEMENT, into squad+0xC0. No `itemData` step.

So a manager element IS an item. We were nesting the fields one level deeper,
so the parser read only the two keys that happen to be item atoms -- `id` and
`dream` -- and left everything else at its default. Measured on a cold client,
the manager record existed at squad+0xC0 with the correct id and resourceId 0,
while sibling players in the same response carried theirs. resourceId is the
merge key compared RAW against carddbid, so 0 resolves no manager: no name, no
rating, no art, empty slot.

The client's own save corroborates the shape: it PUTs
`"manager":[{"id":...,"dream":false}]` -- flat, and both keys are item atoms.

Flatten the element to the item plus `dream`. Cold-load proven on staging: the
manager record now carries resourceId 1000509 in the same layout as its player
siblings (83906881, 84053575) in the same array region, and the operator
confirms a manager is assigned in the squad management screen.

Two earlier shapes are now both explained and covered by tests: `{id, dream}`
carries no merge key, and `{id, itemData, dream}` hides it from this path.
 2026-08-25 02:50:22 +00:00
funman300 c3d0e56f69 chore(core): bump pointer for partial squad role update 
Core 20e281e adds `PUT /squad/roles`, the role-only patch the FIFA 17
captain/kick-taker screen needs. The host change (e7893a0) requires it.
 2026-08-25 01:52:59 +00:00
funman300 e7893a0162 fix(fifa17): route a partial squad PUT to a role patch, not a replacement 
FIFA 17 sends two different operations to `PUT …/squad/<id>` and distinguishes
them only by body shape. Across 73 captured squad PUTs in five captures there
are exactly two:

  * 68x with `players` -- a full replacement (also carrying squadName,
    formation, squadType, manager, chemistry/rating, and redundantly
    captain/kicktakers);
  * 5x without `players` -- `{id, custom, captain, kicktakers}`, emitted by the
    captain/kick-taker screen.

`players` has `#[serde(default)]`, so an absent key and an explicit `[]`
collapsed to the same empty vec and every partial update was handed to Core as
a replacement with zero slots. Core's empty-replacement guard refused it (400)
and the host reported 502, losing the user's captain/kick-taker change.

`classify_squad_put` now tests key PRESENCE on the raw JSON before
deserialising, so absence ("the squad was not part of this edit") stays
distinct from an explicit empty array ("replace with nothing"). An explicit
`"players": []` still classifies as a replacement and still meets the guard --
the patch path is not a way around it.

The patch path carries the contract correction: omitted `players`, `manager`
and actives mean UNCHANGED, never cleared. That is structural --
`CoreRolePatchRequest` has no field able to express them. The extension is
MERGED rather than overwritten, because the partial body carries only `custom`
and `kicktakers`; overwriting would drop every kit number in the squad.
`custom` IS taken from the patch, since the role screen writes per-slot values
into it and the two shapes genuinely differ there.

Also fixes the error mapping on this route: a Core 400 means the REQUEST was
invalid, so it is reported as 400, not as a 502 that blames the server and
hides a client error behind "upstream unavailable".

Tests use the real captured body and assert it takes the patch path
(`replace_squad` call count unchanged), that the manager survives, that kit
numbers survive the merge, that an explicit empty `players` still reaches the
replacement path, and that an unresolvable captain refuses the whole patch
rather than half-applying the kick-takers.
 2026-08-25 01:52:51 +00:00
funman300 a2b0c32a70 docs(fifa17): numeric squad ids are real; our collapsing is safe, not authentic 
The numeric id in squad/<n> was being justified as "matching the oracle". That
justification does not survive inspection, and the code now says why.

FIFA 17 has genuine multi-squad semantics. The client's own shipped action
table has SelectSquadById, RetrieveSquad as an action DISTINCT from
LoadActiveSquad, CreateSquadWithName, RenameSquad, DeleteSquad, CopySquad,
indexed SQUAD_ID-%d list entries and FUT_MAX_NUM_SQUAD_REACHED. The base
template is `ut/%s/squad` with the id appended. The number identifies a squad.

The inherited behaviour came from a bare prefix regex in the Python oracle -
`re.compile(G + r"/squad")` calling squad_route(), which never reads the URL id
(GET returns current_squad(), PUT echoes the id from the BODY). The comments
around it show /squad/list and the draft routes had to be registered first
because that rule was swallowing them. It was expedient, not evidence-driven.

Collapsing the id is nonetheless SAFE today, and only for a specific reason:
we advertise exactly one squad. ACTIVE_SQUAD_WIRE_ID is a constant 0,
/squad/list returns a single-element array carrying it, and no
create/rename/delete/copy route exists, so the client can only echo back the id
we gave it. Every numeric path in retained captures is squad/0, all PUTs whose
body id also reads 0; no numeric GET has ever been recorded.

Behaviour is therefore UNCHANGED - no evidence justifies changing it, and
unknown-id semantics are deliberately not invented. What changes is that the
assumption is now explicit and enforced:
numeric_squad_routing_is_safe_only_while_one_squad_is_advertised pins the wire
id at 0 and /squad/list at one entry, and fails the moment a second squad
becomes addressable. Verified by simulating a second advertised squad.

Workspace 1252 passed (1251 + this test), 0 failed.
 2026-08-24 22:35:28 +00:00
funman300 e49c1f211c fix(fifa17): route the client's lowercase usermassinfo to the Rust handler 
The retail client sends BOTH casings. Observed twice on staging, each time
inside a genuine client sequence:

  16:56:56  route=squad-active 200
  16:56:56  GET /ut/game/fifa17/usermassinfo -> passthrough -> 502
  16:56:56  route=userMassInfo 200

classify matched the exact literal `userMassInfo`, so the lowercase request
fell through to the Python upstream. Today that is a harmless 502 because the
upstream is dead and the client immediately retries with the canonical casing -
but on a deployment with Python ALIVE that request would be ANSWERED there,
silently splitting authority away from Rust for a route Core owns. That is the
real defect, not the wasted round trip.

Fixed with the smallest possible alias: this one tail is matched
case-insensitively, the rest of the table stays exact since no other route has
ever shown a casing variant. Paths are NOT globally lowercased.

Tests cover the canonical casing, lowercase, uppercase, two adjacent tails that
must NOT be swept up by the alias (`usermassinfox`, `usermass`), and method
semantics (PUT/POST still passthrough). With the alias reverted the test fails.
 2026-08-24 22:00:08 +00:00
funman300 96f24e799a fix(test): restore #[test] on the SBC fault guard test 
The squad_actives default test was inserted between #[test] and the function
it belonged to, which stacked a duplicate attribute on the new test and left
sbc_post_commit_faults_require_all_staging_guards with none - silently
disabling it while the new test ran twice.

Caught by clippy (-D duplicate-macro-attributes, -D dead-code); the doubled
test name in the earlier run was the tell. Lib tests go 129 -> 131 with both
now executing.
 2026-08-24 21:39:48 +00:00
funman300 f315f16e8e feat(fifa17): emit squad.actives by default 
Serving the club's active home and away kit is normal FIFA 17 behaviour, not
an experiment: it is what lets the client make the kits resident and render
the pre-match selector. A correct deployment should not have to opt in, so the
default is now ON and the environment variable survives only as a diagnostic
off switch (OPENFUT_FIFA17_SQUAD_ACTIVES=0).

The gate was added when a populated actives array was once seen to empty the
squad. That justification no longer holds:

  - it never reproduced, and the feature is now proven end to end on a retail
    client - 29 resident nodes, both cardtype-7 kits in club slots 0 and 1 with
    itemState 101/102 and category 4, alongside 23/23 players and a resident
    manager, with the selector rendering correct distinct home and away kits;
  - it can no longer cause durable damage, because both squad write-back paths
    are guarded in Core (empty replacement refused; an absent manager field no
    longer read as "clear").

Scope audited before flipping: squad_actives() emits ONLY the home and away
kit, each resolved from Core's active designations and required to be genuinely
owned. Badge, ball and stadium are never emitted, so enabling this cannot
surface an unproven active family - confirmed on the wire, where the emitted
itemTypes are exactly {"kit"}.

Env parsing moved into a pure parse_squad_actives() so the DEFAULT is testable
rather than depending on process environment. Unrecognised values stay ON
rather than silently disabling the feature.

Verified on staging with the env var REMOVED from host.env entirely: the host
logs squad_actives=true and serves both kits (assetId 14/15, states 101/102)
with 23/23 players and the manager intact.
 2026-08-24 21:38:33 +00:00
funman300 ead0426ea0 tools(re): correct transposed field labels in the kit record diff 
club_items.json's _record_map is authoritative: cardassetid is +0x1c and
assetId is +0x20. The probe had them the other way round, which made a correct
assetId 14/15 read out as an identical cardassetid and briefly supported the
wrong conclusion that assetId was not the art selector.
 2026-08-24 21:01:29 +00:00
funman300 74768693ec fix(fifa17): send a club item's real wire assetId, not its carddbid 
A club item's `assetId` (record +0x20) is family specific and is NOT the
carddbid: per the client's own tables a kit carries the art class from
fcc_kitcards.assetid - 14 for the 63xxxxx home/third band, 15 for the 64xxxxx
away band - a badge carries its team id, and a ball and stadium their own
asset number. The catalog shipped `asset_id`, the carddbid, in that slot.

Measured on the live client with both kits resident: record +0x20 held
6300006 (home) and 6400003 (away) where the table says 14 and 15, while every
other field - resourceId, cardassetid 35, category 2/3, teamid 21, year 0,
itemState 101/102 - already matched. Operator reports both pre-match kit tiles
rendering identically. assetId is the only field that diverges from the
client's own data, and an assetId that is not a valid kit art class cannot
resolve to distinct art.

`resource_id` is derived from `asset_id`, and every home kit shares art class
14, so the two cannot be the same field: catalogs now carry an optional
`club_asset_id`, defaulting to `asset_id` so a catalog predating the field and
every non-club kind are unchanged. resolve_kit emits it as the wire `assetId`.

Fixed at the source too - scripts/sold-staging-up.py emitted asset_id as the
wire assetId for all four club families, so a re-emit would have regressed it.

Field-offset note: club_items.json's _record_map is authoritative and my
earlier working note had these transposed - assetId is +0x20 and cardassetid
is +0x1c, not the reverse.

Adds tools/live/diff_kit_records.py, which byte-diffs the two resident kit
records and names the fields the decoded clone query consumes.

Staging wire now reads assetId 14/15 with cardassetid 35 on both
squad.actives and /club?type=equippables. Workspace 1250 passed, 0 failed.
Client re-parse still to be confirmed visually.
 2026-08-24 20:35:58 +00:00
funman300 6bbc0eaf4f fix(fifa17): never turn a missing manager ref into a manager deletion 
The host called set_squad_manager unconditionally on every squad save, passing
the resolved manager or None. None was serialised as {"owned_card_id": null},
an EXPLICIT removal, so a save that merely said nothing about the manager
deleted the assignment. That is how a client whose squad model had been
destroyed wiped a real manager row (WAL commit 468, squad_managers 1 -> 0).

FIFA 17 has no wire shape that removes a manager: the client always sends a
ref. So None never means "the user cleared the slot" - it means the ref was
absent, zero, or unmappable, i.e. this save carries no manager decision. The
assignment is now left untouched and the skip is logged.

The capability is removed at the TYPE level: CoreAccess::set_squad_manager
takes &str, not Option<&str>, so the host cannot express a clear at all. Core
still supports deliberate removal via an explicit null for other callers.

The existing test asserted the destructive behaviour as intended ("a later save
without a manager CLEARS it"). That contract was the bug; it now asserts the
manager survives and that both saves still commit their slots. With the fix
reverted the test fails.

Live-proven on staging against the real route (PUT /ut/game/fifa17/squad/<n>;
squad/active is a GET-only tail and falls through to the dead Python upstream,
which is why an earlier replay attempt proved nothing):

  exact original shape (no resolvable players, manager: [])
    -> 502 core_error, core returned status 400, nothing mutated
  valid 23-player save carrying manager: []
    -> 200 {"id":0}, manager_write_skipped logged, manager PRESERVED
  valid 23-player save carrying the real manager ref
    -> 200 {"id":0}, manager assigned

Players 23/23, manager 1, captain, active club items, coins, integrity and FK
identical before and after, and again after a Core+host restart.
 2026-08-24 19:59:09 +00:00
funman300 09bb2dc306 chore: bump openfut-core - refuse squad replacements that empty a populated squad 2026-08-24 19:27:45 +00:00
funman300 42229e5782 tools(re): report club-item slot indices in the residency probe 
The squad parser writes actives element i to club-item slot r15d+i, and r15d
is shared scratch that other atom handlers clobber. Which slots are filled
therefore reveals the index the parse actually started from, which is the
open question behind the regression in vault section 18.

probe_resident_fields.py now prints the slot index of every populated entry
plus the empty ones, and verify_kits.sh runs it next to the map census so one
command reports both residency and whether the squad survived.
 2026-08-24 18:58:41 +00:00
funman300 d929efdffe fix(fifa17): disable squad.actives by default after it emptied the squad 
Populating `squad.actives` is the proven way to make a club item resident —
the squad parser writes each element straight into a club-item slot, both
kits came back resident with the client writing `category 4` itself, and the
pre-match kit selector worked.

But a populated array was then observed to cost the rest of the squad. On a
full client relaunch the resident item map fell from 24 entries to just the
2 kits, the 23-slot player vector came back fully null, and the starting-11
screen was empty; the manager and staff were gone too. Every host response
was 200/outcome=ok with no warning, so the loss is entirely client-side
parse behaviour. `actives` sorts first in the squad object, so `captain`,
`formation`, `manager`, `players` and everything else after it are lost —
consistent with the element loop leaving the tokenizer misaligned.

The same payload produced a correct 24-node map on an earlier relaunch, so
the interaction is not yet understood and is not safely shippable. An empty
squad is far worse than a missing kit, so the array is now gated behind
`HostConfig::squad_actives` (env `OPENFUT_FIFA17_SQUAD_ACTIVES`) and off by
default. The projection, identity plumbing and tests are kept intact: they
are correct and are what the investigation will re-enable.

Staging redeployed with the flag off and verified back to 23/23 populated
player slots and `actives: []`.
 2026-08-24 18:53:28 +00:00
funman300 98f30931a0 fix(fifa17): never schedule the club's own kit team as a season opponent 
The pre-match kit clone resolves BOTH sides out of the client's own
teamkits table keyed on teamtechid, with only teamkittypetechid (0 home,
1 away) telling the strips apart:

    teamtechid        == record+0x94   (wire teamid)
    teamkittypetechid == 0 for activeHomeKit, 1 for activeAwayKit
    year              == record+0xba   (wire year)

Our club wears team 21's kit (fcc_kitcards carddbid 6300006/6400003 are
both teamid 21), and the offline-season ladder cycled a fixed opponent
list whose first entry was also 21. So round 0 put the club against the
team whose kit it wears and both sides rendered the same strip. It is
also simply wrong data: a club playing itself.

The schedule now excludes the club's own kit team, which the host derives
from Core's active kit designations via resolve_kit. An exclusion that
would empty the rotation is ignored, because an empty matches array makes
StartSeason dereference NULL at CardsDLL+0xfc5b5.

This is not a kit-pipeline change: squad.actives already produces the two
resident cardtype-7 records with the correct itemStates, and the clone
query is satisfied by that data unchanged.
 2026-08-24 18:26:10 +00:00
funman300 a5e5628039 tools(re): one-command native proof for resident kit records 2026-08-24 18:00:25 +00:00
funman300 0e200758f0 fix(fifa17): project active club items through squad.actives 
FIFA 17 makes a club item resident ONLY through squad.actives. The squad
parser's arm for atom 11 computes the address of the i-th element of the
client's five-element club-item array and hands it to the item
deserializer as the out-handle:

    cmp  edi,0x5                    ; at most five entries are read
    mov  rax,QWORD PTR [r13+0x108]  ; the club-item array
    lea  rcx,[rax+rcx*8]            ; &array[edi]
    call 0x18013fe00                ; item deserializer, writing that slot

That deserializer inserts the record into the client's resident item map
- keyed by wire instance id, gated only on the id being non-zero - and
binds the slot handle to it. So each element must be a full item object
like squad.manager[].itemData; an id reference alone installs nothing,
because the manager installer looks its id up in that same map and does
nothing on a miss.

We emitted actives: [] as an 'observed constant', which was circular: it
came from our own captures and the Python oracle seeded it. The client
then read the array-end token immediately, parsed nothing, and left all
five slots null, so every lookup resolved to the static not-found
sentinel whose item pointer is NULL. That is why the pre-match kit
selector had no kits, and it is also why /club?type=kit could never fix
it: no /club response feeds that array.

Core already owns the designations via /club/active-items, so the host
reuses get_active_kits() and the adapter shapes each entry with the same
shape_club_item primitive /club?type=kit uses, keeping one wire dialect.
A Core transport error yields no actives and is reported rather than
silently empty. userInfo.actives already mirrors the squad's.

Verified against the client's own fcc_kitcards table: 6300006 is team
21's home card (category 2) and 6400003 the away card (category 3).
 2026-08-24 17:59:11 +00:00
funman300 2fc335c37d tools(re): interpret FIFA17 atom mappers and enumerate the resident item map 
Two tools, both gated on positive controls because the previous pass
produced a confidently wrong negative result.

atom_mapper_emu.py interprets the atom -> field-id dispatch functions
instead of pattern-scanning them. Its selftest encodes the two decoder
traps that caused earlier mistakes - ModRM rm=5 with mod!=0 is [rbp+disp]
rather than RIP-relative, and a constant may reach its use through a
register - plus the live-verified controls that the item mapper maps atom
568 'players' to field id 1 and atom 11 'actives' to 0. The mandatory
manager atom 424 control still fails as a coverage limit: only 2 of the 52
resolver callers are pure dispatch chains, so the tool refuses to support
any absence claim about the squad mapper.

The live probes enumerate the resident item map at owner+0x160c8, whose
layout came from the lower_bound at 0x180119640: key = wire instance id at
node+0x20, record at node+0x28, count at owner+0x160e8. probe_map2 reaches
22 nodes against a count field of 22, so the enumeration validates itself,
and probe_hunt searches all writable memory with its own in-run positive
control. Result: all four club staff are resident, both kit ids are absent
everywhere, and a lookup miss returns the static sentinel 0x1802c2a28
whose +0x10 is NULL - which is exactly the KIT_SCAN symptom.
 2026-08-24 17:24:57 +00:00
funman300 25b7089c54 tools(re): walk the record pool embedded in the club-model owner 
Records are 0x180 bytes starting at owner+0x162d8, below the embedded
manager subobject at owner+0x1f9d8. Walking that pool answers whether the
client ever builds a record for an item it was served, independently of
whether the record is filed into a collection.

Result on the live client with the kit selector open: 21 records exist -
18 squad players with category 1, plus one cardtype 10 and two cardtype 4
staff with category 0 - and no cardtype 7 record anywhere, despite two kit
items having been served three times in the same boot.
 2026-08-24 17:00:31 +00:00
funman300 8983998707 tools(re): dump resident record fields to settle the kit category gate 
The kit clone driver FUN_1801c3480 gates on record+0x60 == 4, and no
instruction stores that immediate, so the value had to be read off a
genuinely resident record. This dumps cardtype, cardsubtypeid, itemState,
category, teamid and teamkittypetechid for both the player vector and the
club-item vector, resolving the store through the same chain as the census.

Result: all 18 resident players carry category 1 and the five club-item
slots are null, which identifies +0x60 as a per-collection tag rather than
item data.
 2026-08-24 16:54:04 +00:00
funman300 96610ccb16 tools(re): remove the port-8081 DNAT that breaks FIFA 17's roster TLS 
A client-local nat rule redirecting dport 8081 to the plain-HTTP staging
UTAS host captures the roster/squad-update TLS connection, which is
https://winter15.gosredirector.ea.com:8081/fifa17/fut/rosterupdate.xml.
The staging host completes the TCP handshake then closes on the
ClientHello, so the client retries and shows "An error occurred
downloading the FUT squad update."

Proven by capturing on the server while probing from the client: a
connection addressed to :8081 arrives as dport 8299, while an :8443
control in the same capture yields 75 packets and a clean handshake.

The script deletes only nat rules whose destination port is 8299, then
verifies the endpoint presents CN = winter15.gosredirector.ea.com.
 2026-08-24 16:36:56 +00:00
funman300 704482be84 tools(re): watch resident club-item population for route correlation 
Read-only watcher that waits for FIFA17.exe, re-resolves the club-item store
each tick (the manager is reallocated per login), and emits one timestamped line
per CHANGE. Pair it with

    journalctl -u openfut-staging-host -o short-iso

to answer "after which response does a resident club item first appear?" by wall
clock, without having to reverse the constructor first.

Re-resolving per tick matters: the store is reached through
[CardsDLL+0x2e6398] -> vtable[0x4e8], and that getter is a `lea`, so the manager
is an embedded subobject whose address moves with the owner. The tool also
re-checks the module base against a known immediate every time it attaches and
refuses to report from a wrong base.

Verified against the currently live client: club=0/5 players=18/23.

Staging can host the session: every bootstrap route probed answers 200
(userMassInfo, squad/active, squad/list, club/stats/*, hub, user, club arms,
item idList, clubUser, season/list, watchList, purchased/items, settings,
clientdata) with the single exception of /statistics/tournament, which 502s
because staging's Python upstream is deliberately dead and which is not on the
club bootstrap path.
 2026-08-24 16:13:36 +00:00
funman300 0997dd3b60 tools(re): census FIFA 17's resident club-item vector 
Read-only /proc/PID/mem census of the client's resident club-item store, which
is what the pre-match kit selector actually consumes. No writes.

Resolves the whole chain from static RE rather than guessing offsets:

  [CardsDLL+0x2e6398]        -> owner object       (FUN_18011a830 is a plain
                                                    global read)
  owner->vtable[0x4e8]       -> lea rax,[rcx+0x1f9d8]; ret, i.e. mgr is an
                                EMBEDDED subobject, not a pointer
  mgr+0x108 .. mgr+0x110     -> club-item vector, stride 24
  element+0x10               -> the item record    (FUN_1800d73d0)

CardsDLL is located by its NEAREST PRECEDING NAMED mapping, because Wine maps PE
sections anonymously and the Wine heap is also rwx, so permissions do not
discriminate code from heap. The base is then sanity-checked against a known
immediate (mov edx,0x7575 at 0x180026fea) and the tool aborts rather than
reporting from a wrong base.

Field offsets are the ones already proven, and nothing else is interpreted:
+0x4c cardtype, +0x50 cardsubtypeid, +0x5c itemState, +0x60 category,
+0x94 teamid, +0xba teamkittypetechid (u16).

FIRST RESULT, live on the client parked at the pre-match kit selector:

  players    mgr+0x0d8: 23 slots, 18 non-null, all (cardtype 1, subtype 0)
  club items mgr+0x108:  5 slots,  0 non-null

Five slots, every item pointer NULL. Five is the club's active club-item set --
home kit, away kit, badge, stadium, ball -- so the client knows it should hold
five and holds none. That is why FUN_1800d73d0 returns the 0x1802c2a28 sentinel
whose +0x10 is NULL, and why the tiles are untextured.
 2026-08-24 16:08:02 +00:00
funman300 743b20b00b kits: 0x757a is the command "useSavedMatchKits" - the gate was never the bug 
Recovered from the live retail client (pid 44405, parked on the pre-match kit
selector) by read-only /proc/PID/mem. No writes, no debugger, no detours, no
client modification. Denuvo decrypts FIFA17.exe in memory, so the immediate that
is absent on disk is present at runtime.

At live 0x147de80e8 FIFA17.exe runs a name-registration loop through the same
string-setter vtable slot (+0x20) CardsDLL uses, so each id can be given its
name:

    0x7579  useSavedMatchData        -> movb $1, ctx+0x151
    0x757a  useSavedMatchKits        -> movb $1, ctx+0x152  == KITS_AVAILABLE
    0x7587  setFUTServerEnvironment

271 pairs recovered and committed. This is a DIFFERENT namespace from CardsDLL's
DataProvider id table -- the same numeric id has a different name in each --
matching the APT's own split between game.uif.UIFDataProviderList and the
action/command list.

KITS_AVAILABLE therefore does not mean "the server sent kits". It means "use the
previously SAVED match kits", and the APT writes those via ACTION_SAVE_MATCH_KIT
in SaveKitsForMatch. Live, both flags read 0 on a fresh match at the exact
moment the tiles are blank. So 0 is CORRECT on first entry and the client is
designed to take the fallback path. The gate was never the defect, which is what
the 2026-08-23 measured negative was already indicating when better item data
changed nothing.

The fallback is GetKitArrayForFUT -> ION_Uniform.GetIDs(teamId), which natively
gates on team id 130000 (0x1800d8ab0) or 130001 (0x1800d8ad0) -- the synthetic
FUT home/away pair -- and otherwise defers to the generic engine catalogue. For
a matching team it packs the two active kit records and admits them through a
check that resolves at runtime to "cmp edx,0x189a1003 / setne al", i.e. merely
"not the invalid sentinel".

Still no OpenFUT change: whether the selector requests 130000/130001, and
whether the active kit records resolve, are both unanswered and both live
questions. Full write-up in the Vault under Kit Selector APT Decode section 8.
 2026-08-24 05:29:21 +00:00
funman300 e48d659bce host: fix stale test that still asserted equippables was withheld 
d146f9c flipped `club?type=equippables` from withheld to answering the KIT
family — the change that made kits render in My Club, operator-confirmed — but
it only touched src/lib.rs. `withheld_club_type_arms_are_empty_with_a_recorded_reason`
still listed that arm, so the suite asserted the exact behaviour the fix
removed. It failed on `cargo test --workspace`; the "1241 passed" figure carried
in the notes was measured before the flip and was stale.

Drops the arm from the withheld table and adds a test for what actually ships:
the tab answers, serves exactly the kit family with cardsubtypeid 9, and returns
the same body as `?type=kit`, so the two tabs cannot drift apart.

`OPENFUT_FIFA17_EQUIPPABLES=0` is deliberately not exercised: it is read through
a OnceLock, so flipping the process-wide env in one test would leak into every
other test in the binary.
 2026-08-23 23:08:24 +00:00
funman300 a86d21ec79 kits: decode the FIFA 17 APT bytecode; KITS_AVAILABLE is not a server field 
Adds fifa17-recon/tools/apt_decode.py, a clean-room decoder for the EA APT
compiled-ActionScript format as FIFA 17 ships it, and deletes avm1_disasm.py,
which assumed SWF framing and could not decode this artifact.

FORMAT. FIFA 17 uses a 64-bit variant of the format: constant-pool entries are
16-byte {u64 type, u64 value} in a separate "Apt1" container member, container
pointers and counts are u64, DefineFunction2's operand block is 48 bytes rather
than 28, its 0x1234567898765432 trailer is stored as two u64 halves, and
parameterised instructions align their operand block to EIGHT bytes, not four.
The alignment is the fact that made the stream decodable: the ConstantPool at
0xd38 yields garbage at align-4 and count=401 at align-8, with an index array
that terminates exactly on the parameter-list region.

The three opcodes that blocked the previous attempt are all unaligned 2-byte
records: 0xAF EA_GetNamedMember (u8 constant-pool index, pop object push member),
0xB9 EA_PushRegister (u8 register index), 0xA2 EA_PushConstantByte (u8
constant-pool index). Byte-wide indices only reach pool entries 0-255, which is
why CheckIsKitLocked at index 293 is emitted as 0xA3 PushConstantWord.

Format facts came from a written specification derived from OpenSAGE
(588ac477367a0022adf29f20a084e8873014e6ce, GPL-3.0 with EA section 7 additional
terms). No code was copied or transliterated; only the interface specification
was used. Provenance is recorded in the module docstring.

VALIDATION. The whole artifact decodes: 5251 instructions, 24 functions, action
stream 0xd38..0x3e75 with 12605 of 12605 bytes covered and zero interior gaps,
zero unresolved opcodes, zero invalid branch targets, zero unresolved strings.
Every byte of the 20630-byte member is accounted for by region. --selftest
asserts all of it, plus operand fixtures and fail-closed behaviour on truncated
records, out-of-range pool indices and unknown opcodes. Unknown opcodes still
refuse to guess a length rather than resynchronising.

RESULT. KITS_AVAILABLE is a BOOLEAN in the DataProvider header, not a count, so
the logged Some(0) means false. futSelectTeam::Publish reads
publishObject.header.KITS_AVAILABLE == true and only then fills m_arrKitPanelData
from data[side].LENGTH and data[side]["KIT_"+i]; CardsDLL's builder writes
exactly that shape ("LENGTH" and "KIT_%d" confirmed in .rdata). The flag comes
from ctx+0x152, whose only setter is internal message 0x757a. That message is
never constructed in ActionScript (the asset contains zero integer literals
above 255) and never sent by CardsDLL (247 of 247 send sites pass an immediate,
none of them 0x757a; four sites in the same family are the positive control).

So no HTTP response can open this gate, and no OpenFUT change is made here.
CheckIsKitLocked is called at 0x2cc3 but defined on the mcSelectTeam child clip
in another asset, so its body is deliberately NOT reconstructed rather than
guessed. Full findings in the Vault under Kit Selector APT Decode.
 2026-08-23 22:44:14 +00:00
funman300 f40e8587ac kits: futSelectTeam APT extracted; bytecode is EA-extended AVM1, not plain SWF 
Operator exported futSelectTeam.BIG (88272 B, BIGF, 11 members). Confirmed the
right screen: FUT_GET_MATCH_KITS_DP, CheckIsKitLocked, mcLockHome and
KITS_AVAILABLE all present. Members split out and committed:

  futSelectTeam_Apt1.bin     14526 B  magic Apt1
  futSelectTeam_AptData.bin  20630 B  magic "Apt Data:1:7:8"

STRUCTURE, measured rather than assumed:
  * Apt1 is header + a u32 STRING POINTER TABLE + an 8-byte-aligned string table.
    Every symbol has exactly one u32 reference and the refs run in the same order
    as the strings, so they are pointers, not code references.
  * Apt Data holds the actions. Opcode frequencies are AVM1-shaped - GetMember
    0x4e x309, If 0x9d x172, CallMethod 0x52 x160, DefineFunction2 0x8e x33,
    Jump 0x99 x74 - but two non-standard opcodes dominate (0xaf x1081,
    0xb9 x1064), so this is EA's extended dialect and strings are referenced by
    table offset instead of a SWF ActionConstantPool.

Adds avm1_disasm.py, which reads the standard subset and prints unknown opcodes
with their length rather than skipping them. It is NOT sufficient for this file:
decoding 0xaf/0xb9 is the remaining work, and OpenSAGE apt-toolkit is the
reference implementation for EA APT actions.

So CheckIsKitLocked is located but not yet READ. What is known stays known: the
native side only ever writes LOCKED = 0, so the predicate lives here.
 2026-08-23 22:09:17 +00:00
funman300 5bf2c7ddc1 kits: the pre-match kit screen is futSelectTeam, found without Frosty 
The Frostbite .cas chunks holding APT ActionScript are greppable, so screens can
be identified and their whole symbol table recovered without driving the GUI.
Control: KitAssignmentPopup (a string from an already-exported BIG) hits 43 times
across the 52 cas files, so a miss would have been meaningful.

FUT_GET_MATCH_KITS_DP hits 10 times. The binding screen is
external.ion_fut.screens.futSelectTeam
(fifa_installpackage_01/cas_01.cas @ 0x3707ecd7), which no exported BIG contained
after 33 attempts at guessing names.

It binds FUT_GET_MATCH_KITS_DP, KitSelectDP and TeamSetupDP, and carries exactly
the vocabulary the native side implies:

  panels/locks  mcKitHome mcKitAway mcLockHome mcLockAway m_arrKitPanels
  sides         HOME_SIDE AWAY_SIDE NEUTRAL_SIDE SIDE_HOME SIDE_AWAY
  DP fields     KITS_AVAILABLE  KIT_  HOME_KIT_ID  AWAY_KIT_ID
  flow          InitializeKitConfig GetKitArrayForFUT InitializeKitsFromArray
                EnterKitSelect IsKitSelectCreated ExitKitSelect SaveKitsForMatch
  lock          CheckIsKitLocked  RemoveKitLocks  SetKitReady  SetKitUnReady
  uniform       SetUniform ION_Uniform GetNonConflictingUniformID

CheckIsKitLocked is the lock predicate the native side does not own — recall
sub_180033430 only ever writes LOCKED = 0, so the "kit is currently locked" dialog
is raised here.

Adds find_apt_in_cas.py (control-guarded) and the recovered 934-symbol table.
 2026-08-23 21:52:36 +00:00
funman300 d146f9c3fc host: answer club?type=equippables by default — kits now render in My Club 
OPERATOR-CONFIRMED on the retail client: the My Club kit tab shows both kits, the
first time kits have ever rendered in this project.

The tab asks for `?type=equippables`, and that arm was withheld, so the screen got
an empty body and showed nothing. That is exactly what "0 kits in my club" was —
not a shaping problem, a refused question. Log line that identified it:

    route=club outcome=withheld filter=[type=equippables,
                    reason=multi_family_crash_2026_08_05] total=0 emitted=0

TWO fixes were both required, so neither alone is the cause:
  * this arm answers (KITS ONLY), and
  * GET ut/%s/item (FutViewCards) returns the OWNED INSTANCE rather than a
    definition placeholder, so the kit arrives as cardsubtypeid 9 /
    itemState active{Home,Away}Kit instead of "a free player" (d4a39ba).

The 2026-08-05 crash that motivated the withholding was 30 items across FIVE
families. This arm serves one family, and the live body is two items. Serving the
other four families here is untested and stays unserved.

Default flips from opt-in to opt-out: OPENFUT_FIFA17_EQUIPPABLES=0 restores the
withheld body with a restart and no rebuild. The switch is kept rather than
deleted because the only live evidence is a club holding exactly TWO kits; a club
holding many is untested and the original crash was about size and family mixing.

Verified with no env flag set: ?type=equippables -> 2 items, family {9}.
cargo test -p openfut-utas-host: 190 passed, 0 failed. clippy -D warnings clean.
Production untouched — staging only.
 2026-08-23 21:34:05 +00:00
funman300 d4a39ba75d host: ViewCards must return OWNED INSTANCES, not definition placeholders 
GET ut/%s/item is FutViewCards and its ids are OWNED INSTANCE ids - the client
builds the query as ?idList=%lld (CardsDLL .rdata 0x220080) from ids it already
holds. It was being answered with the definition body, which echoes the queried
id straight back. Asked about the active home kit, instance 100004874, the server
replied:

    resourceId 100004874, cardsubtypeid 0, itemType "player", itemState "free"

i.e. "your active home kit is a free player". No kit can ever be seen as active
through that. Real players were equally wrong: instance 100000003 came back as
resourceId 100000003 instead of the actual card 200389 rating 87.

This is on the active-kit path, and the evidence for that is the client's own UI.
KitAssignmentPopup.BIG (exported from Frosty today) decompiles to
external.ion_fut.components.KitAssignmentPopup and contains OSDKCards_ViewCards,
OSDKCards_ActivateCard, mHomeKitID/mAwayKitID/mSourceKitID, and the search states
SEARCH_STATE_ACTIVE_HOME_KIT / SEARCH_STATE_ACTIVE_AWAY_KIT. Those states can
only come from the itemState this route returns.

Route::ViewCards is now distinct from Route::ItemDefs. Owned instances are shaped
by the SAME projector /club uses, so there is one wire dialect and no drift; ids
that are not owned instances still fall back to the definition placeholder, and
the empty query still answers {"itemData": []}, preserving oracle parity for the
definition-style callers (item/resource, defid).

Verified on staging:
  ?idList=100004874,100004873 -> resourceId 6300006/6400003, cardsubtypeid 9,
        itemType kit, itemState activeHomeKit/activeAwayKit, teamid 21, cat 2/3
  ?idList=100000003           -> resourceId 200389, rating 87 (the real card)
  ?idList=999999999           -> definition fallback
  no query                    -> {"itemData": []}
  item/resource? and defid?   -> unchanged

cargo test -p openfut-utas-host: 190 passed, 0 failed. clippy -D warnings clean.
 2026-08-23 21:20:07 +00:00
funman300 9cc5188e5c host: claim GET ut/%s/item (FutViewCards), which fell through to Python 
Fifth instance of this project's recurring dead-route defect: a handler exists and
is correct, but classify() never produces the route, so every request falls
through to the Python upstream. Invisible in production, where the oracle answers;
on staging, where the upstream is deliberately dead, it is a 502.

GET ut/%s/item is FutViewCards (deser 0x1801293d0, top-level itemData via the
shared card element 0x18013fe00). The oracle answers it with defs_route - the SAME
handler already wired for item/resource and defid: pull every integer out of the
query (idList=a,b,c / definitionId= / resourceId=) and return one definition per
id, or {"itemData": []} when there are none (tools/utas_server.py:1103). So
claiming it is byte-identical parity, not new behaviour.

The query handling is the substance of the fix, not decoration. ut_tail does NOT
strip the query string, so an equality-only arm (`Some("item")`) misses every real
request while passing a no-query unit test - which is precisely how the route
stayed unclaimed. The same latent bug applied to the two arms that were already
there: item/resource and defid only matched with no query, so
`item/resource?resourceId=` and `defid?definitionId=` were ALSO falling through.
All three now mirror the oracle's own `item(\?|$)` pattern.

Verified on staging, all 200 where they were 502:
  GET /item                                  -> itemData 0
  GET /item?idList=100000003,100000004       -> itemData 2
  GET /ut/v2/game/fifa17/item                -> itemData 0
  GET /item/resource?resourceId=5003012      -> itemData 1
  GET /defid?definitionId=200389             -> itemData 1

Does NOT by itself fix the kit selector - GET /item is a definition lookup keyed
by ids the client already holds, not the thing that seeds the club collection, and
the observed session never requested it. It is a real production-masked gap and a
prerequisite for testing anything else on staging.

get_item_is_claimed_and_the_other_item_verbs_are_unaffected pins the claim plus
the three verbs that share the prefix: PUT item stays FutMoveCard on the economy
path and DELETE item/<id> stays QuickSellPath.

cargo test -p openfut-utas-host: 190 passed, 0 failed. clippy -D warnings clean.
 2026-08-23 20:22:54 +00:00
funman300 6baa673252 kits: recover the selector data path from CardsDLL; residency tracks the ROUTE, not itemType 
RETRACTION FIRST. The previous commit added itemType to club items on the theory
that it gated ingestion, because player/staff sent it and were resident while
kit/badge/stadium omitted it and were not. Relaunched the client with itemType on
all three: ?type=kit answered total=2 emitted=2, and still no cardtype-7 record.

The correlation was an artefact of the control. Measured read-only over
/proc/PID/mem with full coverage (3605 MiB, nothing skipped): the "resident"
players and staff were all SQUAD members, which arrive via userMassInfo. Players
that appear in /club?type=player but NOT in userMassInfo are not resident either -
0 records for 6 of 6 sampled, 5 with no byte match at all, out of 1966 served.
Residency tracks the ROUTE. /club?type= responses never enter the persistent card
collection, and no value of itemType changes that. itemType is kept as wire
fidelity (every real EA item carries it) and relabelled; its doc no longer claims
to fix anything. The diagnostic KIT_PROBE is removed - it could only have tested
shape hypotheses that this result makes moot.

RECOVERED from the unpacked CardsDLL, no archive extraction, no instrumentation:

  Packed kit id, both directions present and agreeing:
    id = (teamid << 14) | (year ? (year-1800) << 5 : 0) | kittype
  so a kit is addressed by the triple (teamid, year, kittype).

  FUN_180033770 answers ONLY for team 130000 - 0x1800d8ab0 is literally
  `mov $0x1fbd0,%eax ; ret`. Every other team id falls through to the engine's
  catalogue kits, which are the lockable ones.

  sub_180033430 writes the tile: NAME = "HOME_SIDE"/"AWAY_SIDE", TYPE = the
  localised Kit_type_0 / Kit_type_1 / Kit_type_historical, and LOCKED (always
  value 0, never 1). If the queried triple matches NEITHER active triple it
  writes NOTHING - which is exactly why one tile rendered "undefined". A missing
  write, not a bad string. There is no Kit_type_2.

  FUN_1800d73d0 selector 2/3 does `setne dil ; add $0x65,%edi` then compares
  itemState: active home = 101, active away = 102, derived arithmetically and
  independent of the enum table. year at +0xba is movzbl - a byte INDEX.

  Above all of it: FUT_GET_MATCH_KITS_DP (0x7565) handler FUN_1800be6a0 gates on
  `cmpb $0x1,0x152(%r14)` and returns early otherwise. KITS_AVAILABLE IS
  ctx+0x152. Constructor zeroes it; the only setter is case index 6 (message
  0x757a) of the jump table at 0x1800c00d4. Live value is 0, so no kit list is
  ever built. 0x757a has no name in CardsDLL and that is bounded, not sloppy: the
  registration run ends at 0x7575 with the epilogue immediately after, and 70
  other ids resolve from the same table as the positive control.

Tables (audit_fifa17_kits.py, full-table counts): category 2/3/5 -> engine kit
type 0/1/2 with 0 counterexamples against 54/166/145 discriminating keys; the id
band is NOT home/away (band 63 holds 740 home AND 88 third).

Vault: "Kit Selector Data Path.md". cargo test 429 passed 0 failed across the two
crates; clippy -D warnings clean; fmt clean.
 2026-08-23 20:08:08 +00:00
funman300 eefa98c961 kits: canonical table-proven kit map, and category is the home/away key (not the id band) 
Answers from the extracted client tables, before touching a binary. Every number
is a count over the full table.

  fcc_kitcards 1482 rows, teamkits 2576 rows.

CATEGORY -> ENGINE KIT TYPE, with a test that can actually fail. Asserting
"category 3 means away" because away kits usually exist is not evidence: types
0/1/2 are present for most teams, so it is true by construction. The
discriminating cases are the teams that LACK a type.

  category 2 -> type 0 HOME    54 keys lack type 0, 0 counterexamples
  category 3 -> type 1 AWAY   166 keys lack type 1, 0 counterexamples
  category 5 -> type 2 THIRD  145 keys lack type 2, 0 counterexamples

and there is never more than one card per (team, year, category).

THE ID BAND IS NOT HOME/AWAY. Band 6300000 holds 740 HOME cards AND 88 THIRD
cards; band 6400000 holds the 654 AWAY cards. assetid is fully determined by the
band (14 for 828/828 of 63xxxxx, 15 for 654/654 of 64xxxxx), so it carries no
information the band does not. cardassetid is 35 on all 1482 rows - it is the FUT
card frame, not the kit art.

This matters for openfut-adapter-fifa17: KIT_AWAY_FLOOR splits home from away at
6_400_000, which is right for home vs away but silently classifies all 88 THIRD
kits as HOME. Recorded here, not yet fixed - third kits are not currently
ownable, so nothing observable depends on it.

teamkits.islocked is 0 on all 2576 rows, so the DB lock flag is NOT what makes
the pre-match selector call a kit locked. 6 rows are embargoed.

Team 21, the staging club, resolves exactly:
  6300006 cat 2 HOME  year 0    assetid 14 -> teamkitid 1376
  6400003 cat 3 AWAY  year 0    assetid 15 -> teamkitid 1377
  6300007 cat 2 HOME  year 1972 assetid 14 -> teamkitid 5126
  6300008 cat 5 THIRD year 0    assetid 14 -> teamkitid 1378

so the two kits OpenFUT serves are the correct home/away pair.

NOT recoverable from data/tables: the kit's own name string. fcc_kitcards
name/header/description/biodescription are byte OFFSETS into the table's string
blob (583, 597, 608, 619 on one row), and that blob is not among the extracted
tables.

Adds audit_fifa17_kits.py (the tool, with the discriminating test inline) and
fifa17-kit-map.json (its output) so this is reusable data rather than terminal
scrollback.
 2026-08-23 19:34:06 +00:00
funman300 88ae754b0f launcher: record the detour revert (d764117) 
The submodule pointer still referenced the rate-limited engine-provider build.
d764117 removes those detours entirely; they froze the client once and crashed
it once, and the fault was the detours themselves rather than their logging.
 2026-08-23 19:30:23 +00:00
funman300 e0f1e379b7 kit probe: settle the ingest question in one restart; itemType alone did NOT fix it 
RESULT OF THE PREVIOUS COMMIT, recorded before anything else: sending itemType on
cardtype-7 club items did NOT make them ingest. Client relaunched, ?type=kit
answered total=2 emitted=2 with itemType="kit" on both, and afterwards there is
still no cardtype-7 record resident and the hook still traces
KITS_AVAILABLE = 0. The player/staff-vs-kit/badge/stadium correlation was real
but it is NOT the cause. The field is kept because every real EA item in the
capture corpus carries it and the two ingesting families already did, but it is
now labelled wire fidelity, not a fix.

Also already refuted, so neither is the answer: ?type=equippables answered with a
kits-only body (kits stayed undefined), and the kit ids are correct - 6300006 and
6400003 are the real fcc_kitcards carddbids for team 21 home/away with matching
category 2/3 and year 0.

This adds OPENFUT_FIFA17_KIT_PROBE (default OFF, staging armed) which appends two
synthetic kits to ?type=kit so ONE client restart discriminates the two remaining
hypotheses instead of one restart each:

  6300007 MINIMAL - exactly the field set a STAFF item carries, which is known to
    ingest, plus cardsubtypeid 9. If only this appears, one of the kit-only
    extras (assetId, cardassetid, teamid, category, year) makes the client
    discard the item.
  6300008 NAMED - full kit shape plus name/localizedName/description, the three
    fields the cardtype-7 parse arm is documented to copy and which OpenFUT has
    never sent. If only this appears, they are required, not optional.

If NEITHER appears, ?type=kit is not the route that populates the collection
FUN_1800d73d0 scans, and the search moves to which route does.

Both ids are real team-21 carddbids, served free so they cannot disturb the
active-kit assignment, with instance ids outside Core's range. Two items in one
family: the response that crashed this client on 2026-08-05 was thirty across
five.
 2026-08-23 19:29:33 +00:00
funman300 6d89d62e41 club items: send itemType, which every ingested family already carries 
Measured live 2026-08-23 against the client parked on the pre-match kit selector
(pid 8793, read-only /proc/PID/mem). Whether a served club item becomes a
resident item record correlates perfectly with whether we send itemType:

    family    itemType sent   resident record?
    player    "player"        yes
    staff     "staff"         yes
    kit       (absent)        NO
    badge     (absent)        NO
    stadium   (absent)        NO

Two of two families that carry it are ingested; none of the three that omit it
is. With no cardtype-7 record resident the club scan FUN_1800d73d0 matches
nothing, the FUT match-kit DataProvider is built empty (traced: KITS_AVAILABLE
= 0), and the selector falls back to catalogue-gated engine kits - which is the
"This kit is currently locked. To unlock and use it, please go to the Football
Club Catalogue." dialog the operator sees. That string lives in the Flash UI, and
Blaze receives no catalogue or unlock request at any point, so the lock is
decided client-side from data the client already holds.

CARD_SYSTEM.md records that itemType "is parsed into a heap string and never
stored". That stays true of the RECORD; it does not follow that the string is
unused, and the correlation is evidence it is consulted before the record is
kept.

Tokens come from the ?type= vocabulary decoded from the FUN_18012ec50 jump table
(kit 12, stadium 13, badge 11) - the same vocabulary the two working families
use. INFERRED, not proven: no real EA club item exists anywhere in the capture
corpus, so the exact token is taken from the atom vocabulary, not observed wire.

Near miss worth recording: STADIUM_SUBTYPE was not imported at module scope, so
match treated it as a fresh binding instead of a constant, made that arm
irrefutable and typed badges as "stadium". It compiled with only an
unused-variable warning. every_cardtype7_family_carries_its_own_item_type
asserts three distinct tokens, which is what catches that.

cargo test --workspace: 1240 passed, 0 failed.
 2026-08-23 19:15:38 +00:00
funman300 40e53ed02c kit selector: withdraw the "client dead end" verdict, measure what is actually resident 
The 2026-08-21 entry concluded the pre-match kit selector "is a client dead end,
not a missing wire field" because nothing stores 4 into item +0x60. Withdrawn.
It rested on two mistakes:

  1. +0x60 == 4 DOES occur live - a record with +0x4c == 2 and +0x60 == 4 reached
     the art-clone driver FUN_1801c3480. The immediate-store scan cannot see it,
     so "nothing can satisfy the gate" was never licensed by that evidence.
  2. It annotated `cmp [rdi+0x4c], 7` with "<- we produce this" without measuring
     it. Its own live half showed only {1: players, 0: staff}: zero cardtype-7
     records. That is the finding, and it was read as the opposite.

Measured now against the live client parked on the kit selector, read-only via
/proc/PID/mem over 3047 MiB, searching the exact u32 values the server sent:
players and staff are resident with sane fields; kit, badge and stadium are all
absent by resourceId AND by instance id. The host served ?type=kit total=2
emitted=2 at 17:50:09 this session and neither kit produced a record.

So the blocker sits upstream of the +0x60 gate: no cardtype-7 record is ever
created, so the club scan FUN_1800d73d0 has nothing to match, KIT_DESC never
fires and KITS_AVAILABLE reads 0. Cause is not yet settled - either our wire
shape (the cardtype-7 arm wants name/localizedName/description, which we do not
send) or cardtype-7 items being transient. Neither is recorded as fact.

Also: kit_gate_probe.py's live half is unreliable. On pid 8793 it reported
"CardsDb is empty" while a byte scan found 1966 resident players, so its
structural chain is stale and its record counts understate reality. Adds
club_record_residency_probe.py, which is read-only and cannot disturb the game.
 2026-08-23 18:51:34 +00:00
funman300 b55dd16a46 chore: bump openfut-launcher (engine-provider kit traces) 2026-08-23 17:55:12 +00:00
funman300 11b7991d81 feat(fifa17): gated kits-only club?type=equippables, to test the locked-kit cause 
A live kit_trace run on the retail client showed the kit clone driver only ever
sees PLAYERS - about 19 records, all cardtype 1 / itemState 1 / +0x60 = 1 - and
never a kit, with no KIT_DBCLONE line at all. So the locked-kit failure is
UPSTREAM of the item+0x60 == 4 gate that this arm's comment blamed.

In the same session the client asked for ?type=kit six times, which we answer
and which feeds the items browser, and ?type=equippables twice, which we answer
empty. If the equippable view is what populates the collection FUN_1800d73d0
scans to build the active-kit triple, an empty answer explains precisely why the
triple stays zero and the engine falls back to its own catalogue kit.

The arm now selects ContentKind::Kit behind OPENFUT_FIFA17_EQUIPPABLES=1, so it
answers with TWO items rather than the thirty across five families that crashed
the client on 2026-08-05. Default OFF: that crash is real and reproducible, and
the narrow body is a hypothesis under test rather than an established safe
response. Reverting is an env change plus a restart, no rebuild.
 2026-08-23 17:38:32 +00:00
funman300 e18304d365 fix(fifa17): serve the full kit identity triple so the selector can match 
Operator report: selecting a kit in the pre-match selector gives "This kit is
currently locked. To unlock and use it, please go to the football club
catalogue."

Root cause, from static RE of the UNPACKED CardsDLL. CardsDLL registers a kit
provider into the FIFA engine (singleton FUN_1800338f0, vtable 0x1801f1d68):

  slot +0x08 FUN_180033770  enumerate kits for a team
  slot +0x10 sub_180033430  describe one kit   <- the lock gate

The describe function decodes a packed kit id into (teamid, year, slot) and
compares it against the club's ACTIVE HOME and ACTIVE AWAY triples. On a match
it writes NAME/TYPE (and, for historical kits, LOCKED). On no match it writes
NOTHING AT ALL and the descriptor falls through to the engine's own default,
which is where the locked-catalogue message comes from.

The active triple is 100% server-driven. FUN_1801c26d0 -> FUN_1800d73d0 scans
club items for cardtype 7 + cardsubtypeid 9 + itemState 101/102, then reads:

  teamid    <- item+0x94   (atom 0x306)   we were sending this
  year      <- item+0xba   (atom 0x389)   WE WERE NOT SENDING THIS
  slot      <- item+0xb8   (category)     WE WERE NOT SENDING THIS
               category 2 -> slot 0 home, 3 -> slot 1 away, 5 -> slot 3 third

So we shipped kits carrying only teamid, and the triple could never match.

fifa17-recon/data/club_items.json already has category and year per kit
resourceId (1482 kits; category {2:740, 3:654, 5:88}; 85 historical years), so
this is carried through the catalog rather than invented: Fifa17CardIdentity
gains category/year, Fifa17KitIdentity carries them, and shape_club_item emits
them for KIT_SUBTYPE only. Badges and stadiums deliberately do not gain the
fields - the slot mapping is kit-specific, and sending a family a field its
resolver does not read is how this project previously froze the client.

Also corrects the Vault note: item+0xba is `year`, not `kittype`. The side comes
from itemState 101/102 and the slot from category.

Two things this does NOT fix, both client-owned and recorded rather than
guessed:
  - the runtime teamkits clone into FUT club 130000 (the kit ART) is gated on
    item+0x60 == 4, and +0x60 has no wire atom at all: the deserialiser
    unconditionally zeroes it, the only CMP against 4 in the whole DLL is
    0x1801c34f1, and a live probe measured it as 1 for players / 0 for staff,
    never 4. The existing lib.rs claim that a server can never produce 4 is
    CONFIRMED, though its stated reason was a live observation rather than the
    real one (no wire atom exists).
  - whether a year==0 kit needs an explicit LOCKED write is UNKNOWN: CardsDLL
    only writes LOCKED for year != 0, and the engine's default for an untouched
    descriptor is in Denuvo-packed FIFA17.exe.
 2026-08-23 04:30:19 +00:00
funman300 8614acff57 chore: bump openfut-core (one-match training expiry in the match transaction) 2026-08-23 02:58:36 +00:00
funman300 3ff09ae62c chore: bump openfut-launcher (config BOM tolerance + corrupt-config quarantine) 2026-08-23 02:06:39 +00:00
funman300 34be38260d chore: bump openfut-launcher to 9ba88c7 (roster socket redirect) 
Records the submodule commit carrying ea_ports::FIFA17_ROSTER, which the
version.dll build deployed to the Windows client is built from.
 2026-08-23 01:58:19 +00:00
funman300 1e0124c197 hook: redirect the FIFA 17 roster dial in-process, drop the DNS workaround 
The client fetches the roster from the URL our own Blaze hands it,
https://winter15.gosredirector.ea.com:8081/fifa17/fut/rosterupdate.xml, and
ProtoSSL verifies that certificate by dNSName only. An IP-addressed roster host
is refused even with IP Address:10.10.0.120 in the SANs (retested on Windows
2026-08-23), so the hostname has to survive into SNI while the connection lands
on us.

The hook log showed the dial was ALREADY being intercepted:

    connect_hook: call 20.51.153.159:8081   (octets logged reversed)

It simply was not rewritten, because 8081 was not in the EA port table. So this
is a table entry, not new hook surface: ea_ports::FIFA17_ROSTER makes the
existing connect/WSAConnect/ConnectEx detour rewrite the destination while
leaving the URL untouched, and the certificate still validates.

That removes the scoped DNS responder and the client NRPT rule from the normal
path. scoped-dns.py stays as the documented contingency for EA withdrawing the
public record, which is the one dependency this cannot remove: the name must
still resolve to something for connect() to be reached at all.

roster_port is accepted in openfut.cfg but written only when non-default. The
parser rejects unknown keys, so emitting it unconditionally would make every
already-deployed hook reject the file and install NO redirect, breaking the game
rather than degrading.

Also corrects two documented claims that are false on the real machine:
elevation comes from the shortcuts' RunAsAdmin bit, not from an AppCompatFlags
RUNASADMIN entry (there is none), and hook_dll_path must point at a source copy
rather than the deployed version.dll it is copied onto.
 2026-08-23 01:57:46 +00:00
funman300 286a44461d tools/windows: scoped DNS resolver for the FIFA 17 roster hostname 
FIFA 17's ProtoSSL verifies the roster certificate by dNSName only, so the
client must reach the roster as winter15.gosredirector.ea.com. Retested on
Windows 2026-08-23: an IP-addressed roster host is refused even though the
certificate carries IP Address:10.10.0.120 as a SAN.

Public DNS points that name at EA's dead 159.153.51.20, so the client has to
resolve it to us. scoped-dns.py pins exactly that one name and forwards every
other query upstream verbatim, so a client pointed at it cannot lose general
resolution -- verified against www.microsoft.com, github.com and
www.msftconnecttest.com.

Paired with a Windows NRPT rule rather than a hosts entry: per-name, auditable
via Get-DnsClientNrptRule, and revertible in one command. A hosts edit on this
machine had previously taken its whole internet down.
 2026-08-23 01:34:13 +00:00
funman300 8c353c6c66 chore: bump openfut-core (training replace + all-six card) 2026-08-22 23:33:44 +00:00
funman300 3a038fe406 feat(fifa17): apply the rare all-six training card 
Passes a null attribute slot for the rare card -- Core reads absence as
"every slot", so sending 0 would silently train pace alone -- and declares
the per-family ceiling rather than a single constant.

Tests pin the null-slot serialisation, both ceilings, and that all 36
single-attribute plus all 6 rare cards resolve.
 2026-08-22 23:33:43 +00:00
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.
 2026-08-22 23:33:43 +00:00
funman300 a9bac8be8e chore: bump openfut-core to a45155e (attribute training effect) 2026-08-22 22:59:46 +00:00
funman300 3c28b0d1af feat(fifa17): apply training cards, and project trained attributes 
Opens the 409 `apply_effect_unproven` gate for attribute training, the
second family after contracts to have its effect settled rather than merely
its magnitude.

`ApplyEffect` replaces the single-family `AddContractMatches` struct: Core
dispatches on `kind`, so an unproven family must be impossible to express,
not merely discouraged. The shared half of an apply -- the exactly-once key,
Core's transaction, the error mapping and the client's payload -- is now one
`finish_consumable_apply`, so a new family cannot quietly acquire its own
idempotency format or its own success shape.

Two refusals are training-specific and both prevent silent corruption rather
than merely being tidy: a non-player target has no attributes to write, and
a cross-class target would train a different attribute from the one printed
on the card, because a keeper's slots mean DIV/HAN/KIC/REF/SPD/POS where an
outfielder's mean PAC/SHO/PAS/DRI/DEF/PHY.

`attributeList` now prefers Core's `effective_attributes` and only falls
back to the immutable definition when Core does not send them -- reading the
definition regardless would silently drop every applied training off the
card the client draws.

Tests pin the verb split on `item/resource/<rid>` (POST applies, PUT stays
quick-sell, GET is not an economy route at all), the digit guard, the exact
JSON Core deserialises for both effects, and that no shipped training card
exceeds the ceiling the host declares to Core.
 2026-08-22 22:59:46 +00:00
funman300 4936654f84 feat(fifa17): map training subtypes to attribute slots 
Which attribute a FIFA 17 training card trains is recoverable after all --
not from a table, but from the client's own dispatch: `FUN_18013f4d0`
derives a consumable's whole presentation from `cardsubtypeid` and writes an
attribute selector to `rec+0xbc`. Paired with `fcc_trainingcards.amount`
(TABLE_PROVEN, matching the wire 8/8), that settles both halves of the
effect for all 36 attribute training cards -- 12 families x 5/10/15, 18
goalkeeper and 18 outfield.

The subtype order is NOT the slot order: 54 is SPEED at slot 4 while 56 is
REFLEXES at slot 3, and 65 is HEADING at slot 5 while 66 is DEFENDING at
slot 4. Reading them sequentially trains a different stat from the one on
the card, invisibly, so the table is explicit and a test pins those four.

The two SQUAD training cards (57, 67) share the table and the client's
training UI bucket but are the only ones whose single-target byte is 0: they
act on a squad and move fitness, not an attribute. They resolve to None and
fail closed rather than being mistaken for a +3 attribute card.

A keeper's six slots mean DIV/HAN/KIC/REF/SPD/POS and an outfielder's mean
PAC/SHO/PAS/DRI/DEF/PHY -- same numbers, different attributes -- so the
class gate is not cosmetic.
 2026-08-22 22:59:46 +00:00
funman300 4156dc5810 ops(systemd): record unattended proof of post-boot recovery 
The reboot-survival gate is a test no operator can stand inside: the machine
under test is the machine running the session. So the machine records its own
recovery.

openfut-boot-evidence.service polls until the anchor, Core and host agree on
a namespace (or a 180s deadline expires), then writes a JSON file with the
boot id, anchor/Core/host pids and netns inodes, unit states, restart counts,
whether the reconciler had to act this boot, mount count, four non-mutating
probes, route ownership, and the full economy snapshot — plus the journal for
the boot so ordering is read from real timestamps rather than inferred from
unit dependencies.

It observes only; it never starts, stops or repairs anything, and carries no
Requires= or ordering that anything else waits on, so it cannot affect the
boot it is measuring. If the chain is broken the file says so, which is the
point.

Polling rather than a fixed sleep means a boot-time reconcile retry is
recorded as "settled late" rather than as a failure.
 2026-08-22 21:38:28 +00:00
funman300 fc1fdcc5ab ops(systemd): exact mount match in status, add detached rollback script 
Two things surfaced by the production promotion.

`status` counted namespace mounts with an unanchored grep, so on production
"run/netns/openfut" also matched "openfut-staging" and reported a phantom
"2 = leaked stack" against a perfectly healthy host. A status command that
invents a fault is the same class of bug as a unit that reports active while
serving nobody, so it is fixed with an exact mount-point match. The bind and
reconcile logic is untouched; it always umounted an exact path.

openfut-rollback-detached.sh makes the documented rollback executable rather
than a paragraph in a runbook: it removes supervision, resolves the anchor's
CURRENT pid from Docker, and relaunches the incumbent detached pair with the
environment replayed from the captured env.json. --dry-run prints the exact
commands and touches nothing, which is how it was validated while production
was still being served by the processes it would restore.
 2026-08-22 21:28:21 +00:00
funman300 1e8d46b258 ops(systemd): follow the anchor container's netns across recreation 
Recreating the Docker anchor left the supervised Core and host stranded in
the dead namespace while systemd still reported them active — serving
nobody, invisible to any monitoring that trusts unit state. Reproduced on
staging: netns 4026539938 -> 4026540033, both pids unchanged in the old
one, both units "active", traffic ConnectionResetError.

There is no systemd-native edge signal to bind to. Containers do appear as
units, but the scope name embeds the container ID (docker-<id>.scope), which
changes on every recreate, so BindsTo= has no stable target;
NetworkNamespacePath= resolves once at start; a .path unit on /run/netns
would watch the file this tooling maintains. So: a level-triggered reconcile
on a 10s timer, comparing the namespace the services are ACTUALLY in against
the anchor's CURRENT one, acting only on a real difference. That cannot miss
an event while the watcher restarts or dockerd is down, and needs no
debounce — a burst of three recreations produced exactly one rebind. The
trigger stays separable: a docker-events unit could invoke the same script.

Anchor absent stops the dependants rather than falling back to host
networking; docker unavailable logs once and retries on the next tick.

Two defects found while testing and fixed here:
- mount --bind STACKS when the old mount is busy, silently leaking nsfs
  entries; the bind helper now drains stale mounts in a loop.
- reconcile must stop -> rebind -> start, not rebind -> restart: a running
  service holds the old namespace open and makes the umount fail busy.

Staging also gained a faithful anchor container so the reproduction is
structural rather than mocked. Economy state was byte-identical across every
lifecycle test. Production units are templates only and remain uninstalled.
 2026-08-22 21:14:23 +00:00
funman300 8ae432223a ops: systemd supervision for Core and the FIFA17 host (staging-proven) 
Replaces the detached `setsid nohup … nsenter …` launch, which had no restart
policy, no boot persistence and no supervisor-visible logs. Staging units are
installed and proven; production units are TEMPLATES and are not installed.

Three decisions, each measured rather than assumed:

* `Wants=`, not `Requires=`, from host to Core. With `Requires`, stopping Core
  stopped the host AND a later Core start did not bring it back -- a routine
  Core restart would leave the client with no server. With `Wants` the host
  survives a Core outage, answers 503 core_unavailable, never falls back to
  Python, and resumes the moment Core returns with no intervention. Both halves
  tested.
* Readiness is a bounded ExecStartPre TCP gate, because ordering proves nothing
  about readiness and Type=exec only proves the binary exec'd. Core binds its
  listener after migrations and content load, so "port open" is a real signal.
  The gate FAILS rather than blocking: a host that waits forever looks healthy
  while serving nobody.
* The netns is resolved by container NAME every start. The container is
  restart=unless-stopped and its netns inode CHANGES on restart (measured:
  4026539938 -> 4026540033), so a hardcoded pid is wrong by construction and
  anything left in the old namespace serves nobody. Proven equivalent to today's
  nsenter against a scratch container, never production's namespace.

`systemd-analyze verify` caught two real defects before deployment:
StartLimitIntervalSec/StartLimitBurst sat in [Service], where systemd 252
silently ignores them, so the crash-loop ceiling was not taking effect; and a
Documentation URL containing %20 parsed as a specifier. Both fixed and the
effective properties re-confirmed from the running units.

Staging evidence: Core-first ordering, host refused when Core is absent or
merely not listening, outage survival, automatic recovery, restart, graceful
stop with no strays, boot simulated via multi-user.target, 3x SIGKILL contained
at ~5s spacing, journald logs, and economy state byte-identical throughout
(integrity ok, fk 0).
 2026-08-22 20:46:15 +00:00
funman300 9026220533 feat(fifa17): manager contracts, from a Core-owned staff tier 
ROOT CAUSE, one line. openfut-import-fifa17 emitted `"overall": 0` for every
non-player Core definition while `d.rating` already held EA's authoritative
`value` -- and the very next block wrote that same number correctly to the
adapter catalog. So the tier existed host-side but never reached Core:
Core overall 0 -> /collection effective_overall 0 -> CoreOwnedItem.rating 0 ->
tier_for_rating(0) = Bronze for a Gold (88) manager. That silent mis-grant is
exactly what the 409 was protecting against, so the refusal was correct.

The emitter now also writes `source_rating`, keeping `overall` at 0. Regenerating
the production pack changes exactly 18 entries and exactly one field each
(source_rating None -> value); same 1710 ids, same fingerprint 28c333f1e833338a.

WHY value IS the tier source, and why the thresholds are the player ladder:
LIVE_PROVEN, not inferred. The client re-rates staff from its own
managercards/*coachcards/physiocards by carddbid and applies discard_level's
65/75 ladder; coach_probe/discard_probe agree 4/4 (manager value 88 -> level 3,
coaches 66 -> level 2). The shipped coach tables corroborate: each family has
exactly 3 tiers x 2 rarities, and only 65/75 splits them 2/2/2.

Manager contracts stop refusing and now resolve the TARGET's tier from
Core-owned state. Still fail-closed everywhere it matters: a coach or physio is
`contract_target_not_a_manager` (only cardsubtypeid 4 is a manager), and a
manager Core carries no source_rating for is `manager_tier_unknown` rather than
a guessed tier. Core's own content_kind token is sent as target_kind, because
Core calls the squad manager `manager` while the catalog classifies it
`staff`+subtype 4.

NOT implemented, unchanged: STORED_MANAGER_BONUS and MATCH_CONTRACT_DECREMENT.
 2026-08-22 20:08:26 +00:00
funman300 f0c6dcf238 tooling: verified backup, state snapshot, retargetable apply validator 
Promotion prep for the contract-apply cutover, which unlike the quick-sell
promotion moves BOTH binaries and applies a schema migration.

fifa17-promotion-backup.py uses SQLite's online backup API, not cp. Production
runs WAL with a routinely uncheckpointed WAL (515 KB at capture time); copying
the main file alone is not atomic against a live writer and carries no
guarantee the WAL holds no newer committed state. Emits a checksummed backup, a
metadata record and a RESTORE-*.sh that removes the stale -wal/-shm BEFORE
restoring -- omit that and SQLite replays the old journal over the file you just
put back, resurrecting the state you were abandoning.

fifa17-promotion-snapshot.py is read-only (mode=ro) and counts EVERY table
rather than a hand-picked list, so a delta cannot hide in a table nobody thought
to name. It also fingerprints the ownership rows, catching a row silently
rewritten when counts alone would match.

fifa17-contract-apply-validate.py gains --host/--db so one tool serves staging,
the migration rehearsal and the production acceptance run. Defaults stay
staging: there is deliberately no production default, so a bare invocation
cannot touch production.
 2026-08-22 18:40:12 +00:00
funman300 6c97bc4e2b feat(fifa17): real player-contract consumable apply, replacing the probe 
POST /ut/game/fifa17/item/resource/<rid> {"apply":[{"id":N}]} now performs a
durable atomic contract application instead of falling through to Python.

THE RULE. grant = fcc_contractcards[card][tier(TARGET.rating)], then
min(99, contract + grant). The column is keyed on the TARGET's tier, NOT the
card's own -- all 36 cells of EA's shipped table match the published FIFA 17
matrix, and staging discriminates the two readings outright: a bronze-RARE
card on a rating-89 player granted 3 (the gold column), where the card-level
reading predicts 15.

No client binary reads fcc_contractcards -- a string scan of every .exe/.dll
in the install finds it referenced nowhere, and CardsDLL reads only 14 fcc_
tables (fcc_discardcoins among them, which is why quick-sell prices locally).
Consumable effects are server-authoritative, so EA's shipped table is the only
non-invented source and the client renders whatever we persist and re-serve.

The host computes the grant, Core owns the mutation -- the same split
quick-sell already uses (host prices via discard_value, Core performs
sell_item), and what migration 0027 means by "Core defines NO per-category
formula".

FAILS CLOSED, never 200-and-do-nothing: manager contracts 409 because staff
ratings are unimported so the target tier is unknowable; every other family
409 as unproven; batch 400; unresolvable operand 404. Core's deterministic
refusals pass through with their own status instead of collapsing to 503,
which would tell the client to retry a request that can never succeed.

`contract: 7` stops being a hardcode in shape_item/shape_staff_item and
becomes the fallback for an instance Core tracks no contract for. `fitness: 99`
is the same class of hardcode and is deliberately untouched.

CLEAN CUTOVER: Route::ConsumableApplyProbe, its handler, apply_probe_enabled,
the OPENFUT_FIFA17_APPLY_PROBE gate and both probe scripts are deleted. A
handler no classifier can reach is this repo's recurring defect class, and the
new economy arm preempts the probe. fifa17-migration-rehearse.py also drove
the probe (spelled "apply probe", so an apply-probe grep missed it) and would
have eaten a card off the rehearsal profile; retargeted to a non-mutating
assertion.

Not implemented, on purpose: the stored-manager bonus (real mechanic, rule
appears in no shipped table -- guessing it would corrupt the proven part) and
contract decrement per match (nothing spends contracts yet).
 2026-08-22 18:23:22 +00:00
funman300 3c67fea074 feat(fifa17): serve the consumable quick-sell (PUT item/resource/<rid>) 
Fixing the display was only half of it. Quick-selling a consumable from the
repaired screen produced "There was a problem communicating with the FIFA
Ultimate Team servers", because the client's consumable quick-sell is a route
neither stack had ever served:

    PUT /ut/game/fifa17/item/resource/5003068     body_len=0

Live-captured on staging. That path now carries three verbs -- GET is the
definition lookup, POST applies the consumable (ApplyCardByRes), PUT quick-sells
it -- and it is keyed by the stack's RESOURCE id, not an owned instance, unlike
the player quick-sell (DELETE item/<instanceId>).

This had to be Rust-owned rather than proxied: the Python oracle maps
item/resource method-agnostically to its definition route, so on production --
where the oracle is alive -- a PUT would return 200 with a definition list and
sell nothing, and the client would show a successful sale of a card the player
still owns.

Implementation reuses the retail-proven quick-sell path verbatim
(handle_quick_sell_path), so pricing comes from the same
ItemIdentityResolver::discard_value that stamps the number on the stack. Display
and payout are the same call; they cannot drift.

Two decisions, both documented in the code as decisions rather than discoveries:

  * ONE copy per request. The request carries no quantity, and the screen prices
    a CARD, so consuming a whole stack on one keypress would pay one card's
    price for N cards. Selling one is the conservative reading.
  * The copy sold is Core's first matching owned instance -- the same one whose
    wire id the consumables screen already published as the stack's `item`, so
    the player sells the card they were shown.

Verified against the running staging host:
    displays 38 -> PUT -> coins +38, owned -1, consumables -1, stack 2 -> 1
    replay sold the one remaining copy (+38, -1), no double credit
    exhausted -> 404 not_owned, coins +0, owned +0 (no phantom payment)

123 host tests (+1 locking all three verbs on the shared path, and that the bare
`item` PUT stays the pile move), clippy -D warnings clean, fmt clean.
 2026-08-22 17:02:14 +00:00
funman300 2a9507cb6a docs(re): consumable quick-sell is PUT item/resource, live-captured 2026-08-22 16:56:01 +00:00
funman300 5b8bee286c feat(ops): read-only interception preflight for OpenFUT endpoints 
During the Rust production cutover four stale openfut-switch nft rules were
still redirecting production-facing traffic to staging (42127->42227,
8081->8281, 8094->18094, 8099->18106). They matched `ip daddr 10.10.0.120`, so
every server-side probe via 127.0.0.1 or the container IP passed while the
CLIENT was refused. That cost a full false-negative acceptance round: a retail
quick-sell landed on staging while production sat untouched, and the launcher
reported the server "not answering".

The failure mode is mechanical, so the check is:

  * openfut-switch.sh status
  * nft rules on OpenFUT ports, split into REDIRECT (interception) and DNAT
    (docker publishing, expected -- reporting those as problems would train the
    reader to ignore the tool)
  * the actual point: loopback vs the ADVERTISED address per port. A redirect
    keyed on the LAN IP is invisible to loopback, which is exactly why the
    cutover probes all passed.

Verdict is CLEAN / INTERCEPTION_PRESENT with exit 0/1/2. Both branches
observed: it reports CLEAN now, and reported INTERCEPTION_PRESENT on a
loopback/advertised disagreement before :4216 was excluded.

:4216 is excluded from the verdict because LSX runs on the game machine --
compose publishes the port but OPENFUT_SERVERS omits lsx, so "published but not
served" is its normal state. It is still printed, marked as expected.

READ-ONLY by design: it never deletes a rule. Clearing interception stays a
deliberate operator act via `openfut-switch.sh off --name <id>`.

Run before production acceptance, client repoints, migrations and retail
protocol tests.
 2026-08-22 02:02:00 +00:00
funman300 ba19954ffb fix(fifa17): consumable stacks carry their real quick-sell value 
A production club displayed "Quick sell for 0 coins" for contract cards that
Core would have paid 3/13/32 for. The consumables stack wrapper hard-coded
discardValue (atom 0xd7) to 0.

The old rationale was that the client prices the card itself, the way it does
when we omit discardValue from an item. That is true of the ITEM record and not
of the STACK, and the evidence separates them cleanly:

  * item+0x38 non-zero makes the client SKIP its local computation and show our
    number -- re-proven on the live production client, 16/16 resident cards
    "SERVER-SHOWN (local calc skipped)", including the acceptance card
    235066 -> 40.
  * We send no discardValue inside a consumable's item, so +0x38 is 0 and the
    local computation DOES run and fills +0x3c correctly -- Milestone 1 measured
    3/3/32/38 there, matching this table.
  * The screen still showed 0. So the screen is not reading the item's computed
    +0x3c; it reads the stack's atom 0xd7, which we were sending as 0.

So the number belongs on the stack, and it is the SAME
discard::value_for_definition that computes the payout -- one source, so the
screen and the wallet cannot disagree. Per CARD, not per stack: FUT prices a
card and the stack is only a quantity badge over identical copies. An
unpriceable definition stays 0 rather than inventing a number.

Verified on staging across every populated family, 16/16 stacks shown ==
recovered, none zero:
  contracts 32/3/13 · healing 32/3 · training 3/13/34 · playstyle 38/38/38
  · position 36/38/38/38/38

Two tests lock it: the payout equality (with the exact 3/13/32 the production
club would have been shortchanged on) and per-card-not-per-stack pricing for a
collapsed count=3 stack.

No payout logic changed, no taxonomy change, no ownership change, no Python.
250 adapter tests, 122 host, clippy -D warnings clean, fmt clean.
 2026-08-22 02:00:40 +00:00
funman300 88b4cad780 test(fifa17): migration invariant capture and rehearsal harness 
fifa17-migration-invariants.py  Pre/post invariants across every domain the
    migration authorization names: coins, ownership (+kind histogram, distinct
    definitions, chemistry styles, loans, position overrides), squads,
    managers, staff, consumables, club items, transfer state (market_listings),
    packs, SBC, match history, plus integrity_check and foreign_key_check.
    Table names are the REAL schema, not guessed: transfer state lives in
    market_listings (29 rows in production), the FIFA17 opaque squad blob in
    game_entity_ext.

fifa17-migration-rehearse.py    Serves a migrated COPY with the candidate Rust
    stack on isolated ports and validates the wire surface: club discardValue
    is table-derived, squad projects, consumable categories populate, and the
    apply probe is OFF (502 upstream-unavailable rather than a diagnostic ack).

Both are read-only against production: the rehearsal operates on a copy under
/home/alex/openfut-migration/, and nothing under openfut-promotion/state is
opened.

Evidence from the 2026-08-22 rehearsal is written up in the Vault runbook
"FIFA17 Rust Production Migration (rehearsed)".
 2026-08-22 01:15:45 +00:00
funman300 a4c6aeed49 docs(re): ApplyCardByRes post-ACK protocol is outcome B, live-proven 2026-08-22 01:07:54 +00:00
funman300 97498c560e docs(re): refute the contract:7 effect source; record the competing development reading 
Two corrections found while trying to close the effect boundary statically.

1. `contract: 7` IS OUR OWN PLACEHOLDER. fut_store.py:232's generic _item()
   factory -- which builds every item the oracle serves -- hardcodes
   playStyle 250 / contract 7 / fitness 99 on players and consumables alike. The
   staging GK reads back exactly those three constants. So the production
   catalog's contract:7 for resource 5001004 is an oracle placeholder
   round-tripped through an observed profile, not an EA value. Its status is not
   INFERRED, it is KNOWN-BOGUS as a source. Had the effect been implemented on
   it, it would have been a fabricated game rule wearing observed-data clothing.

2. fcc_contractcards is NOT amount-less. An earlier note here claimed it "has no
   amount column, so this value comes from observed data". It has 13 rows with
   gold/silver/bronze/rating, 6 player + 6 manager paired by rating plus a
   99/99/99 special. The sibling fcc_healingcards shares every column except
   that it carries a single `amount`, which argues the differing columns ARE the
   effect payload (per target tier). Against that: the values are non-monotonic
   across tiers, which suits weights better than amounts; and no column of
   5001004 is 7, so neither reading explains the placeholder.

   The reader that would settle amount-vs-weight is in FIFA17.exe, not CardsDLL
   (the table and column literals are absent from the DLL), so this stays
   EFFECT_UNKNOWN rather than being guessed.

Also records, in content_taxonomy.rs, the competing reading of `development`:
fut_consumables.py's TYPE_CATEGORIES groups it as card-categories {6,7,8,9,10}
(modifiers only), explicitly flagged there as inferred from UI-bucket names and
never observed on the wire. Different enum space from the CONSUMABLE_TYPE switch
that actually emits the segment, and the switch gives formation/position/
playStyle/managerLeagueModifier their own segments rather than folding them into
development -- so the unfiltered reading is better supported, but it is still a
reading and the doc now says so instead of sounding settled.

248 adapter tests, fmt clean. No behaviour change.
 2026-08-22 01:01:47 +00:00
funman300 8cb2a0f9c6 test(fifa17): smoke-test the apply probe and prove the gate fails closed 
Unit tests cover classification and body parsing; they do not prove the running
host behaves. These three scripts exercise the real service, and they found
nothing broken but make the two load-bearing claims checkable:

fifa17-apply-snapshot.py   Core truth around an apply: coins, owned rows, kind
                           histogram, the source stack's copy count, and the
                           target's mutable fields (contract/fitness/playStyle/
                           training/injury). Coins and ownership come from the
                           staging DB, not the wire, so the check cannot be
                           satisfied by a projection bug.

fifa17-apply-probe-smoke.py  Replays the EXACT captured request plus the edges,
                           against the live host, no client needed:
                             1. {"apply":[{"id":100000003}]} -> 200 {"itemData":[]}
                                source=Consumable subtype=201 copies=1,
                                target=fifa17_200389 rating=87
                             2. two targets            -> 400 apply_batch_unsupported
                             3. unknown target wire id -> 200 UNRESOLVED_WIRE_ID
                             4. unowned source         -> 200 NOT_OWNED
                           then re-snapshots: Core identical after all four.

fifa17-apply-gate-off.py   The production-safety claim. With APPLY_PROBE unset
                           the same request must produce the pre-probe
                           behaviour, and does: no apply-probe line, three
                           passthrough lines, 502 into the dead upstream, Core
                           unchanged. Verified by restarting staging without the
                           flag -- an assertion about failing closed is worth
                           nothing unless the closed path is executed.

Nothing here writes to production; snapshot reads the staging DB read-only.
 2026-08-22 00:54:24 +00:00
funman300 9f445904a5 docs(re): record the reversed ApplyCardByRes success contract and the nine-segment consumables vocabulary 2026-08-22 00:50:47 +00:00
funman300 ce5d4204ac feat(host): staging-only consumable-apply probe; reverse the success contract 
Claims POST ut/<sku>/item/resource/<resourceId> -- the consumable apply captured
live 2026-08-21 -- behind OPENFUT_FIFA17_APPLY_PROBE=1, default OFF. With the
gate off the route takes the extracted `passthrough` method, i.e. byte-for-byte
the behaviour that existed before this commit, so production cannot serve a
diagnostic even if the route is reached.

The handler is NON-AUTHORITATIVE BY CONSTRUCTION: it consumes no source card,
mutates no target, touches no contract/fitness/chemistry/training/injury state,
mints no coins and changes no ownership. It exists only to observe the client's
success path, because the EFFECT of a consumable is still unreversed and
implementing one on an inferred value is not acceptable.

RESPONSE SHAPE, from static RE rather than convenience (the brief was explicit
that `{}` must not be chosen because it is easy):

  * The apply completion handler is CardsDLL 0x180035520. It does
    `mov ecx,[rdx+0x1c]; test ecx,ecx; jne FAILURE`, raising
    EVENT_CARDS_APPLY_CARD_SUCCESS (0x1801f37f0) on zero and
    EVENT_CARDS_APPLY_CARD_FAILURE (0x1801f3810) otherwise. It tests exactly one
    field -- the transport code -- and never inspects the body.
  * That is materially different from the MOVE ack (0x180128600), which builds
    per-item verdict records and reports FAILURE when the vector is EMPTY. The
    `{}`-is-broken precedent does not transfer.
  * The response object's constructor (0x1800a4ce0) initialises its record vector
    (+0x50/+0x58/+0x60, 0x20-byte elements) EMPTY, so an empty parse result is a
    legal state here, and the destructor (0x1800682b0) frees it accordingly.
  * The legacy oracle routes `item/resource` method-agnostically to defs_route,
    so historically this path answered with an `itemData` OBJECT.

`{"itemData":[]}` is the smallest candidate consistent with all four, and it is
labelled a PROBE, not a proven contract.

`apply` is an array, but only len==1 has ever been observed, so a multi-target
request is logged and refused (400 apply_batch_unsupported) rather than given
invented batch semantics.

Operands are identified READ-ONLY for the capture: the source by Core card id
(`<sku>_<resourceId>`, no new resolver method for a probe) with a copy count, the
target by reversing the wire id through the identity store -- never a guess,
`UNRESOLVED_WIRE_ID` when unknown.

Also records the reversed protocol and the `development` finding in
CLIENT_ROUTE_SURFACE.md.

122 host tests (+2: the verb/resource-id classification boundary, and target
parsing incl. the exact captured bytes). clippy and fmt clean.
 2026-08-22 00:49:23 +00:00
funman300 6ca735749e fix(fifa17): serve the development and formation consumable categories 
The live client asked for `club/consumables/development` and got an empty
screen: `consumable_families_for_category` had no arm for it. Tracing that
segment recovered the client's OWN category vocabulary, and it is nine segments,
not the seven this file assumed.

CardsDLL, live 2026-08-22: the literal table at 0x1801f5a38 (under
MyClubAdapterClass / CONSUMABLE_TYPE) and the switch at 0x180048820, which
indexes by `enum + 1` through the byte table at 0x180048a90 into the case table
at 0x180048a6c:

    enum -1 (unset)      -> development
    enum 1, 2            -> contracts
    enum 3               -> healing
    enum 4               -> fitness
    enum 16              -> formation
    enum 17              -> position
    enum 23              -> playStyle
    enum 24              -> managerLeagueModifier
    enum 0, 5..15, 18..22 -> training (switch default)

Two consequences:

1. `formation` HAS a segment (enum 16). This file claimed the two formation
   modifier families "have NO group code, so no segment can reach them -- that is
   the client's own gap, not an omission here", and a test asserted it. Both were
   wrong, and wrong in the direction that hides a server bug: it was our gap.
   `formation` now maps to manager_formation_mod + formation_mod, so all
   THIRTEEN families are reachable instead of eleven.

2. `development` is the type-UNSET bucket -- index 0 of a table indexed by
   `enum + 1` -- i.e. no type filter. It is therefore the unfiltered view and
   maps to every family via ALL_CONSUMABLE_FAMILIES. That is consistent rather
   than overlapping by accident: the eight TYPED segments already reach all
   thirteen families exactly once, so there is no family for `development` to
   own privately.

The partition test now asserts the eight typed segments cover all thirteen
families with no duplicates, and that `development` is exactly their union, so a
family added to the taxonomy cannot silently vanish from the unfiltered screen.
Ownership and classification are untouched; this is projection only.

248 adapter tests, clippy and fmt clean.
 2026-08-22 00:49:04 +00:00
funman300 739228efdb feat(host): capture unclaimed request bodies; record the consumable-apply wire 
Milestone 2: the consumable-apply protocol is now LIVE_PROVEN.

Adds opt-in passthrough BODY logging (OPENFUT_FIFA17_LOG_PASSTHROUGH_BODY=1,
default off, capped at 512 bytes) because a body is what names an unknown
mutation's operands, while also being the one place a request could carry
something that should not reach a log. Staging probe only.

With it, one operator apply captured the whole thing:

    POST /ut/game/fifa17/item/resource/5001004
    {"apply":[{"id":100000003}]}

  source consumable : resource 5001004 (player contract, subtype 201) -- in the PATH
  target item(s)    : wire 100000003 (squad slot 0 GK, resourceId 200389) -- body apply[]
  verb              : POST

There is NO /apply endpoint, exactly as the static route work concluded. The
apply re-uses `ut/%s/item/resource`, which we already serve for GET (definition
lookup); the POST verb on that path is the mutation and nothing claimed it. This
is the wire form of the ApplyCardByRes task (id 0x0e), which is why the source is
a definition id rather than an instance id. `apply` is an array, so one resource
can name several targets.

Fail-closed verified: with the upstream dead the request 502s and Core is left
exactly unchanged -- coins 29,843,976, owned 1993, consumables 17, source card
still owned. No partial mutation.

NOT implemented: the response shape is unobserved and the EFFECT is unreversed.
Our catalog carries contract:7 for 5001004, documented as the matches granted,
but that is observed profile data (INFERRED), so no effect is written on it.

Bonus, caught by the same logging: the client really does request
`club/consumables/development`, which has no arm in
consumable_families_for_category and is served empty. Recorded, not guessed.

Host 120 lib tests, fmt clean.
 2026-08-22 00:23:15 +00:00
funman300 db5fb37980 feat(host): name unclaimed requests, and record the FUT task vocabulary 
Milestone 2 groundwork.

The passthrough arm forwarded to Python without ever recording WHAT was asked
for, so on staging -- where the upstream is deliberately dead -- an unhandled
request produced an anonymous 502. It now logs method, path and body length
before forwarding, which is how the next unclaimed route gets identified:

  utas-host owner=PYTHON route=passthrough method=GET path=/ut/... body_len=0

Also records the FUT TASK vocabulary read out of the live client. The client
drives UTAS through named tasks held in a CardsDLL .rdata table of 0x20-byte
MixedCase/UPPERCASE slots, with a .data descriptor table giving each a task id:

  ApplyCard 0x0d, ApplyCardByRes 0x0e, ConsumeCard, ActivateCard, AssingCard(sic),
  MoveCard, MoveCardByRes, SwapCard, DiscardCard, DiscardCardByRes, ViewCards, ...

So consumable application IS a first-class client action even though the route
table contains no /apply endpoint -- it must ride an existing route. The
descriptor's function pointer is a `mov [rip+flag], cl; ret` setter, not a
request builder, so the request is assembled elsewhere keyed by task id; that is
cheaper to answer with one live capture than with more static tracing.

Search tooling carries mandatory positive controls (tradePile, ut/%s/item, squad
-- all FOUND), so the "no /apply route" result is a valid negative rather than a
failed scan.

Host 120 lib tests, fmt and clippy clean.
 2026-08-22 00:14:11 +00:00
funman300 0a7c4e129c docs(fifa17): record discard economy validation evidence and impact 
Adds scripts/fifa17-discard-impact.py (owned-instance economic impact, computed
from the shipped implementation's matrix -- informational, never a reason to
alter a value) and records the measured results.

Owned club, 1993 instances: legacy 1,820,700 -> recovered 19,128,031 = 10.51x.
Players 10.53x, manager 1.88x, consumables 0.19x (the ladder overpaid them ~5x),
staff 0.24x, club items 900 -> 0.
 2026-08-21 23:59:35 +00:00
funman300 a96d06dbc0 test(fifa17): validate discard payouts, replay, concurrency and persistence 
Adds two staging-only harnesses and records the results.

scripts/fifa17-discard-validate.py drives the REAL Rust/Core quick-sell path for
a fixture spanning every quick-sell-relevant category, and checks each against
the authoritative table value emitted by the discard_matrix example (i.e. the
shipped implementation, not a reimplementation). Per item it asserts the payout
is exact, the instance is removed exactly once, and a REPLAY of the same request
grants nothing and resurrects nothing.

Results with OPENFUT_FIFA17_DISCARD_TABLE=1 on the real 1993-item club:

  players     6/6 exact   752 .. 74,400 (rareflag 1,3,4,5,6,11,21,22,23,24)
  staff       2/2 exact   36 (gk coach, fitness coach)
  consumables 4/4 exact   3, 3, 32, 38
  club item   1/1 exact   0  (kit -- and 0 is what the client displays)
  TOTAL      12/12 exact, 0 replay grants

  wire discardValue == expected == actual payout for every player, so what the
  client is shown and what Core credits are the same number by construction.

Concurrency: 4 simultaneous DELETEs on one wire id -> removed exactly 1, paid
exactly once (23,280).

scripts/fifa17-restart-persistence.py restarts Core and host IN PLACE with their
own environment rather than via the bring-up script, because `up` re-seeds the
club and would mask a persistence failure. It refuses to signal any process
outside the staging root -- production runs as another user and is skipped
explicitly. Result across SIGTERM + respawn of both: coins 29,967,428, owned
1978, players 1958 -> PERSISTED EXACTLY.

Production untouched; staging only, flag set only in staging.
 2026-08-21 23:56:24 +00:00
funman300 06d94bb37d fix(fifa17): club items are zero-value, not a fallback to an invented price 
`value_for_definition` declined for anything non-player without a catalog rating,
which sent club items into the legacy ladder and paid an invented 150 each.

That is wrong, and the client says so. `shape_club_item` sends neither `rating`
nor `discardValue`, and cardtype 7/9 are NOT re-rated by the client (the merge
jump table sends them to the shared tail), so the client computes for itself from
record +0xb4 == 0: level 1, `0 * price / 100` == 0. It DISPLAYS 0. Paying 150
invents value the player was never shown.

Move the decline boundary onto the real distinction, which is `client_rerates`:

  * NOT re-rated (cardtypes 1, 6, 7, 8, 9) -> the server's rating is what the
    client prices with, so Core's value is authoritative even at 0.
  * RE-RATED (2, 3, 4, 5, 10 -- the staff families) -> the client substitutes its
    own database value, so without a catalog rating we genuinely cannot match it
    and must decline rather than guess.

Over the 1717-definition corpus this takes "declined -> legacy" from 6 to ZERO:
every definition is now priced by the one authoritative table and no generic
fallback is reachable in the current corpus. The six club items price at exactly
0; staff and consumables are unchanged.

Adapter 248 lib, host 120 lib, fmt and clippy clean.
 2026-08-21 23:53:14 +00:00
funman300 f371349dd5 refactor(fifa17): one authoritative discard implementation + corpus matrix 
The pricing DECISION (which rating to trust, when to decline) lived in the host
while the TABLE lived in the adapter, so FIFA semantics were split across two
crates and no single function could be pointed at as authoritative.

Move the decision into the adapter as `discard::value_for_definition(subtype,
rareflag, catalog_rating, core_rating) -> Option<i64>` and have the host call it.
Its three tests move with it. There is now exactly one table implementation, one
decision point (`ItemIdentityResolver::discard_value`), and one deliberately
retained rollback ladder (`legacy_discard_value`).

Add `examples/discard_matrix.rs`, which audits an entire FIFA17 corpus using the
SHIPPED implementation rather than reimplementing the formula, so the matrix
cannot drift from what the server pays. Over the current 1717-definition corpus:

  declined -> legacy : 6   (badge, ball, kit x2, misc, stadium -- no catalog rating)
  priced zero        : 0
  negative           : 0
  implausible        : 0
  rating boundaries  : OK (1/2/3 at <65 / 65..74 / >=75)

Also re-verified both numeric cores against the LIVE client rather than trusting
the earlier notes:

  level  0x180141e8a  cmp al,0x4b -> 3 ; cmp al,0x41 ; sbb/add 2 -> 2 else 1
  value  0x180141119  imul rating*price ; /100 via 0x51eb851f ; imul 0x64 ; sub ;
                      cmp remainder,0x32 ; jl/inc   == round-half-up

`(rating*price + 50)/100` is identical to that for non-negative inputs.

Adapter 247 lib, host 120 lib, fmt and clippy clean.
 2026-08-21 23:49:01 +00:00
funman300 fb38ee6087 fifa17: claim five routes whose handlers were already unreachable 
Read the client's COMPLETE UTAS route surface out of CardsDLL's .rdata in the
running process (new tools/url_template_probe.py) and probed every one against
staging, where the Python upstream is deliberately dead so anything the Rust host
does not own answers 502 instead of being silently proxied.

That found five routes whose handlers already existed and were dead code because
`classify` never produced their Route -- the same defect as `season/list` and
`watchList`, whose fix comments are still in the file. This is the third and
fourth time:

  captcha        -> handle_static_ack, which already returns the oracle's exact
                    {encodedImg,sequence,sizeBeforeEncode}
  tfa            -> handle_static_ack, {}
  livemessage    -> handle_static_ack, {}
  activeMessage  -> handle_static_ack, {}
  tournament/user-> FeatureOffEmpty, {} == the oracle with FUT_MODES off
                    (tools/utas_server.py:1504); the client builds this literal
                    at CardsDLL 0x18021e540 and the bare `tournament` arm never
                    matched it

Route's own doc comment already claimed the first four as "Rust-owned
UNCONDITIONAL", so the documentation was wrong rather than the intent. All five
are byte-identical to the oracle, so claiming them is parity, not new behaviour.
Invisible in production because the upstream answers there.

Two tests pin the vocabularies so a handler cannot go unreachable a fifth time;
both are mutation-checked (removing the captcha arm fails the first).

Also documents the surface in docs/CLIENT_ROUTE_SURFACE.md, including the trap
that bit me repeatedly: an .rdata literal is a FRAGMENT, not a callable path.
`clientdata`, `purchasegroup`, `sbs/challenges`, `squadBuildingSets`, `club/items`
and `item` all looked unserved and are not. Only `squad/mode` is genuinely
unserved, and correctly so -- it is Draft-only, which is out of scope.

L5 finding: there is NO consumable-apply route anywhere in the binary. The only
owned-item mutations the client can express are PUT item (move/pile), DELETE
item/<id> and POST delete/item (quick sell), and PUT squad. So applying a
consumable is not a dedicated endpoint; L5/L6 must be pursued by capturing the
PUT item payload, not by implementing a route that does not exist.

Host 123 lib + 45 host_test, fmt and clippy clean. tournament/user, livemessage
and activeMessage verified 200 on staging (were 502).
 2026-08-21 23:28:29 +00:00
funman300 cd5983ecdd fifa17: cardtype 9 is unnameable -- measured, and the gap closes as a negative 
Serving owned balls (subtype 30), league logos (31) and fcc_misccards
(231/232/233/236) was the last projection gap. The open guess was that their
caption would come from `localizedName` on the wire, "probably", and they were
withheld out of caution.

Measured against the running client instead (new
tools/cardtype_dispatch_probe.py, read-only, reproducible, every step with a
positive control). They cannot be named at all:

  1. The merge jump table at rva 0x141eb4 is indexed cardtype-1 with 10 entries.
     Cardtypes 1..5 and 10 each get a DB-merge arm; cardtypes 6,7,8,9 ALL land on
     one shared tail at 0x180141e8a that runs no query and writes no name.
  2. `cmp [reg+0x4c], 9` (cardtype): ZERO sites in .text. For contrast, cardtype
     1 has 13 and cardtype 7 has 6.
  3. `cmp [reg+0x50], 30` and `..., 31` (cardsubtypeid -- the field that actually
     selects a club-item caption): ZERO sites each, while kit 9, stadium 10 and
     badge 11 all appear, which is the control. The only cardtype-9 subtypes
     present anywhere are the four misccards ids, and all four are one boolean
     predicate near 0x1801a72da that returns FALSE for them: an exclusion, not a
     resolver. That predicate is NOT identified and is not claimed to be.
  4. The cardtype-7 resolver is gated `cmp [rax+0x4c], 7` at 0x1800f6f04, so a
     cardtype-9 item never reaches it. Its jne path formats AWARD_LABEL_%i --
     the trophy path, not a fallback that would name a ball.

Nothing reads a localizedName for these subtypes, so sending one cannot become a
caption. Withholding them is a measured limit of the client, not caution, and no
server change can lift it.

CORRECTION: FUN_180119bd0 was recorded as "zero refs in CardsDLL -> almost
certainly an export, its caller is in FIFA17.exe". It is not an export. Its
address occurs exactly once in the whole process, at 0x18021c738 in CardsDLL's
own .rdata, and nothing in FIFA17.exe references it. It is virtual: vtable base
0x18021c2a0, slot +0x498, index 147 -- independently reproducing the recorded
"manager vtable slot +0x498" by a different method. Finding the boundary needs
the constructor-LEA trick; walking back over .text-pointing qwords runs 826 slots
through several adjacent vtables.

Bonus: the shared tail cardtypes 6-9 fall into IS the discard level ladder
(movzx [rdi+0xb4]; cmp 0x4b; cmp 0x41; store [rdi+0x54]), confirming
discard::discard_level instruction for instruction against the live client.

Adapter 244 tests, fmt clean.
 2026-08-21 23:10:44 +00:00
funman300 f97654af86 fifa17: give the staging manager the rating the client re-rates it to 
The bring-up mints a manager (neither club owns one, and FIFA refuses to start a
match without one). Its catalog entry carried nation/league/team read out of
managercards but not `value` or `rare`, so discard pricing declined for it and
fell back to the placeholder ladder: 150 paid against the 282 the client computes
for itself.

Carry managercards.value 88 and managercards.rare 1, from the same table and with
the same provenance as the fields already there. `rare` is not cosmetic -- it
selects the discard price column, which is the whole difference between 282 and
97.

Both are live-confirmed on the running client: coach_probe grades the manager
record HIT (so +0xb4 == value and +0x58 == rare) and discard_probe reads the
value it computed for itself at +0x3c as 282.

Verified on staging: the manager now quick-sells for exactly 282. With this, every
card the client prices for itself -- manager, GK coach, both fitness coaches --
is paid the number it displays.
 2026-08-21 22:55:01 +00:00
funman300 755f237f17 fifa17: carry the staff rating the client re-rates to, verified live 
Staff quick-sell could not be priced correctly: for cardtypes 2/3/4/5/10 the
client overwrites the rating and rare flag we send with values from its own card
database, and a staff wire record carries no rating, no rareflag and no
discardValue at all. The server had no way to know the displayed price from what
it sent, so pricing declined for staff and fell back to the placeholder ladder.

The missing input was read straight out of the running client (pid 6580), no UI
interaction required:

  * tools/coach_probe.py grades all four resident staff records HIT, which by
    construction requires record +0xb4 == the table's `value` and +0x58 == its
    `rare`. That settles `value`-is-the-rating, which was previously an inference
    and was deliberately not shipped on that basis.
  * tools/discard_probe.py (new) reads both discard slots -- +0x38, the value we
    sent, and +0x3c, the value the client computed for itself:

      1000509  sub 4  ct 2  rat 88  rare 1   sent 0   calc 282   predicted 282
      9000081  sub 6  ct 10 rat 66  rare 0   sent 0   calc  36   predicted  36
      3000083  sub 8  ct 4  rat 66  rare 0   sent 0   calc  36   predicted  36

    4 of 4 agree, 0 disagree. 36 on the value-66 GK coach was the exact falsifier
    written for this last commit.

Entities::enrich_staff now fills rating from `value` and rareflag from `rare` for
the five staff families, and the catalog emits the real rareflag instead of a
hardcoded 0 (it is not cosmetic -- it selects the discard price column, which is
why the rare-1 manager prices at 282 and a rare-0 coach at 36). Players and
consumables are untouched; their wire values are authoritative.

Verified on staging: a GK coach quick-sells for 36, not the 150 floor. The
catalog diff is exactly the two coach entries gaining rating 66; 1710 entries in
and out, nothing else changed.

The same probe shows what production does to PLAYERS today: every resident player
carries sent+38 = 1500, which suppresses the client's own computation, against a
real 688..752 for a gold rare and 72,800 / 74,400 for the two legends.

Still open, and not a discard problem: manager fifa17_1000509 is owned in Core
but has no catalog entry or definition (it reaches the client through the opaque
squad extension), so it declines to the ladder. That is definition coverage.

Importer 41 tests, fmt and clippy clean.
 2026-08-21 22:51:16 +00:00
funman300 49b18dd4ac fifa17: price quick-sell from the client's own discard table 
Quick-sell paid an invented five-tier rating ladder (its own comment said
"PLACEHOLDER, not EA-authentic"). It was blind to card type and rareflag, so a
94-rated TOTW special and a 94-rated gold common both sold for 1500, and every
non-player -- whose Core overall is 0 -- sold for the flat 150 floor. The ladder
existed in three places (adapter wire, host payout, an integration test's private
copy), which is a drift waiting to happen.

Add openfut-adapter-fifa17::fut::discard: the client's own fcc_discardcoins
table and its formula, round_half_up(rating * price / 100), keyed
(cardtype, level, rare). All of it is already reversed in
plan-2026-08-05-store-subsystem.md 3.6 and was verified there against 22 live
club items, 22 of 22 exact. DISCARD_COINS is generated from
fifa17-recon/data/tables/fcc_discardcoins.json and a test re-reads that file and
asserts row-for-row agreement, so the transcription cannot drift.

Collapse the three ladders into one method. ItemIdentityResolver::discard_value
both stamps the wire discardValue and prices the sale, because a non-zero
discardValue suppresses the client's local computation -- whatever is sent is
what the player is promised. The host's quick_sell_value is deleted and the
integration test's copy now calls the single implementation. A test with a
resolver double returning an impossible price proves the credit follows the wire;
reverting the payout to a ladder fails it.

Gated on OPENFUT_FIFA17_DISCARD_TABLE=1, default off: switching revalues the real
1991-item club 10.5x (1,820,400 -> 19,128,955 coins if wholly liquidated), up for
specials and DOWN for consumables, which the ladder overpaid 5.5x. That is an
operator's decision.

Staff decline to the ladder rather than pay 0: the client re-rates cardtypes
2/3/4/5/10 from its own DB and their rating is not imported. Deliberately not
guessed -- see the falsifier in the doc.

Verified on staging with the real club, both modes: flag off 1500 wire / 1500
paid; flag on 23760 wire / 23760 paid on an r99 rareflag-11 card (99*24000/100).
Consumables price from their catalog rating and agree with the client's own
computation. Adapter 244 lib tests, host 121 lib + 45 host_test, fmt and clippy
clean.
 2026-08-21 22:40:04 +00:00
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.
 2026-08-21 22:02:53 +00:00
funman300 d76c184cf1 fix(fifa17): make an unhandled club defId= list visible instead of silent 
A health sweep of all 51 host routes found no errors, but did find a gap against
the documented club grammar: the client may send a comma-joined `defId=` list
INSTEAD of the filter block, and `parse_club_query` handled nine parameters
without it. Today such a request is answered with the whole filtered club rather
than the requested definitions — silently.

Deliberately NOT implementing the filter. That grammar is single-source (one
decompile plus one live log line, and the log line carried no defId), so the
reading of "definition id" is unconfirmed against any observed request. Narrowing
on a wrong reading would turn "too many items" into "zero items", which is the
worse failure and the harder one to diagnose.

So the parameter is parsed and reported instead: the filter summary gains
`defId=<n>` and the host logs a NOTICE naming the ids and saying plainly that the
response was not narrowed. The first real occurrence is then impossible to miss,
and the filter can be written against a captured request rather than a guess.

Verified live: the notice fires and total stays 1966.
 2026-08-21 21:58:29 +00:00
funman300 d74aee33f7 feat(fifa17): opt-in commerce settings, the server half of the transfer-list fix 
"Place on Transfer List" is greyed for two reasons. This crate already fixes one
(owned copies emit `untradeable: false`). The other is `tradingEnabled`: the
client's struct defaults it to 0 — it is not a flag we have been overwriting, it
is a flag nobody has ever sent — and it gates the service half of the
TO_TRADE_PILE predicate (vtable slot +0x270, gate byte 0x1fd2e, measured 0 live).
`GET /settings` has always answered `{"configs": []}`.

The schema is high-confidence: FutGetSettingsServerResponse (deser 0x18013c6d0,
read end to end) has a single `configs` key holding `{type, value}` rows, and the
key ladder holds nothing else. `type` is the setting NAME. The row set is ported
from the shape the Python oracle would emit rather than invented.

Default OFF (`OPENFUT_FIFA17_COMMERCE_SETTINGS=1` opts in), because the flags are
RECOVERED BUT UNTESTED and the empty list is the live-proven body — the house
rule is that a flag defaults to the live-proven value. This also moves the
capability out of the oracle we are retiring and into Rust, where it can actually
be reached once Python is gone.

Verified against a real host on both settings: OFF returns {"configs":[]}
byte-identical to today, ON returns the 8-row body with tradingEnabled. It
explains why the menu entry is greyed; it does not promise the market works.
 2026-08-21 21:47:13 +00:00
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.
 2026-08-21 21:33:36 +00:00
funman300 22cfae830f docs(fifa17): apply the plan's corrections to CARD_SYSTEM.md and fut_store.py 
Section 7 of plan-2026-08-06-card-subsystem.md listed these and they were never
applied, so the stale text kept misleading readers — it already cost this project
a ten-row itemState table.

CARD_SYSTEM.md:
  - "STILL UNKNOWN, AND NOT GUESSED" is ANSWERED. Its candidate set was wrong:
    it asked which of 0x1e/0x1f/0x91..0x96 meant kit/badge/stadium, but three of
    the five families are cardtype 7 (kit 9, stadium 10, badge 11) and are not in
    that set at all, and 0x91..0x96 are trophies. Replaced with the settled map
    and how each family's caption resolves.
  - itemState table starts at 0x180229cc0, not 0x180229d20 — the recorded address
    points MID-table, which is why six rows were missing. Added that
    WAITING_FOR_GAME/inGame are aliases, that omitting the key yields invalid and
    not free, and that the match is case-sensitive (measured).
  - the consumables route claim "the /consumables/%s template ... the client has
    still never used" is false; it IS that template, with base index 3 = ut/%s/club.
  - added the dated field-map correction block, extended with the +0x60 and
    definitionId findings measured on 2026-08-21.

tools/fut_store.py: the discard_value premise "that lookup returns no row for our
cards" / "WHY its lookup misses is still UNKNOWN" is false — it does not miss, the
tile reads a different property. That story sent one round of work chasing a table
defect that never existed.
 2026-08-21 21:31:59 +00:00
funman300 404e859cb6 docs(fifa17): the caption path is not in CardsDLL, and a 4th definitionId check 
Chased the league-logo lead to a useful boundary and stopped there.
FUN_180119bd0 — the cardtype-7 caption resolver the whole club-item story rests
on — has ZERO references anywhere in CardsDLL: no call, no jmp, address never
taken in .text/.rdata/.data. It is nonetheless a real function. An unreferenced
real function in a DLL is almost certainly an export, which puts its caller in
FIFA17.exe. So the owned cardtype-9 caption path is not in CardsDLL and looking
for it there is wasted effort; the launch probe remains far cheaper than parsing
the export table and 79 MB of EXE.

Also verified definitionId a fourth way, by a different method than the existing
three: every real atom name appears exactly once in CardsDLL's .rdata
(resourceId, cardsubtypeid, itemState, assetId, cardassetid, rareflag, owners,
contract, discardValue, and localizedName), while definitionId is absent
entirely. Recorded but NOT applied — the path carrying it is live-proven and the
saving is payload only.

Method note added: CardsDLL is .text 0x180001000, .rdata 0x1801e5000, .data
0x18028a000. Confusing a live mapping offset with an image offset reads the wrong
section and returns false negatives — it made every atom lookup, controls
included, come back ABSENT until corrected. Validate scans against a known key.
 2026-08-21 21:28:13 +00:00
funman300 59c249e76a chore: bump openfut-core for reclassify dry-run 2026-08-21 21:23:52 +00:00
funman300 bea3b49070 docs(fifa17): a LeagueName_Abbr_15 path exists — recorded as a lead, not a fix 
FUN_180098f20, previously described as the league-logo function with a hedged
"localizedName, probably", read in full: it queries fcc_leaguelogos WHERE
leagueid == %d, reads carddbid/value/cardassetid, and captions with
'LeagueName_Abbr_15_%d' in the 'FUT String' domain. A database-backed league
name therefore exists, in exactly the shape kits use for teamid — so "cardtype 9
has no DB name resolver" is too strong for league logos.

Deliberately NOT concluded: its only caller passes [rbx+0x20] as the league id,
and rbx there is a loop cursor over small list elements (int/double/int), not the
0x158-byte card record. Reading that as the record's assetId and shipping "send
leagueid as assetId" would be the exact inference this document exists to
prevent. Recorded as a lead with the next question named: does the OWNED render
path reach this resolver, and which field feeds it?
 2026-08-21 21:17:43 +00:00
funman300 e44c88dd68 docs(fifa17): close the eight-flag chain link, and separate the two databases 
FUN_1801aa190 (the plan's "two minutes of work" item) is eleven instructions and
resolves TWO parallel arrays, not the one the earlier claim described:
f(self, idx, which) reads item+0x104+idx*4 when the flag is clear and
item+0x124+idx*4 when it is set — eight ints each, 0x20 apart. Live, BOTH read
all zeros on every resident record including a rating-94 player, so neither can
be the reason any action is greyed today.

The FUT roster database question is partly answered. Scanning FIFA17.exe in the
live process recovers the full API name set — StartFUTRosterDownload,
DL_FUT_LIVEDB, APPLY_FUT_LIVEDB, LoadFUTDatabase, UnLoadFUTDatabase,
SetFUTDatabaseUnloaded, UpdateFUTDBVersion, GetFUTDBCRC, RosterXMLDownloadedFail,
.dbFUTVer/.dbMajor/.dbMinor/CRCs — none of which exists in CardsDLL. That is a
downloaded, versioned, CRC-checked live database with its own lifecycle, which is
categorically not the shipped card tables. Whether it is loaded RIGHT NOW is
still open: the load flag was not located, and the absence of an open DB file
proves nothing since the process only holds Frostbite bundles.
 2026-08-21 21:15:02 +00:00
funman300 a842c5ffb0 tools(fifa17): answer "who writes item +0x60" — nothing does 
The plan called this "the single blocker between 'we can mark a kit equipped'
and 'we can equip a kit'", and recorded that two attempts to find the writer
drowned at 1688 and 4144 instructions.

They drowned because +0x60 is a common struct offset. Two filters make it
readable: only an IMMEDIATE store can introduce a constant (a register store
just propagates one), and item-record code is recognisable by touching +0x4c
(cardtype) or +0x5c (itemState) within a few instructions.

Measured read-only against pid 6580:
  - live +0x60 over all 27 resident records: {1: 23 players, 0: 4 staff}, never 4
  - CardsDLL has 4 comparisons of +0x60 (0, 0, 1, 4); the 4 is the kit gate and
    is the ONLY such comparison in the process
  - CardsDLL has 29 immediate stores to +0x60, constants {-2,0,1,908,0x3f800000}
  - FIFA17.exe, across 79 MB of code: ZERO stores of 4, zero comparisons with 4
  - the gate function has one xref (a jmp) and its address is never taken
  - every register store to +0x60 in CardsDLL is a struct copy or an init

So the gate is not a wire field we failed to send: the value it demands is never
produced by anything. Decoding it fully also shows every OTHER input is already
served — cardtype 7, itemState 101/102, teamid — leaving only the +0xba variant
selector beneath it, which makes a client-side patch the only remaining avenue.
 2026-08-21 21:10:35 +00:00
funman300 7f17cfe439 test(host): name the catalog-card fixture instead of a six-tuple 
clippy::type_complexity, and the struct reads better at the call site: the
fixture rows now say which field is the subtype and which is the art id.
 2026-08-21 21:00:25 +00:00
funman300 622a6ab353 docs(fifa17): the three withheld families are one cardtype-9 name gap 
Ball (30), league logo (31) and misc (231/232/233/236) were tracked as three
separate holes. They are one: cardtype 9 has no database name resolver, so the
displayed name can only come from `localizedName` on the wire, and that single
unproven step gates all three. The cardtype-7 families caption themselves from
the client's own tables, which is why kit, badge and stadium now project.

Ownership, content_kind, club/stats counting and restart durability are already
in place for all three, so the outstanding launch probe is the only remaining
work.
 2026-08-21 20:59:12 +00:00
funman300 67d896615c test(host): lock the whole ownable taxonomy end to end 
A club holding every ownable class, served through the REAL catalog resolver, so
each family travels the production classification path rather than a stub.

Asserts each family reaches its own `?type=` arm, that the staff arm carries the
manager too, and that `teamid` appears only where a caption resolves
TeamName_Abbr15 (badge yes, stadium no).

The cardtype-9 families are asserted WITHHELD with their catalog entries
RESOLVABLE, so an empty ball list is provably a decision about the family and
not an accident of a missing asset id — the two failure modes are otherwise
indistinguishable from the response.

Mutation-checked: reverting `is_cardtype7_club_item` to Kit-only fails this test
on the badge arm, so it guards the behaviour rather than merely describing it.
 2026-08-21 20:58:21 +00:00
funman300 beb505b0fa tools(fifa17): resolve the itemState comparator live — it is CASE-SENSITIVE 
The plan recorded this as "almost certainly unresolvable statically", because
`FUN_180008190` is only a forwarding stub through a slot the host fills at
runtime: `mov rax,[DAT_1802ddfd8]; mov r9,[rax+0x248]; jmp r9`.

It IS resolvable — just not from disk. Read read-only out of the running client
(pid 6580): the slot forwards through two FIFA17.exe thunks into
msvcr120.dll+0x3c330, whose body is strncmp (`test r8,r8` count, `test al,al`
NUL stop, `cmp al,[rcx+rdx]`, then MSVC's 0x8080../0xfefe.. NUL-detect fast
path). No `or ..,0x20`, no folding table: the compare is raw bytes.

So the casing in the table at 0x180229cc0 is a CONTRACT. A mis-cased token does
not degrade gracefully — FUN_180166660 returns 0xffffffff, the record keeps 0 =
invalid, and the item fails the squad builder. This confirms what
fut::item_state already emits; it was previously true by convention and is now
true by measurement.

The probe follows the chain and attributes each hop to its module, which needs
care under Wine: PE sections are mapped anonymously, so a module is identified
by the nearest preceding named mapping rather than the containing one.
 2026-08-21 20:54:29 +00:00
funman300 43aa114bcd style(import-fifa17): rustfmt the club-family classifier and its tests 2026-08-21 20:47:05 +00:00
funman300 4b66906adc feat(fifa17): definition-coverage guard, and a complete-club staging fixture 
The guard classifies every definition id the game ships into exactly one of
KNOWN_OWNABLE / KNOWN_PRESENTATION_ONLY / KNOWN_UNSUPPORTED / UNKNOWN, and fails
when anything lands in UNKNOWN, so a table we cannot place is loud instead of
quietly assumed cosmetic. All 149 tables place: UNKNOWN = 0, 20,876 ownable ids.

Two tables are KNOWN_UNSUPPORTED with stated reasons rather than guessed at:
`fut_storymodehero` (80 ids; the shipped row is only {carddbid, teamid}, so no
item can be shaped without inventing one) and `fcc_misccards` (42 ids; these ARE
owned items, but their per-subtype semantics are not reverse-engineered).

It also counts by SHARED ID SPACE: `fcc_leaguelogos` and
`fcc_leaguelogostickers` both start at carddbid 8010000 and all 39 sticker ids
collide, so the union is 44 and never 83. The collision is printed so summing
cannot regress silently.

Staging now seeds the remaining club families (badge, ball, stadium, league
logo) from the client's own tables, so the rig exercises EVERY ownable class
instead of only the two the real club happens to hold.
 2026-08-21 20:45:45 +00:00
funman300 9823bdac78 feat(fifa17): project badges and stadiums, the other two cardtype-7 club items 
Kit, badge and stadium are ONE record with ONE client-side resolver
(`FUN_180119bd0`, dispatched on `item+0x4c == 7`); they differ only in the field
their caption reads. Kits already ship and render, so the record is live-proven
— badges and stadiums were being withheld as if unreversed when the authority
(`plan-2026-08-06-card-subsystem.md`) marks both CONFIRMED, and its own rollout
order is "kits first, then badges, then stadia".

So the shaper generalises to the family, and carries exactly what each caption
resolves: `teamid` for kit and badge (`TeamName_Abbr15_<teamid>`), withheld for
stadium, whose resolver reads `StadiumName_<assetId>` and never looks at teamid.
Sending a field the resolver does not read is how this project earned a client
freeze.

Ball (30) and league logo (31) stay withheld. They are cardtype 9 with NO
database name resolver, so their name can only come from `localizedName`: the
offset is confirmed, but "the parser reads it" is not "sending it is safe".

Verified against the real club on staging: badge 6000005 emits cardsubtypeid 11
/ cardassetid 39 / teamid 21, stadium 6200000 emits cardsubtypeid 10 /
cardassetid 36 and no teamid, ball and logo emit nothing.
 2026-08-21 20:45:29 +00:00
funman300 7a4dab04d2 feat(import-fifa17): classify every club family, not just kits 
Kits were recognised by the id range 6_300_000..=6_400_654, so stadiums,
badges, balls and league logos all fell through to `Other` and were silently
dropped from the import — a club could own them and Core would never hear.

Club items are now settled by `cardsubtypeid` (kit 9, stadium 10, badge 11,
ball 30, league logo 31), which is the discriminator the client's own club-item
resolver uses and cannot collide with the other classes: consumables occupy
51..=341 and staff 4/6/8.

The render gate generalises with it. Each family ships a CONSTANT cardassetid
(kit 35, stadium 36, ball 37, badge 39, logo 40 — verified across all 2302
shipped rows), so a copy carrying anything else is deferred rather than drawn
as the wrong art. Only kits additionally require a teamid, because their
identity resolver keys on it and real owned kits carry it; demanding one of the
other families would defer every legitimate badge, ball and stadium.

League logos map to `misc`: they have no equipped slot, so Core holds them as
generic owned content rather than inventing a designation.

The real profile is unaffected (it owns no club items beyond its kits) and its
emitted catalog is byte-identical.
 2026-08-21 20:19:04 +00:00
funman300 23f120f889 fix(staging): reclassify the restored club, and assert Core's ownership truth 
The snapshot predates the content taxonomy, so every fresh bring-up restored a
club whose coaches, kits and consumables were recorded as players. The wire
still looked right (the adapter classifies from its own catalog), which is
exactly the kind of divergence that hides until something keys off ownership.

Bring-up now runs Core's reclassify and asserts the club really owns something
of each kind. A Core binary predating the subcommand ignores it and boots the
server instead, so the step is bounded and says so rather than hanging.
 2026-08-21 20:13:35 +00:00
funman300 09db5413cd feat(import-fifa17): emit the Core reclassify request from the catalog 
The importer already knows every definition's kind, so it writes the mapping
Core needs to correct a club imported before the taxonomy existed. Applied to
the real 1989-item club: 20 rows corrected (17 consumables + 3 staff), 1966
players already right, 0 unmatched definitions.
 2026-08-21 19:55:46 +00:00
funman300 1a6355cad5 fix(staging): re-stamp the squad extension after seeding, and prove it 
Filling the bench writes squad rows behind Core's back, which invalidates the
stored FIFA17 opaque extension: Core saw a canonical squad that no longer
matched the extension's fingerprint, the host refused to apply it
(`stale_integrity`), and the client got a squad with zero players and no
manager. Nothing failed loudly — the rig just came up empty.

The seeder now recomputes the fingerprint exactly as
`services::squad::squad_fingerprint` does, and bring-up asserts the squad really
projects (>= 18 occupied, a manager present) instead of trusting that it did.

Seeded owned rows also state their content_kind, so Core does not record a kit
or a manager as a player.
 2026-08-21 19:50:21 +00:00
funman300 770029f207 fix(import-fifa17): carry the fields a consumable needs to exist 
Two defects that together made the club's 17 owned consumables invisible while
club/stats still counted them — the count gate promised 17, the item route
served 0.

1. The catalog omitted `card_asset_id`, `amount`, `contract` and `rating` for
   non-player definitions. Without an art id the adapter refuses to emit the
   card (it would draw the notfound box), and the families that read
   `amount`/`contract` would render "-1" or grant nothing. All four values are
   present in the source wire and were simply dropped on the way out.

2. Owned rows were imported without a `content_kind`, and Core defaults an
   unstated row to `player` — durably recording a fitness coach and a contract
   card as players in the ownership authority, even though the catalog-driven
   wire looked right.

These are definition-level fields, so every owned copy must agree; a group that
disagrees is deferred rather than resolved by taking the first copy's value.
Measured on the real profile: observed `amount` equals the `fcc_*` table row for
every consumable that carries one (1, 2, 4, 5, 10, 15), and a wire omission
corresponds to a table amount of 0. It is therefore NOT a stack count — two
copies of 5003068 are two instances — so the import states no `quantity` at all.
 2026-08-21 19:50:13 +00:00
funman300 802f0f580f feat(host): serve owned non-player content from Core's ownership truth 
Follows Core's kit designations becoming generic active-item slots: the host
reads `GET /club/active-items` (five always-present slots) instead of the
removed `/club/kits`.

Adds the consumables route and widens the club families to every content kind,
all resolved from Core ownership + the FIFA catalog. An item the client sees is
now an item Core actually owns.
 2026-08-21 19:49:59 +00:00
funman300 6c7d0856b6 feat(fifa17): project every owned content kind, from one recovered vocabulary 
Extends the FIFA17 adapter past players so the wire can carry the rest of a
real club's inventory.

itemState: the recovered 12-row table at 0x180229cc0 becomes the single source
(`fut::item_state`), replacing scattered literals. Every shaper draws from it
and the tests assert no shaper can emit a state the client does not know.
CARD_SYSTEM.md's 0x180229d20 is the middle of that table, not its start.

ContentKind covers all nine tokens. Managers stay inside the staff family for
counting, because the client's own club-stats model puts a manager INSIDE the
staff total with staffManager as a sub-bucket — a parallel Manager kind would
silently under-count.

Consumables get their own route (`club/consumables/<category>`) and a
stack-wrapper envelope, classified BEFORE the other club/ arms; they are not a
`?type=` family. This path previously fell through to Python, so owned
inventory was being served by the oracle.

The shaper refuses to emit a card it cannot render: no known art id, or a
missing `amount`/`contract` for the families that read them, or the subtype-219
rareflag trap that silently turns Player Fitness into Squad Fitness. A dropped
card is counted and logged, never faked.
 2026-08-21 19:49:52 +00:00
funman300 dcd470cddc tools(fifa17): measure subtype->cardtype and itemState from the running client 
Two things this project kept carrying as INFERRED are directly observable in the
card record, so this reads them instead of trusting the decompile:

  rec+0x18 resourceId, rec+0x4c cardtype (derived by FUN_1800d8330),
  rec+0x50 cardsubtypeid (as sent), rec+0x5c itemState (decoded enum value).

Measured against the live client (pid 6580, 27 records):

  subtype 0 -> cardtype 1   (23 records)  agrees with FUN_1800d8330
  subtype 4 -> cardtype 2   (1)           agrees
  subtype 6 -> cardtype 10  (1)           agrees
  subtype 8 -> cardtype 4   (2)           agrees
  itemState runtime value 1 on all 27, and every one of those was served as "free"

So the cardtype map is now runtime-confirmed for every subtype we actually serve,
and `free == 1` is an empirical anchor for the itemState enum rather than a
reading of the table at 0x180229cc0. The probe prints the Ghidra prediction
beside each measurement and says DISAGREES rather than quietly matching, so it
stays useful as new families are served.

It also states the obvious limit in its own output: a runtime value only appears
if the client was actually served an item in that state, so absence is not
evidence of absence. The equipped states (activeBadge 100, activeHomeKit 101,
activeAwayKit 102, activeBall 103, activeStadium 104) remain table-recovered and
un-measured until a kit is fetched by the client.

Read-only: /proc/PID/mem is opened 'rb' and there is no write path.
 2026-08-21 18:55:59 +00:00
funman300 8f98e6adda tools(fifa17): probe the manager-only chemistry slots to settle inferred vs proven 
`card_identity_probe` reads the PLAYER slots (F_NATION 0x148, F_LEAGUE 0x154). A
manager does not use those, so grading a manager with it reports nation=0 /
leagueId=0 and reads like a server bug when it is only the wrong offsets.

The manager layout, from the Ghidra reversal already recorded in fut_staff.py, is
teamid rec+0x94, nation rec+0xde, leagueId rec+0xe0, talkrating rec+0xe2,
negotiation rec+0xe3. The managercards merge (FUN_1801356c0) NEVER writes +0xde
or +0xe0, which is exactly what makes them a clean test: whatever sits there came
from our JSON and nowhere else.

Read against the live client (pid 6580, 27 records in the CardsDb map):

  resource   teamid  nation  league  talkrating  negot   verdict
  1000509    241     45      53      0           3       SERVER FIELDS LANDED

So the manager's chemistry fields DO reach the record, and `negotiation=3` agrees
with managercards row 1000509, i.e. the merge ran as well. That moves manager
nation/league from INFERRED to PROVEN without a screenshot.

Read-only: /proc/PID/mem is opened 'rb' and there is no write path.
 2026-08-21 18:53:20 +00:00
funman300 106cb83988 fix(staging): fill the real club's bench to the client's 18-player minimum 
FIFA refuses to kick off with "your squad must have at least 11 players and 7
subs … currently below the minimum number of players (18)". The imported club's
squad carries ONLY its starting XI, so a freshly installed real club is
unplayable until someone fills the bench by hand in the hub.

`fill_bench_to_minimum` tops the squad up with the club's best spare players,
writing EMPTY bench slots from index 11 upward. The 23 slots are 0..10 pitch and
11..22 bench/reserves, derived from the index alone, so the starting XI — and
any bench the operator has already chosen — is never touched and a re-run is a
no-op. Only real PLAYER definitions are eligible: a kit, a manager or a
consumable in a squad slot is nonsense the client would drop anyway. Selection
is best-rating-first with a stable id tiebreak, so the same bench comes back on
a re-run rather than shuffling.

Scoped to the REAL club on purpose. The 14-item fixture is a market test bed
with a single spare player; demanding 18 there would abort a bring-up that never
needed to kick off. Fixture mode therefore does not call this at all.

Verified against a copy of the club snapshot (the live staging database was left
alone, since it currently holds a squad the operator saved by hand): 11 -> 18
players, slots 0..17, no duplicate instance in two slots, every filled pick a
real player definition, and a second run filling nothing.

This is NOT a diagnosis of the failure the operator just hit — that squad had
already been filled to 23 valid players before the match was created, and the
host log shows the client issued no request at all after `match-create` beyond
account-sync, so that refusal is decided entirely client-side. It removes the
variable: after a clean bring-up the club is now playable without hand-editing.
 2026-08-21 18:12:59 +00:00
funman300 33300f2ad1 fix(fifa17): serve the match lifecycle instead of proxying it to a dead upstream 
"There was an error creating your game session. Please try again." on advancing
past the starting XI. The host log names it exactly:

  utas-host ERROR passthrough to Python failed: … /ut/game/fifa17/match
  utas-host owner=PYTHON_FALLBACK method=POST path=/ut/game/fifa17/match status=502

Neither `match` nor `match/end` was claimed by either classifier, so both fell to
Passthrough. This is the third instance of one defect: `season/list` and
`watchList` were the first two, and like `watchList` the handler already existed
and was simply unreachable — `EconomyRoute::MatchEnd` was produced ONLY by
`POST /ut/delete/game/<sku>/match`, a URL the retail client never sends. The
adapter's `match_wire::create_response` had zero callers.

The family is now classified by PATH SUFFIX and is deliberately VERB-AGNOSTIC:
the strings "PUT" and "DELETE" do not occur anywhere in cardsdll.dll, so verb
selection happens outside the DLL and cannot be pinned statically. Matching on a
verb is precisely how these came to be proxied. All three arms live in the
ECONOMY classifier, because `/match/end` credits coins and `try_handle_economy`
is the barrier guaranteeing a claimed route can never also reach Python — and
because create and end must share the in-flight match id, splitting the family
across two classifiers is what let them diverge.

`POST …/match` is both FutCreateMatch and FutPlayGame, discriminated by an
integer `matchId` in the body exactly as the client serializes them; play acks
`{}` and must not mint a second session. `squad` is omitted from the create
response: nested, half-read, the documented freeze mode.

MATCH IDS GET THEIR OWN IDENTITY SCOPE. The oracle mints them from the same
counter as owned items, which is why an observed match id looks like an item id,
but that is an artifact of a single-counter save file. Here the identity store
keeps a real reverse map, so an item-scoped match id would make
`owned_id_for_wire` resolve a match to a bogus owned card and corrupt quick-sell
and move. A new `(game, "match")` scope costs one constant — the store is
already generic over the pair — and an integration assertion now pins that a
match id never appears in the owned-item reverse map.

ECONOMY: `/match/end` is NOT a new authority. It renders Core's single
exactly-once `complete_match` transaction, the same one the legacy
`/matches/result` path was closed in favour of earlier today, and it still omits
`expire_loans`/`advance_season` so FIFA 17 keeps its own seasons and loans.

THE LATENT BUG THIS EXPOSED, which would have been a silent permanent
under-credit the moment the route became reachable: the per-match identity fell
back to a hash of the request body. Every abandoned match sends a BYTE-IDENTICAL
body (`matchReportId:0`, empty items/matchData/telemetry, flags 0), so all of
them collapsed onto one identity and Core's UNIQUE(profile_id, match_identity)
would refuse every DNF after the first — `applied=false`, nothing awarded, no
error. The identity is now the id minted at create, which is unique per match by
construction; the fingerprint remains only as a floor for an end with no create.
It also removes a durable dependency on `DefaultHasher`, which has no
cross-version stability guarantee yet was being persisted.

One bug of my own, caught by driving the real dispatch rather than the handler:
taking the in-flight id on end looked tidy but sent a REPLAYED `/match/end` down
the fingerprint path — a different identity — so Core paid a second time
(measured: a second +75 for one abandoned match). The id is now read and held,
so a replay reuses one identity and the next create overwrites it.

Verified end to end on the restored club: create → ready → play → end returns the
reversed reward shape (`boostConis` included, `bidTokens`/`qualifiedChampionEventId`
never emitted), a DNF credits once, two replays credit zero, and a second match
with a byte-identical body credits again. Host 115 lib + 36 host_test + 7
economy_integration + concurrency/differential/failure, adapter 217 + 25, all green.

Note for the record: a DNF pays Core's COINS_LOSS (75), not the oracle's 100.
Nothing on the wire settles the number — the client renders whatever we send, and
the oracle's own comment says its values were never reversed — so the declared
Rust authority's table wins rather than being bent to match Python.
 2026-08-21 18:00:28 +00:00
funman300 12ad04c9d4 fix(fifa17): carry the manager's item in the squad, not just its id 
The operator picked a manager in the FUT hub, then found no manager on the
pre-match squad. The save was NOT the problem: the host logged three
`route=squad-replace status=200 outcome=ok detail=[]` with no unresolved ref,
Core wrote the `squad_managers` row, and every read projected the assignment
back. The client simply had nothing to draw.

`squad.manager[]` was emitted as a bare `[{id, dream}]`. That looked
retail-faithful, and the previous commit defended it on the grounds that no
capture had ever shown otherwise. Re-reading the captures with a populated
manager in hand shows why that was the wrong conclusion: every retail capture
carrying the bare form has `id: 0` — an EMPTY manager. None of them ever
demonstrated that a POPULATED ref renders without its item, because none of them
had one. `plan-2026-08-05-families.md` says as much outright: "FUN_18013d1f0 was
never read for a staff member".

The squad object is self-contained everywhere else: `players[].itemData` carries
the whole card rather than an id resolved out of band. The manager is the same
kind of slot in the same object, and the one implementation that ever drove a
working manager — the Python oracle's squad — emits `id` BESIDE `itemData`.
The element shapes differ and both are now pinned by tests: a player slot is
`{index, itemData, kitNumber}`, the manager is `{id, itemData, dream}`.

So the manager is projected through `resolve_staff` and its item embedded with
`shape_staff_item`, the same 11-key record `/club` serves. An assignment with no
resolvable staff identity still yields `[]` rather than a fabricated ref.

`STAFF_CONTRACT` moves next to `shape_staff_item` in `fut::item` (re-exported
from `club_response`) so `/club` and the squad cannot disagree about the
contract the client checks before kickoff.

Verified on the restored club: userMassInfo, /squad/0 and /squad/active all
carry the manager with resourceId 1000509, contract 7 and the nation/league/team
the client cannot supply itself. Adapter 217 lib + 25 integration, host 114 lib +
36 host_test and every economy suite green.
 2026-08-21 17:30:14 +00:00
funman300 9c2edc4eee feat(fifa17): serve staff, so the club has a manager and matches can start 
FIFA refuses to kick off with "your player or managers contracts have expired".
The club had no manager, and could not have had one: `/club?type=manager` (the
token the STAFF tab actually sends) was rejected by the host, and staff items
were counted and dropped by the adapter instead of being shaped.

The squad's manager reference is a red herring worth recording. It points at
wire id 100000427, which resolves to resourceId 3000083 = a FITNESS COACH
(cardsubtypeid 8), not a manager. The client's own club/stats agrees:
staff:3, staffManager:0, staffGKCoach:1, staffFitnessCoach:2. This club has
never owned a manager, so one is MINTED rather than restored.

Wire shape is not guessed. `fifa17-recon/tools/fut_staff.py` is an
instruction-level reversal of the item parser and the managercards merge that
justifies every key by its record offset, and CARD_SYSTEM.md records it
confirmed live on 2026-08-05 (ten managers rendered with correct flags, league
names and "CONTRACT 7" on the card front). `shape_staff_item` emits exactly that
key set and nothing else:

* `nation` (rec+0xde) and `leagueId` (rec+0xe0) are MANAGER-ONLY slots the
  client's merge never writes, so the server is their only source — they are the
  flag, the league badge and both halves of manager chemistry. Coaches get
  neither, because the four coach tables have no nation/league/team column and
  emitting zeroes there would be invention.
* `resourceId` is the RAW merge key: staff are read as a u32 with NO &0xffffff
  mask (players are the only masked family), so `version` must stay 0 or the
  lookup misses — silently, since the manager branch has no else-arm.
* `preferredPosition`/`attributeList` are omitted because they SURVIVE the merge
  and are then read by the card view-model; `assetId`/`rating`/`rareflag` are
  omitted because the merge overwrites them from the client's own tables. A
  staff card is therefore never routed through `shape_item`.

Managers stay inside `ContentKind::Staff`, discriminated by `cardsubtypeid == 4`
— the client's own discriminator, and its own stats model counts a manager
INSIDE the staff total with staffManager as a bucket within it. A parallel
`ContentKind::Manager` would have been a second source of truth for a fact the
subtype already carries, and would have silently under-counted club/stats.

`squad.manager[]` stays `[{id, dream}]`. The only populated form anywhere is the
oracle's DRAFT squad; no capture has ever shown itemData in a regular squad, and
feeding that deserializer the wrong container type freezes the SAX reader. The
contract reaches the client through the CardsDb record registered from the
/club envelope, which is a find-or-insert and therefore accumulates.

TWO SILENT BUGS FOUND ON THE WAY, both of which made a correct assignment look
like no assignment at all:

1. `get_squad_manager` read `manager.owned_card_id`, but Core returns the
   assigned OWNED CARD, whose field is `id`. It therefore ALWAYS returned None —
   indistinguishable from "no manager". Now reads `id`, and a present-but-
   unreadable manager is an error rather than a silent absence. The projection
   also now warns when an assignment cannot be resolved to an owned instance,
   which is the documented "Core drops an owned card with no CardDefinition from
   /collection without erroring" trap.

2. `Route::WatchList` was produced by NO classifier arm, so its handler was
   unreachable and every `watchList` request fell through to Passthrough — the
   same defect class as `season/list`. Against a stack whose Python upstream is
   deliberately dead this 502'd. This was failing
   `sbc_survives_complete_core_and_host_restart` at HEAD before this change.

The manager itself is seeded from the client's own tables, never invented:
managercards 1000509 (assetid == carddbid), nation 45, manager[509] "Luis
Enrique" teamid 241, leagueteamlinks 241 -> league 53. League 53 is also the
dominant league in the restored squad (12 of 23), so the chemistry pairing is
the correct one rather than an arbitrary pick.

Verified live against the restored club: /club?type=manager and ?type=staff both
return 4 items (the minted manager plus the 3 coaches the profile already owned
and could never see), the manager carries contract 7 with nation/league/team,
coaches correctly carry none of the three, squad.manager resolves to the same
wire id, and no staff leaks into ?type=player. Adapter 219 tests, host 114 lib +
36 host_test + all economy suites green.
 2026-08-21 17:13:44 +00:00
funman300 de747b79e6 feat(staging): let staging serve the operator's real club, not just the fixture 
The operator could not field a starting XI because staging has only ever held the
14-item synthetic fixture (11 auto-picked starters, one disposable, two kits). The
real club -- the 1986-item CAGE import, 29,843,976 coins -- was never lost, but it
sits in `/home/alex/openfut-promotion/state`, which BOTH staging lifecycle scripts
list in FORBIDDEN_PATHS and refuse to open. That guard is correct and stays.

Worth recording while looking for the club: the LIVE production Core container
serves an EMPTY database (0 owned cards, schema predating even the game_id column).
The real club is not being served anywhere right now; it exists as state on disk.
So restoring it into staging is not a convenience, it is the only way to play it.

Two pieces:

`scripts/club-snapshot.py` is the ONE place allowed to read production state, and
it is read-only by construction: the Core database is opened `mode=ro` and copied
with sqlite's online backup API (a plain file copy can tear a database with a hot
WAL), every destination is asserted to be outside the production directory before
anything is opened for writing, and the sha256 of every source is compared before
and after -- a mismatch aborts, because that would mean the snapshot modified
production. It then proves the copy is faithful (same counts, coins, squad) and
that the identity store maps EVERY owned card to a wire id, since an unmapped card
would reappear under a freshly minted id and break the client's cached squad.

`sold-staging-up.py --club real` installs that snapshot. It is installed BEFORE
Core first starts, so Core migrates the copy forward from schema v19 through
match_completions, squad managers and kit assignments. Seller A is then already
present -- it IS the imported persona -- so only Buyer B is seeded, the kit
fixtures are attached to the real club so the kit work stays exercisable, and the
real squad is left alone. The up script still never reads production state: the
snapshot lives outside it, which is precisely what makes `--club real` compatible
with the `safe_path()` refusal.

The resolvability preflight now covers whichever club will actually be served. This
is the check that matters most for the real one: Core does not fail on an owned card
whose definition is missing, it silently filter_map-drops it, so a gap shows up as
an EMPTY club with all 1986 rows still in the database. Verified: all 1712 distinct
card ids resolve in both the content pack and the identity catalog, 0 missing.

`sold-staging-seed-squad.py` now REFUSES to run when the manifest says the real club
is installed. `PUT /squad/0` is a full replacement, so the fixture seeder would have
overwritten the operator's own lineup with an auto-picked XI -- destructive and not
recoverable in place. `--show` still works in every mode; `--force` overrides.

Verified end to end against the restored club: /club 29,843,976 coins, /collection
1988, 1966 players + 2 kits served over the UTAS wire, squad 'OpenFUT' (f433) rated
90 with 11 players carrying contract 7 / fitness 99, and every wire id stable from
the snapshot identity store. The fixture path was re-run afterwards and still seeds
exactly 14 items, so the SOLD experiment is unaffected.
 2026-08-21 16:35:06 +00:00
funman300 dddcfb917c feat(fifa17): serve offline Seasons instead of an empty body 
Single-player Seasons failed with "There was a problem communicating with the
FIFA Ultimate Team Servers". Two independent faults, both fixed:

1. The client never reached a season endpoint at all. It aborts on a
   prerequisite web file, captured live by the deployed trace:
     SEASONS_WEBFILE_URL: url="packs/loc/storepackdescriptions.en_us.xml"
     SEASONS_STAGE1: status(+0x1c)=999 -> CACHE_PACKNAMES_FAILED
   That is the hook's side (launcher 5294f58): the CDN base is empty in the
   emulator, so the url stays relative and never reaches the POW content server
   on 8085 that actually serves it.

2. `season/list` and `season/user` were not served. Only the EXACT tail
   "season" was classified (as FeatureOffEmpty); every sub-path fell through to
   Passthrough — the deliberately-dead Python upstream — so the mode could not
   have worked even once the web file resolved.

Adds `fut::season_wire` with the reversed element schema (parser FUN_180167740,
stride 0x318; matches elements via FUN_180167fb0) and a `Route::Season` owning
`season…` for GET plus the state-storing PUT. Anything else still proxies rather
than being claimed without evidence.

Two things the types encode because getting them wrong is fatal:

* `matches` is NEVER empty. StartSeason (FUN_1800fc500) indexes
  `matches[*(x+0x70)].teamId` off `elem+0x2e8`; an empty vector makes that a
  NULL dereference and the client dies at CardsDLL+0xfc5b5. A full ten-round
  schedule is emitted, with opponents drawn from team ids observed in this
  client's own database.
* `type` MUST serialise before `divisionId`. `serde_json::Value` is a BTreeMap
  here (no preserve_order), so `json!` sorts keys ALPHABETICALLY and emitted
  divisionId first — caught by a test written for exactly this. The wire shapes
  are therefore `#[derive(Serialize)]` structs (declaration order) rendered
  straight to text via a new `json_text_status`, never round-tripped through
  Value.

Verified on staging: season/list returns the ten-round OFFLINE season with
type before divisionId, season/user the round-1 position, history an empty
list, and the bare tail still {}.

Season progress is not yet persisted: the state-storing PUT is acknowledged
with {} (what the retail wire answers) rather than pretending a round advanced.
 2026-08-21 16:20:01 +00:00
funman300 ff915a306e chore(submodules): bump Core + Bridge for the closed legacy match path 
Core bae0a2b: `POST /matches/result` fails closed (it was a second economy
authority with no transaction and no idempotency key); loan expiry and Core
season progression move into `complete_match`'s transaction behind opt-in flags
that default OFF, so the FIFA 17 retail path is unchanged; notifications emit
post-commit and only when applied; `/auth/reset` now clears `match_completions`,
which previously made any profile that completed a match unresettable.

Bridge 07e83fe: the two EA result routes and the dashboard submit to
`/matches/complete` with a per-submission `match_identity`. Pushed to
`fix/matches-complete-migration` — the bridge pin is deliberately behind its
origin/main, so this does not touch that branch.
 2026-08-21 04:48:45 +00:00
funman300 d6aa704b01 fix(fifa17): a dangling manager ref must not refuse the squad save 
Every real squad save was failing with 400 unresolved_wire_ids. Reproduced on
staging with the repo's own seeder, which sends the captured retail body:

  route=squad-replace status=400 outcome=unresolved_wire_ids detail=[[100000427]]

FIFA 17 always sends a manager ref, and on a real profile it does not resolve to
an owned instance. scripts/sold-staging-seed-squad.py already recorded why:
production's own squad points at instance 100000427, which is absent from
production's /club/staff (1975 items spanning 100000001..100004826), and the
client accepts that squad back unchanged -- so the client never validates the
manager against the club, and the pre-0023 server accepted it.

Making the manager ownership-backed (d37a9d5 / 25f4ad1) turned that ref into a
hard refusal, which took out the primary FUT write path: no squad save means no
squad, which means the client will not enter the FUT hub at all.

A manager ref is not a squad slot. An unresolvable PLAYER slot must still refuse
the save -- committing it would silently drop an owned card from the club. An
unresolvable MANAGER ref just means there is no ownership-backed manager, which
is exactly the state before migration 0023: the save commits, the assignment is
cleared as a full replacement should, and the id is reported on
ProposedSquad::unresolved_manager_wire_id so the host can log what it could not
map instead of letting it vanish. A ref that DOES resolve is still assigned and
still authorized against the club.

Verified end to end on staging: the seeder now answers {"id": 0} with 11
occupied slots, the host logs
`manager_ref_unresolved=100000427 (saved with no manager assignment)`, and the
projected squad carries `manager: []`.
 2026-08-21 04:28:43 +00:00
funman300 054a912357 fix(fifa17): key the kit home/away split on the carddbid, not assetid 
Staging served `kits=2 kitsHome=0 kitsAway=0`: the split compared the catalog
`asset_id` against `fcc_kitcards.assetid` (14/15), but a kit's catalog
`asset_id` IS its carddbid (6300006), not that column, so neither family ever
matched.

The carddbid range is the same fact in the form we actually carry: across all
1482 kit rows, assetid 14 covers precisely the 828 `63xxxxx` ids and assetid 15
precisely the 654 `64xxxxx` ids, with no exceptions either way. Keying on the id
we already have avoids carrying `assetid` as a second source of truth for the
same split. Tests now use the real team-21 pair (6300006 home / 6400003 away).

Verified against the staging stack: `kits=2 kitsHome=1 kitsAway=1`, team-21
bucket 2, `?type=kit` still activeHomeKit/activeAwayKit, `?type=player` 12.
 2026-08-21 04:13:11 +00:00
funman300 3442eac6f0 fix(fifa17): complete kit stats, restore red squad tests, unrot prod gate 
Four defects found by running the suites and the staging lifecycle end to end
after the kit milestone.

1. club-stats kits were half-implemented. The global `kits` counter was real
   but `kitsHome`/`kitsAway` and every per-team `kits` bucket stayed hardcoded
   0, so the same screen reported two owned kits and zero home/away kits.
   `kits` is a total with a family split, exactly like players/playersGold and
   staff/staffManager. The split key is `fcc_kitcards.assetid`: 14 is the home
   family and 15 the away family, verified across all 1482 rows of the kit
   table (assetid 14 covers exactly the 63xxxxx carddbids, 828 rows; assetid 15
   exactly the 64xxxxx ones, 654 rows; no exceptions either way).
   ClubStatInput now carries `asset_id`, and a kit buckets onto the team that
   wears it -- including a team the club owns no player from, the normal case
   for a kit won from a pack. The host reads both from the catalog through new
   NON-MINTING accessors: `resolve`/`resolve_kit` allocate a wire id, which a
   read-only stats query must never do as a side effect.

2. host_test.rs had 10 tests red since the squad-manager work (25f4ad1 /
   d37a9d5); 56bd9dd updated the squad_projection integration test and stopped
   there. `put_body` hardcoded the captured manager ref 100000427 into EVERY
   save, including tests with no manager fixture, so each one was refused with
   `unresolved_wire_ids` -- the tests were reporting a real invariant against a
   fixture that could not satisfy it. The manager is now an explicit
   `Option<i64>` per test, and FakeCore models Core's manager persistence
   instead of inheriting the "not implemented" default that 502'd every save.
   Added the coverage whose absence let this rot: a manager assignment
   round-trips as a Core owned id, a later save without one CLEARS it, and an
   unowned manager ref refuses the whole save with nothing committed.

3. `club_route_maps_query_and_shapes_core_items` pinned `offset`/`limit`
   forwarding to Core, which the kit commit deliberately replaced with
   host-side pagination. It only ever passed because FakeCore ignored the
   window -- against a real Core, `start=10` over a one-item club was always an
   empty page. Retargeted to the real contract (Core gets semantic filters and
   NO window) plus a new test that the window is applied locally after
   filtering, which the old fake made vacuous.

4. The staging lifecycle scripts identified production by hardcoded pids, so a
   correct teardown FATAL'd: production moved into containers and pids
   3631953/3374264 died with a container restart days ago. A pinned pid rots
   into the worst of both worlds -- a kill-refusal gate that no longer names
   any real production process, and a liveness gate that fails a healthy
   teardown. New shared `scripts/openfut_production.py` resolves production
   pids AND published ports from the container runtime at the moment they are
   needed, refuses to signal anything it cannot see, and proves production is
   the same processes serving the same ports before and after. Both lifecycle
   scripts use it, which also closed a real gap: port 8085 is published by
   openfut-fut-backend but was missing from the up script's forbidden list, so
   staging could have bound a production port.

Also fixes the economy differential, red because `complete_match` unlocks
achievements in the same transaction that pays the match reward -- a deliberate
Core feature the Python oracle has no counterpart for. `rust WIN +400` asserted
that progression did not exist; it now asserts the delta is the 400 match reward
plus exactly the achievements the match unlocked, read from Core's own report.
 2026-08-21 04:10:34 +00:00
funman300 db743ffd1f feat(fifa17): project owned kits with active home/away designation 
Closes the server side of the FUT kit selector. Ownership stays generic in
Core (submodule bump: club_kit_assignments + GET/PUT /club/kits); this
commit adds the FIFA17 representation, the host projection and importer
support.

adapter:
* ContentKind::Kit ("kit") so kits are classified alongside player/staff/
  consumable instead of being mistaken for 0-rated players.
* Fifa17CardIdentity carries card_asset_id and team_id; RawCard keeps both
  optional because the emitted catalog writes null for non-kit definitions.
* shape_kit_item emits only the fields the client's kit path reads
  (id/resourceId/assetId/cardassetid/cardsubtypeid/itemState/owners/
  untradeable/teamid) — no attributeList, no itemType.
* itemState on the wire is the STRING token activeHomeKit/activeAwayKit;
  the 101/102 integers are the client's post-deserialisation runtime enum
  (item+0x5c) and are never emitted.
* club_stats S_KITS (0x28) now counts owned kits instead of a hard zero.

host:
* CoreKitAssignments + CoreAccess::get_active_kits (GET /club/kits),
  defaulting to no active kits so a Core without the endpoint degrades
  instead of fabricating a designation.
* handle_club classifies type=player|kit, rejects any other type with an
  empty page and outcome=unsupported_type, and now always fetches
  unpaginated from Core: kind and transfer-pile membership are host-side
  concepts Core cannot express, so filtering and pagination must both
  happen after shaping or pages come back short.

importer:
* ItemClass::Kit (cardsubtypeid == 9 and resourceId in 6_300_000..=6_400_654),
  kit counts/balances, and card_asset_id/team_id carried into the emitted
  catalog and manifest.
* a kit group missing cardassetid == 35 or teamid is DEFERRED
  (missing_kit_render_metadata) rather than defaulted; conflicting render
  metadata across instances defers as render_metadata_conflict.

staging: sold-staging-up.py seeds two owned kits (6300006 home / 6400003
away, team 21) plus both active designations so the projection can be
verified over HTTP before involving the client.
 2026-08-21 03:17:57 +00:00
funman300 ab62440dbf Make FIFA17 roster hostname configurable 2026-08-21 02:35:27 +00:00
funman300 92520de6c3 chore: update launcher WinSock fix 2026-08-21 00:17:33 +00:00
funman300 be4c52ae89 chore: bump openfut-launcher (Milestone B: in-process FIFA17 TLS patch) 
Points at launcher b098617: FIFA17 ProtoSSL cert gates + empty-My-Packs store
guard patched in-process by version.dll (fail-closed, ASLR-safe), replacing the
external autopatch's cert pass. External autopatch retained for parity/rollback.
 2026-08-20 21:15:35 +00:00
funman300 967a808d73 chore: bump openfut-launcher (retire FIFA 23; FIFA17 config-driven redirect) 
Points at launcher 00ad631: retire FIFA 23 as a build target/template while
keeping the hook game-generic by per-game feature, plus the earlier config-driven
FIFA17 socket redirect (16f3452). Build invariant --features fifa17 unchanged.
 2026-08-20 20:57:05 +00:00
funman300 f60dd4da31 chore(launcher): bump submodule for Windows LSX-local fix 2026-08-20 19:57:17 +00:00
funman300 c59c7d88f7 chore(launcher): bump submodule for continuous-VRR present fix 2026-08-20 19:38:43 +00:00
funman300 b24e96b7e6 chore(launcher): bump submodule for VRR flicker fix 2026-08-20 19:35:18 +00:00
funman300 a8078e1d8e docs(windows): document native OpenFUT Launcher GUI + elevation model 2026-08-20 19:21:25 +00:00
funman300 c6abc435cb chore(launcher): bump submodule to native Windows support (057cf92) 2026-08-20 19:21:06 +00:00
funman300 9f1fc1b47c feat(windows): native client preflight + launch/RE docs 
Add read-only preflight verifier and Windows-client documentation for the
reimaged native-Windows FIFA17 client host (10.10.0.105). No launcher script:
the native model is _fifa17.exe run as admin (RUNASADMIN + shortcut). Covers
routing (openfut.cfg -> 10.10.0.120), rollback (version.dll swap), and the
x64dbg RVA<->VA (ASLR) attach workflow (ImageBase 0x180000000 CardsDLL/powdll).
 2026-08-20 18:43:19 +00:00
funman300 d8d704d441 chore(submodules): bump openfut-core -> 2fb8352 (match economy + club manager, pushed) 2026-08-20 18:21:27 +00:00
funman300 07d4a92309 fix(clippy): use slice::from_ref instead of clone in sbc challenge test 2026-08-20 18:17:30 +00:00
funman300 afa5f620bd style(fifa17): cargo fmt match wire + host match integration 2026-08-20 17:59:03 +00:00
funman300 56bd9ddc85 test(fifa17): update squad_projection integration test to ownership-backed manager 
The manager moved from an opaque extension field to an ownership-backed
canonical assignment: SquadProjectionInput.manager (owned item) replaces
Fifa17SquadExtensionV1.manager.

- project_put stand-in passes manager: None; baseline asserts the manager
  projects empty when none is owned.
- persisted_read registers the manager's owned instance + identity and
  passes it as the assignment, asserting the resolved [{id,dream}] ref
  round-trips to the read oracle's manager.
 2026-08-20 17:38:32 +00:00
funman300 9ddd80993c feat(fifa17): route match completion to Core exactly-once economy 
Adapter: new fut/match_wire.rs owns the FIFA17 match wire — endReason
enum -> canonical result token (win/draw/loss/dnf/no_contest), match-end
payload parse (goals from myMatchStats[0], omitted on DNF/QUIT), and the
reward-response projection (only reversed fields; never bidTokens/
qualifiedChampionEventId). Match logic removed from economy_policy.rs
(kept pack/fee); registered match_wire in fut/mod.rs.

Host: handle_match_end now applies the match to Core's authoritative
complete_match (POST /matches/complete) fail-closed — any Core error is a
503, never a Python fallback — and renders Core's authoritative coins.
Per-match identity from matchReportId or a body fingerprint keys Core's
durable idempotency. New CoreEconomy::complete_match transport +
CoreMatchCompletion/CoreMatchReceipt.

Tests: adapter endReason/parse/projection; host shaping, fail-closed,
malformed, identity dedupe; integration replay + rebased balance chains
(match now also grants XP/level-up/achievement coins).
 2026-08-20 17:30:17 +00:00
funman300 25f4ad12bc feat(host): wire ownership-backed squad manager through Core 
Thread the manager assignment between the FIFA squad path and Core:
- CoreAccess gains get_squad_manager/set_squad_manager (GET/PUT
  /club/manager); HttpCoreClient implements both.
- project_active_squad fetches the assigned manager owned item and passes
  it to the projector (non-fatal on error/absence).
- handle_put_squad authorizes the resolved manager against the active
  club (like a slot) and persists it via set_squad_manager after the
  atomic squad replace; fails loudly, never silently drops it.
 2026-08-20 16:44:40 +00:00
funman300 d37a9d5b5e feat(fifa17): ownership-backed squad manager, not opaque round-trip 
Move the squad manager from an opaque, unvalidated wire ref in the squad
extension to a resolved, ownership-backed assignment (Core migration 0023
squad_managers).

- squad::to_proposed reverse-resolves the manager wire ref to a Core
  owned_card_id on ProposedSquad; an unresolvable manager is reported as
  an unresolved wire id (a live save is refused rather than assigning a
  manager the club does not own).
- squad_ext: drop the opaque manager field from Fifa17SquadExtensionV1
  (clean cutover) and the now-unused SquadEntityRef->WireItemRef From.
- squad_projection: project the manager as the STATIC_REVERSED [{id,dream}]
  wire ref resolved from the owned assignment; absent -> [] (never faked).
  Richer manager itemData (contract/league/nation) is INFERRED-only and
  left out pending wire reversal.
- import(apply): drop a historical dangling manager ref rather than
  failing the whole import (live PUTs still refuse an unresolved manager).
 2026-08-20 16:43:39 +00:00
funman300 e5d356e8be chore(submodules): bump core/launcher/bridge pointers to pushed commits 
openfut-core -> a034e74 (cargo fmt pass, pushed)
openfut-launcher -> 8d5bb62 (fifa17 season diag commits, pushed)
openfut-bridge -> c58e732 (consolidate backup HEAD, on origin/main)
All targets verified present on their remotes. fifa-blaze unchanged.
 2026-08-20 16:10:22 +00:00
funman300 0b189b36c5 chore(tools): add utas-filter-diff.py diagnostic 
Read-only UTAS capture diff helper. Retained pre-existing WIP verified.
 2026-08-20 16:06:29 +00:00
funman300 11c17f3039 style(adapter-fifa17): apply cargo fmt to fut store/pack/non_economy/club_stats 
Pure rustfmt reflow; git diff -w confirms logic byte-identical (PACK_CATALOG
values, pack tiers, item_def stubs unchanged). Builds clean. Retained WIP.
 2026-08-20 16:06:29 +00:00
funman300 871d02406f chore(deploy): add root core+bridge compose stack + .env.example 
Localhost-default (127.0.0.1) compose for the Rust core+bridge; env-driven
CORE_PUBLISH. No secrets/staging-prod defaults. Retained WIP verified.
 2026-08-20 16:06:29 +00:00
funman300 6811caeab1 feat(fifa17-docker): OPENFUT_SERVERS component selection for staged Py->Rust migration 
entrypoint.sh validates/selects among lsx blaze roster utas pow and skips
unselected responders (errors if none). docker-compose threads the env
through; .env.example documents it. Retained pre-existing WIP verified.
 2026-08-20 16:06:28 +00:00
funman300 d71234b03d docs: add AGENTS.md canonical entry point; mark FIFA23 README/CLAUDE/setup stale 
AGENTS.md is the new canonical AI-agent entry point (FIFA17 active target,
repo map, FIFA23->FIFA17 pivot history). README/CLAUDE/setup.sh get stale
banners pointing to it. Retained pre-existing WIP brought forward.
 2026-08-20 16:06:28 +00:00
funman300 8e1fb640b6 tools: authoritative Core-state snapshot for FUT loop verification 
Reads openfut-core's authoritative API directly (balance, entitlements, profile,
club, collection, squad/ext) with the fifa17 game header and emits a
machine-readable JSON snapshot plus integrity checks: coin cross-check, duplicate
owned_card_id, squad-references-non-owned, owned-set + card-multiset hashes for
drift/resurrection detection across operations and restarts. Read-only oracle
tooling; used to verify Phases 1-9 of the Core-backed FUT loop audit.
 2026-08-19 19:20:28 +00:00
funman300 0019806a3b tools(fifa17): refuse to stage/deploy a non-fifa17-profile hook DLL 
openfut-hook builds two mutually exclusive injection paths from one crate. The
default (FIFA 23) path installs getaddrinfo/connect/ProtoSSL/origin_spy transport
hooks; `--features fifa17` installs only the FIFA-17-safe logic (module map,
FIFA 17 cert-verify, SBC dispatch, store tab bind).

Deploying a default-feature build into FIFA 17 hijacks the login transport: the
client reports "Unable to connect to the EA servers at this time" and none of the
FIFA 17 repairs are present in the binary at all.

That happened today: artifact 1c71a17a was built by hand without the feature and
deployed, costing two failed launches. It was diagnosed only by comparing embedded
strings between the deployed DLL and the last known-good one (the deployed DLL had
0 occurrences of CardsDLL_Win64_retail.dll and SBC_DISPATCH, and 6 of cert-verify
plus 1 of "connect: inline-hooked" -- the inverse of a fifa17 build).

`build` already passes --features fifa17, but OPENFUT_FIFA17_HOOK_DLL lets a
hand-built DLL reach stage/deploy, so verify_fifa17_profile asserts the profile on
the bytes: CardsDLL_Win64_retail.dll and SBC_DISPATCH must be present, and the
FIFA-23-only markers must be absent. Wired into verify_inputs (stage/inspect) and
into deploy's staged-artifact checks.

Verified: the gate rejects 1c71a17a, accepts 3641d581 (last known good) and
f0ef528f (the corrected fifa17 build now deployed).
 2026-08-19 18:31:27 +00:00
funman300 c7c057a31a superproject: bump launcher submodule to consolidated main 
Records the store-entry category-clamp hook (launcher 9aecc65) as the
launcher tip on main. Only the launcher gitlink is bumped; core stays
271c363 and bridge stays 0f581eb (both as already recorded), and the
in-tree formatting/doc churn is left untouched.
 2026-08-19 15:35:34 +00:00
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.
 2026-08-19 15:00:18 +00:00
funman300 13a22c4507 Bump launcher: plain-language launch status 2026-08-19 04:28:13 +00:00
funman300 1db9acdf6d Bump launcher: persist hook DLL override in the prefix registry 
Removes the manual Steam launch-options step; the launcher now writes
version=native,builtin into the Wine prefix so any launch path loads the hook.
 2026-08-19 03:01:47 +00:00
funman300 911c7a34fd Bump launcher: promote FIFA17 SBC dispatch (no env arming) 
Picks up openfut-launcher 94feaec, which makes the guarded native SBC dispatch
repair a build-armed promoted feature instead of an OPENFUT_SBC_DISPATCH env gate.
Any launch path (Steam, the launcher Launch button, bare umu-run) now gets the
repair, so the SBC screen no longer depends on a harness script exporting a
variable. Every runtime guard is unchanged; rollback is a version.dll file swap.
 2026-08-19 02:45:58 +00:00
funman300 fcc314afb1 fifa17 store: render cover art on My Packs reward tiles 
A reward pack advertised its own id (70-75) as assetId, which is not a client art
asset, so its My Packs tile rendered blank. Reward tiles now carry their tier
store pack as the cover asset (bronze->1, silver->3, gold->5) while `id` stays the
pack own id (the open packId / SERVER_ID); the sentinel keeps its own id so it
stays an inert placeholder.

LIVE-MAPPED on the retail client 2026-08-18 across all three store tabs and two
reward tiles, which corrected an earlier wrong assumption:
  * assetId only gates whether art renders AT ALL (unknown id -> blank tile).
  * WHICH art is drawn comes from packType + packContentInfo.rareQuantity, NOT
    assetId: BRONZE+1rare -> bronze card, BRONZE+3 -> silver, SILVER+1 -> gold,
    SILVER+3 -> silver trio, GOLD+1 -> blue special, GOLD+3 -> red inform.
    Remapping assetId 5->3 and 3->2 left both frames unchanged and only rotated
    the featured player, which proves art is content-driven.

So a reward tile now shows the same cover as the equivalent purchasable pack (a
gold reward shows the blue-special art the 5000-coin Gold Pack shows - EA art
advertises an aspirational card rather than the tier colour). Regression test
reward_tiles_carry_a_renderable_cover_asset added; pack70 golden regenerated.
 2026-08-19 02:08:37 +00:00
funman300 b323244ac9 fifa17 store: make My Packs reward tiles openable (free coins row) 
Reward/My-Packs tiles were emitted with no currencies row (dropped to avoid an
"undefined" payment label). But FIFA 17 opens My Packs through the store PURCHASE
flow (My Packs is a client-side filter over the store catalogue; the open-vs-buy
fork is client-side and no response selects it), so a tile with no purchase path
is not actionable — clicking it navigates instead of opening, sending no request.

Fix: keep the coins currency at the pack price (0 for reward packs; no extPrice,
so no `or %1s` mtx bug). The client then treats the tile as free and clicking
sends POST /purchased, which the server opens for free (owned-only redeem, no
debit). The empty-My-Packs sentinel keeps no currency row so it stays
non-openable. pack70 golden regenerated.

LIVE-PROVEN 2026-08-18: a reward Silver Pack opened and revealed cards on the
retail client (host log: POST /purchased/items 200 -> GET /purchased/items).
 2026-08-19 01:50:51 +00:00
funman300 1d6a6fffcc fifa17 store: make reward packs (SBC/draft/season/...) openable 
SBC completion and the other Core reward services grant packs with symbolic
definition_ids ("silver_pack", "gold_pack", ...). The FIFA 17 pack system keys
entirely on numeric catalogue ids, and entitlement_pack_ids / handle_pack_open
resolved definition_ids with definition_id.parse::<u64>(), so every symbolic
reward pack was silently dropped from the openable My Packs list. The unopened
count (recoveredPacks, = entitlement count) still counted them, so the client
showed "you have N packs" but had no tile to open -> "no pack available".

Fix (adapter-layer, Core stays game-neutral): add owned-only reward pack
catalogue entries 71-75 (bronze/silver/gold/rare_gold/icon) and a resolver
owned_pack_id_for_definition() that maps both numeric owned ids and the symbolic
reward names to their numeric owned-only pack. entitlement_pack_ids and the
pack-open entitlement selection now use it, so reward packs render as openable
My Packs tiles and redeem their entitlement for free (consume-once, no debit).

Server-verified on staging: 3 Core reward entitlements now render 3 openable
mypacks tiles matching recoveredPacks=3. Tests: adapter resolver + rendering,
host symbolic-reward open flow; full adapter + host suites green.
 2026-08-19 01:27:22 +00:00
funman300 f56aa613da fifa17 SBC: keep repeatable challenges re-enterable after completion 
The FIFA 17 client gates challenge re-entry on timesCompleted, not on the
repeatable flag: a nonzero count renders the tile COMPLETED and refuses re-entry
even when repeatable=true. So a repeatable challenge now always projects
timesCompleted=0 (challenges_body) and its set as challengesCompletedCount=0
(sets_body); a non-repeatable challenge keeps its true count and stays locked
once completed. Core keeps the authoritative completion record — economy is
unaffected; this is presentation only.

Live-proven on the retail client 2026-08-18: a completed repeatable Bronze
Upgrade now re-opens for a fresh submit instead of blocking. Regression test
repeatable_completed_challenge_stays_enterable added; adapter + full host suite
(incl. differential and the concurrency race) green.
 2026-08-19 01:18:36 +00:00
funman300 8c17f896b4 fifa17 store: native category art via displayGroupAssetId 
The all-groups landing (shown on first store entry) renders one tile per group
whose background is the client-bundled packs_backgrounds_%d.dds, selected by
displayGroupAssetId. Live-probed on the retail client 2026-08-18: index 0 is
blank; indices 1/2/3 render real pack art. Assign non-zero per category
(bronze=1, silver=2, gold/mypacks=3) so that landing shows native pack art
instead of blank shields. The persistent tabbed store (MY PACKS/BRONZE/SILVER/
GOLD PACKS) draws pack art from the packs themselves and is unaffected.

LIVE-CONFIRMED end-to-end: native tabbed store renders the real 6-pack catalogue
with correct prices (Gold 5000 / Premium Gold 7500), counts (12 items, 10 gold,
1/3 rares), pack art, and no "or %1s" line.
 2026-08-19 00:02:13 +00:00
funman300 c68c10cf04 fifa17 store: real 6-pack economy + full-DB pool; drop extPrice 
- store_catalog: replace the invented catalogue with the real always-available
  FUT17 regular packs (Bronze/Prem Bronze/Silver/Prem Silver/Gold/Prem Gold) at
  real prices + tier composition; PackDef now carries per-tier quantities.
- pack_body: drop extPrice (its mtx side-effect switched on the broken "or %1s"
  FIFA-Points tile line; plan-2026-08-05-store-subsystem.md section 3.4).
- pack_content: tier-aware generator draws each pack bronze/silver/gold
  composition with special_chance bias + empty-tier fallback.
- host: CoreAccess::all_definitions (GET /cards); build_content_pool draws the
  FULL card universe via non-minting catalog lookup, owned-inventory fallback.
- economy_differential: store ops reclassified DIFFERENT-BY-DESIGN (Rust is the
  authoritative store; Python oracle stays the untouched rollback baseline).
- fixtures/tests updated to the real catalogue.

Odds are DESIGNED placeholders (FUT17 pack probabilities were never published);
club items remain excluded (cardtype-9 mapping unknown). Full regression green;
real prices + tier-correct draws verified server-side on staging.
 2026-08-18 23:26:55 +00:00
funman300 7116046195 Lock FIFA17 SBC challenge-squad parser to captured retail wire body 
Retail Gate C captured PUT /sbs/challenge/101/squad: 23-slot players[] of
{index,itemData:{id,dream}} plus manager/chemistry/rating/formation siblings.
parse_wire_item_ids already handles it (players[].itemData.id, non-zero only);
update the stale "captures unavailable" note and add a verbatim regression test.
 2026-08-18 21:29:47 +00:00
funman300 dcac2c546b Bump launcher: FIFA17 SBC dispatch notifier lifecycle correction 2026-08-18 20:59:07 +00:00
funman300 5c8e2dc0bd Bump launcher: FIFA17 SBC dispatch response-class live vtable fix 2026-08-18 20:53:05 +00:00
funman300 bd03aec82a Gate FIFA17 SBC dispatch acceptance 2026-08-18 20:20:38 +00:00
funman300 e8d1c1ddac test(fifa17): harden SBC retail acceptance 2026-08-18 19:01:33 +00:00
funman300 f9740f640d feat(fifa17): route SBCs through atomic Rust Core 2026-08-18 18:26:35 +00:00
funman300 bf6db98f0d Migrate club rename and numeric squad reads 2026-08-18 17:29:24 +00:00
funman300 fc55de19fa test(fifa17-tls): reproducible isolated confirmation of the roster-cert fix 
Runs the REAL roster_server.py under `sudo unshare -n` (so port 8081 is free and
production is never touched) and validates its certificate BY THE DIALED IP, proving the
before/after the SAN fix (fbc0da2) targets:

  * OLD cert (DNS-only, production's current shape) -> a by-IP-verifying client is
    rejected with "IP address mismatch, certificate is not valid for '127.0.0.1'" — the
    certificate_unknown class the FIFA client hit.
  * NEW cert (fixed generator, DNS + IP SANs) -> verifies through the actual roster
    server and returns the roster XML (200, application/xml).

roster-cert-verify.py is the client probe (trusts the served self-signed cert as CA,
checks it against the dialed IP, then GETs /fifa17/fut/rosterupdate.xml).
roster-cert-iso-test.sh drives the real server with each cert and asserts new=pass,
old=fail. Two harness bugs were found and fixed while writing it (a shared /tmp log the
production run owns, and a subshell pid that left the first server alive so the "old"
probe hit a stale server presenting the new cert — the tell was "self-signed" instead
of "IP mismatch"), so the final before/after is clean.

Complements the in-process check: this exercises the production server code path, not a
hand-rolled server. Live production confirmation still needs the container rebuilt with
OPENFUT_ADVERTISE set (operator-gated).
 2026-08-18 16:37:19 +00:00
funman300 6ae3364bd0 docs: remove docs/ — migrated into the OpenFUT-Vault (single source of truth) 
The entire docs/ tree (24 top-level notes, 68 evidence captures, 2 plans, research) has
been migrated into ~/OpenFUT-Vault, the curated Obsidian vault, which is now the sole
home for project documentation. Merges preserved all detail (obsolete material kept
under "Superseded" sections); evidence/plans were copied byte-identical; every migrated
note records its Source: docs/<original>.md provenance. Vault commit f55a5ba.

Documentation lives in the vault from here on. Code/script comments that still reference
docs/ paths are stale pointers only (no build dependency); they can be repointed at the
vault opportunistically. References to fifa17-recon/docs/ are a different tree and are
unaffected.
 2026-08-18 16:26:44 +00:00
funman300 5c40b4993f docs: mark the FUT Squad Update cert fix applied (fbc0da2) 
Updates status from root-caused to fixed, and records that option 1 (IP SAN) was
taken across the three cert generators, with the verification and the operator-gated
production rebuild that remains.
 2026-08-18 15:58:18 +00:00
funman300 fbc0da2a1b fix(fifa17-tls): carry the advertised IP in the roster/redirector cert SAN 
The FUT hub failed to load with "An error occurred downloading the FUT Squad
Update" because the client dials the roster (https://<advertise>:8081) and the
redirector BY IP, while the served certificate carried DNS SANs only
(winter15.gosredirector.ea.com + wildcards). The client aborts that handshake with
fatal certificate_unknown. Root cause and evidence in
docs/FIFA17_FUT_SQUAD_UPDATE_TLS.md (commit 082246c): a wire capture shows the client
offering TLS1.2 with RSA suites, the server selecting them, then rejecting the cert —
and autopatch demonstrably patched both ProtoSSL gates in that process, so this
validation path is NOT one of the two the client-side patch covers. The SAN is the fix.

Three generators produced the cert and none put the advertised IP in the SAN:

* docker entrypoint.sh — the production path. The advertised IP is a RUNTIME value
  (OPENFUT_ADVERTISE), unknown at image-build time, so the cert is now reconciled at
  startup: reissued with IP:$ADV,IP:127.0.0.1 in the SAN only when the current cert
  lacks it. That makes a restart reuse the same cert (no per-start fingerprint churn,
  which would otherwise recreate the Aug-13 surprise) and self-heal if $ADV changes.
* Dockerfile — installs openssl unconditionally so the entrypoint can reissue at
  runtime (previously it was dropped with the apt lists), and bakes a loopback-IP
  baseline cert so a plain `docker build` still yields a usable image.
* openfut-fut.sh — the local orchestrator. ensure_cert now defaults the SAN IP to this
  host's primary LAN IP (OPENFUT_ADVERTISE overrides) and reissues when the cert lacks
  it, instead of only generating when the file is absent.

Verified without the client, which is the strongest evidence obtainable here: a
verifying TLS client checking the cert BY IP rejects the old DNS-only cert ("IP address
mismatch, certificate is not valid for '10.10.0.120'") and accepts the new
IP-bearing cert; and the entrypoint reconcile is idempotent end to end — an old cert is
reissued to carry IP:$ADV, a simulated restart leaves the fingerprint unchanged, and
the final SAN carries both the advertised and loopback IPs.

Live confirmation needs the production container rebuilt with OPENFUT_ADVERTISE set
(operator-gated); production is otherwise untouched.

entrypoint.sh carries unrelated pre-existing uncommitted work (env-based component
selection) that is not on any branch; only the cert-reconcile block is committed here,
and that work is left intact in the working tree.
 2026-08-18 15:57:19 +00:00
258 changed files with 61717 additions and 17229 deletions
Expand all files Collapse all files
.env.example
+25
View File
@@ -0,0 +1,25 @@
# OpenFUT Docker stack configuration. Copy to .env and adjust.
# All values have sensible defaults in docker-compose.yml; override as needed.
# --- Container registry (Gitea) ---
# Images resolve to ${REGISTRY}/${NAMESPACE}/<image>:${TAG}
# e.g. git.aleshym.co/openfut/openfut-core:latest
REGISTRY=git.aleshym.co
NAMESPACE=openfut
TAG=latest
# --- Networking ---
# Where the bridge (FIFA client entry point) is published. 0.0.0.0 = all
# interfaces so LAN clients can connect. Set to a specific IP to restrict.
BRIDGE_PUBLISH=0.0.0.0
# Where core's REST API is published. 127.0.0.1 keeps it host-local (the bridge
# still reaches it over the internal docker network). Set 0.0.0.0 to expose it.
CORE_PUBLISH=127.0.0.1
# --- Behaviour ---
# Bridge returns placeholder JSON + captures unknown routes when true.
PLACEHOLDER_MODE=true
# --- Logging (RUST_LOG filters) ---
CORE_LOG=openfut_core=info,tower_http=info
BRIDGE_LOG=openfut_bridge=info,tower_http=info
AGENTS.md
+163
View File
@@ -0,0 +1,163 @@
# AGENTS.md — OpenFUT
**Read this first.** It is the entry point for AI-assisted work on OpenFUT. It supersedes the
root `README.md` and `CLAUDE.md`, which are **stale** (they describe an earlier FIFA 23 plan).
## Project
OpenFUT is a preservation / private-server project that restores **offline, single-player FIFA
Ultimate Team (FUT)** after EA retired the online servers. You must own the game legitimately; the
project does not bypass ownership checks — it only re-serves the dead online services locally.
**Current active target: FIFA 17 (PC).** A clean-room emulation of the full online + FUT stack
was proven working end-to-end on **2026-08-01** (auth → Blaze login → device-trust → FUT hub).
This lives in `fifa17-recon/`. The FIFA 17 work is explicitly the **Rosetta Stone for FIFA 23**
(identical Blaze/LSX/UTAS wire format), so FIFA 23 remains the eventual second target.
Three moving parts, kept strictly separate:
- **The FIFA client** — the retail game (FIFA 17 now). Unmodified except live cert-verify patches.
- **The emulation layer** — Python responders in `fifa17-recon/tools/` (LSX, Blaze, UTAS, roster)
that impersonate EA's online services on localhost. This is where all reverse engineering lives.
- **OpenFUT Core** — a game-independent REST FUT economy backend (`openfut-core/`), feature-complete
and tested. Knows nothing about FIFA. Intended to eventually back the emulation layer's FUT data.
> The emulation layer and Core are **not yet wired together.** The FIFA 17 UTAS server currently
> serves its own hardcoded/JSON payloads, not Core's API. See `docs/PROJECT_STATE.md`.
## Repository map
Monorepo. `openfut-core`, `openfut-bridge`, `openfut-launcher`, `fifa-blaze` are **git submodules**
(each with independent history — use `tea`/Gitea, not `gh`). `fifa17-recon/` is a plain directory.
| Path | What it is | Status |
|---|---|---|
| `fifa17-recon/` | **The live path.** FIFA 17 offline FUT emulation: Python responders, cert patcher, runbook, RE write-ups. | Working |
| `openfut-core/` | Rust (Axum + SQLite) FUT economy backend. Game-independent REST API. | Working, tested |
| `openfut-bridge/` | Rust FIFA 23 in-process hook / proxy RE effort. | Blocked (see below) |
| `fifa-blaze/` | Rust Blaze protocol emulator scaffold for FIFA 23 (capture stub). | Milestone 1 stub |
| `openfut-launcher/` | Rust egui/eframe desktop launcher (targets FIFA 23 hook flow). | Legacy plan |
| `docs/` | **Mirrors** of the vault (`OpenFUT-Vault`), which is canonical. Direction pivots + context. | — |
| `tools/` | Host-side RE helpers (file-watch-diff, exporters, squad-injector) from the FLE-bridge idea. | Legacy plan |
| `setup.sh` | FIFA 23 full-stack orchestrator (core+bridge). | Legacy plan |
**Legacy vs live:** the project pivoted twice — (1) FIFA 23 Blaze backend → (2) FIFA 23 as a match
renderer driven by an FLE Lua bridge (`docs/direction.md`) → (3) **FIFA 17 full online emulation,
which succeeded and is now the primary path** (`fifa17-recon/`). Treat `openfut-bridge`,
`openfut-launcher`, `fifa-blaze`, `tools/`, `setup.sh`, and `docs/direction.md` as historical unless
a task explicitly targets the FIFA 23 port.
## Architecture (live path)
```
FIFA 17 client (Wine/Proton, base 0x140000000)
│ autopatch.py NOPs two ProtoSSL cert-verify gates in /proc/PID/mem
├─ LSX 127.0.0.1:4216 → lsx_responder_v2.py (Origin login/profile/authcode)
├─ TLS 127.0.0.1:42127 → blaze_responder_v3b.py (Blaze redirector, via DNAT of 159.153.51.20)
├─ Blaze 42130 / Nucleus 42131 → blaze_responder_v3b.py (Fire2/Heat2 binary + login)
├─ easw.easports.com (→127.0.0.1) :8099 → utas_server.py (UTAS/RS4 FUT API + device-trust)
└─ roster :8081 → roster_server.py (FUT roster-update XML)
OpenFUT Core (openfut-core, :8080) ── clean REST FUT economy ── NOT YET CONNECTED to the above
```
Host arming (`root_arm.sh` via `pkexec`, volatile across reboot): `ptrace_scope=0`,
`route_localnet=1`, iptables DNAT `159.153.51.20→127.0.0.1:42127`, `/etc/hosts easw.easports.com`.
## Development commands (verified)
**FIFA 17 emulation** (from `fifa17-recon/tools/`):
- Start everything (idempotent; re-run after reboot): `./openfut-fut.sh start`
- Status / stop / restart: `./openfut-fut.sh status | stop | restart`
- Then launch the game fresh (`~/Desktop/launch-fifa17.sh`) and pick Ultimate Team.
- Logs: `/tmp/{lsx,blaze,roster,utas,autopatch}.log`
- Full procedure + gate-ladder troubleshooting: `fifa17-recon/FUT-RUNBOOK.md`
**OpenFUT Core** (from `openfut-core/`): `cargo run` (creates `openfut.db`) · `cargo test`
(full in-memory integration suite; requires `data/`) · `cargo test <name>` for one ·
`cargo clippy -- -D warnings` · `cargo fmt`. Env: `LISTEN_ADDR` (127.0.0.1:8080), `DATABASE_URL`
(sqlite://openfut.db), `DATA_DIR` (data).
**Other Rust crates** (`openfut-bridge`, `fifa-blaze`, `openfut-launcher`): standard
`cargo run/build/test/clippy/fmt` from within each. `fifa-blaze` is a workspace (`--bin blaze-server`).
**CI:** only `openfut-core` has it (`.gitea/workflows/ci.yml`): `fmt --check`, `clippy -D warnings`,
`build --locked`, `test --locked` on push/PR to main. No CI on the other crates or the recon dir.
There is **no install step, no Docker, no JS/TS frontend, no typecheck** in this repo. Do not invent them.
## Coding conventions
- **Rust (Core):** Axum 0.7 + SQLx 0.7 (SQLite, compile-time-checked queries). Strict layering —
`routes/` (handlers, extract state, call services) → `services/` (own **all** DB access + logic)
→ `models/` (pure `Serde`/`FromRow` data). Errors via `AppError` (`src/error.rs`) with
`IntoResponse`. One file per domain across `routes/`, `services/`, `models/`. **Single-profile
design:** every service reads "the active profile" as the first DB row — intentional, don't
parameterize it. Content is data-driven: JSON under `data/` loaded at startup into Arc registries
in `AppState`. Add content by dropping JSON files, not code. Migrations are numbered SQL in
`migrations/`. Keep `clippy -D warnings` and `fmt` clean (CI enforces).
- **Python (recon):** stdlib-only servers, no framework. Each responder is a standalone script with
the reverse-engineered contract documented in its module docstring (byte offsets, VAs, symbol
names). When changing a responder, preserve byte-exactness — the client is the oracle.
- **Clean-room, always.** Every finding derives from binaries we own + live observation. **Never**
use, reference, or reproduce leaked EA source. If a task seems to need it, stop and say so.
## AI-agent rules
1. Read this file before exploring the repo.
2. Read the vault file relevant to the task (`../OpenFUT-Vault/`), not the whole tree. Repo
`docs/` files are mirrors of the vault — consult them for the same content, but treat the
vault as canonical.
3. Don't scan the whole repository unless the knowledge base is clearly stale — if you find it
stale, update the vault, then its repo `docs/` mirror.
4. Search the specific directory (`fifa17-recon/`, `openfut-core/src/<layer>/`) before a repo-wide search.
5. Update the vault when architecture materially changes (and sync the matching `docs/` mirror).
6. Don't refactor or rewrite unrelated working code.
7. Prefer small, testable changes; run the narrowest relevant test first (`cargo test <name>`).
8. **Never invent EA/FIFA/Blaze protocol behavior.** Values you don't know are `TODO/CONFIRM`, not
confident guesses. The live client is the only oracle for whether a gate is satisfied.
9. Clearly separate discovered behavior from hypotheses; record findings in
`../OpenFUT-Vault/02 Reverse Engineering/FIFA 17/Protocol Findings.md` under the right confidence
tier — never silently promote a hypothesis to a fact.
10. Root `README.md` / `CLAUDE.md` and `openfut-bridge/CLAUDE.md` describe superseded FIFA 23 plans;
prefer vault + repository evidence over them when they conflict.
## AI Session Bootstrap
Future agents should start with:
1. Read `AGENTS.md`.
2. Read the vault README (`../OpenFUT-Vault/README.md`) to locate the canonical files.
3. Identify the subsystem the task affects and read the corresponding vault file: Architecture,
Project State, Roadmap/Current Priorities, or Protocol Findings.
4. Inspect only the relevant source directories.
5. Check `../OpenFUT-Vault/02 Reverse Engineering/FIFA 17/Protocol Findings.md` before assuming
anything about FIFA/EA behavior.
6. Check `../OpenFUT-Vault/06 Agent Memory/Project State.md` before assuming a feature exists.
7. Implement the smallest coherent change.
8. Run the narrowest relevant tests.
9. Update the vault (and its repo `docs/` mirror) only if the change makes existing knowledge
inaccurate.
Do not reread the entire repository during every session.
## OpenFUT Knowledge Base
**The OpenFUT Vault is the canonical project knowledge base.** Repo `docs/` files mirror it; the
vault wins on any disagreement. Consult it before starting substantial work and update it after
durable discoveries.
Vault location: `../OpenFUT-Vault/` — start at `../OpenFUT-Vault/README.md`.
Canonical files:
- Dashboard: `00 Dashboard/OpenFUT.md`
- Architecture: `01 Architecture/Architecture.md` (repo mirror `docs/ARCHITECTURE.md`)
- RE findings: `02 Reverse Engineering/FIFA 17/Protocol Findings.md`
(repo mirror `docs/research/KNOWN_FINDINGS.md`)
- Direction history: `04 Decisions/Direction History.md`
- Project State: `06 Agent Memory/Project State.md` (repo mirror `docs/PROJECT_STATE.md`)
- Current Priorities: `06 Agent Memory/Current Priorities.md`
- Known Issues: `06 Agent Memory/Known Issues.md`
- Important Discoveries: `06 Agent Memory/Important Discoveries.md`
- Roadmap: `08 Roadmap/Roadmap.md` (repo mirror `docs/ROADMAP.md`)
When editing knowledge that exists in both places, edit the vault first, then update the matching
`docs/` mirror so they stay in sync.
CLAUDE.md
+2
View File
@@ -2,6 +2,8 @@
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
> ⚠️ **Stale (FIFA 23).** This file's status and targets predate the FIFA 17 pivot. Prefer [`docs/PROJECT_STATE.md`](./docs/PROJECT_STATE.md) (canonical). The working target is **FIFA 17**; the canonical server is `fifa17-recon/docker/fifa17-python` (`docker compose up -d`). `openfut-bridge` (FIFA 23) is superseded; `openfut-core` remains the shared backend.
## Repository Layout
This is a monorepo containing three independent Rust crates as git submodules:
Cargo.lock
Generated
+1
View File
@@ -3210,6 +3210,7 @@ dependencies = [
"serde",
"serde_json",
"sqlx",
"tempfile",
"thiserror 1.0.69",
"tokio",
"tower 0.5.3",
README.md
+4
View File
@@ -1,5 +1,9 @@
# OpenFUT
> ⚠️ **Status — see [`docs/PROJECT_STATE.md`](./docs/PROJECT_STATE.md) (canonical).** The working, actively-developed target is **FIFA 17**, not FIFA 23. Everything below this banner describes the **superseded FIFA 23 `bridge` lineage** and is kept for historical context.
>
> **Run the server (canonical):** `cd fifa17-recon/docker/fifa17-python && docker compose up -d` — see [`fifa17-recon/FUT-RUNBOOK.md`](./fifa17-recon/FUT-RUNBOOK.md). `openfut-core` is the shared offline backend (still used by the FIFA 17 path); `openfut-bridge` is the retired FIFA 23 integration.
**Offline Ultimate Team — like SPT, but for FIFA 23.**
OpenFUT replaces EA's retired FUT servers with a fully offline, single-player backend. You own FIFA 23 legitimately. You just want to keep playing after EA shut down the servers.
docker-compose.yml
+93
View File
@@ -0,0 +1,93 @@
# ============================================================================
# ⚠️ LEGACY (FIFA 23 lineage). This compose runs core + bridge for the
# superseded FIFA 23 direction. It is NOT the canonical server bring-up.
#
# Canonical server (FIFA 17):
# cd fifa17-recon/docker/fifa17-python && docker compose up -d
# (runbook: fifa17-recon/FUT-RUNBOOK.md)
#
# `core` (openfut-core) IS still the shared, game-independent backend and is
# used by the FIFA 17 UTAS host (OPENFUT_CORE_URL). `bridge` (openfut-bridge)
# is the retired FIFA 23 integration, kept for reference.
# Status source of truth: docs/PROJECT_STATE.md
# ============================================================================
# OpenFUT server stack — offline FUT backend (Core) + FIFA proxy (Bridge).
#
# Bring up: docker compose up -d
# Tear down: docker compose down (keeps data/captures volumes)
# Wipe state: docker compose down -v (also drops volumes)
# Rebuild: docker compose build (or ./scripts/registry.sh build)
# Logs: docker compose logs -f
#
# Images are pulled from / pushed to the Gitea container registry. Override the
# registry, namespace, or tag in .env (see .env.example). When REGISTRY is set,
# `up` pulls prebuilt images; the build: blocks let you rebuild locally too.
name: openfut
services:
core:
image: ${REGISTRY:-git.aleshym.co}/${NAMESPACE:-openfut}/openfut-core:${TAG:-latest}
build:
context: ./openfut-core
dockerfile: Dockerfile
restart: unless-stopped
environment:
LISTEN_ADDR: 0.0.0.0:8080
DATABASE_URL: sqlite:///app/db/openfut.db
DATA_DIR: /app/data
RUST_LOG: ${CORE_LOG:-openfut_core=info,tower_http=info}
volumes:
- core-db:/app/db
# Bound to localhost by default — the bridge reaches core over the internal
# network, so core need not be world-exposed. Set CORE_PUBLISH=0.0.0.0 in
# .env if you want to hit the REST API directly from other hosts.
ports:
- "${CORE_PUBLISH:-127.0.0.1}:8080:8080"
networks:
- openfut
healthcheck:
test: ["CMD", "curl", "-fsS", "http://127.0.0.1:8080/health"]
interval: 15s
timeout: 4s
retries: 5
start_period: 10s
bridge:
image: ${REGISTRY:-git.aleshym.co}/${NAMESPACE:-openfut}/openfut-bridge:${TAG:-latest}
build:
context: ./openfut-bridge
dockerfile: Dockerfile
restart: unless-stopped
depends_on:
core:
condition: service_healthy
environment:
BRIDGE_LISTEN_ADDR: 0.0.0.0:8443
CORE_URL: http://core:8080
CAPTURES_DIR: /app/captures
PLACEHOLDER_MODE: ${PLACEHOLDER_MODE:-true}
TLS_ENABLED: "true"
RUST_LOG: ${BRIDGE_LOG:-openfut_bridge=info,tower_http=info}
volumes:
- bridge-captures:/app/captures
# The FIFA client connects here — publish on all interfaces by default so
# LAN clients (e.g. 10.10.0.0/24) can reach it.
ports:
- "${BRIDGE_PUBLISH:-0.0.0.0}:8443:8443"
networks:
- openfut
healthcheck:
test: ["CMD", "curl", "-fsSk", "https://127.0.0.1:8443/_bridge/health"]
interval: 15s
timeout: 4s
retries: 5
start_period: 8s
networks:
openfut:
driver: bridge
volumes:
core-db:
bridge-captures:
docs/CARD_TAXONOMY.md
-142
View File
@@ -1,142 +0,0 @@
# FIFA 17 FUT — Card Taxonomy (single source of truth)
Status: verified 2026-08-12. This document supersedes every earlier scattered
taxonomy claim in the repo (see "Superseded taxonomy" at the bottom).
Evidence labels: **OBSERVED** = read directly from a shipped table or decompiled
function; **INFERRED** = derived from OBSERVED facts; **HYPOTHESIS** = plausible,
not yet proven. `UNKNOWN` is a valid answer and is stated as such.
## Provenance
- Authoritative tables: `10.10.0.105:/home/alex/Documents/OpenFUT/fifa17-recon/data/tables/`,
copied byte-identical into this repo at `fifa17-recon/data/tables/`.
SHA-256 manifest + verification: `docs/evidence/fifa17-recon/table-hashes.sha256`
(36 files: 31 `fcc_*.json` + 5 staff tables; combined hash-of-hashes
`10f239add919089354d8dbff873fc9737b0a0f80f6ac41b1aa2a096c0ec8d331`).
- Each table file is a DECODED dump `{table, source, rowcount, schema[], rows[]}`;
card instances are in `rows[]`, one object per card. Row counts and id ranges
below were re-extracted from the in-repo `.120` copies.
- Semantic (subtype→kind) labels are decompiler-derived, carried in
`fifa17-recon/tools/fut_consumables.py` (`BY_SUBTYPE`, `_DOC`), generated by
`tools/build_consumables.py` from `FUN_1800d8330`, `FUN_18013f4d0`,
`FUN_1801bfac0`, `FUN_1801aa230`, `FUN_180048780` + the fcc tables.
- Staff family selection: `fifa17-recon/docs/CARD_SYSTEM.md` (2026-08-04/05 blocks)
and `fifa17-recon/tools/fut_staff.py` / `fut_coaches.py`.
## Family selector (OBSERVED, binary)
Before registering an item, `FUN_180141660` merges the client's local DB. It
switches on record `+0x4c` (`cardtype`), which `FUN_1800d8330` derives from JSON
atom `0x6c cardsubtypeid` alone:
```
cardsubtypeid 0..3 -> cardtype 1 players
4 -> cardtype 2 managercards
5 -> cardtype 3 headcoachcards
6 -> cardtype 10 gkcoachcards
7 -> cardtype 5 physiocards
8 -> cardtype 4 fitnesscoachcards
0x1e,0x1f,0x91..0x96,0xe7..0xe9,0xec -> cardtype 9 club items + misc
absent (default 342) -> cardtype 0 no merge
```
Key: `carddbid == resourceId` for non-player families (queried RAW, no mask);
players are queried by `playerid = resourceId & 0xffffff` (atom `0x287`), and
`assetId` (atom `0x23`) is never read by the merge.
## Consumable & staff families — evidence table (OBSERVED, `.120` tables)
| Family | Table | Rows | carddbid range | cardsubtype set | cardassetid (ART) |
|---|---|---|---|---|---|
| Contracts | `fcc_contractcards.json` | 13 | 5001001–5001013 | {201, 202} | {7, 8} |
| Fitness + Healing | `fcc_healingcards.json` | 27 | 5002001–5002030 | {211,212,213,215,216,217,218,219,220} | {9, 10} |
| Training (6 sub-families) | `fcc_trainingcards.json` | 143 | 5003001–5003159 | 51-57, 61-67, 91-110, 121-136, 250-273, 300-340 | {1,3,32,34,35,50,51} |
| Misc | `fcc_misccards.json` | 42 | 5004001–5004042 | {231, 232, 233, 236} | {43, 44, 45, 46} |
| Badges | `fcc_badgecards.json` | 656 | 6000000–6000656 | (none in row) | {39} |
| Stadiums | `fcc_stadium.json` | 78 | 6200000–6200077 | (none in row) | {36} |
| Kits | `fcc_kitcards.json` | 1482 | 6300000–6400654 | (none in row) | {35} |
| League logos | `fcc_leaguelogos.json` | 44 | 8010000–8010044 | (none in row) | {40} |
| League logo stickers | `fcc_leaguelogostickers.json` | 39 | 8010000–8010039 | (none in row) | {40} |
| Balls | `fcc_balls.json` | 42 | 8120194–8120236 | (none in row) | {37} |
| Managers | `managercards.json` | 417 | 1000001–1001552 | (staff; by cardsubtypeid 4) | (assetid col) |
| Head coaches | `headcoachcards.json` | 124 | 2000004–2000328 | (staff; subtype 5) | — |
| GK coaches | `gkcoachcards.json` | 121 | 9000001–9000324 | (staff; subtype 6) | — |
| Physios | `physiocards.json` | 51 | 4000002–4000259 | (staff; subtype 7) | — |
| Fitness coaches | `fitnesscoachcards.json` | 115 | 3000019–3000328 | (staff; subtype 8) | — |
Notes:
- **Contracts (5001xxx)** — 201 = player_contract, 202 = manager_contract
(OBSERVED, `BY_SUBTYPE`).
- **Fitness + Healing (5002xxx)** — subtype **214 is a valid enum value but ships
ZERO rows** (OBSERVED: 214 absent from `rows[]`). Enum split (OBSERVED,
`BY_SUBTYPE`): healing = 211-218, player_fitness = 219, squad_fitness = 220.
The `+0x58 rareflag == 1` trap flips subtype 219 to squad-fitness.
- **Training (5003xxx)** — SIX sub-families, all OBSERVED in `rows[]` and labelled
in `BY_SUBTYPE`:
- `gk_training` 51-57 (7)
- `player_training` 61-67 (7)
- `position_mod` 91-110 (20)
- `formation_mod` 121-136 (16)
- chem/play styles 250-273 (24): `player_playstyle` 250-268 (19) +
`gk_playstyle` 269-273 (5)
- `manager_league` 300-**341** in the client enum (42), but the shipped table
contains only 300-340 (41 rows) — 341 is defined, not shipped.
- Client enum also defines vestigial/unshipped ranges NOT in the table:
`manager_formation_mod` 71-86, and `DEAD_ZONE`
58-60,68-70,87-90,111-120,203-210 (28). These have no rows.
- **Misc (5004xxx)** — subtypes {231,232,233,236}; cardassetid ART 43-46.
cardsubtype 231 = 0xe7 anchors the 0xe7..0xe9 block to misc via `FUN_1800d8330`.
- **Club items (badges/stadiums/kits/logos/balls)** carry no `cardsubtype` in the
row; they are keyed by `carddbid` range and distinguished on the wire by ART
`cardassetid` (badges 39, stadium 36, kits 35, logos 40, balls 37). **Kits live
at 6300000–6400654 and are NOT badges** (badges are 6000xxx). The client-side
subtype→family map (which of 0x1e,0x1f,0x91..0x96 is ball vs stadium vs badge vs
kit) is **UNKNOWN** — it is in none of the dumped tables and cardtype 9 has no
miss-fill arm (see `CARD_SYSTEM.md`, "Club items", 2026-08-05).
## Staff — subtype/cardtype selectors (OBSERVED, binary)
| cardsubtypeid | cardtype | Family | Table | Rows | carddbid range |
|---|---|---|---|---|---|
| 4 | 2 | Manager | `managercards.json` | 417 | 1000001–1001552 |
| 5 | 3 | Head coach | `headcoachcards.json` | 124 | 2000004–2000328 |
| 6 | 10 | GK coach | `gkcoachcards.json` | 121 | 9000001–9000324 |
| 7 | 5 | Physio | `physiocards.json` | 51 | 4000002–4000259 |
| 8 | 4 | Fitness coach | `fitnesscoachcards.json` | 115 | 3000019–3000328 |
`cardsubtypeid -> rec+0x50` is the only family selector; `FUN_1800d8330` maps it to
`rec+0x4c cardtype`. Manager merge = `FUN_1801356c0` (queries `managercards` by
`carddbid` raw); coach merges live in the respective tables (`fut_coaches.py`).
All five render live with real photos/bonuses, zero "DB Error" (CARD_SYSTEM.md,
2026-08-05).
## Players (context, out of taxonomy scope here)
Players use cardsubtypeid 0..3 -> cardtype 1; merged by `playerid = resourceId &
0xffffff` against the local `players` table. Identity/name/nation/team come from
the client DB; rating/position/attributes come from our item JSON. See
`CARD_SYSTEM.md` and the migration work in `openfut-adapter-fifa17`.
## Superseded taxonomy (report only — no other files edited)
The earlier working taxonomy (in prior agent-session notes / long-term memory, and
partially in the original `TablesTaxonomy` scout output) got four things wrong.
Corrected here:
1. **Chemistry / play styles are 250-273, NOT 91-136.** 91-110 = `position_mod`,
121-136 = `formation_mod`. (OBSERVED in `fcc_trainingcards` + `BY_SUBTYPE`.)
2. **6300xxx/6400xxx are KITS, not badges.** Badges are 6000xxx. (OBSERVED.)
3. **5004xxx misc cards exist** (subtypes 231/232/233/236, ART 43-46). Previously
omitted. (OBSERVED, `fcc_misccards`.)
4. **8010xxx league logos exist** (+ stickers), ART 40. Previously omitted.
(OBSERVED, `fcc_leaguelogos`.)
**Repo blast-radius of the superseded values: NONE.** A repo-wide grep
(`docs/`, `openfut-adapter-fifa17/`, `openfut-core/`, `fifa17-recon/`) for the wrong
claims (`91-136` chem styles; `6300/6400xxx` as badges) returns zero hits.
`fifa17-recon/docs/CARD_SYSTEM.md` and `plan-2026-08-06-card-subsystem.md` already
use the correct `250..273` for chem styles and the correct staff subtypes 4-8;
`CARD_SYSTEM.md` is a mechanism log, not a taxonomy, and asserts none of the wrong
ranges. The superseded values therefore live only in non-repo agent memory, which
should be corrected to point at this document.
docs/CORE_CORRECTNESS_ISSUES.md
-175
View File
@@ -1,175 +0,0 @@
# openfut-core — Correctness Issues (audit 2026-08-17)
Read-only audit of `openfut-core` (game-agnostic axum + SQLite/sqlx economy authority).
Four reported issue classes confirmed with exact `file:line` evidence, **plus a bonus
HIGH-severity SBC duplicate-card economy exploit**. Nothing here is fixed yet —
fixing bumps Core off the frozen P1 reference (`fbb54ea`, the current known-good
production Core) and one item needs a DB migration + prod backfill, so this needs a
**go/no-go** before rebuild+redeploy.
> **Zero live users right now**, so the HIGH-severity economy exploits are not
> currently exploitable — but they are the exact class (coin overspend + card
> duplication) that crashed live clients earlier (project memory), so they should be
> fixed before any real play.
## Architecture context (why the bugs cluster)
Two generations of economy code coexist:
- **NEW** `services/economy.rs` + `routes/economy.rs` — **fully atomic + validated**:
every compound op acquires a connection, `BEGIN IMMEDIATE`, composes
transaction-scoped primitives (`debit`/`credit`/`add_item`/`remove_item`/
`consume_entitlement`), commits/rolls back via `finish()`, rejects negative amounts,
and has an extensive in-module test suite. **This is the reference fix pattern.**
- **OLD** per-feature services (`club`, `pack`, `market`, `sbc`, `checkin`, `upgrades`,
`match_service`, `season`) — predate it, still do read/check/write directly against
the `&Pool` with each statement on its own connection: no transaction. `economy.rs`'s
own module doc explicitly warns these "cannot offer that guarantee".
Issues 2 and 3 live entirely in the OLD generation; the fix is to route them through
`economy.rs`'s proven atomic ops (or give the pool helpers `&mut SqliteConnection`
transactional variants). Request flow is `X-OpenFUT-Game` header → active profile →
club → service; clients never pass a `club_id`, so cross-club access is **not** a
vector — the risks are intra-club concurrency + unvalidated payloads.
---
## Issue 1 — `sbc_submissions` missing `club_id` (milestone always 0) · **LOW**
- **Root cause:** `migrations/0001_initial.sql:96-102` creates `sbc_submissions(id,
profile_id, sbc_id, submitted_card_ids, passed, submitted_at)` — no `club_id`, and no
later migration adds one. But `src/routes/club.rs:94-99` (`get_milestones`) runs
`SELECT COUNT(*) FROM sbc_submissions WHERE club_id = ? AND passed = 1`. SQLite errors
`no such column: club_id`; the error is swallowed by `.unwrap_or(0)` → the
`sbcs_completed` milestone is **always 0**. Writer `services/sbc.rs:74-83` inserts
`profile_id`, not `club_id`.
- **Impact:** wrong milestone stat only. No crash, no economy corruption.
- **Fix (matches the ticket — needs migration + backfill):** new migration `0019`:
`ALTER TABLE sbc_submissions ADD COLUMN club_id TEXT;` then backfill
`UPDATE sbc_submissions SET club_id = (SELECT c.id FROM clubs c WHERE c.profile_id =
sbc_submissions.profile_id);` and bind `club_id` in `sbc.rs:submit_sbc`'s INSERT
(`club_id` is already a param at `sbc.rs:41`).
- **Simpler alternative (no migration):** change the `club.rs:95` query to
`WHERE profile_id = ?` (column already exists). Ticket asks for the column, so both
are recorded.
- **Migration required:** YES (for the ticket's fix); NO (for the alternative).
## Issue 2 — Non-atomic check-then-act economy mutations (TOCTOU) · **HIGH**
Each does read → check → write across multiple pool round-trips with no
`BEGIN IMMEDIATE`, so concurrent requests race → overspend / duplication / double reward:
| Site | Race |
|---|---|
| `services/club.rs:88-115` `spend_coins` | SELECT coins → `if balance<amount` → UPDATE; two concurrent spends both pass → **overspend / negative balance**. Shared primitive used by all callers below. |
| `services/pack.rs:58-141` `open_pack` | read `pack.opened` → INSERT cards loop → UPDATE opened=1; concurrent double-open → **card duplication** |
| `services/pack.rs:144-160` `buy_pack` | `spend_coins` then `grant_pack`, separate ops → crash between = coins gone, no pack |
| `services/market.rs:129-186` `buy_listing` | SELECT sold=0 → spend → UPDATE sold=1 → INSERT; concurrent double-buy → **two cards minted** |
| `services/market.rs:188+` `sell_card` | SELECT owned → DELETE → add_coins; concurrent double-sell → **double credit** |
| `services/sbc.rs:35-107` `submit_sbc` | validate → DELETE cards → INSERT submission → add_coins/grant_pack; same cards to two SBCs → **double reward** |
| `services/checkin.rs:60-120` `claim` | SELECT last → same-day check → reward → INSERT; concurrent → **double claim** |
| `services/upgrades.rs:64-95` `change_position` | fetch → spend_coins → UPDATE |
| `services/match_service.rs:97-235` + `season.rs` reward | many sequential writes; partial failure leaves partial rewards |
- **Impact:** corrupts economy state (coin overspend + card duplication).
- **Fix:** wrap each compound op in one `BEGIN IMMEDIATE`…`finish()` transaction
exactly as `services/economy.rs:214-236` already does; route pack/market/sbc/checkin/
upgrades through `economy.rs`'s composed atomic ops (or add `&mut SqliteConnection`
variants of `spend_coins`/`add_coins`/`grant_pack`/`add_item`).
- **Migration required:** NO (code-only).
## Issue 3 — Missing input validation: SBC duplicate-card exploit · **HIGH**
- **Root cause:** `services/sbc.rs:53-70` iterates `req.owned_card_ids` with **no dedup
and no length bound**. The same `owned_card_id` repeated N times resolves the same card
N times (each `fetch_optional` succeeds); `validate_sbc` (`sbc.rs:110-116`) counts it
toward `squad_size` and passes; the DELETE loop deletes it once → **a user satisfies
any SBC with ONE card duplicated → free rewards**. Entry point `routes/sbc.rs:30-49`
forwards `req` unvalidated. Unbounded Vec length is also a DoS.
- **Fix:** in `submit_sbc`, reject duplicate ids (collect into a `HashSet`, compare
`len`) and bound the list (e.g. ≤ 30) before resolving → `AppError::BadRequest`.
- **Already-good validation (no change):** `economy.rs:64-67,84-87` reject negative
amounts; `match_service.rs:100-104` clamps goals 0..99; `upgrades.rs` validates
boost 1..3 / positions. Minor: `routes/economy.rs post_grant_reward` forwards an
unbounded `amount` (trusted host caller; add an upper-bound sanity guard).
- **Migration required:** NO.
## Issue 4 — `season.rs` panics + checkin index panic · **LOW**
- **Root cause:** `services/season.rs` `.expect()` on `fetch_optional` Options at
`:23` (`get_or_create`), `:69` and `:144` (`record_match`) — panic if the `seasons`
row is absent when expected. `seasons.profile_id` is PRIMARY KEY
(`migrations/0006_seasons_loans_packs.sql:2`), so the concurrent-insert case surfaces
as a UNIQUE error via `?` (not the panic), lowering probability — but it still
panics-on-invariant, aborting that request (axum → 500 for the request; not a full
server crash).
- **Secondary:** `services/checkin.rs:~52,~88` index `STREAK_COINS[idx]` with
`idx = ((streak-1)%7) as usize`; Rust `%` can be negative → a corrupt/negative
persisted `streak_day` yields a negative index → **panic**.
- **Fix:** replace each `.expect(...)` with
`.ok_or_else(|| AppError::Internal("season row missing".into()))?`; guard the checkin
index with `.rem_euclid(7)` (or clamp `streak_day >= 1` on read).
- **Migration required:** NO.
---
## Fix plan summary
| Issue | Severity | Migration | Files |
|---|---|---|---|
| 1 sbc_submissions club_id | LOW | YES (or none via alt) | `migrations/0001` (+new 0019), `routes/club.rs`, `services/sbc.rs` |
| 2 non-atomic mutations | HIGH | NO | `services/{club,pack,market,sbc,checkin,upgrades,match_service,season}.rs` → route through `services/economy.rs` |
| 3 SBC duplicate-card exploit | HIGH | NO | `services/sbc.rs`, `routes/sbc.rs` |
| 4 season/checkin panics | LOW | NO | `services/season.rs`, `services/checkin.rs` |
**Recommended order:** 3 (smallest, highest-value: kills the free-reward exploit) → 2
(the transactional refactor, largest) → 4 (defensive hygiene) → 1 (cosmetic; do with
the alt query unless the column is wanted).
**Deployment note:** all of these change `openfut-core`, which is currently frozen at
the P1 reference (`fbb54ea`) in production. Fixing + rebuilding + redeploying prod-core
is a deliberate step off that reference — get a go/no-go first. Only Issue 1's
column-add needs a migration + prod backfill; 2/3/4 are code-only.
---
## Resolution (2026-08-17, on `openfut-core` @ `fbb54ea` + these edits)
All four issue classes fixed in the canonical superproject submodule
`openfut-core`; full test suite green (179 tests) + clippy clean + a new
regression test `tests/integration_test.rs::test_sbc_rejects_duplicate_cards`.
| Issue | Fix | Files |
|---|---|---|
| 3 SBC dup-card exploit | dedup (`HashSet`) + `MAX_SBC_CARDS`=30 bound in `submit_sbc`, before card resolution → `BadRequest` | `services/sbc.rs` |
| 1 sbc_submissions club_id | migration `0019` adds `club_id` + backfills from `clubs`; `submit_sbc` INSERT now binds `club_id` | `migrations/0019_*.sql`, `services/sbc.rs` |
| 4 season/checkin panics | `.expect()` → `.ok_or_else(AppError::Internal)?` (3 sites); checkin index `% 7` → `.rem_euclid(7)` (2 sites) | `services/season.rs`, `services/checkin.rs` |
| 2 non-atomic mutations | statement-level compare-and-swap (see below) | `services/{club,pack,market,checkin}.rs` |
### Issue 2 — how it was fixed, and the residual
Rather than the full transaction refactor (threading `&mut SqliteConnection`
through every service), the concurrency-exploitable races were closed with
single-statement **compare-and-swap** — the atomic unit SQLite already gives us,
no transaction plumbing, minimal blast radius on the working prod economy path:
- `club::spend_coins` — `UPDATE … SET coins = coins - ? WHERE id = ? AND coins >= ?`
+ `rows_affected` guard; also rejects negative amounts. Kills **overspend** for
every caller (the shared root primitive).
- `pack::open_pack` — claims the pack (`UPDATE … opened = 1 WHERE … AND opened = 0`)
**before** minting cards; loser aborts. Kills **card duplication** via double-open.
- `market::buy_listing` — claims the listing (`sold 0→1`) before charging; releases
the claim if the debit fails. Kills **double-mint**.
- `market::sell_card` — `DELETE … WHERE id = ? AND club_id = ?` + `rows_affected`
guard before crediting. Kills **double-credit** via double-sell.
- `checkin::claim` — conditional `INSERT … SELECT … WHERE NOT EXISTS (today's row)`
+ `rows_affected` guard; pays out only if the claim landed. Kills **double-claim**.
**Residual (accepted, documented):** the *multi-statement all-or-nothing* edges that
need a real transaction to close — `pack::buy_pack` (spend then grant: a crash between
loses coins with no pack), `sbc::submit_sbc` (concurrent submits sharing cards could
double-consume mid-loop), and `match_service`/`season` reward chains (partial writes on
crash). These are **partial-failure durability edges, not statement-level races**, and
require concurrency that a single-player FIFA17 client does not generate. Closing them
is the `&mut SqliteConnection` transaction refactor originally proposed; deferred as
low-value for single-player. Overspend + duplication + double-credit — the vectors that
corrupt economy state — are all closed.
docs/FIFA17_CONTENT_COMPLETENESS.md
-79
View File
@@ -1,79 +0,0 @@
# FIFA17 Content Completeness (33-record gap)
Evidence: ContentGapMap scout vs import-input.json (persona 33068179, 1995 items),
fifa17-recon/data/tables, manifest/fifa17-import-manifest.json (OBSERVED).
## Summary
| Category | Expected | Resolvable | Unrecoverable |
|---|---|---|---|
| Legend players | 13 instances (10 defs) | 0 | 13 (need .105 Legends locale names) |
| Consumables | 17 | 17 | 0 |
| Staff | 3 | 3 | 0 |
## Consumables (17/17 RESOLVABLE — carddbid present in fcc tables; semantics from cardsubtypeid)
| wire_id | resourceId | subtype | kind | table |
|---|---|---|---|---|
| 100000239 | 5003012 | 54 | gk_training | fcc_trainingcards |
| 100000249 | 5003011 | 54 | gk_training | fcc_trainingcards |
| 100000260 | 5003004 | 52 | gk_training | fcc_trainingcards |
| 100000272 | 5003059 | 91 | position/playstyle mod | fcc_trainingcards |
| 100000250 | 5003060 | 92 | position/playstyle mod | fcc_trainingcards |
| 100000327 | 5003065 | 97 | position/playstyle mod | fcc_trainingcards |
| 100000238 | 5003066 | 98 | position/playstyle mod | fcc_trainingcards |
| 100000261 | 5003068 | 100 | position/playstyle mod | fcc_trainingcards |
| 100000316 | 5003068 | 100 | position/playstyle mod | fcc_trainingcards |
| 100000293 | 5003103 | 258 | player_playstyle | fcc_trainingcards |
| 100000326 | 5003112 | 267 | player_playstyle | fcc_trainingcards |
| 100000283 | 5003116 | 271 | gk_playstyle | fcc_trainingcards |
| 100000294 | 5001004 | 201 | player_contract | fcc_contractcards |
| 100000304 | 5001008 | 202 | manager_contract | fcc_contractcards |
| 100000305 | 5001009 | 202 | manager_contract | fcc_contractcards |
| 100000315 | 5002027 | 217 | healing | fcc_healingcards |
| 100000426 | 5002013 | 213 | healing | fcc_healingcards |
## Staff (3/3 RESOLVABLE)
| wire_id | resourceId | subtype | role | table |
|---|---|---|---|---|
| 100000271 | 3000083 | 8 | fitnesscoach | fitnesscoachcards |
| 100000427 | 3000083 | 8 | fitnesscoach | fitnesscoachcards |
| 100000282 | 9000081 | 6 | gkcoach | gkcoachcards |
## Legends (13 instances / 10 defs — UNRECOVERABLE from .120)
All defer via NoName gate (openfut-import-fifa17/src/lib.rs:476-478). 6 assets absent
from players.json; 236250/236253/236257 resolve only to placeholder nameid 24313='171918'.
dcplayernames.json/editedplayernames.json EMPTY in .120 dump. Version formula holds for all
(resourceId == (version<<24)|assetId) — so they auto-promote the instant a .105-derived
name row exists; NO code change needed, only name data.
| asset | resourceId(ver) | rareflag/rating/pos | wire copies |
|---|---|---|---|
| 169193 | 169193(v0) | 1/r87/CDM | 100000057,100000083,100000146,100000157 |
| 211029 | 211029(v0) | 1/r73/CB | 100000165 |
| 224512 | 224512(v0) | 1/r67/LB | 100000170 |
| 227403 | 227403(v0) | 1/r64/ST | 100000160 |
| 236743 | 236743(v0) | 1/r60/LB | 100000163 |
| 237510 | 237510(v0) | 1/r59/CB | 100000162 |
| 236250 | 17013466(v1) | 3/r78/ST | 100001102 |
| 236253 | 17013469(v1) | 3/r77/CAM | 100001932 |
| 236253 | 100899549(v6) | 21/r77/CAM | 100001472 |
| 236257 | 117676769(v7) | 22/r78/LM | 100001043 |
### .105 read-only verdict (PROVEN 2026-08-14) — UNRECOVERABLE, confirmed
SSH read-only to the FIFA machine (10.10.0.105). Install `/mnt/games/FIFA 17`
is retail PC (FIFA17.exe, build 2017-06-09, changelist 3175939, sku FFA17PCC).
The resident FIFA17.exe database (recon `data/tables`) shows the DLC/Legend name
tables ship ZERO rows in the retail PC build:
- `dcplayernames.json`: rowcount:0, rows_emitted:0 (nameid range 30000-35000 = DLC names)
- `editedplayernames.json`: rowcount:0, rows_emitted:0
- `playernames.json`: 24314 rows (standard players only)
FUT Legends were Xbox-One-exclusive in FIFA 17; the PC client contains no Legend
names at all. The 13 Legend instances are therefore GENUINELY UNRECOVERABLE from
any PC install (.105 == .120, same retail build) — NOT a filtering artifact and
NOT fabricated. Architecture is already correct: they auto-promote the instant a
name row is supplied (e.g. from an Xbox FIFA17 DB), with no importer code change.
## Implementation
- Consumables+staff: NEW emit path in openfut-import-fifa17 (classify already buckets;
plan_definitions only ingests PlayerCard). Add definition builders + Core CardDefinition
rows to fifa17-production-cards.json + owned instances in apply.rs. Data 100% present.
- Legends: attempt read-only .105 Legends locale research; if names recoverable add roster
rows (auto-promote). Otherwise document as unrecoverable (do NOT fabricate names).
docs/FIFA17_FUT_SQUAD_UPDATE_TLS.md
-113
View File
@@ -1,113 +0,0 @@
# FIFA 17 "FUT Squad Update" download failure — root cause
**Status:** root-caused, not yet fixed. Blocks any FIFA session pointed at a stack whose
roster server presents the current self-signed certificate.
**Symptom (client):** entering the FUT hub shows
> An error occurred downloading the FUT Squad Update. Please try again.
Recovered from the live client's memory with `scripts/client-error-string.py`, not from a
log. Nothing server-side reports an error: every UTAS route answers 200 and the Blaze
session stays healthy, answering PINGs while the client sits on the dialog.
## What it is
"Squad Update" here is the **roster update**, not the player's lineup. The Blaze responder
advertises it as the FUT loading gate (`blaze_responder_v3b.py`):
```python
ROSTER_HOST = "%s:8081" % _ADVERTISE
("ROSTERUPDATE_URL", "https://%s/fifa17/fut/rosterupdate.xml" % ROSTER_HOST)
("ROSTER_URL", "https://%s/fifa17/roster/" % ROSTER_HOST)
```
The client fetches that URL over TLS, **by IP**, from `roster_server.py`.
## Root cause
The client completes TCP, sends a ClientHello, receives the certificate, and then
**aborts the handshake itself**. Captured and decoded from the wire:
```
CLIENT: ClientHello client_version = TLS1.2
offers 8 suites: RSA_AES_256_GCM_SHA384, RSA_AES_128_GCM_SHA256,
RSA_AES_256_CBC_SHA256, RSA_AES_128_CBC_SHA256, RSA_AES_256_CBC_SHA,
RSA_AES_128_CBC_SHA, RSA_RC4_128_SHA, RSA_RC4_128_MD5
SERVER: ServerHello TLS1.2 -> Certificate (909 B) -> ServerHelloDone
CLIENT: Alert level=fatal desc=certificate_unknown
```
Protocol and cipher selection are **compatible** — TLS1.2 with an RSA suite is offered and
chosen. The client rejects the **certificate**:
```
subject/issuer = CN = winter15.gosredirector.ea.com (self-signed, CA:TRUE)
SAN = DNS:winter15.gosredirector.ea.com, DNS:*.gosredirector.ea.com, DNS:*.ea.com
notBefore = Aug 13 01:12:30 2026
sha256 = FF:66:69:48:E2:02:AB:F4:A4:40:78:B1:8C:E1:F9:65:96:32:BB:FF:1F:3D:CC:BC:07:54:02:11:8F:4D:12:3F
```
Two facts matter:
1. **The SAN carries DNS names only, no `iPAddress` entry**, while the advertised URL is an
IP literal (`https://10.10.0.120:8081/...`). A DNS-only SAN cannot match an IP dial.
2. **The certificate was regenerated on Aug 13.** `roster_server.py` loads the same
`redir_cert.pem`/`redir_key.pem` as the Blaze redirector, so the redirector rejects
identically — visible as `REDIR REJECTED ... TLS/SSL connection has been closed (EOF)`
in the Blaze log. That is tolerated only because the client then reaches Blaze main over
plain TCP; the roster fetch has no such fallback, so it is where the failure surfaces.
`roster_server.py` still carries the comment *"ProtoSSL cert-verify is patched (autopatch),
so our self-signed cert is accepted."* That assumption no longer holds for this path.
autopatch demonstrably patched both gates in the failing process — the log shows
`pid 56298: PATCHED cert gates` and the live bytes read back as the patched patterns
(`909090909090` at `0x146132548`, `31c0c3` at `0x1461361b0`) — and the client still sent
`certificate_unknown`. So **those two gates do not govern this validation**; either another
check exists on the roster path, or it validates before reaching them.
## Ruled out, with evidence
| Hypothesis | Evidence against |
| --- | --- |
| Missing/mistyped UTAS field | 0 structural differences across 14 hub routes vs production (`scripts/hub-diff-prod-staging.py`) |
| Player squad shape | matches production field-for-field, including `squadType`, `custom`, `chemistry`, `manager` |
| Squad save | PUT/GET round-trips exactly, every field and slot |
| Cert gates unpatched | autopatch log + live byte read both confirm patched |
| Roster server broken | serves `200`, `application/xml` over TLS1.2 `AES256-GCM-SHA384` |
| Advertised host wrong | production and staging Blaze envs are identical for `OPENFUT_ADVERTISE`, `POW_*`; the scripts are byte-identical |
| TLS version mismatch | client offers TLS1.2 and the server selects it |
| Blaze session | healthy, PING/PING_REPLY throughout |
## Probing gotcha
A default modern Python TLS context gets `SSLV3_ALERT_HANDSHAKE_FAILURE` against this
server and looks like a server fault. It is not — the server requires legacy-compatible
cipher selection. Probe with `ALL:@SECLEVEL=0`, and note it rejects TLS1.0/1.1 outright
(`TLSV1_ALERT_PROTOCOL_VERSION`), accepting only TLS1.2.
## Why production appears unaffected
Unresolved, and worth stating plainly rather than guessing. Production advertises the same
URL, backed by the same server and certificate, so the same rejection should occur. The
operator reports production is clean. The likely explanation is that a production client
does not re-fetch the roster (already satisfied), while a session against a different Blaze
forces the fetch — but that has not been measured. The known-good hook log used as a
control (Aug 12 19:13) **predates the Aug 13 certificate regeneration**, so it is not
evidence about the current certificate.
## Fix options (none applied)
1. **Reissue the certificate with an `iPAddress` SAN** for the advertised address. Smallest
change, addresses the concrete mismatch, and benefits the redirector too. Note
`openfut-tls` exists precisely so the redirector and roster hosts cannot configure TLS
separately — the 2026-08-11 mismatch it was written for is the same class of bug.
2. **Serve the roster over plain HTTP** for an isolated stack, by pointing
`ROSTERUPDATE_URL`/`ROSTER_URL` at a staging-owned HTTP server. Sidesteps TLS entirely;
only acceptable off production.
3. **Find the real validation site** on the roster path and extend the patch set. Most
faithful, most work, and the only option that restores the original assumption.
Option 1 is the recommended starting point because it is testable without the client:
a probe that validates hostname/IP against the presented certificate will fail before the
fix and pass after.
docs/FIFA17_HUB_BEHAVIOR_SPEC.md
-1628
View File
File diff suppressed because it is too large Load Diff
docs/FIFA17_SOLD_WIRE_RE.md
-241
View File
@@ -1,241 +0,0 @@
# FIFA 17 seller-facing SOLD state — static recovery from CardsDLL
Reverse engineering of `CardsDLL_Win64_retail.dll`
(md5 `4de3493131d7d2ff7f8b360c5ac9b655`), Ghidra 12.1.2 headless via pyghidra,
13,382 functions, image base `0x180000000`. Queries and raw output:
`docs/evidence/market-sold-re-2026-08-17/`.
Confidence tags: **[PE]** read from the binary · **[PE-PROOF]** a proven *negative*
(an exhaustive absence) · **[PLAN]** corpus prose, not a decompile · **[UNDECIDABLE]**
proven not answerable from this binary.
---
## 1. There is no `sold` token, and now it is exhaustive
Both vocabularies dumped in full to their sentinels, not sampled. **[PE]**
`tradeState` table `0x180229e40` — exactly 4 rows, then a `{0,0}` terminator:
```text
active=1 inactive=2 expired=3 closed=4
```
`itemState` table `0x180229cc0` — exactly 12 rows, then a `{0,-1}` terminator:
```text
invalid=0 free=1 WAITING_FOR_GAME=2 inGame=2 forSale=5 offered=6
activeBadge=100 activeHomeKit=101 activeAwayKit=102 activeBall=103
activeStadium=104 active=255
```
Neither contains `sold`. So the seller's sold state **must** be a combination of
existing atoms. This closes the question that previously rested on a partial dump.
## 2. What `closed` actually does — the complete flag computation
Decompiled from the `auctionInfo` deserializer `0x18013e410`. `local_70` is
`tradeState`, `local_40` is `bidState`. **[PE]**
```c
if (local_70 == 4) { /* tradeState == closed */
local_3b = local_40 != 0; /* bidState != none */
} else {
local_3b = (local_40 - 1U & 0xfffffffd) == 0; /* bidState in {1,3} */
}
local_3a = local_40 - 2U < 2; /* bidState in {2,3} */
```
Evaluated:
| | `none`(0) | `outbid`(1) | `highest`(2) | `buyNow`(3) |
|---|---|---|---|---|
| `local_3b`, tradeState==closed | 0 | **1** | **1** | **1** |
| `local_3b`, otherwise | 0 | 1 | 0 | 1 |
| `local_3a` (any tradeState) | 0 | 0 | **1** | **1** |
## 3. The complete record → Flash mapping
From the publisher `0x1801bf030`, every property it sets, with its record offset.
This supersedes the previous partial list. **[PE]**
| Flash property | record | meaning |
|---|---|---|
| `TRADEID_LOWER` / `TRADEID_UPPER` | +0x38 | tradeId, split into two 32-bit halves |
| `DURATION` | +0x90 | formatted; **`FUT_AUCTION_EXPIRED`** when the value underflows (i.e. `expires == 0`) |
| `TIME_REMAINING` | +0x90 | expires, seconds |
| `MIN_CREDITS` | +0x78 | currentBid |
| `MAX_CREDITS` | +0x70 | buyNowPrice |
| `RESERVEDPRICE` | +0x74 | startingBid |
| `YOURBID` | +0xb8 | **bidState, passed through verbatim** |
| `STATE` | +0x88 | **tradeState, passed through verbatim** |
| **`COINS_AWARDED`** | **+0xbf** | **the `coinsProcessed` atom (0x2f4), u8** |
| `UUID_UPPER` / `UUID_LOWER` | itemData+8 | |
| `CARD_ID` / `FIFA_ID` | itemData+0x18 | `FIFA_ID` masks `& 0xffffff` |
| `CARD_TYPE` | itemData+0x4c | |
| `CARD_OFFERSTATE` | itemData+0x5c | itemState |
| `IS_WATCHED` | +0xbc | `watched` atom |
| `INBOX` | +0xbe | `local_3a` — bidState ∈ {highest, buyNow} |
| `IS_GLOW` | +0xbd | `local_3b` — the table in §2 |
| `TRADE_DATA_AVAILABLE` | — | constant 1 |
**`coinsProcessed`'s consumer is now traced.** The corpus recorded its type and
noted that no consumer had ever been found; it is published to the movie as
**`COINS_AWARDED`**. That is a settlement/"you have been paid" signal, exactly as
the corpus guessed but never demonstrated.
## 4. `highest` vs `buyNow` on a closed row is UNDECIDABLE from CardsDLL
**[UNDECIDABLE]**, and this is a proof, not a failed search.
For `tradeState == closed`, §2 gives `IS_GLOW = (bidState != none)` and
`INBOX = (bidState ∈ {highest, buyNow})`. Both `highest`(2) and `buyNow`(3)
therefore produce **`IS_GLOW=1, INBOX=1`** — bit-identical. No native consumer can
tell them apart.
But §3 sharpens *why* it is undecidable: `bidState` is **not** consumed only through
those flags. It is published verbatim as `YOURBID`, alongside `STATE` and
`COINS_AWARDED`. The movie receives the raw values. So the discrimination exists —
it just lives entirely in the APT/ActionScript front end, which is unread.
Consequence: **no amount of further CardsDLL work can answer "which `bidState` does
a seller see".** Only an AVM1 read of `external/ion_fut/screens/trading/tradepile`,
or a live behavioural A/B, can. This retires the question as a static target.
The corpus's own lifecycle table (`fifa17-recon/docs/plan-2026-08-06-transfer-market.md:720-729`)
asserts the seller sees `closed` / **`highest`** with `coinsProcessed 1`, and assigns
`closed` / `buyNow` to the *buyer*. That is **[PLAN]**, and it **contradicts** the
common third-party lore that a sold seller row is `closed` + `buyNow`. Given §4 the
contradiction cannot be resolved statically — but note the corpus reading is the one
that leaves `buyNow` meaning "*I* bought it now", which is self-consistent with
`YOURBID` being a property about the viewer's own bid.
## 5. The clear-sold verb EXISTS — PE-proven
The request builder `0x1801647c0`: **[PE]**
```c
if (*(longlong *)(param_1 + 0x10) == 0) {
FUN_180007f80(&local_38, 0x20, "/sold"); /* no tradeId -> bulk */
} else {
FUN_180007f80(&local_38, 0x20, "/%lld"); /* one specific tradeId */
}
```
One builder, two forms, on route base `ut/delete/%s/trade` (`DELETETRADE`), response
class `RS4:FutISRemoveTradeServerResponse` (`0x180228bc8`, with the `/sold` literal
at `0x180228bec` immediately after it):
```text
DELETE ut/delete/{ns}/trade/{tradeId} remove one trade
DELETE ut/delete/{ns}/trade/sold remove ALL sold trades
```
Corroborated by the client's own request-name table, where
**`RemoveAllSoldFromTradePile`** (`0x1801efae8`) sits beside `RemoveFromTradePile`,
`AddToWatchList` and `RemoveFromWatchList`.
**Architectural consequence.** A bulk "remove all sold" verb only makes sense if
sold rows **persist in the seller's pile until explicitly cleared**. That is
incompatible with our current host, where a sold/cancelled listing leaves
`/tradePile` the instant the CAS lands (the Fix A invariant). Implementing the sold
path will require revisiting that invariant — and doing so needs live validation,
because Fix A itself was a live-confirmed correction.
## 6. The seller-facing SOLD counter is real, and we hardcode it to 0
A complete chain, wire atom → struct → Flash → localised caption, with no inference
at any step. **[PE]**
Hub `tradePile` sub-deserializer `0x18013ead0`:
| atom | id | writes | Flash slot (publisher `0x1800b1dc0`, tile `0x1c0`) |
|---|---|---|---|
| `count` | 0xbc | +0x1d4 | `TEXT0` with caption `FUT_UC_ITEMS` |
| `notification` | 0x1da | +0x1d6 | `NOTIFICATION`, capped at 99 |
| `selling` | 0x2b8 | +0x1d2 (**and** counts-struct +0x36) | `TEXT2` with caption `FUT_TF_SELLING` |
| **`sold`** | **0x2c9** | **+0x1d8** | **`TEXT3` with caption `FUT_TF_SOLD`** |
The sibling tile `0x1d0` (Transfer Targets) uses `FUT_TF_WINNING` (+0x1c8) and
`FUT_TF_OUTBID`. `selling` writing two structs independently re-confirms the
corpus's counts-struct offset for `selling`.
So FIFA 17 renders a **SOLD** count to the seller, sourced from atom `sold` (0x2c9).
Our host and the Python oracle both hardcode `sold: 0`, so that bucket can never
populate. This is direct client evidence about `sold` — the thing
`MARKET_SOLD_SETTLEMENT.md` required before touching `/tradePile/counts`. It
establishes that `sold` is *displayed*; it does **not** yet establish what should be
counted in it (rows awaiting clear? rows sold this session?).
## 7. Atom-name decoder (method note, reusable)
Atom IDs are **indices into an alphabetically sorted pointer table** of atom-name
strings, base `0x1802d2760`. Validated against all twelve known `auctionInfo`
atoms — 12/12 agree — and cross-checked against `fifa17-recon/docs/fut_atoms.tsv`.
**[PE]**
```text
atom_id = (pointer_slot_address - 0x1802d2760) / 8
```
Newly resolved: `sold`=0x2c9, `count`=0xbc, `offered`=0x1e5, `selling`=0x2b8,
`maxAuctionsAllowed`=0x1bf, `credits`=0xc0, `auctionInfo`=0x35, `total`=0x325,
`duplicateItemIdList`=0xec, `itemState`=0x172, `offers`=0x1e6, `coins`=0x95.
Caution when using it: look up a name by finding the pointer slot **inside the table
range**, not by taking the first matching string in the binary. Common words such as
`sold`, `offered` and `count` appear in several unrelated tables, and taking the
first hit produces confident nonsense (it initially reported `sold` as ABSENT and
`offered` as a negative index).
## 8. An auction-outcome vocabulary exists but this client ignores it
The atom table contains a 7-value outcome vocabulary: **[PE]**
```text
0x36 auctionLostBidRejected 0x39 auctionSoldBid 0x3b auctionWonBid
0x37 auctionLostOutbid 0x3a auctionSoldBuyNow 0x3c auctionWonBuyNow
0x38 auctionLostOutbidSelf
```
These would distinguish seller-sold-by-bid from seller-sold-by-buy-now explicitly.
**No CardsDLL deserializer consumes them.** Every candidate function that compares
against three or more of `0x36..0x3c` was checked and none is an atom dispatcher
(no value-SKIP `0x180135ff0`, no atom loop `0x1801c7f10`) — they are small-immediate
coincidences. **[PE-PROOF]** So the vocabulary is server-side or telemetry, and it
does not carry the sold state to this client.
## 9. The 5% fee is NOT in the client — Task B is undecidable from here
**[PE-PROOF]**, three independent absences:
* no `0.95` or `0.05` constant, `double` or `float`, anywhere in the binary;
* no localisation key for tax/fee/net/proceeds/commission/"you will receive" — the
only `FUT_TF_*` keys in the binary are `SELLING`, `SOLD`, `WINNING`, `OUTBID`;
* the 17 functions using both `5`/`95` and `100` as immediates are all unrelated
(they include the item deserializer) — no fee arithmetic exists.
The client therefore never computes or displays a net. It learns the seller's
balance only from `credits`.
**This makes the rounding rule unmeasurable by experiment against our own server.**
Whatever we credit is what the client displays; there is no client-side expectation
to compare against, so there is no oracle. The only evidence that could settle
floor-the-fee (150 → 143) versus floor-the-proceeds (150 → 142) is an original
EA-era capture of a seller's balance across a known-price sale, which we do not
have.
Accordingly the rule stays a **documented choice**: fee = `floor(gross × 5 / 100)`,
proceeds = `gross − fee`, chosen because `fee + proceeds == gross` holds exactly at
every input. It is pinned by regression tests at 0, 1, 19, 20, 21, 39, 40, 100, 101,
119, 120, 149, 150, 151, 199, 200, 1 000, 15 000, 15 000 000 and `i64::MAX`, so it
cannot drift silently.
## 10. What would close the remaining gaps
| Gap | Only remaining route |
|---|---|
| `highest` vs `buyNow` on a seller's sold row | AVM1 disassembly of `tradepile.isInActiveAuction` / `PreCheckCardOptions`, or a live behavioural A/B (the movie gets `YOURBID` verbatim, so the two ARE separable by the client's behaviour) |
| What `sold` should count | live observation with a real sold row |
| Whether sold rows persist until cleared | live: does the client issue `DELETE .../trade/sold`? |
| The 5% rounding rule | an original EA-era seller-balance capture; nothing in reach |
docs/FIFA17_TRANSFER_MARKET_WIRE.md
-887
View File
@@ -1,887 +0,0 @@
# FIFA 17 Transfer Market — wire findings
Reverse-engineering record for the FIFA 17 UTAS transfer-market surface, kept so
future agents do not reopen settled questions or re-guess enum spellings.
Every claim carries a confidence tag:
| Tag | Meaning |
|---|---|
| **CONFIRMED** | Observed from our own FIFA17.exe client or live host capture |
| **FIFA17-HISTORICAL** | Supported by contemporaneous FIFA 17 implementations (`lorenzh/fut-api`, `futapi/fut` v0.2.18 — the last pre-FIFA-18 release) |
| **INFERRED** | Best explanation, not directly captured |
| **UNKNOWN** | Requires instrumentation; do NOT implement from guesswork |
Authority reminder: FIFA 17 field names, enum spellings, sentinel ids and
empty-state shapes come from captures or the Python oracle — never from a modern
FUT toolkit. Later-FIFA API drift is a known hazard, and reversing a container
type or inventing an enum is the documented client-freeze class.
---
## The auction record (`auctionInfo[]`)
What we emit today, on `/tradePile`, `/trade/status` and market browse:
```json
{
"tradeId": 1000000097,
"itemData": { "...full shaped card...": "", "itemState": "listFS" },
"tradeState": "active",
"buyNowPrice": 15000,
"startingBid": 150,
"currentBid": 0,
"offers": 0,
"bidState": "none",
"expires": 3600,
"tradeOwner": true,
"sellerId": 33068179,
"sellerName": "CAGE",
"sellerEstablished": 1,
"watched": false,
"coinsProcessed": 0
}
```
| Field | Confidence | Note |
|---|---|---|
| `tradeOwner` (bool) | **FIFA17-HISTORICAL** | Exists in FIFA 17 auctionInfo. That it is *the* Actions-panel gate is **UNKNOWN** pending live confirmation. |
| `sellerId` | **FIFA17-HISTORICAL** exists; type numeric is **INFERRED** | Set to the configured persona so it agrees with `tradeOwner`. Never baked in. |
| `sellerName` | **CONFIRMED** it must be the player | `fut_account.py` annotates the persona property as "Blaze PDTL.DSNM / LSX GetProfileResponse Persona / **UTAS sellerName**". EA's `"EASFC"` here is wrong for an own listing. |
| `offers` | **FIFA17-HISTORICAL** | `0` valid for active/unbid. |
| `bidState: "none"` | **FIFA17-HISTORICAL** | Valid for active/unbid. Other observed concepts: `highest`, `buyNow`. Do NOT "fix" this. |
| `expires` | **FIFA17-HISTORICAL** | **SECONDS REMAINING, not an epoch.** Historical durations: 3600, 10800, 21600, 43200, 86400, 259200. |
| `itemData.itemState: "listFS"` | **UNKNOWN** | Plausible and unchanged. Public FIFA 17 material gives no trustworthy enumeration. Do not guess replacements — capture. |
| `itemData.untradeable` | **FIFA17-HISTORICAL** field; our blanket `false` is **INFERRED** | See "Known debt" below. |
| `marketDataMinPrice` / `marketDataMaxPrice` | **do NOT add** | These entered the public parser only after its FIFA 18 migration. |
### Why the differential could not catch the missing fields
Our record's key set was **identical to the Python oracle's**, so field-for-field
parity was green. The oracle omits `tradeOwner` / `sellerId` / `offers` as well,
because *its* remove flow was never driven by a real client either — the only
historical live datapoint is a counts-tile bug. Oracle parity is therefore
**necessary but not sufficient** for any flow the oracle never actually served.
The differential now asserts we cover every oracle key AND that our extra keys are
exactly `{offers, sellerId, tradeOwner}`, so the deliberate superset is pinned
while a new unexplained divergence still fails.
---
## Routes
| Route | Confidence | Behaviour |
|---|---|---|
| `GET …/trade/status` | **CONFIRMED** the client polls it continuously | Live auction-state refresh. It previously fell through `starts_with("trade")` into the buy/view arm, where the tail has no numeric id, so **every poll returned `{"auctionInfo": []}`**. Now a real handler: optional `tradeIds` filter, else the whole active pile. Unknown ids are absent, never an error. |
| `DELETE /ut/game/<sku>/trade/<id>` | **FIFA17-HISTORICAL** | The spelling contemporaneous FIFA 17 clients use, no body, no meaningful response body. Previously landed in the buy/view arm and **silently cancelled nothing while returning 200.** Now maps to MarketCancel. |
| `DELETE /ut/delete/game/<sku>/trade/<id>` | **CONFIRMED** (oracle) | The oracle's spelling; retained because the differential exercises it. Whether FIFA17.exe ever uses it is **UNKNOWN**. |
| `POST …/auctionhouse` | **CONFIRMED** | List for sale. The client sends only `itemData.id`; the server resolves wire id → Core instance → `card_id`/`resourceId` and enforces ownership. |
| `GET …/tradePile/counts` | **INFERRED** | Five scalar ints (`count`, `maxAuctionsAllowed`, `offered`, `selling`, `sold`); a DISTINCT deserializer from `/tradePile`. Exact FIFA 17 semantics of `count` (active auctions vs whole pile) is **UNKNOWN** — we report active auctions and deliberately did NOT speculate. |
| `PUT …/item` (move) | **FIFA17-HISTORICAL** | `{"itemData":[{"pile":"trade"|"club","id":ID}]}` → `{"itemData":[{id,pile,success}]}`. Transfer-List membership is a **separate operation from creating an auction**. |
### Pile encoding
* MOVE commands take a **string** pile (`"trade"`, `"club"`) — **FIFA17-HISTORICAL**.
* Returned `itemData.pile` is documented **numeric** in FIFA 17 auction data — **FIFA17-HISTORICAL**.
* The numeric mapping is **UNKNOWN**. Do not unify the two representations, and do
not derive a mapping from unrelated `pileSize` keys.
---
## Q2 — Transfer List item that is not currently auctioned
A real FUT state: an item in the Transfer List with no active auction (freshly
moved, or expired unsold). **CONFIRMED** to exist as a concept (the external hub
spec §27, and move-vs-list being separate operations).
Its wire representation is **UNKNOWN**: `tradeId` 0 / omitted / null, `tradeState`
value or omission, and `itemData.itemState` are all unestablished.
Consequence, and the reason this matters: our `/tradePile` renders only `active`
listings, so keying the `/club` exclusion on the `trade` **pile** stranded 4 cards
in no screen at all (hidden from the club, absent from the Transfer List).
Commit `f2c4927` keys exclusion on the **active listing** instead, which is
self-healing. That is a workaround, not fidelity — the faithful model needs the
unlisted state represented.
**Required capture** (four states, full structural diff, not just a shortlist):
```
A. moved Club -> Transfer List, NEVER listed
B. actively listed
C. listing expired unsold
D. listing sold
```
Diff at least: `tradeId`, `tradeOwner`, `tradeState`, `bidState`, `expires`,
`offers`, `currentBid`, `startingBid`, `buyNowPrice`, `sellerId`, `sellerName`,
`itemData.id`, `itemData.itemState`, `itemData.pile`, `itemData.untradeable`.
Do NOT drop the unlisted state from the model just because its encoding is unknown.
---
## Deferred, with reasons
* **5% transfer tax** — **INFERRED** architecture only: auction closes → Core
settles → seller credited gross × 0.95, with `auctionInfo` continuing to carry
gross. No trustworthy FIFA 17 field named `tax`/`netPrice`/`sellerProceeds` was
recovered, and no separate settle operation. Not blocking; do not couple
settlement to clearing the sold auction without a capture.
* **Bid / Transfer Targets** — not implemented. Watched / active bid / winning /
outbid / won / expired are distinct states and must not collapse to a flat list.
* **Unassigned** — FIFA 17 had a dedicated Unassigned service; the exact FIFA 17
URL is **UNKNOWN**. Our 29-item `purchased` pile is this state and is currently
rendered inside `/club`. Do not manufacture a route from a modern toolkit.
* **Match CREATE / READY / PLAY** — **UNKNOWN** and explicitly not portable from
public FUT web-app work (the web app could not start matches). Instrument the
real client from Play Match to kickoff before implementing.
---
## Known debt
`shape_item` reports `untradeable: false` for **every** owned instance. Correct
today (Core models no untradeable items) and necessary — a hardcoded `true` greyed
out both list buttons — but it will misrepresent SBC / promo / loan rewards once
those exist. `untradeable` belongs on the owned-item instance as authoritative
state, not inferred from definition, resourceId or rarity.
---
## MEASURED in the live client — 2026-08-17
Read out of the running `FIFA17.exe` (pid-resolved, CardsDLL slide proven against
the on-disk FNV prologue) with `fifa17-recon/tools/trade_gate_probe.py`, which
extends `gate_byte_probe.py` to vtable slot `+0x270` as the transfer-market
analysis asked for. Read-only: `/proc/<pid>/mem` `O_RDONLY` + `pread`.
| Gate | Python era (2026-08-06) | Now | Owner |
|---|---|---|---|
| `IS_TRADING_ENABLED` `model+0x1fd2e` (slot `+0x270`) | **0** | **1** | settings struct `+0x28`; was zeroed by `userInfo.feature.trade` |
| `TRADE_PILE_SIZE` `model+0x1fd1c` | **0** | **100** | `userMassInfo.pileSizeClientData` key 2 |
| watch-list size `model+0x1fd20` | **0** | **50** | same member, key 4 |
| `storeEnabled` `model+0x1fd2f` | 1 | 1 | control |
| `IS_FRIENDLY_SEASON` / `IS_DRAFT_MODE` / `packOpeningAnimation` | 1 | 1 | controls |
**CONFIRMED: every CardsDLL-supplied input the transfer-market analysis named as a
blocker is now open.** The Rust host does this by construction — it emits
`userInfo.feature` as `{}` (no `trade` member, so the kill switch at `0x180174f19`
never arms: it fires only when atom `0x330` inside `0x11c` parses as exactly 1) and
it already sends `pileSizeClientData` keys 2 and 4. Serving `tradingEnabled: 1` in
the settings `configs` array would NOT have worked, because that tail runs after
every member is parsed and would overwrite it.
### What this rules out
The Transfer List Actions panel not opening on an own listing is therefore **not**:
* an ownership field — FIFA 17's auctionInfo has no `tradeOwner`/`sellerId` atom;
* `IS_TRADING_ENABLED`, `TRADE_PILE_SIZE` or the watch-list size — all measured open;
* the cancel route — `DELETE ut/delete/{ns}/trade/{tradeId}` is the PE's spelling and
is what we serve;
* `tradeState` / `bidState` / `expires` spellings — all three are the PE's own
vocabularies and values.
Per the analysis's own falsifier ("if the byte reads 1 and the screen still refuses,
the exe-side predicate has a term we have not enumerated"), the remaining term is
**exe-side UI script**, which CardsDLL does not own and the server cannot set.
Status: **UNKNOWN**, and it is now the narrowest it has ever been.
### Confirmed fidelity bug found on the way
`expires` was a frozen `3600` on every poll, so the client's live countdown never
moved and an auction could never run out. Now derived from `created_at + duration`
(duration taken from the `ISStart` body), clamped at 0, with an aged-out active
listing projecting as `expired`/`none` — FIFA 17's relistable state. Verified live:
the standing listing correctly reads `expires: 0` once past its hour.
---
## RESOLVED against the live client — 2026-08-17 (supersedes the tags above)
Driven by the real FIFA 17 client end to end: list → expire → **relist** → active,
with the operator confirming each UI state. Live-client behaviour OUTRANKS both the
Python oracle and contemporaneous Web App implementations wherever they disagree.
### `tradeOwner` — do not re-litigate this
```text
tradeOwner exists in the FIFA 17-era FUT API:
FIFA17-HISTORICAL
tradeOwner required by FIFA17.exe Transfer List Actions:
DISPROVEN for the current client path
```
It is absent from the twelve atoms FIFA 17's `auctionInfo` deserializer
(`0x18013e410`) reads, so the client value-SKIPs it at `0x180135ff0`. It was
implemented, deployed, observed to change nothing, and REMOVED. A future agent
rediscovering the old Web App sources will find this note before spending
deployments on it again.
### What actually gated the Actions panel — all lifecycle/state bugs
```text
CONFIRMED — FIFA17.exe live client
Own Transfer List interactivity does NOT depend on tradeOwner in this path.
trade/status polling is LOAD-BEARING for Transfer List state. The tail carries no
numeric id, so it fell through the `trade…` buy/view arm and answered every poll
with an empty auctionInfo. Route is ISVIEWTRADE:
GET ut/{ns}/trade/status?tradeIds=a,b,c
auctionInfo.expires is SECONDS REMAINING *and must evolve with wall-clock time*.
A structurally valid but FROZEN value breaks lifecycle behaviour: the auction never
ages into expired/relistable, which is the state where Re-list appears.
Relisting must PERSIST. FIFA 17 relists by re-sending ISStart (POST /auctionhouse)
for an item that already has a listing row, so the primary-key conflict IS the
relist. Swallowing it as success left the stale expired row intact and produced a
client-visible lifecycle failure behind an HTTP 200.
```
### Known-good own active auction (frozen fixture)
Captured at `docs/evidence/market-lifecycle-2026-08-17/`, including
`_index.json._countdown_proof` which records `expires` decrementing (`frozen:
false`) so the live clock is machine-checkable rather than asserted in prose.
```text
tradeState = active
bidState = none
expires = decrementing (seconds remaining)
sellerName = CAGE
auction record = 12 atoms
response envelope = 4 members (auctionInfo, credits, duplicateItemIdList, total)
ISViewTrade body = 2 members (auctionInfo, credits)
pricelimits = BARE ARRAY (container type is load-bearing)
```
**Do not "improve" this shape without a live-client retest.**
### The development rule this established
A response can be structurally plausible, pass differential parity, and render
perfectly while still being behaviourally wrong, because FIFA expects an **evolving
server-side state machine** rather than a static object that looks like one. The
frozen `expires` is the canonical example: every field was the right name, type and
vocabulary, and the feature was still broken.
---
## INVESTIGATION CLOSED — active own auction is not seller-actionable
**Do not reopen without new direct FIFA17.exe evidence contradicting the lifecycle
below.** The correct FIFA 17 lifecycle is:
```text
ACTIVE AUCTION tradeState=active, expires>0/counting down
-> seller CANNOT withdraw it through Transfer List actions
-> the item is not seller-actionable while the auction runs
EXPIRED UNSOLD tradeState=expired, expires=0
-> the item becomes actionable again
-> relist / return-to-club / other expired-item actions
```
### Confidence tags
```text
CONFIRMED — live FIFA17.exe:
active listing with ticking expires is NON-selectable
expired listing IS selectable
relisting makes it active and therefore non-selectable again
no cancel request is ever emitted by the client
expires must advance with the wall clock
no button prompt is offered on the Transfer List for an active auction
CONFIRMED — local RE corpus:
every CardsDLL-side prerequisite passes (IS_TRADING_ENABLED=1,
TRADE_PILE_SIZE=100, watch-list=50, item+0x49 tradeable)
MAY_BE_REMOVED is a CONSTANT 1 — it cannot be the gate and the server
cannot move it
the eight-flag array FUN_18003e370 publishes is the CLUB-CARD Actions menu
and contains NO transfer-auction cancellation flag
the auction parser is limited to the known twelve atoms
HISTORICAL FUT / FIFA17-era:
active auctions are committed until sale or expiry
expired Transfer List items expose relist/return actions
FIFA 17 trading guidance tells players to relist once auctions expire
UNKNOWN, and no longer required for backend fidelity:
the exact Flash/ActionScript branch that makes active cards non-selectable
```
### Explicitly out of scope now
Do NOT add auction fields, change `itemState`, revisit `tradeOwner`, probe
`MAY_BE_REMOVED`, add an active-auction cancel feature, or disassemble Flash in
order to make active auctions selectable. Three of those were already tried and
refuted; the rest are ruled out above.
### Return-to-club transition (implemented)
A pile move to `club` now ENDS any `active` auction on that item. Without it the
pile reads `club` while the listing row stays `active`, so the card is filtered out
of `/club` (exclusion keys on active listings) AND still rendered in the Transfer
List — the move silently appears to do nothing. `reserved` (mid-sale) and `sold`
rows are never touched, so a card can never be both sold and returned.
---
## Q2 — the unlisted transfer-list item, MEASURED 2026-08-17
The operator moved a card Club -> Transfer List **without listing it**
(`PUT /ut/game/fifa17/item`, no `POST /auctionhouse`). State captured immediately,
read-only. Fixture: `docs/evidence/market-lifecycle-2026-08-17/`.
Server truth at capture: trade pile held **6** items, of which **1** had an active
auction and **5** were unlisted.
| Surface | Unlisted item | Actively-listed item (contrast) |
|---|---|---|
| `/tradePile` `auctionInfo` | **absent** | present, `tradeState: active` |
| `/tradePile/counts` | **not counted** (`count 1, selling 1`) | counted |
| `/club` | **present**, `clubPlayers` unchanged at 1965 | **absent** (excluded) |
| `itemData.itemState` | `free` | `listFS` |
| `itemData.pile` | **field not emitted at all** | not emitted |
| `itemData.untradeable` | `false` | `false` |
**Finding: we do not represent the unlisted state anywhere on the wire.** Such an
item is byte-identical to a club item; only the host's own pile store knows it is in
the trade pile, and nothing the client receives says so.
Still **UNKNOWN** (do not guess): the FIFA 17 encoding of that state. The PE
documents returned `itemData.pile` as NUMERIC with an unrecovered mapping, and
`tradeState` decodes through a closed table walk (`active=1 inactive=2 expired=3
closed=4`) where an unrecognised `bidState` is silently swallowed as `none` — so a
wrong enum yields a plausible-looking but WRONG UI. The corpus explicitly warns that
`inactive` decodes but "no client path treats it specially; do not emit it".
Open discriminator, needs the client only: after backing out of FUT and re-entering,
does the Transfer List still show an unlisted item? If it does not, the move is not
durable from the client's point of view and the state must be represented; if it
does, `tradePile` is auctions-only by design and there is nothing to fix.
---
## Domain boundary: pile membership vs auction lifecycle
Two SEPARATE facts, but several mutations require a COORDINATED transition. Both
limbo bugs this session came from conflating them, so this is modelled explicitly
and covered by tests rather than patched route by route.
| Mutation | Pile | Auction |
|---|---|---|
| Club -> Transfer List | becomes `trade` | none necessarily exists |
| list item | stays `trade` | becomes `active` |
| clock runs out unsold | stays `trade` | becomes `expired` (projection; no row mutated) |
| relist | stays `trade` | `active` again, clock restarted, new prices |
| return expired item to Club | becomes `club` | any `active` association MUST end |
| sold / reserved | — | MUST NOT be ended by a generic move-to-club |
Invariant, stated so it can be tested rather than remembered: **an item must never be
simultaneously excluded from `/club` and absent from `/tradePile`.** That is the limbo
state, and it is reachable in two ways, both now closed:
1. Excluding by *pile* rather than by *active listing* (fixed in `f2c4927`) — the
pile can hold items with no auction, and `/tradePile` renders auctions only.
2. Moving to `club` while leaving the auction `active` (fixed in `4e31fb9`) — the
pile says club, the exclusion still fires, and the card shows in neither place.
Tests: `returning_an_expired_listing_to_the_club_ends_its_auction`,
`a_pile_move_never_disturbs_a_sale_in_flight`,
`club_excludes_listed_items_and_paginates_the_visible_set`.
---
## Q2 representation — narrowed to ONE candidate by elimination (2026-08-17) — **SUPERSEDED, see the final section**
Re-entry discriminator result: **CONFIRMED BUG.** After fully leaving and re-entering
FUT, the active auction reconstructs correctly under LISTED ITEMS, but the unlisted
TRANSFER LIST section is **empty** — item `100000059` does not survive. The
immediate post-move visibility was client-local only, so our representation cannot
durably reconstruct trade-pile membership.
The representation is now pinned by elimination over PROVEN facts, not chosen:
1. **Only one route can own a trade-pile list.** The complete CardsDLL route table
(`.rdata 0x18021df80`, 45 routes + 3 empty admin slots) is dumped verbatim at
`docs/evidence/market-lifecycle-2026-08-17/cardsdll-route-table.txt` via
`fifa17-recon/tools/route_table_dump.py` (static, read-only, VA→offset resolved
through the real PE section table). Row 30 `ut/%s/tradePile` is the ONLY
trade-pile route. There is no trade-pile *items* route.
2. **That route carries only auction records.** `FutGetTradePile` (`0x180170810`)
deserializes the shared IS-list body (`0x18013e7f0`), whose `auctionInfo`
elements go through `0x18013e410` — the twelve-atom auction record.
3. **`pile` cannot be set from the wire.** `pile` (atom 0x226) has NO arm in the item
deserializer `FUN_18013fe00` (checked in all four dispatch forms); `item+0x60` is
assigned by the OWNING LIST, reading 1 for every `/club` item and 6 for every
`/purchased` item. So membership is conferred by *arriving in the list*, never by
a field we can add.
4. **Of the twelve atoms, only `tradeState` can express lifecycle.**
5. **`tradeState`'s vocabulary is closed and has exactly one unused value.** The table
walk at `0x180229e40` decodes `active=1 inactive=2 expired=3 closed=4`, anything
else `-1`. `active`, `expired` and `closed` are all already spoken for by the
observed lifecycle.
**Therefore an unlisted trade-pile item can only be an `auctionInfo` record with
`tradeState: "inactive"`.** That is the sole encoding the client's own parser can
accept for "in the pile, no auction" — reached by elimination, not invention.
Status: **INFERRED-BY-ELIMINATION**, not yet CONFIRMED. One binary question remains,
and it is about client *rendering*, not encoding: does the Flash Transfer List place
an `inactive` record in the unlisted section? The corpus's warning that "`inactive`
decodes but no client path treats it specially" was established for the market
PRESENTATION function (`flagA`/`flagB`), where `inactive` is indeed unremarkable —
that is consistent with, and does not contradict, using it for list membership.
Ruled out on evidence, do not retry: adding `itemData.pile` (inert, no deserializer
arm), a second route (none exists), and `tradeId: 0` / invented `itemState` values
(unnecessary — `tradeState` alone carries the distinction).
### Acceptance test for whatever lands
```text
move item Club -> Transfer List
leave FUT entirely
re-enter FUT
item appears in the unlisted TRANSFER LIST section
item can be returned to Club
no auction exists unless explicitly listed
```
Plus the active lifecycle must remain unchanged: active listing under LISTED ITEMS,
`expires` counting down, active non-selectable, expiry making it actionable, relist
working.
### Revised domain invariant
Core pile membership is NOT equivalent to `/tradePile` visibility. Core ownership/pile
state and auction lifecycle are separate authoritative facts; the wire may expose them
through different FIFA 17 resources. **A transition is complete only when a fresh FIFA
session can reconstruct the same user-visible state** — re-entry is the acceptance
test, not the immediate post-mutation response.
---
## Q2 — LIVE-CONFIRMED: `tradeState: "inactive"` is the unlisted representation — **SUPERSEDED, see the final section**
Operator-observed in the real FIFA 17 client, 2026-08-17, with the bounded one-item
probe (`OPENFUT_FIFA17_UNLISTED_PROBE`). Fixture:
`docs/evidence/market-lifecycle-2026-08-17/inactive-row-live-confirmed.json`.
### The observed `inactive` UI contract
| Wire | Client presentation |
|---|---|
| `tradeState: "inactive"` | row placed under the right-hand **TRANSFER LIST** section, NOT under LISTED ITEMS |
| `startingBid: 0` | Start Price = `0` |
| `buyNowPrice: 0` | Buy Now Price = `-` (absent) |
| `currentBid: 0` | Current Bid = `-` (absent) |
| `expires: 0` | Time Remaining = `-` (no timer) |
| `bidState: "none"` | no bid presentation |
| `itemData.itemState: "free"` | renders as a normal owned card |
An `active` row in the same body continued to render separately under LISTED ITEMS,
so the two sections are driven by `tradeState` and the experiment did not disturb the
known-good active path.
Token provenance: dumped from the client's own `{const char*, int}` table at
`0x180229e40` (`active=1 inactive=2 expired=3 closed=4`) — see
`cardsdll-vocab-tables.txt` and `fifa17-recon/tools/vocab_dump.py`. Nothing here was
guessed.
Regression test: `market::tests::unlisted_candidate_is_a_non_active_pile_row` pins the
whole tuple, plus that the row is never emitted for an item outside the `trade` pile
and never duplicates a real auction
(`unlisted_candidate_never_duplicates_a_real_auction`).
### Expired -> Club coupled transition, verified
Operator returned the naturally-expired Ronaldo to the club. Server state after:
```
listing 1000000097 state = cancelled (the coupled transition fired)
pile Ronaldo = club
/tradePile Ronaldo absent
/club Ronaldo present, itemState free
hub clubPlayers 1964 -> 1965, auctionCount 1
counts {count 1, selling 1, sold 0}
```
All of that is durable store state rather than a client-local view, so it survives a
session boundary by construction. Pending the operator's final exit/re-enter
confirmation before this is tagged CONFIRMED.
### Counts observations so far (semantics still UNCHANGED and unresolved)
| State | `count` | `selling` | `sold` |
|---|---|---|---|
| 1 active | 1 | 1 | 0 |
| 2 active | 2 | 2 | 0 |
| 1 active + 1 inactive (probe) | 1 | 1 | 0 |
| unlisted pile items (no probe) | not counted | not counted | 0 |
So `count` currently tracks AUCTION entries, not total Transfer List membership. Do
not change this until the full state set (empty / unlisted / active / expired / sold /
mixed) has been observed — it remains an open question whether FIFA 17 expects
`count` to include non-active pile members.
---
## Q2 status downgrade + the "Expired" differential EXPLAINED (2026-08-17) — **SUPERSEDED, see the final section**
Phase C was a PARTIAL pass. Corrected conclusions:
```text
tradeState "inactive" = CONFIRMED section/lifecycle discriminator
(rows persist across a fresh session and land under
TRANSFER LIST, not LISTED ITEMS)
complete ACTIONABLE unlisted representation = was UNKNOWN; see below
```
### The visual differential, and its cause
| | one-item probe | generalized rows |
|---|---|---|
| Start Price | 0 | 0 |
| Buy Now / Current Bid | `-` | `-` |
| Time Remaining | `-` | **`Expired`** |
Cause: **route coverage, not a field.** `/tradePile` advertised the unlisted
tradeIds, but `GET …/trade/status` (ISVIEWTRADE) answered them from the market store
ONLY — and an unlisted pile member has no listing row, so the poll returned an empty
`auctionInfo`. Observed live as `route=market-status requested=1 returned=0` repeating
for the row the operator had selected (`tradeIds=1000000122`), while the same id was
present in `/tradePile`.
The client polls `/trade/status` for the row it is displaying, and an empty answer
degrades it: Time Remaining renders `Expired` and no actions are offered. The earlier
probe showed `-` simply because the client had not yet polled that id — the logs at
the time show only `tradeIds=1000000097`. So `expires`, `tradeState`,
`itemData.itemState` and `pile` were all innocent, and NO field was changed.
This is the same defect class as the original `trade/status` bug: a route the client
polls being answered with an empty set. The corpus predicted it — `tradeId` must
resolve across `/transfermarket`, `/tradePile`, `/watchList` AND `/trade/status`. We
had stability but not coverage.
Fix: both routes now share ONE pile enumeration (`Server::resolve_trade_pile`), so an
id advertised by `/tradePile` always resolves on `/trade/status`. Verified live: the
six inactive ids went from `returned=0` to `returned=6`. `/trade/status` still answers
only the ids actually asked about, and a real auction always wins over an inactive row
for the same id.
Regression test: `trade_status_resolves_the_unlisted_ids_tradepile_advertises`.
### Investigations NOT needed as a result
`itemData.itemState` and numeric `itemData.pile` were queued for PE recovery on the
assumption the encoding was incomplete. The cause was route coverage, so neither was
touched and neither is implicated. If the actions still do not appear, those remain
the next candidates — and `itemState`'s vocabulary should be dumped statically with
`fifa17-recon/tools/vocab_dump.py` (already validated against the tradeState table)
rather than guessed.
---
## Q2 — RETRACTED, and CLOSED as unrepresentable (2026-08-17, RE of the FUT front-end)
**Everything in the two Q2 sections above is superseded.** The `tradeState:"inactive"`
projection has been removed from `GET …/tradePile` and `…/trade/status`, and the
`UnlistedCandidate` machinery deleted. Live after the fix: `total` 7 → 1, only the real
auction, `inactive` rows 0, coins unchanged, and all six former rows still present in
`/club` (invariant intact).
### Why the earlier conclusion was wrong
It was `LIVE-CONFIRMED` that the row **renders**. That was never in doubt, and it is
not the same claim as the row being usable. The rows were never actionable, and could
not have been:
| Fact | Confidence |
|---|---|
| `tradeState` reaches ONE native branch, `cmp …,0x4` at `0x18013e619` ("is it `closed`?"). `inactive`(2) and `expired`(3) take the same edge → bit-identical `flagA`/`flagB`. Exhaustive 22-site census of `[reg+0x88]` reads across the PE. | CONFIRMED |
| `tradeState` is handed to the movie verbatim as the Flash property `STATE` (publisher `0x1801bf030`); the action gate is in the APT/ActionScript FUT front-end, not CardsDLL. | CONFIRMED |
| The trade-pile movie class partitions rows with `getCardsInAuction`/`isInActiveAuction` (traces `initPile() - IN AUCTION:` / `- NOT IN AUCTION:`), and only auction rows reach `PreCheckCardOptions` → `handleTradeCardAction`. | CONFIRMED (interned AS symbols + trace strings, live) |
| A client rule excludes non-auction pile rows from the action path (Category C). | STRONGLY SUPPORTED |
| The gate term is `STATE == 2`. | **NOT PROVEN** — `STATE`, `CARD_OFFERSTATE` and the `RESERVEDPRICE`/`MAX_CREDITS` pair all differ together in every row we can observe |
| In the shipped game, unlisted pile rows were a CLIENT-SIDE transient built by the movie from a `TO_TRADEPILE` Flash message (`FUN_1801be6a0`), never server-delivered. | STRONGLY SUPPORTED |
This fires the corpus's own pre-registered falsifier E3
(`plan-2026-08-06-transfer-market.md:368-373`): the native predicates all pass
(`IS_TRADING_ENABLED=1`, `TRADE_PILE_SIZE=100`, `tradeable=1`) and an `expired` row in
the same section IS actionable, so "the Flash layer has its own gate and CardsDLL is no
longer the right place to look" is now an observation.
**The corpus said so before any of this was written**, at
`plan-2026-08-06-transfer-market.md:731-733`: "`inactive` decodes but no client path
treats it specially; **do not emit it**." The projection was built anyway, and the
earlier reasoning above (that the warning "was written about the PRESENTATION
function") was motivated rather than evidenced.
**Consequence for the product:** a server cannot put an unlisted item on the Transfer
List in an actionable state. `/tradePile` carries only twelve-atom auction records and
`pile` has no deserializer arm, so anything rendered there must be a real auction.
Unlisted trade-pile membership is now internal state with no wire expression; those
cards live in `/club`, which is where the client can act on them.
### Open: `itemData.itemState: "listFS"` is not a FIFA 17 token
Independent of the gate, and CONFIRMED: `listFS` occurs **0 times** in
`CardsDLL_Win64_retail.dll` (md5 `4de3493131d7d2ff7f8b360c5ac9b655`) and 0 times in
4.26 GiB of live process memory; it decodes to **−1** through `FUN_180166660`, observed
live on our listed row. FIFA 17's value for a listed item is `forSale` (5), from the
12-row table at `0x180229cc0`. We emit `listFS` on `/tradePile` and `/trade/status`, and
so does the Python oracle (`utas_server.py:3921`) — which is exactly why the
differential never caught it: **oracle parity is necessary but not sufficient.**
### Fix B — `forSale` PROMOTED, live-confirmed on the expired path (2026-08-17)
Shipped alone, then validated by an operator FIFA 17 session against the already-expired
row `1000000155` (res 158023, 93 RW).
| Claim | Status |
|---|---|
| `listFS` is not a FIFA 17 token and decodes to −1 | **CONFIRMED** (binary + 4.26 GiB process scan + live row) |
| `forSale` is FIFA 17-native, value 5 | **CONFIRMED** (12-row table at `0x180229cc0`) |
| An expired row carrying `forSale` is still ACTIONABLE, and Return to Club works | **LIVE-CONFIRMED** — operator returned the card; server verified below |
| The result is durable (a fresh session reconstructs it) | **LIVE-CONFIRMED** (Gap 2, 2026-08-17) — the operator exited FUT and re-entered; the host log shows `auth-delete` then two fresh `sid_opened=true` sessions, each re-fetching `/club` and `/tradePile`, and the card was still in My Club. 18/18 server checks passed identically before and after. See the Gap 2 closure section. |
| An ACTIVE seller row carrying `forSale` renders correctly | **LIVE-CONFIRMED** (Gap 1, 2026-08-17) — see the closure section below; the client decoded `CARD_OFFERSTATE = 5` out of its own auction record |
| `CARD_OFFERSTATE` is the Flash action-gate term | **STILL UNPROVEN** — this change does not test it, and the result does not bear on it |
What this rules out: `CARD_OFFERSTATE` is not a gate term that *requires* −1. An expired
row decoding `CARD_OFFERSTATE = 5` remained actionable, so the earlier worry — that every
actionable row we had ever seen carried `itemState = −1` — was a coincidence of our own
bad token, not a client rule. It narrows nothing else: `STATE` and the
`RESERVEDPRICE`/`MAX_CREDITS` pair are untouched and still confounded with each other.
Wire A/B (`docs/evidence/market-lifecycle-2026-08-17/itemstate-forsale-ab.json`): on the
same expired row, **exactly one field changed** — `itemState` `listFS` → `forSale`.
`tradeId`, `tradeState`, `expires`, `startingBid`, `buyNowPrice`, `currentBid`,
`bidState`, `sellerName`, `sellerEstablished`, `watched`, `coinsProcessed`, the atom
count (12), and the whole `itemData` card are byte-identical; coins unchanged; Fix A's
zero `inactive` rows intact.
Risk was lower than it first appeared, for a reason worth recording: the market SEARCH
route (`/transfermarket`) **already** emitted `forSale`, so the client has been decoding
`forSale` (5) on a live path all along — only the seller's own pile carried the invalid
token.
Differential consequence: `market query tradePile` moves from `PARITY` to
`DIFFERENT-BY-DESIGN`, pinning `oracle == "listFS"` and `rust == "forSale"` so the
divergence stays visible. That assertion previously demanded parity and passed while
**both** sides were wrong — the mechanism by which this defect survived every
differential run. **Where the FIFA 17 binary contradicts the Python oracle, the binary
wins.**
Revert is one line if the live A/B fails: both `auction_record_as(l, "forSale")` calls in
`market.rs` back to `"listFS"`, rebuild, restart `prod-host`. On failure the rule is to
revert and go to the AVM1 gate work — NOT to compensate with another field change.
**Claim boundary:** this is protocol correctness of one token. It is not evidence about
the Flash decision tree; `STATE`, `CARD_OFFERSTATE` and `RESERVEDPRICE`/`MAX_CREDITS`
remain confounded.
### Gap 1 CLOSED — an ACTIVE seller row under `forSale` (2026-08-17)
The one thing the Fix B promotion could not test, because no active listing existed
during that session. Closed with a deliberately disposable card: a **75 ST**, resourceId
`212188`, wire id `100000178` — one of **three identical owned copies**, not in the
11-man squad, `untradeable: false`, discardValue 600. Listed **through the real FIFA 17
client** at Start 150 / Buy Now 200 for the shortest offered duration (1h), so expiry
would arrive naturally. No timestamp was touched.
Listing creation was entirely Rust-owned:
`PUT …/item` (club → pile) → `route=market-list POST item_id=100000178 listed=true
trade_id=1000000178` → `POST …/auctionhouse 200`, then the client polling
`GET …/trade/status?tradeIds=1000000178` (`requested=1 returned=1`) for the row it draws.
Wire, active row `1000000178`
(`docs/evidence/market-lifecycle-2026-08-17/gap1-active-forsale.json`):
| Field | Value |
|---|---|
| `itemState` | **`forSale`** |
| `tradeState` | `active` |
| `startingBid` / `buyNowPrice` / `currentBid` | 150 / 200 / 0 |
| `bidState` | `none` |
| `expires` | **3562 → 3556** over a 6-second sample — a live clock, not a frozen scalar |
| atom count | **12**, exactly what `0x18013e410` reads |
| `itemData` | full card, 6-entry `attributeList` |
| `/tradePile/counts` | `count 1, selling 1, offered 0, sold 0` |
| coins | 29,843,976 unchanged |
| Fix A | 0 `inactive` rows |
`/trade/status` stayed coherent with `/tradePile` throughout, agreeing on tradeId,
`active`, `forSale` and a decreasing `expires`.
**The decisive observation** is not the wire — it is what the client made of it. A
read-only `/proc/<pid>/mem` decode of the live trade-pile auction record (slide proven by
FNV control MATCH first; `O_RDONLY` + `pread` only) returned:
```text
tradeId=1000000178 state=1(active) bid=0(none) buyNow=200 start=150 cur=0 expires=3457
item CARD_ID=212188 cardType=1 tradeable=1 itemState=5(forSale) pile=0 rating=75
```
`itemState = 5(forSale)`. The same field read `-1(<unrecognised>)` under `listFS`. This is
the direct A/B on the only changed field, taken from the client's own memory rather than
from our response — the strongest form of this evidence available without AVM1 work.
`pile = 0` again, confirming pile is still never set from the wire.
Operator UI acceptance: card under **LISTED ITEMS** (not the TRANSFER LIST section), Start
150 / Buy Now 200 correct, **Time Remaining visibly counting down**, normal card art, no
malformed row, no duplicate, no premature Expired, no crash, and correctly
**non-actionable while active**. The client's container populating with exactly this row
(`rows=1`) independently corroborates that the Transfer List screen bound and drew it.
**No code change was required** — the promoted implementation was already correct on the
active path, which is what the test was designed to find out.
Two process notes worth keeping. First, an early capture reported "countdown NO"; that was
a bug in the capture script (it re-read a hardcoded copy id rather than the row it had
resolved), not a server fault — the same run's `/trade/status` already showed a lower
`expires` than `/tradePile`. Verify the instrument before believing a negative. Second,
the client's auction-record containers read **0 rows** while the operator was on any other
screen; they populate only while the Transfer List is bound. An empty container is not
evidence of an empty pile.
**Claim boundary unchanged:** this proves the client *decodes* the token. It says nothing
about the Flash action-gate term.
### Proving the gate (not yet done)
Disassemble the AVM1 action buffer of `tradepile.isInActiveAuction` (and
`PreCheckCardOptions`): either walk from the interned symbol at `0xb84d7498` to its APT
function object in the live process, or extract
`external/ion_fut/screens/trading/tradepile` from `ui.sb` + the `cas` archives offline.
Nothing else in reach separates `STATE` from `CARD_OFFERSTATE` from the price pair,
because all three differ together in every observable row.
---
## Gap 2 CLOSED — Return to Club survives a full exit/re-entry (2026-08-17)
The claim the Fix B promotion could only make server-side. Closed on the same
disposable card as Gap 1 (75 ST, res `212188`, wire id `100000178`, tradeId
`1000000178`) after it expired **naturally** — the 1h auction was allowed to run
out. No timestamp was mutated at any point in either gap.
### The whole lifecycle, observed rather than forced
A read-only sampler polled `/tradePile` once a minute for the auction's full hour
(55 samples). `expires` is derived from `created_at + duration`, so watching is the
only honest way to see expiry happen:
```text
t=1787012091 active expires 3175 itemState forSale
... counting down, one sample a minute ...
t=1787015271 expired expires 0 itemState forSale <- natural expiry
t=1787015301 (absent) total 0 <- Return to Club
```
`itemState` stayed `forSale` across the `active -> expired` transition, which is the
Fix B behaviour under the one state change we had never watched live.
### Return to Club, then two session boundaries
The host log records the coupled transition and the re-entries:
```text
route=move-items wire=100000178 pile=club auction_cancelled=1
route=auth-delete
route=auth ... ip=10.10.0.105 persona=33068179 sid_opened=true
route=hub clubPlayers=1966 auctionCount=0
route=club total=1986 emitted=1966 dropped_no_asset=0
... the full auth -> userMassInfo -> hub -> club -> tradePile -> trade/status
cycle then repeats for a SECOND fresh session ...
```
`auction_cancelled=1` is `cancel_active_for_core_item` firing: the pile move to
`club` ends the auction that put the card there, which is the coupled transition
that keeps pile membership and auction lifecycle from disagreeing.
Two independent fresh sessions each rebuilt the state from durable storage, and the
operator confirmed the card was still in My Club. One session boundary was the
requirement; two is stronger.
### Server state — 18/18, byte-identical before and after re-entry
| Surface | Result |
|---|---|
| `/tradePile` | `total 0`, 0 rows, no reference to the item or the tradeId |
| `/tradePile/counts` | `count 0, selling 0, sold 0, offered 0` |
| `/trade/status` | tradeId `1000000178` → **`closed`**, `expires 0` — still resolves, correctly terminal |
| `/club` | **1966** items; `id=100000178 res=212188 rating=75 ST itemState=free untradeable=False` |
| Duplicate owned ids | **0** across all 1966 |
| Market store | listing `1000000178` = `cancelled`; **0 active, 0 reserved** anywhere |
| Coins | **29,843,976** unchanged for the entire test |
| Fix A | 0 `inactive` rows |
The `1965 → 1966` club count is the pile-aware exclusion working in both directions:
the card left `/club` while actively listed and returned on cancel. A tradeId that
can still be asked about still answers — terminally — rather than vanishing.
**No code change was required for either gap.** Both tests were designed to find out
whether the promoted implementation was already correct on paths it had not been
exercised on. It was.
---
## FROZEN BASELINE — the known-good transfer-list lifecycle (2026-08-17)
With both gaps closed, this lifecycle is the reference. A future change that alters
any line here is a regression until proven otherwise.
```text
CLUB
itemState free, present in /club, absent from /tradePile
| PUT /item {pile:"trade"} + POST /auctionhouse (ISStart)
v
ACTIVE AUCTION
/tradePile: tradeState active, itemState forSale, 12 atoms,
expires counting down from duration, currentBid 0, bidState none
/tradePile/counts: count 1, selling 1
/club: EXCLUDED while listed
/trade/status: agrees with the pile on every field
client: renders under LISTED ITEMS, CARD_OFFERSTATE = 5, non-actionable
| wall clock reaches created_at + duration
v
EXPIRED
/tradePile: tradeState expired, expires 0, itemState still forSale
client: row becomes ACTIONABLE, offers Return to Club
| PUT /item {pile:"club"} -> cancel_active_for_core_item
v
CLUB (terminal)
/tradePile: total 0 /tradePile/counts: all zero
/club: present again, itemState free market store: cancelled
/trade/status: old tradeId -> closed, expires 0
coins: unchanged throughout
survives: FUT exit + re-entry, repeatedly
```
Invariants this baseline pins:
* an item is never in limbo — it is in `/club` or in an active auction, never neither;
* `expires` is SECONDS REMAINING and must evolve with wall-clock;
* pile membership and auction lifecycle are separate facts that must be changed
together;
* a tradeId resolves on every route that can be asked about it, even when terminal;
* only real active auctions appear in `/tradePile` (Fix A);
* a listed item carries `itemState forSale` (Fix B), and the client decodes 5;
* an active own auction is intentionally non-actionable;
* coins move only when coins should move — this whole lifecycle moves none.
What is still NOT established: the SOLD path (no counterparty exists yet; settlement
is implemented and unit-tested in Core but never client-validated — see
`MARKET_SOLD_SETTLEMENT.md`), `/tradePile/counts` exact FIFA semantics, and the AVM1
action gate.
docs/MARKET_SOLD_SETTLEMENT.md
-352
View File
@@ -1,352 +0,0 @@
# Transfer-market sold settlement + transaction fee
How a completed market sale moves coins and ownership. Written while the
`forSale` expiry lifecycle test was running, so **nothing here has been deployed
or validated against a FIFA client** — see the confidence table.
Every claim carries one of:
| Tag | Meaning |
|---|---|
| **CODE** | Read directly out of the current implementation |
| **TESTED** | Pinned by a unit or integration test that fails if it regresses |
| **FIFA17-HISTORICAL** | Supported by contemporaneous FIFA 17 knowledge, not by our client binary |
| **NEEDS-LIVE** | Requires a real FIFA 17 client to confirm; must not be treated as settled |
---
## 1. What the Buy Now path did before this work
Traced end to end, **CODE**:
```text
POST/PUT /ut/game/fifa17/trade/<id>
-> openfut-utas-host/src/lib.rs route classification (EconomyRoute::MarketBuy)
-> market.rs::handle_market_buy
store.get_listing(id) market_store.rs
bid < buy_now -> echo raised bid, NO coin movement, return
store.reserve_listing(id) CAS active -> reserved
econ.balance() pre-check, 461 if short
econ.purchase_item(price, "market-buy:<id>", listing.card_id)
-> POST {core}/economy/purchase-item
-> openfut-core services/economy.rs::purchase_item
BEGIN IMMEDIATE; debit(club, cost); add_item(club, item, card); COMMIT
store.complete_sale(id) CAS reserved -> sold
-> auctionInfo record with tradeState "closed", bidState "highest",
currentBid = price, itemData.itemState "free"
```
The module header at `openfut-utas-host/src/market.rs:12-16` states it plainly:
a buy-now *"debits the buyer and MINTS the won card into their club … there is no
real counterparty and no seller credit"*.
### The ten questions, answered from code
| # | Question | Answer (**CODE**) |
|---|---|---|
| 1 | Where are buyer coins debited? | `services/economy.rs::debit` inside `purchase_item`, one `BEGIN IMMEDIATE` transaction. Host pre-checks with `econ.balance()` only to distinguish 461 from 503. |
| 2 | Does Core know the seller? | **No.** Every `/economy/*` route resolves ONE club from the `X-OpenFUT-Game` active profile (`routes/economy.rs:23-28`); no request shape carries a counterparty. |
| 3 | Does the auction persist seller-owned item identity? | **Yes** — `listings.core_item_id` and `wire_item_id` (`market_store.rs:199-203`). The settlement inputs already existed; the buy path just ignored them. |
| 4 | Transfer or mint? | **Mint.** `purchase_item` INSERTs a new `owned_cards` row keyed `market-buy:<tradeId>`. The seller's row is untouched, so a sold card existed **twice**. |
| 5 | Is the seller credited? | **No.** Nowhere. |
| 6 | Any tax calculation? | **No.** Zero occurrences of `*5/100`, `0.95`, `fee`, `tax` in Core, host, adapter *or* the Python oracle. It existed only as prose in `FIFA17_HUB_BEHAVIOR_SPEC.md:884` and `FIFA17_TRANSFER_MARKET_WIRE.md:127-131`, both labelled unimplemented. |
| 7 | Auction state sequence? | `active -> reserved -> sold`, host-side (`market_store.rs`). On any Core failure `reserved -> active`. |
| 8 | Is there a `reserved` state? | **Yes**, and it is the concurrency guard, not decoration — `reserve_listing` is a `BEGIN IMMEDIATE` compare-and-swap, so of two concurrent buyers exactly one proceeds to a debit. |
| 9 | When does the item leave the seller's `/tradePile`? | When the listing stops being `active`: the pile projection emits only real active auctions (the Fix A invariant). `sold`/`cancelled` rows vanish from the pile the moment the CAS lands. |
| 10 | What makes a retry safe? | The same CAS. A second Buy Now finds the listing non-`active`, so `reserve_listing` returns `false` and the handler returns an empty `auctionInfo` — the client reads "auction gone", and no economy call is made. |
### Deficiencies
1. **Ownership duplication.** A sold card ends up owned by both parties. Structural, not a race.
2. **No seller credit** — selling was economically pointless.
3. **No fee**, so no sink; every synthetic buy was pure coin destruction and every sale would have been pure creation.
4. **Core could not express a counterparty at all** — the single-club resolver had no seller/buyer distinction to make.
5. `UPDATE owned_cards SET club_id` did not exist anywhere in Core: there was **no ownership-transfer primitive** to call.
---
## 2. The settlement transaction
`openfut-core/src/services/economy.rs`, alongside the existing tx-scoped
primitives so it reuses the module's proven atomicity (`pool.acquire()` +
`BEGIN IMMEDIATE` + `finish()`), **CODE**:
```rust
pub enum SaleBuyer<'a> { Club(&'a str), Outside }
pub struct SaleTerms { pub gross: i64, pub fee: i64 }
pub async fn settle_sale(
pool: &Pool, item_id: &str, seller_club_id: &str,
buyer: SaleBuyer<'_>, terms: SaleTerms,
) -> AppResult<SaleReceipt>
```
One transaction: debit buyer `gross` → evict the item from every squad →
transfer the existing row → credit seller `gross - fee`. The fee is simply never
credited anywhere, which is what destroys it.
Exposed as `POST /economy/settle-sale`. It is the **only** economy route that
names clubs explicitly, because a sale has two sides and the active-profile
resolver can only describe one. Both are optional: an omitted `seller_club_id`
means the active club (the production shape — the player listed the item), and an
omitted `buyer_club_id` means `Outside`, *not* the active club, so the route can
never accidentally settle a club against itself.
### Ownership transfer, not duplication
```sql
UPDATE owned_cards SET club_id = ? WHERE id = ? AND club_id = ?
```
No INSERT and no DELETE on the two-party path, so the instance id, its
`chemistry_style`/`position_override`/`training_bonus` and its `acquired_at` all
survive and the inventory row count cannot change. Duplication is ruled out
structurally rather than by an assertion. `acquired_at` is deliberately preserved:
this is the same instance under new ownership, not a new acquisition.
**TESTED** — `settle_sale_transfers_ownership_and_splits_coins` asserts both that
the item's owner changed and that `SELECT COUNT(*) FROM owned_cards` is still 1.
### The seller is pinned, not inferred — and this was a real bug
The first implementation derived the seller from *current* ownership, which reads
naturally ("the seller is whoever owns it") and is wrong. The concurrency test
caught it immediately: **both** racing buyers succeeded, because after the first
sale the item was owned by buyer B, so the second call read B as the seller and
cheerfully chain-sold it B → C. Core has no listing concept, so it had no way to
notice that this was a replay of one listing rather than a new sale.
The fix is that `seller_club_id` is the club the caller **believes** owns the item,
and every ownership statement is predicated on it. That turns the `UPDATE` into an
ownership compare-and-swap which is authoritative about "this sale already
happened", independently of any caller-side listing state. Safety is not weakened:
a caller still cannot credit a club that never owned the item, because the credit
only follows a matched CAS.
**TESTED** — `two_buyers_racing_one_item_settle_once` (exactly one winner, loser's
balance untouched, one instance, seller paid once) and
`settling_the_same_sale_twice_pays_once`.
### Squad eviction is mandatory
`squad_players.owned_card_id` is a foreign key onto `owned_cards(id)` and the pool
enables `foreign_keys`. Two consequences, both **CODE**:
* an `Outside` sale of a squadded card would fail outright on the FK;
* a two-party transfer preserves the row id, so a surviving `squad_players` row
would leave the **previous** owner fielding a card they no longer own.
So both paths evict first, and the receipt reports `squad_slots_freed`.
**TESTED** — `sale_evicts_the_item_from_the_sellers_squad`.
> Noticed while reading, NOT fixed here (out of scope, no behaviour changed):
> `routes/cards.rs:187-192` (quick sell) and `services/market.rs` both DELETE an
> owned card without clearing `squad_players` and without a transaction, so
> quick-selling a squadded card should fail on the same FK. Worth a follow-up.
---
## 3. The fee arithmetic
Lives in `openfut-adapter-fifa17/src/fut/economy_policy.rs`, beside `pack_price`
and `match_reward_total`, because 5% is a **FIFA policy constant** and Core must
stay game-neutral. Core validates `0 <= fee <= gross` and never computes a rate.
```rust
pub const TRANSFER_MARKET_FEE_PERCENT: i64 = 5;
pub fn transfer_market_fee(gross: i64) -> i64 { /* floor, i128 intermediate */ }
pub fn seller_proceeds(gross: i64) -> i64 { gross.max(0) - transfer_market_fee(gross) }
```
Integer only. Floating point is never used for coin settlement: `0.05` is not
representable in binary, and at large prices a `f64` round trip can create or
destroy a coin. The multiply widens to `i128`, so overflow is unreachable for any
`i64` price and no price ceiling has to be assumed.
**Rounding is a CHOICE, and it is NEEDS-LIVE.** The fee is floored, so the seller
keeps the fractional coin. That was chosen because it makes
```text
fee + proceeds == gross
```
hold exactly at every input, which is what the accounting invariant rests on. The
discriminating case against the alternative (flooring the seller's 95% instead) is
a gross of **150**: this rule pays **143**, the alternative pays **142**. Nothing
in the corpus or the client binary settles which the real server did — the client
is only ever told the gross, and no `tax`/`netPrice`/`sellerProceeds` wire field
exists. **A future live test should list something at 150 coins and read the
credited amount.**
**TESTED** at `0, 1, 19, 20, 21, 39, 40, 100, 150, 200, 1_000, 15_000,
15_000_000, i64::MAX`, plus `fee + proceeds == gross` swept over 0..2000 and the
extremes, plus negative-gross rejection.
| gross | fee | proceeds | why it is in the table |
|---|---|---|---|
| 19 | 0 | 19 | last fee-free price |
| 20 | 1 | 19 | first price that pays |
| 150 | 7 | 143 | **the NEEDS-LIVE discriminator** (alternative: 8 / 142) |
| 15,000 | 750 | 14,250 | canonical fixture |
| i64::MAX | MAX/20 | remainder | proves no overflow |
---
## 4. Accounting invariant
For `SaleBuyer::Club`, **TESTED** by `sale_conserves_coins_minus_the_fee`:
```text
buyer_debit == seller_credit + fee
total modelled coins shrink by EXACTLY the fee
21,000 -> 20,250 (difference 750)
```
For `SaleBuyer::Outside` the identity deliberately differs and the doc comment
says so: the counterparty owns no `clubs` row, so nothing is debited and the
seller's proceeds **enter** the economy from outside. **TESTED** by
`settle_sale_to_outside_retires_the_item_and_pays_net`, which asserts total coins
*rise* by the proceeds. Conflating the two would look like a conservation bug.
---
## 5. Rejected sales
All **TESTED** by `invalid_sales_change_nothing`, which re-seeds a fresh fixture
per case and asserts both balances and the item's owner afterwards:
| Case | Outcome |
|---|---|
| buyer cannot afford `gross` | rejected, nothing moves |
| buyer == seller | rejected at the Core domain boundary — not a market path, and it would otherwise debit and credit one club while destroying the fee |
| item does not exist | rejected |
| item not owned by the named seller (**includes every replay**) | rejected |
| buyer club does not exist | rejected |
| `fee > gross` | rejected |
| negative fee / negative gross | rejected |
| ownership changed mid-flight | rejected by the CAS |
A zero-price sale is **legal** (a free transfer, no fee) — **TESTED** by
`zero_price_sale_is_a_free_transfer`.
Auction-level states (`expired`, `cancelled`, already-`sold`) are **not** Core's
business: Core has no listing concept, and the host's `active -> reserved` CAS
already refuses those. Duplicating that check in Core would create a second
authority on auction lifecycle.
---
## 6. Atomicity
`services::economy` is the **only** module in Core that is genuinely atomic; it
uses `pool.acquire()` + raw `BEGIN IMMEDIATE` + `finish()` deliberately, because a
DEFERRED `pool.begin()` upgrades to a write at first write, where SQLite returns
`SQLITE_BUSY` immediately instead of honouring `busy_timeout`
(`services/economy.rs:218-223`). Settlement is built inside that module for
exactly this reason, so it inherits the guarantee rather than re-deriving it.
Handlers receive a pooled clone, never `&mut SqliteConnection`, so the transaction
boundary is inside the service function. **CODE.** No externally observable state
exists where the buyer is debited without the item moving, or the seller credited
without the buyer debited — every step shares one connection inside one
transaction, and `finish()` rolls back the whole thing on any error.
### Rejection precedence, and a test that passed for the wrong reason
Inside one transaction the order of the steps cannot change the final state — any
error rolls everything back. It does change **which reason** a rejection carries,
and that turned out to matter.
The first implementation debited the buyer before touching ownership, on the
reasonable-sounding grounds that an unaffordable sale should fail before ownership
moves. The isolated staging harness then showed that a replayed settlement was
refused with `insufficient balance: have 5000, need 15000` — because the buyer had
already spent the coins on the sale that succeeded. The affordability guard fired
first, so **the ownership CAS was never consulted**, and the unit test named
`settling_the_same_sale_twice_pays_once` was passing without ever exercising the
replay guard it claimed to test.
Two fixes, both **TESTED**:
* ownership is now judged before affordability, so a replay is reported as
`item not owned by club` (404) — the true cause;
* the replay test now asserts the error is specifically `AppError::NotFound`, and
adds a deliberately CHEAP replay (gross 100 out of the buyer's remaining 5,000)
that only ownership can possibly refuse.
The lesson generalises: a guard that is merely *shadowed* by an earlier guard is
untested, and a green assertion on "the second call failed" says nothing about
which mechanism failed it.
---
## 6b. Isolated staging harness
`scripts/settlement-staging.py` — stdlib-only, exercises the settlement against a
**real Core over real HTTP** with zero production contact. It picks an ephemeral
loopback port (production 8099/8199/18080 sit in a hard deny-list checked in three
places), runs Core once to apply its own migrations, seeds the canonical two-party
fixture by direct SQL, relaunches Core, then prints BEFORE / PURCHASE / AFTER with
PASS-FAIL lines and cleans up in a `finally`.
Result: **31/31 checks pass**, exit 0.
```text
BEFORE seller 1,000 buyer 20,000 owner club-seller rows 1 total 21,000
POST /economy/settle-sale {item_id, gross 15000, fee 750, seller, buyer} -> 200
AFTER seller 15,250 buyer 5,000 owner club-buyer rows 1 total 20,250
fee destroyed 750 duplicates 1 coins destroyed 750
RETRY (identical) -> 404 item not owned by club: item-x nothing moved
REPLAY GUARD (gross 100) -> 404 item not owned by club: item-x nothing moved
```
Two things it found that the unit tests had not:
1. the rejection-precedence bug above;
2. Core's **content preflight** aborts startup when an owned card references a
`CardDefinitionId` that no loaded pack defines (`content preflight failed: 1
owned card(s) reference CardDefinitionId(s) not loaded (e.g. ["def-x"])`), so
the harness writes a one-entry content pack for its synthetic card rather than
quietly substituting a stock card id.
---
## 7. What is NOT done, and why
* **No production wire change, no deployment.** The host gained the *capability*
(`CoreEconomy::settle_sale`) but `handle_market_buy` is untouched: the synthetic
buy path (`core_item_id == None`) has no counterparty, so minting there is
correct and unchanged.
* **Nothing decides that a player's listing has sold.** That trigger is the real
remaining feature, and it needs the seller-facing sold wire representation,
which is deliberately deferred — `tradeState`/`itemState` for a sold row are
**NEEDS-LIVE** and must not be guessed. `docs/FIFA17_TRANSFER_MARKET_WIRE.md`
records that no `sold` token exists in FIFA 17's `tradeState` table
(`active=1 inactive=2 expired=3 closed=4`).
* **`/tradePile/counts` semantics unchanged.** Its `sold` field stays as-is; the
Core facts a correct `sold` count would need now exist, but the route output
must not change without client evidence.
* **The 5% rate itself is FIFA17-HISTORICAL**, and the rounding rule is
**NEEDS-LIVE** (the 150-coin discriminator above).
## 8. Confidence summary
| Claim | Status |
|---|---|
| The old buy path minted a duplicate and never credited a seller | **CODE** |
| No fee arithmetic existed anywhere in the project | **CODE** |
| Ownership now transfers as one row, with no duplicate possible | **TESTED** |
| Buyer debited, seller credited net, fee destroyed, in one transaction | **TESTED** |
| `buyer_debit == seller_credit + fee` | **TESTED** |
| Canonical 15,000 fixture: 20,000→5,000 / 1,000→15,250 / fee 750 | **TESTED** |
| A replayed settlement pays once | **TESTED** |
| Two racing buyers settle exactly once | **TESTED** |
| A sold card leaves the seller's lineup | **TESTED** |
| Invalid sales leave the economy unchanged | **TESTED** |
| The fee rate is 5% of gross | **FIFA17-HISTORICAL** |
| The fee is floored (150 → 143, not 142) | **UNDECIDABLE from available evidence** — CardsDLL contains no fee arithmetic, no `0.95`/`0.05` constant and no tax/net caption, so the client never computes or displays a net and there is no oracle to measure against. See `FIFA17_SOLD_WIRE_RE.md` §9. Remains a pinned CHOICE. |
| The seller-facing sold wire state | **PARTIALLY RECOVERED** from the binary — see `FIFA17_SOLD_WIRE_RE.md`. Proven: no `sold` token in either vocabulary (exhaustive); `coinsProcessed` is published to Flash as `COINS_AWARDED`; a bulk clear-sold verb `DELETE …/trade/sold` exists; the seller's SOLD counter is real (atom `sold` 0x2c9 → `FUT_TF_SOLD`). Still UNDECIDABLE statically: `highest` vs `buyNow`. |
| The client renders a settled sale correctly | **NEEDS-LIVE** — never exercised |
No Core test here establishes anything about the FIFA 17 wire contract. They
establish the domain transaction only.
docs/MATCH_LIFECYCLE.md
-208
View File
@@ -1,208 +0,0 @@
# FIFA 17 FUT Match Lifecycle
Design + contract reference for the **FUT match loop** as OpenFUT implements it on
the backend/responder side. Consolidates knowledge previously scattered across
`docs/PROJECT_STATE.md`, `fifa17-recon/tools/utas_server.py` (`match_route`),
`openfut-utas-host` (Rust economy END leg), `fifa17-recon/tools/test_match_lifecycle.py`,
and the vault (`Protocol Findings.md`, `Project State.md`, `Known Issues.md`).
Evidence labels: **OBSERVED** (live), **PROVEN** (test/static-analysis),
**HYPOTHESIS** (reasoned, not yet live-confirmed).
> ## Status caveat (read first)
> **No football match has ever started or completed in FIFA against this stack.**
> The lifecycle below is validated by CardsDLL static analysis (RPC descriptor
> blocks) + isolated persistence replay (`test_match_lifecycle.py`), **not** in-game
> acceptance. The reward amounts are FUT-plausible env-tunable defaults, **not**
> reversed values. Two blockers keep `FUT_MODES` **off by default** (see
> [Open questions](#open-questions--blockers)).
## Scope
This documents the **UTAS responder handshake + economy reward** for a match — the
HTTP calls CardsDLL makes around a match and the state they mutate. It does **not**
cover the actual football simulation (Blaze game-server side, "past the FUT hub"),
which remains unverified.
## The loop: a four-call state machine
CardsDLL issues six match RPCs; four form the playable loop. All share the base
path `ut/<sku>/match`; the operation is discriminated by **suffix + body**, not by
HTTP verb (verb selection lives outside CardsDLL, so the classifier is verb-agnostic).
```mermaid
stateDiagram-v2
[*] --> Created: POST /match (no matchId)
Created --> Ready: POST|PUT /match/ready {matchId}
Ready --> Playing: POST /match {matchId} (bare path + int matchId)
Playing --> Ended: POST|PUT|DELETE /match/end {matchId, endReason, ...}
Ended --> [*]: rewards credited, W/D/L + matchesPlayed persisted
```
### Call classifier (`_match_call`, utas_server.py:3325)
The discriminator (**PROVEN** from CardsDLL RPC descriptors):
1. path ends `/match/end` → **END** (routed as `FutDestroyMatch` regardless of verb).
2. body has integer `matchId` on the **bare** `/match` path → **PLAY** (`FutPlayGame`).
CREATE and PLAY share `ut/<sku>/match`; the presence of an int `matchId` is the
only discriminator — this is why a bare `/match` carrying `matchId` must NOT
allocate a new match.
3. path ends `/match/ready` → **READY** (`FutMatchReady`).
4. otherwise → **CREATE** (`FutCreateMatch`).
## Per-call contracts
### CREATE — `POST /ut/<sku>/match` (empty/no `matchId`)
CardsDLL: `FutCreateMatch` @ `0x180120380`; deserializes `startDateTime`(740,int),
`reportIdEnabled`(641,bool). `squad`(717,nested) is a **FREEZE-RISK** and is omitted
(SKIP-safe).
Response (`match_route`, utas_server.py:3399):
```json
{"startDateTime": <unix_ts:int>, "reportIdEnabled": false, "id": <matchId:int>}
```
Effect: allocates a match id; **advances `nextItemId` by 1** (PROVEN,
`test_match_lifecycle.py:51`).
### READY — `POST|PUT /ut/<sku>/match/ready` (`{matchId}`)
CardsDLL: `FutMatchReady` — no deserializer at all on the request; the server
response parser has two scalar members + one nested member.
Response (`match_ready_body`, utas_server.py:3353):
```json
{"matchId": <int>, "opponentPersonaId": <int, default 0>}
```
- `opponentPersonaId` defaults to `0` — a neutral placeholder, **never** the
logged-in user's persona.
- The parser also has a nested `items` member (the opponent squad). It is **omitted
deliberately** until the opponent-squad item contract is recovered from a live
capture; unrecognized/absent members are skip-safe. **This omission is one of the
two blockers.**
### PLAY — `POST /ut/<sku>/match` (bare path, `{matchId:int}`)
CardsDLL: `FutPlayGame` — no request deserializer.
Response: `{}` (empty). Effect: **none** — must NOT allocate a match or advance
`nextItemId` (PROVEN, `test_match_lifecycle.py:62-63`). This is purely a client
keepalive/transition ack.
### END — `POST|PUT|DELETE /ut/<sku>/match/end` (`{matchId, endReason, myMatchStats, opponentMatchStats}`)
CardsDLL: `FutDestroyMatch` @ `0x180121b60` — **the rewards call**. Routed as
DestroyMatch regardless of verb (`FUT_MATCH_END`, default ON).
> **Wire path (Rust vs Python).** The Rust-owned reward is classified by `classify_economy`
> on **`POST /ut/delete/game/<sku>/match`** — EA/CardsDLL tunnels DELETE-semantics ops through the
> `/ut/delete/game/` prefix (`FutDestroyMatch` = `DELETE ut/%s/match/{id}`). Python's `match_route`
> additionally accepts `/ut/game/<sku>/match/end`. Which exact form the retail client emits is
> unverified (no match ever played); the Rust economy owns the `/ut/delete/game` form, and a
> `/ut/game/.../match/end` would fall to Python. Both credit the same reward shape.
Request fields that matter:
- `endReason` (atom 260) — **STRING enum, the AUTHORITATIVE result signal**. A score
comparison is NOT how the client reports the outcome. Nine values, mapped to a
win/draw/loss bucket:
| endReason | bucket |
|---|---|
| `WIN`, `DNF_WIN` | won |
| `DRAW`, `DNF_DRAW`, `NO_CONTEST` | draw |
| `LOSS`, `DNF_LOSS`, `DNF`, `QUIT` | loss |
| (missing/unknown) | draw (neutral fallback — credits without inventing a win) |
- `myMatchStats` / `opponentMatchStats` — literal-keyed objects, 15 int fields each,
first is `goals`. **Omitted by the client when `endReason` is `DNF`/`QUIT`**, so
nothing may require them. Used only as a fallback outcome probe if `endReason` is
absent.
Response (`destroy_match_body` / Rust `build_match_reward_body`) — every field a
**top-level scalar** (zero freeze risk) except the deliberately nested reward:
```json
{
"allCoins": <post-credit balance:int>,
"matchCoins": <per-result coins:int>,
"seasonCoins": 0,
"tournamentCoins": 0,
"boostConis": 0, // EA's typo — exact key required
"participationAward": <int>,
"teamOfTournamentWinner": false,
"gameModeAward": { "coins": <total award:int> }
}
```
> **Critical correction (2026-08-04):** the reward `coins` (atom 149) is read by the
> deserializer **only inside `gameModeAward`**, never as a top-level key. An earlier
> top-level `"coins"` was silently skipped and never reached the client — the one
> field most obviously named "the reward" was the one going nowhere.
Effect (persisted to the active FUT save): credit coins; increment the matching
`record.{won,draw,loss}`; increment `matchesPlayed` (PROVEN,
`test_match_lifecycle.py:74-81`).
## Reward policy
Env-tunable defaults (FUT-plausible, **not reversed** — `economy_policy.rs:20-36`,
`utas_server.py:3201-3206`):
| Result | Match coins | Participation | Total |
|---|---|---|---|
| Win | 400 (`FUT_MATCH_COINS_WIN`) | 0 (`FUT_MATCH_PARTICIPATION`) | 400 |
| Draw | 200 (`FUT_MATCH_COINS_DRAW`) | 0 | 200 |
| Loss | 100 (`FUT_MATCH_COINS_LOSS`) | 0 | 100 |
`allCoins` = post-credit balance; `gameModeAward.coins` = per-result + participation.
## Ownership split (Rust vs Python)
The match loop is **partially migrated**. Only the coin-crediting END leg is
economy state, so only it is Rust/Core-owned; the CREATE/READY/PLAY legs are still
served by the Python oracle.
| Call | Owner | Where |
|---|---|---|
| CREATE | Python | `utas_server.py::match_route` (via host `Route::Passthrough`) |
| READY | Python | `utas_server.py::match_route` |
| PLAY | Python | `utas_server.py::match_route` |
| END (reward) | **Rust/Core** (on `POST /ut/delete/game/<sku>/match`) | `EconomyRoute::MatchEnd` → `handle_match_end` → `build_match_reward_body`; outcome via `economy_policy::match_result_from_reason`, coins via `match_result_coins`/`match_reward_total`. 503 on Core error, never Python. Python also accepts `/ut/game/<sku>/match/end`. |
END is classified in `classify_economy` (`openfut-utas-host/src/lib.rs`) and dispatched
by the economy authority barrier ahead of the general classifier — so it can never
also reach the Python passthrough (NEVER-BOTH). The Rust END writes the coin reward
through the single Core economy transaction (`grant_reward`); W/D/L record + match
count still live in the Python save until CREATE/READY/PLAY migrate.
## Test coverage
`fifa17-recon/tools/test_match_lifecycle.py` (PROVEN, isolated — temp profile, no
live server): drives CREATE→READY→PLAY→END and asserts:
- CREATE returns `reportIdEnabled:false` + advances `nextItemId` by 1.
- READY returns exactly `{matchId, opponentPersonaId:0}`.
- PLAY returns `{}` and does **not** advance `nextItemId`.
- END credits `MATCH_COINS["won"] + MATCH_PARTICIPATION`, persists
`record == {won:1,draw:0,loss:0}` and `matchesPlayed == 1`.
## Open questions / blockers
1. **READY `items` contract (opponent squad)** — the nested `items` member of
`FutMatchReadyServerResponse` is unserved pending a live capture. Whether the
client requires it present/non-empty to enter a match is unknown. **Blocker.**
2. **Client mode-entry gate** — reaching a match from the FUT hub UI is unverified;
`FUT_MODES` stays **off by default** (the season/tournament routes return `{}`).
3. **No in-game acceptance** — every claim here is static-analysis + isolated replay.
The first live match is expected to reveal whether the static read was complete
(every match body is logged for exactly this reason).
4. **Football simulation** — the actual gameplay (Blaze game-server) is out of scope
here and unverified.
## Sources
- `docs/PROJECT_STATE.md` (match lifecycle status), `docs/direction.md` (Tier-2 loop).
- `fifa17-recon/tools/utas_server.py`: `_match_call` (3325), `match_ready_body` (3346),
`match_route` (3357), `destroy_match_body` (3281), `_match_result` (3236),
`MATCH_COINS`/`MATCH_PARTICIPATION` (3201), `_END_REASON` (3229); CardsDLL RPC
descriptor block (3183-3197).
- `openfut-adapter-fifa17/src/fut/economy_policy.rs` (reward policy + outcome map).
- `openfut-utas-host/src/lib.rs`: `EconomyRoute::MatchEnd`, `handle_match_end`,
`build_match_reward_body`.
- `fifa17-recon/tools/test_match_lifecycle.py` (lifecycle regression).
- Vault: `02 Reverse Engineering/FIFA 17/Protocol Findings.md`,
`06 Agent Memory/{Project State,Known Issues}.md`.
docs/OVERNIGHT_HANDOFF_2026-08-17.md
-165
View File
@@ -1,165 +0,0 @@
# Overnight session handoff — 2026-08-17
Autonomous session while you slept. Low-ceremony per your instruction. Everything
below is verified as noted; nothing was committed or pushed (see
[Uncommitted work](#uncommitted-work--needs-your-review)).
## TL;DR
1. **Production promotion completed** (you chose "promotion"): prod-host swapped to the
post-P1 build, content-gap imported. Then I migrated the **remaining Python UTAS
routes that have a known contract** to Rust: account/sync, ut/auth (SID mint),
userMassInfo (full), clientdata, club/stats/{country,league,team}, and the trivial
static acks. The client's **observed FUT-hub/economy flow is now fully Rust**; a
tail of lower-traffic routes **without a captured wire shape** (item-defs,
user-identity, watchList/marketdata, non-active `squad/<n>`, draft, and mode-gated
season/tournament/champion/leaderboards/sbs) **still proxy to the Python oracle**.
2. **Launcher redesigned to a shareholder-grade egui UI** (your headline ask). Builds
clean; screenshots captured.
3. **New docs:** `MATCH_LIFECYCLE.md` (you asked), `CORE_CORRECTNESS_ISSUES.md`
(4 known Core bugs + 1 bonus exploit, ready to fix on your go/no-go).
4. **Nothing committed** — all work is in the working tree for your review (git state is
delicate: preserved-dirty Core submodule + a concurrent `funman300` actor + detached
launcher branch; I didn't want to entangle that unsupervised).
## What's live in production now (`10.10.0.120:8099`)
| Thing | State |
|---|---|
| prod-host binary | post-P1 `fda40d12` **+ my migration rebuild** (release, in `target/release/openfut-utas-host`) |
| prod-host pid | 3207781 (hub-managed, restart=no; retained spec points at the rebuilt binary) |
| Catalog | `9f6addaa` (post-P1) |
| Core content (cards) | `136d8d68` (post-P1, +18 content-gap defs) → Core loads **1710** defs |
| Core owned | **1982** (1962 players + 17 consumables + 3 staff) |
| Coins | **29,876,776** (baseline — reset from the P1 test value when the content-gap DB was swapped in; you said data isn't precious) |
| prod-core | **fixed build** from canonical submodule (`fbb54ea` + 4 correctness fixes), DB migrated ver 18 → 19; binary now `/home/alex/OpenFUT/target/release/openfut-core` |
| UTAS routes (Rust) | economy, club, squad (0/active/list/PUT), account/sync, ut/auth, userMassInfo, **user**, clientdata, hub, settings, accountinfo, leaderboards/options, match/reset, phishing, club/stats/{year,consumables,staff,country,league,team}, watchList, static acks (store/keepalive/captcha/tfa/livemessage/activeMessage) |
| Still Python (:8199) | item-defs (item/resource, defid), club-identity (clubUser, user/list, user/club), `squad/<n>` (n≠0), draft, marketdata, mode-gated (season/tournament/champion/leaderboards/sbs → `{}` while off), and match CREATE/READY/PLAY. See `docs/PRODUCTION_AUTHORITY_MATRIX.md`. |
Smoke-verified live in prod (in the prod netns): all migrated routes return
`owner=RUST`, coins consistent, clientdata round-trips, club/stats context modes emit
distinct nation/league/team buckets. Scripts:
`/home/alex/openfut-promotion/economy-2026-08-17-p2/{p2_precheck,smoke_migrated,smoke_clubstats}.py`.
## Changes made (all verified: builds clean, tests green)
### 1. Production promotion (deployed)
- Host binary `e5be8730` (P1) → `fda40d12` (post-P1) + catalog `9f6addaa`.
- Content-gap DB swapped in (owned 1962 → 1982). Backups in
`/home/alex/openfut-promotion/economy-2026-08-17-p2/backup/` + `ROLLBACK.txt`.
### 2. Route migration to Rust (deployed, rebuilt binary)
- `POST /ut/auth` — Rust mints the SID (`OPENFUT-SID-{:016X}`), opens the Rust session,
adopts persona from body. No Python. (`+ /ut/delete/auth`.)
- `POST /openfut/account/sync` — full Rust envelope; coins/unopenedPacks from Core.
- `GET /userMassInfo` — **full** Rust envelope (was a Python-proxy+overlay hybrid).
- `GET/PUT /clientdata/<key>` — new host `ClientDataStore` (JSON-persisted).
- `GET /club/stats/{country,league,team}` — made `club_stats_body` context-aware
(nation/league/team buckets); classify now routes all `club/stats/*` to Rust.
- `GET /squad/0` — routed to the Rust active-squad projection (verified structurally
identical to Python `squad/0`: same 15 keys, players=23).
- `GET /watchList` (+ no-op add/remove) — empty list + authoritative Core credits.
- Static acks (`store`, `match/keepalive`, `captcha`, `tfa`, `livemessage`,
`activeMessage`) — Rust constants (StaticAck route), byte-identical to the oracle.
- Captured the remaining routes' Python wire shapes as reference fixtures for later
migration: `docs/evidence/route-shapes-2026-08-17/` (user, defs, marketdata,
clubUser, watchList, squad/0, season/tournament/champion/sbs, draft).
- Files: `openfut-utas-host/src/{lib.rs,clientdata_store.rs(new),config.rs}`,
`openfut-adapter-fifa17/src/fut/{non_economy.rs,club_stats.rs}`,
`openfut-utas-host/tests/economy_integration.rs`.
- Tests: `openfut-utas-host` + `openfut-adapter-fifa17` full suites **GREEN**
(188 adapter + 76 host lib + all integration incl the 116s economy integration).
### 3. Launcher redesign + polish + live account panel (built, NOT deployed — client tool)
- **Redesign**: new `openfut-launcher/src/theme.rs` design system (palette, embedded
fonts, egui Visuals/Style, card/pill helpers). Branded hero header (OF monogram),
left nav rail, card-based dashboard with status pills, prominent accent Launch CTA,
console-style Logs. All existing launch/health/preflight/service/config logic preserved.
- **Polish**: OpenFUT window/taskbar icon (OF monogram `IconData`), Config tab rebuilt
into themed cards, consistency sweep.
- **Live "Your Club" panel** (new feature): a background `AccountMonitor` (mirrors
`HealthMonitor`, 5s poll, non-blocking) fetches the account summary and the Dashboard
shows a "Your Club" card — club name/abbr, Manager, **COINS hero number**, Level + XP
bar, unopened packs, account funds — with clean loading/offline/error states.
- Builds clean (0 warnings). Screenshots preserved (for your shareholder demo) in
`/home/alex/openfut-post-p1/launcher-screenshots-2026-08-17/` — `launcher_account.png`
(the populated "Your Club" card: COINS 29,876,776, Level 12, packs 3) is the headline;
plus dashboard/setup/logs/config + the offline state. All reviewed — product-quality.
- Files: `openfut-launcher/src/{theme.rs(new),account_monitor.rs(new),app.rs,main.rs,
account_sync.rs,config.rs}` + `assets/` (fonts + icon). All additive; behavior preserved.
### 4. Core correctness fixes (deployed 2026-08-17)
All four `CORE_CORRECTNESS_ISSUES.md` classes fixed in the canonical `openfut-core`
submodule and deployed to prod-core (see that doc's "Resolution" section):
- **Issue 3 (HIGH, exploit):** SBC duplicate-card free-reward — `submit_sbc` now dedups
ids + bounds the list (`MAX_SBC_CARDS`=30) → `BadRequest`. Regression test added.
- **Issue 2 (HIGH):** non-atomic economy mutations — closed the concurrency-exploit
races with single-statement compare-and-swap (`spend_coins` conditional debit,
`open_pack`/`buy_listing`/`sell_card`/`checkin` claim-then-act). Multi-statement
partial-failure edges (`buy_pack`, concurrent SBC, match/season chains) left as
documented residual — need the transaction refactor, negligible for single-player.
- **Issue 4 (LOW):** `season.rs` `.expect()` panics → graceful `AppError`; checkin index
`% 7` → `.rem_euclid(7)`.
- **Issue 1 (LOW):** `sbc_submissions.club_id` — migration `0019` (add + backfill) +
`submit_sbc` binds it; milestone query now correct.
- Verified: Core suite **179 green** + clippy clean; migration dry-run on a prod-DB copy;
post-deploy prod migration ver 19, owned 1982, coins 29,876,776, all Core + host
endpoints 200. Rollback: `backup/prod-core.preCoreFix.db` (ver 18) + old binary path —
see `backup/ROLLBACK_CORE_FIX.txt`.
## New / updated docs
- `docs/MATCH_LIFECYCLE.md` (NEW) — consolidated FUT match loop design (CREATE→READY→
PLAY→END), contracts, reward policy, ownership split, blockers. (You asked for this.)
- `docs/CORE_CORRECTNESS_ISSUES.md` (NEW) — 4 known Core bugs + 1 bonus SBC
duplicate-card exploit, each with file:line + concrete fix + severity. **Needs your
go/no-go** (fixing bumps Core off the frozen P1 reference).
- `docs/PRODUCTION_AUTHORITY_MATRIX.md` (UPDATED) — reflects the completed migration.
- Vault `06 Agent Memory/Current Priorities.md` (UPDATED).
## Uncommitted work — needs your review
**I committed nothing** (git state is delicate: openfut-core is intentionally
preserved-dirty; a concurrent `funman300` actor; launcher on detached HEAD `d1a71bd`).
Review + commit these when you're ready:
- Superproject (mine): `openfut-utas-host/src/{lib.rs,config.rs}`,
`openfut-utas-host/src/clientdata_store.rs`,
`openfut-utas-host/tests/{economy_integration.rs,host_test.rs}`,
`openfut-adapter-fifa17/src/fut/{club_stats.rs,non_economy.rs}`,
`docs/{PRODUCTION_AUTHORITY_MATRIX.md,MATCH_LIFECYCLE.md,CORE_CORRECTNESS_ISSUES.md,OVERNIGHT_HANDOFF_2026-08-17.md,PYTHON_RETIREMENT_PLAN.md}`,
and the reference fixtures `docs/evidence/route-shapes-2026-08-17/`.
- Launcher submodule (mine): `src/{app.rs,main.rs,theme.rs(new),account_monitor.rs(new),account_sync.rs,config.rs}`, `assets/` (fonts + icon).
- **Leave the pre-existing dirt alone** (not mine): `CLAUDE.md`, `README.md`,
`.env.example`, `docker-compose.yml`, `AGENTS.md`, `setup.sh`, `openfut-bridge`,
`fifa17-recon/docker/...`, `docs/{ARCHITECTURE,ROADMAP,docker,fifa17-emulation}.md`,
`docs/research/`, `scripts/utas-filter-diff.py`.
- `openfut-core` (mine, this session): `migrations/0019_sbc_submissions_club_id.sql` (new),
`src/services/{sbc.rs,club.rs,pack.rs,market.rs,checkin.rs,season.rs}`,
`tests/integration_test.rs`. Built + deployed to prod-core; still detached HEAD at
`fbb54ea` (edits uncommitted, per your branch strategy).
## Open decisions for you
1. ~~**Core correctness bugs**~~ — **DONE (2026-08-17):** all four classes fixed +
deployed to prod-core (see "Core correctness fixes" above and the Resolution section
of `docs/CORE_CORRECTNESS_ISSUES.md`). prod-core is now off the frozen P1 point,
running `fbb54ea` + fixes at migration ver 19. Residual (documented): the
multi-statement transaction refactor for partial-failure atomicity — negligible for
single-player; do it if/when concurrency matters.
2. **Match handshake legs** (CREATE/READY/PLAY) — the only routes still on Python.
Deferred: no match has ever been played in-game, READY `items` contract unknown,
`FUT_MODES` off (see `docs/MATCH_LIFECYCLE.md`). Migrating them risks the economy
`/match/end` routing for a never-exercised path — I judged it not worth it unmonitored.
3. **Aux service container cutover** (blaze/redirector/roster → Rust) — operator-gated
container change; unchanged.
## Rollback (still hot)
- Python P2 image `openfut-fut-backend:p2-rollback` (b1b929953f) + profile 39bb3e83 +
`rollback-to-python-p2.sh`.
- prod-host P1 binary + P1 catalog backed up in
`/home/alex/openfut-promotion/economy-2026-08-17-p2/backup/` (see `ROLLBACK.txt`).
- prod state (pre-content-gap) backed up: `backup/prod-core.preB.db`,
`prod-identity.preB.json`, plus P1 `fifa17-production-{catalog,cards}.p1.json`.
docs/PRODUCTION_AUTHORITY_MATRIX.md
-165
View File
@@ -1,165 +0,0 @@
# Production Authority Matrix (post-P1 -> P2-routes promoted 2026-08-17)
> **P2-routes promoted to production 2026-08-17.** prod-host swapped P1 `e5be8730` -> post-P1
> `fda40d12`; catalog `35a0913b` -> `9f6addaa` (resolves all owned assets, dropped_no_asset=0).
> Every previously-Python non-economy route now RUST in prod (OBSERVED prod log). Rollback hot:
> restore P1 binary + backup catalog (`economy-2026-08-17-p2/backup/`).
Definitive inventory of every production-reachable FIFA17 route/service and its
current owner. Derived from the live `prod-host` dispatch log (owner= labels,
real Client A session 2026-08-14), `openfut-utas-host/ROUTE_AUTHORITY.md`, and the
prod container config (`OPENFUT_SERVERS="blaze roster pow"`).
Evidence labels: OBSERVED (live log/db), PROVEN (test), INFERRED, HYPOTHESIS.
Legend: owner R = Rust/Core, P = Python oracle (:8199 proxied via PYTHON_FALLBACK).
## UTAS HTTP (front door: openfut-utas-host :8099)
### ECONOMY — already Rust (Python economy hits = 0, OBSERVED)
| Method/path (tail) | Prod owner | Writes state | Rust handler | Py proxy |
|---|---|---|---|---|
| GET /user/credits | R | no | handle_credits | NO |
| GET /store/purchasegroup[/all] | R | no | handle_purchasegroup | NO |
| PUT /store/transaction[/<id>] | R | coins,inv,pile | handle_store_buy | NO |
| POST /purchased[/items] | R | coins,inv,ent,pile | handle_pack_open | NO |
| GET /purchased[/items] | R | no | shape_purchased_reveal | NO |
| DELETE /item/<id> | R | coins,inv | handle_quick_sell_path | NO |
| POST /ut/delete/../item | R | coins,inv | handle_quick_sell_body | NO |
| PUT /item | R | inv,pile | handle_move_items | NO |
| POST /ut/delete/../match | R | coins | handle_match_end | NO |
| POST /auctionhouse,/transfermarket | R | listings | handle_market_list | NO |
| GET /tradePile | R | no | handle_market_query | NO |
| GET /tradePile/counts | R | no | handle_market_counts | NO |
| /trade/<id> (POST/PUT/GET) | R | coins,inv,listings | handle_market_buy | NO |
| DELETE /ut/delete/../trade/<id> | R | listings | handle_market_cancel | NO |
**Transfer-market semantics (live-verified 2026-08-17).** Three things here are
load-bearing and were each a live defect:
1. `/tradePile` and `/tradePile/counts` are **different deserializers** and MUST NOT
share a handler. `/counts` is FutGetAuctionCount: five scalar ints
(`count`, `maxAuctionsAllowed`, `offered`, `selling`, `sold`) and nothing else.
Served the `auctionInfo` body it skips every field, leaving the counts at 0 — the
hub tile shows a listing while the Transfer List screen shows no active sale.
2. An auction record's `itemData` MUST be the **full card object** (the same shape
`/club` emits), not a stub. A listing therefore persists a shaped-card SNAPSHOT
(`listings.item_json`) at list time. The seller's own pile stamps
`itemState: listFS`; market search uses `forSale`.
3. `POST /auctionhouse` resolves the listed card **server-side** from the wire item
id (`wire → Core instance → card_id + resourceId`); the client's FutISStart body
carries only the id. This also enforces that you can only list what you own.
### NON-ECONOMY — Rust-owned (route migration 2026-08-17, OBSERVED prod log)
| Route | Owner | Notes |
|---|---|---|
| POST /ut/auth (+ /ut/delete/auth) | R | Rust mints the SID (OPENFUT-SID-{:016X}); opens Rust session; adopts persona from body. No Python. |
| POST /openfut/account/sync | R | full Rust envelope; coins/unopenedPacks from Core; clubName OpenFUT / clubAbbr OFC constants |
| GET /userMassInfo | R | FULL Rust envelope (userInfo+squad+settings+pileSizeClientData); no Python. coins from Core, squad == /squad/active |
| GET/PUT /clientdata/<key> | R | host ClientDataStore (JSON-persisted); PUT acks {}, GET returns blob or {} |
| capability (/openfut/fifa17/capability) | R | -> Bound (CleanV1) |
| GET /club, /club/* readers | R | Core-backed collection (dropped_no_asset=0). Cards with an **ACTIVE listing are excluded** — a listed card has left the club. Keyed on the listing, NOT on the `trade` pile: the pile can hold cards with no listing (bare move, or cancelled/sold) and `/tradePile` renders only ACTIVE listings, so hiding the pile would make those invisible in BOTH views. Keying on the listing is self-healing — cancel/sale restores club visibility with no extra transition. Pagination then runs over the club-visible set (Core cannot filter host-owned listing state, so letting it paginate would yield short pages); with nothing hidden the fast Core-paginated path is unchanged. |
| GET /squad/0, /squad/active, /squad/list; PUT /squad/<n> | R | Core squad projection + tx; GET /squad/0 == active squad (verified structurally identical) |
| GET /user/accountinfo | R | {} |
| GET /user | R | `{"userInfo": …}` — same userInfo builder as userMassInfo (shared); squad rating is Core-authoritative (DIFFERENT-BY-DESIGN vs Python's stale value) |
| GET /settings | R | {"configs":[]} |
| GET /leaderboards/options | R | {} |
| PUT /match/reset | R | {} |
| GET /phishing/trusteddevice | R | security-question stateless ack |
| GET /hub | R | Core-derived counts; `clubPlayers` excludes actively-listed cards, `auctionCount`/`tradePile` from the durable market store |
| GET /club/stats/{year,consumables,staff,country,league,team} | R | Core aggregation; context buckets keyed nation/league/team (owned=1982); staff={} |
| GET /store, /match/keepalive, /captcha, /tfa, /livemessage, /activeMessage | R | unconditional constant acks (byte-identical to the oracle; StaticAck route) |
| GET /watchList (+ PUT/POST/DELETE) | R | empty watch list + authoritative Core credits; add/remove is a no-op ack (oracle persists none) |
| GET /season, /tournament, /champion, /clubUser, /user/list | R | FUT modes + club-identity off → `{}` (FeatureOffEmpty; byte-identical to the flag-off oracle). Migrated + deployed 2026-08-17 |
| POST /ut/.../match/end (DestroyMatch) | R | economy reward (coins credited via Core grant_reward) |
| GET /item/resource, /defid | R | `{itemData:[item_def…]}` — asset=rid&0xffffff; hardcoded Ronaldo (20801) + placeholder ("Player",75,CM,attrs 70), mirroring the oracle's `item_def`. Client renders from its LOCAL DB, so the placeholder is exact parity. Migrated + deployed 2026-08-17 |
| GET /marketdata, /marketdata/pricelimits | R | suggested pricing, constant band 150..15000. `/pricelimits` = bare ARRAY (one per defId); plain `/marketdata` = OBJECT — container type is load-bearing (object-where-array froze a live client). Migrated + deployed 2026-08-17 |
### NON-ECONOMY — still Python (PYTHON_FALLBACK)
| Method/path | Owner | Reason |
|---|---|---|
| POST /user/club (rename) | P | mutating club rename; Core has `clubs` but rename needs a Core write (deferred). Reads `clubUser`/`user/list` are now Rust. |
| GET /squad/<n> (n≠0, non-active) | P | no multi-squad Core model (Rust owns squad/0, squad/active, /squad/list, PUT) |
| /squad/mode/draft/* | P | FUT Draft mode |
| GET /leaderboards, /sbs/* | P | mode-gated (FUT_MODES/_SBC off → `{}`/content; `/sbs/sets` ships content); real behavior needs the mode logic ported. `season`/`tournament`/`champion` are now Rust. |
| POST /ut/.../match (CREATE), /match/ready (READY), /match (PLAY) | P | match handshake legs; no match ever played in-game (see docs/MATCH_LIFECYCLE.md) |
## AUXILIARY SERVICES (prod container OPENFUT_SERVERS="blaze roster pow")
All aux services are **Python in production today** (container `entrypoint.sh` runs
`blaze_responder_v3b.py`/`roster_server.py`/`pow_server.py`). Rust equivalents exist
outside Docker; deploying them is operator-gated (production deployment forbidden here).
| Service | Rust crate | Completeness | Prod owner | Reachable | Blocker to candidate |
|---|---|---|---|---|---|
| Blaze (:42130) | openfut-blaze-host + openfut-protocol-blaze + adapter::blaze | COMPLETE, gate-proven to real FUT (Gate 10: 3 logins, 10 pack opens, 448/448 py suite) | Python | yes | ERRC error-reply placement unresolved; wire into candidate bring-up |
| Redirector (:42127 TLS) | openfut-redirector-host + openfut-tls (OpenSSL vendored) | COMPLETE, 1 live handshake 2026-08-11 (TLSv1.2/AES256-GCM-SHA384) | Python | yes | never full-path gated; cert consistency |
| Roster (:8081) | openfut-roster-host | COMPLETE, oracle-parity + lifecycle tests, unit-only | Python | yes | never live-gated |
| POW (:8094 + :8080) | NONE (only pow_server.py) | no Rust host; 58 templates, bodies placeholder | Python | yes | LARGEST: no crate + bodies un-reversed |
| Nucleus (:42131) | none (advertised string only) | n/a | Python stub (advertised, unused) | NO (0 live hits) | DEAD in current flow — keep advertising URL, no migration |
RETIRED/out-of-scope: fifa-blaze (FIFA23 capture stub), openfut-bridge (FIFA23). Not in FIFA17 flow.
## NON-ECONOMY UTAS TARGET OWNER (confirmed via scouts)
Core already exposes GET/PUT /settings, GET /club|/collection|/statistics|/profile, /squad/*.
New Rust arm = Route variant + classify() arm (lib.rs:118-140) + owner-labelled handler.
| Route | Port complexity | Target | Notes |
|---|---|---|---|
| user/accountinfo | trivial-static ({}) | R | host constant |
| settings | trivial-static ({"configs":[]}) | R | host constant / Core /settings |
| leaderboards/options | trivial-static | R | host constant |
| match/reset | trivial-static ({}) | R | host constant ack |
| phishing/trusteddevice | small (validate hex + constant) | R | security-question: stateless ack, always verified/trusted |
| clientdata/userHubData | small stateful | R | Core PUT /settings upsert keyed userHubData |
| hub | medium (derived counts) | R | Core collection + market counts |
| club/stats/year | medium (rating-tier aggregation) | R | Core /collection + /statistics |
| club/stats/consumables | medium | R | BLOCKED on 17-consumable import |
| club/stats/staff | trivial ({}) or derived | R | BLOCKED on 3-staff import |
| account/sync | small-medium (persona select + save) | R | hardest: no direct Core route; host session/persona logic |
| ut/auth envelope | small (SID mint) | R (currently OBSERVE) | Python still mints envelope; boundary decision |
## MIGRATION PRIORITY ORDER (Phase 12)
1. Content gap consumable+staff emit (unblocks club/stats/{consumables,staff}) — import crate.
2. Trivial-static host routes: accountinfo, settings, leaderboards/options, match/reset, phishing/trusteddevice.
3. clientdata/userHubData (Core settings upsert).
4. hub + club/stats/year (Core-derived aggregation).
5. userMassInfo full ownership (envelope scaffold; econ+squad already Rust).
6. account/sync + ut/auth envelope (account/session boundary).
7. Aux candidate wiring (blaze/roster/redirector already built) + POW (blocked) + Nucleus (dead).
## ECONOMY EXPECTATION
Python economy hits = 0 (OBSERVED live + PROVEN by NEVER-BOTH/no-fallback tests).
Any nonzero Python economy hit = P1 regression, priority zero.
## STATUS
Baseline + economy + Rust-owned non-economy rows: OBSERVED/PROVEN.
Aux + non-economy target owners: confirmed via HostSourceMap/PythonContractMap/AuxServiceMap/ContentGapMap scouts.
## CANDIDATE MIGRATION STATUS (post-P1 progress, off-production)
DONE (Rust-owned in candidate source; committed on top of 5020137; workspace tests green):
- Content gap: consumable+staff emit (20 instances / 18 defs; verified real-profile re-import 1962+20).
- Non-economy routes migrated to Rust: user/accountinfo, settings, leaderboards/options,
match/reset, phishing/{trusteddevice,question,validate}, club/stats/staff, hub,
club/stats/{year,consumables}.
(hub clubPlayers = owned player count from Core; may be < Python profile count by the deferred
Legend instances = DIFFERENT-BY-DESIGN.)
- Reachability reporter (scripts/openfut-reachability.py) gates Python-hit invariants.
RESIDUAL PYTHON (still proxied; each has a concrete blocker, not ordinary difficulty):
- club/stats/{country,league,team} — RESIDUAL (nation/league/team context sub-screens). The global
MY-CLUB stat set (club/stats/{year,consumables,staff}) is now Rust (adapter club_stats.rs faithful
port of fut_club_stats.py VOCAB + counts, Core-accurate over real imported content, staging-verified
RUST route=club-stats owned=1982 players=1962). The per-nation-bucket context sub-screens still proxy
Python (low value, unrecognized atoms inert); migrate with a live context capture if ever needed.
- account/sync — launcher-facing (POST /openfut/account/sync, pre-auth); envelope has fields not in
Core (clubAbbr, established, profilePath, accountFunds cap); changing it risks the launcher. Needs
a Core account endpoint or host account logic + launcher-contract verification.
- userMassInfo — SAFE hybrid today (Rust overlays economy+squad on Python envelope). Full ownership
needs a real full-envelope capture first (missing one scaffold field breaks a hot route); deferred.
- ut/auth — ORDERING-BLOCKED: still-proxied Python routes rely on Python's session table, so auth
must stay proxied (Python mints SID, Rust OBSERVEs) until every session-needing route is Rust. Migrate LAST.
- clientdata/userHubData — BLOCKED: Core /settings supports only 2 fixed keys (difficulty,
preferred_formation); storing an arbitrary blob needs a frozen-Core change or a new host store.
Low-value UI-pref blob; kept Python per Phase 23 (no Python-by-ideology).
AUX (Rust built, deploy = operator-gated container cutover, NOT this task): blaze/roster/redirector.
POW = blocked (no crate, bodies un-reversed). Nucleus = dead (0 live hits).
docs/PROJECT_STATE.md
-192
View File
@@ -1,192 +0,0 @@
# OpenFUT — Project State
> **Canonical source:** `../OpenFUT-Vault/06 Agent Memory/Project State.md`
> This file is a mirror. If the two disagree, the vault wins. Update the vault first.
Factual snapshot. Prefer this over the stale root `README.md`/`CLAUDE.md` status tables (FIFA 23).
Last compiled from repository evidence during context initialization.
## Working
- **FIFA 17 offline FUT stack, end-to-end.** Proven 2026-08-01: auth → Blaze login → device-trust →
the FUT hub. Brought up by `fifa17-recon/tools/openfut-fut.sh start`. Evidence: `FUT-RUNBOOK.md`,
`fifa17-recon/README.md`, the five responder scripts, gate-ladder troubleshooting table.
- **ProtoSSL cert-pin defeat** — two live `/proc/PID/mem` patches (`autopatch.py`), VAs stable
across launches. gdb-verified which gate was the wall.
- **LSX / Origin layer** — crypto handshake reversed byte-exact and confirmed against the repack's
own emu disassembly (`docs/REPACK_INTEL.md`); Origin login gates cleared.
- **Blaze redirector + Fire2/Heat2** — both hops defeated; preAuth/login/personas answered.
- **UTAS/RS4 FUT API** — `ut/auth` + boot calls + device-trust reach the hub with hand-authored JSON.
- **Persistent FIFA 17 account selection** — the launcher synchronizes one configured EA persona to
the Python backend before starting LSX/FIFA. LSX, Blaze, POW/EASFC, and UTAS then share that
identity, while FUT coins, inventory, squads, progression, and unopened packs persist in an
isolated save beneath `fifa17-recon/docker/state/accounts/<persona-id>/`. The POW level/XP/funds
shown in FIFA's general account bar are account-scoped but remain distinct from FUT club coins.
A reversible server test on 2026-08-09 verified profile switching, POW values, a 400-coin pack
debit, five awarded items, and restoration of the original profile.
- **Account-scoped FUT security compatibility** — launcher account synchronization initializes a
persisted `securityQuestion` verification record in that persona's FIFA 17 profile. The UTAS
PHISHING handler returns the complete CardsDLL trusted-console response (`changed`, `exists`,
`locked`, `trusted`), accepts only well-formed legacy setup/validate requests under `X-UT-SID`,
and never stores or logs the client-transformed answer. This is server-side emulation; the hook
and launcher do not contain an answer or add UI automation. Automated contract coverage is in
`fifa17-recon/docker/ctx/tools/test_security_question.py`; live first/repeat-launch acceptance is
partially complete: the first launch entered FUT without a security dialog on 2026-08-09; a
second fresh-process FUT entry is still required to close persistence acceptance.
- **Safe responder diagnostics** — ordinary LSX logs redact challenge/session/auth-code attributes;
ordinary Blaze logs redact auth/session keys and no longer emit raw Fire2 hex, decoded TDF, or
config values. Forensic Blaze capture remains available only with the explicit
`OPENFUT_BLAZE_DUMP_FRAMES=1` opt-in. LSX and Blaze self-tests cover the new defaults.
- **OpenFUT Core** — Rust FUT economy backend, feature-complete for its scope and tested: profiles,
clubs, coins, packs, cards, squads, chemistry styles, SBCs, objectives, matches, market (NPC),
draft, FUT Champs, seasons, statistics, achievements, events, daily check-in, division
leaderboard, market trade history. 13 migrations. Integration suite (`tests/integration_test.rs`,
96 test fns) runs against in-memory SQLite; CI (fmt/clippy/build/test) green on `openfut-core`.
## Partially implemented
- **FIFA 17 FUT hub depth** — reaching the hub is proven, but how much of FUT is fully navigable
beyond it (playing matches, pack opening, SBC submission through the *game* UI vs. spinner/error
states) is not documented as complete. The runbook's gate ladder lists failure modes still
guarded against. Treat "past the hub" as unverified.
- **Pack opening through the game UI** — proven live on 2026-08-09 with the recovered CAGE test
profile: purchase, reveal, item assignment/quick-sell, wallet refresh, and return from the reveal
all completed. The Python transaction path also passes its 446-check contract suite. FIFA's
hardcoded post-reveal `mypacks` return is supported by a short-lived active grace record for every
opened pack; it is excluded from unopened-pack counts and retired at the next hub request.
- **FIFA 17 FUT match lifecycle** — CardsDLL static analysis and isolated responder tests now cover
CREATE→READY→PLAY→END. Bare `/match` requests carrying body `matchId` are classified as PLAY
instead of accidentally allocating another match; READY returns the verified scalar `matchId`
and `opponentPersonaId` fields; END persists W/D/L, matches played, and coin rewards per account.
The implementation is deployed and `test_match_lifecycle.py` passes, but no football match has
started or completed in FIFA yet. The READY opponent `items` contract and client mode-entry gate
remain unresolved; `FUT_MODES` therefore stays off by default.
- **Core ↔ emulation integration** — the two halves exist and wiring has **started**. First
slice (2026-08-11): the My Squad owned-player search. `openfut-core` gained a semantic,
game-independent owned-inventory query (`services::inventory::{OwnedItemQuery, apply_query}`
+ a `Quality` tier) that filters (AND) → orders deterministically → paginates, wired into
`GET /collection`; `openfut-adapter-fifa17::fut::owned_query` parses the FIFA17 `/club` wire
query and resolves numeric league/nation/team ids → semantic names (unknown id = hard error,
no raw-id passthrough). Intentional fix, not parity: Python applies only `league`+`team` and
ignores `level`/`rare`/`position`/`nation`/`start`/`count` (the request-amplification bug);
Core applies all proven filters and paginates. `rare=SP` semantics UNKNOWN, unimplemented.
Slice 2 (2026-08-11): `openfut-utas-host` — the first live UTAS host. Serves `GET …/club`
from Core through the adapter and reverse-proxies every other UTAS route verbatim to the
Python oracle (`utas_server.py`); plaintext HTTP/1.1 keep-alive, classify-before-execute,
no python-fallback after a Core error. `CoreAccess` is a host-owned boundary (the adapter
stays transport-agnostic). 11 host + 22 adapter tests; 10/10 mutations killed; fmt/clippy
clean. Slice 3 (2026-08-11, `3ef3bc3`): the real `Fifa17IdentityResolver` — catalog
(card id → real asset id) + persistent `openfut-identity` store (owned instance →
stable/reversible wire int) + wire-id policy, replacing all placeholders (one
production path). Wire-id namespace is globally monotonic within `(fifa17, owned-item)`,
not per-account (Core owned ids are UUIDs → unambiguous reverse). Slice 4 (2026-08-11,
core `36abd4b`): a curated 32-card real FIFA17 dev content pack
(`data/games/fifa17/dev/cards.json`, ids `fifa17_<asset>`), loaded only via opt-in
`Config.dev_content_games`; `seed-dev` grants a `game_id=fifa17` profile+club real
`OwnedCard`s (no FIFA wire ids — the resolver mints those at request time), idempotent,
default content untouched. Slice 5 (2026-08-11, `5276dd2`): the host sends
`X-OpenFUT-Game: fifa17` so `/club` resolves the all-mapped fifa17 profile —
**composition proven live** over HTTP (real Core+host, no FIFA client): FIFA wire query
→ real `resourceId`s (catalog) + stable/reversible wire `id`s (store); 33 renderable,
gold=22, Premier League=18, pagination page1=11/page2=7/overlap=0 (clean paging, no
drops). **The only remaining gate is the live retail FIFA A/B** (no FIFA client in the
build env; runbook `openfut-utas-host/README.md`). See the vault UTAS Endpoint Map +
Known Issues (incl. "identity resolution is NOT authorization" for later mutations).
**Slice 6 (2026-08-11): `/club` RUNTIME VALIDATED on retail FIFA 17** — operator-assisted
live A/B (`.105` client → `.120` backend via a source-scoped NAT redirect into a staged
`36abd4b` Core + `openfut-utas-host`). Every checkpoint passed on the real client:
transport, per-route Python fallback, Python-negative `/club`, Core `X-OpenFUT-Game`
scoping, real card + persistent owned-item identity (incl. the two-copy fixture),
no-filter/Gold/position/nation/league/team/combined-AND filtering, retail pagination
with no amplification, card selection, identity stability across relaunch, Python
rollback, and Rust re-enable (identity store byte-identical across the cycle, 0
reallocation). Live findings: the retail client steps `start += 10` with `count=11`
(sometimes bulk `count=100`) — Core honours `offset` and terminates; the My Club UI
nests team under league; the "~1900" club counter is Python `userMassInfo`, not `/club`.
Remaining is operational only (promote the staged stack to a durable deployment).
- **Slice 7 (2026-08-12): FUT squad authority (read + write) RUNTIME VALIDATED on retail FIFA 17.**
Staged operator-assisted A/B (`.105` retail client → `.120`, source-scoped utas switch
`:8099→:8199` into `openfut-utas-host` over a staged `615c5fd` Core seeded by `seed-dev` with the
dev 33-card inventory). FIFA itself consumed the Rust squad path end-to-end: FUT boot served
`RUST_OVERLAY userMassInfo` (squad overlay) and the squad screen rendered the dev XI; a controlled
in-game squad edit issued `PUT …/squad/0` → host `squad-replace` → Core → `{"id":0}`; an in-game
formation change f442→f433 persisted to Core (canonical fingerprint changed, `position_index`
remapped 0–10); a FULL FIFA relaunch cold-fetched and rendered the persisted f433 squad (no client
cache). Reversibility proven on the exact client path by log presence, not response data (both
backends coincidentally hold the same dev squad — the Python oracle `fifa17_profile.json` was
seeded from the same `squad_put_f442.json` capture): disarmed `.105:8099` reached Python (absent
from host log), re-armed reached Rust (`route=club limit=Some(9)` present); the persistent identity
store survived the cycle with 0 reallocation. Non-migrated routes (`/ut/auth`, `account/sync`,
`accountinfo`, `settings`, `hub`, store txn) correctly Python-fallback. NEW startup requirement:
the Core server loads dev card defs only for games in env `OPENFUT_DEV_CONTENT_GAMES` (comma-sep);
omitting `fifa17` makes `get_collection` silently drop every owned card (empty `/collection`,
"no squad") despite a successful seed — MUST become a deployment/preflight assertion. Preceded the
same day by a staged two-process parity gate (real Core+host over HTTP, no FIFA) confirming byte-
shape parity of `userMassInfo.squad` vs the captured oracle. Next milestone: real-data Core
import / profile strategy → production Rust UTAS. Blaze deferred.
- **Slice 8 (2026-08-12): REAL-DATA staged retail A/B PASS (import + club + squad).** The real FIFA 17
profile was imported into a staged Core via the two-store protocol (`openfut-import-fifa17 --apply`:
generic transactional Core import + `openfut-identity` seeding, idempotent), then FIFA itself
consumed it end-to-end over the source-scoped utas switch (`.105`→`.120:8199`). Imported population
1949 of 1962 player instances (13 Legend/special assets deferred as unnameable — 9 NoName + the 4
copies of `169193`), every original Python wire id preserved (set-equal, 0 minted/dropped), each
owned instance an opaque Core UUID. On the retail client: real club rendered (1949, not the 33-card
dev XI); `/club` pagination clean (paged==full, no loop/overlap/drop); the `Special` quality filter
returned only specials (1665, 0 base leaked) and paginated the filtered set; a squad edit persisted
to Core (canonical + opaque extension atomically, fingerprint recomputed) and survived a full cold
relaunch; rollback→Python→Rust re-enable proven on the exact client path (disarm reached Python,
re-arm returned the imported club + edited squad; identity store 0 reallocation). Three real-data
fidelity gaps the base-only dev fixture had hidden were found on the live client and fixed:
(1) `e187cd4` versioned `resourceId` — `shape_item` emitted the base assetId as `resourceId`,
collapsing every special onto its base card art; `Fifa17Identity` now carries the versioned
`resource_id`. (2) `626c972` observed `rareflag` — `shape_item` hardcoded `rareflag=1`, so all
specials rendered as basic rare; `rareflag` now flows through the FIFA catalog and onto the wire
(wire distribution == source exactly). (3) `6f16a23` `rare=SP` Special filter — previously a no-op
("semantics UNKNOWN"), now grounded as `rareflag > 1` and applied host-side (Core has no rareflag).
Also `44fcf24`: nation/league/team proven to be INSTANCE metadata (not definition identity — the 4
copies of `169193` are identical but for club), so the definition-consistency gate now compares
identity only (no `--defer-conflict` needed; no majority-vote). PRODUCTION NOT READY: the 13 deferred
Legends are unnameable from the `.120` client dump (absent/placeholder in `players.json`; DLC/Legends
name tables empty) — honest names require the FIFA 17 Legends locale data from the `.105` client.
Next: resolve the 13 names → re-import to 1962/0 → full-fidelity gate → gitlink reconcile →
production Rust UTAS.
## Stubbed / planned
- **`fifa-blaze`** (Rust) — Milestone 1 capture stub only. Two TLS listeners that log packets; no
FIFA 23 component/command handlers. Its own README says IDs are unknown. Superseded in practice by
the Python FIFA 17 responders, kept as the intended FIFA 23 implementation surface.
- **`openfut-launcher` legacy controls** — core/bridge and FIFA 23 setup controls belong to a
superseded plan. The launcher now also owns the live FIFA 17 client flow: server/hook config,
account synchronization, local LSX, privileged autopatch, and game launch.
- **`tools/`** (file-watch-diff, squad-injector, exporters) — helpers for the FLE-Lua-bridge idea in
`docs/direction.md`. Not part of the live FIFA 17 path.
- **`docs/foundational-xi-injection-test.md`** — a planned (not executed) test procedure for the FLE
bridge route.
## Stubbed / blocked (FIFA 23 lineage)
- **`openfut-bridge`** — in-process `version.dll` hook on ProtoSSL. Git history: injection works but
the effort hit an "architectural wall" (async event-driven gate, not a poll). Superseded first by
the FLE-bridge pivot, then by the FIFA 17 route. Its `CLAUDE.md` task list is historical.
## Unknown / requires investigation
- Whether the FIFA 17 hub supports actually **playing a FUT match** offline and getting results back.
- Whether FUT actions beyond the now-verified pack reveal/assignment flow (submit SBC, transfer
market buy/sell, matches) round-trip correctly through `utas_server.py`.
- The exact division of FUT state ownership once Core is wired in (who is source of truth).
- Degree of FIFA 23 wire-format identity — asserted ("identical wire format") but the FIFA 23 client
has not been re-tested against these responders in this repo's evidence.
## Known technical debt / hazards
- **Root docs are stale.** `README.md`, `CLAUDE.md`, `openfut-bridge/CLAUDE.md` all describe FIFA 23
as the target and mark FIFA 23 integration as the open item — they predate the FIFA 17 success.
- **All host state is volatile** across reboot except the `/etc/hosts` line — re-run
`openfut-fut.sh start`. Requires `ptrace_scope=0` + root arming (security-relevant).
- **Whole stack rides on EAAC staying neutralized** and game updates being off; a client update can
break the memory patches (VAs) and cert bypass.
- **`fifa17-recon/tools/lsx_responder_v2.py` is currently modified in the working tree** (uncommitted).
- `33068179` / `CAGE` remains the responder fallback, but the launcher now blocks one-button launch
until an explicit persona is configured and synchronized across LSX, Blaze, POW, and UTAS.
docs/PYTHON_RETIREMENT_PLAN.md
-45
View File
@@ -1,45 +0,0 @@
# Python Retirement Readiness (post-P1)
Classification of every Python component still present. Evidence: prod-host
`owner=` dispatch log (OBSERVED), AuxServiceMap/PythonContractMap scouts,
container `entrypoint.sh`. **P2 rollback stays hot regardless** (do NOT remove
rollback-to-python-p2.sh, :p2-rollback image b1b929953f, profile 39bb3e83).
## A. LIVE PRODUCTION REQUIRED (still owns behavior in the live flow)
| Component | Role | Rust status | Retire when |
|---|---|---|---|
| oracle utas_server.py (:8199) NON-ECONOMY | **remaining**: user/club rename, non-active squad/<n>, draft/*, mode-gated leaderboards + /sbs/* | **Most non-economy migrated 2026-08-17** (account/sync, auth, userMassInfo, user, clientdata, hub, club/stats/*, settings, accountinfo, phishing, match/reset, leaderboards/options, watchList, static acks, item-defs (item/resource,defid), marketdata (+/pricelimits), and the flag-off empty reads season/tournament/champion/clubUser/user/list → `{}` — all Rust). See PRODUCTION_AUTHORITY_MATRIX | remaining tail is mutation (user/club), no-Core-model (squad/<n>), or unimplemented modes (draft/leaderboards/sbs) |
| blaze_responder_v3b.py (:42130 Blaze) | FUT Blaze transport | Rust openfut-blaze-host COMPLETE, gate-proven (Gate 10) | container cutover (operator-gated deploy) |
| blaze_responder_v3b.py (:42127 redirector TLS) | first-hop TLS redirect | Rust openfut-redirector-host COMPLETE (OpenSSL) | container cutover + cert consistency |
| roster_server.py (:8081) | roster-update XML | Rust openfut-roster-host COMPLETE (unit-only) | container cutover |
| pow_server.py (:8094/:8080) | Proof-of-Work / content | NO Rust crate; 58 templates, bodies un-reversed | needs Rust host + body RE (BLOCKED) |
## B. ORACLE ONLY (reference / differential, not production authority)
- utas_server.py economy handlers: now oracle-only (economy is Rust; Python economy hits = 0). Used by
`economy_differential.rs` as the parity oracle. KEEP.
- fut_store.py / fut_accounts.py / fut_consumables.py: reference models + Ghidra-derived taxonomy source. KEEP.
## C. MIGRATION TOOL ONLY (offline)
- scripts/*.py (seed_fifa17_cards.py, utas-observe/mutate/diff, check-*). KEEP (dev tooling).
- fifa17-recon/tools/db_dump.py etc.: table extraction. KEEP.
## D. ROLLBACK ONLY (hot, DO NOT REMOVE)
- rollback-to-python-p2.sh; image openfut-fut-backend:p2-rollback (b1b929953f) + :dev; profile 39bb3e83;
compose/env backup; tuple OPENFUT_SERVERS="blaze roster utas pow".
## E. DEAD (advertised but not followed in current FIFA17 flow)
- Nucleus /connect/token stub (:42131): 0 live hits across Gate 5-10 (client never POSTs). Keep the ADVERTISED
URL so the client can't reach real EA, but no migration needed. No Rust listener required.
- fifa-blaze (FIFA23 capture stub), openfut-bridge (FIFA23): retired lineage, not in FIFA17 flow.
## Retirement gating
1. **Mostly DONE (2026-08-17)**: account/sync, ut/auth (Rust SID mint), userMassInfo (full), clientdata,
club/stats/{country,league,team}, watchList, static acks, the flag-off empty reads
(season/tournament/champion/clubUser/user/list → `{}`), item-defs (item/resource,defid), and
marketdata (+/pricelimits, container-type-exact) migrated + deployed. **Remaining on Python**:
user/club rename (mutating; needs a Core write), non-active squad/<n> (no multi-squad Core model),
and the unimplemented modes draft/* + leaderboards + /sbs/* (need the mode logic ported, not a proxy).
2. Deploy Rust blaze/roster/redirector via container cutover (operator-gated) — then those Python responders
are class D/E only.
3. POW: build Rust host + reverse bodies (largest blocker) OR keep Python POW as class A indefinitely.
4. Only after a long stable window: consider retiring the P2 rollback (separate explicit decision — NOT now).
docs/SOLD_STAGING_RUNBOOK.md
-293
View File
@@ -1,293 +0,0 @@
# SOLD-row A/B experiment — isolated FIFA-17 staging runbook
Operator procedure for driving the seller-facing **SOLD row** experiment with a real
FIFA 17 client against a **completely separate** staging stack, while the frozen P1
production stack keeps running untouched.
The experiment asks one question the PE cannot answer: for a `closed` trade-pile row,
does the FUT ActionScript front end treat `bidState:"highest"` or `bidState:"buyNow"`
as *"you sold this"*? Both are bit-identical to every native CardsDLL consumer, but
`bidState` is published to the movie verbatim as `YOURBID`, so only the client can
say. See `openfut-utas-host/src/sold_experiment.rs`.
---
## 1. What the two scripts do
| Script | Purpose |
| --- | --- |
| `scripts/sold-staging-up.py` | Brings up the **whole** staging stack (Core + utas-host + Blaze), seeds two identities, prints the client config block. One entry point. |
| `scripts/sold-staging-down.py` | Stops **exactly** the processes the up script recorded, proves the staging ports are free, and proves production is still alive. |
```bash
cd /home/alex/OpenFUT
# variant A — the sold row is closed / highest
python3 scripts/sold-staging-up.py --variant highest
# variant B — same state, only bidState (and optionally coinsProcessed) differ
python3 scripts/sold-staging-up.py --variant buyNow --coins-processed 1 \
--count-mode active_plus_sold
# projection disabled: identical to production behaviour (control run)
python3 scripts/sold-staging-up.py --variant off
python3 scripts/sold-staging-down.py # stop, keep dbs/logs as evidence
python3 scripts/sold-staging-down.py --purge # stop and delete the staging dir
```
To flip A → B, run `sold-staging-down.py` then `sold-staging-up.py --variant buyNow`.
The staging databases are throwaway: a fresh `up` deletes the previous ones and
reseeds, so each variant run starts from a known state. Never edit a live stack's
environment in place — the banner in `logs/utas-host.log` is the only record of which
variant produced a capture, and it is written at startup.
---
## 2. Staging port block and state
Everything lives under `/home/alex/openfut-sold-staging/` (override with `--dir` or
`OPENFUT_SOLD_STAGING_DIR`).
| Service | Bind | Notes |
| --- | --- | --- |
| staging Core | `127.0.0.1:18081` | loopback only; the client never talks to Core |
| staging utas-host | `0.0.0.0:8299` | the UTAS the client reaches |
| staging Blaze redirector | `0.0.0.0:42327` | TLS; receives EA `:10041` and `:42230` |
| staging Blaze main | `0.0.0.0:42330` | receives EA `:42127` |
| staging Blaze nucleus | `0.0.0.0:42331` | local OAuth stub |
| dead Python upstream | `127.0.0.1:8399` | **must stay unbound** (see §5) |
The redirector is on `42327`, not the "obvious" `42227`: that port is permanently
held by `openfut-redirector-host` (pid 862419).
| State file | Path |
| --- | --- |
| Core sqlite | `staging-core.db` |
| market sqlite | `staging-market.db` |
| pile sqlite | `staging-pile.db` |
| identity store | `staging-identity.json` |
| clientdata blobs | `staging-clientdata.json` |
| content pack | `content/fifa17-production-cards.json` |
| identity catalog | `content/fifa17-production-catalog.json` |
| patched Blaze | `blaze/blaze_responder_staging.py` |
| process manifest | `manifest.json` |
| logs | `logs/{core,utas-host,blaze,blaze-responder}.log` |
Seeded identities (direct SQL against the schema Core migrates for itself):
* **Seller A** — profile `prof-seller-a-cage`, club `club-seller-a-cage`, username
`CAGE`, `game_id = fifa17`, 1 000 coins, 11 starters in a canonical squad, plus
**one disposable item** (`owned-a-disposable`, card `fifa17_232273`, Nelson Atiagli
LB 51) — that is the card to list and sell during the experiment.
Seller A carries `game_id = fifa17`, so the retail client (which sends
`X-OpenFUT-Game: fifa17`) resolves to this profile and can log in as persona
`33068179`.
* **Buyer B** — profile `prof-buyer-b`, club `club-buyer-b`, 20 000 coins, parked on
its own `game_id = fifa17-buyer-b`. Core is single-profile-per-game, so this keeps
Buyer B from ever shadowing Seller A as the active `fifa17` profile while still
being reachable by club id for a settlement.
---
## 3. The client change — the only thing the operator touches
The FIFA client learns its **UTAS** base URL from Blaze, not from `openfut.cfg`:
`blaze_responder_v3b.py` builds `UTAS_BASE = "http://%s:8099/" % _ADVERTISE` with the
port **hardcoded**. The up script therefore copies the responder into the staging dir
and rewrites that literal to `:8299`. **Pointing the client at staging Blaze is
sufficient to move UTAS too** — there is no UTAS line in `openfut.cfg`.
On the FIFA client machine **10.10.0.105**, file
`"/mnt/games/FIFA 17/openfut.cfg"`:
```bash
# back it up FIRST
cd "/mnt/games/FIFA 17"
cp openfut.cfg openfut.cfg.prod
```
Set these **three** lines:
```
host=10.10.0.120
blaze_redirector_port=42327
blaze_main_port=42330
```
Leave `https_port=8443` **unchanged** — that is Bridge, which holds no economy
state. The resulting file is:
```
host=10.10.0.120
https_port=8443
blaze_redirector_port=42327
blaze_main_port=42330
```
Then **relaunch the FIFA 17 client.** A client that is already running caches its
UTAS session (SID) in memory and will not re-auth against a different stack; the
symptom is the dialog *"An error occurred downloading the FUT Squad Update"* with
**zero** requests in the staging host log. "The operator is at the main menu" is not
the same as "the client disconnected".
### Revert to production
```
host=10.10.0.120
https_port=8443
blaze_redirector_port=42127
blaze_main_port=42130
```
or simply `cp openfut.cfg.prod openfut.cfg` — then **relaunch the client again**.
These are the values the file holds today; the staging scripts never write to
10.10.0.105, so this revert is the *only* client-side change to undo.
---
## 4. Running the experiment
1. `python3 scripts/sold-staging-up.py --variant highest`
2. Apply §3 to the client and relaunch it. Confirm it reaches the FUT hub;
`logs/utas-host.log` should show `route=auth status=200 sid_opened=true`.
3. List the disposable item on the transfer market from the client.
4. Complete the sale (Buyer B side) through the real settlement path.
5. Observe the seller's Transfer List: which bucket the row lands in, what the
counter says, and which request the client issues to clear it. Capture both the
screen and `logs/utas-host.log`.
6. `python3 scripts/sold-staging-down.py`
7. `python3 scripts/sold-staging-up.py --variant buyNow`, relaunch the client, and
repeat steps 3–5. The two runs differ **only** in `bidState` (and
`coinsProcessed`/`count` if those flags are used), which is what makes the client's
reaction attributable.
8. When done: `sold-staging-down.py` and revert the client per §3.
`DELETE /ut/delete/game/fifa17/trade/sold` clears the sold rows (logged as
`route=market-clear-sold cleared=N`) — that is the verb the client is expected to
issue from the *Clear Sold* affordance, and seeing whether it does is part of the
observation.
---
## 5. Isolation: what guarantees production is untouched
Production frozen P1 must keep running throughout. The scripts enforce, not assume:
* **Hard port deny-list.** `8099 8199 18080 8443 42127 42130 42131 4216 8080 8081
8094` are refused before every bind and before every HTTP request the scripts make.
Each staging port is also proven free first, and bring-up aborts before launching
anything if one is not.
* **Hard path deny-list.** Every filesystem path goes through `safe_path()`, which
refuses `/home/alex/openfut-promotion/state/` (the live `prod-core.db`,
`prod-market.db`, `prod-pile.db`, `prod-identity.json`). Nothing there is ever
opened — not even read. The FIFA17 content the staging stack loads is copied from
`/home/alex/openfut-post-p1/staging/emit/content/`, a build tree outside that
directory.
* **The Python fallback fails closed.** `OPENFUT_UTAS_PYTHON_URL` points at
`http://127.0.0.1:8399`, where **nothing listens**, so a fallback to the Python
oracle surfaces as a visible connection error instead of silently serving the
production oracle on `8199`.
* **Binaries are copied into the staging dir and run from there.** A later
`cargo build` cannot change what staging is running, and — more importantly — every
staging process's `/proc/<pid>/cmdline` provably contains the staging directory,
which production's never can.
* **Teardown kills by recorded pid only, never by pattern.** `openfut-utas-host` and
`openfut-core` each name *two* live processes on this machine. `sold-staging-down.py`
reads pids from `manifest.json`, re-reads `/proc/<pid>/cmdline` and **refuses** to
signal anything whose cmdline does not contain the staging dir; it refuses the known
production pids explicitly; and it signals only the process group the up script
created (`pgid == pid`, via a new session). There is no `pkill`/`pgrep` anywhere.
* **The Blaze patch cannot silently no-op.** Six substitutions are applied to the
copy, each anchored to a whole assignment line and each required to match **exactly
once**; the file is then re-read from disk and every value re-checked, including an
explicit assertion that `UTAS_BASE` no longer contains `:8099`. A responder that
changed shape aborts bring-up rather than running half-patched and pointing at
production. The four protocol values are `REDIR_PORT`, `BLAZE_PORT`,
`NUCLEUS_PORT`, `UTAS_BASE`; the two extra ones are the responder's hardcoded
`LOG = "/tmp/blaze_responder.log"` and `RXDIR = "/tmp/blaze_rx"`, redirected into
the staging dir so a capture can never be ambiguous about which stack wrote it.
* **Production liveness is asserted** at preflight, at the end of bring-up, and after
teardown (`prod utas-host` pid 3631953, `prod Core` pid 3374264).
* **Nothing on 10.10.0.105 is written.** The scripts only *print* the config block;
the operator edits it by hand.
### Production services deliberately shared, read-only
Staging Blaze advertises the **production** auxiliary endpoints, exactly the strings
production Blaze advertises:
| Advertised to client | Value | Why sharing is safe |
| --- | --- | --- |
| roster XML / roster URL | `10.10.0.120:8081` | static roster update XML; **no economy state**. Hardcoded as `ROSTER_HOST = "%s:8081" % _ADVERTISE` in the responder. |
| `FIFA_POW_CONTENT_SERVER_URL` | `10.10.0.120:8085` | static POW content; no economy state (`POW_CONTENT_HOST`) |
| `FIFA_POW_URL` / nucleus proxy | `10.10.0.120:8094` | POW API, only emitted when `FUT_POW=1`, which staging leaves unset (`POW_HOST`) |
| LSX layer-1 responder | `:4216` | persona/session handshake for the same persona `33068179`; no economy state |
The staging stack **never connects** to any of these itself — it only hands the client
the same strings production hands it. Every service that owns economy state (UTAS,
Core, market/pile/identity) is duplicated on staging ports against staging files.
Because those aux services are shared, **do not run a staging session and a
production session simultaneously**: one client at a time.
`heat2` (TDF codec) and `fut_account` (the single source of truth for persona
`33068179` / `CAGE`, shared with LSX and the oracle) are imported read-only from
`fifa17-recon/tools/` via `PYTHONPATH` rather than copied, so the staging Blaze
asserts a **byte-identical** identity to what LSX already asserts. Cross-layer
identity consistency is the constraint; a divergent copy would break login.
---
## 6. Verifying a live stack by hand
All read-only, and none of it touches a production port:
```bash
S=/home/alex/openfut-sold-staging
# which variant is live
grep sold-experiment $S/logs/utas-host.log
# staging UTAS answers, from staging state
python3 - <<'PY'
import http.client, json
c = http.client.HTTPConnection("127.0.0.1", 8299, timeout=5)
c.request("GET", "/ut/game/fifa17/tradePile/counts",
headers={"X-OpenFUT-Game": "fifa17"})
print(c.getresponse().read().decode())
PY
# the patched Blaze points at staging UTAS, not production
grep -nE '^(UTAS_BASE|REDIR_PORT|BLAZE_PORT|NUCLEUS_PORT) = ' \
$S/blaze/blaze_responder_staging.py
# exactly six lines differ from the original responder
diff fifa17-recon/tools/blaze_responder_v3b.py \
$S/blaze/blaze_responder_staging.py
# no staging process has a handle on production state
for p in $(python3 -c "import json;print(' '.join(str(x['pid']) for x in json.load(open('$S/manifest.json'))['processes']))"); do
echo "pid $p: $(sudo ls -l /proc/$p/fd | grep -c openfut-promotion/state) prod-state handles"
done
# production is still up
ps -o pid=,cmd= -p 3631953
```
Never `curl` port 8099/8199/18080 to "compare with production" — those ports are on
the deny-list. Independence is proven structurally (separate pids, separate ports,
separate files, zero shared handles), not by poking the live stack.
---
## 7. Troubleshooting
| Symptom | Cause / fix |
| --- | --- |
| `REFUSING to start -- these staging ports are not free` | something else holds a staging port. Nothing was launched. Free it, or edit the port block at the top of `sold-staging-up.py`. |
| `a previous staging stack is STILL UP` | run `sold-staging-down.py` first. The up script never steps on a live stack. |
| `blaze patch <NAME> applied 0 times` | `blaze_responder_v3b.py` changed shape. Fix the regex in `blaze_patches()`; do **not** disable the assertion. |
| `seed card ids are not resolvable` | the emitted content in `CONTENT_SRC` no longer contains a seeded `card_id`. Re-point `CONTENT_SRC` or update the seed ids — both memberships (content pack **and** identity catalog) are required. |
| client shows *"error occurred downloading the FUT Squad Update"*, staging host log shows **no request at all** | the failure is upstream of UTAS. Almost always a client that was not relaunched after the config change (§3). Check the *absence* of requests in `logs/utas-host.log` before touching any code. |
| `<name> pid N is alive but its cmdline does NOT contain <staging dir>` | pid reuse or a stale manifest. Teardown refuses rather than guessing — identify the process by hand and stop it by pid. |
| staging host log shows connection errors to `127.0.0.1:8399` | expected and intended: a UTAS route fell through to the Python fallback, which is deliberately dead. Fix the route; do **not** point the fallback at `8199`. |
docs/direction.md
-250
View File
@@ -1,250 +0,0 @@
# OpenFUT — Direction Document
*The pivot: FUT lives in the app; FIFA 23 is the match renderer.*
*Supersedes the Blaze-backend approach as the primary plan. Last updated 2026-06-30.*
---
## 1. Goal (revised)
Deliver an **intuitive way to play a FUT-style experience with FIFA 23**, where:
- The entire **FUT experience** — cards, squads, packs, SBCs, coins, chemistry,
progression — lives in a **custom app** (web UI or desktop) built on the
already-complete OpenFUT Core economy backend.
- **FIFA 23 is demoted to a match renderer.** Its only job is to play a
single-player match using the squad the app built. No FUT mode, no online, no
Blaze, no EA servers.
This deliberately drops in-game FUT cards/UI (they live in the app) in exchange
for a project that **converges** instead of being gated behind months of
backend reverse-engineering.
### Why this replaces the backend plan
The status review confirmed the backend route (faking EA's online stack) is
blocked at an upstream in-process EbisuSDK gate, with Blaze/Fire2 unconfirmed
beyond it — realistically 3–6 months of expert RE that may not converge. The
app-centric route sidesteps **every** wall in that review by never making FIFA's
own FUT mode run.
---
## 2. Base mode: Career, not Kick-Off
**Career mode is the base.** Reasons:
- FLE's live-editing API (`EditDBTableField`, Freeze Lineup) is **confirmed to
work in career mode** and explicitly does NOT work in FUT/online modes.
- Career already provides the FUT-shaped scaffolding we'd otherwise fake:
persistent club, a fixture schedule, recorded results, progression across a
season.
- **Match results are written into the career DB**, making result capture a DB
read rather than a fragile live-memory grab.
**Kick-Off is the prototype sandbox.** Use it first to prove squad injection
works with nothing to corrupt (no save to break), then move the real loop onto
career. Run the foundational injection test in BOTH.
---
## 3. Core architecture: the bidirectional FLE bridge
The backbone is a **bidirectional channel between the app and a resident FLE Lua
script running inside the game.** Everything else is messages over this channel.
```
Custom App (FUT experience)
│ squad push ──────────────► ┌─────────────────────────────┐
│ │ Resident FLE Lua script │
│ ◄────────── game state │ (inside FIFA 23, career) │
│ ◄────────── match result │ - reads game state │
└────────────────────────────► │ - applies squad live │
(file-watch or local socket) │ - reads results from DB │
└─────────────────────────────┘
│
FIFA 23 plays the match
```
Three message types over the bridge:
1. **App → Game: squad push.** The app's chosen XI + stats applied LIVE via
`EditDBTableField`, replicating whatever DB write FLE's "Freeze Lineup"
feature performs (see `docs/foundational-xi-injection-test.md` — the exact
field(s) are found by diffing, not assumed). No restart, no
file-copy-reload. (File-load remains a fallback.)
2. **Game → App: game state.** The resident script polls the game's current
screen/menu state and reports "safe to apply" vs "not safe", driving a smart
Apply button in the app (see §5).
3. **Game → App: match result.** After full-time, the script reads the result
from the career DB and pushes score/scorers to the app, which awards
coins/progression. (Manual entry is the baseline fallback.)
The bridge transport can be a watched file the in-game Lua polls, or a local
socket — decided in build (see §7). Either way the *game keeps running*; a file,
if used, is just the message channel, not a reload.
---
## 4. Tiered mod scope
Build in tiers matched to risk. The core tier is all the SAME kind of DB write,
so it lands together once squad injection works.
### Tier 1 — Core writes (ride the same live DB-edit mechanism)
- **Squad / custom XI** — the load-bearing primitive (Freeze Lineup's
underlying write, replicated via script — see §6).
- **Player stats as "cards"** — card tiers, in-form versions, SBC upgrades all
expressed as written attribute values.
- **Chemistry as stat adjustment** — app computes FUT chemistry, applies it as
small stat bumps when writing players in (no in-game chem UI; that's in the app).
- **Appearance / identity** — kits, names, team assignment, so the club looks
like your club on the pitch.
- **Formation / tactics** — squad structure carries the app's build onto the pitch.
### Tier 2 — Confirm-then-add
- **Match difficulty per game** — to drive a Squad-Battles-style "this opponent is
World Class". Settable in-game trivially; programmatic drive needs confirming.
- **Match rules / modifiers** (half length, etc.) — for app-defined challenges.
### Tier 3 — Result capture (manual baseline + automated stretch)
- **Manual:** user enters the score in the app after the match. Zero RE, ships
first.
- **Automated:** resident script reads the career-DB result (or, for Kick-Off,
reads the in-match score from memory at full-time — precedent exists: the
CM cheat table's `export_season_stats.lua` already reads goals/cards from
memory via known offsets). Push to app → auto-award progression.
### Out of scope (stays in the app, by design)
- In-game FUT cards, FUT menus, pack-opening animation, chemistry board, FUT
presentation. The app is where it looks/feels like FUT.
---
## 5. The smart Apply button (state-aware)
Live DB edits only "stick" in safe menu states (the in-game "Edit Player" screen,
for example, overwrites edits). So the bridge reads game state and gates applying:
- Resident Lua script polls the game's current-screen value (a few Hz),
classifies **safe / not safe**, reports to the app.
- App's **Apply button is enabled only when the script confirms a safe state**
(squad hub, main menu); greyed otherwise.
- **Safe-by-default-OFF:** unknown state → button greyed → never a risky write.
Expand the known-safe list incrementally as states are confirmed.
- **v2 (more seamless):** instead of greying, the app always lets you click and
the script **queues** the apply, executing the moment a safe state is entered,
then confirms back. Greying is v1; queue-and-apply is v2.
`IsInCM()` is a confirmed state-read; the specific screen-state address + the
value→screen mapping is one-time reconnaissance (same technique as result reading).
---
## 6. What's confirmed vs what needs validating
**Confirmed (from FLE's own Lua API docs/wiki, checked 2026-06-30):**
- FLE live-edits the running career DB without restart, via `EditDBTableField`
(real signature: `EditDBTableField(cell)` where `cell = row["fieldname"]`
with `.value` mutated first — not the table/index/field/value form an
earlier draft of this doc assumed).
- FLE reads game state via `IsInCM()`.
- A `MEMORY` Lua class exists (`ReadInt`/`WriteInt`/`ReadMultilevelPointer`/
etc.) for arbitrary process memory — confirms the result-reading fallback
in §4 Tier 3 is a real, documented capability, not just cheat-table analogy.
- `GetPlayersStats()` is a documented function returning per-player
goals/assists/cards/etc. — a better confirmed path for match-result capture
than raw memory offsets.
- **Freeze Lineup** (Formation Editor → arrange XI → tick "Freeze Lineup" →
`Data → Save`) is FLE's actual documented mechanism for forcing a starting
XI in career mode. This **replaces** "selection bias" below.
- OpenFUT Core (economy) is complete and tested.
**Walked back — not actually confirmed:**
- "Selection bias forces specific players into the starting XI" — no such
field appears anywhere in FLE's documented Lua API or its own example
scripts. This was an unverified assumption carried over from general FIFA
modding precedent (other titles), not anything checked against FLE/FIFA 23.
See `docs/foundational-xi-injection-test.md` for the corrected plan, which
uses Freeze Lineup instead.
**Needs validating (the foundational tests — see §7):**
- Whether Freeze Lineup actually holds into a played match (FLE's wiki
documents the feature but not a live-match test of it).
- What DB table/field Freeze Lineup's `Data → Save` actually writes — it's
GUI-only and undocumented at that level; finding it is part of the
foundational test.
- Whether that write can be replicated by a script (`EditDBTableField`) well
enough to drive it from an EXTERNAL trigger, not just the Formation Editor
UI — required for the app↔game bridge.
- The app↔game bridge transport (file-watch vs socket) works cleanly under the
run setup.
- The screen-state address + safe/not-safe classification (FLE's `Events`
API page exists in the wiki index but its content is currently empty/
undocumented — this is more open than previously assumed).
- Result read-back from the career DB after a match.
**Standing caveat:** the whole stack rides on **EAAC staying neutralized**
(FLE's fake-launcher bypass). If a game update re-enables it, hooks fail. Keep
game updates off; confirm neutralized state each session.
---
## 7. Build order / next steps
Each is a bounded, verifiable step. Do them in order; later ones depend on
earlier answers.
1. **FOUNDATIONAL TEST — live custom XI in career.** Confirm Freeze Lineup
holds into a played match, reverse-engineer the DB write it makes, then
replicate that write from a script so it can be triggered externally
instead of through the Formation Editor UI. See
`docs/foundational-xi-injection-test.md` for the full procedure. *Done =
a script-driven write produces a match that fields the squad you
specified.* Everything rests on this.
2. **Pick the bridge transport.** Decide file-watch vs local socket for app↔game
messaging; implement the minimal app→game squad push. *Done = app sends a
squad, the resident script receives and applies it.*
3. **Game-state reader + smart Apply.** Find the screen-state address, classify
safe/not-safe, expose to the app, gate the Apply button. *Done = button greys
when you enter a match/edit screen, enables in the squad hub.*
4. **Result read-back.** Read the career-DB match result post-game, push to app,
award progression. Manual entry ships alongside as the fallback. *Done = app
updates coins from a played match.*
5. **Tier 1 breadth.** Extend the squad push to carry stats, appearance,
formation (same write mechanism). *Done = the club looks and plays like the
app's build.*
6. **Tier 2 + economy loop polish.** Difficulty drive, challenges, and the full
pack → SBC → squad → match → reward loop closed end-to-end.
### Decision still open
- **App form factor:** web UI vs desktop app. This affects the bridge transport
(a desktop app can hold a local socket more naturally; a web UI leans toward a
small local helper/file-watch). Decide before step 2.
---
## 8. Provenance
Clean-room throughout. This route relies on FLE's documented public API and the
game's own supported career mode — no EA backend, no Blaze, and nothing derived
from leaked EA source. The earlier backend RE remains clean-room and is preserved
as a spec artifact; it is simply no longer the primary path.
---
## 9. One-paragraph summary
OpenFUT becomes a **FUT companion app that uses FIFA 23 as a match engine.** The
app owns the entire FUT experience; a resident FLE Lua script in career mode
applies the app's squad live (no restart), reports game state to drive a safe
Apply button, and reads match results back to feed progression. This sidesteps
every backend wall, runs on confirmed FLE capabilities, builds on the finished
economy core, and delivers the intuitive, offline, FUT-flavored loop that is the
actual goal.
docs/evidence/FIFA17_EMPTY_MYPACKS_CLIENT_CONTRACT.md
-443
View File
@@ -1,443 +0,0 @@
# FIFA 17 — Empty "My Packs" Client Contract (store/purchasegroup)
> **STATUS (2026-08-13): ROOT CAUSE ESTABLISHED; P2 backend compatibility workaround
> IMPLEMENTED.** Root cause: FIFA 17's Store/Scaleform path resolves the `mypacks`
> category even with zero unopened packs, and CardsDLL `FUN_1800147f0` assumes the
> resolved group is non-null (crash if absent). Backend decision: **P2** — emit an
> **active** non-openable synthetic `mypacks` placeholder (id 65534) when
> `unopenedPackIds == []` (`fifa17-recon/tools/utas_server.py` `store_catalog`; tests
> `fifa17-recon/tools/test_empty_mypacks.py`). Crash-safe + economy-safe; known UX
> limitations (fake tile, click-dialog, Browse→My-Packs nav quirk) are Scaleform-driven
> and require the client-side fix in `docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md`.
> This is a FIFA-17-specific compatibility shim, NOT an EA-authentic representation,
> and is confined to the FIFA-17 adapter/backend (NOT OpenFUT Core).
Evidence labels: **OBSERVED** (runtime capture / crash dump / already-decompiled RE
quoted in-repo), **INFERRED**, **HYPOTHESIS**, **UNKNOWN**. No server behavior is
changed by this document; it is analysis only.
Binaries (hashes verified 2026-08-13 on `.105`):
`CardsDLL_Win64_retail.dll` SHA-256 `4706a881ae1fc7b5769fd810b25a868d29d2b16a8e65a7513436327ef645573c`
(load base in the crash dump `0x00006FFFFC120000`; RE-space base `0x180000000`).
`FIFA17.exe` SHA-256 `29c31cef12b0c3c2a7305220617c7b4fa139ab76b8c857851bdbe88987962899` (packed).
## 1. Question
How must the server represent an account that owns **zero unopened packs** in
`GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true` so that FIFA 17 neither
(a) crashes nor (b) shows "The pack you've selected is currently not available",
**without granting the user a real/openable pack** and without breaking the normal
bronze/gold/special store? The current OpenFUT answer (a synthetic inactive `mypacks`
sentinel) only downgrades a crash to a dialog; it is not the correct contract.
## 2. Established experimental behavior (OBSERVED)
Profile-state ladder, all with normal packs 1/5/6/7 unchanged:
| profile `unopenedPackIds` | `mypacks` group in response | client outcome |
|---|---|---|
| `[]` (baseline) | one **inactive** sentinel pack `65534`, empty description | "pack not available" dialog → FUT Hub |
| `[70]` (Exp A) | one **active** real owned pack `70` | **store works**; My Packs visible |
| `[]` + sentinel suppressed (Exp B) | **no `mypacks` group at all** | **client CRASH** |
Captures: `store_purchasegroup_capture_2026-08-12.json` (baseline),
`…_mypacks70_2026-08-12.json` (A), `…_empty_no_sentinel_2026-08-12.json` (B).
Details in `STORE_TILE_6C.md` §14-§15.
## 3. Existing RE evidence (from `docs/plan-2026-08-05-store-subsystem.md`, decompiled)
All addresses RE-space (CardsDLL base `0x180000000`):
- **`FUN_18013af30`** — per-element pack deser; each `purchase[]` entry → a `0x158`
wire record. `displayGroup.value`(atom 0x377) → record `+0x00` (ctor default the
literal `"unknown"`). `displayGroup.priority`(0x250) → `+0x34`.
(store-subsystem §"wire record", :996.)
- **`FUN_1800150d0`** — group builder. Walks `purchase[]` in array order; for each
pack, finds-or-creates a `0x108` display group by **exact strcmp of
`displayGroup.value` against `group+0x70`** (`FUN_180014380`). New group
(`FUN_180012950`): `+0x00` = 1-based ordinal (groups-so-far+1), `+0x100` =
priority, **`+0x104` = (value == "mypacks")**, `+0x40` = vector of `0x1a8` tile
models. Pack→tile via `FUN_18002c3c0`. (:152-161, :1042-1049.)
- **`FUN_1800147f0`** — group **resolver/renderer**, called as
`FUN_1800147f0(model, screen+0x290, dataProvider, 0, 0)` from `FUN_18007dab0`.
`screen+0x290 == 0` → "list the group tiles" (`FUN_180014610`); **any other value
→ `FUN_180014420`, which exact-matches `group+0x00` (the ordinal) and returns NULL
on a miss, after which `FUN_1800147f0` dereferences `[RAX+0x40]` with NO guard**
("checked in raw disassembly … a real absence"). **"The only legal category values
are 0 and the ordinals 1..N."** (:163-169, :1051-1054.)
- **`FUN_180014580`** — the six-tab bar: switch 0..5 over the hardcoded lowercase
literals `mypacks, points, bronze, silver, gold, special`. `FUN_18007e5e0` gives
each panel a `PANEL_ID` = the matching group's ordinal, **or HIDES the panel** if no
matching group; `FUN_18007df60` publishes `MYPACK_/…/SPECIAL_CATEGORY_ID`.
(:202-206, :1058-1062.)
## 4. Store parser code path (OBSERVED, decompiled)
```
HTTP 200 {"purchase":[...]} (server: store_catalog / _pack_body)
→ per-element deser FUN_18013af30 → 0x158 wire records
→ FUN_1800150d0 → 0x108 display groups (by displayGroup.value),
tiles (0x1a8, FUN_18002c3c0) into group+0x40
→ render FUN_18007dab0 → FUN_1800147f0(model, screen+0x290, …)
screen+0x290 == 0 → FUN_180014610 list this group's tiles
screen+0x290 == N>0 → FUN_180014420 exact-match ordinal; NULL on miss
→ [RAX+0x40] dereference (NO NULL GUARD) ← crash site
```
## 5. My Packs group construction (OBSERVED)
A `mypacks` group exists **iff at least one `purchase[]` entry carries
`displayGroup.value == "mypacks"`** (the group is derived from packs; there is no
independent group object on the wire). Its ordinal is its 1-based creation position
in array order; `group+0x104` is set because the value is `"mypacks"`; its tiles live
in `group+0x40`. Consequently the server **cannot** emit an "empty `mypacks` group"
via `purchase[]` — removing the pack removes the group entirely.
## 6. Default / selected group logic (partly UNKNOWN)
- `FUN_1800147f0` resolves whatever category ordinal it is handed via `screen+0x290`;
legal values are `0` (list tiles) and `1..N` (existing ordinals). A value that is
not an existing ordinal (e.g. `-1` for a hidden/absent panel) → `FUN_180014420`
NULL → crash. (OBSERVED via §8 crash + RE.)
- **Whether the store defaults to / auto-resolves the `mypacks` category on open, and
why it does so even when the unopened count is 0, is UNKNOWN** — the store-screen
controller and default-tab selection are Scaleform/packed-FIFA17.exe
("Which tile the movie thinks you clicked | CLIENT | Scaleform, unread",
store-subsystem :695). Experiment B proves that in this configuration the client
DID resolve a `mypacks` ordinal that did not exist (it crashed), so the store is
reaching the My Packs category with zero owned packs. Root of "why" = UNKNOWN.
## 7. Pack availability predicate (UNKNOWN)
The predicate that turns the baseline inactive sentinel into "pack not available"
(while active pack 70 passes) is **in the packed FIFA17.exe and unread**
(`plan-2026-08-05-pack-opening.md:553`: `state/saleType/quantity/purchaseLimit/
purchaseCount/start/end` are parsed and copied to the tile, "the predicate that greys
a tile is in the packed exe and unread"). Candidate deciding fields, from the
baseline↔A diff (INFERRED, unproven): **`state` (`inactive`→`active`)** and/or
**`unopened` (`false`→`true`)**. The exact field is **UNKNOWN**.
## 8. Experiment B crash analysis (OBSERVED)
Minidump `CrashDump_…18.21.08…dmp` (the only crash in the hour; minute `:21` matches
the `00:21:07` store request; SHA-256 `fbddda18…`), parsed:
- Exception: **`0xC0000005` ACCESS_VIOLATION**, access type **READ**, **faulting VA
`0x0000000000000048`**.
- Faulting instruction: **`CardsDLL_Win64_retail.dll + 0x14882`** → RE-space
**`0x180014882`** = **`0x92` bytes into `FUN_1800147f0`** (entry `0x1800147f0`).
- Interpretation (OBSERVED crash ⋂ decompiled RE): the group pointer returned by
`FUN_180014420` was **NULL** (no `mypacks` group present with `unopenedPackIds==[]`
and the sentinel suppressed), and `FUN_1800147f0` dereferenced `[NULL+0x48]` → read
of address `0x48` → access violation. This is exactly the "no null guard" branch
the RE flagged (RE said `[RAX+0x40]`; the actual faulting offset is `+0x48`, same
member region — the group struct's `+0x40` vector accessed via a `+0x48` field).
- Note: the pre-built Ghidra project and `/tmp/fut/cardsdll.dll` were absent on `.105`
(tmp cleared); confirmation used the OBSERVED crash dump + the previously-decompiled
RE rather than a fresh (expensive) re-analysis. CardsDLL is unpacked, so this code
is statically readable if a fresh project is ever needed.
## 9. Empty My Packs client contract (the answer, as far as evidence allows)
- **The client has NO guard for a missing selected group.** If the store resolves the
`mypacks` category and no `mypacks` group exists, it null-derefs and crashes.
(OBSERVED.)
- **A `mypacks` group can only exist if a `purchase[]` entry carries
`displayGroup.value=="mypacks"`.** (OBSERVED.) There is no wire representation of an
"empty group."
- **If the `mypacks` group's selected pack is not a valid/active pack, the client
shows "pack not available".** (OBSERVED baseline vs A; deciding field UNKNOWN, §7.)
- Therefore, under the *current* client behavior, a zero-unopened-packs account is
only cleanly handled when the `mypacks` group contains a **valid active pack**
(Exp A). Whether an active-but-non-openable placeholder would also satisfy the
availability predicate is **UNKNOWN** (depends on §7).
- **The correct retail-EA representation of zero unopened packs is UNKNOWN.** It is
NOT "omit the group" (crash) and NOT "inactive placeholder" (dialog). It is most
likely one of: (i) the retail store does not auto-select My Packs when the unopened
count is 0 (a client/Scaleform decision, possibly gated by a count the server sets),
or (ii) retail sends a `mypacks` entry the client treats as an empty-but-valid state
via a field we have not identified. Neither is established.
## 10. Candidate server representations
| # | Candidate | Client evidence | Expected behavior | Confidence | Safe to test? |
|---|---|---|---|---|---|
| A | No `mypacks` pack, no `mypacks` group | Exp B crash (`0x180014882`, `[NULL+0x48]`) | **CRASH** | OBSERVED | Already tested — reject |
| B | `mypacks` group present but zero packs | Not representable via `purchase[]` (groups derive from packs, `FUN_1800150d0`) | UNKNOWN | INFERRED-not-representable | No server mechanism |
| C | Inactive placeholder pack (current sentinel) | Baseline dialog | "pack not available" → Hub | OBSERVED | Already tested — reject |
| C′ | **Active** placeholder pack, id absent from `PACK_CATALOG` (so open/buy handlers reject it) | Exp A shows an *active* mypacks pack works; sentinel id 65534 is already rejected by open/buy (not in `PACK_CATALOG`) | Group resolves (no crash); MIGHT pass availability (no dialog) while remaining non-openable → no free pack | HYPOTHESIS | Yes — code change, restart; economy-safe (non-openable) |
| D | Hide My Packs when unopened count == 0 | `FUN_18007e5e0` hides a panel with no group, but the store still resolved `mypacks` at count 0 (Exp B crash) | Hiding via absence CRASHES; a client count-gate is Scaleform/unknown | UNKNOWN | Not server-controllable as far as known |
| E | Different default category when count == 0 | Default-tab selection is Scaleform/packed | UNKNOWN | UNKNOWN | Not server-controllable as far as known |
| F | A count/quantities field (e.g. `ut/v2/store` `FutStorePackQuantities`, or `userInfo.unopenedPacks`) that suppresses the My Packs auto-select | eligibility gate exists (`ENDPOINT_MAP.md:60`); relationship to My Packs default UNKNOWN | UNKNOWN | HYPOTHESIS | Read-only RE first |
## 11. Recommended next controlled experiment
**Experiment C′ (economy-safe placeholder).** Keep `unopenedPackIds == []`; change the
synthetic sentinel `65534` ONLY in `state` (and, if needed, `unopened`) so the
`mypacks` group's single tile is **active** — but leave its id `65534` **absent from
`PACK_CATALOG`** so `store_buy`/`open_pack`/`consume_unopened_pack` still reject it
(no pack can be opened → **no free pack, no economy change**). Observe whether the
store then opens without the "pack not available" dialog (would identify `state` as
the availability field and give an economy-safe fix), or still shows the dialog
(implicating another field / packed predicate).
- Requires a temporary code change to `store_catalog` (sentinel construction) →
restart. Same experiment discipline as Experiment B (patch container copy, capture,
revert, restart). Economy-safe because the placeholder remains non-openable.
- If C′ still fails, escalate to read-only RE of the availability predicate / the
count-gated default-tab hypothesis (candidate F) before any further change.
## 12. Open questions
1. Exact field that flips the sentinel from "pack not available" to acceptable
(`state`? `unopened`? another). UNKNOWN — packed predicate. (Exp C′ targets this.)
2. Why does the store resolve/select `mypacks` with zero owned packs? Is there a
server-settable count that would stop it? UNKNOWN — Scaleform/packed.
3. Does retail FIFA 17 ever present an empty My Packs, and how? No capture on record.
4. Is an active-but-non-openable placeholder (C′) accepted by the availability
predicate? HYPOTHESIS — untested.
---
## Permanent-fix requirements (Phase 11 — REPORT ONLY, not implemented)
A correct permanent fix MUST satisfy ALL of:
- Zero unopened packs must **NOT** grant the user a free pack.
- No synthetic **openable** reward may be created (any placeholder must be rejected by
`store_buy`/`open_pack`/`consume_unopened_pack`).
- Client must **not crash** (a resolvable `mypacks` group must exist, OR the client
must be kept from resolving `mypacks` when empty).
- Client must **not** show "The pack you've selected is currently not available".
- Normal Bronze/Gold/Special store categories must still work unchanged.
- When a genuine unopened pack exists, My Packs must continue to work (Exp A).
- Profile/economy semantics must remain correct (no coins/nextItemId/inventory drift).
Nothing implemented. The evidence favours investigating an **economy-safe active
placeholder (C′)** and/or the **count-gated My-Packs default (F)**; it explicitly does
NOT support "grant pack 70 whenever My Packs is empty".
---
## UPDATE after Experiment C′ (2026-08-13) — active non-openable placeholder tested
Executed C′: sentinel 65534 `state "inactive"→"active"` only; `unopenedPackIds==[]`;
65534 kept out of `PACK_CATALOG`. Full record in `STORE_TILE_6C.md` §16. Capture:
`store_purchasegroup_capture_active_placeholder_2026-08-12.json` (C′-vs-baseline JSON
diff = only `65534.state`).
**Resolves §7 (availability predicate), partially:** `state` **DOES participate**
(OBSERVED). `state:"active"` removed the "pack not available" dialog while the group's
existence still prevented the crash. So the earlier §7 "deciding field UNKNOWN" is
updated: **`state` (inactive vs active) is (at least) a deciding field** for the
dialog. `unopened` was NOT varied and remains untested. The full predicate may still
involve other fields, but `state` alone flips dialog→no-dialog.
**Updated candidate table verdict:**
- **C′ (active placeholder, non-openable): SUPPORTED with UX caveats — best option so
far, but NOT adopted.** No crash, no dialog, store usable, and **no automatic
transaction/open for 65534** (only a routine boot `TRANSACTIONCANCEL` no-op).
Caveats (OBSERVED): (1) the placeholder renders as a **visible empty pack tile**
("0 items, 0 bronze, 0 rares", no cover) that a user could try to open (server-safe:
opening 65534 → no-op `{}`/stale `last_pack`, no value — §16.1); (2) **navigation
gate**: from the Store "Browse Packs" entry the Bronze/Gold/Special categories are
not reachable until "My Packs" is opened first (not present with a genuine owned
pack, Exp A).
- A (real active pack 70): works cleanly but grants a real openable pack → economy
risk; rejected as the permanent fix.
- Candidate **F (count-gated My-Packs default)** gains weight: C′'s visible-empty-tile
and Browse-Packs navigation gate suggest the client is being pushed to resolve/enter
My Packs when it should not with zero packs. If a server-settable count (e.g.
`userInfo.unopenedPacks` / `ut/v2/store` quantities) suppresses the My-Packs
default/tile, that could remove both the crash risk and the empty-tile artifact
without any placeholder. UNTESTED.
**Permanent fix: still NOT established.** Even though C′ is the first
crash-free/dialog-free representation, the empty-tile UX + navigation gate + the
untested "explicit placeholder selection" behavior bar adoption. Required next steps
(design/authorize separately): (a) controlled test of explicitly focusing/opening the
active placeholder; (b) investigate candidate F (count-gated My-Packs) to avoid a fake
tile entirely. Do NOT adopt `state:"active"` or "grant pack 70" as the fix on current
evidence.
---
# Candidate F — Count-Gated My Packs Navigation (READ-ONLY investigation, 2026-08-13)
Question: can the server make FIFA decide **not** to resolve/default into My Packs
when the account owns zero unopened packs (avoiding any placeholder)?
## 1. Server-sent unopened-pack signals (inventory, OBSERVED code)
| field / endpoint | source | value source | when sent | client consumer | conf |
|---|---|---|---|---|---|
| `userInfo.unopenedPacks.recoveredPacks` (via `userMassInfo`) | `utas_server.py:409-414` | `len(unopenedPackIds)` | boot massinfo; only if count>0 **or** `_UI∈{packs,full}` (default `_UI=roster` → omitted at 0) | hub unopened-pack model / My Packs badge (`FUN…vtbl[0x4e0]`, pack-opening RE) | OBSERVED (code) |
| `/user/credits` `.unopenedPacks.recoveredPacks` | `utas_server.py:3542-3545` | `len(unopenedPackIds)` | on credits fetch; **only if count>0** | My Packs badge / CentralUnclaimedPack hub tile | OBSERVED (code+capture) |
| `/hub` body | `utas_server.py:1449-1453` | — | hub load | — (**no pack count present**) | OBSERVED |
| profile `unopenedPackIds` | `fut_store.py` | account state | internal | not wire-visible directly | OBSERVED |
`pileSize`/`store quantities` (`ut/v2/store` `FutStorePackQuantities`) exist as an
eligibility gate (`ENDPOINT_MAP.md:60`) but were **never requested** in any capture
(8h logs); they carry a store-open `result`, not a My-Packs count.
## 2. Pre-store request sequence (OBSERVED, captures)
Boot → `accountinfo → /ut/auth → settings → phishing → match/reset → userMassInfo →
PUT store/transaction/0 (TRANSACTIONCANCEL→{}) → /hub → clientdata → /user/credits →
GET /store/purchasegroup/all`. The only pack-count-bearing responses **before**
`purchasegroup` are `userMassInfo`(userInfo) and `/user/credits`.
## 3. Baseline([]) vs Experiment A([70]) pre-store diff (OBSERVED, captures)
The single profile change `[] → [70]` altered exactly one pre-store wire signal:
- `/user/credits`: **`[]` → no `unopenedPacks` member** (C′ capture, all 3 fetches:
`{"credits":…,"currencies":[…]}`); **`[70]` → `"unopenedPacks":{"preOrderPacks":0,
"recoveredPacks":1}`** (A capture line 25). OBSERVED.
- `userInfo.unopenedPacks`: same pattern (present at `[70]`, omitted at `[]` with
`_UI=roster`). INFERRED from code; A-capture credits corroborates.
- **No other pre-store field changed.**
Candidate signal:
```
Candidate: unopenedPacks.recoveredPacks (count)
Endpoint: /user/credits and userMassInfo(userInfo)
Baseline([]) value: ABSENT (i.e. zero)
Experiment A([70]) value: {preOrderPacks:0, recoveredPacks:1}
Source: utas_server.py:3542-3545 / :409-414 (= len(unopenedPackIds))
Client-visible before purchasegroup?: YES
Confidence: OBSERVED that it differs; its CONTROL over My-Packs nav = see §9
```
**Key point: this count is already CORRECT** — it reports zero (absent) when the
account is empty. OpenFUT is **not** misreporting a nonzero pack count.
## 4. Navigation / client call path (OBSERVED, decompiled RE)
`FUN_18007dab0 → FUN_1800147f0(model, screen+0x290, …)`. `screen+0x290==0` lists
group tiles; else `FUN_180014420` exact-matches the group ordinal (NULL on miss →
`[NULL+0x48]` crash). `screen+0x290` is written in exactly two CardsDLL sites: the
screen ctor `FUN_18007d1a0` writes `0`, and **`FUN_18007e7f0` case `0x7551` copies
the Flash movie message field `CATEGORY_ID` verbatim** into it
(store-subsystem :172-175, :1055-1056). So the resolved category is chosen by the
**Scaleform movie**, not by any server response field.
## 5. `GOTO_STORE_MYPACK` analysis (OBSERVED, RE)
`GOTO_STORE_MYPACK` is the **destination of the hub `CentralUnclaimedPack` tile**
(tile type 0x1c); "Nothing in the chain issues a request, and no request could
exist" (pack-opening :888-890). Whether that HUB tile appears is gated by the
unopened-pack count in the hub model (`model+0x20950`) — i.e. the count DOES control
the *hub unclaimed-pack tile*, but the operator reached the store via **Browse Packs**
/ the store screen, whose category resolution is the movie-driven `CATEGORY_ID` path
(§4), not `GOTO_STORE_MYPACK`. `GOTO_STORE_MYPACK` is a UI navigation command,
**not** a server-state-gated store-category selector.
## 6. Candidate count/flag fields — verdict per field
- `unopenedPacks.recoveredPacks`: correct at 0 when empty; controls the hub badge /
CentralUnclaimedPack tile, **not** the store's category resolver. Not a viable gate
for the store My-Packs entry.
- No other server field feeds `screen+0x290` (RE §4: only ctor-0 and movie
`CATEGORY_ID`).
## 7. EA-capture evidence
No EA-origin `purchasegroup`/`credits` capture for a zero-unopened-packs account
exists in the repo (all captures are OpenFUT-generated). EA count semantics for empty
My Packs remain **UNKNOWN**.
## 8. Where My Packs selection occurs (OBSERVED)
**Before** `purchasegroup` parsing decides content, the **Scaleform movie** decides
which category to resolve and writes it to `screen+0x290` (§4). The server's role is
limited to which groups EXIST in `purchase[]`. Therefore the sentinel is compensating
for a **movie-side** decision to resolve My Packs; it is not fixing an incorrect
server count (the count is already correct).
## 9. Candidate F verdict — **F3 (CONTRADICTED)** (with an F4 residue)
My Packs selection is **not** controlled by server-sent unopened-pack state:
- OBSERVED: the server count is correctly zero/absent when empty, yet the store still
resolved My Packs (baseline dialog, Exp-B crash). A correct zero signal did not stop
it.
- OBSERVED (RE): `screen+0x290` (the resolved category) comes from the movie's
`CATEGORY_ID`, with no server-field input; default is 0.
Residue (F4): the movie's internal logic for *why* it asks for My Packs on store open
is in packed Scaleform and is not statically readable — but no server lever into it
has been found. **Conclusion: there is no server-controlled count/flag that makes FIFA
skip resolving My Packs; the server can only ensure the `mypacks` group exists.** The
"clean count-gated fix" is therefore **not achievable server-side**.
## 10. Proposed next experiment
Because F is contradicted, a count experiment is NOT recommended (the count is already
correct and does not gate the store). No single-variable server signal will make FIFA
enter Browse Packs instead of My Packs. The realistic next step is the previously
deferred **explicit active-placeholder selection test**: with the C′ active
non-openable placeholder in place (sentinel 65534 at baseline otherwise), have the
operator explicitly focus/open the empty My-Packs tile and observe (server-safe per
§16.1 — opening 65534 is a no-op — but UX/navigation behavior unknown). That
characterizes the best available server-side option (C′) before any adoption.
- Would it change profile state? No (`unopenedPackIds=[]`).
- Would it change purchasegroup/sentinel behavior? Only `state:"active"` (as C′),
reverted after.
- Code change? Yes (same one-line C′ patch). Restart? Yes. (Not authorized here.)
If explicit selection proves unsafe/ugly, the remaining options are all **client-side
/ out-of-scope** (the decision is in the Scaleform movie), or accepting C′ with its
documented UX artifacts.
**Candidate F does NOT provide the hoped-for clean fix. The active non-openable
placeholder (C′) remains the best server-side representation; its empty-tile and
Browse-Packs navigation artifacts are movie-driven and not server-fixable.**
---
# Explicit Active-Placeholder Selection Test — FINAL backend-side result (2026-08-13)
With the C′ active placeholder in place (`unopenedPackIds=[]`, 65534 active/mypacks/
∉PACK_CATALOG), the operator explicitly opened the empty My-Packs tile once. Full
record in `STORE_TILE_6C.md` §17.
- **Outcome: S1 — pure client-side rejection.** Dialog **"This pack is no longer
available"** → back to My Packs → Hub; **no crash**, navigation stays usable.
- **No server request** on selection (no `/store/transaction`, no `/purchased/items`,
no 65534 reference); the verdict is client-side. (OBSERVED)
- **Zero economy/profile mutation:** coins/items/nextItemId/`unopenedPackIds`/
`last_pack` all unchanged; profile byte-identical (`39bb3e83…`); 65534 not
persisted. (OBSERVED)
**Active-placeholder verdict: MARGINALLY ACCEPTABLE** — crash-safe + economy-safe +
navigable, but with user-visible defects (empty fake tile; "no longer available" on
explicit click; Browse-Packs nav gate). It is a *strict improvement* over the current
inactive-sentinel baseline (which errors on store OPEN and bounces to Hub).
**Backend-side question is now fully answered.** The complete zero-unopened-packs
ladder:
```
no mypacks group -> CardsDLL null-deref CRASH (unsafe)
inactive placeholder -> "pack not available" on store open -> Hub (baseline)
active placeholder -> store loads; empty tile; "no longer available" only on
explicit click; recoverable; economy-safe (best backend option)
real active owned pack -> fully correct UI (but grants a real openable pack — economy risk)
```
**Permanent-fix recommendation: P2.** The active non-openable placeholder is the best
*safe* backend-only option, but a fully *clean* zero-pack experience is **not**
achievable server-side (Candidate F CONTRADICTED — the My-Packs resolution is
Scaleform/movie-driven). Recommend: adopt the active placeholder as an optional
backend compatibility mode (safe, strictly better than baseline) AND pursue a
client-side fix (hide the fake tile / stop the forced My-Packs resolution) for the
fully clean result. **Not implemented.** Do NOT grant a real pack.
---
## Client resolver-guard experiment (2026-08-13) — RESULT F3 (crash, confounded)
A client-side `autopatch.py` memory guard (CardsDLL `0x180014858` `JNZ`→`JG`, routing
category `<0` to list-all/Browse) was tested against the exact no-sentinel server condition
(sentinel 65534 suppressed; `GET /store/purchasegroup` ids `[1,5,6,7]`, no mypacks group).
The client **crashed at the identical resolver site `0x180014882`** (`[NULL+0x48]`), because
it presented a **positive** My-Packs ordinal (crash is in the `>0` resolve branch), not the
`-1` the guard diverts. **Confound:** FIFA was not relaunched after the backend flip, so it
reused stale (sentinel-present) tab state. So the negative-only guard is **insufficient for a
positive stale/invalid ordinal**, and the fresh-client case is **not yet decided** (needs a
clean re-test: fresh launch with backend already no-sentinel). Backend P2 sentinel was
restored immediately (mandatory rollback). Full record + candidate stronger guard:
`docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md` PART III.
## Fresh-process no-sentinel retest (2026-08-13) — RESULT R1 (SUCCESS)
Re-ran the above cleanly: backend entered no-sentinel mode **while FIFA was closed**, then a
**fresh** FIFA (pid 553220, new autopatch 552999, guard `85 ff 7f 0f` enforced) launched and
opened the Store. The genuine no-sentinel `/store/purchasegroup` (ids `[1,5,6,7]`, no 65534/
mypacks) is **byte-identical** to the F3 capture, so the only changed variable is client
process lifetime. Outcome: **no crash, no dialog, Store opens on Browse Packs, packs
navigable** (cosmetics only: no tabs / no cover art / "0 items" — pre-existing). A fresh
client publishes category `-1` for the absent group, which `JNZ→JG` routes to Browse/list-all
with no NULL deref. **This confirms F3 was stale-positive-ordinal contamination, and proves
Strategy A (resolver guard) on the tested build.** Backend P2 sentinel restored immediately
(`f416e71e…`, `state=active`) and remains production default. Full record:
`docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md` PART IV.
docs/evidence/STORE_TILE_6C.md
-924
View File
@@ -1,924 +0,0 @@
# Store Tile Investigation (bug 6c)
Status: **ROOT CAUSE ESTABLISHED — P2 compatibility workaround IMPLEMENTED**
(2026-08-13). Full investigation complete (§1-§17); backend fix landed in
`fifa17-recon/tools/utas_server.py` `store_catalog` with regression tests in
`fifa17-recon/tools/test_empty_mypacks.py`. The store-tiles flags are unchanged
(`FUT_STORE_DISPLAYGROUP=ON`, `FUT_STORE_GROUPID=OFF`) and the profile is unchanged.
## RESOLUTION (2026-08-13)
**ROOT CAUSE (bug 6c):** FIFA 17's Store/Scaleform path RESOLVES the `mypacks`
category even when the account owns zero unopened packs (the category is chosen
client-side from the movie's `CATEGORY_ID` → `screen+0x290`; no server field gates
it — Candidate F CONTRADICTED). CardsDLL `FUN_1800147f0` then dereferences the
resolved group with NO null guard, so an absent `mypacks` group crashes the client
(`CardsDLL_Win64_retail.dll+0x14882`, `[NULL+0x48]` — minidump-confirmed, §8).
**BACKEND RESULT / DECISION — P2 (compatibility workaround):** emit a synthetic,
**active**, non-openable `mypacks` placeholder (id 65534, absent from `PACK_CATALOG`)
only when `unopenedPackIds == []`. This is crash-safe AND economy-safe (explicit
selection is rejected client-side with "This pack is no longer available", sends no
backend request, and mutates nothing — §17). It is a FIFA-17 client-compatibility
shim, **NOT** an EA-authentic empty-My-Packs representation, and is confined to the
FIFA-17 adapter/backend layer (NOT OpenFUT Core).
**KNOWN UX LIMITATIONS (unfixable server-side):** a fake empty "0 items" tile; an
explicit-selection dialog "This pack is no longer available"; and a Browse-Packs →
My-Packs navigation quirk. These are Scaleform/movie-driven.
**CLEAN CLIENT FIX:** still unresolved; belongs to client-side work —
`docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md`.
Evidence labels: **OBSERVED** (running code / `docker inspect` / live log / minidump /
table), **INFERRED**, **HYPOTHESIS**, **UNKNOWN**.
### Hypotheses
- **H1 (original — subtype/definition):** *Store tiles render "unknown" because the
server emits definitions whose type/subtype the client cannot map (prime suspects
5004xxx misc {231,232,233,236}, 8010xxx league logos, FCC↔wire subtype gaps).*
**Verdict: CONTRADICTED by static store-handler evidence.** The `/store/purchasegroup`
handler emits PACK definitions only — no `cardsubtypeid`/`carddbid`/`cardassetid`
anywhere in the response (§2). Those subtype families belong to the separate
**club-item / consumable / equippable** paths (`fut_clubitems.py`, `fut_consumables`,
`/club?type=`), which are OUT OF SCOPE for this store-tile task. History preserved
in §3.3 and §8; not investigated further here.
- **H2 (revised — displayGroup token):** **HYPOTHESIS (under runtime test).** *The
"unknown" FUT Store tile is caused by one or more pack entries whose
`displayGroup.value` token is not one of the six categories FIFA 17 can render:*
`mypacks, points, bronze, silver, gold, special`. Tested against a real capture in
§4-§8.
---
## Runtime capture plan (Phase 2) — OBSERVED
- **Backend container:** `openfut-fut-backend` (logs on stdout via `log()`,
`utas_server.py:59-62`; each request logs `"<VERB> <path>"` at `:3732`, and the
response line `" -> <code> <body[:200]>"` at `:3754` — **response body truncated
to 200 bytes**, so the full JSON body is NOT in the log).
- **Endpoint / path matcher:** `GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true`
(OBSERVED historically in the log; route regex `/store/purchasegroup`,
`utas_server.py:1215`).
- **Capture marker (UTC, set immediately before the manual test):**
`2026-08-12T23:54:01Z` (saved to `/tmp/store_capture_marker.txt`; 0 log lines
after it at set-time → clean boundary).
- **Log command to isolate the manual action:**
`docker logs --since 2026-08-12T23:54:01Z --timestamps openfut-fut-backend`
then locate the first `GET .../store/purchasegroup` line after the marker plus its
following headers and `-> 200 {"purchase"...` line.
- **Full-body recovery (because the log truncates at 200 bytes):** the response is a
deterministic pure function — `store_catalog()` (`:3408`) over static `PACK_CATALOG`
(`fut_store.py:820`) + live `STORE.unopened_packs()` (from `/state` profile) under
fixed flags (`STORE_DISPLAYGROUP=ON`, `STORE_GROUPID=OFF`, `FUT_PRICE_PROBE=OFF`).
Plan: reconstruct the exact body from the running `/app` code + live `/state`
profile, then **verify** its `json.dumps(...)[:200]` byte-for-byte equals the genuine
logged 200-byte prefix. Match ⇒ the reconstruction IS the sent body. No request is
synthesized, replayed, or curl'd; the genuine log line is the ground-truth anchor.
## 1. Method
### Environment (OBSERVED)
- Running on `10.10.0.120` (dev-lxc). Client is `10.10.0.105`.
- Backend under test: Docker container `openfut-fut-backend`
(image `openfut-fut-backend:dev`), `Up 7 hours`, entrypoint `/app/entrypoint.sh`.
- `docker inspect openfut-fut-backend`: only mount is
`/home/alex/OpenFUT/fifa17-recon/docker/state -> /state (rw)`; container ENV
contains **no `FUT_STORE_*`** vars.
- `entrypoint.sh` launches `python3 -u utas_server.py` from `/app/tools` with extra
env `FUT_TRADING=1 FUT_PILESIZES=1 FUT_TRADEABLE=1 FUT_DISCARD_TABLE=1
FUT_DISCARD_SEND=1` — again **no `FUT_STORE_*`**.
- The running store code is `/app/tools/utas_server.py`. Extracted read-only via
`docker cp openfut-fut-backend:/app/tools /tmp/app-tools` and confirmed
**byte-identical** (`sha256`) to the repo copy
`fifa17-recon/tools/utas_server.py` (both 3765 lines) and
`fifa17-recon/tools/fut_clubitems.py`. All line references below are to the repo
paths and equal the running code.
### Commands (exact)
```
docker ps --format '{{.Names}}\t{{.Image}}\t{{.Command}}\t{{.Status}}'
docker inspect openfut-fut-backend --format '...CMD/ENTRYPOINT/MOUNTS/ENV...'
docker exec openfut-fut-backend cat /app/entrypoint.sh
docker cp openfut-fut-backend:/app/tools /tmp/app-tools
docker cp openfut-fut-backend:/app/data /tmp/app-data
diff /tmp/app-tools/utas_server.py fifa17-recon/tools/utas_server.py # identical
diff /tmp/app-tools/fut_clubitems.py fifa17-recon/tools/fut_clubitems.py # identical
```
### Manual test sequence
NOT executed. The manual FIFA-client store capture (2D/2E) was never reached
because the investigation blocked at 2C before any flag could be enabled. No
request was synthesized, replayed, or simulated.
---
## 2. Store handler code path (2A) — OBSERVED
Request → response for the store tile screen:
1. **Endpoint.** `GET ut/<sku>/store/purchasegroup/...` — `FutStoreGetPackTypes`
(client deser root `0x1801234e0`). (`utas_server.py:3408-3409` docstring.)
- Route table entry: `(re.compile(r"/store/purchasegroup"), lambda m,h:
store_catalog(h))` at `utas_server.py:1215`.
- Sibling store routes: `/store/transaction -> store_buy(h)` (`:1216`, the BUY);
bare `/store(\?|$) -> (200,{"result":"SUCCESS"})` eligibility gate (`:1221`).
2. **Handler.** `store_catalog(h)` (`utas_server.py:3408-3447`).
- Iterates `PACK_CATALOG` (non-`ownedOnly` packs) → `_pack_body(p, idx)`.
- Appends owned unopened packs from `visible_unopened_packs()` →
`STORE.unopened_packs()` + `_OPENED_PACK_GRACE` (`:51-52`, `:3423-3427`).
- If no owned packs, appends one inactive `mypacks` sentinel (id 65534) so
`GOTO_STORE_MYPACK` resolves (`:3428-3446`).
- Returns `200, {"purchase": [<pack bodies>], "timestamp": 1596326400}`
(`:3447`).
3. **Definition construction.** `_pack_body(p, idx, owned=False)`
(`utas_server.py:3268-3405`). Emitted keys (OBSERVED, `:3293-3328`):
`assetId`(=`p["id"]`), `id`(=`p["id"]`), `packType`, `description`(=`p["name"]`),
`state`, `saleType`, `limitType`, `quantity`, `purchaseLimit`, `purchaseCount`,
`isPremium`, `sortPriority`, `currencies`, `extPrice`, `packContentInfo`
(`bronze/silver/gold/rare/itemQuantity`), `unopened`, and one of:
- owned pack → `displayGroup = {"value":"mypacks","priority":idx}` (`:3336`);
- else if `STORE_DISPLAYGROUP` → `displayGroup = {"value": category}` where
`category ∈ {special, gold, silver, bronze}` chosen from
`p["specialChance"]`/`p["gold"]` (`:3337`,`:3373-3379`), and if `STORE_GROUPID`
also `displayGroupAssetId = p["id"]` (`:3403-3404`).
4. **Data source(s).**
- `PACK_CATALOG` — a hardcoded list of 3 pack dicts
(`{id,name,price,count,gold,tiers,specialChance}`) at `fut_store.py:820-841`.
There is NO card table read in this path.
- `STORE = Store()` (`fut_store.py:843`), backed by the profile JSON
(`unopened_packs()` reads `unopenedPackIds`, `fut_store.py:619-621`).
5. **Serialization → HTTP.** The dict is JSON-encoded by the server's response
writer and returned as the HTTP body.
### Fields 5 (`cardsubtypeid`/`carddbid`/`cardassetid`) — OBSERVED
**None of `cardsubtypeid`, `carddbid`, or `cardassetid` appear anywhere in the
store-tile (`purchasegroup`) response.** `_pack_body` (`:3293-3405`) emits only the
pack keys listed above; `assetId`/`id` are the PACK id `p["id"]` (e.g. 1, 5), not a
card asset id. The store catalog emits PACKS, never card definitions. (Grep of
`_pack_body` and `store_catalog` for those three field names returns zero hits.)
### Families the store handler can emit
Only **packs** (`PACK_CATALOG`: "Bronze Pack" id 1, "Gold Pack" id 5, and the third
catalog entry) plus owned reward packs and the `mypacks` sentinel. It cannot emit
any card family (players, staff, consumables, club items).
### Filtering / transformation
- `normal = [p for p in PACK_CATALOG if not p.get("ownedOnly")]` (`:3421`).
- `_pack_body` maps a pack to a category token via `specialChance>=1.0 -> special`,
else `gold -> gold`, `p.get("silver") -> silver`, else `bronze` (`:3373-3379`).
- The tile caption/category is `displayGroup.value`; `description` carries the
per-pack title.
---
## 3. Wire subtype coverage (2B)
### 3.1 Store path
The store-tile path emits **no `cardsubtypeid`** at all (see §2). So for the store
tile, "is `cardsubtypeid` the raw FCC subtype, the wire category, transformed, or
something else?" → **not present** (N/A). The store tile is selected by
`displayGroup.value` (a category-token STRING), not by any card subtype.
Per `_pack_body:3367-3372` (citing `FUN_180014580`/`FUN_180014df0`): FIFA 17's
StoreFront resolves exactly **six hard-coded category tokens** —
`mypacks, points, bronze, silver, gold, special`. Any other `displayGroup.value`
(e.g. a raw pack title) creates an "unsupported pseudo-category". The documented
cause of "unknown" store tiles is therefore a **`displayGroup` category-token**
issue on packs (absent group, or a non-canonical token), NOT a card type/subtype.
### 3.2 Club-item path (the only place wire subtypes live) — `fut_clubitems.py`
Club items are served on the **`/club?type=` route** (`utas_server.py:2250`,
`handle_club`), gated by `FUT_CLUBITEMS`, NOT by the store route. Current `FAMILIES`
(`fut_clubitems.py:61-67`), format `(family, table, art id, stat id, stat name,
UNVERIFIED cardsubtypeid)`:
| wire subtype | mapped family | table | art id | source | confidence |
|---|---|---|---|---|---|
| 9 | kits | fcc_kitcards.json | 35 | `fut_clubitems.py:65` | HYPOTHESIS (marked "UNVERIFIED", `:49`,`:30-32`) |
| 10 | stadia | fcc_stadium.json | 36 | `fut_clubitems.py:63` | HYPOTHESIS ("UNVERIFIED") |
| 11 | badges | fcc_badgecards.json| 39 | `fut_clubitems.py:64` | HYPOTHESIS ("UNVERIFIED") |
| 30 | balls | fcc_balls.json | 37 | `fut_clubitems.py:62` | HYPOTHESIS ("UNVERIFIED") |
| 31 | leaguelogos | fcc_leaguelogos.json| 40| `fut_clubitems.py:66` | HYPOTHESIS ("UNVERIFIED") |
- The prior recorded mapping (9=kits,10=stadia,11=badges,30=balls,31=logos) is
**confirmed present in current code** — but the code itself marks every one
"UNVERIFIED cardsubtypeid" and states the binary assigns family↔subtype **nowhere**
in the 149 dumped tables; cardtype-9 admits the set `{30,31,145,146,147,148,149,150}`
(`fut_clubitems.py:26-28`, `:73`). So these are server-chosen HYPOTHESIS values.
- In the club-item wire item (`_item:88-119`), `cardsubtypeid` (`:97`) is a
**server-assigned wire-category constant** (9/10/11/30/31), NOT the raw FCC
subtype: the club-item fcc tables carry **no `cardsubtype` column at all** (Task 1:
badges/stadium/kit/logos/balls have empty subtype sets). `resourceId`/`assetId`
= `carddbid`, and `cardassetid` = the family ART id (`:94-96`). So for club items:
**`cardsubtypeid` = wire category (server constant), `carddbid`/`cardassetid` =
real fcc columns.**
- By contrast, consumables (`fut_store._item` / `fut_consumables`) DO carry the raw
FCC subtype (51..341) as `cardsubtypeid`.
### 3.3 Task-1 families vs wire-subtype coverage
Families that the **store handler** can map to a wire subtype: **none** — the store
handler emits packs, which have no card subtype (by design).
Families for which a **club-item** wire subtype exists (HYPOTHESIS-grade):
kits(9), stadia(10), badges(11), balls(30), leaguelogos(31).
Task-1 card families with **no wire subtype mapping anywhere in the server**:
- **5001xxx contracts, 5002xxx fitness/healing, 5003xxx training** — served as
consumables carrying their raw FCC subtype; these are consumable overlays, not
store tiles, and not part of any store/club-item wire-category map.
- **5004xxx misc {231,232,233,236}** — **no wire subtype mapping found** in
`fut_clubitems.py` or the store path. (Grep: no `misc` family, no {231,232,233,236}
wire assignment.) They exist only as raw FCC subtypes in consumable data.
- **8010xxx league logos/stickers** — mapped in the **club-item** path as wire
subtype **31** (`fut_clubitems.py:66`), HYPOTHESIS-grade. `fcc_leaguelogostickers`
(39 rows) is NOT wired in `FAMILIES` (only `fcc_leaguelogos`, 44 rows).
- **6000xxx badges, 6200xxx stadiums, 6300/6400xxx kits, 8120xxx balls** — mapped in
the club-item path (11/10/9/30), HYPOTHESIS-grade.
- **staff (managers/coaches, subtypes 4-8)** — served by `fut_staff` on `/club?type=
manager`, not a store tile.
Note none of these belong to the **store-tile** (`purchasegroup`) response.
---
## 2C flag investigation — BLOCKED
### Store-tiles flags located (OBSERVED)
Two, both in `utas_server.py`, both module-level constants read **once at import**:
| flag | env var | line (read) | consumed | default | current running value |
|---|---|---|---|---|---|
| `STORE_DISPLAYGROUP` | `FUT_STORE_DISPLAYGROUP` | `:975` | `_pack_body:3337` | `"1"` → **ON** | **ON** (no env override) |
| `STORE_GROUPID` | `FUT_STORE_GROUPID` | `:980` | `_pack_body:3403` | `"0"` → **OFF** | **OFF** (no env override) |
- `:975` `STORE_DISPLAYGROUP = os.environ.get("FUT_STORE_DISPLAYGROUP", "1") == "1"`
- `:980` `STORE_GROUPID = os.environ.get("FUT_STORE_GROUPID", "0") == "1"`
**Current values (recorded before any change; nothing was changed):**
- `FUT_STORE_DISPLAYGROUP`: unset in container env → default `"1"` →
`STORE_DISPLAYGROUP = True` (**ON**). (INFERRED from OBSERVED env dump + OBSERVED
code default.)
- `FUT_STORE_GROUPID`: unset in container env → default `"0"` →
`STORE_GROUPID = False` (**OFF**). This is the flag "expected to be OFF".
The related club-item flag `FUT_CLUBITEMS` (`:1647-1648`) is likewise unset →
`CLUBITEMS = False` (club items not currently served), also a module-level import
constant.
### Dynamic evaluation? NO (OBSERVED)
- All three flags are top-level `os.environ.get(...)` assignments evaluated at
module import (`:975`, `:980`, `:1647`); `_pack_body` reads the resulting module
**constants** (`:3337`, `:3403`), never `os.environ` at request time.
- Repo-wide there is **no** `importlib.reload`, no `signal`/`SIGHUP` handler, and no
per-request environ re-read for these flags. (The only runtime-refreshable feature
is `FUT_ID_SWEEP`, which re-reads a *file* `SWEEP_FILE`, `:1965-1966` — unrelated.)
- `:3250` documents the intended workflow explicitly:
`# Enable for the test with: FUT_PRICE_PROBE=1 ./openfut-fut.sh restart`.
### Restart conflict → STOP
Changing either store flag requires either setting a container env var (→
`docker` recreate = restart) or editing the module (→ re-import = restart). Both
violate the no-restart / no-redeploy / no-recreate constraint. Therefore:
```
TASK 2 BLOCKED AT 2C:
Flag requires restart, conflicting with no-restart constraint.
```
No flag was enabled. 2D/2E (manual client capture + definition analysis) NOT
started. No client request generated, replayed, or simulated.
---
## 4. Captured request and response (Phase 3) — OBSERVED
Real client action (operator opened the FUT Store on `.105`, 2026-08-12). Only one
`/store/purchasegroup` request occurred after the capture marker
`2026-08-12T23:54:01Z`, so attribution is unambiguous (only the operator drives the
client). Log via `docker logs --since 2026-08-12T23:54:01Z --timestamps openfut-fut-backend`.
- **Request:** `23:54:43 GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true`
(Host `10.10.0.120:8099`, `User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)`,
`X-UT-SID` present). Preceded at 23:54:43 by `GET /ut/game/fifa17/user/credits`
→ `200 {"credits": 29876776, ...}`.
- **Response:** `200`. The server log truncates the body to 200 bytes
(`utas_server.py:3754`, `raw[:200]`), genuine prefix:
`{"purchase": [{"assetId": 1, "id": 1, "packType": "BRONZE", "description": "Bronze Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount`
- **Full body recovered** by running the exact running-container code
(`docker exec openfut-fut-backend python3 -c "import utas_server as u; u.store_catalog(None)"`)
over the live `/state` profile, under the live flags (confirmed in-process:
`STORE_DISPLAYGROUP=True`, `STORE_GROUPID=False`). Its `json.dumps(...)[:200]`
equals the genuine logged 200-byte prefix **byte-for-byte** (verified MATCH), so the
reconstruction IS the sent body (deterministic pure function + verified prefix). No
request was synthesized, replayed, or curl'd. Full body (2841 bytes) preserved
verbatim at `docs/evidence/store_purchasegroup_capture_2026-08-12.json`.
- **Operator-reported client behavior:** on opening the store, an error dialog
appeared — *"The pack you've selected is currently not available. Please select a
different pack or try again later."* — and clicking OK returned to the FUT hub. No
tiles were browsable; **no "unknown" tiles were reported**. There was **no**
`PUT /store/transaction` (no buy) and **no server error** (server answered `200`).
## 5. Definition analysis (Phase 4/5) — OBSERVED
`purchase[]` = 5 entries (`timestamp` 1596326400). No `cardsubtypeid`/`carddbid`/
`cardassetid` in any entry (packs, not cards).
| idx | id | assetId | packType | description | displayGroup.value | priority | state | dgAssetId | classification |
|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 1 | BRONZE | Bronze Pack | `bronze` | — | active | absent | KNOWN TOKEN |
| 1 | 5 | 5 | GOLD | Gold Pack | `gold` | — | active | absent | KNOWN TOKEN |
| 2 | 6 | 6 | GOLD | Premium Gold | `gold` | — | active | absent | KNOWN TOKEN |
| 3 | 7 | 7 | GOLD | Special Players Pack | `special` | — | active | absent | KNOWN TOKEN |
| 4 | 65534 | 65534 | GOLD | "" (empty) | `mypacks` | 1 | **inactive** | absent | KNOWN TOKEN |
Per-pack fields (idx 0-3 identical shape): `saleType:"promo"`, `limitType:"NONE"`,
`quantity:0`, `purchaseLimit:0`, `purchaseCount:0`, `isPremium:false`,
`currencies:[{"name":"coins","funds":<price>,"finalFunds":<price>}]`,
`extPrice:{finalPrice/originalPrice:{amount:<price/100>,currency:"mtx"}}`,
`packContentInfo:{...tier quantities...}`, `unopened:false`. Prices: Bronze 400,
Gold 5000, Premium Gold 15000, Special Players 25000. The sentinel (idx 4) drops
`currencies`/`extPrice`, has empty description, `state:"inactive"`.
**Unique `displayGroup.value` set emitted: `{bronze, gold, special, mypacks}`.**
Compared to the six client renderer tokens `{mypacks, points, bronze, silver, gold,
special}` (`FUN_180014580`/`FUN_180014df0`, `plan-2026-08-05-store-subsystem.md:202-206`):
**every emitted token is a KNOWN token; the set outside the renderer categories is
EMPTY.**
## 6. Unmapped definitions / suspect tokens found — OBSERVED
None. Zero SUSPECT/UNKNOWN `displayGroup.value` tokens; zero card definitions;
zero `cardsubtypeid`/`carddbid`/`cardassetid`. The only anomalous element is the
**inactive, empty-description `mypacks` sentinel** (idx 4), emitted by
`store_catalog:3428-3446` **only when the profile owns zero unopened packs**
(OBSERVED: profile `unopenedPackIds == []`).
## 7. Client-side evidence (Phase 7) — existing RE only
No new Ghidra run. Existing decompiler evidence already bounds the answer and shows
new static analysis would be unproductive:
- **The parser is not the gate** (`OPENCODE_ENDPOINT_PROMPT.md:118-120`): per-pack
epilogue `0x18013badc` pushes every parsed pack unconditionally — no drop predicate
in the parse path. So a `200` with clean JSON cannot be rejected by the deserializer.
- **Store-level "not available"** (`FUT_CatalogNotAvailable`, msg `0x7550`) comes from
downstream client gates (`OPENCODE_ENDPOINT_PROMPT.md:120-131`): (1) resolution
`GetSystemMetrics` ≤1024×768, (2) store-data-model load status `0x180013cf0`,
(3) Blaze purchase-config flags `IS_STORE_ENABLED/IS_COIN_PURCHASABLE/...` (these
are already served, `blaze_responder_v3b.py:708-719`).
- **Per-pack tile-availability predicate is in the PACKED FIFA17.exe and UNREAD**
(`plan-2026-08-05-pack-opening.md:553`): fields `state/saleType/quantity/
purchaseLimit/purchaseCount/start/end` are parsed and copied to the tile, but the
predicate that greys/blocks a tile "is in the packed exe and unread." Whether
`purchaseLimit`+`purchaseCount` greys a tile is explicitly an OPEN question
(`:644-645`). Static Ghidra on the packed exe cannot read it (decrypts only in live
memory); resolving it requires a live-memory experiment on the running FIFA process,
which is out of scope (must not touch FIFA).
- The exact operator string *"The pack you've selected is currently not available"*
is **not present** anywhere in the recon corpus (docs/tools); the documented
store/pack error strings are `FUT_CatalogNotAvailable` and
`CARDS_CB_ERR_PACK_NOT_IN_DIME` (a server-returnable code). UNKNOWN loc key.
## 8. Assessment (Phase 8) — runtime verdict
- **H1 (subtype/definition): CONTRADICTED.** The captured response contains no card
definitions and no `cardsubtypeid`/`carddbid`/`cardassetid` (OBSERVED §4-§5).
- **H2 (unknown `displayGroup.value` token): CONTRADICTED.** Every emitted token is a
KNOWN renderer category (`bronze/gold/special/mypacks`); the unsupported-token set
is EMPTY (OBSERVED §5). The store-tile "unknown" mechanism is NOT reproduced under
the current config (`STORE_DISPLAYGROUP=ON`).
Answering the Phase-8 questions:
1. **Unsupported `displayGroup.value` in the response?** No — all four tokens
(`bronze/gold/special/mypacks`) are recognized. (OBSERVED)
2. **Which pack got it?** None. (OBSERVED)
3. **Correspond to an unknown tile in FIFA?** No unknown tile was reported; the
observed symptom was a *"pack not available"* dialog, not an unknown tile. (OBSERVED)
4. **Where does the backend assign the token?** `_pack_body:3373-3379` maps each pack
to `special/gold/silver/bronze` from `specialChance`/`gold`; owned/sentinel →
`mypacks` (`:3336`). All canonical. (OBSERVED)
5. **Is `displayGroup.value` sufficient to explain the bug?** No. The response is
clean; the failure is a downstream client/packed-exe gate, not a token. (INFERRED)
6. **Is the server emitting a value FIFA demonstrably cannot understand?** No.
(OBSERVED)
7. **Narrowest likely fix (REPORT ONLY — not implemented):** The single anomalous,
server-controllable element is the **inactive empty `mypacks` sentinel** emitted
when `unopenedPackIds == []` (`store_catalog:3428-3446`). Leading HYPOTHESIS: with
no owned packs, the store's My-Packs group contains only this inactive pack, and
the client's (packed-exe) selection/availability path lands on it →
*"the pack you've selected is currently not available"* → back to hub. Narrowest
candidate fixes to TEST (each needs a controlled change, hence a future
restart-gated experiment — do NOT implement now):
(a) suppress the sentinel when there are no owned packs and instead let the store
land on a real active category (bronze/gold/special); or
(b) if My-Packs must resolve, make the sentinel non-selectable rather than an
`inactive` pack in the group.
Cheaper-to-eliminate CLIENT-side cause to check first (existing RE, no server
change): FIFA display resolution must be **>1024×768** on `.105`
(`OPENCODE_ENDPOINT_PROMPT.md:122-124`).
**Overall runtime verdict: CONTRADICTED** — neither H1 nor H2 reproduces; the
"unknown store tile" hypothesis is not the live failure. The live failure is a
distinct *pack-availability* error whose trigger is in the packed FIFA17.exe and
cannot be pinned from the (clean) server response alone.
## 9. Open questions
1. What exactly raises *"The pack you've selected is currently not available"*? The
loc key is unknown and the predicate is in the packed exe (unread). Resolving it
needs a controlled field/flag experiment or live-memory RE (both currently gated).
2. Does the store, with `unopenedPackIds == []`, land on / auto-select the inactive
`mypacks` sentinel? (HYPOTHESIS §8.7; unproven without client-side observation.)
3. Did the store render tiles successfully in earlier sessions when the profile
owned unopened packs (e.g. the 21:54-21:57 pack-opening burst)? If so, the
presence/absence of owned packs (sentinel) is implicated. (UNKNOWN — earlier logs
truncate the body; not proven.)
4. Does `purchaseLimit:0`/`purchaseCount:0` grey a tile? Existing RE lists this as an
OPEN question; would need a controlled experiment. (UNKNOWN)
5. Is bug 6c ("unknown tile") a stale symptom from before `STORE_DISPLAYGROUP` became
the default `ON`? Under the current config no unknown tile reproduces.
---
## H3 — EMPTY MY-PACKS SENTINEL (HYPOTHESIS)
When the profile owns zero unopened packs (`unopenedPackIds == []`), OpenFUT emits
synthetic **inactive** pack id **65534** in the `mypacks` display group
(`store_catalog:3428-3446`). The FIFA 17 store may treat this object as a selectable
pack whose availability predicate fails, producing *"The pack you've selected is
currently not available"* and returning the user to the FUT Hub before any
`/store/transaction`. **Status: HYPOTHESIS (untested).**
## 10. Resolution check (Phase 1) — OBSERVED
Read-only inspection of `.105` (FIFA pid 529227, not touched):
- Desktop/monitor: **2560x1440** — DRM connectors `card1-DP-2` and `card1-HDMI-A-1`
both `connected`, native mode 2560x1440; compositor KDE `kwin_wayland` (no gamescope).
- FIFA render config: `…/Games/umu/fifa17/pfx/drive_c/users/steamuser/Documents/FIFA 17/settings/overrideAutodetect.lua`
→ `ResolutionWidth = 1280`, `ResolutionHeight = 720`, `FullscreenEnabled = 0` (windowed).
- Session: Wayland (`WAYLAND_DISPLAY=wayland-0`), FIFA via XWayland (`DISPLAY=:0`,
`XAUTHORITY=/run/pressure-vessel/Xauthority` inside the game namespace).
**Is FIFA rendering above 1024x768? YES (1280x720).**
**Resolution hypothesis eliminated for this reproduction.**
## 11. Sentinel 65534 provenance (Phase 3)
1. **Basis:** **OpenFUT INVENTION** (OBSERVED). `65534` (0xFFFE) appears nowhere in
any EA capture or recon note — repo-wide it exists only in `utas_server.py`
(`store_catalog:3435-3446`) and this evidence set. The author's comment
(`:3428-3434`) states it is a workaround: "Retain an inactive zero-item sentinel so
the [`mypacks`] destination resolves… Its id is deliberately absent from
PACK_CATALOG." It is a compatibility guess, not captured behavior.
2. **Known-good EA capture of EMPTY My Packs:** **UNKNOWN** — none found. All recon
My-Packs analysis is client-side RE (`FUN_1800150d0` filters
`displayGroup.value=="mypacks"`, `plan-2026-08-05-pack-opening.md:34-36,893-895`);
no EA server response for an empty My Packs state is on record.
3. **Known-good response with ≥1 unopened pack:** **UNKNOWN** for EA. OpenFUT's own
seed grants reward pack id 70 (`_new_profile` `unopenedPackIds:[70]`,
`fut_store.py:360`), but that is an OpenFUT synthetic grant, not an EA capture.
4. **Evidence FIFA EXPECTS a sentinel/placeholder:** **NO / UNKNOWN.** Recon shows My
Packs is a client-side filter over the ordinary catalogue; the "empty-category
dialog over the wrong tab" concern behind the sentinel is the author's HYPOTHESIS,
not decompiler-confirmed. No evidence FIFA requires a placeholder object.
5. **Evidence for the `inactive` representation:** **UNKNOWN / HYPOTHESIS.** The claim
"state != active keeps it out of the visible row list" (`:3432`) is an unverified
author assumption; no RE shows `state:"inactive"` hides a pack from selection. If
FIFA does NOT hide it, the sole `mypacks` entry is a selectable inactive pack —
exactly the H3 failure mode.
## 12. Empty vs non-empty My Packs behavior (Phase 2) — OBSERVED (code) / captured
`store_catalog(h)` (`utas_server.py:3421-3447`):
- Always emits the 4 non-`ownedOnly` catalogue packs (ids 1,5,6,7) via `_pack_body`.
- For each id in `visible_unopened_packs()` (= `STORE.unopened_packs()` +
`_OPENED_PACK_GRACE`) that resolves in `PACK_CATALOG`, appends `_pack_body(owned,
idx, owned=True)`.
- **Only when `unopened_packs()` is empty (`if not owned_ids`)** appends the inactive
sentinel (`:3428-3446`).
Sentinel 65534 vs a normal active pack (Bronze, idx 0), field-by-field (from the
captured body):
| field | sentinel 65534 | Bronze Pack (active) |
|---|---|---|
| id | 65534 | 1 |
| assetId | 65534 | 1 |
| packType | GOLD | BRONZE |
| description | "" (empty) | "Bronze Pack" |
| state | **inactive** | active |
| saleType | promo | promo |
| limitType | NONE | NONE |
| quantity | 0 | 0 |
| purchaseLimit | 0 | 0 |
| purchaseCount | 0 | 0 |
| isPremium | false | false |
| sortPriority | 1 | 1 |
| currencies | **ABSENT** (popped) | `[{coins,400,400}]` |
| extPrice | **ABSENT** (popped) | `{mtx 4/4}` |
| packContentInfo | all-zero quantities | bronze 5 / item 5 |
| unopened | false | false |
| displayGroup.value | **mypacks** | bronze |
| displayGroup.priority | 1 | ABSENT |
| displayGroupAssetId | ABSENT | ABSENT |
**What changes when `unopenedPackIds` is non-empty (e.g. `[70]`):** the sentinel is
NOT emitted; instead pack 70 (Reward Special Players Pack, `ownedOnly`) appears via
the owned branch of `_pack_body` (`:3335-3336`): `displayGroup={"value":"mypacks",
"priority":idx}`, `state:"active"` (default), `unopened:true`, `currencies`/`extPrice`
popped. i.e. the `mypacks` group would hold a genuine **active** owned pack instead of
the inactive sentinel.
## 13. Proposed controlled experiments (Phase 5) — DESIGN ONLY, NOT EXECUTED
### Existing grant mechanism (Phase 4)
- **Supported profile-only method: YES** — `Store.grant_unopened_pack(pack_id)`
(`fut_store.py:635-643`): validates the id is in `PACK_CATALOG`, appends to
`unopenedPackIds`, persists; reverts via `consume_unopened_pack` (`:623-633`).
Modifies **only** profile state; cleanly reversible.
- **BUT restart IS required to take effect.** `Store.load()` caches `self._p`
(`:370-372`); **no route calls `grant_unopened_pack` or `select_account`**, and
`select_account` only re-reads on a persona *change*. So an out-of-process grant or
a raw profile-file edit writes disk but the **running server keeps serving its
cached `unopenedPackIds`** until the process reloads. There is no SIGHUP/reload
endpoint. Therefore any profile change needs a container restart to be observed.
### Experiment A — Non-empty My Packs (PREFERRED; least invasive)
- **State change:** set the profile's `unopenedPackIds` to `[70]` (edit
`…/state/accounts/33068179/fifa17_profile.json`, or call
`STORE.grant_unopened_pack(70)`), **store code/config unchanged**.
- **Restart required?** **YES** — profile cache (above). Profile-only; no code edit.
- **Rollback:** set `unopenedPackIds` back to `[]` (or `consume_unopened_pack(70)`),
restart. (Also restore `nextItemId`/coins only if a pack is actually opened — the
grant alone touches only `unopenedPackIds`.)
- **Expected `purchasegroup` difference:** sentinel 65534 GONE; instead one active
pack id 70 in the `mypacks` group (`state:active`, `unopened:true`); hub/credits
report `recoveredPacks:1`.
- **Expected client observation:** if H3 is correct, the immediate *"pack not
available"* dialog should NOT fire (or behavior changes) and My Packs should show a
real pack. If the dialog still fires identically, H3 is weakened and the cause is
elsewhere (packed-exe predicate / another field).
### Experiment B — Suppress the empty sentinel (only if A is inconclusive)
- **Change:** in `store_catalog` (`:3428-3446`), when `unopened_packs()` is empty, do
NOT append pack 65534 (emit no `mypacks` entry). **Code change ⇒ restart. NOT
authorized.** Narrowest patch: guard/remove the `if not owned_ids:` sentinel block.
- **Purpose:** distinguishes "the inactive sentinel is selected and fails" (A already
tests the inverse) from "an absent `mypacks` group causes a different failure"
(the original author's stated fear at `:3429-3431`).
### Experiment C — Alternate sentinel representation (design only)
- If evidence later shows FIFA expects an empty `mypacks` group represented
differently (e.g. present-but-not-a-pack, or `state` other than `inactive`), adjust
the sentinel shape. **DESIGN ONLY; DO NOT IMPLEMENT.** No current evidence specifies
the correct empty-group representation (see §11.4-11.5).
Note: both A and B require a restart (A for the profile cache, B for the code). A is
strictly less invasive (profile-only, clean rollback, no code change) and is the
preferred next experiment. Neither is authorized yet.
---
## 14. Experiment A — Non-empty My Packs (EXECUTED 2026-08-13) — OBSERVED
Authorized controlled test of H3: change ONLY the profile's `unopenedPackIds`
(`[] → [70]`), restart the FUT backend once, capture a genuine FIFA store request,
then roll back. No store code/config/flags/PACK_CATALOG/pack-70/sentinel-code
changed; FIFA not modified/restarted; operator drove the client.
### 14.1 Baseline profile state
- Path: `fifa17-recon/docker/state/accounts/33068179/fifa17_profile.json` (persona
33068179/CAGE; proven live: `STORE.path` in-process = `/state/accounts/33068179/
fifa17_profile.json`, coins 29876776 matching the live `/user/credits`).
- `unopenedPackIds == []`. Original SHA-256
`39bb3e833fa55287d8516815ba3a717b41c0f0c7a7c41d20503f3a55c65cc6e7`. Backup:
`/tmp/fifa17_profile.33068179.ORIG.20260813T001228Z.json` (same hash).
### 14.2 State change
- Narrow anchored edit of line 97070 only: ` "unopenedPackIds": [],` →
` "unopenedPackIds": [70],`. Diff vs backup = exactly one line; semantic diff =
only key `unopenedPackIds` (`[] → [70]`), all other 24 keys identical. Modified
SHA-256 `2b5760baa265f320904de2d23fd6ab374733efe74cb0756c3be39c083bce4ac8`.
(Used the direct edit rather than `grant_unopened_pack(70)` to avoid whole-file
reserialization; net semantic effect is identical.)
### 14.3 Restart
- `docker restart openfut-fut-backend` (Pid 1398009→1548312, StartedAt
2026-08-12T16:40:52Z → 2026-08-13T00:13:54Z). Bridge/Core and Rust hosts untouched.
This container bundles blaze/roster/utas/pow (per `entrypoint.sh`); all rebound.
- Post-restart in-process check: `STORE.load()['unopenedPackIds'] == [70]`;
`store_catalog(None)` → pack 70 present, sentinel 65534 absent.
### 14.4 Genuine FIFA capture
- Marker `2026-08-13T00:14:24Z`. Single request after it (unambiguous):
`00:14:58 GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true → 200`.
**No `/store/transaction`, no `/purchased/items`** in the window (pack 70 not opened).
- Full body recovered from the running code over the live [70] profile; its
`[:200]` matches the genuine logged 200-byte prefix byte-for-byte (verified MATCH).
Preserved at `docs/evidence/store_purchasegroup_capture_mypacks70_2026-08-12.json`.
### 14.5 Client-observed behavior (operator report)
1. Store remains open: **YES**.
2. "The pack you've selected is currently not available": **NO (gone)**.
3. My Packs category / unopened reward pack visible: **YES**.
4. Returned to FUT Hub: yes (normal navigation; not forced by an error dialog).
### 14.6 Response diff (baseline 2026-08-12 vs experiment)
Only difference across all 5 entries:
- **Removed:** id `65534` (`state:inactive`, `displayGroup:mypacks`, `description:""`).
- **Added:** id `70` (`state:active`, `displayGroup:mypacks`,
`description:"Reward Special Players Pack"`, `unopened:true`).
- Packs 1/5/6/7 byte-identical. Classification: **all EXPECTED FROM UNOPENED PACK
STATE; nothing UNEXPECTED.**
### 14.7 H3 assessment — **SUPPORTED**
65534 disappeared AND pack 70 replaced it as a real My Packs entry AND the
"pack not available" / store-exit behavior disappeared → per the pre-registered
criterion, **H3 is strongly SUPPORTED**. The failure is tied to the My Packs group
content when the profile owns zero unopened packs.
Sub-hypothesis resolution:
- **H3c (failure unrelated to My Packs): RULED OUT.** A My-Packs-only profile change
(no store code/config change) eliminated the failure.
- **H3a (the inactive sentinel object itself is the trigger) vs H3b (empty My Packs
state generally is the trigger): NOT DISTINGUISHED by Experiment A.** The change
simultaneously (i) removed the inactive sentinel and (ii) supplied a real active
owned pack. Either "presence of the inactive/empty sentinel" or "absence of any
real owned pack" could be the cause. Distinguishing them requires Experiment B
(empty `unopenedPackIds` AND suppress the sentinel so `mypacks` has no entry): if
that also fixes it → H3a (sentinel object was the problem); if it re-breaks or
changes → H3b (empty My Packs itself is the problem). Experiment B is a code change
(restart-gated) and remains unauthorized.
### 14.8 Rollback verification
- Profile restored from backup → SHA-256 `39bb3e83…` == original (byte-identical);
`unopenedPackIds == []`. Disk was unmutated during the test (still `2b5760ba…`
before rollback → store reads don't persist; pack 70 never opened).
- `docker restart openfut-fut-backend` (Pid 1549503, StartedAt 2026-08-13T00:16:56Z).
Post-restart in-process: `unopenedPackIds == []`, sentinel 65534 present again,
pack 70 absent → runtime baseline restored. Bridge/Core untouched.
**H3 status: SUPPORTED (H3c ruled out; H3a vs H3b open).** No permanent fix
implemented.
---
## 15. Experiment B — Empty My Packs Without Sentinel (EXECUTED 2026-08-13) — OBSERVED
### 15.1 Purpose
Distinguish **H3a** (the synthetic inactive sentinel 65534 itself is the trigger)
from **H3b** (FIFA cannot tolerate an empty My Packs state even without a sentinel).
Hold `unopenedPackIds == []` constant; change ONLY: sentinel 65534 emitted →
suppressed. Authorized TEMPORARY code change, reverted after test.
### 15.2 Baseline
Profile `unopenedPackIds == []` (SHA-256 `39bb3e83…`, unchanged throughout). Running
code before patch = `c89d43ea…` (host repo == container copy). Sentinel 65534 emitted.
### 15.3 Temporary patch — **TEMPORARY EXPERIMENT B PATCH, NOT A PERMANENT FIX**
Applied to the **container** copy `/app/tools/utas_server.py` only (the container
mounts `/state`, not `/app`; host repo `fifa17-recon/tools/utas_server.py` was NOT
edited — its git diff stayed empty). Single line, `store_catalog` (line 3428):
```
- if not owned_ids:
+ if False: # TEMP EXPERIMENT B PATCH -- suppress synthetic sentinel 65534 (NOT A PERMANENT FIX)
```
Semantic effect: when `unopened_packs()` is empty, append nothing (no sentinel, no
replacement object). Normal packs 1/5/6/7 (appended earlier) unchanged. Diff vs the
backed-up original = exactly this one line. Patched code SHA-256 `5bb8fca9…`.
### 15.4 Restart verification
`docker restart openfut-fut-backend` (Pid 1549503→1551026, StartedAt
2026-08-13T00:20:45Z). The writable-layer edit survived the restart; running
`/app/tools/utas_server.py` = `5bb8fca9…` (patched). In-process: `unopenedPackIds ==
[]`; `store_catalog` → 4 packs {1,5,6,7}, **no 65534, no 70, no `mypacks` entry**.
Flags unchanged (`DISPLAYGROUP=ON`, `GROUPID=OFF`). Bridge/Core/Rust untouched.
### 15.5 Genuine FIFA capture
Marker `2026-08-13T00:20:55Z`. Request sequence (operator opened the store):
`00:21:05 GET /hub` → `00:21:07 GET /user/credits` → `00:21:07 GET
/store/purchasegroup/all?ppInfo=true → 200`. **No `/store/transaction`; no further
requests** (client crashed after receiving the store body). Full body recovered from
the running patched code; `[:200]` matches the genuine logged prefix byte-for-byte
(verified MATCH). Preserved at
`docs/evidence/store_purchasegroup_capture_empty_no_sentinel_2026-08-12.json`
(4 packs {1,5,6,7}, no `mypacks` group).
### 15.6 Client behavior (operator report)
**The game CRASHED** on opening the store. Not the baseline dialog; a hard crash. No
`/store/transaction` was issued.
### 15.7 Three-way response comparison
| capture | ids present | `mypacks` group entry | client outcome |
|---|---|---|---|
| Baseline (`…_2026-08-12.json`) | 1,5,6,7,**65534** | 65534 `inactive`, desc "" | "pack not available" dialog → Hub |
| Exp A (`…_mypacks70_…json`) | 1,5,6,7,**70** | 70 `active`, "Reward Special Players Pack" | **works** — store open, My Packs visible |
| Exp B (`…_empty_no_sentinel_…json`) | 1,5,6,7 | **none** | **CRASH** |
Normal packs {1,5,6,7} identical across all three.
### 15.8 H3a / H3b verdict
- **H3a (sentinel object itself is the trigger): CONTRADICTED.** Removing the
sentinel did NOT restore the store; it produced a *worse* outcome (crash). If the
sentinel object were the sole cause, its removal would yield a working store (it
did not).
- **H3b (FIFA cannot tolerate an empty My Packs state): SUPPORTED.** Only Exp A — a
real **active** owned pack in `mypacks` — worked. Both the inactive sentinel
(graceful "pack not available" dialog) and the total absence of any `mypacks` entry
(crash) fail. The sentinel is a **load-bearing workaround** that *downgrades* the
failure from a crash to a dialog but does not fix it.
- **Pre-registered-rule nuance:** Exp B produced a *distinct* failure (crash), which
the pre-registered rules classify as **B3 (different failure)** rather than the
exact B2 dialog. Documented as such: the crash is a THIRD failure mode. It still
resolves the question — it rules out H3a and supports H3b — but the specific
outcome (crash, not the same dialog) is stronger than B2 anticipated. Not forced
into a clean binary beyond what the evidence shows.
**Does FIFA tolerate an empty My Packs without the sentinel? NO — it crashes.**
### 15.9 Rollback verification
- Container `/app/tools/utas_server.py` restored from backup → SHA-256 `c89d43ea…`
== pre-experiment (byte-identical); the `if False:` patch fully removed.
- `docker restart openfut-fut-backend` (final Pid 1551901,
StartedAt 2026-08-13T00:22:04Z). In-process: `unopenedPackIds == []`, sentinel
65534 emitted again, pack 70 absent; `DISPLAYGROUP=ON`, `GROUPID=OFF`.
- Host repo `fifa17-recon/tools/utas_server.py` never edited (git diff empty, SHA-256
`c89d43ea…`). Profile unchanged (`39bb3e83…`). Bridge/Core/Rust untouched.
### 15.10 Likely permanent fix (REPORT ONLY — not implemented)
Evidence: the store's `mypacks` group must contain a **valid, active, openable owned
pack**; both an inactive sentinel and an absent group fail (dialog / crash). The only
working configuration observed is a genuine active owned pack (Exp A). Candidate
directions (report only, each needs design + authorization):
1. Ensure the profile always owns ≥1 legitimate active unopened pack while the store
is shown (e.g. keep a real reward pack such as id 70 granted), so `mypacks` is
never empty — this matches the only known-working state but changes economy state
and needs a lifecycle policy (what happens after the user opens it).
2. Change what `store_catalog` advertises so FIFA never lands on / requires a
`mypacks` group when there are zero owned packs (client-compatible empty-store
representation) — the correct representation is UNKNOWN; neither current option
(inactive sentinel / no group) is it, so this needs new client-side RE before
implementation.
Recommendation: do NOT simply delete the sentinel (Exp B proves that crashes). No fix
implemented.
**H3 status: SUPPORTED. H3a CONTRADICTED, H3b SUPPORTED (Exp B crash = third failure
mode; empty My Packs is the root problem). Sentinel is a load-bearing workaround.**
---
## 16. Experiment C′ — Active Non-Openable Placeholder (EXECUTED 2026-08-13) — OBSERVED
Question: can the required `mypacks` group be kept structurally valid with an
**active** placeholder that stays impossible to open/purchase? Change exactly one
field of sentinel 65534: `state "inactive" → "active"`. Profile untouched
(`unopenedPackIds==[]`); 65534 kept absent from `PACK_CATALOG`.
### 16.1 Server-side safety proof (OBSERVED, code)
65534 cannot grant value regardless of `state` — pack resolution is by
`pack_by_id(id)` over `PACK_CATALOG` (ids 1,5,6,7,70), independent of the display
`state`:
- `store_buy` (PUT `/store/transaction`, `:3460-3465`): `pack_by_id(65534)=None` →
`if not pack: return 200, {}` (no `open_pack`, no coin change).
- `purchased_items` (POST, `:3494-3496`): `pack_by_id(65534)=None` →
`return 200, {"itemData": STORE.last_pack()}` (stale prior items only; no new
grant, no `open_pack`, no `consume_unopened_pack`).
- `open_pack`/`consume_unopened_pack` are unreachable for 65534 (pack resolves to
None first). Precondition PASSED.
### 16.2 Baseline / patch
Baseline: profile `39bb3e83…`, code `c89d43ea…` (host==container), sentinel
`inactive`/`mypacks`, 65534∉catalog, flags `DISPLAYGROUP=ON`/`GROUPID=OFF`.
Temporary container-only patch (host repo untouched), line 3444:
`empty["state"] = "inactive"` → `empty["state"] = "active"`. Diff vs original = this
one line; patched code `e1a4e1dc…`. **TEMPORARY EXPERIMENT C′ PATCH — NOT A PERMANENT
FIX.**
### 16.3 Restart / runtime
`docker restart openfut-fut-backend` (Pid 1556305, StartedAt 00:38:51Z). Running code
`e1a4e1dc…`; `unopenedPackIds==[]`; sentinel `65534 state=active unopened=False
dg=mypacks desc=""`; 65534∉catalog; normal packs 1/5/6/7 active; 70 absent; flags
unchanged.
### 16.4 Genuine FIFA capture
Marker `2026-08-13T00:38:53Z`. FIFA relaunched (Exp-B crash had closed it) → booted to
hub. Three genuine store fetches: `00:39:44`, `00:40:26`, `00:41:23`
(`GET /store/purchasegroup/all?ppInfo=true → 200`), reconstructed body prefix-matches
the logged 200-byte prefix (verified). Saved
`docs/evidence/store_purchasegroup_capture_active_placeholder_2026-08-12.json`.
C′-vs-baseline full JSON diff = **only** `65534.state: "inactive" → "active"`.
### 16.5 UI observation (operator report)
1. **No crash** (game launched to hub).
2. **No "pack not available" dialog.**
3. Store remains open.
4. My Packs tab **not shown while inside the Store (Browse Packs)**.
5. Via the FUT-hub **My Packs** menu: **one pack tile with no cover, "0 items, 0
bronze, 0 rares"** (the placeholder renders as a visible empty pack).
6. Navigation: from the hub **My Packs** menu → Bronze/Gold/Special reachable; but
from the **Browse Packs** (Store) entry, Bronze/Gold/Special are **not reachable
until My Packs is opened first**.
### 16.6 Passive request sequence (OBSERVED)
Boot: `.../accountinfo → /ut/auth → settings → phishing → match/reset → userMassInfo
→ PUT store/transaction/0 → hub …`. The single `/store/transaction` is the routine
**boot** call with body `{"state":"TRANSACTIONCANCEL"}` → `200 {}` (no packId), fired
at 00:39:39 **before** any store fetch. Across all three store opens: **no
`/store/transaction`, no `/purchased`, and no request referencing 65534.** The active
placeholder did NOT cause FIFA to auto-submit any transaction/open.
### 16.7 Availability result / verdict
**Result C1 (strong positive) — ACTIVE PLACEHOLDER HYPOTHESIS SUPPORTED, with UX
caveats.** `state` participates materially: with `state:"active"` the group exists
(no crash, as in baseline) AND the availability path is satisfied (no
"pack not available" dialog, unlike baseline). So **C2 is refuted** — `state` is a
deciding field for the dialog. But it is **not a clean permanent fix**:
- the placeholder renders as a **visible empty pack tile** ("0 items"), i.e. a fake
pack a user could try to open (server-safe: opening → no-op `{}` / stale
`last_pack`, but confusing UX);
- **navigation caveat #6**: from Browse Packs the other categories are gated behind
opening My Packs first — an UNEXPECTED behavior not present with a genuine owned
pack (Exp A).
### 16.8 Rollback verification
Container code restored from backup → `c89d43ea…` (== host, == pre-experiment); the
`state` change removed. `docker restart` (Pid 1557831, StartedAt 00:43:04Z).
In-process: `unopenedPackIds==[]`, sentinel `state=inactive`, 65534∉catalog, 70
absent, flags `DISPLAYGROUP=ON`/`GROUPID=OFF`. Host repo `utas_server.py` never edited
(`c89d43ea…`, git diff empty). Profile `39bb3e83…` unchanged. Bridge/Core untouched.
### 16.9 Implications for the client contract
`state:"active"` satisfies the pack-availability predicate (no dialog) while the
group's existence prevents the crash — so an active non-openable placeholder is the
first representation that neither crashes nor shows the dialog. However it exposes a
**visible empty "pack"** and a **Browse-Packs navigation gate** (#5/#6), so it is NOT
adopted. **Permanent fix NOT established.** Open follow-ups: (a) what happens if the
user explicitly selects/opens the active placeholder (a later controlled test —
server-safe per §16.1 but UX-unknown); (b) whether a count-gated My-Packs default or a
representation that avoids rendering a fake tile can remove the empty-tile/navigation
artifacts. Do NOT adopt `state:"active"` as the fix on this evidence alone.
---
## 17. Explicit Active-Placeholder Selection Test (EXECUTED 2026-08-13) — OBSERVED
**Purpose:** with the C′ active placeholder in place, characterize what happens when
the user *explicitly opens* the empty 65534 My-Packs tile (the last open backend-side
question).
**Server safety proof (re-confirmed, code `c89d43ea`):** `pack_by_id(65534)=None`;
65534∉PACK_CATALOG∉unopenedPackIds. `store_buy`→`200 {}`; `purchased_items`→
`200 {"itemData": last_pack}` (stale). No inventory/coin/profile mutation possible.
**Temporary C′ state:** container-only one-line patch `65534.state "inactive"→"active"`
(patched `e1a4e1dc…`), restart (Pid 1560774). `unopenedPackIds=[]`, 65534
active/mypacks/∉catalog, normal packs unchanged, flags ON/OFF, host code + profile
unchanged. Marker `2026-08-13T00:53:09Z`.
**Manual selection behavior (operator report):** opened FUT → My Packs → the empty
placeholder tile visible → selected/opened it ONCE:
1. Dialog: **YES**. 2. Exact text: **"This pack is no longer available"**.
3. Stays in My Packs: yes. 4. After closing the dialog → returns to My Packs.
5. Then navigates back to the FUT Hub successfully. 6. **No crash.** 7. No spinner.
8. **Navigation remains fully usable afterward.**
**Genuine request sequence (OBSERVED, marker `00:53:09Z`):** boot (`…/auth →
userMassInfo → PUT store/transaction/0 {"state":"TRANSACTIONCANCEL"}→200 {} → hub →
credits → purchasegroup`) then navigation (`hub→credits→purchasegroup` ×2 for the
store/My-Packs views). **The explicit tile selection generated NO server request** —
no `/store/transaction`, no `/purchased/items`, and NO reference to 65534 anywhere.
The "no longer available" verdict is rendered **client-side**.
**Result class: S1 — pure client-side rejection.**
**Post-test profile/economy integrity (OBSERVED):** coins 29876776, nextItemId
100004837, items 1995, purchased 0, `unopenedPackIds` `[]`, `last_pack` empty — ALL
unchanged vs pre-test; 65534 not persisted in items or unopenedPackIds; profile
SHA-256 `39bb3e83…` byte-identical. **Zero mutation.**
**UX assessment:** crash-safe ✓, economy-safe ✓ (no request even sent), navigation
recoverable ✓. Blemishes: a **visible empty "0 items" tile**, a **"This pack is no
longer available" dialog on explicit click**, and (from §16.5) the **Browse-Packs
navigation gate** (must open My Packs first). Notably this is a *strict improvement*
over the inactive-sentinel baseline, which throws "pack not available" immediately on
STORE OPEN and bounces to the Hub; the active placeholder only errors if the user
deliberately clicks the empty tile, and recovers cleanly.
**Active-placeholder verdict: MARGINALLY ACCEPTABLE.** Safe (crash + economy) and
usable, but visibly imperfect (fake tile + click-dialog + browse nav gate). Not
UNACCEPTABLE (no crash/economy risk, recoverable); not fully ACCEPTABLE (user-visible
defects).
**Permanent-fix decision: P2.** The active sentinel technically works and is safe, but
its UX is poor and — per Candidate F (CONTRADICTED) — **no backend-only *clean*
solution exists** (the store's My-Packs resolution is Scaleform/movie-driven, not
server-gated). Recommendation: keep the active placeholder as an optional/temporary
backend compatibility mode (strictly better than the current inactive-sentinel
baseline) and pursue a **client-side** fix for a fully clean zero-pack experience
(hiding the fake tile / suppressing the forced My-Packs resolution). NOT implemented.
**Rollback verification:** container code restored to `c89d43ea…` (== host, ==
pre-experiment), sentinel back to `inactive`; `docker restart` (Pid 1562665, StartedAt
00:59:04Z); `unopenedPackIds=[]`, 65534 inactive/∉catalog, 70 absent, flags ON/OFF;
host `utas_server.py` never edited; profile `39bb3e83…` unchanged. Bridge/Core
untouched.
docs/evidence/fifa17-recon/table-hashes.sha256
-44
View File
@@ -1,44 +0,0 @@
# FIFA 17 card-table provenance manifest
# Source (authoritative): 10.10.0.105:/home/alex/Documents/OpenFUT/fifa17-recon/data/tables/
# Dest (this repo): fifa17-recon/data/tables/
# Verified 2026-08-12: source and dest byte-identical (sha256), order-independent.
# Combined hash-of-hashes: 10f239add919089354d8dbff873fc9737b0a0f80f6ac41b1aa2a096c0ec8d331
# 31 fcc_*.json + 5 staff tables = 36 files. Files are DECODED tables:
# each carries {table, source, rowcount, schema[], rows[]}; card instances live in rows[].
#
0d1c9af7ae654c3e4363f18bb89bad03a0631056d36425c84b9a680fa989618c fcc_managerbonusvalues.json
0e5d5309cd1d9322476f8047fc6eaf4a88f4f19211b8ea01fe4d28ddd3733134 fcc_healingcards.json
1da80e390169ebb8ee8a6543e14b1191d9151f675797f01e23628f6c24d434c5 fcc_misccards.json
2212b0ee8d962f0fb6bd346bee35fff6566e22539e397cc2e42bb6efd4dc3ad3 fcc_textposvalues_hd.json
2a8e22ddb000b2c08f1a3e5eb47bc56ecf43f733ce6e7519498d332e4f439746 headcoachcards.json
3a323e1c0688a4068ccd21be0c9d8e88a875ab10ce2158d3aed79fc14e65f0fb fcc_chemlinkcalc.json
4a60bc4c0d8cb8d2b903e152a3dd5302348753568630818fde059b2de41f82ab fcc_leaguelogos.json
5304114078200da4564d33612c955598f12a44bdf52f18274184b98922229b8b fcc_GrandStandPlayers.json
5503291e381fee5008120615cd6d30a732b97636d4694a88f943eb14cb992741 fcc_leaguelogostickers.json
550739c124ca915fb294954afe3d9d04fb7d1faf2b0c96930b2dcdb1bfe7ac8f fcc_formationcardspositions_kc.json
5a5aabec1d40ffa21b8effb84f79e4b788cb42352aa592d71d95eba1db0d209e fcc_trainingcards.json
6476e396f166905857d2ada4f12cc37645ca42efdca121e8e74270fbf7422336 managercards.json
6546f602024973e20d04522a857c6c243473a177cab5b3be8400390651a42fab fcc_navcoords_hd.json
6b0209647383e4e940d2af2c3bbb2185a4aac7ac0e799fe6b50ae52e7625710d fcc_contractcards.json
6c52c83aafd9d9d3406e21c656762ac5cc0ba4522002f424e5593430bc5190f5 physiocards.json
765687d7f1e5c6c989adf45b174a0fdab0f65597c83132304b53b9f859c02586 fcc_stadium.json
79e50b07eecc47a0edf4d2a87782e904785e653937698cc712258a82fdf8b079 fcc_formationcardspositions_hd.json
7d36e0fbb9349eabd4267215bacbe29d78ff621deeb8cab3380dcac72c535eb9 fcc_preferredformationcalcmid.json
8122a4070901662fac97f675a3e4194dd5fd7e02194fdab204989af42676e268 fitnesscoachcards.json
828f8b90241672b9f62a9bbd3cb219a1d3bd8856bd160cc46284f2958e08f7d4 fcc_discardcoins.json
852bb82ed373881373d8610e6f4f2ca4406bac13da4bda9d6abba693d7cafc56 fcc_myclubscategories.json
974dcbbe6a46c02dc97c77df6c270c9a7f09ba23bee23005ecf95fd114ee66a7 gkcoachcards.json
9aa4b3b3f226202b21d2e9f96a1508ecce56abba64372099e090df101fce5eeb fcc_nationcalc.json
9b6797991520c05f7448b28e66d160f96afc73eefd661ed8272b0a093b6ba89f fcc_kitcards.json
9e8e6595fa8d3bcf963eb25bd9f9ea5d131aa92ed0e7e4ae3089adf5e1d55927 fcc_preferredformationcalcst.json
a4e8ac2ba0a6db45f1f59fe384fbd39a8cee8fb72a72f846e52daca44f1c7ff9 fcc_myclubs.json
bbf405e3a63b6fd03da1237b8b118764c57a40c797faf85d1e4691a1c95a840e fcc_balls.json
ca1184bd85cff3308af0104077feda4357ef483fae6335fa964922eea4e94330 fcc_navcoords_kc.json
ca3e4ab0f7892aac7473b774de4699c067c54647ca4a82cdd5fd1108c56ed894 fcc_badgecards.json
ccdda8ad0a15f73a056fa336abde8739b346d12b78cb8adbea0f0677487bb598 fcc_preferredpositioncalc.json
dbf95bddd456137e4b90a44bdd1f637458f4846ecd5c3ba6747d3f069c3f590f fcc_textposvalues_kc.json
dd8c2c860b18d999877c37e0f63dac64ef7bb57bff5a2173960cde71242f9a34 fcc_bonusvalues.json
df5b997b153941a5bb760ad5bb0fb23dc16cf8612b300559be23ac929b55eec6 fcc_leagues.json
e4619db324a7848639a8ba53f513cf3ea153eeaf698de05d71e56c319b3cc424 fcc_coinrewards.json
e6b1ca3ecb7c3923d77e73bda2e6c3f9794b9158354d566112f7979b33b4422c fcc_preferredformationcalcgk.json
f54814d61b72dd2b6186e9e414df4fbfbdbea1732da6a4622f001a1ff03bc12a fcc_preferredformationcalcback.json
docs/evidence/live-captures-2026-08-15/README.md
-66
View File
@@ -1,66 +0,0 @@
# Live UTAS wire captures — 2026-08-15
Fresh sanitised FIFA 17 UTAS wire, captured during the post-P1 staging A/B on a
**real FIFA 17 client** (`10.10.0.105`) driving the isolated post-P1 candidate
backend (`10.10.0.121`, host bin `fda40d12`, Core `fbb54ea`). Production untouched.
This rebuilds the primary-capture corpus that was lost to `.gitignore` (Known Issues
#200 / "take sanitised captures on the next live FIFA run and commit them").
## Files
- `utas-requests.sanitised.txt` — 10 real client requests (`---`-separated).
- `utas-responses.sanitised.txt` — 12 responses.
Captured with `tcpdump` on the container netns (UTAS is plain HTTP on `:8099`),
reassembled + split + **sanitised** by `openfut-staging/extract_http.py`. Redacted:
`X-UT-SID`/`sid` (`<SID>`), `authCode` (`<AUTH>`), `deviceId` (`<DEV>`), `macAddress`
(`<MAC>`), and any 32+char hex token (`<TOKEN>`). The raw `.pcap` is intentionally
NOT committed (it is unsanitised).
## Route contracts captured (verbatim shapes)
### POST /openfut/account/sync (launcher control-plane, Python-served)
Request (launcher → backend):
```json
{"personaId":33068179,"personaName":"CAGE","level":1,"experience":0,
"experienceMax":1000,"accountFunds":0,"accountFundsCap":100000}
```
Response:
```json
{"account":{"personaId":33068179,"personaName":"CAGE","clubName":"OpenFUT",
"clubAbbr":"OFC","level":1,"experience":0,"experienceMax":1000,"accountFunds":0,
"accountFundsCap":100000,"profilePath":"accounts/33068179/fifa17_profile.json",
"coins":29826776,"unopenedPacks":0},"status":"OK"}
```
NOTE: `coins` here is Python's STALE profile value (29,826,776) — Core's authoritative
balance at capture time was 29,859,876. The launcher's `AccountSummary` parser is
lenient and requires only `{personaId,personaName,level,experience,accountFunds,coins,
unopenedPacks}` (clubName/clubAbbr/etc. ignored). BLOCKER for a Rust migration is NOT
the shape — it is that Python `account/sync` also *selects the active profile* the
still-Python-served userMassInfo envelope depends on, so it is coupled to the
userMassInfo hybrid and cannot migrate standalone.
### GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true (empty My-Packs sentinel)
The `mypacks` group carries the synthetic sentinel pack when My Packs is empty:
```json
{"assetId":65534,"displayGroup":{"priority":1,"value":"mypacks"},"id":65534,
"packType":"GOLD","packContentInfo":{"goldQuantity":0,"itemQuantity":0,...},
"state":"active","unopened":false}
```
Client renders empty My Packs AS Browse Packs (no crash) — the bug-6c resolver guard.
### GET /ut/game/fifa17/userMassInfo (RUST_OVERLAY hybrid, full 8 KB envelope captured)
The complete envelope is in `utas-responses.sanitised.txt`: root `pileSizeClientData` +
`userInfo` (with `clubName`, `clubAbbr`, `established`, `accountCreatedPlatformName`,
`currencies` [Core coins overlaid by Rust], `won/draw/loss`, `clubNameChangeAllowed`,
`divisionOffline/Online`, `purchased`, `feature`, `reliability`, `bidTokens`, `trophies`,
`sessionCoinsBankBalance`, `actives`, `squadList`). Field spec is authoritative in
`fifa17-recon/tools/utas_server.py::user_info()`. This is the target shape for a future
full-Rust userMassInfo (needs the `clubAbbr`/`established` account triad, which Core lacks).
### Other captured request lines
`POST /ut/auth`, `GET user/accountinfo`, `GET settings`, `GET phishing/trusteddevice`,
`PUT match/reset`, `GET userMassInfo`, `PUT clientdata/userHubData`,
`PUT /ut/v2/game/fifa17/store/transaction/0`.
See `openfut-staging/p1p-live-2026-08-15/AB_VERDICT.md` for the full A/B result.
docs/evidence/live-captures-2026-08-15/utas-requests.sanitised.txt
-117
View File
@@ -1,117 +0,0 @@
POST /openfut/account/sync HTTP/1.1
Host: 10.10.0.121:8099
Content-Type: application/json
Content-Length: 131
Connection: close
{"personaId":33068179,"personaName":"CAGE","level":1,"experience":0,"experienceMax":1000,"accountFunds":0,"accountFundsCap":100000}
---
GET /ut/game/fifa17/user/accountinfo HTTP/1.1
Host: 10.10.0.121:8099
Connection: Close
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
Accept-Encoding: gzip
Easw-Session-Data-Nucleus-Id: 33068179
Accept-Encoding: gzip
---
POST /ut/auth HTTP/1.1
Host: 10.10.0.121:8099
Content-Length: 380
Connection: Close
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
Hash: <TOKEN>
{"isReadOnly":false,"priorityLevel":6,"sku":"FFA17PCC","nucleusPersonaPlatform":"pc","clientVersion":3,"nuc":33068179,"nucleusPersonaId":33068179,"nucleusPersonaDisplayName":"CAGE","locale":"en-US","regionCode":"US","deviceId":"<DEV>","macAddress":"<MAC>","method":"authcode","identification":{"authCode":"<AUTH>"}}
---
GET /ut/game/fifa17/settings HTTP/1.1
Host: 10.10.0.121:8099
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
X-UT-SID: <SID>
Accept-Encoding: gzip
---
GET /ut/game/fifa17/phishing/trusteddevice?deviceId=<DEV> HTTP/1.1
Host: 10.10.0.121:8099
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
X-UT-SID: <SID>
Accept-Encoding: gzip
---
PUT /ut/game/fifa17/match/reset HTTP/1.1
Host: 10.10.0.121:8099
Content-Length: 0
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
X-UT-SID: <SID>
---
GET /ut/game/fifa17/userMassInfo HTTP/1.1
Host: 10.10.0.121:8099
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
X-UT-SID: <SID>
Accept-Encoding: gzip
---
PUT /ut/v2/game/fifa17/store/transaction/0 HTTP/1.1
Host: 10.10.0.121:8099
Content-Length: 29
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
X-UT-SID: <SID>
{"state":"TRANSACTIONCANCEL"}
---
PUT /ut/game/fifa17/clientdata/userHubData HTTP/1.1
Host: 10.10.0.121:8099
Content-Length: 53
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
X-UT-SID: <SID>
{"entries":[{"key":0,"value":0},{"key":1,"value":1}]}
---
GET /ut/game/fifa17/store/purchasegroup/all?ppInfo=true HTTP/1.1
Host: 10.10.0.121:8099
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Accept: application/json
Content-Type: application/json
X-UT-SID: <SID>
Accept-Encoding: gzip
docs/evidence/live-captures-2026-08-15/utas-responses.sanitised.txt
-101
View File
File diff suppressed because one or more lines are too long
docs/evidence/market-lifecycle-2026-08-17/_index.json
-38
View File
@@ -1,38 +0,0 @@
{
"_countdown_proof": {
"delta": -4,
"expires_after_4s": 2216,
"expires_first": 2220,
"frozen": false
},
"auctionhouse-browse": {
"container": "object",
"path": "/auctionhouse",
"status": 200
},
"marketdata-pricelimits": {
"container": "array",
"path": "/marketdata/pricelimits?defId=20801",
"status": 200
},
"trade-status-filtered": {
"container": "object",
"path": "/trade/status?tradeIds=1000000097",
"status": 200
},
"trade-status-unfiltered": {
"container": "object",
"path": "/trade/status",
"status": 200
},
"tradePile": {
"container": "object",
"path": "/tradePile",
"status": 200
},
"tradePile-counts": {
"container": "object",
"path": "/tradePile/counts",
"status": 200
}
}
docs/evidence/market-lifecycle-2026-08-17/auctionhouse-browse.json
-73
View File
@@ -1,73 +0,0 @@
{
"auctionInfo": [
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 2220,
"itemData": {
"assetId": 20801,
"attributeList": [
{
"index": 0,
"value": 92
},
{
"index": 1,
"value": 92
},
{
"index": 2,
"value": 81
},
{
"index": 3,
"value": 91
},
{
"index": 4,
"value": 33
},
{
"index": 5,
"value": 80
}
],
"cardassetid": 20801,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 20801,
"discardValue": 1500,
"fitness": 99,
"id": 100000097,
"itemState": "forSale",
"itemType": "player",
"leagueId": 53,
"nation": 38,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LW",
"rareflag": 1,
"rating": 94,
"resourceId": 20801,
"teamid": 243,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000097,
"tradeState": "active",
"watched": false
}
],
"count": 0,
"credits": 29843976,
"duplicateItemIdList": [],
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 1,
"sold": 0,
"total": 1
}
docs/evidence/market-lifecycle-2026-08-17/cardsdll-route-table.txt
-61
View File
@@ -1,61 +0,0 @@
image_base=0x180000000 sections=7
.text rva=0x00001000 vsize=0x1e3f62 rawptr=0x00000400 rawsize=0x1e4000
.rdata rva=0x001e5000 vsize=0xa4094 rawptr=0x001e4400 rawsize=0xa4200
.data rva=0x0028a000 vsize=0x65c08 rawptr=0x00288600 rawsize=0x54000
.pdata rva=0x002f0000 vsize=0x132cc rawptr=0x002dc600 rawsize=0x13400
.tls rva=0x00304000 vsize=0x9 rawptr=0x002efa00 rawsize=0x200
.rsrc rva=0x00305000 vsize=0x4e8 rawptr=0x002efc00 rawsize=0x600
.reloc rva=0x00306000 vsize=0x16bc4 rawptr=0x002f0200 rawsize=0x16c00
route table VA 0x18021df80 -> file offset 0x21d380
# field A field B
0 'ut/%s/auctionhouse' 'AUCTIONHOUSE'
1 'ut/%s/clubUser' 'CLUB_USER'
2 'ut/%s/user/list' 'CLUB_INFO'
3 'ut/%s/club' 'CLUB'
4 'ut/%s/defid' 'DREAM'
5 'ut/%s/squad' 'SQUAD'
6 'ut/delete/%s/squad' 'DELETE_SQUAD'
7 'ut/%s/leaderboards/options' 'LBOPTIONS'
8 'ut/%s/leaderboards' 'LBDEFAULT'
9 'ut/%s/activeMessage' 'PAFPRACTICE'
10 'ut/%s' 'UT'
11 'ut/%s/user' 'USER'
12 'ut/delete/%s/user' 'DELETEUSER'
13 'ut/%s/item' 'ITEMS'
14 'ut/%s/item/resource' 'ITEMS_BY_RES'
15 'ut/delete/%s/item' 'DELETEITEMS'
16 'ut/%s/match' 'MATCH'
17 'ut/%s/sbs' 'SBC'
18 'ut/%s/tournament' 'TOURNAMENT'
19 'ut/%s/tournament/user' 'TOURNAMENTUSER'
20 'ut/delete/%s/tournament/user' 'TOURNAMENTQUIT'
21 'ut/%s/season' 'SEASON'
22 'ut/%s/season/user' 'SEASONUSER'
23 'ut/%s/season/%%s/user' 'SEASONUSER_ALTER'
24 'ut/%s/season/%%s/reset' 'SEASONRESET'
25 'ut/%s/season/friendly' 'FRIENDLYSEASON'
26 'ut/%s/purchased' 'PURCHASED'
27 'ut/%s/store' 'STORE'
28 'ut/%s/watchList' 'WATCHLIST'
29 'ut/delete/%s/watchList' 'DELETEWATCHLIST'
30 'ut/%s/tradePile' 'TRADEPILE'
31 'ut/%s/trade' 'TRADE'
32 'ut/delete/%s/trade' 'DELETETRADE'
33 'ut/%s/marketdata' 'MARKETDATA'
34 'ut/%s/clientdata' 'CLIENTDATA'
35 'ut/auth' 'AUTH'
36 'ut/delete/auth' 'DELETE_AUTH'
37 'ut/%s/phishing' 'PHISHING'
38 'ut/%s/captcha' 'CAPTCHA'
39 'ut/%s/tfa' 'TFA'
40 'ut/%s/squad/mode' 'SQUADMODE'
41 'ut/%s/draft/mode' 'DRAFT'
42 'ut/%s/champion' 'CHAMPIONS'
43 'ut/v2/%s/store' 'V2STORE'
44 'ut/%s/livemessage' 'LIVEMESSAGE'
45 '' 'ADMIN'
46 '' 'DEBUG'
47 '' 'MAINTENANCE'
-- table ends after 48 rows --
docs/evidence/market-lifecycle-2026-08-17/cardsdll-vocab-tables.txt
-107
View File
@@ -1,107 +0,0 @@
=== tradeState (table walk) VA 0x180229e40 -> off 0x229240 ===
'active' = 1
'inactive' = 2
'expired' = 3
'closed' = 4
-- NULL terminator after 4 rows --
=== type VA 0x180229c30 -> off 0x229030 ===
'any' = -1
'player' = 1
'staff' = 2
'clubInfo' = 3
'training' = 4
'development' = 5
'stadium' = 6
'ball' = 7
-- NULL terminator after 8 rows --
=== zone VA 0x1802296e0 -> off 0x228ae0 ===
'goalKeeper' = 0
'defense' = 1
'midfield' = 2
'attacker' = 3
-- NULL terminator after 4 rows --
=== lev VA 0x180229a60 -> off 0x228e60 ===
'any' = 0
'gold' = 3
'silver' = 2
'bronze' = 1
-- NULL terminator after 4 rows --
=== pos VA 0x1802295c0 -> off 0x2289c0 ===
'GK' = 0
'RWB' = 2
'RB' = 3
'CB' = 5
'LB' = 7
'LWB' = 8
'CDM' = 10
'RM' = 12
'CM' = 14
'LM' = 16
'CAM' = 18
'RF' = 20
'CF' = 21
'LF' = 22
'RW' = 23
'ST' = 25
'LW' = 27
-- NULL terminator after 17 rows --
=== cat VA 0x180229ab0 -> off 0x228eb0 ===
'any' = -1
'playerGK' = 1
'playerRD' = 2
'playerRM' = 3
'playerRA' = 4
'manager' = 5
'headCoach' = 6
'GKCoach' = 7
'fitnessCoach' = 8
'physio' = 9
'badge' = 10
'kit' = 11
'leagueLogo' = 12
'playerTraining' = 13
'GKTraining' = 14
'position' = 15
'playStyle' = 16
'managerLeagueModifier' = 17
'contract' = 18
'fitness' = 19
'healing' = 20
'stadium' = 21
'ball' = 22
-- NULL terminator after 23 rows --
=== form VA 0x180229880 -> off 0x228c80 ===
'f3412' = 23
'f3421' = 24
'f343' = 25
'f352' = 27
'f41212' = 14
'f4231' = 3
'f4222' = 13
'f4312' = 6
'f4321' = 7
'f433' = 8
'f4411' = 19
'f442' = 16
'f451' = 21
'f5212' = 29
'f5221' = 30
'f532' = 31
'f541' = 32
'f41212a' = 15
'f4141' = 2
'f4231a' = 4
'f433a' = 9
'f433b' = 10
'f433c' = 11
'f433d' = 12
'f442a' = 17
'f451a' = 20
-- NULL terminator after 26 rows --
docs/evidence/market-lifecycle-2026-08-17/gap1-active-forsale.json
-173
View File
@@ -1,173 +0,0 @@
{
"gap": 1,
"test": "ACTIVE seller row under itemState=forSale",
"date": "2026-08-17",
"disposable_card": {
"wire_item_id": 100000178,
"resourceId": 212188,
"rating": 75,
"preferredPosition": "ST",
"copies_owned": 3,
"discardValue": 600,
"in_active_squad": false,
"untradeable": false
},
"pre_state": {
"club_items": 1966,
"coins": 29843976,
"tradePile_rows": 0,
"tradePile_counts": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 0
}
},
"listing_creation_route_log": "utas-host owner=RUST route=market-list POST item_id=100000178 listed=true trade_id=1000000178",
"client_flow_observed_rust_owned": [
"PUT /ut/game/fifa17/item (club -> trade pile move)",
"POST /ut/game/fifa17/auctionhouse (ISStart) -> 200",
"GET /ut/game/fifa17/tradePile (repeated)",
"GET /ut/game/fifa17/trade/status?tradeIds=1000000178 -> requested=1 returned=1 (repeated poll)",
"GET /ut/game/fifa17/tradePile/counts"
],
"wire_active_row": {
"tradeId": 1000000178,
"tradeState": "active",
"itemState": "forSale",
"startingBid": 150,
"buyNowPrice": 200,
"currentBid": 0,
"bidState": "none",
"sellerName": "CAGE",
"sellerEstablished": 1,
"watched": false,
"coinsProcessed": 0,
"atom_count": 12,
"itemData_attributeList_entries": 6
},
"countdown_sample": {
"expires": [
3562,
3556
],
"delta_secs": 6,
"live": true
},
"trade_status_coherent_while_running": true,
"trade_status_rows": [
{
"bidState": "none",
"buyNowPrice": 200,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 3556,
"itemData": {
"assetId": 212188,
"attributeList": [
{
"index": 0,
"value": 90
},
{
"index": 1,
"value": 70
},
{
"index": 2,
"value": 64
},
{
"index": 3,
"value": 78
},
{
"index": 4,
"value": 24
},
{
"index": 5,
"value": 62
}
],
"cardassetid": 212188,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 212188,
"discardValue": 600,
"fitness": 99,
"id": 100000178,
"itemState": "forSale",
"itemType": "player",
"leagueId": 19,
"nation": 21,
"owners": 1,
"playStyle": 250,
"preferredPosition": "ST",
"rareflag": 1,
"rating": 75,
"resourceId": 212188,
"teamid": 112172,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000178,
"tradeState": "active",
"watched": false
}
],
"tradePile_counts_while_active": {
"count": 1,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 1,
"sold": 0
},
"coins_unchanged": true,
"fix_a_inactive_rows": 0,
"CARD_OFFERSTATE_live_decode": {
"observed": true,
"method": "read-only /proc/<pid>/mem via fifa17-recon-derived auction_record_probe.py; slide proven by FNV control MATCH before any other read; O_RDONLY + pread only",
"client_pid": 29670,
"container": "model->vt[0x120] (trade pile), rows=1, +0x60 override=1",
"record": {
"tradeId": 1000000178,
"STATE_tradeState": "1(active)",
"YOURBID_bidState": "0(none)",
"MAX_CREDITS_buyNowPrice": 200,
"RESERVEDPRICE_startingBid": 150,
"currentBid": 0,
"expires": 3457,
"coinsProcessed": 0,
"IS_GLOW_flagB": 0,
"INBOX_flagA": 0,
"IS_WATCHED": 0
},
"item": {
"CARD_ID": 212188,
"CARD_TYPE": 1,
"tradeable": 1,
"rating": 75,
"CARD_OFFERSTATE_itemState": "5(forSale)",
"pile": 0
},
"ab_significance": "This is the direct A/B on the only changed field. Baseline `listFS` decoded to -1(<unrecognised>) in the client's own record; candidate `forSale` decodes to 5. Every other field in the record is unchanged in kind.",
"claim_boundary": "Proves the CLIENT DECODES the token correctly. Says nothing about the Flash action-gate term."
},
"ui_acceptance": {
"operator_report": "looks right",
"confirmed": [
"card renders under LISTED ITEMS (not the TRANSFER LIST section)",
"Start Price 150 and Buy Now 200 displayed correctly, Current Bid as expected",
"Time Remaining visibly counting down",
"card art renders normally; no malformed row, no duplicate, no premature Expired, no crash",
"row correctly non-actionable while active (established FIFA 17 behaviour, not a fault)"
],
"corroboration": "the client's trade-pile container populated with exactly this row (rows=1), so the Transfer List screen bound and drew it"
},
"verdict": "GAP 1 CLOSED \u2014 LIVE-CONFIRMED: an active seller auction with itemState=forSale renders correctly and is decoded by the client as CARD_OFFERSTATE=5",
"code_change_required": false
}
docs/evidence/market-lifecycle-2026-08-17/gap2-natural-expiry-samples.jsonl
-55
View File
@@ -1,55 +0,0 @@
{"t": 1787012091, "present": true, "tradeState": "active", "expires": 3175, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012151, "present": true, "tradeState": "active", "expires": 3115, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012211, "present": true, "tradeState": "active", "expires": 3055, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012271, "present": true, "tradeState": "active", "expires": 2995, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012331, "present": true, "tradeState": "active", "expires": 2935, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012391, "present": true, "tradeState": "active", "expires": 2875, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012451, "present": true, "tradeState": "active", "expires": 2815, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012511, "present": true, "tradeState": "active", "expires": 2755, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012571, "present": true, "tradeState": "active", "expires": 2695, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012631, "present": true, "tradeState": "active", "expires": 2635, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012691, "present": true, "tradeState": "active", "expires": 2575, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012751, "present": true, "tradeState": "active", "expires": 2515, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012811, "present": true, "tradeState": "active", "expires": 2455, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012871, "present": true, "tradeState": "active", "expires": 2395, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012931, "present": true, "tradeState": "active", "expires": 2335, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787012991, "present": true, "tradeState": "active", "expires": 2275, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013051, "present": true, "tradeState": "active", "expires": 2215, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013111, "present": true, "tradeState": "active", "expires": 2155, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013171, "present": true, "tradeState": "active", "expires": 2095, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013231, "present": true, "tradeState": "active", "expires": 2035, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013291, "present": true, "tradeState": "active", "expires": 1975, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013351, "present": true, "tradeState": "active", "expires": 1915, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013411, "present": true, "tradeState": "active", "expires": 1855, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013471, "present": true, "tradeState": "active", "expires": 1795, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013531, "present": true, "tradeState": "active", "expires": 1735, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013591, "present": true, "tradeState": "active", "expires": 1675, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013651, "present": true, "tradeState": "active", "expires": 1615, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013711, "present": true, "tradeState": "active", "expires": 1555, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013771, "present": true, "tradeState": "active", "expires": 1495, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013831, "present": true, "tradeState": "active", "expires": 1435, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013891, "present": true, "tradeState": "active", "expires": 1375, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787013951, "present": true, "tradeState": "active", "expires": 1315, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014011, "present": true, "tradeState": "active", "expires": 1255, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014071, "present": true, "tradeState": "active", "expires": 1195, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014131, "present": true, "tradeState": "active", "expires": 1135, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014191, "present": true, "tradeState": "active", "expires": 1075, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014251, "present": true, "tradeState": "active", "expires": 1015, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014311, "present": true, "tradeState": "active", "expires": 955, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014371, "present": true, "tradeState": "active", "expires": 895, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014431, "present": true, "tradeState": "active", "expires": 835, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014491, "present": true, "tradeState": "active", "expires": 775, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014551, "present": true, "tradeState": "active", "expires": 715, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014611, "present": true, "tradeState": "active", "expires": 655, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014671, "present": true, "tradeState": "active", "expires": 595, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014731, "present": true, "tradeState": "active", "expires": 535, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014791, "present": true, "tradeState": "active", "expires": 475, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014851, "present": true, "tradeState": "active", "expires": 415, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014911, "present": true, "tradeState": "active", "expires": 355, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787014971, "present": true, "tradeState": "active", "expires": 295, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787015031, "present": true, "tradeState": "active", "expires": 235, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787015091, "present": true, "tradeState": "active", "expires": 175, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787015151, "present": true, "tradeState": "active", "expires": 115, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787015211, "present": true, "tradeState": "active", "expires": 55, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787015271, "present": true, "tradeState": "expired", "expires": 0, "itemState": "forSale", "startingBid": 150, "buyNowPrice": 200, "total": 1, "credits": 29843976}
{"t": 1787015301, "present": false, "tradeState": null, "expires": null, "itemState": null, "startingBid": null, "buyNowPrice": null, "total": 0, "credits": 29843976}
docs/evidence/market-lifecycle-2026-08-17/gap2-return-to-club-persistence.json
-91
View File
@@ -1,91 +0,0 @@
{
"gap": 2,
"test": "expired -> Return to Club -> full exit/re-entry persistence",
"date": "2026-08-17",
"item": {
"wire_item_id": 100000178,
"resourceId": 212188,
"rating": 75,
"preferredPosition": "ST",
"tradeId": 1000000178
},
"natural_expiry": {
"method": "read-only sampler polling /tradePile once a minute; expiry is derived from created_at + duration, so it was OBSERVED, never forced. No timestamp was mutated at any point.",
"samples": 55,
"transitions": [
{
"t": 1787012091,
"tradeState": "active",
"expires": 3175,
"itemState": "forSale"
},
{
"t": 1787015271,
"tradeState": "expired",
"expires": 0,
"itemState": "forSale",
"note": "natural expiry reached; itemState stayed forSale through the transition"
},
{
"t": 1787015301,
"tradeState": null,
"total": 0,
"note": "row left the pile entirely \u2014 the operator's Return to Club"
}
],
"auction_duration_secs": 3600
},
"return_to_club_server_state": {
"tradePile_total": 0,
"tradePile_rows": 0,
"tradePile_counts": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 0
},
"trade_status": {
"tradeId": 1000000178,
"tradeState": "closed",
"expires": 0
},
"club_items": 1966,
"club_row": {
"id": 100000178,
"resourceId": 212188,
"rating": 75,
"preferredPosition": "ST",
"itemState": "free",
"untradeable": false
},
"duplicate_owned_ids": 0,
"market_store": {
"listing_1000000178": "cancelled",
"active": 0,
"reserved": 0,
"all_by_state": {
"cancelled": 3
}
},
"coins": 29843976,
"fix_a_inactive_rows": 0,
"checks_passed": "18/18"
},
"status": "GAP 2 CLOSED \u2014 Return to Club is durable across repeated full FUT exit/re-entry",
"exit_reentry": {
"observed": true,
"operator_report": "yes that card is still there",
"host_log_evidence": [
"route=move-items wire=100000178 pile=club auction_cancelled=1",
"route=auth-delete",
"route=auth ... ip=10.10.0.105 persona=33068179 sid_opened=true (fresh session)",
"route=hub clubPlayers=1966 auctionCount=0",
"route=club total=1986 emitted=1966 dropped_no_asset=0",
"the full auth -> userMassInfo -> hub -> club -> tradePile -> trade/status cycle repeated for a SECOND fresh session"
],
"session_boundaries_crossed": 2,
"server_checks_after_reentry": "18/18, identical to before the re-entry"
},
"code_change_required": false
}
docs/evidence/market-lifecycle-2026-08-17/hub.json
-9
View File
@@ -1,9 +0,0 @@
{
"auctionCount": 1,
"clubPlayers": 1965,
"tradePile": {
"count": 1,
"selling": 1,
"sold": 0
}
}
docs/evidence/market-lifecycle-2026-08-17/inactive-projection-removed.json
-34
View File
@@ -1,34 +0,0 @@
{
"date": "2026-08-17",
"change": "removed tradeState:'inactive' projection from /tradePile and /trade/status",
"why": "RE of the FUT front-end: the action gate is in the APT/ActionScript layer; only rows classified as auctions (getCardsInAuction/isInActiveAuction) reach PreCheckCardOptions -> handleTradeCardAction, so an 'inactive' row renders and can never be acted on. The corpus already said 'do not emit it' (plan-2026-08-06-transfer-market.md:731-733).",
"before": {
"total": 7,
"by_state": {
"expired": 1,
"inactive": 6
},
"credits": 29843976,
"trade_status_returned": 7
},
"after": {
"total": 1,
"by_state": {
"expired": 1
},
"credits": 29843976,
"trade_status_returned": 1
},
"club_invariant": {
"formerly_inactive_members_visible_in_club": 6,
"of": 6,
"stranded": 0,
"club_items": 1965
},
"not_fixed_here": {
"itemState": "listFS",
"finding": "0 occurrences in CardsDLL (md5 4de3493131d7d2ff7f8b360c5ac9b655) and 0 in 4.26 GiB of process memory; decodes to -1. FIFA 17 value is forSale (5).",
"reason_deferred": "CARD_OFFERSTATE is one of three unresolved action-gate candidates; every actionable row observed carried itemState -1, so changing it could perturb the working expired -> Return-to-Club flow. Ships alone with its own live A/B."
},
"gate_status": "Category C, STRONGLY SUPPORTED. Gate term NOT PROVEN: STATE, CARD_OFFERSTATE and RESERVEDPRICE/MAX_CREDITS all differ together in every observable row. Proof needs AVM1 disassembly of tradepile.isInActiveAuction."
}
docs/evidence/market-lifecycle-2026-08-17/inactive-row-live-confirmed.json
-129
View File
@@ -1,129 +0,0 @@
{
"auctionInfo": [
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 2674,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000155,
"itemState": "listFS",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000155,
"tradeState": "active",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000059,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000000059,
"tradeState": "inactive",
"watched": false
}
],
"credits": 29843976,
"duplicateItemIdList": [],
"total": 2
}
docs/evidence/market-lifecycle-2026-08-17/itemstate-forsale-ab.json
-110
View File
@@ -1,110 +0,0 @@
{
"date": "2026-08-17",
"change": "itemData.itemState on the seller's own auction rows: listFS -> forSale",
"sites": [
"openfut-utas-host/src/market.rs handle_market_query (GET /tradePile)",
"openfut-utas-host/src/market.rs handle_market_status (GET /trade/status)"
],
"why": {
"listFS": "not a FIFA 17 token: 0 occurrences in CardsDLL_Win64_retail.dll (md5 4de3493131d7d2ff7f8b360c5ac9b655), 0 in 4.26 GiB of live client memory, decodes to -1 via FUN_180166660",
"forSale": "FIFA 17 native, value 5, from the 12-row itemState table at 0x180229cc0",
"oracle": "the Python oracle emits listFS (utas_server.py:3921); the differential asserted PARITY and so passed while both sides were wrong"
},
"supporting_evidence_the_token_is_safe": "the market SEARCH route (/transfermarket) already emitted forSale before this change, so the client has been decoding forSale=5 on a live path all along",
"wire_ab": {
"baseline": {
"tradeId": 1000000155,
"tradeState": "expired",
"bidState": "none",
"expires": 0,
"startingBid": 150,
"buyNowPrice": 15000,
"currentBid": 0,
"sellerName": "CAGE",
"sellerEstablished": 1,
"watched": false,
"coinsProcessed": 0,
"atom_count": 12,
"itemState": "listFS",
"item_id": 100000155,
"resourceId": 158023,
"untradeable": false,
"rating": 93,
"preferredPosition": "RW"
},
"candidate": {
"tradeId": 1000000155,
"tradeState": "expired",
"bidState": "none",
"expires": 0,
"startingBid": 150,
"buyNowPrice": 15000,
"currentBid": 0,
"sellerName": "CAGE",
"sellerEstablished": 1,
"watched": false,
"coinsProcessed": 0,
"atom_count": 12,
"itemState": "forSale",
"item_id": 100000155,
"resourceId": 158023,
"untradeable": false,
"rating": 93,
"preferredPosition": "RW"
},
"fields_changed": [
"itemState"
],
"fields_identical": 17,
"credits_before": 29843976,
"credits_after": 29843976,
"fix_a_inactive_rows_before": 0,
"fix_a_inactive_rows_after": 0
},
"offline_gates": {
"host_tests": "126 pass",
"adapter_tests": "214 pass",
"fmt": "clean",
"clippy": "clean",
"differential": "relabelled market-query tradePile PARITY -> DIFFERENT-BY-DESIGN; now pins oracle=listFS and rust=forSale so the divergence stays visible"
},
"status": "PROMOTED \u2014 live-confirmed on the expired path",
"live_status": {
"session": "operator FIFA 17 session, 2026-08-17, against the already-expired row 1000000155 (res 158023, 93 RW)",
"expired_row_actionable": true,
"return_to_club_offered": true,
"return_to_club_succeeded": true,
"operator_report": "the card is back in my club",
"server_verified_after": {
"tradePile_total": 0,
"tradePile_rows": 0,
"tradePile_counts": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 0
},
"trade_status_1000000155": "closed",
"market_store_state": "cancelled",
"club_items": 1966,
"club_items_before": 1965,
"card_in_club": {
"id": 100000155,
"resourceId": 158023,
"rating": 93,
"preferredPosition": "RW",
"itemState": "free",
"untradeable": false
},
"duplicate_ids_in_club": 0,
"stale_active_listings": 0,
"inactive_rows": 0
},
"active_row_render_with_forSale": "NOT OBSERVED \u2014 no active listing existed during the session",
"full_exit_reentry_ui": "NOT DIRECTLY OBSERVED \u2014 durability established from the server state a fresh session reads (empty tradePile + card in club)"
},
"revert": "single-line: set both auction_record_as(l, \"forSale\") calls in market.rs back to \"listFS\", rebuild, hub restart prod-host",
"claim_boundary": "This validates PROTOCOL CORRECTNESS of the token only. It does NOT prove the Flash action-gate term; STATE / CARD_OFFERSTATE / RESERVEDPRICE+MAX_CREDITS remain confounded and the gate stays Category C / STRONGLY SUPPORTED / not proven.",
"narrows": "CARD_OFFERSTATE is not a gate term requiring -1: an expired row decoding 5 stayed actionable. STATE and RESERVEDPRICE/MAX_CREDITS remain confounded; the Flash gate is still Category C / not proven."
}
docs/evidence/market-lifecycle-2026-08-17/marketdata-pricelimits.json
-7
View File
@@ -1,7 +0,0 @@
[
{
"defId": 20801,
"maxPrice": 15000,
"minPrice": 150
}
]
docs/evidence/market-lifecycle-2026-08-17/phase-c-full-pile-exposed.json
-434
View File
@@ -1,434 +0,0 @@
{
"auctionInfo": [
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 1474,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000155,
"itemState": "listFS",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000155,
"tradeState": "active",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 172610,
"attributeList": [
{
"index": 0,
"value": 69
},
{
"index": 1,
"value": 33
},
{
"index": 2,
"value": 47
},
{
"index": 3,
"value": 57
},
{
"index": 4,
"value": 80
},
{
"index": 5,
"value": 76
}
],
"cardassetid": 172610,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 172610,
"discardValue": 900,
"fitness": 99,
"id": 100004867,
"itemState": "free",
"itemType": "player",
"leagueId": 31,
"nation": 54,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 1,
"rating": 80,
"resourceId": 172610,
"teamid": 54,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000004867,
"tradeState": "inactive",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 163824,
"attributeList": [
{
"index": 0,
"value": 70
},
{
"index": 1,
"value": 43
},
{
"index": 2,
"value": 56
},
{
"index": 3,
"value": 62
},
{
"index": 4,
"value": 82
},
{
"index": 5,
"value": 82
}
],
"cardassetid": 163824,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 163824,
"discardValue": 900,
"fitness": 99,
"id": 100004866,
"itemState": "free",
"itemType": "player",
"leagueId": 13,
"nation": 50,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 1,
"rating": 83,
"resourceId": 163824,
"teamid": 7,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000004866,
"tradeState": "inactive",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 177003,
"attributeList": [
{
"index": 0,
"value": 74
},
{
"index": 1,
"value": 75
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 89
},
{
"index": 4,
"value": 72
},
{
"index": 5,
"value": 66
}
],
"cardassetid": 177003,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 177003,
"discardValue": 1500,
"fitness": 99,
"id": 100000122,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 10,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 1,
"rating": 89,
"resourceId": 177003,
"teamid": 243,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000000122,
"tradeState": "inactive",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 177003,
"attributeList": [
{
"index": 0,
"value": 74
},
{
"index": 1,
"value": 75
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 89
},
{
"index": 4,
"value": 72
},
{
"index": 5,
"value": 66
}
],
"cardassetid": 177003,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 177003,
"discardValue": 1500,
"fitness": 99,
"id": 100000127,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 10,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 1,
"rating": 89,
"resourceId": 177003,
"teamid": 243,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000000127,
"tradeState": "inactive",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000059,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000000059,
"tradeState": "inactive",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000079,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000000079,
"tradeState": "inactive",
"watched": false
}
],
"credits": 29843976,
"duplicateItemIdList": [],
"total": 7
}
docs/evidence/market-lifecycle-2026-08-17/three-state-tradepile-active-expired-inactive.json
-190
View File
@@ -1,190 +0,0 @@
{
"auctionInfo": [
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 20801,
"attributeList": [
{
"index": 0,
"value": 92
},
{
"index": 1,
"value": 92
},
{
"index": 2,
"value": 81
},
{
"index": 3,
"value": 91
},
{
"index": 4,
"value": 33
},
{
"index": 5,
"value": 80
}
],
"cardassetid": 20801,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 20801,
"discardValue": 1500,
"fitness": 99,
"id": 100000097,
"itemState": "listFS",
"itemType": "player",
"leagueId": 53,
"nation": 38,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LW",
"rareflag": 1,
"rating": 94,
"resourceId": 20801,
"teamid": 243,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000097,
"tradeState": "expired",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 2996,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000155,
"itemState": "listFS",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000155,
"tradeState": "active",
"watched": false
},
{
"bidState": "none",
"buyNowPrice": 0,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 0,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000059,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 0,
"tradeId": 1000000059,
"tradeState": "inactive",
"watched": false
}
],
"credits": 29843976,
"duplicateItemIdList": [],
"total": 3
}
docs/evidence/market-lifecycle-2026-08-17/trade-status-filtered.json
-66
View File
@@ -1,66 +0,0 @@
{
"auctionInfo": [
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 2220,
"itemData": {
"assetId": 20801,
"attributeList": [
{
"index": 0,
"value": 92
},
{
"index": 1,
"value": 92
},
{
"index": 2,
"value": 81
},
{
"index": 3,
"value": 91
},
{
"index": 4,
"value": 33
},
{
"index": 5,
"value": 80
}
],
"cardassetid": 20801,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 20801,
"discardValue": 1500,
"fitness": 99,
"id": 100000097,
"itemState": "listFS",
"itemType": "player",
"leagueId": 53,
"nation": 38,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LW",
"rareflag": 1,
"rating": 94,
"resourceId": 20801,
"teamid": 243,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000097,
"tradeState": "active",
"watched": false
}
],
"credits": 29843976
}
docs/evidence/market-lifecycle-2026-08-17/trade-status-unfiltered.json
-66
View File
@@ -1,66 +0,0 @@
{
"auctionInfo": [
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 1199,
"itemData": {
"assetId": 20801,
"attributeList": [
{
"index": 0,
"value": 92
},
{
"index": 1,
"value": 92
},
{
"index": 2,
"value": 81
},
{
"index": 3,
"value": 91
},
{
"index": 4,
"value": 33
},
{
"index": 5,
"value": 80
}
],
"cardassetid": 20801,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 20801,
"discardValue": 1500,
"fitness": 99,
"id": 100000097,
"itemState": "listFS",
"itemType": "player",
"leagueId": 53,
"nation": 38,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LW",
"rareflag": 1,
"rating": 94,
"resourceId": 20801,
"teamid": 243,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000097,
"tradeState": "active",
"watched": false
}
],
"credits": 29843976
}
docs/evidence/market-lifecycle-2026-08-17/tradePile-counts.json
-7
View File
@@ -1,7 +0,0 @@
{
"count": 1,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 1,
"sold": 0
}
docs/evidence/market-lifecycle-2026-08-17/tradePile.json
-68
View File
@@ -1,68 +0,0 @@
{
"auctionInfo": [
{
"bidState": "none",
"buyNowPrice": 15000,
"coinsProcessed": 0,
"currentBid": 0,
"expires": 1199,
"itemData": {
"assetId": 20801,
"attributeList": [
{
"index": 0,
"value": 92
},
{
"index": 1,
"value": 92
},
{
"index": 2,
"value": 81
},
{
"index": 3,
"value": 91
},
{
"index": 4,
"value": 33
},
{
"index": 5,
"value": 80
}
],
"cardassetid": 20801,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 20801,
"discardValue": 1500,
"fitness": 99,
"id": 100000097,
"itemState": "listFS",
"itemType": "player",
"leagueId": 53,
"nation": 38,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LW",
"rareflag": 1,
"rating": 94,
"resourceId": 20801,
"teamid": 243,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 1000000097,
"tradeState": "active",
"watched": false
}
],
"credits": 29843976,
"duplicateItemIdList": [],
"total": 1
}
docs/evidence/market-lifecycle-2026-08-17/unlisted-club-records.json
-242
View File
@@ -1,242 +0,0 @@
{
"100000059": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"discardValue": 1500,
"fitness": 99,
"id": 100000059,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": false
},
"100000122": {
"assetId": 177003,
"attributeList": [
{
"index": 0,
"value": 74
},
{
"index": 1,
"value": 75
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 89
},
{
"index": 4,
"value": 72
},
{
"index": 5,
"value": 66
}
],
"cardassetid": 177003,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 177003,
"discardValue": 1500,
"fitness": 99,
"id": 100000122,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 10,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 1,
"rating": 89,
"resourceId": 177003,
"teamid": 243,
"untradeable": false
},
"100000127": {
"assetId": 177003,
"attributeList": [
{
"index": 0,
"value": 74
},
{
"index": 1,
"value": 75
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 89
},
{
"index": 4,
"value": 72
},
{
"index": 5,
"value": 66
}
],
"cardassetid": 177003,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 177003,
"discardValue": 1500,
"fitness": 99,
"id": 100000127,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 10,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 1,
"rating": 89,
"resourceId": 177003,
"teamid": 243,
"untradeable": false
},
"100004866": {
"assetId": 163824,
"attributeList": [
{
"index": 0,
"value": 70
},
{
"index": 1,
"value": 43
},
{
"index": 2,
"value": 56
},
{
"index": 3,
"value": 62
},
{
"index": 4,
"value": 82
},
{
"index": 5,
"value": 82
}
],
"cardassetid": 163824,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 163824,
"discardValue": 900,
"fitness": 99,
"id": 100004866,
"itemState": "free",
"itemType": "player",
"leagueId": 13,
"nation": 50,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 1,
"rating": 83,
"resourceId": 163824,
"teamid": 7,
"untradeable": false
},
"100004867": {
"assetId": 172610,
"attributeList": [
{
"index": 0,
"value": 69
},
{
"index": 1,
"value": 33
},
{
"index": 2,
"value": 47
},
{
"index": 3,
"value": 57
},
{
"index": 4,
"value": 80
},
{
"index": 5,
"value": 76
}
],
"cardassetid": 172610,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 172610,
"discardValue": 900,
"fitness": 99,
"id": 100004867,
"itemState": "free",
"itemType": "player",
"leagueId": 31,
"nation": 54,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 1,
"rating": 80,
"resourceId": 172610,
"teamid": 54,
"untradeable": false
}
}
docs/evidence/market-sold-re-2026-08-17/q_sold_1.out
-308
View File
@@ -1,308 +0,0 @@
==============================================================================
== auctionInfo deserializer 0x18013e410 — full decompilation
==============================================================================
/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */
undefined4 FUN_18013e410(undefined8 param_1,longlong param_2,undefined8 param_3)
{
longlong *plVar1;
undefined1 *puVar2;
undefined1 *puVar3;
undefined ***pppuVar4;
undefined ***pppuVar5;
char cVar6;
int iVar7;
int iVar8;
undefined8 uVar9;
longlong *plVar10;
undefined4 uVar11;
undefined1 auStack_138 [32];
undefined **local_118;
undefined8 local_110;
longlong local_108;
undefined8 local_100;
undefined **local_f8;
undefined1 local_f0 [32];
undefined1 local_d0;
longlong *local_c8;
undefined8 local_c0;
undefined1 local_b0 [36];
undefined4 local_8c;
undefined4 local_88;
undefined4 local_84;
undefined4 local_80;
int local_70;
undefined8 local_68;
undefined1 local_58 [8];
longlong local_50;
longlong *local_48;
int local_40;
undefined1 local_3c;
undefined1 local_3b;
undefined1 local_3a;
undefined1 local_39;
ulonglong local_38;
local_100 = 0xfffffffffffffffe;
local_38 = DAT_1802db6e0 ^ (ulonglong)auStack_138;
iVar8 = 0x38c;
FUN_18010f5f0(&local_f8);
iVar7 = FUN_1801c7f10(param_2);
while (iVar7 != 10) {
if (*(int *)(param_2 + 0xd0) == 0xb) {
iVar8 = FUN_180180d00(*(undefined8 *)(param_2 + 0xf8));
iVar7 = FUN_1801c7f10(param_2);
if (iVar7 != 6) goto LAB_18013e498;
}
else {
LAB_18013e498:
if (iVar8 < 0x2b8) {
if (iVar8 == 0x2b7) {
uVar9 = FUN_1801c7aa0(param_2);
FUN_180008120(local_b0,uVar9,0x1e);
}
else if (iVar8 < 0x117) {
if (iVar8 == 0x116) {
local_68 = FUN_1801c79d0(param_2);
}
else if (iVar8 == 0x57) {
uVar9 = FUN_1801c7aa0(param_2);
local_40 = FUN_180166380(uVar9);
}
else if (iVar8 == 0x65) {
uVar9 = FUN_1801c79d0(param_2);
local_88 = FUN_1800d7b30(uVar9);
}
else {
if (iVar8 != 0xc1) goto LAB_18013e59b;
uVar9 = FUN_1801c79d0(param_2);
local_80 = FUN_1800d7b30(uVar9);
}
}
else if (iVar8 == 0x16b) {
FUN_18013fe00(local_58,param_2,0);
}
else if (iVar8 == 0x2b6) {
uVar9 = FUN_1801c79d0(param_2);
local_8c = FUN_1800d7b30(uVar9);
}
else {
LAB_18013e59b:
FUN_180135ff0(iVar8,param_2);
}
}
else if (iVar8 == 0x2e6) {
uVar9 = FUN_1801c79d0(param_2);
local_84 = FUN_1800d7b30(uVar9);
}
else if (iVar8 == 0x2f4) {
uVar9 = FUN_1801c79d0(param_2);
local_39 = FUN_1800d7b50(uVar9);
}
else if (iVar8 == 0x331) {
local_c0 = FUN_1801c79d0(param_2);
}
else if (iVar8 == 0x335) {
uVar9 = FUN_1801c7aa0(param_2);
local_70 = FUN_180166bd0(uVar9);
}
else {
if (iVar8 != 0x380) goto LAB_18013e59b;
cVar6 = FUN_1801c7620(param_2);
local_3c = cVar6 != '\0';
}
}
iVar7 = FUN_1801c7f10(param_2);
}
if (local_70 == 4) {
local_3b = local_40 != 0;
}
else {
local_3b = (local_40 - 1U & 0xfffffffd) == 0;
}
local_3a = local_40 - 2U < 2;
local_d0 = 1;
FUN_180007f60(local_f0,param_3,1);
plVar10 = (longlong *)FUN_18011a830();
if (local_48 == (longlong *)0x0) {
local_110 = 0;
local_118 = &PTR_LAB_180214de8;
local_108 = 0;
(**(code **)(*plVar10 + 0xa00))(plVar10,&local_118,local_c0);
if (local_108 == 0) {
uVar11 = 1;
goto LAB_18013e795;
}
if ((local_58 != (undefined1 *)(local_108 + 0xa0)) &&
(plVar1 = *(longlong **)(local_108 + 0xb0), local_48 != plVar1)) {
if (local_48 != (longlong *)0x0) {
puVar2 = (undefined1 *)*local_48;
puVar3 = *(undefined1 **)(puVar2 + 8);
if (local_58 == puVar2) {
*local_48 = (longlong)puVar3;
}
else {
for (; puVar3 != (undefined1 *)0x0; puVar3 = *(undefined1 **)(puVar3 + 8)) {
if (puVar3 == local_58) {
*(undefined8 *)(puVar2 + 8) = *(undefined8 *)(puVar3 + 8);
break;
}
puVar2 = puVar3;
}
}
}
local_48 = plVar1;
if (plVar1 != (longlong *)0x0) {
local_50 = *plVar1;
*plVar1 = (longlong)local_58;
}
}
local_118 = &PTR_LAB_180214de8;
if (local_108 != 0) {
pppuVar4 = *(undefined ****)(local_108 + 0x30);
pppuVar5 = (undefined ***)pppuVar4[1];
if (&local_118 == pppuVar4) {
*(undefined ****)(local_108 + 0x30) = pppuVar5;
}
else {
for (; pppuVar5 != (undefined ***)0x0; pppuVar5 = (undefined ***)pppuVar5[1]) {
if (pppuVar5 == &local_118) {
pppuVar4[1] = pppuVar5[1];
break;
}
pppuVar4 = pppuVar5;
}
}
}
}
(**(code **)(*plVar10 + 0x9f8))(plVar10,param_1,&local_f8);
uVar11 = 10;
LAB_18013e795:
FUN_18000a3c0(local_58);
local_f8 = &PTR_FUN_18021b520;
while (local_c8 != (longlong *)0x0) {
plVar10 = (longlong *)local_c8[1];
(**(code **)(*local_c8 + 8))();
local_c8 = plVar10;
}
return uVar11;
}
==============================================================================
== Flash publisher 0x1801bf030 — full decompilation
==============================================================================
void FUN_1801bf030(longlong *param_1,longlong param_2,undefined8 param_3,undefined8 param_4)
{
longlong lVar1;
longlong *plVar2;
longlong lVar3;
int iVar4;
undefined4 local_res8 [2];
undefined4 local_res10 [2];
undefined4 local_res18 [2];
undefined4 local_res20 [2];
undefined1 *local_b0;
undefined1 *local_a8;
undefined1 *local_a0;
longlong *local_98;
undefined4 local_90;
char *local_88;
longlong local_80 [2];
longlong local_70;
longlong *local_68;
(**(code **)(*param_1 + 8))
(param_1,(*(longlong *)(param_2 + 0x38) - *(longlong *)(param_2 + 0x30)) / 0x18,*param_1
,param_4,0xfffffffffffffffe);
iVar4 = 0;
lVar3 = *(longlong *)(param_2 + 0x30);
if (lVar3 != *(longlong *)(param_2 + 0x38)) {
do {
lVar1 = *(longlong *)(lVar3 + 0x10);
FUN_1800d8fa0(*(undefined8 *)(lVar1 + 0x38),local_res10,local_res8);
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"TRADEID_LOWER",local_res8[0]);
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"TRADEID_UPPER",local_res10[0]);
FUN_1801a9200(local_80,*(undefined4 *)(lVar1 + 0x6c));
local_98 = (longlong *)FUN_1800d7370();
local_90 = 1;
local_88 = "FUT String";
local_b0 = &DAT_1802e13a0;
local_a8 = &DAT_1802e13a0;
local_a0 = &DAT_1802e13a1;
if (*(longlong *)(lVar1 + 0x90) - 1U < 0x20f5800) {
FUN_1801c2e50(&local_b0);
}
else {
plVar2 = (longlong *)FUN_18019e320();
(**(code **)(*plVar2 + 400))(plVar2,&local_b0,"FUT_AUCTION_EXPIRED",1);
}
(**(code **)(*param_1 + 0x30))(param_1,iVar4,"DURATION",local_b0);
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"TIME_REMAINING",*(undefined4 *)(lVar1 + 0x90));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"MIN_CREDITS",*(undefined4 *)(lVar1 + 0x78));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"MAX_CREDITS",*(undefined4 *)(lVar1 + 0x70));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"RESERVEDPRICE",*(undefined4 *)(lVar1 + 0x74));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"YOURBID",*(undefined4 *)(lVar1 + 0xb8));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"STATE",*(undefined4 *)(lVar1 + 0x88));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"COINS_AWARDED",*(undefined1 *)(lVar1 + 0xbf));
FUN_1800d8fa0(*(undefined8 *)(*(longlong *)(lVar1 + 0xb0) + 8),local_res18,local_res20);
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"UUID_UPPER",local_res18[0]);
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"UUID_LOWER",local_res20[0]);
(**(code **)(*param_1 + 0x20))
(param_1,iVar4,"CARD_ID",*(undefined4 *)(*(longlong *)(lVar1 + 0xb0) + 0x18));
(**(code **)(*param_1 + 0x20))
(param_1,iVar4,"FIFA_ID",*(uint *)(*(longlong *)(lVar1 + 0xb0) + 0x18) & 0xffffff);
(**(code **)(*param_1 + 0x20))
(param_1,iVar4,"CARD_TYPE",*(undefined4 *)(*(longlong *)(lVar1 + 0xb0) + 0x4c));
(**(code **)(*param_1 + 0x20))
(param_1,iVar4,"CARD_OFFERSTATE",*(undefined4 *)(*(longlong *)(lVar1 + 0xb0) + 0x5c)
);
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"IS_WATCHED",*(undefined1 *)(lVar1 + 0xbc));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"INBOX",*(undefined1 *)(lVar1 + 0xbe));
(**(code **)(*param_1 + 0x20))(param_1,iVar4,"IS_GLOW",*(undefined1 *)(lVar1 + 0xbd));
(**(code **)(*param_1 + 0x18))(param_1,iVar4,"TRADE_DATA_AVAILABLE",1);
if (1 < (longlong)local_a0 - (longlong)local_b0) {
if (local_b0 != (undefined1 *)0x0) {
(**(code **)(*local_98 + 0x18))(local_98,local_b0,(int)local_a0 - (int)local_b0);
}
}
if ((1 < local_70 - local_80[0]) && (local_80[0] != 0)) {
(**(code **)(*local_68 + 0x18))(local_68,local_80[0],(int)local_70 - (int)local_80[0]);
}
lVar3 = lVar3 + 0x18;
iVar4 = iVar4 + 1;
} while (lVar3 != *(longlong *)(param_2 + 0x38));
}
return;
}
==============================================================================
== strings: sold / clear / inbox / glow / collect
==============================================================================
sold 0x180228bed 'sold'
sold 0x18022f524 'sold'
Sold 0x1801efaf1 'SoldFromTradePile'
Sold 0x1802302cf 'SoldBid'
Sold 0x1802302df 'SoldBuyNow'
SOLD 0x18020a0c7 'SOLD'
clearSold ABSENT
ClearSold ABSENT
INBOX 0x180215044 'INBOX'
inbox ABSENT
IS_GLOW 0x1802151a0 'IS_GLOW'
glow ABSENT
Glow ABSENT
collect 0x1802307e0 'collector'
Collect 0x1801ec3c1 'CollectedCards'
Collect 0x1801ec3f8 'Collection'
Collect 0x1801ec422 'Collection'
Collect 0x1801ec449 'Collection'
unclaimed 0x18022fd68 'unclaimedPrizesChampionEvents'
claim 0x1802099d1 'claimedPack'
claim 0x1802099e9 'claimedPack2'
claim 0x18022fd6a 'claimedPrizesChampionEvents'
docs/evidence/market-sold-re-2026-08-17/q_sold_1.py
-30
View File
@@ -1,30 +0,0 @@
"""Q1 — what does FIFA17 do with tradeState == closed(4)?
Targets the ONE native tradeState consumer branch (cmp [rbp-0x38],0x4 at
0x18013e619) inside the auctionInfo deserializer 0x18013e410, and the Flash
publisher 0x1801bf030.
"""
print("=" * 78)
print("== auctionInfo deserializer 0x18013e410 — full decompilation")
print("=" * 78)
print(dec(0x18013E410))
print("=" * 78)
print("== Flash publisher 0x1801bf030 — full decompilation")
print("=" * 78)
print(dec(0x1801BF030))
print("=" * 78)
print("== strings: sold / clear / inbox / glow / collect")
print("=" * 78)
for needle in (b"sold", b"Sold", b"SOLD", b"clearSold", b"ClearSold",
b"INBOX", b"inbox", b"IS_GLOW", b"glow", b"Glow",
b"collect", b"Collect", b"unclaimed", b"claim"):
hits = find_all(needle, blocks=(".rdata", ".data", ".text"))
for h in hits[:14]:
s = rd_str(h, 90)
if s and len(s) > 2:
print(f" {needle.decode():12s} 0x{h:x} {s!r}")
if not hits:
print(f" {needle.decode():12s} ABSENT")
docs/evidence/market-sold-re-2026-08-17/q_sold_2.out
-114
View File
@@ -1,114 +0,0 @@
==============================================================================
== neighbourhood of SoldBid/SoldBuyNow (0x1802302cf) — read the whole table
==============================================================================
0x180230280 'auctionLostBidRejected'
0x180230298 'auctionLostOutbid'
0x1802302b0 'auctionLostOutbidSelf'
0x1802302c8 'auctionSoldBid'
0x1802302d8 'auctionSoldBuyNow'
0x1802302f0 'auctionWonBid'
0x180230300 'auctionWonBuyNow'
0x180230318 'authToken'
0x180230328 'available'
0x180230338 'awaykit'
0x180230340 'awardCount'
0x180230350 'awardedPrizes'
0x180230360 'awardItemData'
0x180230370 'awardMappings'
0x180230380 'awardType'
0x180230390 'awardSet'
0x1802303a0 'awardSetId'
0x1802303ac 'awards'
0x1802303b8 'awardValue'
0x1802303c8 'badgeDBid'
0x1802303d4 'badges'
0x1802303dc 'balls'
0x1802303e8 'BEGINNER'
0x1802303f8 'bestBuilderScore'
==============================================================================
== xrefs to each sold-ish string
==============================================================================
sold@228bed 0 xref(s)
sold@22f524 1 xref(s)
from 0x1802d3da8 DATA in ? (entry 0x0)
SoldFromTradePile 0 xref(s)
SoldBid 0 xref(s)
SoldBuyNow 0 xref(s)
SOLD@20a0c7 0 xref(s)
==============================================================================
== who reads record +0xbf (COINS_AWARDED) / +0xbe (INBOX) / +0xbd (IS_GLOW)
== i.e. the deserializer's coinsProcessed + the two computed flags
==============================================================================
-- decoder for atom 0x2f4 (coinsProcessed): FUN_1800d7b50
ulonglong FUN_1800d7b50(longlong param_1)
{
ulonglong in_RAX;
byte bVar1;
if (0 < param_1) {
bVar1 = 0xff;
if (param_1 < 0xff) {
bVar1 = (byte)param_1;
}
return (ulonglong)bVar1;
}
return in_RAX & 0xffffffffffffff00;
}
==============================================================================
== route table 0x18021df80 — all 45 rows, looking for a clear/sold route
==============================================================================
[ 0] 0x18021df80 -> 0x18021e308 'ut/%s/auctionhouse'
[ 1] 0x18021df88 -> 0x18021e320 'AUCTIONHOUSE'
[ 2] 0x18021df90 -> 0x18021e330 'ut/%s/clubUser'
[ 3] 0x18021df98 -> 0x18021e340 'CLUB_USER'
[ 4] 0x18021dfa0 -> 0x18021e350 'ut/%s/user/list'
[ 5] 0x18021dfa8 -> 0x1801fa0b8 'CLUB_INFO'
[ 6] 0x18021dfb0 -> 0x18021e360 'ut/%s/club'
[ 7] 0x18021dfb8 -> 0x1801f6438 'CLUB'
[ 8] 0x18021dfc0 -> 0x18021e370 'ut/%s/defid'
[ 9] 0x18021dfc8 -> 0x18021e37c 'DREAM'
[10] 0x18021dfd0 -> 0x18021e388 'ut/%s/squad'
[11] 0x18021dfd8 -> 0x18021e394 'SQUAD'
[12] 0x18021dfe0 -> 0x18021e3a0 'ut/delete/%s/squad'
[13] 0x18021dfe8 -> 0x18021e3b8 'DELETE_SQUAD'
[14] 0x18021dff0 -> 0x18021e3c8 'ut/%s/leaderboards/options'
[15] 0x18021dff8 -> 0x18021e3e8 'LBOPTIONS'
[16] 0x18021e000 -> 0x18021e3f8 'ut/%s/leaderboards'
[17] 0x18021e008 -> 0x18021e410 'LBDEFAULT'
[18] 0x18021e010 -> 0x18021e420 'ut/%s/activeMessage'
[19] 0x18021e018 -> 0x18021e438 'PAFPRACTICE'
[20] 0x18021e020 -> 0x18021e444 'ut/%s'
[21] 0x18021e028 -> 0x18021e44c 'UT'
[22] 0x18021e030 -> 0x18021e450 'ut/%s/user'
[23] 0x18021e038 -> 0x18021e45c 'USER'
[24] 0x18021e040 -> 0x18021e468 'ut/delete/%s/user'
[25] 0x18021e048 -> 0x18021e480 'DELETEUSER'
[26] 0x18021e050 -> 0x18021e490 'ut/%s/item'
[27] 0x18021e058 -> 0x18021e49c 'ITEMS'
[28] 0x18021e060 -> 0x18021e4a8 'ut/%s/item/resource'
[29] 0x18021e068 -> 0x18021e4c0 'ITEMS_BY_RES'
[30] 0x18021e070 -> 0x18021e4d0 'ut/delete/%s/item'
[31] 0x18021e078 -> 0x18021e4e8 'DELETEITEMS'
[32] 0x18021e080 -> 0x18021e4f8 'ut/%s/match'
[33] 0x18021e088 -> 0x1801ecc34 'MATCH'
[34] 0x18021e090 -> 0x18021e508 'ut/%s/sbs'
[35] 0x18021e098 -> 0x18021e514 'SBC'
[36] 0x18021e0a0 -> 0x18021e518 'ut/%s/tournament'
[37] 0x18021e0a8 -> 0x18021e530 'TOURNAMENT'
[38] 0x18021e0b0 -> 0x18021e540 'ut/%s/tournament/user'
[39] 0x18021e0b8 -> 0x18021e558 'TOURNAMENTUSER'
[40] 0x18021e0c0 -> 0x18021e568 'ut/delete/%s/tournament/user'
[41] 0x18021e0c8 -> 0x18021e588 'TOURNAMENTQUIT'
[42] 0x18021e0d0 -> 0x18021e598 'ut/%s/season'
[43] 0x18021e0d8 -> 0x180209fc4 'SEASON'
[44] 0x18021e0e0 -> 0x18021e5a8 'ut/%s/season/user'
[45] 0x18021e0e8 -> 0x18021e5c0 'SEASONUSER'
[46] 0x18021e0f0 -> 0x18021e5d0 'ut/%s/season/%%s/user'
[47] 0x18021e0f8 -> 0x18021e5e8 'SEASONUSER_ALTER'
docs/evidence/market-sold-re-2026-08-17/q_sold_2.py
-50
View File
@@ -1,50 +0,0 @@
"""Q2 — the sold vocabulary: SoldBid / SoldBuyNow / SoldFromTradePile / sold,
the coinsProcessed -> COINS_AWARDED path, and the route table (clear-sold?).
"""
print("=" * 78)
print("== neighbourhood of SoldBid/SoldBuyNow (0x1802302cf) — read the whole table")
print("=" * 78)
a = 0x180230280
while a < 0x180230400:
s = rd_str(a, 60)
if s and len(s) > 1 and s.isprintable():
print(f" 0x{a:x} {s!r}")
a += len(s.encode()) + 1
else:
a += 1
print()
print("=" * 78)
print("== xrefs to each sold-ish string")
print("=" * 78)
for name, sa in (("sold@228bed", 0x180228BED), ("sold@22f524", 0x18022F524),
("SoldFromTradePile", 0x1801EFAF1), ("SoldBid", 0x1802302CF),
("SoldBuyNow", 0x1802302DF), ("SOLD@20a0c7", 0x18020A0C7)):
xs = xrefs_to(sa)
print(f" {name:20s} {len(xs)} xref(s)")
for x in xs[:8]:
print(f" from 0x{x[0]:x} {x[1]} in {x[2]} (entry 0x{x[3]:x})")
print()
print("=" * 78)
print("== who reads record +0xbf (COINS_AWARDED) / +0xbe (INBOX) / +0xbd (IS_GLOW)")
print("== i.e. the deserializer's coinsProcessed + the two computed flags")
print("=" * 78)
print("-- decoder for atom 0x2f4 (coinsProcessed): FUN_1800d7b50")
print(dec(0x1800D7B50))
print()
print("=" * 78)
print("== route table 0x18021df80 — all 45 rows, looking for a clear/sold route")
print("=" * 78)
for i in range(48):
ea = 0x18021DF80 + i * 8
try:
p = qword(ea)
except Exception:
break
s = ""
if 0x180000000 < p < 0x180400000:
s = rd_str(p, 120)
print(f" [{i:2d}] 0x{ea:x} -> 0x{p:x} {s!r}")
docs/evidence/market-sold-re-2026-08-17/q_sold_3.out
-123
View File
@@ -1,123 +0,0 @@
==============================================================================
== route table continued from 0x18021e0f8 until it stops looking like one
==============================================================================
0x18021e100 -> 0x18021e600 'ut/%s/season/%%s/reset'
0x18021e108 -> 0x18021e618 'SEASONRESET'
0x18021e110 -> 0x18021e628 'ut/%s/season/friendly'
0x18021e118 -> 0x18021e640 'FRIENDLYSEASON'
0x18021e120 -> 0x18021e650 'ut/%s/purchased'
0x18021e128 -> 0x18021e660 'PURCHASED'
0x18021e130 -> 0x18021e670 'ut/%s/store'
0x18021e138 -> 0x18021e67c 'STORE'
0x18021e140 -> 0x18021e688 'ut/%s/watchList'
0x18021e148 -> 0x18021e698 'WATCHLIST'
0x18021e150 -> 0x18021e6a8 'ut/delete/%s/watchList'
0x18021e158 -> 0x18021e6c0 'DELETEWATCHLIST'
0x18021e160 -> 0x18021e6d0 'ut/%s/tradePile'
0x18021e168 -> 0x18021e6e0 'TRADEPILE'
0x18021e170 -> 0x18021e6f0 'ut/%s/trade'
0x18021e178 -> 0x18021e6fc 'TRADE'
0x18021e180 -> 0x18021e708 'ut/delete/%s/trade'
0x18021e188 -> 0x18021e720 'DELETETRADE'
0x18021e190 -> 0x18021e730 'ut/%s/marketdata'
0x18021e198 -> 0x18021e748 'MARKETDATA'
0x18021e1a0 -> 0x18021e758 'ut/%s/clientdata'
0x18021e1a8 -> 0x18021e770 'CLIENTDATA'
0x18021e1b0 -> 0x18021e780 'ut/auth'
0x18021e1b8 -> 0x18021e788 'AUTH'
0x18021e1c0 -> 0x18021e790 'ut/delete/auth'
0x18021e1c8 -> 0x18021e7a0 'DELETE_AUTH'
0x18021e1d0 -> 0x18021e7b0 'ut/%s/phishing'
0x18021e1d8 -> 0x18021e7c0 'PHISHING'
0x18021e1e0 -> 0x18021e7d0 'ut/%s/captcha'
0x18021e1e8 -> 0x18021e7e0 'CAPTCHA'
0x18021e1f0 -> 0x18021e7e8 'ut/%s/tfa'
0x18021e1f8 -> 0x18021e7f4 'TFA'
0x18021e200 -> 0x18021e7f8 'ut/%s/squad/mode'
0x18021e208 -> 0x18021e810 'SQUADMODE'
0x18021e210 -> 0x18021e820 'ut/%s/draft/mode'
0x18021e218 -> 0x18021e834 'DRAFT'
0x18021e220 -> 0x18021e840 'ut/%s/champion'
0x18021e228 -> 0x18021e850 'CHAMPIONS'
0x18021e230 -> 0x18021e860 'ut/v2/%s/store'
0x18021e238 -> 0x18021e870 'V2STORE'
0x18021e240 -> 0x18021e878 'ut/%s/livemessage'
0x18021e248 -> 0x18021e890 'LIVEMESSAGE'
0x18021e258 -> 0x18021e89c 'ADMIN'
0x18021e268 -> 0x18021e8a4 'DEBUG'
0x18021e278 -> 0x18021e8b0 'MAINTENANCE'
==============================================================================
== itemState table 0x180229cc0 (prior work: 12 rows) — dump generously
==============================================================================
[ 0] 0x180229cc0 str=0x18022a2a0 'invalid' val=0 (0x0)
[ 1] 0x180229cd0 str=0x18022a2a8 'free' val=1 (0x1)
[ 2] 0x180229ce0 str=0x18022a2b0 'WAITING_FOR_GAME' val=2 (0x2)
[ 3] 0x180229cf0 str=0x18022a2c4 'inGame' val=2 (0x2)
[ 4] 0x180229d00 str=0x18022a2d0 'forSale' val=5 (0x5)
[ 5] 0x180229d10 str=0x18022a2d8 'offered' val=6 (0x6)
[ 6] 0x180229d20 str=0x18022a2e0 'activeBadge' val=100 (0x64)
[ 7] 0x180229d30 str=0x18022a2f0 'activeHomeKit' val=101 (0x65)
[ 8] 0x180229d40 str=0x18022a300 'activeAwayKit' val=102 (0x66)
[ 9] 0x180229d50 str=0x18022a310 'activeBall' val=103 (0x67)
[10] 0x180229d60 str=0x18022a320 'activeStadium' val=104 (0x68)
[11] 0x180229d70 str=0x180221c04 'active' val=255 (0xff)
[12] 0x180229d80 str=0x0 '' val=4294967295 (0xffffffff)
[13] 0x180229d90 str=0x18022a330 'none' val=8 (0x8)
[14] 0x180229da0 str=0x18022a338 'head' val=0 (0x0)
[15] 0x180229db0 str=0x18022a340 'shoulder' val=1 (0x1)
[16] 0x180229dc0 str=0x18022a34c 'arm' val=2 (0x2)
[17] 0x180229dd0 str=0x1802009d0 'back' val=3 (0x3)
[18] 0x180229de0 str=0x18022a350 'hip' val=4 (0x4)
[19] 0x180229df0 str=0x18022a354 'leg' val=5 (0x5)
==============================================================================
== tradeState table 0x180229e40 — dump generously
==============================================================================
[ 0] 0x180229e40 str=0x180221c04 'active' val=1 (0x1)
[ 1] 0x180229e50 str=0x18022a360 'inactive' val=2 (0x2)
[ 2] 0x180229e60 str=0x18022a370 'expired' val=3 (0x3)
[ 3] 0x180229e70 str=0x18022a378 'closed' val=4 (0x4)
[ 4] 0x180229e80 str=0x0 '' val=0 (0x0)
[ 5] 0x180229e90 str=0x4e4f5f53544f4853 '' val=1380013151 (0x5241545f)
[ 6] 0x180229ea0 str=0x4653534543435553 '' val=1415531605 (0x545f4c55)
[ 7] 0x180229eb0 str=0x5345 '' val=1314017091 (0x4e524f43)
[ 8] 0x180229ec0 str=0x4548534e41454c43 '' val=5461061 (0x535445)
[ 9] 0x180229ed0 str=0x5f474e4953534150 '' val=1129465168 (0x43524550)
[10] 0x180229ee0 str=0x4547 '' val=1397968720 (0x53534f50)
[11] 0x180229ef0 str=0x45435245505f4e4f '' val=1195463758 (0x4741544e)
==============================================================================
== pointer arrays containing the sold vocabulary
==============================================================================
auctionSoldBid pointer found at: ['0x1802d2928']
auctionSoldBuyNow pointer found at: ['0x1802d2930']
auctionWonBuyNow pointer found at: ['0x1802d2940']
sold@22f524 pointer found at: ['0x1802d3da8']
sold@228bed pointer found at: NOWHERE
SoldFromTradePile pointer found at: NOWHERE
SOLD@20a0c7 pointer found at: NOWHERE
==============================================================================
== the .data array around 0x1802d3da8 (the one DATA xref to 'sold')
==============================================================================
0x1802d3d68 -> 0x1801e98ac 'shots'
0x1802d3d70 -> 0x18022f4c8 'shotsOnTarget'
0x1802d3d78 -> 0x18022f4d8 'silhouetteName'
0x1802d3d80 -> 0x18022f4e8 'silName'
0x1802d3d88 -> 0x1801ec108 'silver'
0x1802d3d90 -> 0x18022f4f0 'silverQuantity'
0x1802d3d98 -> 0x18022f500 'sizeBeforeEncode'
0x1802d3da0 -> 0x18022f518 'slotIndex'
0x1802d3da8 -> 0x18022f524 'sold' <<<
0x1802d3db0 -> 0x18022f52c 'sort'
0x1802d3db8 -> 0x18022f538 'sortPriority'
0x1802d3dc0 -> 0x18022ed30 'source'
0x1802d3dc8 -> 0x18022f548 'squad'
0x1802d3dd0 -> 0x18022f550 'squadActives'
0x1802d3dd8 -> 0x18022f560 'squadBuildingSetsClientData'
0x1802d3de0 -> 0x18022f580 'squadBuildingSetsGracePeriodMinutes'
0x1802d3de8 -> 0x18022f5a8 'squadChallenge'
0x1802d3df0 -> 0x18022f5b8 'squadId'
0x1802d3df8 -> 0x18022f5c0 'squadName'
0x1802d3e00 -> 0x18022f5d0 'squadList'
docs/evidence/market-sold-re-2026-08-17/q_sold_3.py
-68
View File
@@ -1,68 +0,0 @@
"""Q3 — full route table, the itemState/tradeState enum tables, and the pointer
arrays that reference the auctionSold* vocabulary and the bare 'sold' string.
"""
import struct
print("=" * 78)
print("== route table continued from 0x18021e0f8 until it stops looking like one")
print("=" * 78)
a = 0x18021E100
misses = 0
while a < 0x18021E400 and misses < 6:
p = qword(a)
s = rd_str(p, 120) if 0x180000000 < p < 0x180400000 else ""
if s and s.isprintable():
print(f" 0x{a:x} -> 0x{p:x} {s!r}")
misses = 0
else:
misses += 1
a += 8
print()
print("=" * 78)
print("== itemState table 0x180229cc0 (prior work: 12 rows) — dump generously")
print("=" * 78)
for i in range(20):
ea = 0x180229CC0 + i * 16
p, v = qword(ea), dword(ea + 8)
s = rd_str(p, 40) if 0x180000000 < p < 0x180400000 else ""
print(f" [{i:2d}] 0x{ea:x} str=0x{p:x} {s!r:24s} val={v} (0x{v:x})")
print()
print("=" * 78)
print("== tradeState table 0x180229e40 — dump generously")
print("=" * 78)
for i in range(12):
ea = 0x180229E40 + i * 16
p, v = qword(ea), dword(ea + 8)
s = rd_str(p, 40) if 0x180000000 < p < 0x180400000 else ""
print(f" [{i:2d}] 0x{ea:x} str=0x{p:x} {s!r:24s} val={v} (0x{v:x})")
print()
print("=" * 78)
print("== pointer arrays containing the sold vocabulary")
print("=" * 78)
for label, target in (("auctionSoldBid", 0x1802302C8),
("auctionSoldBuyNow", 0x1802302D8),
("auctionWonBuyNow", 0x180230300),
("sold@22f524", 0x18022F524),
("sold@228bed", 0x180228BED),
("SoldFromTradePile", 0x1801EFAF1),
("SOLD@20a0c7", 0x18020A0C7)):
pat = struct.pack("<Q", target)
hits = find_all(pat, blocks=(".rdata", ".data", ".text"))
print(f" {label:20s} pointer found at: {[hex(h) for h in hits] or 'NOWHERE'}")
print()
print("=" * 78)
print("== the .data array around 0x1802d3da8 (the one DATA xref to 'sold')")
print("=" * 78)
for i in range(-8, 12):
ea = 0x1802D3DA8 + i * 8
try:
p = qword(ea)
except Exception:
continue
s = rd_str(p, 50) if 0x180000000 < p < 0x180400000 else ""
mark = " <<<" if i == 0 else ""
print(f" 0x{ea:x} -> 0x{p:x} {s!r}{mark}")
docs/evidence/market-sold-re-2026-08-17/q_sold_4.py
-67
View File
@@ -1,67 +0,0 @@
"""Q4 — is the atom ID the index into the alphabetical atom-name pointer table?
Validate against the twelve KNOWN auctionInfo atoms. If all twelve agree on one
base, the table is the atom dictionary and we can read the ID of any name.
"""
import struct
KNOWN = { # atom id -> name, from the confirmed auctionInfo deserializer
0x57: "bidState", 0x65: "buyNowPrice", 0xC1: "currentBid", 0x116: "expires",
0x16B: "itemData", 0x2B6: "sellerEstablished", 0x2B7: "sellerName",
0x2E6: "startingBid", 0x2F4: "coinsProcessed", 0x331: "tradeId",
0x335: "tradeState", 0x380: "watched",
}
def str_addr(name):
"""Address of the exact NUL-terminated string `name`."""
for h in find_all(name.encode() + b"\x00", blocks=(".rdata", ".data")):
return h
return None
def ptr_addr(sa):
hits = find_all(struct.pack("<Q", sa), blocks=(".rdata", ".data"))
return hits[0] if hits else None
print("=" * 78)
print("== solve for the table base using the twelve known atoms")
print("=" * 78)
bases = {}
for aid, name in sorted(KNOWN.items()):
sa = str_addr(name)
pa = ptr_addr(sa) if sa else None
if pa is None:
print(f" 0x{aid:03x} {name:20s} string=0x{sa or 0:x} pointer=NOT FOUND")
continue
base = pa - 8 * aid
bases[base] = bases.get(base, 0) + 1
print(f" 0x{aid:03x} {name:20s} str=0x{sa:x} ptr=0x{pa:x} -> base 0x{base:x}")
print()
print(" base histogram:", {hex(b): n for b, n in sorted(bases.items(), key=lambda kv: -kv[1])})
if not bases:
raise SystemExit("no bases resolved")
BASE = max(bases, key=bases.get)
print(f" CONSENSUS BASE = 0x{BASE:x} ({bases[BASE]}/{len(KNOWN)} atoms agree)")
print()
print("=" * 78)
print("== read the atom id of every sold/counts-related name")
print("=" * 78)
for name in ("sold", "selling", "offered", "count", "maxAuctionsAllowed",
"auctionSoldBid", "auctionSoldBuyNow", "auctionWonBid",
"auctionWonBuyNow", "auctionLostOutbid", "auctionLostOutbidSelf",
"auctionLostBidRejected", "credits", "coins", "tradeIdStr",
"itemState", "offers", "bids", "watched", "expires"):
sa = str_addr(name)
pa = ptr_addr(sa) if sa else None
if pa is None:
print(f" {name:24s} ABSENT from the table")
continue
off = pa - BASE
if off % 8:
print(f" {name:24s} ptr=0x{pa:x} misaligned (off {off})")
continue
print(f" {name:24s} ptr=0x{pa:x} ATOM ID = 0x{off // 8:x} ({off // 8})")
docs/evidence/market-sold-re-2026-08-17/q_sold_5.out
-80
View File
@@ -1,80 +0,0 @@
==============================================================================
== atom ids, resolved against the table range only
==============================================================================
sold str=0x18022f524 ptr=0x1802d3da8 ATOM ID = 0x2c9 (713)
count str=0x180230abc ptr=0x1802d2d40 ATOM ID = 0xbc (188)
offered str=0x18022a2d8 ptr=0x1802d3688 ATOM ID = 0x1e5 (485)
selling str=0x18022f460 ptr=0x1802d3d20 ATOM ID = 0x2b8 (696)
maxAuctionsAllowed str=0x1802318a8 ptr=0x1802d3558 ATOM ID = 0x1bf (447)
credits str=0x180230af8 ptr=0x1802d2d60 ATOM ID = 0xc0 (192)
auctionInfo str=0x180230270 ptr=0x1802d2908 ATOM ID = 0x35 (53)
itemData str=0x180231438 ptr=0x1802d32b8 ATOM ID = 0x16b (363)
bidState str=0x180230458 ptr=0x1802d2a18 ATOM ID = 0x57 (87)
tradeState str=0x18022fb48 ptr=0x1802d4108 ATOM ID = 0x335 (821)
coinsProcessed str=0x18022f768 ptr=0x1802d3f00 ATOM ID = 0x2f4 (756)
offers str=0x180231ae4 ptr=0x1802d3690 ATOM ID = 0x1e6 (486)
duplicateItemIdList str=0x180230d18 ptr=0x1802d2ec0 ATOM ID = 0xec (236)
total str=0x18022fa4c ptr=0x1802d4088 ATOM ID = 0x325 (805)
==============================================================================
== functions that compare against >=3 of the auction-outcome atoms 0x36..0x3c
==============================================================================
scanned 13308 functions
0x180043b90 FUN_180043b90 sees ['0x36', '0x37', '0x38', '0x3c']
0x1800455b0 FUN_1800455b0 sees ['0x37', '0x38', '0x39']
0x18006b4c0 FUN_18006b4c0 sees ['0x38', '0x39', '0x3c']
0x180094ce0 FUN_180094ce0 sees ['0x36', '0x37', '0x38']
0x180097c70 FUN_180097c70 sees ['0x36', '0x37', '0x38']
0x1800cabb0 FUN_1800cabb0 sees ['0x38', '0x39', '0x3a']
0x1800cf3b0 FUN_1800cf3b0 sees ['0x36', '0x38', '0x3a', '0x3c']
0x1800e6410 FUN_1800e6410 sees ['0x36', '0x37', '0x38', '0x39']
0x1800ee7c0 FUN_1800ee7c0 sees ['0x36', '0x37', '0x38', '0x39', '0x3a', '0x3c']
0x1800fb5b0 FUN_1800fb5b0 sees ['0x38', '0x39', '0x3a', '0x3b']
0x1801071f0 FUN_1801071f0 sees ['0x36', '0x37', '0x38', '0x3a', '0x3b', '0x3c']
0x18012b370 FUN_18012b370 sees ['0x36', '0x37', '0x38', '0x39', '0x3a', '0x3b', '0x3c']
0x18012fd40 FUN_18012fd40 sees ['0x36', '0x37', '0x38', '0x3c']
0x18013fe00 FUN_18013fe00 sees ['0x36', '0x38', '0x3a', '0x3b']
0x180163770 FUN_180163770 sees ['0x36', '0x38', '0x3a']
0x180172d00 FUN_180172d00 sees ['0x38', '0x3a', '0x3c']
==============================================================================
== string neighbourhoods: SoldFromTradePile / SOLD / sold
==============================================================================
-- SoldFromTradePile
0x1801efa40 'CardsRequestStaffBonuses'
0x1801efa60 'CardsGetStaffBonuses'
0x1801efa78 'WatchListRequest'
0x1801efa90 'WatchListResultsRequest'
0x1801efaa8 'AddToWatchList'
0x1801efab8 'RemoveFromWatchList'
0x1801efad0 'RemoveFromTradePile'
0x1801efae8 'RemoveAllSoldFromTradePile'
0x1801efb08 'GetPhishingQuestion'
0x1801efb20 'SetPhishingAnswer'
0x1801efb38 'ValidatePhishingAnswer'
0x1801efb50 'RetrieveTrustedConsoleList'
0x1801efb70 'EnableLiveStreaming'
-- SOLD
0x18020a040 'D_PRIZES'
0x18020a050 'EVENT_ID'
0x18020a05c 'TEXT0'
0x18020a068 'FUT_UC_SQUAD'
0x18020a078 'TEXT1'
0x18020a080 'FUT_TOTAL_AUCTIONS'
0x18020a098 'FUT_UC_ITEMS'
0x18020a0a8 'FUT_TF_SELLING'
0x18020a0b8 'TEXT2'
0x18020a0c0 'FUT_TF_SOLD'
0x18020a0cc 'TEXT3'
0x18020a0d8 'FUT_TF_WINNING'
0x18020a0e8 'FUT_TF_OUTBID'
0x18020a0f8 'FUT_GH_TOTAL_PLAYERS_0'
0x18020a110 'FUT_GH_TOTAL_PLAYERS_1'
0x18020a128 'FUT_GH_TOP_SCORER'
-- sold@228bed
0x180228bc8 'RS4:FutISRemoveTradeServerResponse'
0x180228bec '/sold'
0x180228c00 '\\�&'
0x180228c11 "�'"
0x180228c28 "X�'"
0x180228c38 "`�'"
docs/evidence/market-sold-re-2026-08-17/q_sold_5.py
-83
View File
@@ -1,83 +0,0 @@
"""Q5 — fix the atom lookup, then find the CONSUMER of atoms 0x36..0x3c
(auctionLost*/auctionSold*/auctionWon*) and read the sold-related string
neighbourhoods.
"""
import struct
BASE = 0x1802D2760
TABLE_LO, TABLE_HI = 0x1802D2760, 0x1802D4800
def atom_id(name):
"""Every string with this exact spelling, then the pointer that lies INSIDE
the atom table. Taking the first string match is wrong: common words appear
in several unrelated tables."""
out = []
for sa in find_all(name.encode() + b"\x00", blocks=(".rdata", ".data")):
for pa in find_all(struct.pack("<Q", sa), blocks=(".rdata", ".data")):
if TABLE_LO <= pa < TABLE_HI and (pa - BASE) % 8 == 0:
out.append((sa, pa, (pa - BASE) // 8))
return out
print("=" * 78)
print("== atom ids, resolved against the table range only")
print("=" * 78)
for name in ("sold", "count", "offered", "selling", "maxAuctionsAllowed",
"credits", "auctionInfo", "itemData", "bidState", "tradeState",
"coinsProcessed", "offers", "duplicateItemIdList", "total"):
res = atom_id(name)
if not res:
print(f" {name:22s} ABSENT from the atom table")
for sa, pa, aid in res:
print(f" {name:22s} str=0x{sa:x} ptr=0x{pa:x} ATOM ID = 0x{aid:x} ({aid})")
print()
print("=" * 78)
print("== functions that compare against >=3 of the auction-outcome atoms 0x36..0x3c")
print("=" * 78)
WANT = set(range(0x36, 0x3D))
hits = {}
fi = fm.getFunctions(True)
n = 0
for f in fi:
n += 1
ent = int(f.getEntryPoint().getOffset())
body = f.getBody()
seen = set()
it = listing.getInstructions(body, True)
while it.hasNext():
ins = it.next()
m = ins.getMnemonicString()
if m not in ("CMP", "SUB", "MOV", "LEA"):
continue
for i in range(ins.getNumOperands()):
for o in ins.getOpObjects(i):
try:
v = int(o.getValue())
except Exception:
continue
if v in WANT:
seen.add(v)
if len(seen) >= 3:
hits[ent] = (f.getName(), sorted(hex(v) for v in seen))
print(f" scanned {n} functions")
for ent, (nm, vals) in sorted(hits.items()):
print(f" 0x{ent:x} {nm:28s} sees {vals}")
print()
print("=" * 78)
print("== string neighbourhoods: SoldFromTradePile / SOLD / sold")
print("=" * 78)
for label, lo, hi in (("SoldFromTradePile", 0x1801EFA40, 0x1801EFB80),
("SOLD", 0x18020A040, 0x18020A140),
("sold@228bed", 0x180228B60, 0x180228C60)):
print(f"-- {label}")
a = lo
while a < hi:
s = rd_str(a, 70)
if s and len(s) > 1 and s.isprintable():
print(f" 0x{a:x} {s!r}")
a += len(s.encode()) + 1
else:
a += 1
docs/evidence/market-sold-re-2026-08-17/q_sold_6.out
-469
View File
@@ -1,469 +0,0 @@
==============================================================================
== (a) xrefs: request names + the /sold path suffix
==============================================================================
RemoveAllSoldFromTradePile 1 xref(s)
0x1800293fe DATA in FUN_180028b50 (entry 0x180028b50)
RemoveFromTradePile 1 xref(s)
0x1800293d4 DATA in FUN_180028b50 (entry 0x180028b50)
AddToWatchList 1 xref(s)
0x180029380 DATA in FUN_180028b50 (entry 0x180028b50)
/sold suffix 1 xref(s)
0x180164813 DATA in FUN_1801647c0 (entry 0x1801647c0)
RS4:FutISRemoveTradeServerResponse 2 xref(s)
0x1801defe9 DATA in Unwind@1801defd0 (entry 0x1801defd0)
0x18016488d DATA in FUN_180164860 (entry 0x180164860)
==============================================================================
== (b) xrefs: the Transfer List caption keys
==============================================================================
FUT_TOTAL_AUCTIONS 1 xref(s)
0x1800b1ef8 DATA in FUN_1800b1dc0 (entry 0x1800b1dc0)
FUT_UC_ITEMS 4 xref(s)
0x1800fbbdc DATA in FUN_1800fbae0 (entry 0x1800fbae0)
0x1800fbe5a DATA in FUN_1800fbae0 (entry 0x1800fbae0)
0x1800b1fe7 DATA in FUN_1800b1dc0 (entry 0x1800b1dc0)
0x1800b21a9 DATA in FUN_1800b1dc0 (entry 0x1800b1dc0)
FUT_TF_SELLING 1 xref(s)
0x1800b2023 DATA in FUN_1800b1dc0 (entry 0x1800b1dc0)
FUT_TF_SOLD 1 xref(s)
0x1800b208e DATA in FUN_1800b1dc0 (entry 0x1800b1dc0)
FUT_TF_WINNING 1 xref(s)
0x1800b21e5 DATA in FUN_1800b1dc0 (entry 0x1800b1dc0)
FUT_TF_OUTBID 1 xref(s)
0x1800b2250 DATA in FUN_1800b1dc0 (entry 0x1800b1dc0)
caption publisher candidates (entry -> #caption refs): {'0x1800b1dc0': 7, '0x1800fbae0': 2}
==============================================================================
== decompiled caption publisher 0x1800b1dc0
==============================================================================
void FUN_1800b1dc0(undefined8 param_1,longlong *param_2)
{
char cVar1;
undefined8 uVar2;
longlong lVar3;
longlong *plVar4;
ushort uVar5;
longlong *local_res10;
undefined1 *local_90;
undefined1 *local_88;
undefined1 *local_80;
longlong *local_78;
undefined4 local_70;
char *local_68;
undefined1 *local_60;
undefined1 *local_58;
undefined1 *local_50;
longlong *local_48;
undefined4 local_40;
char *local_38;
uVar2 = FUN_1800d7170();
FUN_180009c80(&local_res10,uVar2);
lVar3 = (**(code **)(*local_res10 + 0x1f8))(local_res10);
local_78 = (longlong *)FUN_1800d7370();
local_70 = 1;
local_68 = "FUT String";
local_90 = &DAT_1802e13a0;
local_88 = &DAT_1802e13a0;
local_80 = &DAT_1802e13a1;
local_48 = (longlong *)FUN_1800d7370();
local_40 = 1;
local_38 = "FUT String";
local_60 = &DAT_1802e13a0;
local_58 = &DAT_1802e13a0;
local_50 = &DAT_1802e13a1;
(**(code **)(*param_2 + 0x58))(param_2,4);
(**(code **)(*param_2 + 0x78))(param_2,0,"UPDATE_TYPE",PTR_s_PANEL_UPDATE_1802a4fb0);
(**(code **)(*param_2 + 0x70))(param_2,0,"TILE_ID",0x1b0);
(**(code **)(*param_2 + 0x70))(param_2,0,"ADDON_ENUM",5);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 0xb8))(plVar4,&local_90,*(undefined4 *)(lVar3 + 0x38));
(**(code **)(*param_2 + 0x78))(param_2,0,"TEXT0",local_90);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 400))(plVar4,&local_90,"FUT_TOTAL_AUCTIONS",1);
(**(code **)(*param_2 + 0x78))(param_2,0,"TEXT1",local_90);
(**(code **)(*param_2 + 0x78))(param_2,1,"UPDATE_TYPE",PTR_s_PANEL_UPDATE_1802a4fb0);
(**(code **)(*param_2 + 0x70))(param_2,1,"TILE_ID",0x1c0);
uVar5 = *(ushort *)(lVar3 + 0x1d6);
if (0x62 < uVar5) {
uVar5 = 99;
}
(**(code **)(*param_2 + 0x70))(param_2,1,"NOTIFICATION",uVar5);
(**(code **)(*param_2 + 0x70))(param_2,1,"ADDON_ENUM");
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 0xb8))(plVar4,&local_90,*(undefined2 *)(lVar3 + 0x1d4));
(**(code **)(*param_2 + 0x78))(param_2,1,"TEXT0",local_90);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 400))(plVar4,&local_90,"FUT_UC_ITEMS",1);
(**(code **)(*param_2 + 0x78))(param_2,1,"TEXT1",local_90);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 400))(plVar4,&local_90,"FUT_TF_SELLING",1);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 0xb8))(plVar4,&local_60,*(undefined2 *)(lVar3 + 0x1d2));
FUN_18000fbd0(&local_90,local_90,local_60);
(**(code **)(*param_2 + 0x78))(param_2,1,"TEXT2",local_90);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 400))(plVar4,&local_90,"FUT_TF_SOLD",1);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 0xb8))(plVar4,&local_60,*(undefined2 *)(lVar3 + 0x1d8));
FUN_18000fbd0(&local_90,local_90,local_60);
(**(code **)(*param_2 + 0x78))(param_2,1,"TEXT3",local_90);
(**(code **)(*param_2 + 0x78))(param_2,2,"UPDATE_TYPE",PTR_s_PANEL_UPDATE_1802a4fb0);
(**(code **)(*param_2 + 0x70))(param_2,2,"TILE_ID",0x1d0);
uVar5 = 99;
if (*(ushort *)(lVar3 + 0x1ce) < 99) {
uVar5 = *(ushort *)(lVar3 + 0x1ce);
}
(**(code **)(*param_2 + 0x70))(param_2,2,"NOTIFICATION",uVar5);
(**(code **)(*param_2 + 0x70))(param_2,2,"ADDON_ENUM");
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 0xb8))(plVar4,&local_90,*(undefined2 *)(lVar3 + 0x1ca));
(**(code **)(*param_2 + 0x78))(param_2,2,"TEXT0",local_90);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 400))(plVar4,&local_90,"FUT_UC_ITEMS",1);
(**(code **)(*param_2 + 0x78))(param_2,2,"TEXT1",local_90);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 400))(plVar4,&local_90,"FUT_TF_WINNING",1);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 0xb8))(plVar4,&local_60,*(undefined2 *)(lVar3 + 0x1c8));
FUN_18000fbd0(&local_90,local_90,local_60);
(**(code **)(*param_2 + 0x78))(param_2,2,"TEXT2",local_90);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 400))(plVar4,&local_90,"FUT_TF_OUTBID",1);
plVar4 = (longlong *)FUN_18019e320();
(**(code **)(*plVar4 + 0xb8))(plVar4,&local_60,*(undefined2 *)(lVar3 + 0x1cc));
FUN_18000fbd0(&local_90,local_90,local_60);
(**(code **)(*param_2 + 0x78))(param_2,2,"TEXT3",local_90);
uVar2 = FUN_1800264e0();
cVar1 = FUN_180026510(uVar2);
if (cVar1 == '\0') {
(**(code **)(*param_2 + 0x78))(param_2,3,"UPDATE_TYPE",PTR_s_PANEL_UPDATE_1802a4fb0);
(**(code **)(*param_2 + 0x70))(param_2,3,"TILE_ID",0x200);
(**(code **)(*param_2 + 0x70))(param_2,3,"ADDON_ENUM");
}
if ((1 < (longlong)local_50 - (longlong)local_60) && (local_60 != (undefined1 *)0x0)) {
(**(code **)(*local_48 + 0x18))(local_48,local_60,(int)local_50 - (int)local_60);
}
if ((1 < (longlong)local_80 - (longlong)local_90) && (local_90 != (undefined1 *)0x0)) {
(**(code **)(*local_78 + 0x18))(local_78,local_90,(int)local_80 - (int)local_90);
}
(**(code **)(*local_res10 + 8))(local_res10);
return;
}
==============================================================================
== decompiled caption publisher 0x1800fbae0
==============================================================================
/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */
/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */
uint FUN_1800fbae0(undefined8 param_1,undefined4 param_2,undefined8 *param_3)
{
undefined1 *puVar1;
longlong lVar2;
uint uVar3;
int iVar4;
longlong *plVar5;
undefined8 uVar6;
longlong *plVar7;
longlong lVar8;
size_t sVar9;
size_t sVar10;
undefined1 auStack_2e8 [32];
undefined4 local_2c8;
undefined1 local_2b8;
uint local_2b4;
undefined4 local_2b0;
undefined4 uStack_2ac;
undefined1 *local_2a8;
undefined1 *local_2a0;
undefined1 *local_298;
longlong *local_290;
undefined4 local_288;
char *local_280;
undefined1 *local_278;
undefined1 *local_270;
undefined1 *local_268;
longlong *local_260;
undefined4 local_258;
char *local_250;
undefined1 *local_248;
undefined1 *local_240;
undefined1 *local_238;
longlong *local_230;
undefined4 local_228;
char *local_220;
longlong local_218;
undefined8 local_210;
longlong local_208;
longlong *local_200;
undefined4 local_1f8;
char *local_1f0;
void *local_1e8;
longlong local_1e0;
longlong local_1d8;
longlong *local_1d0;
undefined8 local_1b8;
longlong *local_1a8;
undefined8 local_1a0;
undefined8 local_198;
undefined8 local_190;
undefined4 local_188;
undefined2 local_184;
undefined8 local_180;
undefined8 local_178;
undefined8 local_170;
undefined8 local_168;
undefined2 local_160;
undefined4 local_15c;
ulonglong local_158;
undefined8 uStack_150;
undefined4 local_148;
undefined2 local_144;
undefined4 local_140;
undefined **local_138;
undefined8 local_130;
undefined8 local_128;
undefined8 local_120;
undefined8 local_118;
undefined8 local_110;
undefined8 local_108;
undefined8 local_100;
undefined4 local_f8;
undefined2 local_f4;
undefined1 local_f2;
undefined1 local_f0 [168];
ulonglong local_48;
local_1b8 = 0xfffffffffffffffe;
local_48 = DAT_1802db6e0 ^ (ulonglong)auStack_2e8;
local_200 = (longlong *)FUN_1800d7370();
local_218 = 0;
local_208 = 0;
local_1f8 = 1;
local_1f0 = "FUT Vector";
FUN_18004fff0(0,0,local_2b8);
local_210 = 0;
local_2b0 = 0;
uVar3 = FUN_1800fb8c0(param_1,param_2,&local_218,&local_2b0);
if ((undefined1 *)*param_3 != (undefined1 *)param_3[1]) {
*(undefined1 *)*param_3 = 0;
param_3[1] = *param_3;
}
local_2b4 = uVar3;
local_260 = (longlong *)FUN_1800d7370();
lVar2 = local_218;
local_258 = 1;
local_250 = "FUT String";
local_278 = &DAT_1802e13a0;
local_270 = &DAT_1802e13a0;
local_268 = &DAT_1802e13a1;
if (uVar3 < 2) {
if (uVar3 == 1) {
local_1a8 = (longlong *)0x0;
local_1a0 = 0;
local_198 = 0;
local_190 = 0;
local_188 = 0;
local_184 = 0;
local_180 = 0;
local_178 = 0;
local_170 = 0;
local_168 = 0;
local_160 = 0x100;
lVar8 = -1;
local_15c = 0xffffffff;
local_158 = _DAT_1801f66a0;
uStack_150 = _UNK_1801f66a8;
local_148 = 0;
local_144 = 0;
local_140 = 0;
local_130 = 0;
local_138 = &PTR_LAB_1801eaac0;
local_128 = 0;
local_120 = 0;
local_118 = 0;
local_f4 = 0;
local_f2 = 0;
local_110 = 0;
local_108 = 0;
local_100 = 0;
local_f8 = 0;
memset(local_f0,0,0xa0);
local_190 = CONCAT44(local_190._4_4_,*(undefined4 *)(lVar2 + 4)) & 0xffffffff00ffffff;
FUN_1801362e0(&local_1a8);
FUN_180141660(&local_1a8);
uVar6 = FUN_1800d7170();
FUN_180009c80(&local_2b0,uVar6);
plVar5 = (longlong *)CONCAT44(uStack_2ac,local_2b0);
local_2c8 = (undefined4)local_190;
(**(code **)(*plVar5 + 0x490))(plVar5,&local_1e8,local_15c,local_158 & 0xffffffff);
sVar10 = local_1e0 - (longlong)local_1e8;
sVar9 = sVar10;
if (0 < (longlong)sVar10) {
sVar9 = 0;
}
iVar4 = memcmp(local_1e8,&DAT_1801e9caf,sVar9);
if (((iVar4 == 0) && (-1 < (longlong)sVar10)) && ((longlong)sVar10 < 1)) {
local_230 = (longlong *)FUN_1800d7370();
local_228 = 1;
local_220 = "FUT String";
local_248 = &DAT_1802e13a0;
local_240 = &DAT_1802e13a0;
local_238 = &DAT_1802e13a1;
local_290 = (longlong *)FUN_1800d7370();
local_288 = 1;
local_280 = "FUT String";
local_2a8 = &DAT_1802e13a0;
local_2a0 = &DAT_1802e13a0;
local_298 = &DAT_1802e13a1;
FUN_18000fbd0(&local_248,"AWARD_LABEL_%i",*(undefined4 *)(lVar2 + 8));
plVar7 = (longlong *)FUN_18019e320();
puVar1 = local_248;
(**(code **)(*plVar7 + 400))(plVar7,&local_2a8,local_248,1);
sVar10 = (longlong)local_2a0 - (longlong)local_2a8;
sVar9 = sVar10;
if (0 < (longlong)sVar10) {
sVar9 = 0;
}
iVar4 = memcmp(local_2a8,&DAT_1801e9caf,sVar9);
if (((iVar4 == 0) && (-1 < (longlong)sVar10)) && ((longlong)sVar10 < 1)) {
plVar7 = (longlong *)FUN_18019e320();
(**(code **)(*plVar7 + 400))(plVar7,&local_2a8,"FUT_UC_ITEMS",1);
}
FUN_18000fbd0(param_3,&DAT_18021940c,*(undefined4 *)(lVar2 + 0xc));
do {
lVar8 = lVar8 + 1;
} while (local_2a8[lVar8] != '\0');
FUN_18000f650(param_3,local_2a8,local_2a8 + lVar8);
if (1 < (longlong)local_298 - (longlong)local_2a8) {
if (local_2a8 != (undefined1 *)0x0) {
(**(code **)(*local_290 + 0x18))(local_290,local_2a8,(int)local_298 - (int)local_2a8);
}
}
if (1 < (longlong)local_238 - (longlong)puVar1) {
if (puVar1 != (undefined1 *)0x0) {
(**(code **)(*local_230 + 0x18))(local_230,puVar1,(int)local_238 - (int)local_248);
}
}
}
else {
FUN_18000fbd0(param_3,&DAT_18021940c,*(undefined4 *)(lVar2 + 0xc));
do {
lVar8 = lVar8 + 1;
} while (*(char *)((longlong)local_1e8 + lVar8) != '\0');
FUN_18000f650(param_3,local_1e8,(longlong)local_1e8 + lVar8);
}
if ((1 < local_1d8 - (longlong)local_1e8) && (local_1e8 != (void *)0x0)) {
(**(code **)(*local_1d0 + 0x18))(local_1d0,local_1e8,(int)local_1d8 - (int)local_1e8);
}
(**(code **)(*plVar5 + 8))(plVar5);
FUN_18000a3c0(&local_138);
plVar5 = local_1a8;
while (uVar3 = local_2b4, plVar5 != (longlong *)0x0) {
plVar7 = (longlong *)plVar5[1];
(**(code **)(*plVar5 + 8))();
plVar5 = plVar7;
}
}
}
else {
plVar5 = (longlong *)FUN_18019e320();
(**(code **)(*plVar5 + 400))(plVar5,&local_278,"FUT_UC_ITEMS",1);
FUN_18000fbd0(param_3,"%i %s",local_2b0,local_278);
}
if (1 < (longlong)local_268 - (longlong)local_278) {
if (local_278 != (undefined1 *)0x0) {
(**(code **)(*local_260 + 0x18))(local_260,local_278,(int)local_268 - (int)local_278);
}
}
FUN_18004fff0(lVar2,local_210,local_2b8);
if (lVar2 != 0) {
(**(code **)(*local_200 + 0x18))(local_200,lVar2,((local_208 - lVar2) / 0x38) * 0x38);
}
return uVar3;
}
==============================================================================
== (c) GetAuctionCount deserializer FUN_180163770
==============================================================================
/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */
undefined8 FUN_180163770(undefined8 param_1,undefined8 *param_2)
{
undefined2 uVar1;
int iVar2;
undefined4 uVar3;
undefined8 uVar4;
longlong *plVar5;
longlong lVar6;
undefined1 auStack_168 [32];
int local_148 [2];
undefined8 local_140;
undefined1 local_138 [288];
ulonglong local_18;
local_140 = 0xfffffffffffffffe;
local_18 = DAT_1802db6e0 ^ (ulonglong)auStack_168;
FUN_1801c63e0(local_138,0,0);
local_148[0] = 0x38c;
uVar4 = FUN_180008130(*param_2);
FUN_1801c8270(local_138,*param_2,uVar4,0);
FUN_1801c7f10(local_138);
FUN_1801c7f10(local_138);
plVar5 = (longlong *)FUN_18011a830();
lVar6 = (**(code **)(*plVar5 + 0x130))(plVar5);
*(undefined4 *)(lVar6 + 0x30) = 0xffffffff;
*(undefined8 *)(lVar6 + 0x34) = 0;
iVar2 = FUN_1801c7f10(local_138);
while (iVar2 != 10) {
iVar2 = FUN_180141ee0(local_148,local_138);
if (iVar2 != 6) {
if (local_148[0] == 0xbc) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x34) = uVar1;
}
else if (local_148[0] == 0x1bf) {
uVar4 = FUN_1801c79d0(local_138);
uVar3 = FUN_1800d7af0(uVar4);
*(undefined4 *)(lVar6 + 0x30) = uVar3;
}
else if (local_148[0] == 0x1e5) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x3a) = uVar1;
}
else if (local_148[0] == 0x2b8) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x36) = uVar1;
}
else if (local_148[0] == 0x2c9) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x38) = uVar1;
}
else {
FUN_180135ff0(local_148[0],local_138);
}
}
iVar2 = FUN_1801c7f10(local_138);
}
*(undefined1 *)(lVar6 + 0x28) = 1;
FUN_1801c6560(local_138);
return 1;
}
docs/evidence/market-sold-re-2026-08-17/q_sold_6.py
-51
View File
@@ -1,51 +0,0 @@
"""Q6 — the decisive reads:
(a) who builds the /sold request (clear-all-sold) and what it is called;
(b) who publishes FUT_TF_SELLING / FUT_TF_SOLD / FUT_TF_WINNING / FUT_TF_OUTBID,
i.e. which count feeds the seller's SOLD bucket;
(c) the GetAuctionCount deserializer, to pin the five counts atoms.
"""
print("=" * 78)
print("== (a) xrefs: request names + the /sold path suffix")
print("=" * 78)
for label, a in (("RemoveAllSoldFromTradePile", 0x1801EFAE8),
("RemoveFromTradePile", 0x1801EFAD0),
("AddToWatchList", 0x1801EFAA8),
("/sold suffix", 0x180228BEC),
("RS4:FutISRemoveTradeServerResponse", 0x180228BC8)):
xs = xrefs_to(a)
print(f" {label:36s} {len(xs)} xref(s)")
for x in xs[:10]:
print(f" 0x{x[0]:x} {x[1]:12s} in {x[2]} (entry 0x{x[3]:x})")
print()
print("=" * 78)
print("== (b) xrefs: the Transfer List caption keys")
print("=" * 78)
caps = (("FUT_TOTAL_AUCTIONS", 0x18020A080), ("FUT_UC_ITEMS", 0x18020A098),
("FUT_TF_SELLING", 0x18020A0A8), ("FUT_TF_SOLD", 0x18020A0C0),
("FUT_TF_WINNING", 0x18020A0D8), ("FUT_TF_OUTBID", 0x18020A0E8))
owners = {}
for label, a in caps:
xs = xrefs_to(a)
print(f" {label:20s} {len(xs)} xref(s)")
for x in xs[:10]:
print(f" 0x{x[0]:x} {x[1]:12s} in {x[2]} (entry 0x{x[3]:x})")
owners[x[3]] = owners.get(x[3], 0) + 1
print()
print(" caption publisher candidates (entry -> #caption refs):",
{hex(k): v for k, v in sorted(owners.items(), key=lambda kv: -kv[1])})
for ent in sorted(owners, key=lambda e: -owners[e])[:2]:
print()
print("=" * 78)
print(f"== decompiled caption publisher 0x{ent:x}")
print("=" * 78)
print(dec(ent))
print()
print("=" * 78)
print("== (c) GetAuctionCount deserializer FUN_180163770")
print("=" * 78)
print(dec(0x180163770))
docs/evidence/market-sold-re-2026-08-17/q_sold_7.out
-178
View File
@@ -1,178 +0,0 @@
==============================================================================
== (a) hub tradePile sub-deserializer 0x18013ead0
== atom ids of interest: count=0xbc notification=0x1da selling=0x2b8 sold=0x2c9
==============================================================================
undefined4 FUN_18013ead0(longlong param_1,longlong param_2,longlong param_3)
{
undefined2 uVar1;
int iVar2;
int iVar3;
undefined8 uVar4;
iVar3 = 0x38c;
iVar2 = FUN_1801c7f10(param_3);
do {
if (iVar2 == 10) {
*(undefined1 *)(param_1 + 0x1da) = 1;
return 10;
}
if (*(int *)(param_3 + 0xd0) == 0xb) {
iVar3 = FUN_180180d00(*(undefined8 *)(param_3 + 0xf8));
iVar2 = FUN_1801c7f10(param_3);
if (iVar2 != 6) goto LAB_18013eb2e;
}
else {
LAB_18013eb2e:
if (iVar3 == 0xbc) {
uVar4 = FUN_1801c79d0(param_3);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(param_1 + 0x1d4) = uVar1;
}
else if (iVar3 == 0x1da) {
uVar4 = FUN_1801c79d0(param_3);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(param_1 + 0x1d6) = uVar1;
}
else if (iVar3 == 0x2b8) {
uVar4 = FUN_1801c79d0(param_3);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(param_1 + 0x1d2) = uVar1;
uVar4 = FUN_1801c79d0(param_3);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(param_2 + 0x36) = uVar1;
}
else if (iVar3 == 0x2c9) {
uVar4 = FUN_1801c79d0(param_3);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(param_1 + 0x1d8) = uVar1;
}
else {
FUN_180135ff0(iVar3,param_3);
}
}
iVar2 = FUN_1801c7f10(param_3);
} while( true );
}
==============================================================================
== (b) /sold request builder 0x1801647c0
==============================================================================
/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */
void FUN_1801647c0(longlong param_1,undefined8 param_2,undefined4 param_3)
{
undefined1 auStack_58 [32];
undefined1 local_38;
undefined8 local_37;
undefined8 local_2f;
undefined8 local_27;
undefined4 local_1f;
undefined2 local_1b;
undefined1 local_19;
ulonglong local_18;
local_18 = DAT_1802db6e0 ^ (ulonglong)auStack_58;
local_38 = 0;
local_37 = 0;
local_2f = 0;
local_27 = 0;
local_1f = 0;
local_1b = 0;
local_19 = 0;
if (*(longlong *)(param_1 + 0x10) == 0) {
FUN_180007f80(&local_38,0x20,"/sold");
}
else {
FUN_180007f80(&local_38,0x20,"/%lld");
}
FUN_180008100(param_2,&local_38,param_3);
return;
}
==============================================================================
== (c) FutGetAuctionCount deserializer 0x180163770
==============================================================================
/* WARNING: Function: __security_check_cookie replaced with injection: security_check_cookie */
undefined8 FUN_180163770(undefined8 param_1,undefined8 *param_2)
{
undefined2 uVar1;
int iVar2;
undefined4 uVar3;
undefined8 uVar4;
longlong *plVar5;
longlong lVar6;
undefined1 auStack_168 [32];
int local_148 [2];
undefined8 local_140;
undefined1 local_138 [288];
ulonglong local_18;
local_140 = 0xfffffffffffffffe;
local_18 = DAT_1802db6e0 ^ (ulonglong)auStack_168;
FUN_1801c63e0(local_138,0,0);
local_148[0] = 0x38c;
uVar4 = FUN_180008130(*param_2);
FUN_1801c8270(local_138,*param_2,uVar4,0);
FUN_1801c7f10(local_138);
FUN_1801c7f10(local_138);
plVar5 = (longlong *)FUN_18011a830();
lVar6 = (**(code **)(*plVar5 + 0x130))(plVar5);
*(undefined4 *)(lVar6 + 0x30) = 0xffffffff;
*(undefined8 *)(lVar6 + 0x34) = 0;
iVar2 = FUN_1801c7f10(local_138);
while (iVar2 != 10) {
iVar2 = FUN_180141ee0(local_148,local_138);
if (iVar2 != 6) {
if (local_148[0] == 0xbc) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x34) = uVar1;
}
else if (local_148[0] == 0x1bf) {
uVar4 = FUN_1801c79d0(local_138);
uVar3 = FUN_1800d7af0(uVar4);
*(undefined4 *)(lVar6 + 0x30) = uVar3;
}
else if (local_148[0] == 0x1e5) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x3a) = uVar1;
}
else if (local_148[0] == 0x2b8) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x36) = uVar1;
}
else if (local_148[0] == 0x2c9) {
uVar4 = FUN_1801c79d0(local_138);
uVar1 = FUN_1800d7b10(uVar4);
*(undefined2 *)(lVar6 + 0x38) = uVar1;
}
else {
FUN_180135ff0(local_148[0],local_138);
}
}
iVar2 = FUN_1801c7f10(local_138);
}
*(undefined1 *)(lVar6 + 0x28) = 1;
FUN_1801c6560(local_138);
return 1;
}
==============================================================================
== callers of the hub tradePile sub-deserializer (which response embeds it)
==============================================================================
0x180139610 FUN_180139610
docs/evidence/market-sold-re-2026-08-17/q_sold_7.py
-31
View File
@@ -1,31 +0,0 @@
"""Q7 — close it:
(a) hub tradePile sub-deserializer 0x18013ead0: which ATOM writes +0x1d8 (the
offset the FUT_TF_SOLD caption reads)?
(b) the /sold request builder 0x1801647c0 — bulk clear, or per-trade?
(c) FutGetAuctionCount deserializer 0x180163770 — the five counts atoms.
"""
print("=" * 78)
print("== (a) hub tradePile sub-deserializer 0x18013ead0")
print("== atom ids of interest: count=0xbc notification=0x1da selling=0x2b8 sold=0x2c9")
print("=" * 78)
print(dec(0x18013EAD0))
print()
print("=" * 78)
print("== (b) /sold request builder 0x1801647c0")
print("=" * 78)
print(dec(0x1801647C0))
print()
print("=" * 78)
print("== (c) FutGetAuctionCount deserializer 0x180163770")
print("=" * 78)
print(dec(0x180163770))
print()
print("=" * 78)
print("== callers of the hub tradePile sub-deserializer (which response embeds it)")
print("=" * 78)
for a, n in callers(0x18013EAD0):
print(f" 0x{a:x} {n}")
docs/evidence/market-sold-re-2026-08-17/q_sold_8.py
-25
View File
@@ -1,25 +0,0 @@
"""Q8 — are atoms 0x36..0x3c (auctionLost*/auctionSold*/auctionWon*) real response
keys? If a deserializer dispatches on them, the server tells the client HOW an
auction concluded via its own atom, and bidState is not the carrier.
Signature of a genuine atom dispatcher: the SAME local compared against many atom
ids, with FUN_180135ff0 (value-SKIP) as the else, and FUN_1801c7f10 driving the loop.
"""
CANDIDATES = (0x18012B370, 0x1801071F0, 0x1800EE7C0, 0x1800FB5B0, 0x1800CF3B0)
for ent in CANDIDATES:
print("=" * 78)
print(f"== 0x{ent:x} callees include value-SKIP? "
f"{any(c[0] == 0x180135FF0 for c in callees(ent))}"
f" atom-loop? {any(c[0] == 0x1801C7F10 for c in callees(ent))}")
print("=" * 78)
body = dec(ent)
# Only print if it smells like an atom dispatcher, else just report.
if "FUN_180135ff0" in body or "FUN_1801c7f10" in body:
print(body[:6000])
else:
print(" NOT an atom dispatcher (no value-SKIP, no atom loop) — small-immediate noise")
print(f" size {len(body)} chars; first 400:")
print(body[:400])
print()
docs/evidence/market-sold-re-2026-08-17/q_tax.out
-62
View File
@@ -1,62 +0,0 @@
==============================================================================
== localisation / string keys about tax, fee, net proceeds
==============================================================================
TAX (no printable hits)
tax (no printable hits)
Tax (no printable hits)
FEE 0x18023a3a8 'FEET_ATTEMPTED'
FEE 0x18023a3c0 'FEET_COMPLETED'
_FEE 0x18023a3a7 '_FEET_ATTEMPTED'
_FEE 0x18023a3bf '_FEET_COMPLETED'
fee (no printable hits)
NET 0x180209b1c 'NETOURNAMENT_0'
NET 0x180209b3c 'NETOURNAMENT_1'
NET 0x18020dd10 'NET'
_NET 0x18020dd0f '_NET'
RECEIVE 0x18023933f 'RECEIVER'
RECEIVE 0x180239350 'RECEIVER'
RECEIVE 0x18023983f 'RECEIVER'
RECEIVE 0x18023990d 'RECEIVER'
RECEIVE 0x180239a0b 'RECEIVER'
RECEIVE 0x18023a06f 'RECEIVED'
Receive (no printable hits)
PROCEEDS (no printable hits)
COMMISSION (no printable hits)
EA_TAX (no printable hits)
FUT_TF_ 0x18020a0a8 'FUT_TF_SELLING'
FUT_TF_ 0x18020a0c0 'FUT_TF_SOLD'
FUT_TF_ 0x18020a0d8 'FUT_TF_WINNING'
FUT_TF_ 0x18020a0e8 'FUT_TF_OUTBID'
AFTER_TAX (no printable hits)
earnings (no printable hits)
Earnings (no printable hits)
==============================================================================
== float constants 0.95 / 0.05 / 0.95f / 0.05f
==============================================================================
double 0.95 ABSENT
double 0.05 ABSENT
float 0.95f ABSENT
float 0.05f ABSENT
==============================================================================
== functions using BOTH 95 (or 5) and 100 as immediates — integer fee math
==============================================================================
17 candidate(s)
0x18000b5c0 FUN_18000b5c0 immediates [5, 100]
0x180051cd0 FUN_180051cd0 immediates [5, 20, 100]
0x180057b00 FUN_180057b00 immediates [5, 100]
0x180082c30 FUN_180082c30 immediates [5, 100]
0x180088cb0 FUN_180088cb0 immediates [5, 100]
0x1800a3cb0 FUN_1800a3cb0 immediates [5, 100]
0x1800a47b0 FUN_1800a47b0 immediates [5, 100]
0x1800d5050 FUN_1800d5050 immediates [5, 20, 100]
0x1800d5450 FUN_1800d5450 immediates [5, 20, 100]
0x1801129f0 FUN_1801129f0 immediates [5, 100]
0x18013af30 FUN_18013af30 immediates [5, 20, 100]
0x18013ec10 FUN_18013ec10 immediates [5, 100]
0x18013fe00 FUN_18013fe00 immediates [5, 100]
0x180147070 FUN_180147070 immediates [5, 100]
0x180180ea0 FUN_180180ea0 immediates [5, 100]
0x1801adae0 FUN_1801adae0 immediates [5, 100]
0x1801b9e60 FUN_1801b9e60 immediates [5, 100]
docs/evidence/market-sold-re-2026-08-17/q_tax.py
-69
View File
@@ -1,69 +0,0 @@
"""Task B — does FIFA17.exe itself compute the transfer fee / net proceeds?
If the list-item confirmation screen shows "you will receive N", the rounding rule
is IN THE BINARY and needs no live measurement. Look for:
* localisation keys mentioning tax/fee/net/receive
* float constants 0.95 / 0.05
* integer 95 or 5 used with 100 in the same function
"""
import struct
print("=" * 78)
print("== localisation / string keys about tax, fee, net proceeds")
print("=" * 78)
for needle in (b"TAX", b"tax", b"Tax", b"FEE", b"_FEE", b"fee", b"NET", b"_NET",
b"RECEIVE", b"Receive", b"PROCEEDS", b"COMMISSION", b"EA_TAX",
b"FUT_TF_", b"AFTER_TAX", b"earnings", b"Earnings"):
hits = find_all(needle, blocks=(".rdata", ".data"))
shown = 0
for h in hits:
s = rd_str(h, 70)
if s and len(s) > 2 and s.isprintable():
print(f" {needle.decode():10s} 0x{h:x} {s!r}")
shown += 1
if shown >= 12:
break
if not shown:
print(f" {needle.decode():10s} (no printable hits)")
print()
print("=" * 78)
print("== float constants 0.95 / 0.05 / 0.95f / 0.05f")
print("=" * 78)
for label, pat in (("double 0.95", struct.pack("<d", 0.95)),
("double 0.05", struct.pack("<d", 0.05)),
("float 0.95f", struct.pack("<f", 0.95)),
("float 0.05f", struct.pack("<f", 0.05))):
hits = find_all(pat, blocks=(".rdata", ".data"))
print(f" {label:12s} {[hex(h) for h in hits[:10]] or 'ABSENT'}")
for h in hits[:6]:
xs = xrefs_to(h)
for x in xs[:4]:
print(f" used at 0x{x[0]:x} in {x[2]} (entry 0x{x[3]:x})")
print()
print("=" * 78)
print("== functions using BOTH 95 (or 5) and 100 as immediates — integer fee math")
print("=" * 78)
found = []
for f in fm.getFunctions(True):
ent = int(f.getEntryPoint().getOffset())
vals = set()
it = listing.getInstructions(f.getBody(), True)
while it.hasNext():
ins = it.next()
if ins.getMnemonicString() not in ("IMUL", "MOV", "CMP", "ADD", "SUB", "LEA", "SHL"):
continue
for i in range(ins.getNumOperands()):
for o in ins.getOpObjects(i):
try:
v = int(o.getValue())
except Exception:
continue
if v in (95, 100, 5, 20):
vals.add(v)
if 100 in vals and (95 in vals or 5 in vals):
found.append((ent, f.getName(), sorted(vals)))
print(f" {len(found)} candidate(s)")
for ent, nm, vals in found[:40]:
print(f" 0x{ent:x} {nm:26s} immediates {vals}")
docs/evidence/route-shapes-2026-08-17/_index.json
-67
View File
@@ -1,67 +0,0 @@
{
"champion": {
"bytes": 2,
"path": "/ut/game/fifa17/champion",
"status": 200
},
"clubUser": {
"bytes": 2,
"path": "/ut/game/fifa17/clubUser",
"status": 200
},
"defid": {
"bytes": 600,
"path": "/ut/game/fifa17/defid?definitionId=200389",
"status": 200
},
"defs_resource": {
"bytes": 600,
"path": "/ut/game/fifa17/item/resource?resourceId=200389",
"status": 200
},
"draft_state": {
"bytes": 118,
"path": "/ut/game/fifa17/squad/mode/draft/state",
"status": 200
},
"marketdata": {
"bytes": 110,
"path": "/ut/game/fifa17/marketdata/pricelimits?defId=200389,200104",
"status": 200
},
"sbs_sets": {
"bytes": 537,
"path": "/ut/game/fifa17/sbs/sets",
"status": 200
},
"season": {
"bytes": 2,
"path": "/ut/game/fifa17/season",
"status": 200
},
"squad_0": {
"bytes": 7792,
"path": "/ut/game/fifa17/squad/0",
"status": 200
},
"tournament": {
"bytes": 2,
"path": "/ut/game/fifa17/tournament",
"status": 200
},
"user": {
"bytes": 751,
"path": "/ut/game/fifa17/user",
"status": 200
},
"user_list": {
"bytes": 2,
"path": "/ut/game/fifa17/user/list",
"status": 200
},
"watchList": {
"bytes": 52,
"path": "/ut/game/fifa17/watchList",
"status": 200
}
}
docs/evidence/route-shapes-2026-08-17/champion.json
-1
View File
@@ -1 +0,0 @@
{}
docs/evidence/route-shapes-2026-08-17/clubUser.json
-1
View File
@@ -1 +0,0 @@
{}
docs/evidence/route-shapes-2026-08-17/defid.json
-53
View File
@@ -1,53 +0,0 @@
{
"itemData": [
{
"assetId": 200389,
"attributeList": [
{
"index": 0,
"value": 70
},
{
"index": 1,
"value": 70
},
{
"index": 2,
"value": 70
},
{
"index": 3,
"value": 70
},
{
"index": 4,
"value": 70
},
{
"index": 5,
"value": 70
}
],
"cardType": 0,
"cardassetid": 200389,
"cardsubtypeid": 0,
"commodityId": 200389,
"commonName": "Player",
"definitionId": 200389,
"id": 200389,
"itemState": "free",
"itemType": "player",
"lastName": "Player",
"leagueId": 0,
"name": "Player",
"nation": 0,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 1,
"rating": 75,
"resourceId": 200389,
"teamid": 0,
"untradeable": true
}
]
}
docs/evidence/route-shapes-2026-08-17/defs_resource.json
-53
View File
@@ -1,53 +0,0 @@
{
"itemData": [
{
"assetId": 200389,
"attributeList": [
{
"index": 0,
"value": 70
},
{
"index": 1,
"value": 70
},
{
"index": 2,
"value": 70
},
{
"index": 3,
"value": 70
},
{
"index": 4,
"value": 70
},
{
"index": 5,
"value": 70
}
],
"cardType": 0,
"cardassetid": 200389,
"cardsubtypeid": 0,
"commodityId": 200389,
"commonName": "Player",
"definitionId": 200389,
"id": 200389,
"itemState": "free",
"itemType": "player",
"lastName": "Player",
"leagueId": 0,
"name": "Player",
"nation": 0,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 1,
"rating": 75,
"resourceId": 200389,
"teamid": 0,
"untradeable": true
}
]
}
docs/evidence/route-shapes-2026-08-17/draft_state.json
-9
View File
@@ -1,9 +0,0 @@
[
{
"gamesWonCurrentMatch": 0,
"roundsInfo": [],
"squadState": "INVALID",
"stateParam1": "INVALID",
"stateParam2": "0"
}
]
docs/evidence/route-shapes-2026-08-17/marketdata.json
-12
View File
@@ -1,12 +0,0 @@
[
{
"defId": 200389,
"maxPrice": 15000,
"minPrice": 150
},
{
"defId": 200104,
"maxPrice": 15000,
"minPrice": 150
}
]
docs/evidence/route-shapes-2026-08-17/sbs_sets.json
-35
View File
@@ -1,35 +0,0 @@
{
"categories": [
{
"categoryId": 1,
"name": "Foundations",
"priority": 1,
"sets": [
{
"awards": [],
"categoryId": 1,
"challengesCompletedCount": 0,
"challengesCount": 1,
"description": "Submit an 11-player squad.",
"endTime": 4102444800,
"hidden": false,
"name": "Bronze Challenge",
"priority": 1,
"setId": 1
},
{
"awards": [],
"categoryId": 1,
"challengesCompletedCount": 0,
"challengesCount": 1,
"description": "Get started with your first SBC.",
"endTime": 4102444800,
"hidden": false,
"name": "Simple Start",
"priority": 2,
"setId": 2
}
]
}
]
}
docs/evidence/route-shapes-2026-08-17/season.json
-1
View File
@@ -1 +0,0 @@
{}
docs/evidence/route-shapes-2026-08-17/squad_0.json
-707
View File
@@ -1,707 +0,0 @@
{
"actives": [],
"captain": 100000001,
"changed": 0,
"chemistry": 49,
"custom": "[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,50,50,0,50,40,65,0,65,50,50,1]",
"formation": "f433",
"id": 0,
"kicktakers": [
{
"dream": false,
"id": 100000001,
"index": 0
},
{
"dream": false,
"id": 100000001,
"index": 1
},
{
"dream": false,
"id": 100000001,
"index": 2
},
{
"dream": false,
"id": 100000001,
"index": 3
},
{
"dream": false,
"id": 100000001,
"index": 4
}
],
"manager": [
{
"dream": false,
"id": 100000427
}
],
"personaId": 33068179,
"players": [
{
"index": 0,
"itemData": {
"assetId": 200389,
"attributeList": [
{
"index": 0,
"value": 83
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 77
},
{
"index": 3,
"value": 82
},
{
"index": 4,
"value": 50
},
{
"index": 5,
"value": 87
}
],
"cardassetid": 200389,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 200389,
"fitness": 99,
"id": 100000003,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 44,
"owners": 1,
"playStyle": 250,
"preferredPosition": "GK",
"rareflag": 1,
"rating": 87,
"resourceId": 200389,
"teamid": 240,
"untradeable": true
},
"kitNumber": 1
},
{
"index": 1,
"itemData": {
"assetId": 197445,
"attributeList": [
{
"index": 0,
"value": 86
},
{
"index": 1,
"value": 73
},
{
"index": 2,
"value": 81
},
{
"index": 3,
"value": 83
},
{
"index": 4,
"value": 83
},
{
"index": 5,
"value": 73
}
],
"cardassetid": 197445,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 197445,
"fitness": 99,
"id": 100000006,
"itemState": "free",
"itemType": "player",
"leagueId": 19,
"nation": 4,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LB",
"rareflag": 1,
"rating": 87,
"resourceId": 197445,
"teamid": 21,
"untradeable": true
},
"kitNumber": 4
},
{
"index": 2,
"itemData": {
"assetId": 155862,
"attributeList": [
{
"index": 0,
"value": 78
},
{
"index": 1,
"value": 63
},
{
"index": 2,
"value": 70
},
{
"index": 3,
"value": 70
},
{
"index": 4,
"value": 87
},
{
"index": 5,
"value": 83
}
],
"cardassetid": 155862,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 155862,
"fitness": 99,
"id": 100000005,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 45,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 1,
"rating": 89,
"resourceId": 155862,
"teamid": 243,
"untradeable": true
},
"kitNumber": 3
},
{
"index": 3,
"itemData": {
"assetId": 182521,
"attributeList": [
{
"index": 0,
"value": 45
},
{
"index": 1,
"value": 80
},
{
"index": 2,
"value": 88
},
{
"index": 3,
"value": 79
},
{
"index": 4,
"value": 69
},
{
"index": 5,
"value": 70
}
],
"cardassetid": 182521,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 182521,
"fitness": 99,
"id": 100000008,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 21,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 1,
"rating": 88,
"resourceId": 182521,
"teamid": 243,
"untradeable": true
},
"kitNumber": 6
},
{
"index": 4,
"itemData": {
"assetId": 189332,
"attributeList": [
{
"index": 0,
"value": 93
},
{
"index": 1,
"value": 69
},
{
"index": 2,
"value": 75
},
{
"index": 3,
"value": 83
},
{
"index": 4,
"value": 81
},
{
"index": 5,
"value": 75
}
],
"cardassetid": 189332,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 189332,
"fitness": 99,
"id": 100000007,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 45,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LB",
"rareflag": 1,
"rating": 86,
"resourceId": 189332,
"teamid": 241,
"untradeable": true
},
"kitNumber": 5
},
{
"index": 5,
"itemData": {
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 89
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 26
},
{
"index": 5,
"value": 61
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 158023,
"fitness": 99,
"id": 100000002,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 1,
"rating": 93,
"resourceId": 158023,
"teamid": 241,
"untradeable": true
},
"kitNumber": 9
},
{
"index": 6,
"itemData": {
"assetId": 183907,
"attributeList": [
{
"index": 0,
"value": 79
},
{
"index": 1,
"value": 50
},
{
"index": 2,
"value": 72
},
{
"index": 3,
"value": 68
},
{
"index": 4,
"value": 90
},
{
"index": 5,
"value": 85
}
],
"cardassetid": 183907,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 183907,
"fitness": 99,
"id": 100000004,
"itemState": "free",
"itemType": "player",
"leagueId": 19,
"nation": 21,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 1,
"rating": 90,
"resourceId": 183907,
"teamid": 21,
"untradeable": true
},
"kitNumber": 2
},
{
"index": 7,
"itemData": {
"assetId": 183277,
"attributeList": [
{
"index": 0,
"value": 90
},
{
"index": 1,
"value": 81
},
{
"index": 2,
"value": 82
},
{
"index": 3,
"value": 91
},
{
"index": 4,
"value": 32
},
{
"index": 5,
"value": 64
}
],
"cardassetid": 183277,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 183277,
"fitness": 99,
"id": 100000009,
"itemState": "free",
"itemType": "player",
"leagueId": 13,
"nation": 7,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LM",
"rareflag": 1,
"rating": 88,
"resourceId": 183277,
"teamid": 5,
"untradeable": true
},
"kitNumber": 7
},
{
"index": 8,
"itemData": {
"assetId": 176580,
"attributeList": [
{
"index": 0,
"value": 82
},
{
"index": 1,
"value": 90
},
{
"index": 2,
"value": 79
},
{
"index": 3,
"value": 87
},
{
"index": 4,
"value": 42
},
{
"index": 5,
"value": 79
}
],
"cardassetid": 176580,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 176580,
"fitness": 99,
"id": 100000010,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 60,
"owners": 1,
"playStyle": 250,
"preferredPosition": "ST",
"rareflag": 1,
"rating": 92,
"resourceId": 176580,
"teamid": 241,
"untradeable": true
},
"kitNumber": 10
},
{
"index": 9,
"itemData": {
"assetId": 188545,
"attributeList": [
{
"index": 0,
"value": 81
},
{
"index": 1,
"value": 87
},
{
"index": 2,
"value": 74
},
{
"index": 3,
"value": 85
},
{
"index": 4,
"value": 38
},
{
"index": 5,
"value": 82
}
],
"cardassetid": 188545,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 188545,
"fitness": 99,
"id": 100000025,
"itemState": "free",
"itemType": "player",
"leagueId": 19,
"nation": 37,
"owners": 1,
"pile": "club",
"playStyle": 250,
"preferredPosition": "ST",
"rareflag": 1,
"rating": 90,
"resourceId": 188545,
"teamid": 21,
"untradeable": true
},
"kitNumber": 11
},
{
"index": 10,
"itemData": {
"assetId": 20801,
"attributeList": [
{
"index": 0,
"value": 92
},
{
"index": 1,
"value": 92
},
{
"index": 2,
"value": 81
},
{
"index": 3,
"value": 91
},
{
"index": 4,
"value": 33
},
{
"index": 5,
"value": 80
}
],
"cardassetid": 20801,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 20801,
"fitness": 99,
"id": 100000001,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 38,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LW",
"rareflag": 1,
"rating": 94,
"resourceId": 20801,
"teamid": 243,
"untradeable": true
},
"kitNumber": 8
},
{
"index": 11,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 12,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 13,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 14,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 15,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 16,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 17,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 18,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 19,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 20,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 21,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
},
{
"index": 22,
"itemData": {
"dream": false,
"id": 0
},
"kitNumber": 0
}
],
"rating": 90,
"squadName": "OpenFUT",
"squadType": "REGULAR_SQUAD",
"starRating": 90
}
docs/evidence/route-shapes-2026-08-17/tournament.json
-1
View File
@@ -1 +0,0 @@
{}
docs/evidence/route-shapes-2026-08-17/user.json
-54
View File
@@ -1,54 +0,0 @@
{
"userInfo": {
"accountCreatedPlatformName": "pc",
"actives": [],
"bidTokens": {
"count": 0,
"updateTime": 0
},
"clubAbbr": "OFC",
"clubName": "OpenFUT",
"clubNameChangeAllowed": false,
"currencies": [
{
"active": true,
"finalFunds": 29876776,
"funds": 29876776,
"name": "coins"
},
{
"active": true,
"finalFunds": 0,
"funds": 0,
"name": "points"
}
],
"divisionOffline": 10,
"divisionOnline": 10,
"draw": 0,
"established": "2026",
"feature": {},
"loss": 0,
"personaId": 33068179,
"purchased": false,
"reliability": {
"matchUnfinishedTime": 0,
"reliability": 100
},
"sessionCoinsBankBalance": 0,
"squadList": {
"squad": [
{
"chemistry": 49,
"formation": "f433",
"id": 0,
"rating": 89,
"squadName": "OpenFUT",
"squadType": "REGULAR_SQUAD"
}
]
},
"trophies": 0,
"won": 0
}
}
docs/evidence/route-shapes-2026-08-17/user_list.json
-1
View File
@@ -1 +0,0 @@
{}
docs/evidence/route-shapes-2026-08-17/watchList.json
-5
View File
@@ -1,5 +0,0 @@
{
"auctionInfo": [],
"credits": 29876776,
"total": 0
}
docs/evidence/sold-ab-2026-08-18/A_highest.json
-114
View File
@@ -1,114 +0,0 @@
{
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "0",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "highest"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "caecc67a615ddd0f209b36c7c8ea6a04e0002552d9a42b8eeca20df84feedf3c",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
}
}
}
docs/evidence/sold-ab-2026-08-18/B_buyNow.json
-114
View File
@@ -1,114 +0,0 @@
{
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "0",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "buyNow"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "buyNow",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "0b6e5cc5ab58fdbdd76586b1cff685a562e669fd37750cbd1397db9ee9e97407",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "buyNow",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "fab8d43b7ac0f0e09d6902155f7c5f6d91e57b4b595ec8f6093a5a9dcb02bcdb",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "buyNow",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "fab8d43b7ac0f0e09d6902155f7c5f6d91e57b4b595ec8f6093a5a9dcb02bcdb",
"status": 200
}
}
}
docs/evidence/sold-ab-2026-08-18/C_cp0.json
-114
View File
@@ -1,114 +0,0 @@
{
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "0",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "highest"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "caecc67a615ddd0f209b36c7c8ea6a04e0002552d9a42b8eeca20df84feedf3c",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
}
}
}
docs/evidence/sold-ab-2026-08-18/D_cp1.json
-114
View File
@@ -1,114 +0,0 @@
{
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "1",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "highest"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 1,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "6e228a34b5d7fac6bf70710cbd4ca35b58740e04ae455ffeee04b6ce7faab8e5",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 1,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "c1557013bf20285d0512ca0d055a16df8036260559d640da11102a2379ac5986",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 1,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "c1557013bf20285d0512ca0d055a16df8036260559d640da11102a2379ac5986",
"status": 200
}
}
}
docs/evidence/sold-ab-2026-08-18/differential.json
-509
View File
@@ -1,509 +0,0 @@
{
"counts_states": {
"S1_zero_active_one_sold": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"S2_one_active_one_sold_count_active": {
"count": 1,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 1,
"sold": 1
},
"S2_one_active_one_sold_count_membership": {
"count": 2,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 1,
"sold": 1
}
},
"diffs": {
"orthogonal_coinsprocessed": [
{
"a": 0,
"b": 1,
"kind": "VALUE_MISMATCH",
"path": "auctionInfo[0].coinsProcessed"
}
],
"primary_bidstate": [
{
"a": "highest",
"b": "buyNow",
"kind": "VALUE_MISMATCH",
"path": "auctionInfo[0].bidState"
}
]
},
"generated": "2026-08-18T02:19:25Z",
"settlement": {
"buyer": 19850,
"fee": 7,
"instances": 1,
"owner": "club-buyer-b",
"seller": 1143
},
"variants": {
"A_highest": {
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "0",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "highest"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "caecc67a615ddd0f209b36c7c8ea6a04e0002552d9a42b8eeca20df84feedf3c",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
}
}
},
"B_buyNow": {
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "0",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "buyNow"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "buyNow",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "0b6e5cc5ab58fdbdd76586b1cff685a562e669fd37750cbd1397db9ee9e97407",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "buyNow",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "fab8d43b7ac0f0e09d6902155f7c5f6d91e57b4b595ec8f6093a5a9dcb02bcdb",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "buyNow",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "fab8d43b7ac0f0e09d6902155f7c5f6d91e57b4b595ec8f6093a5a9dcb02bcdb",
"status": 200
}
}
},
"C_cp0": {
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "0",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "highest"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "caecc67a615ddd0f209b36c7c8ea6a04e0002552d9a42b8eeca20df84feedf3c",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "0107bf70809cce10fa5fa0f7f4e196f7ffdd6def1b9f63407eeffc7e66f35855",
"status": 200
}
}
},
"D_cp1": {
"env": {
"OPENFUT_FIFA17_SOLD_COINS_PROCESSED": "1",
"OPENFUT_FIFA17_SOLD_EXPERIMENT": "highest"
},
"surfaces": {
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 1,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "6e228a34b5d7fac6bf70710cbd4ca35b58740e04ae455ffeee04b6ce7faab8e5",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 1,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "c1557013bf20285d0512ca0d055a16df8036260559d640da11102a2379ac5986",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 1,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 212188,
"id": 100000178,
"itemState": "forSale",
"preferredPosition": "ST",
"rating": 75,
"resourceId": 212188,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "c1557013bf20285d0512ca0d055a16df8036260559d640da11102a2379ac5986",
"status": 200
}
}
}
}
}
docs/evidence/sold-ab-2026-08-18/phase0-variantA-staging-sold-row.json
-850
View File
@@ -1,850 +0,0 @@
{
"captured": "2026-08-18T02:21:49Z",
"phase": "0 \u2014 staging validated, sold row present, awaiting live client",
"settlement": {
"clubs": {
"club-buyer-b": 19850,
"club-seller-a-cage": 1143
},
"disposable_owner": [
"club-buyer-b"
],
"fee": 7,
"gross": 150,
"instances": 1,
"proceeds": 143
},
"sold_row": {
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 232273,
"attributeList": [
{
"index": 0,
"value": 62
},
{
"index": 1,
"value": 28
},
{
"index": 2,
"value": 33
},
{
"index": 3,
"value": 49
},
{
"index": 4,
"value": 53
},
{
"index": 5,
"value": 50
}
],
"cardassetid": 232273,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 232273,
"discardValue": 150,
"fitness": 99,
"id": 100000012,
"itemState": "forSale",
"itemType": "player",
"leagueId": 32,
"nation": 117,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LB",
"rareflag": 1,
"rating": 51,
"resourceId": 232273,
"teamid": 112487,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
},
"surfaces": {
"club": {
"body": {
"itemData": [
{
"assetId": 20801,
"attributeList": [
{
"index": 0,
"value": 97
},
{
"index": 1,
"value": 97
},
{
"index": 2,
"value": 86
},
{
"index": 3,
"value": 96
},
{
"index": 4,
"value": 38
},
{
"index": 5,
"value": 85
}
],
"cardassetid": 20801,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 83906881,
"discardValue": 1500,
"fitness": 99,
"id": 100000001,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 38,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LW",
"rareflag": 11,
"rating": 99,
"resourceId": 83906881,
"teamid": 243,
"untradeable": false
},
{
"assetId": 158023,
"attributeList": [
{
"index": 0,
"value": 94
},
{
"index": 1,
"value": 95
},
{
"index": 2,
"value": 91
},
{
"index": 3,
"value": 99
},
{
"index": 4,
"value": 31
},
{
"index": 5,
"value": 66
}
],
"cardassetid": 158023,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 84044103,
"discardValue": 1500,
"fitness": 99,
"id": 100000002,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 52,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RW",
"rareflag": 11,
"rating": 98,
"resourceId": 84044103,
"teamid": 241,
"untradeable": false
},
{
"assetId": 167495,
"attributeList": [
{
"index": 0,
"value": 94
},
{
"index": 1,
"value": 95
},
{
"index": 2,
"value": 99
},
{
"index": 3,
"value": 94
},
{
"index": 4,
"value": 64
},
{
"index": 5,
"value": 96
}
],
"cardassetid": 167495,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 84053575,
"discardValue": 1500,
"fitness": 99,
"id": 100000003,
"itemState": "free",
"itemType": "player",
"leagueId": 19,
"nation": 21,
"owners": 1,
"playStyle": 250,
"preferredPosition": "GK",
"rareflag": 11,
"rating": 97,
"resourceId": 84053575,
"teamid": 21,
"untradeable": false
},
{
"assetId": 176580,
"attributeList": [
{
"index": 0,
"value": 85
},
{
"index": 1,
"value": 93
},
{
"index": 2,
"value": 82
},
{
"index": 3,
"value": 90
},
{
"index": 4,
"value": 45
},
{
"index": 5,
"value": 82
}
],
"cardassetid": 176580,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 117617092,
"discardValue": 1500,
"fitness": 99,
"id": 100000004,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 60,
"owners": 1,
"playStyle": 250,
"preferredPosition": "ST",
"rareflag": 22,
"rating": 95,
"resourceId": 117617092,
"teamid": 241,
"untradeable": false
},
{
"assetId": 177003,
"attributeList": [
{
"index": 0,
"value": 78
},
{
"index": 1,
"value": 79
},
{
"index": 2,
"value": 90
},
{
"index": 3,
"value": 93
},
{
"index": 4,
"value": 76
},
{
"index": 5,
"value": 70
}
],
"cardassetid": 177003,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 151171947,
"discardValue": 1500,
"fitness": 99,
"id": 100000005,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 10,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 24,
"rating": 93,
"resourceId": 151171947,
"teamid": 243,
"untradeable": false
},
{
"assetId": 164240,
"attributeList": [
{
"index": 0,
"value": 77
},
{
"index": 1,
"value": 60
},
{
"index": 2,
"value": 76
},
{
"index": 3,
"value": 76
},
{
"index": 4,
"value": 93
},
{
"index": 5,
"value": 82
}
],
"cardassetid": 164240,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 134381968,
"discardValue": 1500,
"fitness": 99,
"id": 100000006,
"itemState": "free",
"itemType": "player",
"leagueId": 16,
"nation": 54,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 23,
"rating": 92,
"resourceId": 134381968,
"teamid": 73,
"untradeable": false
},
{
"assetId": 182493,
"attributeList": [
{
"index": 0,
"value": 69
},
{
"index": 1,
"value": 52
},
{
"index": 2,
"value": 69
},
{
"index": 3,
"value": 67
},
{
"index": 4,
"value": 92
},
{
"index": 5,
"value": 83
}
],
"cardassetid": 182493,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 151177437,
"discardValue": 1500,
"fitness": 99,
"id": 100000007,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 60,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CB",
"rareflag": 24,
"rating": 92,
"resourceId": 151177437,
"teamid": 240,
"untradeable": false
},
{
"assetId": 168651,
"attributeList": [
{
"index": 0,
"value": 71
},
{
"index": 1,
"value": 89
},
{
"index": 2,
"value": 91
},
{
"index": 3,
"value": 87
},
{
"index": 4,
"value": 64
},
{
"index": 5,
"value": 71
}
],
"cardassetid": 168651,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 84054731,
"discardValue": 1500,
"fitness": 99,
"id": 100000008,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 10,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 11,
"rating": 92,
"resourceId": 84054731,
"teamid": 241,
"untradeable": false
},
{
"assetId": 182521,
"attributeList": [
{
"index": 0,
"value": 48
},
{
"index": 1,
"value": 83
},
{
"index": 2,
"value": 91
},
{
"index": 3,
"value": 82
},
{
"index": 4,
"value": 72
},
{
"index": 5,
"value": 73
}
],
"cardassetid": 182521,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 134400249,
"discardValue": 1500,
"fitness": 99,
"id": 100000009,
"itemState": "free",
"itemType": "player",
"leagueId": 53,
"nation": 21,
"owners": 1,
"playStyle": 250,
"preferredPosition": "CM",
"rareflag": 23,
"rating": 91,
"resourceId": 134400249,
"teamid": 243,
"untradeable": false
},
{
"assetId": 197445,
"attributeList": [
{
"index": 0,
"value": 90
},
{
"index": 1,
"value": 77
},
{
"index": 2,
"value": 85
},
{
"index": 3,
"value": 87
},
{
"index": 4,
"value": 87
},
{
"index": 5,
"value": 77
}
],
"cardassetid": 197445,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 151192389,
"discardValue": 1500,
"fitness": 99,
"id": 100000010,
"itemState": "free",
"itemType": "player",
"leagueId": 19,
"nation": 4,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LB",
"rareflag": 24,
"rating": 91,
"resourceId": 151192389,
"teamid": 21,
"untradeable": false
},
{
"assetId": 121939,
"attributeList": [
{
"index": 0,
"value": 70
},
{
"index": 1,
"value": 58
},
{
"index": 2,
"value": 84
},
{
"index": 3,
"value": 86
},
{
"index": 4,
"value": 88
},
{
"index": 5,
"value": 66
}
],
"cardassetid": 121939,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 100785235,
"discardValue": 1500,
"fitness": 99,
"id": 100000011,
"itemState": "free",
"itemType": "player",
"leagueId": 19,
"nation": 21,
"owners": 1,
"playStyle": 250,
"preferredPosition": "RB",
"rareflag": 21,
"rating": 90,
"resourceId": 100785235,
"teamid": 21,
"untradeable": false
}
]
},
"sha256": "0a916e8e129a9c05294784738c305d651beedd58ebd914a6abfa94bd0a59abc7",
"status": 200
},
"counts": {
"body": {
"count": 0,
"maxAuctionsAllowed": 100,
"offered": 0,
"selling": 0,
"sold": 1
},
"sha256": "766b1fcc4ca47442e6f570c81583840b6ae8df9cbeae52473b3c100ca881e206",
"status": 200
},
"tradePile": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 232273,
"attributeList": [
{
"index": 0,
"value": 62
},
{
"index": 1,
"value": 28
},
{
"index": 2,
"value": 33
},
{
"index": 3,
"value": 49
},
{
"index": 4,
"value": 53
},
{
"index": 5,
"value": 50
}
],
"cardassetid": 232273,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 232273,
"discardValue": 150,
"fitness": 99,
"id": 100000012,
"itemState": "forSale",
"itemType": "player",
"leagueId": 32,
"nation": 117,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LB",
"rareflag": 1,
"rating": 51,
"resourceId": 232273,
"teamid": 112487,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143,
"duplicateItemIdList": [],
"total": 1
},
"sha256": "c792ebcf179a5c617ffe02859ad39eba830a4d5b5224a0953ecef774ee4cf75b",
"status": 200
},
"trade_status_filtered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 232273,
"attributeList": [
{
"index": 0,
"value": 62
},
{
"index": 1,
"value": 28
},
{
"index": 2,
"value": 33
},
{
"index": 3,
"value": 49
},
{
"index": 4,
"value": 53
},
{
"index": 5,
"value": 50
}
],
"cardassetid": 232273,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 232273,
"discardValue": 150,
"fitness": 99,
"id": 100000012,
"itemState": "forSale",
"itemType": "player",
"leagueId": 32,
"nation": 117,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LB",
"rareflag": 1,
"rating": 51,
"resourceId": 232273,
"teamid": 112487,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "db79d9fcfc47ae680b44311598e82918b8afd3284160143c33e525adf693f30e",
"status": 200
},
"trade_status_unfiltered": {
"body": {
"auctionInfo": [
{
"bidState": "highest",
"buyNowPrice": 150,
"coinsProcessed": 0,
"currentBid": 150,
"expires": 0,
"itemData": {
"assetId": 232273,
"attributeList": [
{
"index": 0,
"value": 62
},
{
"index": 1,
"value": 28
},
{
"index": 2,
"value": 33
},
{
"index": 3,
"value": 49
},
{
"index": 4,
"value": 53
},
{
"index": 5,
"value": 50
}
],
"cardassetid": 232273,
"cardsubtypeid": 0,
"contract": 7,
"definitionId": 232273,
"discardValue": 150,
"fitness": 99,
"id": 100000012,
"itemState": "forSale",
"itemType": "player",
"leagueId": 32,
"nation": 117,
"owners": 1,
"playStyle": 250,
"preferredPosition": "LB",
"rareflag": 1,
"rating": 51,
"resourceId": 232273,
"teamid": 112487,
"untradeable": false
},
"sellerEstablished": 1,
"sellerName": "CAGE",
"startingBid": 150,
"tradeId": 900500150,
"tradeState": "closed",
"watched": false
}
],
"credits": 1143
},
"sha256": "db79d9fcfc47ae680b44311598e82918b8afd3284160143c33e525adf693f30e",
"status": 200
}
},
"topology": {
"advertises_utas": "http://<host>:8299/",
"blaze": [
42327,
42330,
42331
],
"core": 18081,
"utas_host": 8299
},
"variant": "A_highest (bidState=highest, coinsProcessed=0, countMode=active)"
}
docs/evidence/store_purchasegroup_capture_2026-08-12.json
-199
View File
@@ -1,199 +0,0 @@
{
"purchase": [
{
"assetId": 1,
"id": 1,
"packType": "BRONZE",
"description": "Bronze Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 1,
"currencies": [
{
"name": "coins",
"funds": 400,
"finalFunds": 400
}
],
"extPrice": {
"finalPrice": {
"amount": 4,
"currency": "mtx"
},
"originalPrice": {
"amount": 4,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 5,
"silverQuantity": 0,
"goldQuantity": 0,
"rareQuantity": 0,
"itemQuantity": 5
},
"unopened": false,
"displayGroup": {
"value": "bronze"
}
},
{
"assetId": 5,
"id": 5,
"packType": "GOLD",
"description": "Gold Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 2,
"currencies": [
{
"name": "coins",
"funds": 5000,
"finalFunds": 5000
}
],
"extPrice": {
"finalPrice": {
"amount": 50,
"currency": "mtx"
},
"originalPrice": {
"amount": 50,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 7,
"rareQuantity": 7,
"itemQuantity": 7
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 6,
"id": 6,
"packType": "GOLD",
"description": "Premium Gold",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 3,
"currencies": [
{
"name": "coins",
"funds": 15000,
"finalFunds": 15000
}
],
"extPrice": {
"finalPrice": {
"amount": 150,
"currency": "mtx"
},
"originalPrice": {
"amount": 150,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 7,
"id": 7,
"packType": "GOLD",
"description": "Special Players Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 4,
"currencies": [
{
"name": "coins",
"funds": 25000,
"finalFunds": 25000
}
],
"extPrice": {
"finalPrice": {
"amount": 250,
"currency": "mtx"
},
"originalPrice": {
"amount": 250,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "special"
}
},
{
"assetId": 65534,
"id": 65534,
"packType": "GOLD",
"description": "",
"state": "inactive",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 1,
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 0,
"rareQuantity": 0,
"itemQuantity": 0
},
"unopened": false,
"displayGroup": {
"value": "mypacks",
"priority": 1
}
}
],
"timestamp": 1596326400
}
docs/evidence/store_purchasegroup_capture_active_placeholder_2026-08-12.json
-199
View File
@@ -1,199 +0,0 @@
{
"purchase": [
{
"assetId": 1,
"id": 1,
"packType": "BRONZE",
"description": "Bronze Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 1,
"currencies": [
{
"name": "coins",
"funds": 400,
"finalFunds": 400
}
],
"extPrice": {
"finalPrice": {
"amount": 4,
"currency": "mtx"
},
"originalPrice": {
"amount": 4,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 5,
"silverQuantity": 0,
"goldQuantity": 0,
"rareQuantity": 0,
"itemQuantity": 5
},
"unopened": false,
"displayGroup": {
"value": "bronze"
}
},
{
"assetId": 5,
"id": 5,
"packType": "GOLD",
"description": "Gold Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 2,
"currencies": [
{
"name": "coins",
"funds": 5000,
"finalFunds": 5000
}
],
"extPrice": {
"finalPrice": {
"amount": 50,
"currency": "mtx"
},
"originalPrice": {
"amount": 50,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 7,
"rareQuantity": 7,
"itemQuantity": 7
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 6,
"id": 6,
"packType": "GOLD",
"description": "Premium Gold",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 3,
"currencies": [
{
"name": "coins",
"funds": 15000,
"finalFunds": 15000
}
],
"extPrice": {
"finalPrice": {
"amount": 150,
"currency": "mtx"
},
"originalPrice": {
"amount": 150,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 7,
"id": 7,
"packType": "GOLD",
"description": "Special Players Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 4,
"currencies": [
{
"name": "coins",
"funds": 25000,
"finalFunds": 25000
}
],
"extPrice": {
"finalPrice": {
"amount": 250,
"currency": "mtx"
},
"originalPrice": {
"amount": 250,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "special"
}
},
{
"assetId": 65534,
"id": 65534,
"packType": "GOLD",
"description": "",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 1,
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 0,
"rareQuantity": 0,
"itemQuantity": 0
},
"unopened": false,
"displayGroup": {
"value": "mypacks",
"priority": 1
}
}
],
"timestamp": 1596326400
}
docs/evidence/store_purchasegroup_capture_client_guard_no_sentinel_2026-08-13.json
-1
View File
@@ -1 +0,0 @@
{"purchase": [{"assetId": 1, "id": 1, "packType": "BRONZE", "description": "Bronze Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 1, "currencies": [{"name": "coins", "funds": 400, "finalFunds": 400}], "extPrice": {"finalPrice": {"amount": 4, "currency": "mtx"}, "originalPrice": {"amount": 4, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 5, "silverQuantity": 0, "goldQuantity": 0, "rareQuantity": 0, "itemQuantity": 5}, "unopened": false, "displayGroup": {"value": "bronze"}}, {"assetId": 5, "id": 5, "packType": "GOLD", "description": "Gold Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 2, "currencies": [{"name": "coins", "funds": 5000, "finalFunds": 5000}], "extPrice": {"finalPrice": {"amount": 50, "currency": "mtx"}, "originalPrice": {"amount": 50, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 7, "rareQuantity": 7, "itemQuantity": 7}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 6, "id": 6, "packType": "GOLD", "description": "Premium Gold", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 3, "currencies": [{"name": "coins", "funds": 15000, "finalFunds": 15000}], "extPrice": {"finalPrice": {"amount": 150, "currency": "mtx"}, "originalPrice": {"amount": 150, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 7, "id": 7, "packType": "GOLD", "description": "Special Players Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 4, "currencies": [{"name": "coins", "funds": 25000, "finalFunds": 25000}], "extPrice": {"finalPrice": {"amount": 250, "currency": "mtx"}, "originalPrice": {"amount": 250, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "special"}}], "timestamp": 1596326400}
docs/evidence/store_purchasegroup_capture_empty_no_sentinel_2026-08-12.json
-173
View File
@@ -1,173 +0,0 @@
{
"purchase": [
{
"assetId": 1,
"id": 1,
"packType": "BRONZE",
"description": "Bronze Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 1,
"currencies": [
{
"name": "coins",
"funds": 400,
"finalFunds": 400
}
],
"extPrice": {
"finalPrice": {
"amount": 4,
"currency": "mtx"
},
"originalPrice": {
"amount": 4,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 5,
"silverQuantity": 0,
"goldQuantity": 0,
"rareQuantity": 0,
"itemQuantity": 5
},
"unopened": false,
"displayGroup": {
"value": "bronze"
}
},
{
"assetId": 5,
"id": 5,
"packType": "GOLD",
"description": "Gold Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 2,
"currencies": [
{
"name": "coins",
"funds": 5000,
"finalFunds": 5000
}
],
"extPrice": {
"finalPrice": {
"amount": 50,
"currency": "mtx"
},
"originalPrice": {
"amount": 50,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 7,
"rareQuantity": 7,
"itemQuantity": 7
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 6,
"id": 6,
"packType": "GOLD",
"description": "Premium Gold",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 3,
"currencies": [
{
"name": "coins",
"funds": 15000,
"finalFunds": 15000
}
],
"extPrice": {
"finalPrice": {
"amount": 150,
"currency": "mtx"
},
"originalPrice": {
"amount": 150,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 7,
"id": 7,
"packType": "GOLD",
"description": "Special Players Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 4,
"currencies": [
{
"name": "coins",
"funds": 25000,
"finalFunds": 25000
}
],
"extPrice": {
"finalPrice": {
"amount": 250,
"currency": "mtx"
},
"originalPrice": {
"amount": 250,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "special"
}
}
],
"timestamp": 1596326400
}
docs/evidence/store_purchasegroup_capture_freshretest_no_sentinel_2026-08-13.json
-1
View File
@@ -1 +0,0 @@
{"purchase": [{"assetId": 1, "id": 1, "packType": "BRONZE", "description": "Bronze Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 1, "currencies": [{"name": "coins", "funds": 400, "finalFunds": 400}], "extPrice": {"finalPrice": {"amount": 4, "currency": "mtx"}, "originalPrice": {"amount": 4, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 5, "silverQuantity": 0, "goldQuantity": 0, "rareQuantity": 0, "itemQuantity": 5}, "unopened": false, "displayGroup": {"value": "bronze"}}, {"assetId": 5, "id": 5, "packType": "GOLD", "description": "Gold Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 2, "currencies": [{"name": "coins", "funds": 5000, "finalFunds": 5000}], "extPrice": {"finalPrice": {"amount": 50, "currency": "mtx"}, "originalPrice": {"amount": 50, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 7, "rareQuantity": 7, "itemQuantity": 7}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 6, "id": 6, "packType": "GOLD", "description": "Premium Gold", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 3, "currencies": [{"name": "coins", "funds": 15000, "finalFunds": 15000}], "extPrice": {"finalPrice": {"amount": 150, "currency": "mtx"}, "originalPrice": {"amount": 150, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "gold"}}, {"assetId": 7, "id": 7, "packType": "GOLD", "description": "Special Players Pack", "state": "active", "saleType": "promo", "limitType": "NONE", "quantity": 0, "purchaseLimit": 0, "purchaseCount": 0, "isPremium": false, "sortPriority": 4, "currencies": [{"name": "coins", "funds": 25000, "finalFunds": 25000}], "extPrice": {"finalPrice": {"amount": 250, "currency": "mtx"}, "originalPrice": {"amount": 250, "currency": "mtx"}}, "packContentInfo": {"bronzeQuantity": 0, "silverQuantity": 0, "goldQuantity": 11, "rareQuantity": 11, "itemQuantity": 11}, "unopened": false, "displayGroup": {"value": "special"}}], "timestamp": 1596326400}
docs/evidence/store_purchasegroup_capture_mypacks70_2026-08-12.json
-199
View File
@@ -1,199 +0,0 @@
{
"purchase": [
{
"assetId": 1,
"id": 1,
"packType": "BRONZE",
"description": "Bronze Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 1,
"currencies": [
{
"name": "coins",
"funds": 400,
"finalFunds": 400
}
],
"extPrice": {
"finalPrice": {
"amount": 4,
"currency": "mtx"
},
"originalPrice": {
"amount": 4,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 5,
"silverQuantity": 0,
"goldQuantity": 0,
"rareQuantity": 0,
"itemQuantity": 5
},
"unopened": false,
"displayGroup": {
"value": "bronze"
}
},
{
"assetId": 5,
"id": 5,
"packType": "GOLD",
"description": "Gold Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 2,
"currencies": [
{
"name": "coins",
"funds": 5000,
"finalFunds": 5000
}
],
"extPrice": {
"finalPrice": {
"amount": 50,
"currency": "mtx"
},
"originalPrice": {
"amount": 50,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 7,
"rareQuantity": 7,
"itemQuantity": 7
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 6,
"id": 6,
"packType": "GOLD",
"description": "Premium Gold",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 3,
"currencies": [
{
"name": "coins",
"funds": 15000,
"finalFunds": 15000
}
],
"extPrice": {
"finalPrice": {
"amount": 150,
"currency": "mtx"
},
"originalPrice": {
"amount": 150,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "gold"
}
},
{
"assetId": 7,
"id": 7,
"packType": "GOLD",
"description": "Special Players Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 4,
"currencies": [
{
"name": "coins",
"funds": 25000,
"finalFunds": 25000
}
],
"extPrice": {
"finalPrice": {
"amount": 250,
"currency": "mtx"
},
"originalPrice": {
"amount": 250,
"currency": "mtx"
}
},
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": false,
"displayGroup": {
"value": "special"
}
},
{
"assetId": 70,
"id": 70,
"packType": "GOLD",
"description": "Reward Special Players Pack",
"state": "active",
"saleType": "promo",
"limitType": "NONE",
"quantity": 0,
"purchaseLimit": 0,
"purchaseCount": 0,
"isPremium": false,
"sortPriority": 1,
"packContentInfo": {
"bronzeQuantity": 0,
"silverQuantity": 0,
"goldQuantity": 11,
"rareQuantity": 11,
"itemQuantity": 11
},
"unopened": true,
"displayGroup": {
"value": "mypacks",
"priority": 1
}
}
],
"timestamp": 1596326400
}
docs/fifa23-startup-flow.md
-108
View File
@@ -1,108 +0,0 @@
# FIFA 23 PC Startup Flow (Offline / Proton)
Observed via FLE log, hook log, and file inspection on 2026-06-26.
## Launch chain
```
umu-run / Steam → FIFA23.exe (via Proton/Wine)
│
├─ DLL load order (before entry point)
│ ntdll.dll, kernel32.dll, ws2_32.dll …
│ version.dll ← our hook DLL slot (loads here)
│ FIFALiveEditor.DLL ← injected by FLE launcher after ~100 ms
│
├─ anadius / LSX emulator (anadius64.dll)
│ Fakes EA App / Origin session
│ Reads HKLM\SOFTWARE\Wow6432Node\Origin\ClientPath
│ Writes AppData\Local\anadius\LSX emu\achievement-*.xml
│ Provides fake PersonaId=1144668899 / UserId=1000200030000
│
├─ EA Anti-Cheat (EAAntiCheat.GameServiceLauncher.exe)
│ Spawns as child; checks EAAntiCheat.cfg
│ Not active in offline/cracked builds (FakeEAACLauncher present)
│
└─ FIFA23.exe entry point
Frostbite engine init (BuildDate 2023-07-05, changelist 5417699)
Reads Data\initfs_Win32 ← Frostbite package manifest
Reads Data\layout.toc ← file-system layout
Reads Patch\initfs_Win32 ← patches on top of base
Reads Documents\FIFA 23\fifasetup.ini ← display settings
Reads Data\locale.ini ← language table
Reads Data\db_meta.xml (via FLE) ← DB schema for all tables
```
## Phase timing (observed, single machine)
| Phase | Time after launch | Trigger |
|------------------------------|-------------------|----------------------------------|
| DLL load + FLE injection | 0 – 0.3 s | OS loader |
| Engine + DirectX init | 0.3 – 5 s | FIFA23 entry point |
| "Press any key" splash | ~5 s | First rendered frame |
| Main menu | ~25 s | After key press |
| FUT mode entry (attempted) | user-driven | User selects FUT tile |
| Network calls to EA services | at FUT entry | DirtySDK / EAWebKit |
## Files read at startup (observed)
| File | Format | Purpose |
|------|--------|---------|
| `Data/initfs_Win32` | Frostbite pkg | Base asset manifest |
| `Data/layout.toc` | Frostbite TOC | File layout index |
| `Patch/initfs_Win32` | Frostbite pkg | Patch layer |
| `Data/locale.ini` | INI | String localisation |
| `Data/db_meta.xml` | XML | DB schema (loaded by FLE) |
| `Data/id_map.json` | JSON | Player/team ID→name map |
| `Data/char_conv.json` | JSON | Character conversion table |
| `Documents/FIFA 23/fifasetup.ini` | INI | Display/audio settings |
| `AppData/Local/Temp/FIFA 23/_replay0.bin` | binary | Replay buffer |
| `anadius.cfg` | VDF | Fake EA persona config |
| `AppData/Local/anadius/LSX emu/achievement-*.xml` | XML | Achievement state |
## Files written during a session (observed)
| File | When written | Content |
|------|-------------|---------|
| `Documents/FIFA 23/settings/Settings*` | Main menu reached | FBCHUNKS — controller/display prefs |
| `Documents/FIFA 23/settings/ProfileOptions` | Profile load | FBCHUNKS — 1.5 MB profile blob |
| `Documents/FIFA 23/filesystemcache/survey.state` | Startup | Empty state file |
| `Documents/FIFA 23/filesystemcache/atlPlayTimeJson/playtime_*.json` | Ongoing | Playtime tracking |
| `FIFA 23 Live Editor/config.json` | FLE ready | FLE settings (rewritten each session) |
| `Logs/log_DD-MM-YYYY.txt` | Throughout | FLE debug log |
## Save file formats
### FBCHUNKS (Frostbite chunk container)
- Magic: `46 42 43 48 55 4E 4B 53` (`FBCHUNKS`)
- Byte 8: version (01 seen)
- Offset 0x12: null-terminated label string (e.g. "Personal Settings 1", "Career - Player Progress 1")
- Remainder: compressed/binary chunk data — no public spec; requires Frostbite tooling to fully parse
- Tools: [Frosty Tool Suite](https://github.com/CadeEvs/FrostyToolSuite) can read/write these
### fifasetup.ini
- Plain `KEY = VALUE` ini, fully human-readable
- Safe to edit (display resolution, locale, vsync)
## Network calls at FUT entry (observed with iptables redirect)
Traffic pattern captured before changing strategy:
- Multiple TLS connections to port 443 (destination: EA servers, resolved as various EA IPs)
- TLS 1.3, AES-256-GCM (DirtySDK's copy of ProtoSSL, inline in FIFA23.exe)
- No SNI sent (DirtySDK does not set `server_name` extension)
- Connections originate from Wine/Proton network stack via Linux kernel TCP
Specific EA hostnames used (from openfut-bridge captures, not decoded from TLS):
- `fut.ea.com` (FUT API)
- `accounts.ea.com` (auth)
- `gateway.ea.com` (entitlements)
- `pin-river.data.ea.com` (telemetry)
## Key FLE Lua API hooks
FLE injects `FIFALiveEditor.DLL` and exposes a Lua engine that can:
- Read any in-memory DB table via `GetDBTableRows(tableName)`
- Write any cell via `EditDBTableField`
- Query career mode state via `IsInCM()`
- Get player/team names via `GetPlayerName`, `GetTeamName`
This is the primary safe integration path (see `fut-integration-options.md`).
docs/foundational-xi-injection-test.md
-191
View File
@@ -1,191 +0,0 @@
# Foundational test — live custom XI via Freeze Lineup
**Status: PENDING — test has not yet been run.**
This is build-order step 1 from `docs/direction.md`: the test everything else
in the direction pivot depends on.
## What changed since the first draft of this doc
The first version of this test guessed at a "selection bias" DB field and a
candidate squad/lineup table name, based on general FIFA-modding precedent
that turned out not to hold for FLE's documented API — no such field appears
anywhere in FLE's actual Lua API docs or its own example scripts. While
researching an unrelated hotkey issue, a **confirmed, FLE-documented**
mechanism for forcing a starting XI turned up instead: the **Formation
Editor's "Freeze Lineup" feature** (FLE wiki, `Formation-Editor.md`):
> This feature can be used in player career mode if you want to manage the
> starting lineup of your team. Can be also used in manager career mode to
> manually manage your next opponent's starting lineup.
Steps (GUI, no scripting): open Formation Editor for a team → arrange players
on the pitch → tick **Freeze Lineup** → `Data → Save`.
This is real and documented, but it's GUI-only — there is no Lua function for
it, and what DB write it actually performs under the hood is undocumented.
This test is now two phases: confirm the GUI feature works at all, then
reverse the DB write it makes so it can be replicated programmatically
(required for the app→game bridge in build-order step 2, which needs this
driven from outside the game, not from a person clicking checkboxes).
Also fixed in this pass: `EditDBTableField`'s real signature, confirmed from
FLE's own docs and `lua/scripts/99ovr_99pot.lua`, is
`EditDBTableField(cell)` where `cell` is `row["fieldname"]` with `.value`
mutated in place — **not** `EditDBTableField(table, row_index, field, value)`
as originally (incorrectly) written into the first draft of the injector
script.
## What this test settles
Whether a *specific, externally-chosen* 11 players can be forced into a
career (or Kick-Off) match's starting lineup, live, with no restart — and
whether the mechanism that does it (Freeze Lineup's underlying DB write) can
be driven by a script instead of a person clicking through the Formation
Editor UI.
If Freeze Lineup itself doesn't actually hold under match start (the wiki
doesn't show it being tested against a live match, only "you should be able
to see... when you play against them"), the whole bridge architecture in
`docs/direction.md` §3 needs rethinking — there is no other documented
mechanism for forcing a lineup.
## Prerequisites
- FIFA 23 launched normally (FLE injected, EAAC neutralized — same baseline
as `track-c-fut-table-test.md`)
- A career save loaded (Freeze Lineup is documented for career mode
specifically — confirm separately whether it does anything in Kick-Off,
don't assume it does)
- Note 11 player IDs from your club (`tools/squad-exporter/export_squad.lua`
output, `playerid` field) that are NOT currently your starting XI
## Phase 1 — confirm Freeze Lineup actually holds into a match
This has zero scripting and should be done first since everything else is
wasted effort if it fails.
1. Open the Live Editor overlay (F9, or `Windows → Settings` from the
overlay's own menu bar if the hotkey isn't registering — see the umu/Wine
hotkey note below).
2. `Features → Teams` → find your team → `Edit`.
3. `Team → Formation` to open the Formation Editor.
4. Swap players around on the pitch so the XI differs from your current
actual starting XI in some checkable way (e.g. swap two outfield players'
positions, or bench/start a specific player).
5. Tick **Freeze Lineup**.
6. `Data → Save`.
7. Hide Live Editor (F9), save your career **on a new slot** (don't overwrite
your main save in case this corrupts something), exit to main menu, reload
that save, and check the team's lineup screen / play a match and watch who
starts.
**Record in the Results table below whether the frozen lineup actually took
the pitch.** If not, stop here — Phase 2 is moot.
## Phase 2 — find the underlying DB write
Only proceed if Phase 1 confirmed Freeze Lineup works.
1. In FLE's Lua Engine, run `tools/squad-injector/snapshot_lineup_tables.lua`.
This dumps every DB table whose name contains `squad`, `lineup`,
`formation`, `tactic`, `teamsheet`, `selection`, `players`, or `teams` to
`C:\FIFA 23 Live Editor\openfut_snapshot_<timestamp>.json`. Note this
filename — this is your **before** snapshot.
2. Without restarting or reloading, repeat the Formation Editor steps from
Phase 1 (steps 2–6 only — open Formation Editor, change the lineup, tick
Freeze Lineup, `Data → Save`). Don't save/reload the career between
snapshot and this step — keep it to a single live session so the diff
isn't polluted by other state changes.
3. Run `snapshot_lineup_tables.lua` again. This is your **after** snapshot.
4. Copy both JSON files out of the Wine prefix (same path pattern as
`track-c-fut-table-test.md`: `~/Games/umu/.../drive_c/FIFA 23 Live
Editor/`) and run:
```bash
python3 tools/squad-injector/diff_snapshots.py before.json after.json
```
5. The output shows exactly which table(s) and field(s) changed. This is the
real, confirmed write Freeze Lineup performs — record it in the Results
table below.
## Phase 3 — replicate the write via script
1. Open `tools/squad-injector/apply_lineup_write.lua` and fill in
`TARGET_TABLE` and `TARGET_FIELDS` using Phase 2's diff output.
2. Edit `C:\FIFA 23 Live Editor\openfut_test_xi.json`:
```json
{
"team_id": 12345,
"xi": [
{ "player_id": 111111, "position": 0 },
{ "player_id": 222222, "position": 5 }
]
}
```
Use 11 entries. Position codes are **confirmed numeric 0–27**
(`GK=0, SW=1, RWB=2, RB=3, RCB=4, CB=5, LCB=6, LB=7, LWB=8, RDM=9, CDM=10,
LDM=11, RM=12, RCM=13, CM=14, LCM=15, LM=16, RAM=17, CAM=18, LAM=19,
RF=20, CF=21, LF=22, RW=23, RS=24, ST=25, LS=26, LW=27`) — from
`lua/scripts/export_season_stats.lua`'s `get_pos_name` table in FLE's own
repo, not a guess.
3. Run `apply_lineup_write.lua` from FLE's Lua Engine.
4. Repeat the save-to-new-slot / reload / check-lineup verification from
Phase 1, but this time without ever opening the Formation Editor — the
write was made entirely from the script.
## Classification criteria
### "Confirmed — full mechanism works"
Phase 1 holds, Phase 2 finds a clean diff, Phase 3's scripted write produces
the same in-match result as the manual GUI path.
**Verdict:** Build-order step 1 done. Proceed to step 2 (bridge transport) in
`docs/direction.md`.
### "GUI works, script doesn't"
Phase 1 holds but Phase 3's replicated write doesn't stick, even though the
diffed fields matched what changed in Phase 2.
**Verdict:** Freeze Lineup likely does more than a single DB field write
(e.g. an internal engine call beyond `EditDBTableField`'s reach, or a second
write the diff missed because it happened in a table outside the `KEYWORDS`
filter in `snapshot_lineup_tables.lua` — widen the filter and redo Phase 2).
### "Freeze Lineup doesn't hold at all"
Phase 1 fails — the lineup reverts to the game's own AI-picked XI regardless.
**Verdict:** No confirmed mechanism exists for forcing a lineup. This kills
the bridge architecture as designed in `direction.md` §3 and needs a return
to first principles — there is no fallback documented anywhere in FLE's wiki
for this specific case.
## A note on the umu/Wine F9/F11 hotkey issue
If FLE's F9 (hide/show) hotkey isn't registering under umu, this is plausibly
a Wine keyboard-hook limitation (FLE's global hotkey detection likely uses a
low-level hook that doesn't translate cleanly through Wine's input layer) —
not something documented anywhere in FLE's own troubleshooting docs, which
don't mention Linux/Wine at all. F11 specifically has **no documented FLE
function** — F9 is the only documented toggle. Workaround: click directly
into the FLE overlay window (it should still be visible/clickable even if the
hotkey doesn't fire) and use its own menu bar instead of relying on the
hotkey.
## Results
*(To be filled in after the test is run.)*
| Field | Value |
|---|---|
| Date run | — |
| Phase 1: Freeze Lineup holds into a match? | — |
| Phase 2: table(s)/field(s) changed | — |
| Phase 3: scripted write reproduces Phase 1 result? | — |
| **Classification** | **PENDING** |
docs/fut-integration-options.md
-136
View File
@@ -1,136 +0,0 @@
# FUT Integration Options
How to connect FIFA 23 to the OpenFUT local simulator, ranked by safety and feasibility.
## Option A — FLE Lua scripting (RECOMMENDED)
**What it does:** Use FIFA Live Editor's in-memory Lua API to read and write the game's
database tables at runtime. FLE is already injected; no additional hooking needed.
**Why it's the right path:**
- Fully offline, no EA servers touched
- FLE is already trusted by the user (it's the launch mechanism)
- `GetDBTableRows` / `EditDBTableField` expose the full Frostbite DB in memory
- Scripts run inside the game process; no IPC complexity
- Same mechanism used by modders for career mode edits today
**Integration design:**
```
openfut-core (SQLite)
│
│ HTTP REST (localhost)
▼
openfut-bridge (port 8080, plain HTTP, no TLS)
│ pulls club/squad/player data as JSON
▼
FLE Lua bridge script
│ calls GetDBTableRows, EditDBTableField
▼
FIFA 23 in-memory DB (Frostbite)
```
The Lua script polls openfut-core's REST API at intervals (or on FUT menu entry)
and writes simulator data (coins, items, squad) into the appropriate DB tables.
**Tables likely involved (to verify with export_squad.lua):**
| Table | Expected FUT content |
|-------|---------------------|
| `players` | Player attributes (OVR, potential, stats) |
| `teams` | Club identity, stadium, colors |
| `fut_clubs` | FUT club record (if in memory when FUT loads) |
| `fut_items` | Card inventory (if in memory) |
| `fut_squads` | Active squad (if in memory) |
**Steps to implement:**
1. Run `tools/squad-exporter/export_squad.lua` from FLE Lua Engine while in FUT to discover which tables are live
2. Map openfut-core's data model to the discovered table fields
3. Write a Lua polling script that fetches `/api/v1/club`, `/api/v1/squad`, etc. from openfut-core and calls `EditDBTableField` to populate them
4. Optionally add a small HTTP client to the Lua script using LuaSocket (FLE ships with Lua 5.4)
**Limitations:**
- Changes are in-memory only; they reset on game restart (acceptable for a simulator)
- Only works while FLE is running (always true in our setup)
- FUT tables may only be populated when the FUT hub is loaded; test with the exporter
---
## Option B — Local save file injection (career mode proxy)
**What it does:** Generate or modify offline career mode save files that contain FUT-like
squad/player data, using Frostbite's FBCHUNKS format.
**Feasibility:** Medium
- FBCHUNKS format is not publicly documented but has been partially reverse-engineered by the Frosty Tool Suite project
- Career saves are 16 MB — large and complex
- Changes take effect only after a game restart
**Best use:** Pre-populating a career club with the same players as the FUT simulator squad, so offline Squad Battles use "your" players.
**Steps:**
1. Use Frosty Tool Suite to open a career save and map the schema
2. Build a Python exporter that writes a valid FBCHUNKS save with simulator squad data
3. Test: replace the career save, launch FIFA, verify squad is correct
---
## Option C — Local companion web UI
**What it does:** The user manages their FUT simulator entirely in a web browser (openfut-core already has this). A button exports the current squad/club state to a format that a Lua script or file injector can consume.
**This is already implemented** — openfut-core serves the FUT simulator REST API. The missing piece is the Lua bridge script (Option A) that reads from it.
---
## Option D — Local proxy for non-secured local calls only
**What it does:** Intercept FIFA 23's calls to `localhost:*` or a known local endpoint (not EA servers) and respond with simulator data.
**Feasibility:** Low value in isolation
- FIFA 23 does not make calls to localhost in normal operation (except EA App on port 10853)
- All FUT API calls go to EA's servers over TLS
- Intercepting those would require the approach we explicitly ruled out
**Not recommended as a primary path.** Could be combined with Option A if the Lua script exposes a local socket that a coordinator process writes to.
---
## Option E — Memory bridge (Cheat Engine / FLE offsets)
**What it does:** Use known memory offsets (FLE's `offset_cache.json`) to read/write FUT state directly in FIFA23.exe's heap.
**Feasibility:** Medium — FLE already does this for career mode
- FLE's `offset_cache.json` contains addresses for many game structures
- FUT in-memory structs are separate from career structs and may not be mapped yet
- This is fragile (offsets change with game updates)
**Not recommended** unless Options A and B both fail — too brittle.
---
## Recommendation
**Start with Option A (FLE Lua scripting).**
1. Run `tools/squad-exporter/export_squad.lua` in-game to discover which DB tables exist in FUT mode
2. Use `tools/file-watch-diff/watch.sh` to snapshot file state entering FUT and identify any new local files
3. Use `tools/network-metadata-logger/netlog.sh` to log which EA hosts FIFA contacts at FUT entry (metadata only, no decryption)
4. Map findings back to openfut-core's data model
5. Implement the Lua bridge script that calls openfut-core's REST API and writes to discovered tables
If FUT tables are not exposed by FLE's DB API (they may not be — FUT data lives server-side in online mode), fall back to **Option B** (career save injection) to provide a squad that mirrors the simulator's club.
---
## Safety boundary
The following are out of scope and must not be implemented:
- Decrypting or inspecting EA's TLS traffic
- Spoofing EA domain names or impersonating EA servers
- Sending modified clients to EA's production services
- Bypassing EA App login or account verification
- Anything that could constitute online cheating or violate EA's ToS for online play
All integration must remain local/offline/single-player.
docs/plans/FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md
-523
View File
@@ -1,523 +0,0 @@
# FIFA 17 — Clean Empty-My-Packs client fix (DESIGN / RESEARCH ONLY)
Status: **design only — no client binary/movie changes made.** This is the client-side
follow-up to bug 6c. The backend already ships a compatibility workaround (P2, active
non-openable sentinel 65534; see `docs/evidence/STORE_TILE_6C.md` §17 and
`FIFA17_EMPTY_MYPACKS_CLIENT_CONTRACT.md`). This plan describes what a *client-side*
fix would need to change so the backend shim can eventually become unnecessary for
patched clients.
Do NOT patch the executable, DLLs, or Scaleform movies in this task.
## 1. Established client-side evidence
Binary: `CardsDLL_Win64_retail.dll`
SHA-256 `4706a881ae1fc7b5769fd810b25a868d29d2b16a8e65a7513436327ef645573c`
(dump load base `0x00006FFFFC120000`; RE-space base `0x180000000`). `FIFA17.exe`
(`29c31cef…`) is Denuvo-packed (decrypts only in live memory).
Store category pipeline (all decompiled; see `docs/plan-2026-08-05-store-subsystem.md`):
- `FUN_1800150d0` — builds display groups from `purchase[]`; a `mypacks` group exists
iff some pack has `displayGroup.value=="mypacks"`. `group+0x104=(value=="mypacks")`,
tiles in `group+0x40`, ordinal in `group+0x00` (1-based creation order).
- `FUN_18007dab0` → `FUN_1800147f0(model, screen+0x290, …)` — renders/resolves a
category. `screen+0x290==0` lists group tiles (`FUN_180014610`); otherwise
`FUN_180014420` exact-matches the ordinal and **returns NULL on a miss**, after
which `FUN_1800147f0` dereferences `[RAX+0x48]` with **no null guard** →
**crash at `0x180014882`** (`ACCESS_VIOLATION` read of `0x48`, minidump-confirmed).
- `screen+0x290` is written in exactly two CardsDLL sites: ctor `FUN_18007d1a0`
writes `0`; **`FUN_18007e7f0` case `0x7551` copies the Flash movie message field
`CATEGORY_ID` verbatim** into it. So the category is chosen by the Scaleform movie.
- `FUN_18007e5e0` binds the six store tabs (`FUN_180014580`: `mypacks, points, bronze,
silver, gold, special`) to `PANEL_ID` = matching group ordinal, or hides the panel.
- Unopened-pack count signals (server, already correct at 0 when empty):
`userInfo.unopenedPacks.recoveredPacks` and `/user/credits .unopenedPacks`. The hub
`CentralUnclaimedPack` tile (destination `GOTO_STORE_MYPACK`) is gated by this count
in the hub model (`model+0x20950`). **Candidate F (a server count gating the STORE's
My-Packs resolution) was CONTRADICTED**: the count is correct at 0 yet the store
still resolves My Packs, because the decision is movie-side.
## 2. Desired clean client behavior
```
unopened-pack count == 0:
Store defaults to Browse Packs (e.g. a real category such as bronze/gold)
My Packs is NOT selected/resolved
no synthetic placeholder tile is required from the server
unopened-pack count > 0:
existing My Packs behavior unchanged
```
## 3. Candidate insertion points (ranked)
Ranking favors fixing the UX (not merely preventing the crash) and the smallest,
lowest-risk change that achieves it.
### Rank 1 (preferred, best UX) — Scaleform / category-selection layer
Prevent the movie from emitting `CATEGORY_ID == mypacks` (and from defaulting the
store into My Packs) when the unopened-pack count is 0; default to Browse Packs
instead.
- **Where:** the FUT Store Scaleform movie / ActionScript (`StoreFront`,
`CATEGORY_ID`/`ACTION_GET_PACKLIST`, `GOTO_STORE_MYPACK`), which the packed exe hosts
and which reads the hub model (it already knows the count for the
`CentralUnclaimedPack` tile).
- **Behavior changed:** the store's initial/selected category when empty.
- **Scope:** movie asset edit (client-side), no native-code patch.
- **Risk:** medium — Scaleform RE/editing is fiddly; must find where the default
`CATEGORY_ID` is chosen and gate it on the count without breaking the count>0 path.
- **Compatibility:** per-client asset change; does not touch protocol or other clients.
- **Fixes UX or just crash?** **UX** — no fake tile, correct default; the crash also
disappears because `mypacks` is never resolved when absent.
- **Evidence:** `screen+0x290 ← CATEGORY_ID` (`FUN_18007e7f0` case `0x7551`); count
already available client-side (hub model / `unopenedPacks`).
### Rank 2 — Native Store resolver fallback (CardsDLL)
Make `FUN_1800147f0`/`FUN_180014420` fall back to a safe category (e.g. list-tiles
`N==0`, or the first existing group) when the requested ordinal misses, instead of
dereferencing NULL.
- **Behavior changed:** category-miss handling for ALL categories, not just mypacks.
- **Scope:** small, localized CardsDLL binary patch near `0x180014420`/`0x180014882`.
- **Risk:** medium — alters native store behavior globally; could mask other
legitimate misses; the movie may still believe it is in My Packs (empty/odd view).
- **Compatibility:** binary patch to the shipped DLL (client-side).
- **Fixes UX or just crash?** Crash + partial UX (no crash, but the empty-My-Packs
view may still be awkward).
- **Evidence:** the no-guard deref at `0x180014882`; `FUN_180014420` returns NULL on
miss.
### Rank 3 (cheapest, crash-only) — CardsDLL null guard
Insert a null check before the `[RAX+0x48]` dereference in `FUN_1800147f0` (a single
`TEST/JZ` around the deref) so a NULL group is skipped/returned safely.
- **Behavior changed:** only the crash path.
- **Scope:** minimal (a few bytes) binary patch at `~0x180014882`.
- **Risk:** low — smallest change; but purely crash-prevention. With no `mypacks`
group the resulting empty view is unverified (could be a blank/empty-category state).
- **Compatibility:** binary patch (client-side).
- **Fixes UX or just crash?** Crash only.
- **Evidence:** minidump faulting instruction `CardsDLL+0x14882`, `[NULL+0x48]`.
## 4. Recommended long-term outcome
Rank 1 (Scaleform default-category gating) is the clean fix: with count 0 the store
opens on Browse Packs, no `mypacks` resolution, no fake tile — and the **backend
sentinel 65534 can be dropped for patched clients** (the server would simply omit the
`mypacks` group when empty, which is safe once the client no longer resolves it).
Rank 3 (null guard) is a cheap universal crash-safety net that could ship alongside.
Until a client-side fix exists, the backend P2 sentinel remains the required
compatibility behavior for unpatched retail clients.
## 5. Open questions / next research (no execution here)
- Locate the Store movie's default/initial `CATEGORY_ID` selection and confirm it can
read the unopened count (Rank 1 feasibility).
- Confirm, via a guarded-resolver experiment, what the empty-My-Packs view degrades to
if the `mypacks` group is simply absent + a null guard is present (Rank 2/3).
- Determine whether the Browse-Packs→My-Packs navigation gate (observed with the
active sentinel) also resolves under Rank 1.
---
# PART II — Native client-fix design (RE-backed, 2026-08-13)
Investigation-and-design phase (no client binary/movie changed, no backend changed,
no new live Store experiment). CardsDLL was re-analysed in Ghidra on `.105`; the
in-repo decompiled addresses were reconfirmed against a freshly-built project. Every
claim below is labelled **ESTABLISHED** (read from this build's binary / crash dump),
**PROPOSED** (design, not yet implemented), or **UNKNOWN**.
## 6. Binary + environment verification (ESTABLISHED)
Hashes re-verified on `.105` (`/mnt/games/FIFA 17/`) — identical to the recorded RE:
- `CardsDLL_Win64_retail.dll` SHA-256 `4706a881ae1fc7b5769fd810b25a868d29d2b16a8e65a7513436327ef645573c`,
size 3179952, PE `TimeDateStamp` 1497050156 (2017-06-09T23:15:56Z), `SizeOfImage`
`0x31d000`, image base `0x180000000` (RE-space). **Unpacked → statically analysable.**
- `FIFA17.exe` SHA-256 `29c31cef12b0c3c2a7305220617c7b4fa139ab76b8c857851bdbe88987962899`,
size 224639408, **Denuvo-packed** → the Scaleform/StoreFront ActionScript that
*decides* to emit `CATEGORY_ID` is NOT statically readable. This is why a
pure-Scaleform edit (old "Rank 1") is not the practical vehicle; the fix is taken
at the readable native boundary in CardsDLL instead.
- Ghidra project rebuilt at `.105:/tmp/ghidra_fut/cardsdll` (headless import+analysis
succeeded). Tooling: `fifa17-recon/tools/ghidra_env.py` run under `~/.venv`
(`PYTHONPATH=/opt/ghidra/Ghidra/Features/PyGhidra/pypkg/src:/usr/lib/python3.14/site-packages`;
`jpype1` reinstalled offline from pip cache). RVAs below = static VA − `0x180000000`.
## 7. Category-selection path (ESTABLISHED — decompiled this build)
Store message dispatch `FUN_18007d880` (RVA `0x7d880`) routes Flash message ids:
`0x753f → FUN_18007dab0` (render), `0x278a → FUN_18007df60` (publish category ids),
and the input handler `FUN_18007e7f0` (RVA `0x7e7f0`) case **`0x7551`** copies the
movie field `CATEGORY_ID` verbatim into `screen+0x290` (the only non-ctor writer;
ctor `FUN_18007d1a0` writes 0).
**Store render `FUN_18007dab0` (RVA `0x7dab0`), decompiled verbatim, is the decision
point:**
```c
iVar1 = *(int *)(param_1 + 0x290); // requested CATEGORY_ID (screen+0x290)
iVar6 = FUN_180014580(store, 1); // the *points* category id (see tab map)
if (iVar1 == iVar6) { // requested category is POINTS (real-money)
if (region_check() == 0) { post "REGION_MISMATCH"; return; }
if (FUN_180014de0(store) != 0) return; // points group present → handled
FUN_180014b60(store, dp); // else points render
} else {
FUN_1800147f0(store, iVar1, dp, 0, 0); // EVERY other category, incl. My Packs
}
```
- `param_1` (RCX) = the store-screen object; `+0x290` is the requested category.
- **Tab→id map `FUN_180014580(store, n)` (RVA `0x14580`): `0=mypacks, 1=points,
2=bronze, 3=silver, 4=gold, 5=special`.** Each returns the group's **1-based
ordinal** (via caption compare `FUN_180014380`) or **`-1`** if that group is absent.
So category ids are DYNAMIC ordinals, not fixed constants. The tab publisher
`FUN_18007df60` pushes `MYPACK_/BRONZE_/…_CATEGORY_ID` to the movie from these
lookups; the movie echoes one back as `CATEGORY_ID`.
- The **points** tab is the only one special-cased (commerce/region gate). **My Packs
is NOT special-cased — it falls into the `else` and is resolved by
`FUN_1800147f0`.**
**Resolver `FUN_1800147f0` (RVA `0x147f0`) — the crash (ESTABLISHED, instruction
level):**
```
0x14856: 85 ff TEST EDI,EDI ; EDI = category ordinal (param_2)
0x14858: 75 0f JNZ 0x14869 ; ==0 → list-all (Browse), else resolve
0x1485a: … CALL 0x14610 ; FUN_180014610 list ALL group tiles
0x14867: eb 29 JMP 0x14892
0x14869: 8b d7 MOV EDX,EDI
0x1486b: e8 … CALL 0x14420 ; FUN_180014420(store, ordinal) → RAX (group|NULL)
0x14870: 48 8d 50 40 LEA RDX,[RAX + 0x40] ; RDX = group+0x40 (=0x40 when RAX=NULL)
0x14878: 48 3b c2 CMP RAX,RDX
0x1487b: 74 15 JZ 0x14892
0x14882: 4c 8b 42 08 MOV R8,[RDX + 0x8] ; <-- FAULT: read [0x40+0x8]=0x48 when NULL
0x14886: 48 8b 12 MOV RDX,[RDX] ; [0x40]
```
`FUN_180014420` (RVA `0x14420`) exact-matches `group+0x00` (ordinal), stride `0x108`,
**returns NULL on a miss, with no guard in the caller** → faulting read of VA `0x48`
at `0x180014882`. This is byte-for-byte the Experiment-B minidump
(`0xC0000005` READ `0x48` at `CardsDLL+0x14882`).
- `param_2 == 0` → `FUN_180014610` lists **all** group tiles = the safe "Browse Packs"
view. `param_2 == existing ordinal` → resolves. `param_2 == a non-existent ordinal`
(e.g. `-1`, which `MYPACK_CATEGORY_ID` becomes when the group is absent) → NULL → crash.
**Why it crashes with zero packs (ESTABLISHED):** with `unopenedPackIds==[]` and no
sentinel, no `mypacks` group exists, so `FUN_180014580(store,0) = -1`,
`MYPACK_CATEGORY_ID = -1`, the movie still selects My Packs and echoes `CATEGORY_ID =
-1`, and `FUN_1800147f0(store, -1, …)` → `FUN_180014420(-1)=NULL` → crash. The active
sentinel (65534) works only because it makes a real `mypacks` ordinal exist to resolve.
## 8. Zero-pack state client-side (ESTABLISHED)
The client already holds the correct unopened-pack count in a **data-manager
singleton** (the same one the store resolver uses):
- Obtain: `seed = FUN_1800d7170()` then `FUN_180009c80(&p, seed)` → `p` (release with
`p->vtbl[0x08](p)`). This exact accessor already runs inside `FUN_180014420` and
`FUN_1800147f0`, so any store-category hook can reach it.
- **Read count: `p->vtbl[0x4d8](p)` → int. Write: `p->vtbl[0x4e0](p, n)`.** Confirmed
in `FUN_180019780`, which reads slot `0x4d8`, adds the number of set booleans in a
pack response, and writes slot `0x4e0` (it also fetches `FutGetPurchasedItems`).
- Representation: plain `int`; **0 = no unopened packs**, `>0` = count. Lifetime: the
singleton persists for the session; updated on pack acquire/open.
- No dedicated "hasUnopenedPacks" boolean helper was found; `count != 0` is the
predicate. (The hub `CentralUnclaimedPack` tile is gated by this same count via
`model+0x20950`, written by `FUN_18010cdc0`/`FUN_18011e120` — the hub mirror, not the
store gate.)
## 9. Implementation vehicle (ESTABLISHED — reuse, do not build a new loader)
OpenFUT **already ships a client hook framework**: `openfut-launcher/openfut-hook`
(`crate-type=["cdylib"]`) builds **`version.dll`**, a proxy DLL placed in the game dir
(`/mnt/games/FIFA 17/version.dll`, present & active; log `~/.wine/drive_c/openfut_hook.log`).
- Load path: Wine/Windows loads `version.dll` from the app dir at process start →
`DllMain(DLL_PROCESS_ATTACH)` → `install_hooks()`.
- Existing hooks (`lib.rs`): `getaddrinfo` (IAT via `iat::resolve`), `connect`
(inline detour), `WSAConnect`, `WSAIoctl`/ConnectEx, origin_spy registry/mutex,
crypt32 `CertVerifyCertificateChainPolicy`, **and in-memory byte-patching of the
loaded (packed) main exe + EAWebKit** (`ssl_patch`: `GetModuleHandleA` → scan for a
unique prologue → `VirtualProtect`+`copy_nonoverlapping`).
- Inline-hook primitive (`connect_hook`): `write_hook(target, dest)` lays a 14-byte
`FF 25 00000000 <abs64>` JMP; `restore_original` restores saved bytes
(unhook → call real → rehook, avoiding trampoline relocation).
- Config: `openfut.cfg` beside the DLL (`host`/ports today; a `store_mypacks_fix`
flag would be added there).
- **Suitability for the Store fix: direct.** The DLL is in-process with full access
to the loaded `CardsDLL_Win64_retail.dll`; the store fix is a NEW module
(`store_hook.rs`) installed from `install_hooks`, reusing the `ssl_patch`
signature-scan and the `connect_hook` inline-detour patterns. No new loader, no ASI,
no separate injector.
## 10. Three strategies re-evaluated against the RE (Task 4)
### A. Category-selection redirect — **PREFERRED** (best UX, native, targeted)
Hook `FUN_18007dab0` (RVA `0x7dab0`) at entry; before the original runs, redirect a
zero-pack My-Packs request to Browse Packs:
```
cat = *(int*)(store + 0x290)
mypacks_id = FUN_180014580(store, 0) // -1 when the group is absent
if (cat == mypacks_id) { // movie asked for My Packs (incl. cat==-1==id)
if (unopened_count() == 0) // singleton vtbl[0x4d8]
*(int*)(store + 0x290) = 0; // 0 = FUN_180014610 list-all = Browse Packs
}
// then call the original FUN_18007dab0(store)
```
- Uses the real count? **Yes** (singleton `vtbl[0x4d8]`). Removes the fake 65534 tile?
**Yes** (server can omit the group). Removes the click-dialog? **Yes** (no placeholder
to click). Removes the Browse→My-Packs nav gate? **Yes** (store lands on Browse, not
an empty My-Packs). Preserves count>0? **Yes** (`cat==mypacks_id` with count>0 is left
untouched → normal My Packs). Affects other categories? **No** (`cat!=mypacks_id`
path is unmodified; points/bronze/… unchanged).
- Prevents the crash as a side effect (My Packs is never resolved when its group is
absent). This is the old "Rank 1" INTENT, implemented at the readable native boundary
instead of in packed Scaleform.
### B. Resolver fallback — acceptable safety net, less targeted
In `FUN_1800147f0` (or right after the `CALL 0x14420` at RVA `0x1486b`): if the
resolved group is NULL, fall back to list-all (`param_2=0`) instead of dereferencing.
- Prevents crash? **Yes.** Fixes default nav / removes fake tile? **Partially** — the
movie still believes it is in My Packs, so the view may be an empty/odd My-Packs
rather than a clean Browse. Leaves other lookups unchanged? **It changes miss-handling
for ALL categories** — a generic NULL fallback that could mask a genuine
missing-category protocol bug. Higher risk than A for that reason; keep as a
belt-and-braces guard, not the primary UX fix. The resolver does NOT know *why*
`mypacks` is missing, which is exactly the concern the task flags.
### C. Null-guard only — weakest (crash-only)
Insert `TEST RAX,RAX; JZ 0x14892` immediately after `CALL 0x14420` (RVA `0x1486b`),
before `LEA RDX,[RAX+0x40]`. Needs a trampoline (no inline slack).
- Converts the crash into whatever an empty tile-vector renders (unverified; likely a
blank/empty category). Does **not** remove the fake tile or fix the default category;
the sentinel would still be needed for acceptable UX. Verified as expected-weakest.
## 11. Concrete hook target for strategy A (Task 6, PROPOSED)
```
module: CardsDLL_Win64_retail.dll (GetModuleHandleA)
function: FUN_18007dab0 (store render / message 0x753f)
RVA: 0x7dab0 (static VA 0x18007dab0)
calling conv: Microsoft x64 fastcall; single arg store-screen ptr in RCX
screen offset: store+0x290 = requested CATEGORY_ID (int)
helpers to call: FUN_180014580 (RVA 0x14580) tab→ordinal, arg0=RCX store, arg1=EDX index(0=mypacks)
count singleton: FUN_1800d7170 (0xd7370-seed) + FUN_180009c80 (0x9c80), read vtbl[0x4d8]
redirect target: set store+0x290 = 0 (FUN_180014610 list-all → Browse Packs)
original behavior: zero packs → resolves absent mypacks ordinal → FUN_180014420 NULL → crash at 0x14882
desired behavior: zero packs + mypacks requested → store+0x290 forced to 0 → Browse Packs; no crash/dialog/tile
```
Hook mechanics (reuse `connect_hook`): lay a 14-byte `FF 25` JMP at `base+0x7dab0` to a
Rust `hooked_store_render(store)`; inside: apply the redirect, unhook, call real
`FUN_18007dab0(store)`, rehook, return its value. Intercepting only the entry means the
minimum interception is the 14 JMP bytes; the first instructions of `FUN_18007dab0`
(`MOV RAX,RSP; MOV [RAX+8],RCX; PUSH …`) are a standard prologue safe to save/restore.
Alt insertion point (earlier): `FUN_18007e7f0` case `0x7551`, where `CATEGORY_ID` is
written to `screen+0x290` — redirect there instead of at render. Entry-hook of
`FUN_18007dab0` is preferred (single, well-typed arg; runs once per store render).
Thread/context: the store screen runs on the client's UI/update thread; the hook reads
one int and (rarely) writes one int on the same object the callee immediately reads —
no new synchronization needed. Called for categories other than My Packs? The FUNCTION
is, but the redirect body only fires when `cat==mypacks_id`, so other tabs are
untouched.
## 12. Version / build safety (Task 7, PROPOSED)
FIFA17-specific compat code MUST validate the client before hooking, and MUST no-op on
any other build (the same `version.dll` is also used for FIFA23):
1. **Module gate:** only proceed if `GetModuleHandleA("CardsDLL_Win64_retail.dll")`
resolves (FIFA23 has no such module → auto-skip).
2. **Build gate (both, belt-and-braces):**
- Exact hash/PE gate: on-disk SHA-256 == `4706a881…`, or PE `SizeOfImage==0x31d000`
&& `TimeDateStamp==1497050156` (cheap in-memory check).
- Signature scan + validation: locate `FUN_18007dab0` by a unique prologue/byte
window rather than trusting the RVA, and assert the known bytes at the branch
(`85 ff 75 0f` region) and at the resolver `CALL 0x14420` site match before
installing. Recommend **both**: hash to reject the wrong game fast, signature to
confirm the exact patch site.
3. **Failure behavior:** any check fails (unknown/updated build) → **do NOT patch**,
log, and leave the **backend P2 active-sentinel (65534) as the fallback**. Never
patch or crash an unrecognised build.
## 13. First controlled client experiment (Task 8, PROPOSED — not executed here)
Goal: prove a patched client sends zero-pack Store entry to Browse Packs with **no**
active placeholder.
- Build `openfut-hook` with strategy-A `store_hook`, gated behind `openfut.cfg`
`store_mypacks_fix=1` (opt-in; default off preserves today's behavior).
- Test profile: `unopenedPackIds == []`.
- Sequence (each variable changed alone; operator drives FIFA; read-only capture):
1. Deploy patched `version.dll`; confirm `openfut_hook.log` shows the store hook
installed + build gate PASSED.
2. **Backend test mode (LATER, separately authorized — NOT in this task):** switch the
backend to *empty-no-sentinel* (the Exp-B config that crashed the UNPATCHED client)
so the patched client must handle a genuinely-absent `mypacks` group.
3. Operator opens Store. **Predicted (patched + zero packs + no sentinel):** Store
opens, defaults to Browse Packs, no `mypacks` resolve, **no crash, no dialog, no
fake tile**.
4. Set `unopenedPackIds=[70]`; reopen. **Predicted:** My Packs works normally
(hook body skipped because count>0).
5. Revert backend to the active sentinel.
- **Backend change eventually required for this experiment: YES** — a controlled
empty-no-sentinel test mode to force the absent group. It is NOT performed in this
phase and MUST be separately authorized (same experiment discipline: patch the
container copy, capture, revert, restart; never synthesize a client request).
- **Client rollback:** flip `store_mypacks_fix=0` (hook not installed) or restore the
original `version.dll`; the game reverts to depending on the backend sentinel. No FIFA
binaries/movies/config are modified on disk — the hook is in-memory only, so rollback
is a file/flag swap.
## 14. Interaction with the backend 65534 fallback (ESTABLISHED + PROPOSED)
- **Keep the backend sentinel deployed** until strategy A is implemented AND verified.
It remains the required behavior for unpatched retail clients and for any client whose
build gate fails.
- Once strategy A is verified, the server MAY, **for patched clients only**, omit the
`mypacks` group when empty (the safe representation the client will then handle) —
but only behind explicit detection/opt-in; do NOT drop the sentinel globally, since
unpatched clients still crash without it.
## 15. ESTABLISHED / PROPOSED / UNKNOWN summary
- **ESTABLISHED:** binary hashes/build; the full native category path and addresses
(`FUN_18007d880/18007dab0/18007e7f0/1800147f0/180014420/180014580/180014610`); the
instruction-level crash (`0x14882`, `[NULL+0x48]`); tab→ordinal map; that My Packs is
not special-cased and funnels through `FUN_1800147f0`; the unopened-count singleton
and its `vtbl[0x4d8]/[0x4e0]` accessors, reachable from store code; the
`openfut-hook`/`version.dll` vehicle and its hook/patch primitives.
- **PROPOSED (not implemented):** the strategy-A entry hook and its redirect logic; the
build-guard scheme; the opt-in config flag; the first experiment and its backend
test-mode requirement; the per-patched-client server relaxation.
- **UNKNOWN:** exactly why the packed Scaleform movie selects My Packs on store open
(Denuvo-packed, unread) — not needed for strategy A, which intercepts the native
result; the precise rendered appearance of `category==0` list-all in this empty
configuration (to be observed in the experiment); whether any non-store path also
drives `screen+0x290` to a My-Packs ordinal (none found; `FUN_18007e7f0` case `0x7551`
and the ctor are the only writers).
---
# PART III — Final no-sentinel resolver experiment (2026-08-13) — RESULT F3 (CRASH), CONFOUNDED
Vehicle change: the resolver guard was implemented as an **`autopatch.py` memory patch**
(the live FIFA-17 client-patch mechanism), NOT the `version.dll` proxy — Proton loads its
builtin `version.dll`, so the earlier `store_hook`/`version.dll` prototype was inert and
has been rolled back. Guard: at CardsDLL `0x180014858`, `JNZ 0x14869` (`75 0f`) →
`JG 0x14869` (`7f 0f`), orig-verified; routes category `< 0` (and `== 0`) to the safe
list-all/Browse path (`FUN_180014610`), category `> 0` to the existing resolver.
`TEST EDI,EDI` at `0x180014856` is the flag source (OF cleared ⇒ `JG` = signed `> 0`).
## Setup (verified)
- CLIENT: guard active/enforced — live bytes `85 ff 7f 0f` at `0x180014856` (FIFA pid 547843,
autopatch pid 547621; log `ENFORCED guarded store patch @ … (JNZ->JG)`, orig `75 0f` matched).
- BACKEND: sentinel 65534 suppressed by a one-line `if not owned_ids:` → `if False:` in the
container copy only (committed source `f42279f` untouched; backup `/tmp/utas_server.EXP_ORIG.py`).
Genuine `GET /store/purchasegroup` (02:44:39Z) → ids `[1,5,6,7]`, **no 65534, no mypacks group**,
normal packs unchanged (evidence: `docs/evidence/store_purchasegroup_capture_client_guard_no_sentinel_2026-08-13.json`).
- PROFILE: `unopenedPackIds=[]`, coins 29,876,776, sha `39bb3e83…` — unchanged throughout.
## Result — F3 (CRASH)
Minidump `CrashDump_2026.08.12_20.44.40.302.dmp` (preserved `/tmp/expF_crash.dmp`, sha `4dcb0cb7…`):
`0xC0000005` READ of VA `0x48` at `ExceptionAddress 0x6ffffc224882` → **RE `0x180014882`** —
the **identical** resolver crash instruction as Experiment B (`FUN_1800147f0`,
`MOV R8,[RDX+0x8]` with the group ptr NULL).
**Mechanism (decisive):** `0x14882` lives in the *resolve* branch, which the guard's `JG`
reaches **only when category `> 0`**. Since the guard was verified in place, the client
presented a **positive** My-Packs ordinal that no longer resolves (no mypacks group) →
`FUN_180014420` returned NULL → crash. The guard's design assumption — *absent mypacks ⇒
category `-1`* — did NOT hold on this path.
## Confound (uncontrolled variable)
FIFA was **not relaunched** after the backend flipped to no-sentinel; the client carried
**stale store/tab state** from the sentinel-present safe stage, where the mypacks group
existed at a *positive* ordinal `N` (`MYPACK_CATEGORY_ID = N`). Reopening the Store reused
that stale positive ordinal rather than the `-1` a **fresh** launch publishes
(`FUN_18007df60 → FUN_180014580(store,0) = -1` when absent). So the intended clean A/B (client
only ever sees the no-sentinel response) was not achieved — the category that reached the
resolver was a stale `>0`, exactly the case the negative-only guard does not divert.
## Conclusion / strategy status
- **The guard as-written does NOT handle a positive, now-invalid My-Packs ordinal** — proven
by this crash. Diverting only `category < 0` is insufficient when the client presents a
stale/positive ordinal for an absent group.
- **Not falsified for the fresh-client case.** Whether a fresh no-sentinel launch presents
`-1` (guard diverts → Browse, no crash) or still a positive ordinal is **UNKNOWN** and needs
a **clean re-test**: launch FIFA fresh with the backend already in no-sentinel mode so the
client never sees a mypacks group. That is the proper equivalent of Experiment B.
- **Candidate stronger guard** (design only, not implemented): divert to list-all when the
resolved group is NULL for *any* category (guard `FUN_180014420`'s NULL return at the
`0x14870`/`0x14882` site), not merely when `category < 0`. This covers the positive-invalid
ordinal too, at the cost of being a generic miss-fallback (the higher-risk Rank-2 behavior).
Do NOT implement without authorization and a clean re-test first.
**Strategy A / resolver guard status: NOT PROVEN.** Crash-guard installs and is build-validated
and dormant-safe with the sentinel present, but the first no-sentinel test CRASHED at the
resolver via a positive stale ordinal (confounded by no relaunch). Backend P2 active-sentinel
was restored immediately (mandatory rollback; source `f416e71e…`, sentinel `state=active`),
and remains the production safety net. Guard left in `autopatch.py` (dormant) pending the
clean re-test decision; `autopatch.py.pre-storeguard.bak` available to remove it.
---
# PART IV — Fresh-process no-sentinel retest (2026-08-13) — RESULT R1 (SUCCESS)
Corrects PART III's confound. This time the mandatory ordering was enforced: the backend
entered no-sentinel mode **while FIFA was closed**, then FIFA launched **fresh** (new pid,
new autopatch) so the process never saw a sentinel-present Store response.
## Setup (verified, clean A/B)
- BACKEND set no-sentinel at 02:55:09Z with FIFA down; genuine `GET /store/purchasegroup`
(02:58:45Z) served to the fresh client = ids `[1,5,6,7]`, **no 65534, no mypacks group**,
packs 1/5/6/7 present. This body is **byte-identical** to the PART III (F3) no-sentinel
capture — the ONLY changed variable vs F3 is the client process lifetime.
Evidence: `docs/evidence/store_purchasegroup_capture_freshretest_no_sentinel_2026-08-13.json`.
- CLIENT: NEW FIFA pid 553220, NEW autopatch pid 552999; guard ENFORCED (orig `75 0f`
matched → `85 ff 7f 0f` = `TEST EDI,EDI; JG`). Process never saw a sentinel response
(0 purchasegroup responses containing 65534 after the no-sentinel restart).
- PROFILE unchanged throughout (`39bb3e83…`, `[]`, coins 29,876,776).
## Result — R1 (operator-observed)
- **No crash** (FIFA 553220 alive after the test; no new minidump), **no dialog**, **Store
stays open**, opens on **Browse Packs**, Bronze/Gold/Special packs visible and navigable.
- Cosmetic-only imperfections (pre-existing, NOT caused by the guard): the six-tab bar is
unbound (no tabs), packs render without cover art, and tiles show "0 items". These match
the known store tab-bind / list-all rendering quirks (`plan-2026-08-05-store-subsystem.md`
§2.1) and are independent of the resolver guard.
## Causal conclusion (decisive A/B)
```
server response (no sentinel, no mypacks group) == byte-identical across F3 and R1
client original JNZ + this response -> CRASH 0x180014882 (Experiment B)
client JG (stale positive ordinal) -> CRASH 0x180014882 (PART III F3, contaminated)
client JG (FRESH, category = -1) -> NO CRASH, Browse Packs (PART IV R1) ✅
```
A **fresh** client publishes `MYPACK_CATEGORY_ID = FUN_180014580(store,0) = -1` for the absent
group; the movie echoes `-1`; `TEST EDI,EDI; JG` does **not** take the resolve branch, so the
client runs the list-all/Browse path (`FUN_180014610`) — no `FUN_180014420(NULL)` deref, no
crash. **PART III's F3 is confirmed as stale-positive-ordinal contamination** (FIFA not
relaunched across the sentinel→no-sentinel flip), not a guard failure.
## Strategy status
**Strategy A / resolver guard: PROVEN ON THE TESTED FIFA 17 BUILD** (CardsDLL
`4706a881…`) for the clean process-lifetime case — it safely routes the absent My-Packs
category to Browse Packs with no crash and no dialog, needing **no** backend sentinel. Scope
caveats: (1) tested build only; (2) the negative-only guard does NOT cover a stale/positive
invalid ordinal (PART III) — only arises if the client's Store state predates a sentinel→
no-sentinel change within one process, which does not happen on a normal launch; a NULL-return
guard at `FUN_180014420` would additionally cover that, deferred/not implemented; (3) UX still
has the pre-existing no-tabs/no-art/"0 items" cosmetics.
Backend P2 active-sentinel was restored immediately after capture (mandatory rollback; source
`f416e71e…`, sentinel `state=active`) and **remains production default**. The clean UX is only
safe to serve when the server knows the client is patched — see PART II §12 rollout options
(recommend B: suppress the sentinel only when client patch-capability is known; keep the
sentinel universal by default). Guard retained in `autopatch.py` (dormant with the sentinel).
## INVARIANT — empty-My-Packs capability MUST be session-stable
F3 vs R1 establish a hard operational invariant for any deployment (sentinel or client
guard): **the server MUST NOT switch a running FIFA client between sentinel-present and
sentinel-absent for the My Packs group within a single FIFA process lifetime.**
Rationale: the client resolves and caches the My-Packs group **ordinal** (positive when a
group — real or sentinel — is present; `-1` when absent) from the `purchasegroup` response
seen at Store-subsystem init. The resolver guard only reclassifies the ordinal *sign*
(`≤0` → Browse). If a client that already cached a **positive** ordinal later receives a
no-sentinel topology, the stale positive ordinal still takes the resolve branch and
`FUN_180014420` returns NULL → crash at `0x180014882` (exactly F3). A **fresh** process that
only ever sees the no-sentinel topology caches `-1` and is routed to Browse safely (R1).
Practical rules:
- Choose the My-Packs representation (sentinel-present vs sentinel-absent) **before** a client
starts its session, and hold it for that session.
- The future patch-capability handshake (PART II §12) MUST therefore be decided at
login/session start, not toggled mid-session.
- A NULL-return guard at `FUN_180014420` (deferred) is the only thing that would make a
mid-session flip crash-safe; until then, session stability is mandatory.
docs/plans/FIFA17_PATCHED_CLIENT_CAPABILITY.md
-358
View File
@@ -1,358 +0,0 @@
# FIFA 17 — verified patched-client capability negotiation
Goal: let the FIFA 17 backend suppress the synthetic My-Packs sentinel (id 65534)
**only when the current FIFA process has positively verified that the CardsDLL
resolver guard is active** (JNZ→JG at RVA `0x14858`). Unpatched / unsupported /
unknown / failed-patch clients keep receiving the existing P2 active sentinel.
Core principle: **the capability is not "this launcher supports the patch"; it is
"the resolver guard was verified in *this particular FIFA process*."**
This document is the design + the cross-component contract. It is deliberately
additive: the P2 active-sentinel path (`docs/evidence/FIFA17_EMPTY_MYPACKS_CLIENT_CONTRACT.md`)
remains the default and the universal fallback.
---
## 1. Architecture inventory (as-built, verified by reading the code)
Data flow today (launch of one FIFA process):
```
LauncherApp::launch_game (openfut-launcher/src/app.rs:450)
-> account_sync::sync POST /openfut/account/sync (:8099) [REQUIRED; launch is gated on it]
-> ensure_local_services() spawn LSX, then autopatch.py --launcher-pid <launcher_pid>
-> game_launch::launch umu-run FIFA17.exe (grandchild; launcher never learns FIFA PID)
FIFA process
-> autopatch.py self-discovers FIFA by comm=='FIFA17.exe'; patches /proc/<pid>/mem each tick
-> FIFA -> backend POST /ut/auth (login) ; GET /store/purchasegroup ; ... (:8099)
```
Facts that shape the design:
- **Launcher ↔ autopatch IPC = one-way stdout only.** `local_services::spawn`
(openfut-launcher/src/local_services.rs:279-296) pipes autopatch stdout/stderr
into the launcher `LogBuffer` line-by-line as `[autopatch] <line>`. There is no
socket / named pipe / status-file readback. `--launcher-pid` is the *launcher's*
own pid (local_services.rs:66), used for liveness, not to identify FIFA.
- **Launcher ↔ backend = exactly one control call:** `account_sync::sync`
(openfut-launcher/src/account_sync.rs:43) — a tiny stdlib-HTTP `POST
/openfut/account/sync` on `openfut_account_sync_port` (default 8099), sent once
per launch, *before* FIFA starts, and **launch is blocked unless it succeeds**
(utas_server.py:1204). This is the reliable per-FIFA-process session boundary.
- **Backend is single-account, stateless-per-request, threaded.** `SID` is a fixed
module constant shared by all clients (utas_server.py:32); account identity is one
global `ACCOUNT` singleton. There is **no per-session identity** in requests. The
only per-connection discriminator available at every handler is
`self.client_address[0]` (peer IP), currently unused. Server is
`ThreadingHTTPServer` (utas_server.py:3784); module is import-safe (server under
`if __name__ == "__main__"`).
- **No bridge/proxy in the FIFA-17 path.** FIFA reaches the Python backend's
published `:8099` directly (client-side DNAT/hosts redirect); the openfut-bridge is
legacy FIFA-23. Docker's iptables DNAT preserves the source IP for external LAN
clients. The launcher and FIFA run on the **same** client machine, so the backend
observes them under the **same** peer IP regardless of NAT.
## 2. Capability transport — options and choice
Ranked against the as-built architecture:
**autopatch → launcher (chosen: structured stdout line).**
1. **Structured stdout line (CHOSEN).** Reuses the existing one-way pipe the
launcher already reads. It is *live* (only the current autopatch child's stdout),
inherently child-bound, and carries **zero stale-file risk** — a previous
launch's capability cannot leak because nothing is persisted. Smallest possible
change. Format is a machine-readable token (§4).
2. Status file in `$XDG_RUNTIME_DIR` keyed by launcher-pid+FIFA-pid+version+timestamp
— works but needs explicit staleness handling and cleanup; more moving parts.
3. Unix-domain socket — most capable but overkill; there is no bidirectional need.
**launcher → backend (chosen: sibling HTTP endpoint on the account-sync port).**
- A. **Existing session-init channel (CHOSEN).** Add `POST /openfut/fifa17/capability`
next to the existing `/openfut/account/sync` (same port 8099, same tiny stdlib-HTTP
client). It cannot ride *inside* account_sync because the capability is only known
*after* autopatch verifies (which happens after account_sync + FIFA start), so it is
a separate, later call — but on the same proven transport.
- B. Blaze/login metadata — rejected: no OpenFUT-owned field is available without
risking a field FIFA depends on, and Blaze runs in a separate responder.
- C. New local IPC + backend side-channel — unnecessary; A already exists.
- D. Server-wide "assume patched" config — dev/testing fallback only; cannot
distinguish patched vs unpatched clients, so never the production mechanism.
## 3. The capability (name + version + VERIFIED semantics)
- Name: **`fifa17.empty_mypacks_resolver`**, integer version, current **`1`**.
- **VERIFIED (v1) means, for THIS FIFA process:** the CardsDLL tested build was
recognised AND the live bytes at RVA `0x14858` are `7f 0f` (`JG`) **after
autopatch enforcement** — i.e. `guarded_action` returned `"patch"` (was `75 0f`,
written, re-read as `7f 0f`) **or** `"noop"` (already `7f 0f`).
- It explicitly does **NOT** mean any of: "autopatch.py contains the guard code",
"the launcher build is new enough", or "a config flag is set". The signal
represents **observed runtime enforcement on the specific process**, nothing less.
## 4. autopatch verification state + emitted line
Per-FIFA-pid guard status (fail-closed; never loosens the existing byte guard):
| state | meaning |
|---|---|
| `NOT_ATTEMPTED` | CardsDLL not yet mapped / guard not evaluated for this pid |
| `VERIFIED` | live bytes == `7f 0f` after enforcement (from `patch` or `noop`) |
| `UNSUPPORTED_BUILD` | live bytes are neither the known original nor patched (`guarded_action` → `skip`) |
| `WRITE_FAILED` | `/proc/<pid>/mem` write raised |
| `VERIFY_FAILED` | post-write re-read != `7f 0f` |
Only `VERIFIED` advertises capability. On transition to `VERIFIED`, autopatch emits
**once per FIFA pid** on stdout:
```
[store-guard] verified capability fifa17.empty_mypacks_resolver=1 fifa_pid=<pid>
```
Any non-verified terminal state emits an explicit, non-advertising status line, e.g.:
```
[store-guard] guard status=UNSUPPORTED_BUILD fifa_pid=<pid> (no capability advertised)
```
## 5. Launcher per-process capability state
```rust
pub struct Fifa17ClientCapabilities { pub empty_mypacks_resolver: Option<u32> }
```
- Starts **UNKNOWN** (`None`) at each launch.
- Becomes `Some(1)` when the launcher parses a valid capability line from the
**current** autopatch child's stdout (`parse_capability_line`).
- **Discarded** when autopatch stops / FIFA exits / launcher exits / next launch. It
is never persisted and never reused for a later FIFA process — staleness is
structurally impossible.
On first `Some(v)`, the launcher registers the capability with the backend (§6) once.
## 6. Launcher → backend registration + binding
`POST /openfut/fifa17/capability` (port = `openfut_account_sync_port`, 8099), body:
```json
{"capability":"empty_mypacks_resolver","version":1,"personaId":<id>,"fifaPid":<pid>}
```
- **Binding key = source IP** (`self.client_address[0]`). The registration arrives
from the client machine's IP; FIFA's `/store/purchasegroup` requests arrive from
the **same** IP (same machine). `personaId`/`fifaPid` are for logging only (the
backend is single-account, so persona cannot discriminate clients).
- Concurrency: distinct client machines → distinct peer IPs → independent decisions
(no global state). Two FIFA processes on **one** machine share an IP — an accepted
limitation (the backend is single-account anyway); documented in §Trust.
## 7. Backend session-stable decision
Per-IP record (guarded by a lock; threaded server):
```
_FIFA17_STORE[ip] = {"resolver": Option[int], "mode": Option[str]} # mode: None|"sentinel"|"clean-v1"
```
- **Reset (session boundary):** `/openfut/account/sync` from `ip` sets
`{resolver: None, mode: None}`. This is the launcher's required per-launch call, so
every new FIFA process starts from a clean, unfrozen record — no cross-process leak.
- **Register:** `/openfut/fifa17/capability` from `ip` sets `resolver = version`. If
`mode` is already frozen, it is logged as late and **ignored for this session**.
- **Freeze point = first `/store/purchasegroup`** from `ip` (§9): if `mode is None`,
set `mode = "clean-v1"` iff `resolver == 1` else `"sentinel"`, and log once.
Thereafter `mode` is immutable for the session.
- **Default / fail-closed:** an IP with no record (no account-sync, no capability),
an unknown resolver version, a late capability, or a disappeared capability all
resolve to (or remain) `"sentinel"`.
## 8. Freeze point rationale
Freeze at **first `/store/purchasegroup`**, not at login/account-sync. account-sync
fires *before* FIFA starts and *before* autopatch can verify, so freezing there would
always be `sentinel`. First Store request is the earliest moment at which a genuine
capability can already be registered (autopatch verifies at process start; the user
opens the Store later), while still being a single, well-defined topology commit for
the session. Once Store topology is served, it must not change (the F3 experiment
proved a mid-session flip can leave a stale positive ordinal that crashes even the
sign-only guard — see `FIFA17_EMPTY_MYPACKS_CLIENT_FIX.md` PART III/IV and the
SESSION-STABLE invariant).
## 9. Store behaviour (additive switch)
At `store_catalog`, only the zero-owned-packs branch changes:
```
if not owned_ids:
if fifa17_empty_mypacks_mode(client_ip) == "clean-v1":
pass # patched client: emit NO mypacks group; guard routes -1 to Browse
else:
<append active 65534 sentinel exactly as today> # P2 fallback (unchanged)
```
Untouched: real owned-pack rendering, `PACK_CATALOG`, pack 70, normal packs 1/5/6/7,
profile state, all store env flags. Default remains sentinel. This lives in the FIFA-17
Python backend only — **never** in game-independent OpenFUT Core.
| client | zero packs | real unopened pack |
|---|---|---|
| verified v1 | **no sentinel** (clean) | genuine My Packs, no sentinel |
| no / unknown capability | **active 65534 sentinel** | genuine My Packs, no sentinel |
## 10. Trust model (Task 14)
This is **not** anti-cheat / attestation. OpenFUT assumes the user controls the
launcher/client machine and the server is a private preservation environment. The
verification exists to prevent *accidents*: a stale capability, an unsupported
CardsDLL build, a failed autopatch, the wrong process, or an unpatched client
receiving no sentinel and crashing. No signatures / PKI / remote attestation.
Isolation across *distinct client machines* relies on the backend observing distinct
peer IPs (source-IP-preserving publish; Docker's default for external LAN via iptables
DNAT). Two FIFA processes on one machine cannot be distinguished by IP — accepted,
since the backend is single-account. The single-client production case is unaffected
by NAT because launcher and FIFA share one IP.
## 11. Fail-closed matrix (Task 15) — every failure ⇒ sentinel
autopatch missing / not run · guard `UNSUPPORTED_BUILD` / `WRITE_FAILED` /
`VERIFY_FAILED` · launcher cannot parse the line · registration POST fails ·
account-sync never called · unknown capability version · capability arrives after
freeze · capability disappears after a sentinel freeze — **all resolve to the active
65534 sentinel.** Asserted by tests (matrix A–J) and this document.
## 12. P2 retained (Task 16)
The active-sentinel implementation is **not** removed. It is the else-branch of the
switch and the universal default for unpatched clients, unsupported builds, failed
patches, unknown launchers, and late capabilities. The clean path is purely additive.
---
## 13. Session binding (hardening — supersedes the per-IP prototype)
**History.** The first implementation keyed the backend capability/store-mode by
**source IP alone** (§7 as originally written). That was rejected before deployment:
two FIFA processes that share a source IP — concurrent, or a relaunch — would share
the key, so an *unverified* process could inherit a *verified* one's `clean-v1`
topology and crash on the empty-My-Packs resolver. Source IP is now **auxiliary only**
(logging, a fail-closed sid/ip sanity check, and the pending hand-off key). This
history is retained deliberately; do not treat per-IP as the design.
**Authoritative key = the per-login UTAS session id (`X-UT-SID`).** `/ut/auth` now
mints a fresh unique SID per login (was a shared constant `OPENFUT-SID-…0001`); the
client echoes it on every later call, and it is **live-confirmed present on real
`/store/purchasegroup` requests**. The SID uniquely identifies one FIFA process/login:
a relaunch re-auths → new SID; two concurrent logins → two SIDs. The legacy constant
is still accepted by the retired security-question gate only, and is **never** used to
grant `clean-v1`. A store request whose SID was opened on a different source IP is
fail-closed to sentinel (sid/ip sanity check).
**Why not persona alone:** the backend is single-account, so `personaId` cannot
distinguish two sessions, and a relaunch keeps the same persona — persona alone would
leak a prior session's mode. Persona is used only (with IP) to key the pending hand-off.
### State machine (per session, keyed by SID)
```
Capability : Unknown | ResolverV1
StoreMode : Unfrozen | Sentinel | CleanV1
/ut/auth (new SID) : Capability=Unknown, StoreMode=Unfrozen, record {ip,persona}
+ consume any pending (ip,persona) -> Capability=ResolverV1
capability registered : bind to the one live Unfrozen/Unbound session for (ip,persona)
-> Capability=ResolverV1 ; else stage single-use pending ;
else (a session exists but is frozen/ambiguous) -> ignored-late
first /store/purchasegroup : Unfrozen + ResolverV1 -> freeze CleanV1
Unfrozen + otherwise -> freeze Sentinel (consume pending first)
late capability : StoreMode already frozen -> unchanged (ignored-late, not staged)
capability lost/cleared : after a CleanV1 freeze -> stays CleanV1 (mode is cached)
session idle > TTL / reaped: session discarded (a later store with that SID -> Sentinel)
```
### Registration order + pending hand-off
The verified capability is known only after the FIFA process exists, CardsDLL is
loaded, and autopatch confirms the JG bytes — which may land before or after
`/ut/auth`, but reliably before the user opens the Store. The launcher cannot know
the SID, so its registration is matched to a session by (source_ip, persona) as a
**single-use, short-TTL pending** (`FIFA17_PENDING_TTL = 120s`) that is consumed by
exactly one session, at whichever of these happens first for that session: its
`/ut/auth` (pending predates login), the registration itself (session already live —
bound directly), or its first store request (lazy). If the Store is reached before a
capability binds, the session freezes **Sentinel** (fail-closed); a later capability
does not change it.
### Session cleanup (Task 10)
- **creation:** at `/ut/auth`.
- **last activity:** bumped on every `/store/purchasegroup` for the session.
- **freeze:** first `/store/purchasegroup`.
- **expiry:** lazy sweep on every session op removes sessions idle for
`FIFA17_SESSION_TTL = 3600s` and pendings older than `FIFA17_PENDING_TTL`. Explicit
Blaze/UTAS teardown is not reliably observable at this handler, so a conservative
activity-based TTL is used instead. Reaping only removes *expired* entries and never
affects another live session from the same IP/persona (keyed by distinct SIDs).
### Residual limitation (documented, fail-closed)
FIFA carries no launcher-controllable per-process token, so two **simultaneous** logins
from the **same (ip, persona)** cannot be disambiguated at the instant a capability is
registered while *both* are Unfrozen/Unbound. That ambiguous case resolves to
`ignored-late` → **both freeze Sentinel** (safe: an unverified process is never granted
clean). The normal one-launcher-per-FIFA and sequential-relaunch flows bind correctly
(proven by matrix K/L/M). This is a UX conservativeness, never a safety hole.
---
## 14. Deployment candidate & controlled A/B (overnight reconciliation 2026-08-13)
**Launcher lineage reconciliation.** The two divergent launcher histories (merge
base `87241ac`) were reconciled by a real merge — **not** a rebase/squash/rewrite —
in a clean worktree:
- `feat/launcher-arming` `13339c1` (client arming + FIFA-17 capability reporting)
- `feat/sbc-hook-tracing` `958ff24` (openfut-hook SBC request tracing / RE probes)
Merged commit **`ca7ce26`** on branch `integration/fifa17-launcher-capability-sbc`
retains **both** ancestors (`git merge-base --is-ancestor` true for both `958ff24`
and `13339c1`). The only conflict was `src/process.rs` (launcher-arming deleted it +
dropped `mod process`; SBC only incidentally tidied it) — resolved **keep-deleted**
(orphan module; the SBC feature lives entirely in `openfut-hook/*`). The two features
are in disjoint crates/processes (launcher-crate Rust host vs `openfut-hook` Windows
DLL) and share no stdout readers, child handles, or lifecycle — no integration code
was needed.
**Gitlink status — DEFERRED (morning blocker).** The superproject gitlink still
records the pre-reconciliation `958ff24`. It was **not** bumped to `ca7ce26` because
the live submodule checkout carries uncommitted `openfut-hook/*` WIP that overlaps the
merged hook content; a non-destructive `git checkout ca7ce26` is refused ("local
changes would be overwritten"), and no `-f`/`reset`/`clean` is permitted. The user
must first reconcile that WIP against the merged `openfut-hook`, then the gitlink can
bump. Preservation artifact: `/tmp/openfut-launcher-overnight-tracked.patch`
(sha256 `8e65de2c…`).
**Validated deployment-candidate tuple** (reproducible from git except the deferred
gitlink):
```
superproject HEAD a82407c (backend per-session + docs)
backend guard b0d5e04 fix(fifa17): guard missing store category resolution
client proof fc29c2e docs(fifa17): record no-sentinel client resolver proof
autopatch report 1c396dd feat(fifa17): report verified client patch capability
backend negotiate b25761e feat(fifa17): negotiate clean empty My Packs mode
session binding 805d754 fix(fifa17): isolate patched-client capability per session
launcher merged HEAD ca7ce26 merge: reconcile launcher capability and SBC tracing
(ancestors 13339c1 capability + 958ff24 SBC)
launcher gitlink (super) 958ff24 <-- to become ca7ce26 once WIP reconciled
```
Local build artifacts (NOT deployed): launcher `target/release/openfut-launcher`
(sha256 `a390c61d…`); backend image `openfut-fut-backend:candidate-overnight`
(`84d280be…`, ships `utas_server.py` `33e0ef3…`). Live `:dev` image and the running
container were left untouched.
### Controlled A/B sequence (execute only in a later authorized deploy task)
**A — patched client:** fresh FIFA process → autopatch verifies the JG guard →
launcher parses the verified line and registers → `/ut/auth` mints a fresh `X-UT-SID`
→ capability binds to that SID → first `/store/purchasegroup` freezes `clean-v1` →
backend omits 65534 → Store opens on Browse Packs, no crash.
**B — unpatched client, same machine/IP, NEW session:** new `X-UT-SID`, no verified
capability → first store freezes `sentinel` → backend emits active 65534 → no crash.
Proves same-IP isolation + fail-closed fallback.
**C — failed patch (optional):** autopatch reports `UNSUPPORTED_BUILD`/`VERIFY_FAILED`
→ launcher never registers → `sentinel`.
Production remains the P2 active-sentinel universal default until this A/B passes.
docs/status-review.md
-208
View File
@@ -1,208 +0,0 @@
# OpenFUT Status Review
*Generated 2026-06-30 — read-only stocktake, no code changed.*
---
## Executive Summary
OpenFUT has a mature offline FUT economy backend (Core, 25 phases, fully functional in
isolation) and a sophisticated hook DLL that loads into FIFA 23, redirects EA hostnames
to loopback, and bypasses TLS certificate verification. The Blaze/ProtoSSL layer is
structurally ready: framing code exists, a TLS listener runs, cert-verify is patched.
However the project is currently blocked before any Blaze traffic is ever seen.
The fundamental problem is that FIFA 23 submits `GoOnline` to EbisuSDK and then
**waits for an asynchronous ONLINE_STATUS_EVENT push** from the EA-app LSX server —
a push that current code never sends. Every approach tried so far (flipping poll
return values, forcing the state flags, read-only probes) confirms the gate is
event-driven, not poll-driven. The Blaze captures directory contains six empty files.
No Fire2 frame from FIFA 23 has ever been decoded. Until the ONLINE_STATUS_EVENT push
is synthesized and delivered correctly, Milestones 2–7 are all waiting on the same
single wall.
---
## 1. Proven vs Assumed
| Claim | Status | Evidence |
|---|---|---|
| FIFA 23 uses DirtySDK / ProtoSSL | **Proven** | String scan hit `ProtoSSLSend`, `ProtoSSLRecv`, `gosredirector` in FIFA23.exe memory (Task 1) |
| `version.dll` loads and runs hook code | **Proven** | `hook.log` written at DLL_PROCESS_ATTACH |
| `getaddrinfo` IAT hook redirects EA domains to loopback | **Proven** | Hook log records every EA `getaddrinfo` call; connect_hook log confirms port redirects |
| ProtoSSL cert-verify prologue found and patched (FIFA23.exe) | **Proven** | ssl_patch.rs prologue confirmed at file offset 0xf0c850; hook log "ssl: main exe cert-verify patched" |
| ProtoSSL cert-verify patched in EAWebKit.dll | **Proven** (if loaded) | Lazy patch fires on first EA getaddrinfo call; hook log message confirms |
| Gate is upstream of DirtySDK — no DNS/connect fires on FUT entry | **Proven** | getaddrinfo, connect, WSASend/Recv hooks all show zero external traffic during "connecting to EA Servers" |
| `GoOnline` is called by the game | **Proven** | Read-only detour on `anadius64.dll+0x2BB90` confirmed hit |
| anadius returns GoOnline success | **Proven** | Handler observed returning successfully; game still retries every ~7 s |
| Gate is downstream of GoOnline | **Proven** | GoOnline called + returns success; no Blaze connect follows |
| Connection-state function: `GetInternetConnectedState @ anadius64.dll+0x27790` | **Proven** | Located via anadius LSX command-registration table; two-flag branch decoded (`+0xCAB1A`, `+0xCAB1B`) |
| Gate is event-driven (game waits for async push, not a poll return) | **Proven** | Forced both state flags AND GoOnline return to "1"; game kept retrying; worker-thread stack scan confirms handler runs on anadius IOCP thread, not FIFA's thread |
| GoOnline runs on anadius worker thread, not FIFA's call thread | **Proven** | Stack scan from inside detour found zero FIFA23.exe frames, sp ~2.4 KB from thread stack top |
| `protossl-scan` live toolkit is exhausted for finding GoOnline in FIFA23.exe | **Proven** | No `"GoOnline"` string in image; worker-thread call stack has no FIFA frames; jmpscan yields ~3875 hits (overwhelmingly data false positives) |
| FIFA 23 redirector config references `Authorization:` header (Nucleus token) | **Proven** | Found in FIFA23.exe .rdata pointer table @ `+0x83FC858` |
| openfut-core REST API complete and tested | **Proven** | 25 phases, 15 migrations, passing integration tests |
| Bridge LSX server starts and handles request-response | **Proven** (code) | `openfut-bridge/src/lsx.rs` + `main.rs` — server starts on 127.0.0.1:3216 |
| Bridge LSX server ACTUALLY receives FIFA's LSX connections | **UNCONFIRMED** | anadius may intercept the same calls in-process before the TCP connection reaches the bridge |
| Bridge LSX server `GetInternetConnectedState → connected="1"` unblocks the gate | **UNCONFIRMED (known to fail in-process)** | Flipping the value via anadius in-process failed; bridge path not yet confirmed working |
| ONLINE_STATUS_EVENT push XML format | **UNKNOWN** | No capture; format not derived |
| Fire2 framing is correct for FIFA 23 | **UNCONFIRMED** | Implemented based on post-2012 EA convention; all blaze captures are empty (0 bytes) |
| Blaze component / command IDs for FIFA 23 | **UNKNOWN** | Zero captures; dispatch table entirely empty placeholders |
| ProtoSSL recv-injection convention (non-blocking return values etc.) | **UNCONFIRMED** | Never reached M4; recv_hook module removed from active install path |
| FUT REST endpoint paths in mapper.rs | **SPECULATIVE** | Based on community knowledge of older FIFA titles; the one actual capture in `captures/` is an early GET from before the Blaze strategy |
| FLE Lua API exposes FUT DB tables in memory | **UNKNOWN** | `export_squad.lua` has never been run; FUT data may only exist server-side in online mode |
---
## 2. Milestone Status
| Milestone | Status | Blocker | Depends on unconfirmed assumption? |
|---|---|---|---|
| **M1** — Locate connection-state decision point | ✅ Done | — | No |
| **M2** — Flip gate, force "connected" | ⛔ Blocked | Game waits for async ONLINE_STATUS_EVENT push; no current code sends it | Yes — unknown event XML format |
| **M3** — First ProtoSSL plaintext on Blaze connection | 🔲 Not started | Depends on M2 | Yes — Fire2 framing unconfirmed |
| **M4** — Answer redirector + decode first Fire2 frame | 🔲 Not started | Hard wall: Fire2 framing, recv-injection convention, component/command IDs all unconfirmed | Yes — all three unknown |
| **M5** — Blaze preauth / login / postauth | 🔲 Not started | Depends on M4 | Yes — Blaze auth TDF body layout unknown |
| **M6** — FUT entry + hub load | 🔲 Not started | Depends on M5; also requires FUT REST response shapes confirmed | Yes — endpoint paths speculative |
| **M7** — Squad Battles (AI FUT) | 🔲 Not started | Depends on M6 | Yes |
**Note on roadmap.md wording:** Under M2–M4, roadmap.md uses `**Done (observable):**` bullets. These describe the *success criterion* for each milestone, not an achieved state. The authoritative status is in `connection-gate-findings.md` (M2 attempts failed; M3/M4 never started). The roadmap has not been updated to reflect M2 failure.
### M4 is the first hard wall in detail
Even assuming M2 is solved, M4 requires three unconfirmed things simultaneously:
1. **Fire2 framing** — the 12-byte header layout is assumed; if FIFA 23 uses an older Fire variant or a custom delta, the codec will misparse every packet.
2. **ProtoSSL recv-injection** — delivering responses to the game via recv hook requires knowing what return values and buffer conventions ProtoSSL expects; recv_hook.rs exists but is not installed.
3. **Blaze component/command IDs** — the dispatch table is entirely empty; we cannot answer any request until IDs are known from captures.
All three are resolved by getting one real captured frame. M4 is primarily a capture problem, not a decoding problem — once bytes exist, the framing and IDs are immediately readable.
---
## 3. Blockers, Risks, Unknowns
### Blockers (stop progress now)
1. **ONLINE_STATUS_EVENT push not synthesized** *(M2 wall)*
The game calls GoOnline, gets success, then waits indefinitely for a push event on the LSX socket that never arrives. This is the single gate blocking all Blaze work. Options: (a) trace the event format via Ghidra on FIFA23.exe (xref `ONLINE_STATUS_EVENT` string + the game's EbisuSDK listener), (b) RE anadius's LSX event-send path (find what it would push in an "online" scenario), (c) brute-force push candidate event XMLs and observe whether the game advances.
2. **Bridge LSX server delivery unconfirmed** *(architectural risk converted to blocker)*
The hook passes port 3216 connections through, assuming the bridge LSX server on the Linux host receives them. If anadius's in-process hooks intercept the winsock calls before they reach the TCP stack, the bridge server is never reached. This must be confirmed by checking `openfut_hook.log` for a getaddrinfo on the LSX host, or by observing the bridge server's accept logs.
### Risks (could derail later)
3. **Fire2 framing wrong** *(M4 risk)*
If FIFA 23 uses Fire (pre-2012) or a modified frame layout, the codec misparses. Mitigation: the server has a `Raw` fallback mode for capturing raw bytes when framing fails.
4. **Secondary auth-token gate** *(M5 risk)*
`connection-gate-findings.md` noted the redirector request carries an `Authorization:` header. M1's final conclusion said `GetAuthCode` returns a fake token that appears accepted — but this was inferred, not confirmed by seeing the redirector request actually constructed with that token.
5. **EAAC not fully neutralized** *(persistent risk)*
`FakeEAACLauncher` bypasses the anticheat launcher. The hook DLL is unsigned. If EAAC is ever active (e.g., after a game update re-enables it), all hooks fail silently. Marked as "not active in offline/cracked builds" — assumed, not confirmed on every launch.
6. **FUT REST response shapes wrong** *(M6 risk)*
The 61 endpoint mappings in mapper.rs and the shaper stubs in shaper.rs are based on community guesses about older FIFA FUT APIs, not FIFA 23 captures. Response JSON shapes may differ enough to cause the client to fail silently or crash.
### Unknowns (open questions)
7. **ONLINE_STATUS_EVENT XML format** — exact tag names, field order, sender attribute, and any nonces/tokens required.
8. **GoOnline event sequence** — whether ONLINE_STATUS_EVENT alone is sufficient or a sequence of events (e.g., PROFILE_EVENT, LOGIN_EVENT, COMMERCE_EVENT) is expected.
9. **Whether FLE exposes FUT DB tables** — FUT card inventory and squad data likely live server-side in online mode; FLE may not surface them for in-process editing.
10. **Blaze component/command IDs for FIFA 23** — entirely unknown; no captures.
11. **openfut_hook.log current content** — we have the code but no log output in any document. Whether the current hook (with connect, ssl_patch, tls_bypass, WSAIoctl, origin_spy all installed) fires correctly and what it observes is unverified in this review.
---
## 4. Track Comparison
### Track A — Full EA-backend fake (M1–M7, playable FUT vs AI)
**What it delivers:** The FIFA 23 FUT hub loads from OpenFUT Core; Squad Battles matches play and reward economy items.
**Effort:** Research-grade. Minimum path: synthesize ONLINE_STATUS_EVENT (unknown format, 1–2 weeks of RE), then capture Fire2 frames (days once M2 is solved), then implement Blaze auth handlers (weeks), then implement FUT entry (weeks), then Squad Battles (weeks). Realistic minimum: 3–6 months of expert RE work.
**Proven support:** Hook loads and redirects correctly. TLS bypass patched. Core economy backend complete. Blaze framing code and TLS listener exist.
**Assumed:** Fire2 framing correct; component/command IDs discoverable from captures; FUT REST shapes close enough to community guesses; no additional undiscovered gates.
**Evidence for:** Architecture is coherent. The M1 finding (gate precisely named and decoded) was achieved cleanly. The in-process hook approach is validated.
**Evidence against:** M2 was attempted and failed with the in-process approach. The event-driven architecture adds a full EbisuSDK emulation layer before even one Blaze byte is seen. The live toolkit is exhausted (Path A verdict); Ghidra-level work on a 505 MB binary is required. Six capture files with zero bytes.
---
### Track B — Clean-room spec deliverable (M1–M5 documented)
**What it delivers:** A documented map of the connection gate, LSX event sequence, Blaze auth surface (transport, framing, gate conditions, component IDs, TDF schemas). Valuable as an archival/community artifact even if Track A stalls.
**Effort:** Medium. M1 is done. M2–M5 documentation emerges as a by-product of engineering work. The spec itself (writing) is lightweight; the engineering to produce the captures is the cost.
**Proven support:** M1 complete and documented. connection-gate-findings.md is already a high-quality spec artifact.
**Assumed:** Same as Track A for the unconfirmed values, but the spec can mark them `TODO/CONFIRM` rather than needing to implement them.
**Evidence for:** The clean-room constraint means a spec is the only artifact that can be safely published. connection-gate-findings.md shows this approach produces real value. B finishes even if A is never fully playable.
**Evidence against:** Track B alone doesn't produce a playable FUT; it is a foundation, not an end-user product.
---
### Track C — FLE Lua bridge (local-match path, skip the backend gate)
**What it delivers:** FIFA 23 career mode or Kick-Off with an OpenFUT club's players and squad loaded via FLE's in-memory DB API. No online gate, no Blaze, no TLS. Fully offline from day one.
**Effort:** Low-to-medium. FLE is already loaded in the normal launch path. Tools exist (`tools/squad-exporter/`, `tools/profile-exporter/`). Primary unknown is whether FUT-relevant DB tables are accessible.
**Proven support:** FLE Lua API exposes `GetDBTableRows` / `EditDBTableField` for career mode. `fifa23-startup-flow.md` confirms FLE injects at load. `fut-integration-options.md` documents the integration path in detail and rates this as the recommended option.
**Assumed:** FUT card/club/squad data has in-memory DB table representations that FLE can write. If FUT data is purely server-side (loaded from EA servers, not from the Frostbite DB layer), Track C produces no FUT simulation at all — only career mode player stats.
**Evidence for:** Career mode already works with FLE edits (community precedent). Tools are present and designed for this path. No infrastructure work needed.
**Evidence against:** FUT in FIFA 23 uses server-side data. The cards in a player's FUT club, the coins, the squad — these are fetched from `fut.ea.com` REST APIs, not from the Frostbite embedded DB. FLE's `GetDBTableRows` likely exposes base player stats tables but not FUT item tables. The crucial test (run `export_squad.lua` while in FUT mode) has never been done.
---
### Recommendation
**Start Track C immediately as a parallel, low-cost validation.**
Run `export_squad.lua` in FLE while inside the FUT hub (or attempting to enter it). If FUT tables appear in the export, Track C is viable and is the fastest path to something a user can interact with. This test takes one session and costs nothing.
Simultaneously, **continue Track A/B with the next concrete RE step:** synthesize the ONLINE_STATUS_EVENT push. The most actionable option is to run `origin_spy` logs from the current hook to see what LSX events fire during a session, then attempt to push candidate event XMLs via the bridge LSX server and watch whether the game advances. This is bounded, testable work that either unblocks M2 or produces the spec value for Track B.
**Do not abandon Track A/B for Track C** — they are complementary. Core is already built; the bridge is mostly built. The gap is purely the RE wall at M2.
---
## 5. Architecture and Provenance Sanity-Check
### Hook + Brain coherence
The CLAUDE.md bridge architecture diagram (hook intercepts ProtoSSL → plain localhost TCP → blaze_brain → Core) remains coherent. The M1/M2 findings revealed one additional layer (EbisuSDK LSX event) that must precede the Blaze connection. The bridge has been updated to handle LSX directly. The overall design is sound; the M2 blocker is an implementation gap (event synthesis), not an architectural flaw.
**One inconsistency to flag:** The hook's `lsx.rs` contains a complete in-process LSX emulator (AES-128-ECB, CRandom, all response builders), but the recv/send hooks that activate it are explicitly removed (`lib.rs`: "recv/send hooks removed — LSX is now handled by the native openfut-bridge LSX server"). This is dead code. The bridge's LSX server is the current path. The in-process lsx.rs should either be deleted or documented as a fallback; its presence is confusing.
### Clean-room status
No evidence of EA leaked source anywhere in the tree. All RE work is derived from:
- Running the shipping binary and observing behavior (function return values, network traffic patterns)
- Memory scanning of the live process (string search, xref, disasm of observed addresses)
- Reading anadius's own compiled output (its exported symbols, its LSX XML format — which is anadius's own implementation, not EA's)
- Community FUT API knowledge (mapper.rs endpoint paths — plausible but speculative)
The Blaze framing in `fifa-blaze/crates/blaze-proto/src/frame.rs` cites "Fire2 used by ME3, BF3, and most post-2012 titles" — this is sourced from public community documentation of those older titles, not from any leaked EA source. **Clean-room intact.**
The `AES_KEY` in the hook's lsx.rs (`[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15]`) is a placeholder key used for the LSX session encryption. The real session key is derived from the challenge seed via CRandom — this algorithm was RE'd from anadius's own binary. No EA source required.
---
## 6. If You Read Only This
- **The project is blocked at M2.** FIFA 23 submits `GoOnline`, gets success, then waits for an async `ONLINE_STATUS_EVENT` push on the LSX socket that no current code ever sends. All six Blaze capture files are empty (0 bytes). No Fire2 frame has ever been decoded.
- **M1 is the only completed milestone.** The gate function (`GetInternetConnectedState @ anadius64.dll+0x27790`) is precisely named and its two-flag branch decoded. Everything after M1 is either blocked or not started.
- **The next concrete action** is synthesizing the ONLINE_STATUS_EVENT push XML and testing whether the bridge's LSX server can deliver it to the game. This is the single thing that unblocks all Blaze work.
- **Track C (FLE Lua) is untested but cheap to validate.** Run `export_squad.lua` while in FUT to find out if FUT DB tables are accessible. If yes, it is the fastest path to user-visible results. If no, it is ruled out with one session.
- **openfut-core is complete and ready** — 25 phases, 15 migrations, full economy REST API, passing tests. It is not blocking anything; it is waiting for the bridge to connect to it.
docs/track-c-fut-table-test.md
-93
View File
@@ -1,93 +0,0 @@
# Track C — FUT DB table viability test
**Status: PENDING — test has not yet been run.**
## What this test settles
Track C ("FLE Lua bridge") would inject OpenFUT club data directly into FIFA 23's
in-memory Frostbite DB tables at runtime, bypassing the entire backend/Blaze stack.
It is only viable for FUT (not just career mode) if FUT-specific tables — card
inventory, squad composition with FUT fields, coins — are accessible in memory when
the game is in the FUT area.
FUT data in online mode is fetched server-side from `fut.ea.com`. It is not known
whether FIFA 23 mirrors any of this into the Frostbite in-memory DB that FLE
can read/write. This test settles that question directly.
## Test procedure
**Prerequisites:**
- FIFA 23 launched normally via umu-run/Steam
- FLE (FIFA Live Editor) injected and active (normal launch path)
- EAAC in offline/neutralized state
- Game navigated as deep into FUT as possible (FUT hub if reachable; otherwise the
furthest FUT screen before the gate blocks it)
**Run the exporter:**
1. In FLE's Lua Engine, open and run `tools/squad-exporter/export_squad.lua`
(full path on the Windows side: `C:\<game>\openfut_squad_export.json`)
2. Wait for the MessageBox "Done! N players, M teams." or "ERROR writing..."
3. Retrieve the output file from the Wine prefix:
`~/Games/umu/fifa23-tools/drive_c/FIFA 23 Live Editor/openfut_squad_export.json`
(or wherever `C:\FIFA 23 Live Editor\` maps in the active prefix)
**What to inspect in the output:**
- `all_db_tables` array — the complete list of table names visible to FLE right now
- `fut_tables` object — any table whose name contains `fut`, `club`, `pack`, `item`, or
`market` (the script auto-extracts these)
- `is_career_mode` — confirms whether FUT or career mode was active
## Classification criteria
### "FUT tables present"
`fut_tables` is non-empty AND contains FUT-specific fields beyond base player stats:
- e.g., `fut_items` with card-type / rating / chemistry fields
- e.g., a squad table with FUT formation / chemistry / loan-flag fields
- e.g., a coins or points balance field
**Verdict:** Track C is viable for FUT. Fastest path to user-visible results.
### "only base player tables"
`fut_tables` is empty (no `fut_*` / `club_*` / `item_*` / `market_*` table names found
in `all_db_tables`), OR those tables exist but contain only base player attributes
(OVR, potential, position, pace, …) — the same fields visible in career mode.
**Verdict:** Track C cannot produce FUT. It could at most provide a custom Kick-Off or
career-mode match with players sourced from OpenFUT Core. FUT items and coins exist
only on EA's servers (not in the in-memory DB in offline mode).
### "FUT area unreachable to test"
The connection gate blocked entering FUT deeply enough for FUT tables to be populated.
Record which tables were visible and at what screen the test was run.
**Verdict:** Retest after M2 is unblocked, OR test with `TLS_ENABLED=false` bridge
handling the entry check stub.
## Results
*(To be filled in after the test is run.)*
| Field | Value |
|---|---|
| Date run | — |
| FIFA screen at test time | — |
| `is_career_mode` | — |
| Total tables in `all_db_tables` | — |
| FUT-specific table names found | — |
| Key FUT fields present | — |
| **Classification** | **PENDING** |
## Honest prior
`fut-integration-options.md` rates this as the recommended path and lists `fut_clubs`,
`fut_items`, `fut_squads` as "expected" tables. However those expectations are based on
analogy with career mode (which does store club/squad in the DB). FUT's data model is
architecturally different — it is account-bound server-side. The expectation may be
wrong. This test is the oracle.
The `export_squad.lua` script checks `GetDBTablesNames()` exhaustively (not just
assumed names), so it will surface any FUT tables that actually exist, regardless of
what name they use.
fifa17-recon/data/fifa17-kit-map.json
+28332
View File
File diff suppressed because it is too large Load Diff
fifa17-recon/data/futSelectTeam.syms
+934
View File
@@ -0,0 +1,934 @@
k|J|
tz^WU
Gb\X[
,j|L
cXXXX
gzW[rp
)l``b`
c^^^^
zrbnz
r--)
&jzzx
Jl```
c^^^\
----
k|X\^_
c\Xxx
K|bjk
cxxxx
---%
{xx|
cxxxz
Frxz
{VVVW
cpxz~
gr*:
sTVUU
cxz^W
[5555
px~M
cUUU5
cUU-
gz((+
&rX`
&kVX
cUUUx
&r^\
%%%%
&kUW
f[UUW
gcE[
$gcE[
cUU%
UUWT
xxxx
FsUU^
$ecF[
icD[
T\Rb
sUW|
UUU\
VUUU
BIGF
L286
Apt Data:1:7:8
game/globalComponents/globalComponents
game.globalComponents.ImageLoader
game/components/SelectTeam
game.components.SelectTeam
Coins
TournamentData
BackingFUT
VersusFUT
external.ion_fut.screens.futSelectTeam
__Packages.external.ion_fut.screens.futSelectTeam
__Packages.ion.manager.HelpProperties
EACondBold
10.000
Screen
RtIL
RYgO
7uOO
XsOY
2sOY
<@OY
BG&Y
3NuIL
7NuI
3NuI
3NstY
7uOY
&v>Y
&v>t
3NYN
7NYN
tOYZ
BG&v
NZGO
NZGOZu
uOZu
mcCup
txtPrizeHeading
txtCoins
mcCoin
mcBacking
txtVs
mcTournamentInfo
mcSelectTeam
mcVersusFUT
publishObject
dpID
nHomeKitID
nAwayKitID
keyCode
controllerId
nSide
arrKitIDs
teamId
kitToResolve
side
isUser
arrKits
objProperties
Void
nXPos
DDS |
NVTT
DXT5
8VTTT
UUVT
TTTU
0TUVT
TTUW
$$r
%UUU
WUUU
UUUSP
UUUM
UUUNK
72Ib
*72Ib
U;8I
WWWW?>I
UIFI
WWWWLKI
WWWVQNI
VVYVI
`]IB
daIB
heIB
VlhI
vtI"I
UU%!I
*;8I
U?>I
ULKI
Apt1
_global
external
Object
ion_fut
screens
futSelectTeam
futSelectTeam::futSelectTeam()
OnExitScreen
cafe
utility
Delegate
Create
game
globalClasses
ScreenManager
SetOnExitScreenCallback
m_nFlowState
EA_ZONE
gScreenFlowManager
getFlowState
ION_Platform
IsFinal
CardNotification
eState
FUT_OFFLINE_DRAFT
FUT_OFFLINE_TOURNAMENT
FUT_OFFLINE_SEASON
m_bAllowSelectAnyTeam
FUT/ALLOW_ANY_CPU_TEAM
ION_Customization
GetAardvarkIntValue
mcPanelHome
mcPanelAway
mcReadyHome
mcReadyAway
mcKitHome
mcKitAway
mcLockHome
mcLockAway
InitComponents
InitializeScreen
Initialize
screen
BaseScreen
prototype
futSelectTeam::InitializeScreen()
_visible
HOME_SIDE
GameServices
eTeamSide
SIDE_HOME
AWAY_SIDE
SIDE_AWAY
NEUTRAL_SIDE
SIDE_NEUTRAL
m_arrPanelData
Array
m_arrKitPanelData
futSelectTeam::InitComponents()
InitializeKitConfig
InitializeTeamConfig
SetTeamAndKitConfigs
UIFDataProviderList
FUT_USER_CLUB_DATA_DP
UIFUtility
RegisterDataProvider
FUT_OPPONENT_CLUBS_LIST_DP
FUT_OPPONENTS_SQUADS_LIST_DP
FUT_OPPONENT_SQUAD_LINEUP_DP
FUT_USER_SQUAD_LINEUP_DP
FUT_CREATE_MATCH_DP
FUT_GET_MATCH_KITS_DP
SetupReadyTexts
initSideInfo
SetPanels
m_arrPanels
m_arrKitPanels
KitSelectDP
TeamSetupDP
AnimateIn
AnimateInComplete
BeginAnimateIn
futSelectTeam::AnimateInComplete()
m_bHasAnimatedIn
checkForDisconnect
gScreenNotAborted
LocalEventHandler
InputManager
AddLocalEventHandler
SetHandlerId
refreshCurrentConnectionStatus
HelpManager
Update
futSelectTeam::OnExitScreen()
AnimationManager
ClearAnimations
UnregisterDataProvider
INJURY_POPUP_ID
PopupManager
DeletePopup
TOTW_BELOW_MIN_POPUP_ID
USER_BELOW_MIN_POPUP_ID
OPP_BELOW_MIN_POPUP_ID
OPP_HAS_NO_VALID_SQUADS_ID
Shutdown
ClearSavedOpponentData
SQUAD_ID
UUID_UPPER
UUID_LOWER
UIFActionList
ACTION_SAVE_OPPONENT_DATA
SendActionObj
Publish
futSelectTeam::Publish()
header
USER_CLUB_DATA
SetUserClubData
initVersusFUTComponents
OPPONENT_CLUBS
m_arrOpponentClubs
data
MATCH_CREATED
FUT_PAFC_GAME
GetCurrentCountryIndex
SQUADS
GetCurrentLeagueIndex
ACTION_ADVANCE
SendAction
eSoundEvent
PRIMARY_SELECT
playSound
m_bShouldWaitForPublish
OPP_SQUADS_LIST
SetOpponentSquadListData
SQUAD_LINEUP_LOADED
IS_USER
SetSquadLineup
KITS_AVAILABLE
LENGTH
KIT_
push
futSelectTeam::InitializeKitConfig()
SetupTeamsInfo
GetHomeTeamId
ACTION_MATCHDAY_HOME_TEAM_CHANGE
GetAwayTeamId
ACTION_MATCHDAY_AWAY_TEAM_CHANGE
ACTION_MATCHDAY_ADVANCE_KIT_SETUP
SetReadyStatus
FadeOut
GetKitArrayForFUT
HOME_KIT_ID
AWAY_KIT_ID
ION_Uniform
IsKitSelectCreated
EnterKitSelect
IsAlternatingMode
GetUnhighlightedSide
SetKitUnReady
InitializeKitsFromArray
Unhighlight
SetDisabled
SetHighlightedSide
GetHighlightedSide
Highlight
futSelectTeam::InitializeTeamConfig()
LEAGUE_ID
components
TeamSetupControl
TEAM_TOGGLE
GetUserSideForFUT
m_isInFUT
InitData
GetToggleValue
UpdateTeamInfo
m_bOpponentTeamInvalid
m_OppHasSquads
SetChemistryValue
ResetTeamInfo
FadeIn
SetupMouseSupport
SetWomenTeamsOnlyFilter
SetMenTeamsOnlyFilter
DeactivateReady
futSelectTeam::SetupTeamsInfo()
USER_TEAM_ID
ION_GameSetup
GetTeam
SetHomeTeamId
SetAwayTeamId
setCustomSelectionArray
Team
eAttribute
ION_Team
GetAttributes
futSelectTeam::LocalEventHandler()
WARNING: Preventing the user to move until a Publish occurs.
IsInTransition
Stop spamming buttons, the team select screen is in a transition.
GetUserControllerSide
GetScreenState
DataProviders
STATE_TEAM
InputCodes
LEFT
RIGHT
GetReadyStatus
DOWN
BACK
ADVANCE
OPTION_TOP
OPTION_LEFT
IsSwitchSidesActive
STATE_KIT
SetUniform
ExitKitSelect
RemoveKitLocks
ACTION_BACKOUT
CANCEL
SetKit
SaveKitsForMatch
FUT_TOTW_GAME
SetGoingToKickoffHub
SetHomeKitId
SetAwayKitId
GetHomeKitId
GetAwayKitId
ACTION_CREATE_MATCH
SetReady
SetKitReady
FUT_OPP_HAS_NO_VALID_SQUADS
PopupData
Okay_abbr2
AddButton
ShowPopup
ValidateFullLineUp
m_sInjuryOrSuspendedWarning
m_bConceptPlayersInSquad
FUT_DB_Players_Not_Playable
FUT_TOTW_BELOW_MIN_PLAYERS
FUT_BELOW_MIN_PLAYERS
FUT_OPP_BELOW_MIN_PLAYERS
COUNTRY_TOGGLE
LEAGUE_TOGGLE
ACTION_GET_USER_SQUAD_LINEUP
ACTION_GET_OPPONENT_SQUAD_LINEUP
GoToViewSquad
PlatformManager
IsMicrosoft
USER_NAME
length
gEaso
showGamercard
getHelpContext
futSelectTeam::getHelpContext()
STATE_INVALID
FUT_VIEW_SQUAD_HOME
ltxt
manager
HelpItem
CreateHelpItem
FUT_VIEW_SQUAD_AWAY
ViewGamerCard
CreateHelpTickerItem
futSelectTeam::InitializeKitsFromArray()
GetAllAttributes
TYPE_UPPER
ITEM_NAME
ITEM_ID
ASSET_ID
StyleManager
FONT_TILE_HS
SetTitleTextFormat
SetToggleOffset
globalComponents
BasePanel
STYLE_FIFTEEN
SetBasePanelStyle
KIT_SCALE
kits
ToggleWithImage
STYLE_TOGGLE
SetStrokeVisibility
CheckIsKitLocked
futSelectTeam::GetKitArrayForFUT()
GetNonConflictingUniformID
eSortType
SORT_ASCENDING
Uniform
eSortColumn
SORT_NONE
eFilter
FILTER_UNFILTERED
GetIDs
LOCKED
NAME
shift
futSelectTeam::initVersusFUTComponents()
text
Versus_abbr
_height
FUT_Tournament
GetOfflineActiveTournamentId
GetOfflineTournamentInfo
TROPHY_ID
trophy
getArtAssetPath
SCALE_ASPECT_CENTER
setScaling
setSize
setImage
FUT_UC_TOURNAMENT_BONUS
PRIZE_FINAL
ION_Localization
LocalizeInteger
_width
textWidth
FUT_COINS_OFFSET
futSelectTeam::GoToViewSquad()
isUserTeam
CLUB_NAME
BADGE_TEAM_ID
SQUAD_NAME
RATING
SQUAD_RATING
CHEMISTRY
SQUAD_CHEMISTRY
SHOW_CHEM_LINE
SCREEN
VIEW_SQUADS
setContextDataObject
loadOverlayScreen
futSelectTeam::SetUserClubData()
m_arrUserClubs
PUBLIC
CLUB_ABBR
EST_DATE
ACTIVE_SQUAD_ID
SIDE_NAME
Away_Side
Home_Side
futSelectTeam::SetOpponentSquadListData()
split
FUT_NO_VALID_SQUADS
futSelectTeam::SetSquadLineup()
SetTeam
futSelectTeam::GetCurrentCountryIndex()
futSelectTeam::GetCurrentLeagueIndex()
futSelectTeam::GetUserSideForFUT()
bIsDemo
GetLockRules
SIDE_LOCK
futSelectTeam::ValidateFullLineUp()
FUT_SquadManagement
GetOpponentSquadLineup
GetSquadLineup
FUT_NUM_PLAYERS_IN_SQUAD
CARD_ID
ION_Card
GetPlayerCardInfo
IS_DREAM_PLAYER
FUT_NUM_PLAYERS_IN_SQUAD_EXTENDED
gFutHelpers
GetInjuryOrSuspendedSquadWarning
futSelectTeam::SaveKitsForMatch()
SIDE
NUM_KITS
ACTION_SAVE_MATCH_KIT
FUT_TOURNAMENT_CUP_SCALE
INJURY_OR_SUSPENDED_POPUP
TOTW_NUM_PLAYERS_BELOW_MIN_POPUP
USER_NUM_PLAYERS_BELOW_MIN_POPUP
OPP_NUM_PLAYERS_BELOW_MIN_POPUP
OPP_HAS_NO_VALID_SQUADS
SCALE_NONE
SCALE_ASPECT
SCALE_ABSOLUTE
ASSetPropFlags
HelpProperties
mXPos
GetXPos
SetXPos
registerClass
hj\W
hj/U
UUUV
'Z`XV
j`XVW
b$9^
UW^}
hb>x
DA__\X
UWW^
HbCA
hjCA/
+{dA
b#9X7*
I^^|x
(Z``pP
Zxp`
\j~X
&j\xp
jXXXX
Fn%Vb=
xxxp
xh``
WWWW
r\XXX
xxz_
{XPpr
Hb__^\
`x|x
``xX
]{jp
xxhh
X\\\
U\T_
`pz~
_^^^
cq,6
-/+*+
jjjj
jJJj
_^Xp
WV\p
TTWU
```h
pWUU
\UUU
$I">
x^UU
/UUU
$IR`m
$IL#
cAxW
dI/U
&b%W
|UWV\
j_uyQ
|UUVT
|WT\\
j`ppp
|\\\\
bpppp
)---
||x||
bzzzz
s"#)5
K{&R
D(tFR```
j5555
){zxh`
hlUU_`
$Ithd
Ithd
hlUWVT
s(ljj
HR{O
IBww
@Bbb
Hl\\Xx
zzhh
@`pP
Htxxxx
hlHd
Ht%%%5
ZZ\\
H|xxxx
Hthd
xxxX
TV_]
H|hd
Xxx`
_\|p
pppP
H|xxxz
i|%%%5
pX\T
H|xzzz
(dHt
H|`xz_
UU^p
$G|(t
G|(t
(tG\
VTTT
kUUU5
(pXxx
XXXX
KOKK
'cUU^
hs'c
$Gk(c
Gk(c
~ZZX
GkUWx
GkUUU\
'Gk(c
p``H
zUU~
X`pxZ
sUWx
c```
@@@@
WVT\
Vw~U
_^_j
\XPp
^|~^
c``pX\
````
UUUU
\\\\
????
p~UU
Ib'b
X\WU
A*++
UUUX
VWUU
z^VW
W^x
\\\\j
TWVV
\^xx
W^~
VWVt
cI^xxp
k$)WWVT
)W_VT
$1VTVT
(\\\\
\\\\"
$1\\XX
pr`z
AXPp`
yU^r^
$I2,r
PZrC
U{Bz
{||Z
kkki
c`p^
cx6l
\\\\]
dIb`@@
pvv]
'z@@
XVUU
e9`p
UVVV
(.-5
JJJJ
cQxxx
(%-)+
VVVV
#9ZZxx
i-)-
1U_|
#9=*
VVTT
T\\X
X^__
5-)+
$I"'r
rrbJ
8)-%5
ZZZZ
jjjk
1^UUU
g1G)^
!XX\V
BIGF0
Apt Data:1:5:8
U555
Urpp
~B'j
5555
m*((
;RRRR
m***
:RRRR
`15555
sZPPP
`95555
Apppp
95555
{PPPR
RRRR
rrp_
&j2'
pppp
Ns%!U
%)%%%%
f)%!
` 6dC.kE!
Z%)70
1E!W
1E!U
f1E!
F1Xp*
9f)U
xUU\
JV~No
(n{$!
iJPPpp
<W\^
AqUW
{Cq_
U]P\
Pppp
TTTT
PPPp
,(;k
z^\x
\^VT
???/
btTVV
M{-/75
x~_^
TUWW
%555
(^xp`
UUWV
jR\T\\
1xp``
b\\\X
b557/
jZ'5
WWWh
^XPZ
zxxxx
1UWVT
h4Vb%
\^U?
\\\X
I*.$
Hb'A
9UU\
i--+
Wka@
P|WWW
UW^x
@PW^
czXX
++-5
`x@p
brp`
U%%%
\VUW
XPXX
WTTV
PPXX
zc9~^z
I"1-+
!*+*
TTVT
----Y
73 &
Av|z
`^UJ
xx~p
&jB1_
Y444$
xWU0
$_nO
G1BBBB
xxx^
xxz~
---=
***J
O"'@
7 '>
U`X\Y
h035^
Lw!f
&T@a
]8RR
[OAq
D/Oz%F
+1.^-
_,_Y
..^O
CG|!@
;}>|
nHT*
a8Nj
?'Un70
^[zM2Bj @
6nd[N
Z)MBc
wY=A
8p(a
:m"D
[dbt
E'0S
nT+bJuZ
V-:t
v)(n
(*s?p
cc?r
B%{r
-4Yi
sci,Iy
|3;=
<KB6
cCFVJ
J|jg
4VvVV6
p$$e&
4%1{
~%ew==_.
EFGFFED
[FFB}9
$"dOz%^-
mw77
ct3r
ecGB
*\JV
c&WV
w6GMq
13aB
$X~_
mMx%
;11sZR
'&'n
q&##>o
+:Z/Y
]:AY
$(+~
,^:(,
kp>C
luqYql
wf_q
XYX\
@p77
--X&q
{ cf
waF,
znrn;
VRwCE
5=#&
/J"}
_A4Z
gnB7%
q`Y
Q|!+
[MMA
**rV
)~U(w*,)m
Z*SVd
$#&qi
qmUW=
F"MN
HaA%e%
(T!]5(\
IK#k
v wQ
C(\M
];%P
7f&=kJ
%(oRtK
gRr?
+rq_
/==7
,IUk
D?t(zC,
\}oe
'^YY
nwzu
jdf,
i5hFc
z@xOrFp
aqgv
y^oT+
dZ13
d{g~
ttzi
p,@B
upqH
1{pl0
J4)~
&W<;@
p77Es
:aPw
`>(^&
lnW|
~+w8
fifa17-recon/data/live/fifa17exe_command_ids.txt
+278
View File
@@ -0,0 +1,278 @@
# FIFA17.exe runtime command/event id -> name registry
# Recovered 2026-08-24 from live pid 44405 (Denuvo-decrypted, /proc/PID/mem, read-only).
# CardsDLL live base 0x6ffffc0f0000; registration loop at live 0x147dd0000-0x147df8000.
# NOTE: this is a DIFFERENT namespace from CardsDLL's DataProvider id table.
# the same numeric id has a different name in each, matching the APT's split
# between game.uif.UIFDataProviderList and the action/command list.
#
0x0207 %d
0x0bb9 back
0x0bbb preScreenSucceeded
0x0bbc preScreenFailed
0x0bc0 clearTeamSheets
0x0be7 selectTab
0x0c15 optionSelected
0x0c2a leaveGameGroup
0x0c2c quitToHub
0x0dac UpdateStadiumCrests
0x0dac startStoryMode
0x2713 matchdayFixtureChange
0x271a evt_set_matchDay_offline_fixture
0x271b evt_team_setup_state
0x271c advanceDefault
0x271d advanceDefaultWithTeam
0x271e advancePran
0x271f feInitialized
0x2720 skipBootflow
0x2721 startBootflow
0x2722 bootflowStarted
0x2723 bootflowFinished
0x2724 bootflowSaveLoadFailed
0x2725 returnToPressStart
0x2726 showPressStart
0x2727 evt_load_personal_settings
0x2728 evt_settings_load_complete
0x2729 assetUpdate
0x272a pranUpload
0x272b pranDownload
0x272c controllerConfig
0x272d activateGameModeIntro
0x272e ActivateFullGame
0x272f startIntroFlow
0x2730 offlineEulaProfileSuccess
0x2731 offlineEulaProfileFail
0x2732 startIntroMatch
0x2733 abortIntroMatch
0x2735 setCareerType
0x2736 exitTitle
0x2737 evt_set_fullscreen
0x273e enterSubPanel
0x273f exitSubPanel
0x2742 evt_invite_accepted
0x2743 profileSignOut
0x2744 profilePrepareForSave
0x2745 logTelemetry
0x2746 enterPracticeArena
0x2748 navigationBackoutStart
0x2749 navigationBackoutContinue
0x274a navigationBackoutComplete
0x274b checkSpeechData
0x274c newsSharingSettings
0x274d leaveBootFlow
0x274e mainMenuProfileCreationDone
0x274f nonLeadProfileCreation
0x2750 nonLeadProfileLoad
0x2755 teamSheetAction
0x2758 evt_set_lead_profile
0x2759 evt_sign_out
0x275a notifySignOut
0x275b notifySignOutReady
0x275c notifySignOutTitleScreen
0x275d evt_sign_out_flow_ready
0x275e evt_sign_out_flow_not_ready
0x275f showSignOutPopup
0x2760 showSignOutTitleScreenPopup
0x2761 evt_dismiss_sign_out_popup
0x2762 evt_show_account_picker
0x2763 evt_lead_profile_recovered
0x2764 triggerSignOut
0x2765 checkLeadProfilePairing
0x2766 evt_lead_profile_paired
0x2767 evt_lead_profile_unpaired
0x2768 evt_lead_profile_controller_changed
0x2769 beginProfileCheck
0x276a endProfileCheck
0x276b evt_controller_disconnect
0x276c evt_notify_controller_disconnect
0x276d evt_controller_disconnect_flow_ready
0x276e evt_controller_disconnect_flow_not_ready
0x276f showLoadPersonalSettingsPopup
0x2770 showSavePersonalSettingsPopup
0x2771 feRenderInGame
0x2772 pvProfilerStart
0x2773 pvProfilerStop
0x2775 enterMatchDayTab
0x2776 exitMatchDayTab
0x2777 restartWithNewTeams
0x2778 playSecondLegFixture
0x2779 setupSecondLegFixture
0x277a welcomeToMatchDayLive
0x277b exitMatchDayLivePanel
0x277c enableAardvark
0x277d disableAardvark
0x277e conditionAardvark
0x2780 adaptiveDifficultyDetectedPopup
0x2781 adaptiveDifficultyUpPopup
0x2782 adaptiveDifficultyDownPopup
0x2783 adaptiveDifficultyDetected
0x2784 adaptiveDifficultyUp
0x2785 adaptiveDifficultyDown
0x2786 adaptiveDifficultyDisable
0x2787 adaptiveDifficultyReset
0x2788 adaptiveDifficultyKeep
0x2789 adaptiveDifficultyOverride
0x278c evt_countdown_done
0x278d evt_countdown_restart
0x278e evt_start_stadium_change
0x278f evt_wait_for_stadium_change
0x2790 evt_wait_for_stadium_change_bootflow
0x2791 evt_advance_to_wait_popup
0x2792 evt_advance_to_wait
0x2793 evt_stadium_background_loaded
0x2795 setupTournament
0x2796 createTournament
0x2797 createWomenTournament
0x2799 setWomenTournament
0x279a evt_sl_operation_started
0x279b evt_sl_operation_complete
0x279c evt_sl_operation_load
0x279d evt_sl_operation_boot_load
0x279e evt_sl_operation_save
0x279f evt_sl_operation_delete
0x27a0 FUTLoginComplete
0x27a1 requestDownload
0x27a2 backendEnter
0x27a3 backendExit
0x27a4 onlineLoginToEaPopup
0x27a5 onlineBootLoginToEaPopup
0x27a6 evt_onlineAlertPopup
0x27a7 evt_onlineBootLoginFailurePopup
0x27a8 evt_onlineLoginFailurePopup
0x27a9 onlineLoginPopupHide
0x27aa onlineLoginPopupShow
0x27ab evt_invite_flow_ready
0x27ac evt_invite_flow_not_ready
0x27ad inviteFlowAbortSaveLoad
0x27ae evt_verify_invite_nav_cleanup
0x27af downloadComplete
0x27b0 downloadFailed
0x27b1 spevnetNotAvailable
0x27b2 spevnetNotRegistered
0x27b3 spevnetNotRegisteredBeta
0x27b4 userBanned
0x27b5 showExitConfirmPopup
0x27b6 hideExitConfirmPopup
0x27b7 confirmExit
0x27b8 showRegisterConfirmPopup
0x27b9 hideRegisterConfirmPopup
0x27ba setStadiumPosition
0x27bb liveCompCountryDecision
0x27bc liveCompAllCountriesSelect
0x27bd liveCompLimitedCountriesSelect
0x27be liveCompAdvanceToTeamSelect
0x27bf liveCompRegistrationConfirm
0x27c0 liveCompEventListSuccess
0x27c1 liveCompEventListFail
0x27c2 postMatchHighlightExit
0x27c3 postMatchHighlightComplete
0x27c4 postMatchHighlightSelect
0x27c5 postMatchHighlightReelSelect
0x27c6 postMatchHighlightIRSelect
0x27cf leaveUpsell
0x27d0 purchase
0x27d1 advanceFromPMA
0x27d2 evt_transitionToPMADone
0x27d3 cutSceneCommand
0x27d4 cutScenePlay
0x27d5 loadCutScenesSubLevel
0x27d6 unloadCutScenesSubLevel
0x27d7 evt_enable_skip_cutscene
0x27d8 gmCutSceneStarted
0x27d9 gmCutSceneEnded
0x27da gmCutScenesSublevelLoaded
0x27db gmCutScenesSublevelUnloaded
0x27dc gmAirlockToGameplayEnded
0x27dd gmAirlockLoadComplete
0x27de evt_quit_to_training_hub
0x27e0 evt_training_allow_advance_to_game
0x27e1 checkOriginConnected
0x27e2 OriginIsOnline
0x27e3 OriginIsOffline
0x27e4 OIGOpened
0x27e5 OIGClosed
0x27e6 overrideOnlineStadium
0x27e7 smLoadFEStadium
0x27e8 smActivateFreeRoam
0x27e9 smGameOver
0x27ea smScenePrime
0x27eb smScenePrimeAndPrep
0x27ec smScenePause
0x27ed smSceneResume
0x27ee smMoment
0x27ef smMomentRepeat
0x27f0 smMomentComplete
0x27f1 smExitMomentState
0x27f2 smOnPlayScene
0x27f3 smConversation
0x27f4 smConversationComplete
0x27f5 smConversationNotification
0x27f6 smConversationNotificationComplete
0x27f7 smGameplayStartLoad
0x27f8 smGameplayLoadOver
0x27f9 smGameplayStart
0x27fa smGameplayOver
0x27fb smGameplayPause
0x27fc smGameplayResume
0x27ff smTweetConsume
0x2800 smHeroLoanedOut
0x2801 smSetupAcademyMatch
0x2802 smSetupAcademyTeams
0x2803 smStartIntroFlow
0x2804 smStartSeason
0x2805 smPlayMatch
0x2806 smEndMatch
0x2807 smGetTrainingSet
0x2808 smEnterTrainingTeamHub
0x2809 smEnterTraining
0x280a smPlayTrainingSessionVO
0x280b smPrepareTraining
0x280c smPlayTraining
0x280d smStopTraining
0x280e smStartSkillGame
0x280f smSimTraining
0x2810 smEndTraining
0x2811 smSave
0x2812 smAutoSave
0x2814 smLoad
0x2815 smSetScreenFlowLocation
0x2816 smGetScreenFlowLocation
0x2817 smGetHomeHubLocation
0x2818 smGetHeroLeague
0x2819 smCompleteMatchday
0x281a smEndInterviewPeriod
0x281b smHeroRemovedFromMatch
0x281c smEpisodicUploadCheck
0x281d smRetryEpisodicUpload
0x281e smNotifyMatchNotPlayed
0x281f matchFlowStart
0x2820 matchFlowHalftime
0x2821 matchFlowPostgame
0x2822 matchFlowEnd
0x2823 enterGameplay
0x2824 leaveGameplay
0x2825 forfeitMatch
0x2826 matchSetType
0x2827 simMatch
0x2828 simStarted
0x2829 simStopped
0x282a fbStartFlowEvent
0x282b stopSavedInput
0x282c changeSonyStoreBrowseMode
0x282d trialCheck
0x282e gotoTrialUpsell
0x754d retrieveManagerQuestData
0x7560 futWidgetShow
0x7561 futWidgetHide
0x7562 futWidgetLoad
0x7563 futWidgetUnload
0x7567 inviteAcceptedFUT
0x7568 futAddCriticalSection
0x7569 futRemoveCriticalSection
0x7572 exitDraftMode
0x7579 useSavedMatchData
0x757a useSavedMatchKits
0x7580 exitSbcMode
0x7587 setFUTServerEnvironment
0x9cc1 discardTeamSheet
0x9cc1 resetReady
0x9cd0 showKeyboard
fifa17-recon/docker/fifa17-python/.env.example
+29 -3
View File
@@ -1,11 +1,37 @@
# Copy to .env in this directory. Required for remote deployment.
#
# OPENFUT_ADVERTISE — the address of THIS host as seen from the game machine
# (105). The responders advertise it to the client for every next hop (Blaze,
# roster, UTAS, POW). Compose refuses to start without it.
# OPENFUT_ADVERTISE — the IP address of THIS host as seen from the game machine
# (105). Responders advertise it for Blaze, UTAS, telemetry, and QoS.
OPENFUT_ADVERTISE=203.0.113.10 # <- REPLACE with this host's LAN IP
# OPENFUT_BIND — address the listeners bind inside the container.
# Defaults to 0.0.0.0 (container-facing); the original all-on-localhost flow
# uses the loopback default baked into the responders when unset.
OPENFUT_BIND=0.0.0.0
# FIFA17's roster verifier accepts dNSName SANs but ignores iPAddress SANs.
# Advertise the certificate's DNS identity, then resolve that one hostname to
# OPENFUT_ADVERTISE on the client without changing the URL or certificate.
OPENFUT_ROSTER_HOST=winter15.gosredirector.ea.com:8081
# OPENFUT_SERVERS — which Python responders Docker runs (space/comma separated).
# Default (unset) = the server-side set: "blaze roster utas pow".
#
# This host is the SERVER (.120). Docker runs ONLY components that have NOT been
# migrated to a Rust host. During migration the Rust hosts (redirector / roster
# / utas) run OUTSIDE Docker; as each Python component is replaced, remove its
# name here so the two never serve the same role at once.
# blaze Blaze redirector + main + nucleus (bundled) :42127 :42130 :42131
# roster FUT roster-update XML :8081
# utas FUT/UTAS RS4 API :8099
# (Rust utas-host still proxies its non-/club routes here for now)
# pow POW / EASFC :8094 (+ content :8080)
# lsx Origin LSX bootstrap :4216
# CLIENT-SIDE: LSX runs on the game machine (.105) with autopatch, NOT
# on this server. Leave it OUT unless client and server share one box.
#
# Example — Rust already owns roster, so Docker should not also serve it:
# OPENFUT_SERVERS=blaze utas pow
# When you drop a component, also stop advertising / DNAT'ing its port to this
# container so the client is routed to the Rust host instead.
#OPENFUT_SERVERS=blaze roster utas pow
fifa17-recon/docker/fifa17-python/Dockerfile
+11 -7
View File
@@ -37,17 +37,21 @@ RUN set -eu; \
COPY data/ /app/data/
# Redirector TLS cert (CN/SAN = winter15.gosredirector.ea.com). ProtoSSL
# cert-verify is patched client-side, so a self-signed cert is fine. The pair is
# git-ignored (*.pem/*.key); regenerate if absent so a fresh checkout builds
# without extra steps.
# Redirector/roster TLS certificate. FIFA17's roster verifier compares only
# dNSName SAN entries, so deployment advertises winter15.gosredirector.ea.com
# through OPENFUT_ROSTER_HOST and resolves that hostname on the client. The
# entrypoint validates this stable certificate; it never reissues it for an IP
# SAN that the verifier ignores.
#
# OpenSSL remains in the image both to create the git-ignored keypair on a fresh
# checkout and to validate the configured DNS identity at startup.
RUN apt-get update && apt-get install -y --no-install-recommends openssl && \
rm -rf /var/lib/apt/lists/*
RUN if [ ! -s tools/redir_cert.pem ] || [ ! -s tools/redir_key.pem ]; then \
apt-get update && apt-get install -y --no-install-recommends openssl && \
openssl req -x509 -newkey rsa:2048 -nodes \
-keyout tools/redir_key.pem -out tools/redir_cert.pem \
-days 3650 -subj "/CN=winter15.gosredirector.ea.com" \
-addext "subjectAltName=DNS:winter15.gosredirector.ea.com,DNS:*.gosredirector.ea.com,DNS:*.ea.com" && \
rm -rf /var/lib/apt/lists/*; \
-addext "subjectAltName=DNS:winter15.gosredirector.ea.com,DNS:*.gosredirector.ea.com,DNS:*.ea.com,IP:127.0.0.1"; \
fi
# Bake a dataset manifest so every image is self-identifying.

Some files were not shown because too many files have changed in this diff Show More