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>
102 lines
4.1 KiB
Python
102 lines
4.1 KiB
Python
"""D2 QUICK SELL, batch 7: Q2 (assign vs add) and Q3 (bulk discard shape).
|
|
|
|
Q2 CONTEXT. FutDiscardCardServerResponse is a 0x38-byte object freshly allocated
|
|
per request by FUN_180127160 ("RS4:FutDiscardCardServerResponse", size 0x38,
|
|
vtable 0x180220488). Its deserialiser stores totalCredits with a plain
|
|
MOV dword [obj+0x28] and the item id with MOV qword [obj+0x30]; there is no
|
|
read-modify-write anywhere in the deser, and only two functions in the whole DLL
|
|
carry the 0x326 immediate. What remains is: who READS obj+0x28, and does that
|
|
consumer assign or accumulate into the wallet? Route to it: FUN_180127290 (vtable
|
|
slot +0xa0) dispatches to a delegate stored at servercall+0x50 / +0x60.
|
|
|
|
Q3 CONTEXT. FUN_180126f40 emits {"itemId":[<int64>, ...]} using atom 0x16d. Find
|
|
which of the three discard actions owns it (DiscardCard 0x1802cb230 factory
|
|
0x180123cd0, DiscardCardByRes 0x1802cb260 factory 0x180123ce0, DiscardACard
|
|
0x1802cb290 factory 0x180123cc0) and what url/method that action uses.
|
|
|
|
CONTROL for Q3: factory 0x180123cd0 must produce an object whose vtable slot
|
|
+0x08 is the request-body/url set that includes 0x180127570 (the "/%llu" single-id
|
|
url builder we have already seen on the wire as DELETE /ut/game/fifa17/item/<id>).
|
|
"""
|
|
import traceback, os, struct
|
|
|
|
OUT = "/tmp/claude-1000/-home-alex-Documents-OpenFUT/8e521ca1-ca3e-4138-bb96-df1744dd1d30/scratchpad/store/qs/"
|
|
|
|
|
|
def dump(tag, va, path=None):
|
|
try:
|
|
src = dec(va)
|
|
except Exception as e:
|
|
src = "// threw %r" % (e,)
|
|
print("=" * 78)
|
|
print("%s %#x fname=%s len(src)=%d (FULL)" % (tag, va, fname(va), len(src)))
|
|
print("=" * 78)
|
|
print(src)
|
|
if path:
|
|
open(OUT + path, "w").write(src)
|
|
return src
|
|
|
|
|
|
try:
|
|
print("##### Q3: the three discard action factories #####")
|
|
for nm, a in (("DiscardACard", 0x180123cc0), ("DiscardCard", 0x180123cd0),
|
|
("DiscardCardByRes", 0x180123ce0)):
|
|
dump("factory " + nm, a, "qs_fac_%x.txt" % a)
|
|
|
|
print("\n##### Q3: the pointer table around 0x1801f3118 #####")
|
|
for off in range(-0x40, 0x100, 8):
|
|
a = 0x1801f3118 + off
|
|
try:
|
|
v = qword(a)
|
|
except Exception:
|
|
continue
|
|
f = fm.getFunctionAt(addr(v)) if 0x180000000 <= v < 0x181000000 else None
|
|
print(" %#x -> %#x %s" % (a, v, f.getName() if f else ""))
|
|
|
|
print("\n##### Q3: url/method providers #####")
|
|
for a in (0x180126f00, 0x1801277c0, 0x180127800, 0x180068320, 0x180127890,
|
|
0x180122420, 0x18011f940):
|
|
dump("provider", a, "qs_prov_%x.txt" % a)
|
|
|
|
print("\n##### Q3: the url-suffix table entry 0x0d / 0x0e / 0x0f #####")
|
|
# the action rows point at a url index; print the table of url format strings
|
|
for i in range(0x28):
|
|
try:
|
|
p = qword(0x1801f2f00 + i * 8)
|
|
print(" idx %#04x -> %#x %r" % (i, p, rd_str(p, 60) if p else ""))
|
|
except Exception as e:
|
|
print(" idx %#04x ERR %r" % (i, e))
|
|
|
|
print("\n##### Q2: every RS4 class with 'Credit' or 'User' in the name #####")
|
|
for h in find_all(b"RS4:Fut"):
|
|
s = rd_str(h, 90)
|
|
if "Credit" in s or "UserData" in s or "UserInfo" in s:
|
|
print(" %#x %r" % (h, s))
|
|
for frm, typ, fn, ent in xrefs_to(h - 4):
|
|
print(" xref %#x %s %s %#x" % (frm, typ, fn, ent))
|
|
|
|
print("\n##### Q2: functions containing the credits atom 0xc0 as a compare #####")
|
|
it = fm.getFunctions(True)
|
|
n = 0
|
|
found = []
|
|
while it.hasNext():
|
|
f = it.next()
|
|
n += 1
|
|
ii = listing.getInstructions(f.getBody(), True)
|
|
got = []
|
|
while ii.hasNext():
|
|
i = ii.next()
|
|
t = str(i)
|
|
if ("CMP" in t or "SUB" in t) and (",0xc0" in t):
|
|
got.append((int(i.getAddress().getOffset()), t))
|
|
if got:
|
|
found.append((int(f.getEntryPoint().getOffset()), f.getName(), got))
|
|
print(" scanned %d functions, %d contain a CMP/SUB with 0xc0" % (n, len(found)))
|
|
for e, nm, got in found:
|
|
print(" %#x %s" % (e, nm))
|
|
for a, t in got:
|
|
print(" %#x %s" % (a, t))
|
|
|
|
except Exception:
|
|
traceback.print_exc()
|