funman300/OpenFUT
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fifa17-recon: futlog.py -- client-filtered log reader, and a correction it caught

Browse Source 
Implements the standing requirement recorded in priority-2026-08 S5: the User-Agent
filter is now the DEFAULT in the log tooling, not an option. The real client sends
ProtoHttp; our own probes send curl/* or Python-urllib/*. Reading the log unfiltered
gave this project a materially wrong picture of itself (/clubUser and /user/list had 93
and 180 hits, none from the game).

The old futlog.py was a one-off with a hardcoded path and no notion of who made the
request. Replaced with a real tool: timeline or summary, body/response display, path
regex, time window, status filter, and an --unmapped view that lists the endpoints the
client wants and we catch-all. --all and --probes exist for when you deliberately want
our own traffic.

Over the full 3044-request history: 486 requests came from the game.

IT IMMEDIATELY CAUGHT ME OVERSTATING SOMETHING. Yesterday's commit called the PUT /item
request shape "captured for the first time (the client had never successfully reached
this path)". False. There are NINE client PUT /item requests in the log, eight of them
during the failed attempts, every one carrying swap and tradeId:

  08:45:11 08:51:13 08:55:21 08:58:19 09:10:52 09:15:26 09:22:31 09:37:12 | 11:15:48

The request was on the wire and in the log the whole time. What was new was reading it.
Same class of error as the truncated decompile in S16: evidence already collected and
not looked at. REBUILD_RESEARCH S17 corrected.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VUT92pz6RWKih9dSr8ZpxW
This commit is contained in:
funman300
2026-08-04 11:28:42 -07:00
parent 5b139864ee
commit e5bfe58fc8
2 changed files with 220 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
fifa17-recon/docs/REBUILD_RESEARCH.md
+18 -6
View File
@@ -679,17 +679,29 @@ wrong, and §16 explains exactly which truncated decompile produced it.
Both defaults are flipped in `utas_server.py`: `FUT_MOVE_BODY=ack`, and
`FUT_PACK_AUTOCLUB` now defaults **off**.
### New intel: the request shape
Captured for the first time (the client had never successfully reached this path):
### The request shape
```json
{"itemData":[{"id":100000125,"pile":"club","swap":0,"tradeId":0}, ...]}
```
`swap` and `tradeId` accompany `id` and `pile`. We ignore both and the move
succeeded, so neither is load-bearing for a pending-pile-to-club move. `TODO/CONFIRM`
what `swap` means for a squad-slot exchange, where it plausibly is.
`swap` and `tradeId` accompany `id` and `pile`. We ignore both and the move succeeded,
so neither is load-bearing for a pending-pile-to-club move. `TODO/CONFIRM` what `swap`
means for a squad-slot exchange, where it plausibly is.
**Correction to the first version of this section**, which called this shape "captured
for the first time" because "the client had never successfully reached this path". That
is wrong. `futlog.py` over the full history shows **nine** client `PUT /item` requests,
eight of them before today, all carrying `swap` and `tradeId`:
```
08:45:11 08:51:13 08:55:21 08:58:19 09:10:52 09:15:26 09:22:31 09:37:12 11:15:48
the seven failed attempts the fix
```
The request was on the wire and in the log the entire time. What was new today was not
the capture, it was reading it. That is the same class of error as the truncated
decompile in §16: evidence already collected, not looked at.
### Process note, and it is not a small one