Files
OpenFUT/fifa17-recon/futmem/src/mem.rs
T
funman300 afdbb364ca fifa17-recon: pack opening reversed end to end, and there is no pack-inventory endpoint
A twelve-agent pass over the parts of pack opening we did not understand, run against
the live client (CardsDLL slide proven, not assumed) plus static CardsDLL. Findings
below survived an adversarial verification round that corrected several of them; where
a verifier and a finder disagreed, the verifier won.

THE HEADLINE IS A NEGATIVE, and it deletes work rather than creating it. There is no
pack-inventory endpoint in FIFA 17 and there never was. Proven three independent ways:
the 48-entry UTAS route template array at 0x18021df80, a regex for "ut/" over the whole
PE, and the 125-row client action table at 0x1802caa20, which is the complete set of
requests the client can originate. "Serve the pack inventory" comes off the backlog.
The unclaimed-pack tile and My Packs are two fields on responses we already build.

Corrections to ENDPOINT_MAP.md, both freeze-risky as written:
  * duplicateItemIdList is an array of OBJECTS (element parser 0x180138e10: itemId
    0x16d, duplicateItemId 0xeb, itemLoans 0x16f, duplicateItemLoans 0xed), not the
    int list documented at :1095 and :218. Control that this is not a misread:
    dreamSquads 0xe9 in FutMoveCard genuinely is a bare int array and parses with no
    inner object loop. We serve [], so this is a docs bug today and a live freeze the
    moment somebody implements it from the map as written.
  * FutDiscardCardServerResponse is {"items":[{"id":N}],"totalCredits":N}. There is no
    top-level id. :968-971 is wrong twice over.

packContentInfo is DECORATIVE. It is read only into a store-tile view model, and
nothing compares the declared counts against the delivered itemList, so open_pack()
does not have to honour the distribution.

The reveal is entirely CLIENT-SIDE. Walkout, tiering, colours and ordering are
arithmetic over fields we already send. Genuine outstanding server work reduces to
three items: duplicates, quick-sell credit, unopenedPacks.

Perishable intel captured: the real FIFA 17 retail pack catalogue, 41 SKUs with Origin
offer ids, recovered from the client heap as a parsed copy of data/store/storecfg.xml.
It is in no file on disk, only in a running process.

futmem/ is a standalone read-only Rust crate for this kind of work (maps, find,
strings, read). Read-only by construction: it opens /proc/<pid>/mem with File::open
and there is no code path in it that can write to another process, because a live game
session depends on that. Its own [workspace] table keeps it out of the parent
workspace. Chunked scanning overlaps by pattern_len-1 so a match spanning a chunk
boundary is still found.

utas_server.py gains FUT_PORT/FUT_LOG so a throwaway instance can be started without
bouncing the one the live client is using. Defaults unchanged (8099, /tmp/utas_server.log).
Noted for the record: this edit came from a research agent that had been told not to
touch server code. It is benign and useful, but it was out of scope.

Not committed: the doc proposes ENDPOINT_MAP.md changes as pasteable text rather than
applying them, and every proposed server change defaults off per the house rule.
Nothing in this commit changes a response the client sees.

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

103 lines
4.0 KiB
Rust

//! Read-only access to another process's address space.
//!
//! # The safety property this module exists to guarantee
//!
//! A live FIFA 17 session may be running while this tool is used. Corrupting it
//! costs the user their progress and their patience. So the guarantee here is
//! structural, not a matter of being careful:
//!
//! * `/proc/<pid>/mem` is opened with [`File::open`], which is `O_RDONLY`.
//! There is no [`std::fs::OpenOptions`] anywhere in this crate.
//! * [`ProcMem`] exposes `&self` read methods only. It hands out no `&mut File`
//! and no raw fd, so no caller outside this module can upgrade the handle.
//! * Nothing in the crate calls `ptrace`, sends a signal, or writes to any
//! path under `/proc`.
//!
//! Even if a caller tried to write, the kernel would reject it on an `O_RDONLY`
//! descriptor. The type system and the open mode agree, which is the point.
//!
//! # Why pread and not seek + read
//!
//! [`FileExt::read_at`] is `pread(2)`: it takes the offset as an argument
//! instead of mutating a shared file cursor. That means a `&ProcMem` can be
//! shared across threads later without a mutex and without one thread's seek
//! corrupting another's read. It also removes a whole class of "forgot to seek"
//! bugs. There is never a reason to prefer seek+read here.
use std::fs::File;
use std::io;
use std::os::unix::fs::FileExt;
/// The page size we assume when stepping over an unreadable hole. Every x86-64
/// mapping is a multiple of this, so it is a safe granularity for recovery.
pub const PAGE: u64 = 4096;
/// A read-only handle on a process's memory.
pub struct ProcMem {
file: File,
}
/// What a single chunk read produced.
pub enum ChunkRead {
/// `n` bytes landed in the buffer. May be shorter than requested when the
/// read ran into an unmapped hole partway through.
Got(usize),
/// Nothing readable at this address at all.
Hole,
}
impl ProcMem {
/// Open the target read-only. See the module docs for why this is
/// `File::open` and must stay that way.
pub fn open(pid: i32) -> io::Result<Self> {
let file = File::open(format!("/proc/{pid}/mem")).map_err(|e| {
io::Error::new(
e.kind(),
format!("opening /proc/{pid}/mem: {e} (same-user or CAP_SYS_PTRACE required)"),
)
})?;
Ok(Self { file })
}
/// Best-effort read. Never fatal: a hole reports [`ChunkRead::Hole`] rather
/// than propagating an error, because in a 3 GB sweep unreadable regions are
/// the normal case, not an exceptional one.
///
/// Guard pages, Wine's special mappings and pages Denuvo has not faulted in
/// are all marked readable in `/proc/<pid>/maps` yet return `EIO` here. The
/// caller counts these and reports the total so the user knows the sweep was
/// partial.
pub fn read_chunk(&self, va: u64, buf: &mut [u8]) -> ChunkRead {
match self.file.read_at(buf, va) {
Ok(0) | Err(_) => ChunkRead::Hole,
Ok(n) => ChunkRead::Got(n),
}
}
/// Strict read for cases where a short read is genuinely an error, such as
/// an explicit `futmem read <va> <len>` the user asked for by hand.
pub fn read_exact(&self, va: u64, len: usize) -> io::Result<Vec<u8>> {
let mut buf = vec![0u8; len];
self.file.read_exact_at(&mut buf, va).map_err(|e| {
io::Error::new(
e.kind(),
format!("reading {len} bytes at {va:#x}: {e} (address may be unmapped)"),
)
})?;
Ok(buf)
}
/// Read up to `len` bytes, returning however many were actually available.
/// Used for printing context around a hit that sits near the end of a region.
pub fn read_partial(&self, va: u64, len: usize) -> Vec<u8> {
let mut buf = vec![0u8; len];
match self.file.read_at(&mut buf, va) {
Ok(n) => {
buf.truncate(n);
buf
}
Err(_) => Vec::new(),
}
}
}