funman300
21a81ad63c
Multi-agent pass over the store subsystem, 11 agents, findings run through three
adversarial verifiers. Full writeup in docs/plan-2026-08-05-store-subsystem.md.
THE REAL DISCARD TABLE IS RECOVERED. quick_sell() paid an invented rating tier
(600/300/150/50) that was wrong for every single card. The real table is
fcc_discardcoins in the client's own game DB, 141 rows keyed (cardtype, level, rare),
read out of the running client and verified 22/22 against live items:
value = round_half_up(rating * price / 100)
level = 3 if rating >= 75, 2 if 65..74, else 1 (0x180141e8a..0x180141ea3,
derived from rating, NOT a wire field)
cardtype = FUN_1800d8330(cardsubtypeid), decoded from its jump table and checked
across every subtype 0..599 with zero disagreements
A 94-rated gold rare is 752, not 600. A 76 rare is 608, not 150. A 55 bronze is 17,
not 50.
This also closes a disagreement nobody had noticed: the CLIENT already computes and
displays the correct value locally whenever our discardValue (atom 0xd7) is 0 or
absent. FUN_18013fe00 stores our value at item +0x38 and the guard at 0x180141025
skips the local computation when it is non-zero. So the screen has been showing the
real number while the server paid a made-up one, on every quick sell ever made.
Verified beyond what the report claimed, because a missing table row pays ZERO and
that would be a regression the old flat tier could not produce: across all 236 items
in the live profile, 230 map to cardtype 1 and 6 to cardtype 6, and NOT ONE would pay
0 coins. Table reproduces at 141 rows and the worked example lands exactly.
ZERO WIRE CHANGE, FUT_DISCARD_TABLE default off. Nothing new is sent; only the coin
figure the server credits moves. This is the patch worth defaulting on after one
in-game check, which is simply quick-selling a card and seeing the coins paid match
the value the card was already displaying.
THE GROUPING BUG IS NOT IN CARDSDLL, and the fix ranked first would have wasted a
launch. Live in the running client all three display groups own exactly the right
pack, there is exactly one copy of each pack record in 4 GiB, and nothing we send is
mis-parsed. The parsed model is correct and the Scaleform layer picks the wrong pack
when turning a tile click into a category id. displayGroupAssetId is served as 1/5/6
while the screen's category field reads 3, and group tiles carry a hardcoded
CATEGORY_ID of 0. Confirmed by direct read: ordinal 3, assetId 6, i.e. Premium, while
the last click was Gold.
The heap map that made this possible, all scoped to one pid: display-group vector
control block, 3 elements of 0x108; group record fields at +0x00 sortPriority,
+0x04 displayGroupAssetId, +0x40 a one-element pack vector; inner pack record 0x1a8
with packType at +0x38, ids at +0x70/+0xac, price at +0xa0, quantities at +0xc0..+0xd0.
extPrice SHOULD BE DELETED, not corrected. Both sub-parsers read only
externalPriceId; amount and currency are discarded. Sending the key at all creates an
"mtx" currency row that switches on a real-money price line the client can never fill
offline, which is the literal "or %1s" on every tile.
A WORRY NOBODY HAD RAISED, and I confirmed it from our own logs: the client has sent
packId 6 on every purchase it has ever made, four for four tonight and six for six
across history. We have never observed a successful buy of anything but Premium Gold.
Also settled: FUT_STORE_DISPLAYGROUP=0 is the right resting state, argued from
mechanism rather than from history; FUT_USERINFO=packs stays off because the
unopened-pack counter is client-mutable and the flag ladder silently drops squadList;
POST /user is a latent hard freeze that has never fired because the client never
issues that POST.
Honest coverage: the ActionScript layer is unread by everyone and every remaining
store mystery lives there.
Live: 439 contract checks pass, market suite passes, both flags off.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
73 lines
3.3 KiB
Python
73 lines
3.3 KiB
Python
"""DIMENSION 5 pass 2: the pieces the CreateUser / unopenedPacks answers depend on.
|
|
|
|
HYPOTHESES
|
|
H1 FUN_18011a830 returns the model singleton (DAT_1802e6398 or similar), so its
|
|
vtable can be resolved LIVE and slot 0x4e0 identified.
|
|
H2 FUN_180142470 (the userData 0x36d arm of CreateUser) takes only the reader, so
|
|
it parses into a global, not into the response record.
|
|
H3 FUN_180141ee0 is the shared "read FIELD_NAME -> atom, advance to value" helper;
|
|
return 6 means "no value / null" and suppresses dispatch.
|
|
H4 The primitive getters 0x1801c7620 (BOOL) / 0x1801c79d0 (INT) / 0x180135ff0
|
|
(SKIP) determine whether a container fed to a scalar arm desyncs the reader.
|
|
|
|
CONTROL for the vtable slot question: slot 0x480 is used by the squadList(0x2d4) arm
|
|
of the SAME deserializer and is LIVE-CONFIRMED WORKING (MY SQUADS renders). Whatever
|
|
method resolves 0x4e0 must also resolve 0x480 to something sane; if it cannot resolve
|
|
0x480 the method is broken, not the target.
|
|
|
|
CONTROL for the stack-struct offset rule (record_off = 0x268 - N in FUN_18013af30):
|
|
displayGroupAssetId(0xda)->local_238 must give 0x30 and
|
|
displayGroupUseDefaultImage(0xdb)->local_230 must give 0x38, which is what an earlier
|
|
independent pass recorded for those two fields. Both are printed below from the asm.
|
|
"""
|
|
import traceback, os
|
|
|
|
OUT = "/tmp/claude-1000/-home-alex-Documents-OpenFUT/8e521ca1-ca3e-4138-bb96-df1744dd1d30/scratchpad/store"
|
|
|
|
try:
|
|
for name, a in [
|
|
("singleton_18011a830", 0x18011a830),
|
|
("userdata_180142470", 0x180142470),
|
|
("keyhelper_180141ee0", 0x180141ee0),
|
|
("bool_1801c7620", 0x1801c7620),
|
|
("int_1801c79d0", 0x1801c79d0),
|
|
("skip_180135ff0", 0x180135ff0),
|
|
("item_18013fe00", 0x18013fe00),
|
|
("storeroot_1801234e0", 0x1801234e0),
|
|
]:
|
|
src = dec(a, 300)
|
|
p = os.path.join(OUT, "dec_%s.c" % name)
|
|
open(p, "w").write(src)
|
|
print("== %s @ %#x declen=%d -> %s" % (name, a, len(src), p))
|
|
|
|
print("\n---- singleton getter, short ones printed inline ----")
|
|
for a in (0x18011a830, 0x180141ee0, 0x1801c7620):
|
|
s = dec(a, 300)
|
|
if len(s) < 2600:
|
|
print("\n### %#x (len=%d)\n%s" % (a, len(s), s))
|
|
else:
|
|
print("\n### %#x len=%d (see file)" % (a, len(s)))
|
|
|
|
# ---- CONTROL: stack offsets in FUN_18013af30 from the raw asm ----------
|
|
print("\n---- FUN_18013af30 stack-displacement control ----")
|
|
f = func(0x18013af30)
|
|
it = listing.getInstructions(f.getBody(), True)
|
|
want = {}
|
|
while it.hasNext():
|
|
ins = it.next()
|
|
t = str(ins)
|
|
for d in ("0xcd", "0xb4", "0x30", "0x38", "0xce", "0xcc"):
|
|
pass
|
|
want.setdefault("all", []).append((int(ins.getAddress().getOffset()), t))
|
|
# print the instructions immediately around each of the four atom arms
|
|
for label, site in (("0x35d unopened", 0x18013b7b0), ("0xda dGAssetId", 0x0),
|
|
("0xdb dGUseDefImg", 0x0)):
|
|
pass
|
|
# simpler: dump every instruction that writes a byte to a stack slot
|
|
for addr_i, t in want["all"]:
|
|
if ("MOV byte ptr [RSP" in t or "MOV byte ptr [RBP" in t
|
|
or "MOV dword ptr [RSP" in t):
|
|
print(" %#x %s" % (addr_i, t))
|
|
except Exception:
|
|
traceback.print_exc()
|