funman300
3f3d5704a7
Live run, 2026-08-05 evening. Three results, one of them a route that has been dead for
the whole life of the project.
QUICK SELL WAS NEVER SERVED. Captured on the wire:
DELETE /ut/game/fifa17/item/100000240 (single card, id in the URL, no body)
ENDPOINT_MAP documented the path as `ut/delete/game/%s/item`, ROUTES was built from the
doc, and the regex therefore never matched a real quick sell. Every quick sell fell
through to the catch-all, so quick_sell_route() and STORE.quick_sell() behind it had
never once been called.
The empty response was not a harmless no-op. This body is BALANCE-BEARING: the client
takes its coin total from it, so with totalCredits absent it rendered an uninitialised
value. A real session showed 1,133,686,384 coins against a true balance of 9,889,600.
Display artifact only, corrected by the next GET /user/credits, and the save was never
touched, but it is the reason a stub is not acceptable here.
quick_sell_url_route() serves the real form and returns the corrected shape,
{"items":[{"id":N}],"totalCredits":N}. DEFAULT ON, which the house rule now permits:
two quick sells fired through it in one session, each credited 150 and removed the
card, and the coin arithmetic reconciled exactly against the 15,000 pack purchases
either side of them. An unknown id returns {"items": []} rather than claiming a sale we
cannot account for.
Still UNKNOWN and deliberately not chased: whether the client ASSIGNS totalCredits as
the new balance or ADDS it as a delta. We send the new balance. The discriminating
window is about five seconds wide, because the client refetches GET /user/credits
straight afterwards, so either reading self-corrects and the practical impact is a brief
wrong number. It mattered only while we answered {}, because that garbage persisted.
The credit amount is STORE.quick_sell()'s invented rating tier, not FUT's real discard
table, which remains unknown.
finalFunds IS THE RENDERED COIN PRICE. Served funds=15000 / finalFunds=4321 on one pack
and the tile read 4,321. funds is not displayed. ENDPOINT_MAP updated to CONFIRMED LIVE
with the method recorded. FUT_PRICE_PROBE, the flag that produced it, stays default off
and is disarmed: it puts a price on a tile that the buy path does not charge.
TWO UNPLANNED FINDINGS, both recorded for the next round rather than fixed here:
* The store grouping is broken and it is NOT cosmetic. All three packs collapse into
one display group, and the Bronze, Gold and Premium group tiles all drill into the
same single Premium Gold pack, so TWO OF THREE PACKS CANNOT BE BOUGHT. We send
displayGroup {"value": name} but never displayGroupAssetId (0xda), so everything
lands in group 0. The docs had this parked as a cosmetic "tiles read unknown"
issue; it is an availability bug.
* The FIFA Points price renders as the literal "or %1s", an unsubstituted printf
placeholder. extPrice.finalPrice is served as {"amount":N,"currency":"mtx"} and
"mtx" is evidently not a currency token the client resolves. Cosmetic.
Corrected in passing: packContentInfo DOES reach the tile (11 ITEMS / 11 GOLD /
11 RARES against exactly what we serve). An earlier screen showing zeros was the
display-GROUP level, which carries no content info. D3 was right.
Live: 439 contract checks pass, both probe flags off, store prices back to honest.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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 TeamProven 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=1iptables -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.dllserves 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 hardcodesconnected="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 flipm_isLoggedIn. The login mechanism lives ONLY in FIFA17.exe's live-decrypted code.- Our
lsx_responder_v2.pyis 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 C1–C3 (emu-exactchallenge_response+ tail assert, extractresponse=", 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
.dlfGameToken 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
- 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 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?- 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. 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)
pkexec sh tools/../scratchpad/root_arm.sh(ptrace_scope=0, route_localnet, DNAT 159.153.51.20→42127).python3 -u tools/lsx_responder_v2.py— bind :4216 BEFORE launching FIFA.python3 -u tools/blaze_responder_v3b.py— :42127 (redir TLS) / :42130 (blaze) / :42131 (nucleus).python3 tools/autopatch.py— re-applies the two ProtoSSL cert patches to any relaunched FIFA17.exe.- Launch FIFA via
~/Desktop/launch-fifa17.sh; go Online. - 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).