Files
OpenFUT/fifa17-recon
funman300 e3092ca0f9 fifa17-recon: the client now shows the quick-sell value it is actually paid
Follow-on to 21a81ad, both halves confirmed live.

FUT_DISCARD_TABLE IS PROVEN. Quick selling a 75-rated rare gold paid 600 and the
balance moved 9,844,900 -> 9,845,500, exact. The invented tier would have paid 150.
75 * 800 / 100 = 600, straight off the recovered fcc_discardcoins row.

BUT THE SCREEN SAID 0, which is why this commit exists. The value was right and
invisible: "Quick Sell 0" on the card and "Quick Sell all remaining Items 0" too, so
the wallet contradicted the display on every card. Cause is the guard the table work
had already reversed. FUN_18013fe00 stores our discardValue (atom 0xd7) at item +0x38
and 0x180141025 skips the client's own fcc_discardcoins lookup only when that value is
NON-ZERO. We seeded 0, so the client ran its own lookup, that lookup returns no row for
our cards, and it rendered 0.

FUT_DISCARD_SEND puts the value on the wire and the client uses ours verbatim. Live
result, one launch:
    a 77-rated rare gold shows "Quick Sell 616"   (77 * 800 / 100 = 616, exact)
    "Quick Sell all remaining Items" shows 5,640
and 5,640 is exactly the sum of the ten rated PLAYER cards in the pending pile. The
eleventh, a consumable, is excluded by the client from the bulk figure; the twelfth is
a staff card we deliberately send no value for. Both halves of the display now agree
with what the server credits.

WHY THE CLIENT'S OWN LOOKUP MISSES for our cards is still UNKNOWN. This routes around
that question rather than answering it, and it is worth answering.

TWO CORRECTNESS FIXES THE REPORT DID NOT COVER, both found by running the whole save
through the formula rather than trusting the 22/22 sample:
  * The recovered formula scales by rating, so a rating-less STAFF card collapses to 0.
    The old tier paid 50, so shipping it as-is was a regression. discard_value() now
    returns None when the formula does not apply and callers fall back. What FUT really
    pays for staff and consumables is UNKNOWN; the likely answer is the unscaled table
    price, but that is a guess and is not shipped as one.
  * A missing table row also returns None rather than 0, for the same reason.
  Verified across all 246 club items plus the pending pile: not one pays 0 coins.

discardValue is stamped inside the single item factory so every path gets it (pack
contents, starter grant, club, market), and additionally on the club READ path, because
_item() only covers cards minted from now on while the save already holds 246 built
before the flag existed. Stamped on the way out and NOT persisted, so the save stays
clean and turning the flag off is a true revert. Confirmed: 0 items on disk carry the
key.

FUT_DISCARD_SEND requires FUT_DISCARD_TABLE and silently stays off without it, so the
invented tier can never reach the screen and become authoritative-looking.

Freeze risk: low and in the safe direction. discardValue is a plain INT read by the
scalar getter 0x1801c79d0; every freeze on this project has come from an object or
array where a scalar was expected, never the reverse.

Both flags still default OFF. Live: 439 contract checks pass, market suite passes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-06 07:55:05 -07:00
..

FIFA 17 Blaze Recon (Rosetta Stone for FIFA 23)

Clean-room reverse engineering: all findings derive from observing our own running FIFA 17 client + static disassembly of the shipped binary we own. No leaked EA source is used or referenced.

WORKING: FIFA 17 Ultimate Team, 100% offline

The full online + FUT stack is emulated. Quick start → FUT-RUNBOOK.md:

cd tools && ./openfut-fut.sh start     # arm host + start all servers (re-run after reboot)
~/Desktop/launch-fifa17.sh             # then launch FIFA FRESH and select Ultimate Team

Proven end-to-end 2026-08-01: auth → Blaze login → device-trust → the FUT hub. The rest of this file is the reverse-engineering history that got there (see also login_dump/*.md, docs/*.md).

Breakthrough — 2026-07-30: ProtoSSL cert pin DEFEATED, redirector handshake captured

FIFA 17 dials the secure Blaze redirector winter15.gosredirector.ea.com over TLS 1.2 (RSA-kx). We MITM it with a self-signed cert and defeated DirtySDK/ProtoSSL's cert pinning with two live /proc/PID/mem patches, then captured the plaintext first-hop handshake.

Key architectural finding

The secure redirector is HTTPS + XML (ProtoHttp), NOT raw Fire2/Heat2:

POST /redirector/getServerInstance HTTP/1.1
Host: winter15.gosredirector.ea.com:42230
User-Agent: ProtoHttp 1.3/DS 15.1.2.1.0 (Windows)
Content-Type: application/xml
<serverinstancerequest>...</serverinstancerequest>

Fire2/Heat2 binary is the second hop — the redirector replies with a <serverinstance> XML naming a Blaze server IP:port; the client then connects THERE for the binary protocol. Full request body in captures/getServerInstance_request.http.

Reproduce (after reboot — all live state is volatile)

Binary maps flat at base 0x140000000 under Wine/Proton (UMU-Proton-10.0-4, prefix ~/Games/umu/fifa17). VAs below are stable across launches.

1. Root arm (scratchpad/root_arm.sh via pkexec)

  • sysctl kernel.yama.ptrace_scope=0 (enables /proc/mem WRITES)
  • sysctl net.ipv4.conf.lo.route_localnet=1
  • iptables -t nat -A OUTPUT -p tcp -d 159.153.51.20 -j DNAT --to-destination 127.0.0.1:42127 (winter15 resolves to 159.153.51.20; a /etc/hosts entry for winter15 would short-circuit the DNAT and must be ABSENT)

2. TLS capture server

scratchpad/blaze_tls_capture.py on 127.0.0.1:42127, presents redir_cert.pem (self-signed, CN+SAN=winter15.gosredirector.ea.com), ciphers ALL:@SECLEVEL=0.

3. The two cert-verify patches (via scratchpad/memtool.py)

The cert handler lives at ~0x14613252x. Two gates:

VA Role Patch
0x146132548 Gate 1: jne 0x1461326c4 (UNKNOWN_CA branch after chain-verify call 0x146136410) 6 bytes → 90 90 90 90 90 90 (NOP)
0x1461361b0 Gate 2: the real pin — cert verify helper; returned -51 (0xffffffcd) live 3 bytes → 31 c0 c3 (xor eax,eax; ret)

Gate 2 (0x1461361b0) is the decisive one — a shared verify helper (also called from 0x146131f86). Forcing it to return 0 makes r12d=0, the je 0x14613262d at 0x14613256c is taken, and the accept path at 0x146132675 is reached (skips the UNKNOWN_CA alert send at 0x146135250).

NB: last session's patch of 0x146136410 (chain-verify callee) did NOT work — it was not the function returning the live failure. gdb breakpoint on 0x1461361b0 proved Gate 2 was the wall (eax=0xffffffcd).

Breakthrough #2 — 2026-07-30: BOTH HOPS DEFEATED, Fire2/Heat2 decoded

Built tools/blaze_responder.py: answers getServerInstance over TLS with a <serverinstanceinfo> that redirects the client to a local plain Blaze port, and captures the second-hop Fire2 binary. The client accepted the redirect and connected, sending its Util::preAuth handshake in binary Heat2. tools/decode_fire2.py decodes it.

getServerInstance response schema (the redirect)

ServerInstanceInfo.address is a ServerAddress union; Heat2 XML encodes a union as <field member="N"><valu>...</valu></field>. Working response (member=0 = ipAddress variant):

<serverinstanceinfo>
  <address member="0"><valu>
    <hostname>127.0.0.1</hostname><ip>2130706433</ip><port>42130</port>
  </valu></address>
  <secure>0</secure>
  <trialservicename></trialservicename>
  <defaultdnsaddress>0</defaultdnsaddress>
</serverinstanceinfo>

<ip> is a decimal uint32 host-order (2130706433 = 127.0.0.1). <secure> 0/1 picks plaintext vs TLS for the Blaze connection. (Schema cross-confirmed clean-room vs MEC Catalyst private-server projects; response types reversed from the client's own TDF reflection tables at ~0x143891xxx / 0x144873xxx.)

Fire2 frame header (16 bytes, big-endian)

[0:4] u32 payloadLength   [6:8] u16 component   [8:10] u16 command
[10:12] u16 error/msgId    [12] u8 msgType       [13:16] reserved

First RPC observed: component 0x0009 = Util, command 0x0007 = preAuth, msgType 0x02. Ping/pong keep-alives: Util command 0x0002, empty payload, msgType 0x01/0x03.

Heat2 TDF encoding (decoded in decode_fire2.py)

Per field: 3-byte tag (4 chars, 6-bit packed, char = v?v+0x20:' ') + 1 type byte + value. Types: 0x00 int(varint, first byte 6 data bits + continue@0x80), 0x01 string(varint len incl null + bytes), 0x02 blob, 0x03 struct(nested, 0x00 terminator), 0x04 list, 0x05 map, 0x06 union.

preAuth codebook (Util::preAuth PreAuthRequest) — captures/blaze/preauth_decoded.txt

CDAT{ IITO:int LANG:int SVCN:str='fifa-2017-pc' TYPE:int }
CINF{ BSDK='15.1.1.3.0' BTIM='Jun  9 2017 16:15:40' CLNT='FIFA17' CPFT:int=4
      CSKU='FIFAPC' CVER='3175939' DSDK='15.1.2.1.0' ENV='prod' LOC:int PTVR='1.1' }
FCCR{ CFID='BlazeSDK' }
LADD:int

Same fields as the XML getServerInstance request → XML and Fire2 are the two encodings of the same TDFs (the Rosetta mapping).

(Fire2 header was later CORRECTED: byte[12] is the low octet of a 24-bit msgNum, not msgType; msgType lives in byte[13] high bits = (msgType<<5)|userIndex. REPLY=1→0x20, NOTIFICATION=2→0x40. metadataLen is u16 at [4:6]. See tools/heat2.py / blaze_responder_v3b.py.)

Breakthrough #3 — Origin/LSX layer defeated (PreAuthResponse + login flow work)

tools/blaze_responder_v3b.py answers preAuth, ping, fetchClientConfig, login (1/0x0A), getAccount(1/0x1E)=AccountInfo, getPersona/listPersonas, and pushes UserAuthenticated (0x7802/8). But Blaze isn't the online gate — Origin is, via its own in-process LSX layer:

  • The Steampunks stp-origin_emu.dll serves LSX (length-prefixed, NUL-terminated XML) IN-PROCESS on 127.0.0.1:4216. It's a blind fixed-script replayer that reports OFFLINE. Replace it: bind 4216 BEFORE launching FIFA (tools/lsx_responder_v2.py; the stub has no SO_REUSEADDR and stands down cleanly), serve real request-driven LSX.
  • LSX crypto (reversed + verified byte-exact): server sends <Challenge key="<32hex>">; client replies <ChallengeResponse response="<96hex>" key="<32hex>">; H = hex(AES128-ECB(K=000102..0f, PKCS7pad16(clientKey_ascii))) (32 ASCII → 48 bytes/3 blocks); server sends <ChallengeAccepted response="H">; session key = srand(7) LCG of H; later msgs = hex(AES-ECB(pkcs7(xml)))+NUL.
  • LSX verbs to answer: GetProfile(PersonaId=33068179 Persona=CAGE US), GetSetting UPPERCASE (ENVIRONMENT→"production", LANGUAGE→"en_US", else "false"), GetGameInfo (LANGUAGES→locales, UPTODATE→"true" [else "title version outdated"], FREETRIAL→"false"), GetInternetConnectedState→connected="1" [the online gate], etc.
  • Gates cleared this way: "log in to Origin" ✓ and "title version outdated" ✓.

Breakthrough #4 — 2026-07-30: repack fully reversed (LSX contract is a byte-exact oracle)

The Steampunks repack ships two UPX-packed helpers; we unpacked and clean-room reversed BOTH (multi-agent workflow, adversarially verified — full report docs/REPACK_INTEL.md, emu disasm docs/emu.asm). Unpack recipe: upx -d stp-origin_emu.dll and upx -d _fifa17.exe (emu base 0x180000000, loader base 0x140000000; both are NORMAL PEs — objdump works, unlike the encrypted FIFA17.exe). Findings that matter:

  • stp-origin_emu.dll = the reference LSX server, offline BY CONSTRUCTION. It is a blind 18-step straight-line script with NO parser and NO dispatch branch; its ONLY unsolicited frame is the plaintext Challenge; it hardcodes connected="0" and has NO <Login> event / no auth vocab anywhere in its 19,456 bytes. Structural proof (not absence-of-evidence): nothing in the repack can flip m_isLoggedIn. The login mechanism lives ONLY in FIFA17.exe's live-decrypted code.
  • Our lsx_responder_v2.py is CONFIRMED byte-exact on framing (NUL-terminated, NUL counted in send len), crypto (AES-128 K_FIXED=000102..0f, PKCS7, srand(7)→61 session-key LCG), event shape, sender values (EALS / EbisuSDK / ""), and encryption timing (plaintext through ChallengeAccepted id=1, encrypted from id=2). Applied hardening C1C3 (emu-exact challenge_response + tail assert, extract response=", partial-frame buffering). Selftest still green (session key unchanged).
  • The loader is an offline keygen/launcher (no WS2_32, no injection, no Blaze/Nucleus strings); its .dlf GameToken is a local ENTITLEMENT grant, not a session — will not help login. Shared build constants: UserId/PersonaId 33068179, MachineHash == LSX Challenge key 2b8ee7fa…e32 (fixed).

CURRENT WALL — "Unable to retrieve account information" (m_isLoggedIn stays 0)

FIFA has two Origin flags — "internet reachable" (fed by GetInternetConnectedState, DONE) and "user LOGGED IN" = OriginMgr.m_isLoggedIn @[OriginMgr+0x13], whose only setter is dispatcher case-2 @0x146f1e0ab, driven by a server-PUSHED <Event sender="LOGIN_EVENT"><Login IsLoggedIn="true"/>. Pushing it 90× did NOT flip the flag. Breakthrough #4 RULED OUT three causes: framing, event shape, and encryption timing are all confirmed correct. Surviving hypotheses, narrowed: (1) encrypted mid-session Events are dropped — the emu's only Event is plaintext+pre-key, so there is zero evidence FIFA routes an encrypted Event to the same parser (STRONGEST); (2) sender name mismatch; (3) handler-registration timing. Deeper residual: LoginStatePCLogin @0x1471b58e0 may gate on a session OBJECT [0x144b86bf8]->vtbl+0x60, not the flag.

THE decisive next experiment (observe, don't guess) — new tooling ready

  1. Relaunch harness+game (below), run responder with an UNBOUNDED heartbeat so pushes stay in flight: OPENFUT_LSX_EVENT_COUNT=100000 python3 -u tools/lsx_responder_v2.py
  2. bash tools/trace_login.sh — attaches gdb, traces the sender matcher (0x147102880), the parser (0x147138660), and dispatcher case-2 (0x146f1e09e / set-1 0x146f1e0ab / set-0 0x146f1e0b8). Answers the 3-question ladder in ONE run: does the frame reach the matcher? what sender does it strcmp against (dumps the table entry)? does case-2 run and the flag flip?
  3. If the trace shows the ENCRYPTED frame never reaches the matcher → run the A/B: OPENFUT_LSX_LOGIN_PLAINTEXT=1 … pushes the Login Event in plaintext right after ChallengeAccepted.
  4. tools/dump_login_code.py — dumps + disassembles the decrypted login machinery at true VAs for a follow-up static pass if the trace points below the dispatcher.

How to resume (rebuild the volatile harness)

  1. pkexec sh tools/../scratchpad/root_arm.sh (ptrace_scope=0, route_localnet, DNAT 159.153.51.20→42127).
  2. python3 -u tools/lsx_responder_v2.py — bind :4216 BEFORE launching FIFA.
  3. python3 -u tools/blaze_responder_v3b.py — :42127 (redir TLS) / :42130 (blaze) / :42131 (nucleus).
  4. python3 tools/autopatch.py — re-applies the two ProtoSSL cert patches to any relaunched FIFA17.exe.
  5. Launch FIFA via ~/Desktop/launch-fifa17.sh; go Online.
  6. Watch /tmp/lsx.log (LSX) + /tmp/blaze_responder.log (Blaze); use tools/origin_login_probe.py to read m_isLoggedIn. Everything is volatile across reboot; VAs are stable (base 0x140000000).

Live-state note

Volatile across reboot: cert patches, responders, DNAT, ptrace_scope. tools/autopatch.py re-applies both cert patches automatically to any relaunched FIFA17.exe (VAs are stable). Everything ported here (framing, Heat2, LSX crypto, tags) applies to FIFA 23 (identical wire format).