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>
98 lines
4.2 KiB
Python
98 lines
4.2 KiB
Python
"""ADVERSARIAL Q2. Batch.
|
|
|
|
Targets under attack:
|
|
(a) dim1 claim 4: "FUN_1800147f0 ... a miss returns NULL and the caller then
|
|
dereferences address 0x40, i.e. it would crash" -- ABSENCE OF A NULL CHECK.
|
|
Method: print the RAW DISASSEMBLY of FUN_1800147f0 from the CALL to
|
|
FUN_180014420 to the next 40 instructions, so a TEST/JZ is visible if present.
|
|
Control: the same raw-listing method applied to FUN_180014380's call sites,
|
|
where the decompiler DOES show a null test, must show TEST/JZ. Same form.
|
|
(b) dim1 claim 5: "+0x290 is written in exactly TWO places in all of CardsDLL".
|
|
objdump found 12 dword/qword writes at +0x290 plus one QWORD write at +0x28c
|
|
that covers it. Resolve the containing function of every one and decide.
|
|
(c) dim1 claim 9/10: model+0x94 = group ordinal, model+0x1a0 = sortPriority;
|
|
+0x1a0 pushed to no Flash field. Print FUN_18002c3c0 and FUN_180015d80 in full
|
|
and print their exact address ranges so the claim can be re-checked in objdump.
|
|
(d) dim1 claim 3: FUN_1800150d0 / FUN_180012950 / FUN_180014380 full.
|
|
(e) dim1 claim 7: FUN_180014580 / FUN_180014df0 six literals; enumerate.
|
|
(f) FUN_180014610 group-tile builder: does tile+0x9c really get the ordinal
|
|
(CHILD_CATEGORY) and tile+0xac the displayGroupAssetId? Recommendation #1
|
|
depends entirely on this.
|
|
"""
|
|
import sys, traceback, re
|
|
OUT = "/tmp/claude-1000/-home-alex-Documents-OpenFUT/8e521ca1-ca3e-4138-bb96-df1744dd1d30/scratchpad/store/adv/q2_out.txt"
|
|
try:
|
|
fh = open(OUT, "w")
|
|
def P(*a):
|
|
s = " ".join(str(x) for x in a)
|
|
print(s); fh.write(s + "\n")
|
|
|
|
TARGETS = [0x1800150d0, 0x180012950, 0x180014380, 0x180014420, 0x1800147f0,
|
|
0x180014610, 0x18002c3c0, 0x180015d80, 0x180014580, 0x180014df0,
|
|
0x18007e7f0, 0x18007d1a0, 0x18007dab0]
|
|
P("=== FUNCTION BOUNDS ===")
|
|
for t in TARGETS:
|
|
f = func(t)
|
|
if f is None:
|
|
P("%#x -> NO FUNCTION" % t); continue
|
|
P("%#x %-22s min=%#x max=%#x size=%#x" % (t, f.getName(),
|
|
int(f.getBody().getMinAddress().getOffset()),
|
|
int(f.getBody().getMaxAddress().getOffset()),
|
|
int(f.getBody().getNumAddresses())))
|
|
|
|
# (b) resolve containing functions of every +0x290 write objdump found
|
|
P()
|
|
P("=== (b) containing functions of every raw +0x290 / +0x28c write ===")
|
|
W = [0x180051da3,0x18007d3ba,0x18007f0c0,0x18008c777,0x18008fd45,0x1800d3564,
|
|
0x1800d43fc,0x18013454a,0x180189d84,0x18018caa3,0x18018e1ff,0x180191f77,
|
|
0x18015b885,0x180067eb0,0x180067ebf]
|
|
for w in W:
|
|
f = func(w)
|
|
P(" %#x -> %s @ %#x" % (w, f.getName() if f else "NONE",
|
|
int(f.getEntryPoint().getOffset()) if f else 0))
|
|
# is any of those functions in the store-screen vtable?
|
|
P()
|
|
P("=== store screen vtable 0x1801ff690 (first 48 slots) ===")
|
|
ents = set()
|
|
for off, tgt, nm in vtable(0x1801ff690, 48):
|
|
P(" +%#04x %#x %s" % (off, tgt, nm))
|
|
ents.add(tgt)
|
|
P("vtable also at 0x1801ff6f8 / 0x1801ff610 per the claim; dumping 0x1801ff610:")
|
|
for off, tgt, nm in vtable(0x1801ff610, 24):
|
|
P(" +%#04x %#x %s" % (off, tgt, nm))
|
|
|
|
# (a) raw disassembly around the FUN_180014420 call inside FUN_1800147f0
|
|
P()
|
|
P("=== (a) RAW LISTING of FUN_1800147f0 (whole function) ===")
|
|
f = func(0x1800147f0)
|
|
it = listing.getInstructions(f.getBody(), True)
|
|
n = 0
|
|
while it.hasNext():
|
|
i = it.next(); n += 1
|
|
P(" %#x %s" % (int(i.getAddress().getOffset()), str(i)))
|
|
P("instruction count:", n)
|
|
|
|
P()
|
|
P("=== (a-control) RAW LISTING of FUN_180014610 (whole function) ===")
|
|
f = func(0x180014610)
|
|
it = listing.getInstructions(f.getBody(), True)
|
|
n = 0
|
|
while it.hasNext():
|
|
i = it.next(); n += 1
|
|
P(" %#x %s" % (int(i.getAddress().getOffset()), str(i)))
|
|
P("instruction count:", n)
|
|
|
|
for t in TARGETS:
|
|
P()
|
|
f = func(t)
|
|
P("======== DECOMPILE %s @ %#x ========" % (f.getName() if f else "?", t))
|
|
src = dec(t, 300)
|
|
P("len(src) =", len(src))
|
|
P(src)
|
|
P("======== END %#x ========" % t)
|
|
fh.close()
|
|
except Exception:
|
|
traceback.print_exc()
|
|
try: fh.close()
|
|
except Exception: pass
|