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>
91 lines
4.1 KiB
Python
91 lines
4.1 KiB
Python
"""D2 QUICK SELL, batch 5: find the SECOND fcc_discardcoins computation site.
|
|
|
|
THE CONTRADICTION THIS RESOLVES.
|
|
Measured live (read-only, pid 134663): persistent FUT item objects carry, at
|
|
item+0x3c, exactly round_half_up(item_rating * price / 100) where price comes from
|
|
the fcc_discardcoins row (cardtype = item+0x4c, level = item+0x54, rare = item+0x58).
|
|
Two items with identical cardtype 6 / rare 0 but item+0x54 = 1 and 3 got 3 and 38,
|
|
which is only explicable if the level key really varies per item.
|
|
BUT inside FUN_18013fe00 the slot that feeds the "level" argument, [RBP+0x1b4], is
|
|
provably never written: a whole-DLL byte-pattern search for a modrm with
|
|
mod=10 rm=101 disp32=0x000001b4 finds exactly one operand in that function and it
|
|
is the LOAD at 0x18014109a (44 8b 8d b4 01 00 00). So a SECOND site must exist.
|
|
|
|
SEARCHES (all four dispatch forms considered; this is a byte/immediate search, not
|
|
a "== 0x" grep)
|
|
A. every function containing the divide-by-100 magic B8 1F 85 EB 51
|
|
(MOV EAX,0x51eb851f) or 0x51eb851f in any instruction, cross-referenced with
|
|
whether it also calls the db-query wrappers.
|
|
B. xrefs to the four literals "price" 0x1802231e4, "level" 0x180207848,
|
|
"cardtype" 0x180223208, "rare" 0x18022315c, "fcc_discardcoins" 0x1802231f0.
|
|
C. every caller of the db wrappers FUN_1801a0000 (from-table) and FUN_18019ff00
|
|
(where) and FUN_1801a0080 (get cell).
|
|
D. what writes item+0x54? search the whole .text for a dword store with
|
|
disp8/disp32 0x54 is hopeless, so instead: decompile the manager entry
|
|
mgr->vt[0xa08] target reached from FUN_18013fe00 and look for a level/tier
|
|
computation, and decompile the tier helper FUN_1800a9fe0 that an earlier
|
|
agent found returning 1/2/3.
|
|
|
|
CONTROL: search A must report FUN_18013fe00 (it contains MOV EAX,0x51eb851f at
|
|
0x180141123). Search B must report the single known xref 0x18014106d for
|
|
fcc_discardcoins. If either control misses, the search is broken.
|
|
"""
|
|
import traceback
|
|
|
|
try:
|
|
print("##### CONTROL + A: functions containing the /100 magic 0x51eb851f #####")
|
|
hits = {}
|
|
it = fm.getFunctions(True)
|
|
n = 0
|
|
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 "0x51eb851f" in t:
|
|
got.append((int(i.getAddress().getOffset()), t))
|
|
if got:
|
|
hits[int(f.getEntryPoint().getOffset())] = (f.getName(), got)
|
|
print(" scanned %d functions, %d contain the magic" % (n, len(hits)))
|
|
print(" FUN_18013fe00 present: %s" % (0x18013fe00 in hits))
|
|
for e in sorted(hits):
|
|
print(" %#x %s (%d sites)" % (e, hits[e][0], len(hits[e][1])))
|
|
|
|
print("\n##### B: xrefs to the query literals #####")
|
|
for nm, a in (("price", 0x1802231e4), ("level", 0x180207848),
|
|
("cardtype", 0x180223208), ("rare", 0x18022315c),
|
|
("fcc_discardcoins", 0x1802231f0)):
|
|
xs = xrefs_to(a)
|
|
print(" %-18s %#x : %d xrefs" % (nm, a, len(xs)))
|
|
for frm, typ, fn, ent in xs:
|
|
print(" %#x %s %s %#x" % (frm, typ, fn, ent))
|
|
|
|
print("\n##### C: callers of the db wrappers #####")
|
|
for nm, a in (("from-table 0x1801a0000", 0x1801a0000),
|
|
("where 0x18019ff00", 0x18019ff00),
|
|
("getcell 0x1801a0080", 0x1801a0080),
|
|
("rowcount 0x1801a00a0", 0x1801a00a0),
|
|
("select 0x1801a0280", 0x1801a0280)):
|
|
xs = xrefs_to(a)
|
|
fns = sorted({(ent, fn) for frm, typ, fn, ent in xs if ent})
|
|
print(" %-24s %d xrefs from %d functions" % (nm, len(xs), len(fns)))
|
|
for ent, fn in fns:
|
|
print(" %#x %s" % (ent, fn))
|
|
|
|
print("\n##### D: tier helper and the registration entry #####")
|
|
for a in (0x1800a9fe0,):
|
|
src = dec(a)
|
|
print("=" * 78)
|
|
print("FUN_%x len=%d" % (a, len(src)))
|
|
print("=" * 78)
|
|
print(src)
|
|
print(" xrefs to %#x:" % a)
|
|
for frm, typ, fn, ent in xrefs_to(a):
|
|
print(" %#x %s %s %#x" % (frm, typ, fn, ent))
|
|
|
|
except Exception:
|
|
traceback.print_exc()
|