funman300
0f2d66e8ca
A live run refuted the model the existing traces were built on. KIT_SET never
fires, KIT_GET reports KITS_AVAILABLE=0, and FUN_1801c3480 is entered 810 times
without ever seeing a kit (772 players +0x60=1, 24 zeroed +0x60=4, 12 players
+0x60=6, 2 type-2 +0x60=4). So the DP command 0x7576 ->
FutSquadServiceImpl::setAvailableKits path is simply not the one in use.
The selector is fed by a provider CardsDLL registers into the FIFA engine -
singleton FUN_1800338f0, vtable 0x1801f1d68, slot +0x08 enumerate and +0x10
describe - and no trace covered it. Three passive detours added:
KIT_ENUM FUN_180033770 logs the teamId asked for; it answers only for the
FUT club 130000 and otherwise forwards to the engine
default, so a real team id here means our club items
were never in scope.
KIT_DESC sub_180033430 decodes the packed id into (teamid, year, slot). A
descriptor whose triple does not equal the active
home/away triple is left untouched, which is what
makes the engine substitute its own catalogue kit.
KIT_SCAN FUN_1800d73d0 the club scan behind getActiveKit: reports HIT with
the item fields, or MISS meaning the active triple
stays zero.
Prologues were dumped from the analysed Ghidra project (cardsdll.dll, base
0x180000000). Every copy length is instruction-aligned and none of the three
prologues is rip-relative, so the plain installer is correct for all of them -
unlike FUN_1801c3480, which needs the relocating installer for its
MOV RAX,[rip+...]. Note FUN_1800d73d0's prologue compares EDX against 2, so rdx
is the home/away selector (2/3), not the cardtype an earlier note assumed.
All three log then tail-call: behaviour is unchanged.