# OpenFUT Bridge — Claude Code project context

Read this first. It's the standing context for every task in this project. Each
working session will give you ONE bounded task plus a verification clause; this
file is the background that stays true across all of them.

## What this project is

OpenFUT is an **offline FIFA 23 FUT (Ultimate Team) emulator** for single-player
game preservation. EA permanently shut down FIFA 23's online servers in October
2025, which removed FUT. This project lets a legitimately-owned copy run FUT
against a **local emulated backend** instead of EA's (dead) servers.

It has two repos:
- **OpenFUT Core** — the game-independent FUT economy backend (already largely built).
- **OpenFUT Bridge** — the FIFA 23 integration / reverse-engineering layer (this work).

## Hard constraints (do not violate)

- **Clean-room only.** Everything is derived from observing the running client's
  own behaviour. NEVER use, reference, or reproduce leaked EA source code (e.g.
  the 2021 FIFA 21 / Blaze leak). If a task seems to need it, stop and say so.
  Clean-room provenance is the legal foundation of the whole project.
- **Mark uncertainty, don't invent.** Several things are genuinely unconfirmed:
  the Fire2 packet framing, ProtoSSL non-blocking return values, and FIFA 23's
  Blaze component/command IDs. When you don't know a value, leave a clearly
  labelled `TODO/CONFIRM` rather than guessing a confident-looking number.
- **Verify against the client.** The dead servers mean responses are *synthesized
  and tested against the live offline client*, never captured from EA. The client
  is the oracle: a gate is "done" when the client advances to the next command.

## Architecture

```
FIFA 23 client (offline, native Windows)
   |  ProtoSSLConnect / ProtoSSLSend / ProtoSSLRecv   (in-process)
openfut_hook.dll   — fakes the connection, captures requests, injects responses
   |  plain localhost TCP, length-prefixed frames     (no TLS)
blaze_brain (Rust) — decodes requests, crafts Blaze responses   <-- iteration surface
   |
OpenFUT Core       — supplies real FUT economy data for the FUT gates
```

Why in-process (not a localhost TLS server): FIFA 23's ProtoSSL uses modern TLS
with cert pinning, so a fake server gets its cert rejected. Hooking ABOVE the
crypto (ProtoSSLSend/Recv take/return plaintext) sidesteps TLS entirely.

## The entry sequence (the gates to reach FUT)

The client runs these in order; each must be satisfied before the next fires:

1. **LSX** (port 3216, plaintext loopback) — launcher→game bootstrap.
2. **Blaze redirector** — returns a server host/port.
3. **Blaze preauth** (UTIL) — config / component list.
4. **Blaze login** (AUTHENTICATION) — persona, session key, UID.
5. **Blaze postauth** (UTIL) — telemetry/ticker; "fully online".
6. **FUT entry check** — FIFA-specific eligibility/entitlement wall.
7. **FUT hub load** — club/squad over REST; hand off to OpenFUT Core.

Gates 2–5 are largely static/replayable (the client validates little). Gates 6–7
need internally-consistent data and connect to OpenFUT Core.

## Environment

- Native Windows boot (chosen for predictable PE/hooking behaviour over Proton).
- FIFA 23, with EA Anticheat in its offline/neutralized state. Do NOT assume a
  task is safe to hook unless EAAC is confirmed neutralized.
- Rust is the primary language. Hook = `cdylib`, Windows target. Brain = portable.
- Self-hosted Gitea (git.aleshym.co, org Quaternions). Self-hosted CI runner.

## How to work here

- One rung at a time. Don't run ahead into a gate that depends on an unconfirmed
  earlier answer.
- When decoding a frame, work from REAL captured bytes the user pastes in — not
  from a guessed layout. Ask for the bytes if they're not provided.
- End each change with how the user verifies it on the client.


# OpenFUT Bridge — Task prompts (run in order)

Each task is its own Claude Code session. Paste the task, attach the named
starting file(s), and don't move to the next until the verification clause passes.
The project CLAUDE.md is assumed to be in context.

---

## TASK 1 — Confirm the transport (read-only memory scan)

**Goal:** prove whether FIFA 23 uses EA DirtySDK / ProtoSSL before we build any
hook around it. Read-only; no hooking, patching, or injection.

**Do this:**
Write a standalone Windows console program in Rust (target
`x86_64-pc-windows-msvc` or `-gnu`) that:
1. Finds the running FIFA 23 process by name (and accepts a PID argument).
2. Enumerates its modules and committed memory regions (e.g. `EnumProcessModules`
   / `VirtualQueryEx`), readable regions only.
3. Reads memory with `ReadProcessMemory` in chunks (with small overlap so a
   marker spanning a chunk boundary is still found).
4. Searches for these ASCII markers and prints each hit with its absolute address:
   `protossl:`, `ProtoSSLSend`, `ProtoSSLRecv`, `ProtoSSLConnect`,
   `gosredirector`, `DirtySDK`, `blaze`.
5. Prints a summary: which markers were found, and a clear verdict line
   ("ProtoSSL present" vs "no ProtoSSL markers found").

Keep it dependency-light (the `windows` crate is fine). Comment it for a Rust
beginner. It must only read.

**Verification:** with FIFA 23 running and sitting at the main menu, the program
prints whether the ProtoSSL markers are present. If `protossl:` and the
send/recv strings appear, the transport is confirmed and we proceed. If nothing
appears after the menu has loaded, STOP — we rethink the transport, don't build
the hook.

**Note:** reach the main menu before scanning; the networking code/strings may
not be paged in at the title screen.

---

## TASK 2 — Loadable DLL shell (prove we can get code in)

**Goal:** a `version.dll` proxy that loads into FIFA 23 and runs our code, before
any hook logic exists. This isolates "can we inject at all" from "is the hook
correct".

**Do this:**
Create a Rust `cdylib` (Windows target) that:
1. Exports the functions a real `version.dll` exports, forwarding each to the
   system `version.dll` (proxy/sideload pattern). List the needed exports and
   implement the forwarding.
2. In `DllMain`, on `DLL_PROCESS_ATTACH`, spawns a thread (NOT work in DllMain
   itself — loader lock) that writes a line to a log file in a known path, e.g.
   `C:\openfut\hook.log`, with a timestamp.
3. Provide the `Cargo.toml` (`crate-type = ["cdylib"]`) and the exact build
   command.

Clean-room: this is generic proxy/loader scaffolding, nothing EA-derived.

**Verification:** drop the built DLL next to the FIFA 23 executable, launch the
game, and confirm `hook.log` gets the timestamped line. Game still reaches the
menu normally. If it crashes or the line never appears, fix the proxy/forwarding
before continuing.

**Caution:** confirm EAAC is in its offline/neutralized state before loading the
DLL. Do not load it into an anticheat-active session.

---

## TASK 3 — One landing hook on ProtoSSLSend

**Goal:** prove we can hook a ProtoSSL function and see real outbound frames.
Just one function, and it calls the original (passive observation).

**Do this:**
Extend the Task 2 DLL:
1. Add the `retour` crate. Resolve the `ProtoSSLSend` address — first pass: use
   the absolute address Task 1 reported, converted to a module-relative offset
   plus the live module base. (We'll switch to a byte-pattern scan later for
   patch-resilience; leave a TODO for that.)
2. Install a `retour` inline detour on `ProtoSSLSend` with signature
   `extern "C" fn(*mut c_void, *const u8, i32) -> i32` (x64 = one calling
   convention; `extern "C"` is correct).
3. In the detour: log `length` and the first ~32 bytes of the buffer as hex,
   then CALL THE ORIGINAL and return its result (do not block or alter traffic
   yet).

Mark the ProtoSSL return-value conventions and the eventual pattern-scan as
`TODO/CONFIRM` per the project rules.

**Verification:** launch the game, attempt to go online / load FUT, and confirm
`hook.log` shows ProtoSSLSend calls with non-trivial byte dumps — these are the
client's real outbound Blaze frames (still TLS-bound on the wire, but plaintext
here, which is the whole point). Seeing real frames = hooking works, and we now
have actual bytes to decode in later tasks. Paste a few of those captured frames
into the next session.

---

## What to attach to each task

- Task 1: nothing (fresh program), or the Linux `protossl_scan.rs` as a logic
  reference to port.
- Task 2: nothing, or your existing `version.dll` proxy shell if you have one.
- Task 3: the Task 2 DLL, plus the `openfut_hook_sketch.rs` as the structural
  reference, plus the address Task 1 reported.

Once Task 3 yields real captured frames, later tasks (the brain handlers per
gate) should always include the actual pasted bytes — decoding real frames is far
more reliable than guessing the Fire2 layout.