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>
67 lines
2.8 KiB
Python
67 lines
2.8 KiB
Python
"""D2 QUICK SELL, batch 8: which of item+0x38 / item+0x3c does the client READ?
|
|
|
|
WHY IT MATTERS. In FUN_18013fe00 the two are mutually exclusive:
|
|
item+0x38 = discardValue exactly as the server sent it (atom 0xd7)
|
|
item+0x3c = the locally computed fallback, written ONLY when item+0x38 == 0
|
|
So if the UI reads +0x3c alone, serving a non-zero discardValue would make the
|
|
quick-sell figure render as 0. If it reads +0x38 alone, our current seed of 0 would
|
|
render 0 -- which contradicts the live club items, which all carry a correct value
|
|
in +0x3c and 0 in +0x38. The likely shape is a getter "return +0x38 ? +0x38 : +0x3c"
|
|
or a caller that ORs them. Find it.
|
|
|
|
METHOD. Scan every function; keep the ones whose instruction text contains BOTH a
|
|
"+ 0x38]" and a "+ 0x3c]" memory operand. Print the small ones in full. This is a
|
|
text search over decoded operands, so it catches loads through ANY base register,
|
|
which is the form an accessor uses -- unlike an RBP-displacement search.
|
|
|
|
CONTROL: FUN_18013fe00 itself must appear in the list (it has the store to +0x198
|
|
and +0x19c, but those are RBP+0x198 not "+ 0x38", so instead the control is
|
|
FUN_180141660, which is known to touch obj+0x54/+0x58/+0xb4 through RCX and must
|
|
show up in an equivalent scan for "+ 0x54]" and "+ 0x58]"). Both scans are printed.
|
|
"""
|
|
import traceback
|
|
|
|
try:
|
|
def scan(a_txt, b_txt, maxins=60):
|
|
out = []
|
|
it = fm.getFunctions(True)
|
|
while it.hasNext():
|
|
f = it.next()
|
|
ii = listing.getInstructions(f.getBody(), True)
|
|
n = 0
|
|
ha = hb = False
|
|
while ii.hasNext():
|
|
t = str(ii.next())
|
|
n += 1
|
|
if a_txt in t:
|
|
ha = True
|
|
if b_txt in t:
|
|
hb = True
|
|
if ha and hb:
|
|
out.append((int(f.getEntryPoint().getOffset()), f.getName(), n))
|
|
return out
|
|
|
|
print("##### CONTROL scan: '+ 0x54]' and '+ 0x58]' #####")
|
|
ctl = scan("+ 0x54]", "+ 0x58]")
|
|
print(" %d functions; FUN_180141660 present: %s"
|
|
% (len(ctl), any(e == 0x180141660 for e, _, _ in ctl)))
|
|
|
|
print("\n##### TARGET scan: '+ 0x38]' and '+ 0x3c]' #####")
|
|
tgt = scan("+ 0x38]", "+ 0x3c]")
|
|
print(" %d functions" % len(tgt))
|
|
small = [t for t in tgt if t[2] <= 40]
|
|
print(" %d of them are <= 40 instructions" % len(small))
|
|
for e, nm, n in sorted(small, key=lambda x: x[2]):
|
|
src = dec(e)
|
|
print("=" * 78)
|
|
print("%#x %s %d instructions len(src)=%d" % (e, nm, n, len(src)))
|
|
print("=" * 78)
|
|
print(src)
|
|
print("\n --- larger candidates (names only) ---")
|
|
for e, nm, n in sorted(tgt, key=lambda x: x[2]):
|
|
if n > 40:
|
|
print(" %#x %s %d ins" % (e, nm, n))
|
|
|
|
except Exception:
|
|
traceback.print_exc()
|