Read-only /proc/PID/mem census of the client's resident club-item store, which
is what the pre-match kit selector actually consumes. No writes.
Resolves the whole chain from static RE rather than guessing offsets:
[CardsDLL+0x2e6398] -> owner object (FUN_18011a830 is a plain
global read)
owner->vtable[0x4e8] -> lea rax,[rcx+0x1f9d8]; ret, i.e. mgr is an
EMBEDDED subobject, not a pointer
mgr+0x108 .. mgr+0x110 -> club-item vector, stride 24
element+0x10 -> the item record (FUN_1800d73d0)
CardsDLL is located by its NEAREST PRECEDING NAMED mapping, because Wine maps PE
sections anonymously and the Wine heap is also rwx, so permissions do not
discriminate code from heap. The base is then sanity-checked against a known
immediate (mov edx,0x7575 at 0x180026fea) and the tool aborts rather than
reporting from a wrong base.
Field offsets are the ones already proven, and nothing else is interpreted:
+0x4c cardtype, +0x50 cardsubtypeid, +0x5c itemState, +0x60 category,
+0x94 teamid, +0xba teamkittypetechid (u16).
FIRST RESULT, live on the client parked at the pre-match kit selector:
players mgr+0x0d8: 23 slots, 18 non-null, all (cardtype 1, subtype 0)
club items mgr+0x108: 5 slots, 0 non-null
Five slots, every item pointer NULL. Five is the club's active club-item set --
home kit, away kit, badge, stadium, ball -- so the client knows it should hold
five and holds none. That is why FUN_1800d73d0 returns the 0x1802c2a28 sentinel
whose +0x10 is NULL, and why the tiles are untextured.
funman300