funman300
edab23f04a
Emulates FIFA 17's full online + Ultimate Team stack against an offline,
clean-room backend (no EA servers). Proven end-to-end 2026-08-01:
Origin login -> Blaze login -> device-trust -> the FUT hub.
Package:
- tools/openfut-fut.sh one-command orchestrator (start/stop/status/restart)
- tools/root_arm.sh idempotent host arm (sysctls, DNAT, /etc/hosts easw)
- tools/{lsx_responder_v2,blaze_responder_v3b,roster_server,utas_server,autopatch}.py
the 5 servers (Origin LSX :4216, Blaze :42127/42130/42131, roster :8081,
FUT/UTAS :8099) + heat2.py (Fire2/Heat2 TDF codec)
- FUT-RUNBOOK.md runbook + gate-ladder troubleshooting
- docs/, tools/login_dump/*.md the reverse-engineering write-ups
All findings are clean-room, from binaries we own; nothing from any leak.
The wire protocol maps 1:1 to FIFA 23.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PN5bmpDVQR1aXgefyWAt7o
3.7 KiB
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
- 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.
- 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?
- 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.
- 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.