OpenFUT/fifa17-recon/docs/plan-2026-08-06-refusing-modes.md

The refusing modes: Seasons, Draft, SBC/Objectives, Tournaments — where the greying is decided

Written 2026-08-06. One reconnaissance pass over the live gate-byte block and the six /hub mode sub-deserializers, then four parallel per-mode investigations (Seasons, Draft, SBC+Objectives, Tournaments), each followed by an independent adversarial verification round. FIFA 17 was running throughout as pid 24653, sitting at the FUT hub, and was read strictly read-only. No server was restarted, no server code was changed, no memory was poked, and FIFA was never launched or killed.

Slide for every live read: live = static - 0x180000000 + 0x6ffffc140000, i.e. slide 0x6ffe7c140000, re-derived from /proc/24653/maps and proved by tools/gate_byte_probe.py reporting CONTROL FNV MATCH against the FNV hasher prologue at 0x180180d00. CardsDLL is mapped from /mnt/games/FIFA 17/ CardsDLL_Win64_retail.dll; the on-disk copy read with objdump is /tmp/fut/cardsdll.dll, image base 0x180000000. Every address below is live-verified.

This document answers one question the brief posed: is the refusal of these four mode families decided by a server-reachable input we are failing to send (a hub mode sub-object, a massinfo member, a settings/config field, or a dedicated endpoint), or is it decided in the Denuvo-packed FIFA17.exe / Frostbite front-end with no server surface at all?

---

1. Headline — final verdicts (after adversarial verify)

Every mode was independently re-derived by a second agent that attempted to refute the first. All four refutations failed. All four verdicts stand.

Mode	Atoms	Final verdict	Confidence	Verify
FUT Seasons (offline + online + friendly)	friendlySeason 0x131, offlineSeason 0x1ec, onlineSeason 0x1f6	NOT_SERVER_REACHABLE	HIGH	agrees (SAME)
FUT Draft (offline + online)	draftSummary 0xe4	NOT_SERVER_REACHABLE	HIGH	agrees (SAME), strengthened
SBC + Objectives	objectivesForCurrentUser 0x1e3, allObjectivesForCurrentGameSpaceId 0x15	NOT_SERVER_REACHABLE	HIGH	agrees (SAME), prior chain corrected
FUT Tournaments	tournament 0x328, tournamentProgress 0x32c	NOT_SERVER_REACHABLE	HIGH	agrees (SAME)

There is no server fix for any of the four. Every server-reachable input that touches these modes is either cosmetic (a hub stat list feeding a caption/count), an output value the client emits and never branches on, or a settings byte that is already live=1 while the tile stays greyed. The decision lives in the packed front-end. This is the same shape as the transfer-market finding of the same day — except there the switch (userInfo.feature.trade) was ours to flip; here no such switch exists on the wire.

---

2. Ground truth

The named gate-byte block (FutDataManagerImpl, live pid 24653)

Names were resolved by finding the config serializer at 0x18006ccd0, which pairs each IS_*_ENABLED string key (.rdata 0x1801fc118..) with a getter vtable slot, then decoding each slot's accessor stub (0f b6 81 <disp32> c3) to its model displacement. All values read live, slide-proven.

Name	Displacement / slot	Live value
(unnamed)	+0x1fd24	0
(unnamed)	+0x1fd2c	1
(unnamed)	+0x1fd2d	1
IS_TRADING_ENABLED	+0x1fd2e (slot+0x270)	1
(unnamed)	+0x1fd30	1
(unnamed)	+0x1fd37	1
IS_FRIENDLY_SEASON_ENABLED	+0x1fd3a (slot+0x2b0)	1
IS_TOURNAMENT_QUIT_ENABLED	+0x1fd3b (slot+0x2b8)	1
IS_PROCESSING_STATE_ENABLED	+0x1fd3c (slot+0x2c0)	1
IS_DRAFT_MODE_ENABLED	+0x1fd3d (slot+0x2c8)	1
(unnamed)	+0x1fd3e (offline-draft-enable)	1
IS_STORY_MODE_REWARD_ENABLED	+0x1fd3f (slot+0x2d8)	1
IS_RETURNING_USER_REWARDS_SCREEN_ENABLED	+0x1fd40 (slot+0x2f0)	0
(unnamed)	+0x1fd41	0
(unnamed)	+0x1fd42 (allowGracePeriod, SBC)	0
(unnamed)	+0x1fd43	0
objectives-enable (corrected — see §5.3)	+0x1fd44	1
packOpeningAnimation	+0x1fd45	1
(unnamed)	+0x1fd46	1
(unnamed)	+0x1fd47	0
(unnamed)	+0x1fd48	1
IS_STORE_ENABLED	computed getter slot+0x280 @0x18011c600 (not a byte field)	(computed)

Every named gate byte that governs a refusing mode reads ENABLED=1 live. The only 0-valued *_ENABLED byte, IS_RETURNING_USER_REWARDS_SCREEN_ENABLED, does not gate any of the four mode families. This re-confirms the brief's prior ground truth: the gate-byte layer does not explain the refusals.

The six /hub mode sub-deserializers (/hub parser = FUN_180139610)

The hub parser reads 18 atoms via a running-sum sub/dec ladder; six dispatch to the refusing modes. Each nested sub-deser was read in full. None carries an enable/available/unlocked boolean.

Atom	Name	Sub-deser VA	Fields (all cosmetic/data)
0x131	friendlySeason	0x1801392a0	creationTime, dataVersion, opponentPersonaId, opponentUserPoints, round, seasonId, userPoints, defId (8 ints)
0x1ec	offlineSeason	0x18013c3a0	divisionId, gamesPlayed, points, progressDataVersion, totalGames (strings)
0x1f6	onlineSeason	0x18013c3a0 (shared)	divisionId, gamesPlayed, points, progressDataVersion, totalGames (strings)
0xe4	draftSummary	0x180138d60	draftState (str-enum), gamesWon (int)
0x328	tournament	0x18013dc00	id, assetName, imageFormat, silhouetteName, timeUntilEnd, tournamentType, AMATEUR, live_offline, offerState (display)
0x32c	tournamentProgress	0x18013df20	data, tutorialClientData (free-form std::map)

The recurring trap: several of these desers write a per-field byte (offline/onlineSeason [r14+0xa]=1; tournament [rdi+0x162]=1) that an early naive pass could mistake for a JSON enable flag. Every such write is a parser-local "field present" marker, written identically for every field — not a JSON-sourced availability input. This is the same class of mistake that made hub.tradePile look like a gate before it was shown to be a mere count.

---

3. FUT Seasons — NOT_SERVER_REACHABLE (HIGH)

Atoms: friendlySeason 0x131, offlineSeason 0x1ec, onlineSeason 0x1f6. Gate byte: IS_FRIENDLY_SEASON_ENABLED +0x1fd3a, live=1.

Evidence chain. The decisive site is the gate byte +0x1fd3a. A whole-.text grep finds exactly two references:

• Writer 0x18011dd2d: mov byte[rdi+0x1fd3a],al inside settings applier FUN_18011dc50, preceded by cmp dword[rbx+0x58],1 / sete al — the byte is (settings.field+0x58 == 1), sourced from config key friendlySeasonsEnabled. This is the only writer.
• Reader 0x18011c500: movzx eax,byte[rcx+0x1fd3a]; ret — a standalone vtable getter stub (slot+0x2b0). Its absolute address appears in the file exactly once, at the vtable, and grep finds no call/jmp to 0x18011c500 anywhere in CardsDLL .text. Its only consumer is the packed FIFA17.exe front-end via vtable dispatch.

The one server-writable input (friendlySeasonsEnabled → +0x1fd3a) is already 1 live, and the tile is still greyed — so the front-end does not gate on this byte alone; it reads additional non-server state.

• Hub sub-objects carry no enable flag. offline/onlineSeason share deser 0x18013c3a0, which FNV-hashes string keys and for each stores a division/games/ points/version stat; friendlySeason 0x1801392a0 is 8 numeric stats. The [r14+0xa]=1 write is the "field present" marker. These feed a caption/count.
• Settings/massinfo: friendlySeasonsEnabled is the sole season key the applier consumes → +0x1fd3a, already covered. No massinfo member carries a season enable. There is no onlineSeasonEnabled/offlineSeasonEnabled config key or gate byte anywhere in the DLL — verify enumerated all 24 gate-region getter stubs and the only season getter is +0x1fd3a.
• Dedicated endpoint: /season and /season/user routes exist in utas_server.py (guarded by FUT_MODES) but the client has never requested them — 0 season hits across captures/, 486 real ProtoHttp requests over ~30 boots, none for /season. And the tile greys at hub load, before any /season request could fire.
• Front-end: the only season-enable identifiers in the whole DLL are the config input friendlySeasonsEnabled and the output getter name IS_FRIENDLY_SEASON_ENABLED. The viewmodel names (futonlineseasonsviewmodel, futofflineseasonsviewmodel, futfriendlyseasons*viewmodel) live in the Denuvo-packed FIFA17.exe.

Authority boundary. friendlySeasonsEnabled is a server-writable input, but it is already at ENABLED with its only reader off-DLL (client). Offline/ online seasons have no server surface at all — no config key, no gate byte, no getter. The grey/refuse decision is client-side.

---

4. FUT Draft — NOT_SERVER_REACHABLE (HIGH, strengthened by verify)

Atoms: draftSummary 0xe4. Gate byte: IS_DRAFT_MODE_ENABLED +0x1fd3d, live=1.

Evidence chain. Cross-ref of displacement 0x1fd3d returns exactly two real sites (a lea to 0x1801fd3d8 and an instruction at address 0x18011fd3d are coincidental, not xrefs):

• Accessor stub 0x18011c4b0: movzx eax,[rcx+0x1fd3d]; ret (getter vtable .rdata 0x18021c568).
• Writer 0x18011dd5a: mov [rdi+0x1fd3d],al in applier FUN_18011dc50, al = (settings[rbx+0x5c]==1) = parsed enableDraftMode.

There is no cmp/test/branch on this byte anywhere. Its only CardsDLL consumer is the config serializer 0x18006ccd0, which walks the IS_*_ENABLED key table and call [rax+0x2c8] to emit the value outward. So IS_DRAFT_MODE_ENABLED is an output the client serializes, not an input any logic branches on.

The verifier strengthened this by finding a consumer the first pass missed: a flux "DESTINATION" navigation emitter around 0x1800b2700. At 0x1800b2711 it loads getter slot +0x2c8 (draft-enable, +0x1fd3d) into sil and slot +0x2d0 (offline-draft-enable, +0x1fd3e) into [rsp+0x21]. All six GOTO_DRAFT_DISABLED emit sites (0x1800b2cb2, 0x1800b2dc9, 0x1800b333b/347, 0x1800b349f/4a7) are guarded by test sil,sil / cmp [rsp+0x21],0 and route to GOTO_DRAFT_DISABLED only when those bytes are 0, else to GOTO_DRAFT_OFFLINE/ONLINE. Both bytes are live=1, so this emitter — the closest thing to a nav decision inside CardsDLL — already produces the ENABLED destinations, yet the tile is still greyed.

• Hub sub-object draftSummary 0xe4, member deser 0x180138d60: exactly two atoms — draftState 0xe3 (STRING → enum decoder 0x180138cc0, a resume-state enum: INVALID + 2..8) and gamesWon 0x13a (INT). Wrapper 0x18013980c loops ONLINE 0x1f1 / SINGLE_PLAYER 0x29d, each → 0x180138d60. No enable atom; draftState is the continue-state read after entry, not a tile gate.
• Settings/massinfo: atoms enableDraftMode 0xf9 / enableOfflineDraftMode 0xfa / enableSinglePlayerDraftMode 0xff land on sibling emit-only bytes +0x1fd3d/+0x1fd3e/+0x1fd3c via the same applier — none branched on.
• Dedicated endpoints: GET /squad/mode/draft/state (deser 0x180147070) and POST /purchase/mode/N/draft (deser 0x18014c260) are already routed in utas — but these are the post-click entry/session flow (render the draft screen, buy entry after the tile is pressed), not a tile-availability query.
• Front-end: token strings (USER_HAVE_DRAFT_TOKENS 0x1802055f8, GOTO_DRAFT_DISABLED 0x180209aa8, etc.) are bare key-name lea emitters with no greying branch. Decision is in the packed FIFA17.exe.

Authority boundary. The two server-writable inputs (enableDraftMode, enableOfflineDraftMode) are already at their enabled value, and every CardsDLL consumer of them (config serializer and the navigation emitter) already treats draft as enabled. The persistent greying is decided client-side on non-server state.

---

5. SBC + Objectives — NOT_SERVER_REACHABLE (HIGH, prior chain corrected)

Atoms: objectivesForCurrentUser 0x1e3, allObjectivesForCurrentGameSpaceId 0x15. No IS_OBJECTIVES/IS_SBC gate-byte name exists — the task premise that these are governed by no named FutDataManagerImpl gate byte is confirmed.

5.1 Hub sub-object = cosmetic list

In FUN_180139610 both objectives atoms share one arm: objectivesForCurrentUser 0x1e3 (0x180139794) and allObjectivesForCurrentGameSpaceId 0x15 (0x1801397ad) both jump to 0x1801398fe, guarded by the parser-local marker cmp BYTE [rsp+0x21],0x1, calling sub-deser 0x18013a7f0. That deser parses a nested objectives 0x1e2 array of records (element parser 0x18006c9b0) with no enabled/available/unlocked atom — it feeds the "MANAGER TASKS N/M" tile count/caption, the same cosmetic class as hub.tradePile.

5.2 No dedicated endpoint at the hub

The live log across 26+ hub sessions shows the client requests only /hub and /settings; it never calls /sbs/* (grep count 0) or any /objectives endpoint. utas_server.py has no /sbs route. No FutGetObjectivesServerResponse class exists — objectives are ManagerQuests, client-driven. The sbs/* structs that exist serve challenge content after entry, never polled at the hub.

5.3 The correction (verify fixed the first pass's chain)

The first pass mis-traced objectives to settings field [0x1c] → model +0x1fd28 (default 60). The verifier re-derived the settings jump table (dispatch 0x18013ca1e, byte-idx 0x18013ced4, jtbl 0x18013ce90) and found the truth:

• enableObjectives 0xfd and enableObjectivesAsManagerTasks 0xfe route to handler 0x18013cabd = clear-only-on-zero into settings field [0x70]; applier 0x18011ddc7 (cmp [rbx+0x70],1; sete al; mov [rdi+0x1fd44],al) maps it to model gate byte +0x1fd44 — which is inside the named gate block (not outside, as the first pass claimed), reads 1 (ENABLED) live, and has exactly one reader DLL-wide: a getter stub 0x18011c570 returning the byte to the front-end with no internal gating use.
• The first pass's +0x1fd28 (default 60) is actually squadBuildingSetsGracePeriodMinutes 0x2d0, a numeric grace-period param — behavioral, not availability.
• SBC side: enableSquadBuildingSetsFeature 0x100 falls in the dispatch gap (0x100-0x18=0xe8 > 0xe7 → DEFAULT/no handler), as do squadBuildingSetsClientData 0x2cf and squadChallenge 0x2d1. Only numeric SBC params have handlers (allowGracePeriod 0x18 → +0x1fd42, allowUntradeable 0x19 → +0x206f8, gracePeriodMinutes 0x2d0 → [0x1c]/+0x1fd28). No SBC availability model byte exists.

So the single server-controllable objectives-enable input (+0x1fd44) is already at 1 yet the tile refuses, and SBC has no server enable surface whatsoever.

Authority boundary. Objectives-enable is a server-writable byte already ON, read only by the client. SBC availability has no server surface — its enable key is in the settings dispatch gap and lands on no byte. Decision is client-side (futmanagerquestsviewmodel; providers FUT_MQ_QUESTS_DATA_DP / FUT_SQUAD_QUESTS_DP) in the packed FIFA17.exe.

---

6. FUT Tournaments — NOT_SERVER_REACHABLE (HIGH)

Atoms: tournament 0x328, tournamentProgress 0x32c. Gate byte: IS_TOURNAMENT_QUIT_ENABLED +0x1fd3b, live=1 — but this governs quitting a tournament, not tile availability, and no tournamentEnabled atom exists in docs/fut_atoms.tsv.

Evidence chain.

• Hub sub-objects, both cosmetic. tournament 0x328 deser 0x18013dc00 writes only display fields: id [rdi+0x150], round [rdi+0x160], timeUntilEnd [rdi+0x158], silhouette-int [rdi+0x15c], string blobs [rdi]/[rdi+0xa8] (assetName/silhouette/type), an imageFormat=="dds" render bool [rdi+0x163] (strcmp vs .rdata 0x180219400), and a tournamentType enum [rdi+0x154] decoded to live_offline 0x195/live_online 0x196/offline 0x1e8/online 0x1f0 — a categorization, not availability. The [rdi+0x162]=1 write is a record-completeness marker (all core fields present), not a JSON enable. tournamentProgress 0x32c deser 0x18013df20 builds a std::map (ctor 0x1801e5210) of string keys data 0xc9 / tutorialClientData ~0x353 — free-form clientData, no enable atom. (The earlier 0x28a = returningUserRewardsScreenEnabled label was a running-sum mis-decode; the true sum is 0xc9+0x28a=0x353 tutorialClientData.)
• Massinfo/settings. tournamentCoins 809 → +0x30 and teamOfTournamentWinner 776 (bool) → +0x34 appear only in the FutDestroyMatch reward deser 0x180121b60 — a match payout reached only after you are inside a tournament match; a reward count/trophy flag, not a tile gate. The settings applier switch 0x18013c6d0 has 42 arms; the only tournament arm is tournamentQuitEnabled 0x32D → +0x1fd3b (quit, live=1).
• Gate byte +0x1fd3b: getter stub 0x18011c660 is the vtable emit accessor the config serializer 0x18006ccd0 pairs with the JSON key to write it out — the client emits it, does not read it as a server input. Writer 0x18011dd3d, al = sete(cmp settings[rbx+off],1), defaults to 1. Already 1, wrong feature.
• Dedicated endpoint, never called. tournament_list (deser 0x180169ef0) and tournament_user (deser 0x180147cb0) exist in utas_server.py but grep over captures/ and the live /tmp/utas_server.log (3224 lines) finds zero ProtoHttp requests for any /tournament path across all boots — same as /season. The responses are never consumed.
• Front-end. No CardsDLL response deserializer writes any "tournament available/unlocked" field. eligibilities 0xf1 / unlocks 0x35c / available 0x3e are SBC/store vocab per docs/ENDPOINT_MAP.md, not wired to tournaments. Decision is in the packed FIFA17.exe.

Authority boundary. The only server-touchable tournament byte (IS_TOURNAMENT_QUIT_ENABLED) is an emitted output governing a different feature, already 1. Everything else is cosmetic hub data or post-entry reward data. Tile availability is decided client-side.

---

7. What changed vs the prior conclusion

The prior workflow examined only the FutDataManagerImpl gate bytes and concluded "no server fix" for these modes. This workflow re-opened the question by chasing the hub-atom lead — the six mode sub-deserializers we do not currently populate — plus massinfo members, settings arms, and dedicated endpoints.

The hub-atom lead does not change the conclusion for any mode. Per mode:

• Seasons: the hub friendlySeason/offline/onlineSeason sub-objects are numeric stat blobs (division/games/points), cosmetic like hub.tradePile. The [r14+0xa]=1 byte is a "field present" marker, not a JSON enable. No change — still NOT_SERVER_REACHABLE.
• Draft: draftSummary carries only draftState+gamesWon; verify additionally found the in-DLL navigation emitter already routes to the enabled destination on current live state. No change — verdict strengthened.
• SBC/Objectives: the objectives hub arm is a cosmetic list feeding "MANAGER TASKS N/M". Verify corrected the prior chain — the real objectives-enable byte is +0x1fd44 (inside the gate block, live=1), and SBC's enable key falls in a dispatch gap with no byte at all. No change to the verdict; the correction only hardens it.
• Tournaments: both hub sub-objects are display/clientData only. No change.

Net: examining the hub atoms was the right next step, and it closed the lead rather than opening a fix. Every server-reachable surface for these four modes is now accounted for and none is an availability input. The prior "no server fix" conclusion holds, now on much broader evidence.

---

8. Client-vs-server authority boundaries (explicit)

Surface	Who writes it	Who reads it	Is it a mode-availability gate?
Gate bytes +0x1fd3a/3b/3d/44 etc.	server (settings applier FUN_18011dc50)	client (getter stubs, off-DLL vtable dispatch) + config serializer 0x18006ccd0 (emit)	No — all live=1, never branched on inside CardsDLL
Hub mode sub-objects (0x131/1ec/1f6/e4/328/32c)	server (/hub body)	CardsDLL parsers → cosmetic captions/counts	No — no enable atom in any of the six desers
[r14+0xa]=1, [rdi+0x162]=1, [rsp+0x21]==1 markers	CardsDLL parser (local)	same parser	No — "field present" bookkeeping, never JSON-sourced
Settings config keys (friendlySeasonsEnabled, enableDraftMode, enableObjectives, tournamentQuitEnabled)	server (/settings)	applier → gate bytes → client	No — inputs already at enabled; readers are off-DLL
SBC enable (enableSquadBuildingSetsFeature 0x100)	—	—	No surface — falls in the settings dispatch gap, lands on no byte
Offline/online season enable	—	—	No surface — no config key, no gate byte, no getter
/season, /tournament, /sbs/* endpoints	server (utas, routed)	never requested at hub	No — client never polls them; tile greys before any request
DestroyMatch reward fields (tournamentCoins, teamOfTournamentWinner)	server (post-match)	reward payout	No — reached only inside a match
The greying/refusal decision itself	—	client (Denuvo-packed FIFA17.exe / Frostbite viewmodels)	This is the gate — and it has no server surface

The single load-bearing fact across all four modes: every server-writable enable input that exists is already at ENABLED live, its only reader is the client, and the tile refuses anyway. No response body we can send flips a state the front-end has already decided.