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>
95 lines
3.7 KiB
Python
95 lines
3.7 KiB
Python
"""D2 QUICK SELL, batch 4: settle where the "level" query key comes from.
|
|
|
|
MEASURED FACT (live memory, pid 134663, read-only): the fcc_discardcoins table
|
|
has 141 rows keyed (cardtype, level, rare) with level in {1,2,3} only -- there is
|
|
NO level==0 row. Three live club items decode exactly:
|
|
cardtype 1, level 3, rare 1 -> price 800 ; rating 94 -> 752 ; rating 75 -> 600
|
|
cardtype 6, level 1, rare 0 -> price 5 ; rating 55 -> 3
|
|
cardtype 6, level 3, rare 0 -> price 40 ; rating 95 -> 38
|
|
So the query MUST have been issued with level = 3 / 1 / 3, never 0.
|
|
|
|
But batch 2's instruction scan of FUN_18013fe00 found EXACTLY ONE reference to
|
|
[RBP + 0x1b4] (the slot the "level" argument is loaded from) and it is a READ at
|
|
0x180141099; the only write covering that slot appeared to be the 16-byte
|
|
MOVDQA at 0x18013ffa1. Something is wrong with that conclusion -- this is exactly
|
|
the absence trap. Find the write.
|
|
|
|
HYPOTHESES TO TEST, in order
|
|
H1 the MOVDQA source is not _DAT_1801f66a0, or that constant is not
|
|
56 01 00 00 | 00 00 00 00 | ...
|
|
H2 part of the atom switch lives outside the address set Ghidra assigned to
|
|
FUN_18013fe00, so the body-only instruction walk missed an arm. Test by
|
|
walking the whole address range 0x18013fe00..0x180141400 instruction by
|
|
instruction, ignoring function boundaries.
|
|
H3 the slot is written through a register-based pointer (LEA RAX,[RBP+0x160]
|
|
style) rather than an RBP displacement.
|
|
|
|
CONTROL: the same range-walk must find the KNOWN write to [RBP + 0x1ac]
|
|
(cardtype) at 0x180140e16 and the KNOWN write to [RBP + 0x1b8] (rareflag) at
|
|
0x180140cc5. Both are plain RBP-displacement MOVs, the same syntactic form as
|
|
the write being hunted, so finding them proves the walk sees this form.
|
|
"""
|
|
import traceback
|
|
|
|
try:
|
|
print("##### H1: the initialiser constant #####")
|
|
for a in (0x1801f66a0, 0x1801f66b0):
|
|
print(" %#x = %s" % (a, read_bytes(a, 16).hex()))
|
|
print(" asm 0x18013fe00..0x18013fff0:")
|
|
p = 0x18013fe00
|
|
while p < 0x18013fff0:
|
|
i = listing.getInstructionAt(addr(p))
|
|
if i is None:
|
|
p += 1
|
|
continue
|
|
print(" %#x %s" % (p, str(i)))
|
|
p += i.getLength()
|
|
|
|
print("\n##### H2/H3: whole-range instruction walk 0x18013fe00..0x180141400 #####")
|
|
want = ("0x1b4", "0x1b0", "0x1ac", "0x1b8", "0x214", "0x198", "0x19c")
|
|
p = 0x18013fe00
|
|
n = 0
|
|
hits = {w: [] for w in want}
|
|
lea160 = []
|
|
while p < 0x180141400:
|
|
i = listing.getInstructionAt(addr(p))
|
|
if i is None:
|
|
p += 1
|
|
continue
|
|
t = str(i)
|
|
n += 1
|
|
for w in want:
|
|
if w in t:
|
|
hits[w].append((p, t))
|
|
if "RBP + 0x160]" in t or "RBP + 0x1" in t and t.startswith("LEA"):
|
|
lea160.append((p, t))
|
|
p += i.getLength()
|
|
print(" walked %d instructions" % n)
|
|
for w in want:
|
|
print(" --- '%s' : %d ---" % (w, len(hits[w])))
|
|
for a, t in hits[w]:
|
|
print(" %#x %s" % (a, t))
|
|
print(" --- LEA of frame slots ---")
|
|
for a, t in lea160:
|
|
print(" %#x %s" % (a, t))
|
|
|
|
print("\n##### the atom-0x191 (level) question #####")
|
|
# find every immediate 0x191 anywhere in the range, in any form
|
|
p = 0x18013fe00
|
|
while p < 0x180141400:
|
|
i = listing.getInstructionAt(addr(p))
|
|
if i is None:
|
|
p += 1
|
|
continue
|
|
t = str(i)
|
|
if "0x191" in t or "0x18a" in t or "0x192" in t:
|
|
print(" %#x %s" % (p, t))
|
|
p += i.getLength()
|
|
|
|
print("\n##### callers of FUN_18013fe00 (maybe one pre-fills level) #####")
|
|
for frm, typ, fn, ent in xrefs_to(0x18013fe00):
|
|
print(" %#x %s %s %#x" % (frm, typ, fn, ent))
|
|
|
|
except Exception:
|
|
traceback.print_exc()
|