# Agent brief — implement Blaze Component 0x000A / cmd 0x0005 (FUT hang) (clean-room)

## Clean-room rule (HARD)
Derive ONLY from decrypted FIFA17.exe dumps + live /proc/PID/mem (`pgrep -x FIFA17.exe`, live 66672) +
our /tmp/blaze_responder.log + blaze_responder_v3b.py. NEVER leaked EA source/headers.

## Where we are — the WIN, and the new hang
This session cracked the ENTIRE FIFA17 login+connection gauntlet (each gate = a one-attr/one-value/one-type
responder fix). FIFA now: connects, Authentication::login (accepted), full post-login online handshake,
and the go-online connection STAYS ALIVE (the CONF-duration "30s" fix cleared "unable to connect").
**NEW HANG:** trying to enter FUT, FIFA spams **Component 0x000A / cmd 0x0005 — 11,459 times** in a tight
retry loop, because our Blaze responder has NO handler for component 0x000A and replies EMPTY (16-byte
REPLY, 0 payload) → FIFA is not satisfied → immediate resend → hang on a "connecting to FUT" spinner.

## The exact RPC (decoded from /tmp/blaze_rx/)
- Fire2 frame: component=**0x000A**, command=**0x0005**, msgType=MESSAGE, userIndex=0.
- Request payload (5 bytes) decodes via our heat2 to a single field: **`RSUB` (int) = 1**.
  (RSUB tag = 6-bit-packed; value 1.)
- We reply: `TX ... msgType=REPLY 16B total (0 payload)` — EMPTY. FIFA rejects/retries.
- Our responder's known components (blaze_responder_v3b.py ~:193): 0x0001 Auth, 0x0004 GameManager,
  0x0005 Redirector, 0x0007 Stats, 0x0009 Util, 0x000F Messaging, 0x0019 AssocLists, 0x001C
  GameReporting, 0x7802 UserSessions. **0x000A is NOT handled.** (Blaze framework: 0x000A is commonly
  CensusData; confirm from FIFA's own component registry, do not assume.)

## Questions to answer
1. **What is component 0x000A and cmd 0x0005?** Find FIFA's Blaze component/command REGISTRY (the
   reflection tables mapping component id -> name and cmd id -> name + request/response TDF class). Name
   the component (CensusData? a FIFA/OSDK component?) and cmd 0x0005 (subscribe? getData? a poll?).
   Region hint: FifaOnline::* reflection names live ~0x143900000; the Blaze SDK component dispatch is
   ~0x146d00000-0x147000000. RSUB is a request field — find the request TDF class with an RSUB member.
2. **What RESPONSE TDF does FIFA's decoder for 0x000A/0x0005 expect**, and what field/value makes FIFA
   STOP retrying (proceed into FUT) vs an empty reply? Reverse the client-side response handler /
   the code that reacts to this RPC's reply. Is it a poll-until-a-flag, a subscription ack, a
   count/list it needs non-empty, or an error-retry on our malformed/empty TDF?
3. **Why 11,459 immediate retries?** Is our EMPTY reply being decoded as an error (so FIFA retries), or
   is FIFA polling a status until a specific value appears? Determine the minimal reply that ends the loop.
4. **The fix**: the exact blaze_responder_v3b.py handler — register component 0x000A, handle cmd 0x0005,
   return the correct REPLY TDF (fields + values). Give the Heat2/TDF structure precisely (tags, types,
   values) and the observable success signal (FIFA stops resending 0x000A/0x0005 and issues the NEXT
   new RPC / reaches the FUT screen).

## Method / dumps
Our Blaze responder: blaze_responder_v3b.py (component dispatch, reply_to(), encode_tdf(), heat2.py).
Heat2 TDF codec: heat2.py (tags 4-char 6-bit packed; types 0 int,1 str,2 blob,3 struct,4 list,5 map,6 union).
Saved requests: /tmp/blaze_rx/rx_*_000a_0005.bin (21 bytes: 16 hdr + 5 payload). Log: /tmp/blaze_responder.log.
Dump FIFA live: /proc/PID/mem, objdump --adjust-vma. To find the response schema, locate cmd 0x0005's
response TDF class via FIFA's component reflection, or reverse the client handler that consumes the reply.
Every claim needs a VA/bytes/disasm/log line. CLEAN-ROOM: our binaries+logs only.