What this site does, and how

The Elder Scrolls: Blades shuts down on June 30, 2026. After that, the game stops working — every character, every town, every arena rank disappears unless someone has captured enough of the game's network traffic to build a community server.

This site is the platform that captures that traffic. Contributors play Blades through a VPN we run; the VPN forwards game traffic through a tool that records the API calls; the recordings get handed to the server-emulator project so they can replay the game's behaviour offline.

We run a WireGuard VPN. When you flip it on, your phone's internet traffic goes through our server, where we can see and record requests to game servers. When you flip it off, we see nothing.

That's the whole reason for the VPN — a place to put the recorder. We don't use it for anything else, and we filter to a curated list of game-relevant hosts (see below).

Most game traffic is HTTPS — encrypted. To read it, the recorder needs your phone to trust a certificate authority (CA) that we own. Once you install our CA cert and toggle the VPN on, your phone willingly hands the recorder a decrypted view of game requests as they pass through.

The trust window is narrow on purpose: the cert only matters while the VPN is connected. Disconnect WireGuard and the cert is just an unused entry in your phone's trust store — nothing on the public internet can use it against you.

The tool that does the decryption is mitmproxy, an open-source HTTPS proxy. We run a small custom plugin on top of it that writes recorded calls into a database and tags them to your Discord account.

The proxy makes a per-connection decision before any TLS handshake completes. The default is conservative: we only decrypt traffic to hosts on the approved-endpoints list, and that list is visible to you on the dashboard (it's the same list everyone else sees). Anything outside that list flows through the VPN encrypted, untouched.

You also have three per-account knobs over this default:

• Capture mode (default = curated list). Switch your account to * (wildcard) and we'll attempt to decrypt every host your phone talks to while the VPN is on. Useful for discovery sessions when we're looking for unknown game endpoints. Off by default.
• Per-host blocks. Anything you block stays untouched even if it's on the approved list — your bank, your email client, anything.
• Pinned-host bypass. Apps that hard-code their certificates (Apple ID, banking, Microsoft Authenticator, most telemetry SDKs) detect our CA, refuse the handshake, and the proxy auto-promotes them to passthrough so they keep working. They never get decrypted, by them or by us.

You can audit what was and wasn't decrypted in your live session view. Each row is tagged with which rule applied.

We sign you in through Discord because it's where the community already lives, and because Discord's own login flow lets us ask for the bare minimum: your Discord ID and username. We do not ask for your email, your friends, or any other Discord data.

The reason we sign you in at all is so each capture can be tagged back to a person — that way you can see your own data on the dashboard, you can opt out of capturing specific hosts, and you can delete your sessions whenever you want.

Some apps don't just check that the server's certificate is signed by a trusted CA — they hard-code which certificate they will accept, and refuse all others. That's “cert pinning.” Banking, password manager, and identity-provider apps all do this. It's a feature: even if someone tricks your phone into trusting a fake CA, a pinned app still refuses to talk.

For us, it means a few apps you might be running on the same phone (Apple ID, banking apps, Microsoft Authenticator) will not be decrypted by our recorder even when the VPN is on. The traffic passes through us untouched. That's the right outcome — your bank stays your bank.

Blades itself isn't pinned, so we capture it. A handful of companion services (analytics, telemetry SDKs) are pinned and end up in passthrough — the dashboard surfaces those rows so you can tell what was and wasn't captured.

Alongside the decrypted HTTPS view, we run tcpdump on the VPN interface and write the raw packets to disk in a rolling buffer. This is a separate file from anything mitmproxy produces.

Encrypted things stay encrypted. The pcap captures packets exactly as they cross the wire — TLS-protected payloads, banking traffic, anything not in our decrypt scope, all of it stays opaque in the pcap. We don't have keys to break what wasn't already decrypted at the proxy layer above.

We keep raw packets specifically for arena. Arena combat, matchmaking, and voice chat run over UDP and non-443 TCP channels that mitmproxy can't see. To reconstruct the realtime arena protocol for the server emulator, someone has to read those packet flows. That's the only reason we collect raw pcap data; if we could do without, we would.

Retention is bounded. Two layers:

• The active rolling pcap buffer keeps the last ~24 hours on disk (24 hourly files × 200 MB each, oldest auto-rotated out).
• A daily wipe job deletes any raw pcap or .mitm file older than 14 days. Two weeks is enough lead time to debug an ingest bug, re-run a parser, or recover from an outage — after that, the raw bytes are gone for good. Decrypted captures in the database stay (that's the project output); the raw archive does not.

You can also delete an individual session from your dashboard at any time, which scrubs the corresponding slice of raw archive immediately rather than waiting for the 14-day sweep.

Exception — decryption-reference sessions. Sessions that contributed to protocol research (e.g. one where a Frida hook recovered the per-match ChaCha20 key and we now have decrypted arena plaintext) are flagged preserve=1 in the database. Those rows are protected from the user delete button and from any future retention sweep so we don't lose the only known-good samples for the arena wire format. There are very few of these (currently one: session #20), and they're visible on /dashboard/arena-decrypted. An admin can override the flag (with explicit ?force=1 on the delete endpoint) if a session needs to come out for a real reason.

Yes — and please do, especially if you don't want to install a profile on your phone. The recipe:

1. Install mitmproxy on your laptop (homebrew/apt/pip — see mitmproxy docs).
2. Run mitmweb (or mitmproxy in the terminal). It will print a proxy address (typically your-laptop-ip:8080).
3. On your phone, set the Wi-Fi proxy to that address. Visit mitm.it in the phone's browser → download and trust the mitmproxy CA cert.
4. Play Blades. The mitmproxy window fills with decoded API calls.
5. When you're done, save the captured flows from the menu (File → Save) — that gives you a .mitm file.
6. Signed in? Upload the file at /dashboard/upload. Not signed in? Ping us on Discord and we'll sort out a hand-off.

The wizard at /setup is still the easiest path for most people — install one VPN config, forget about it, just play. The laptop method is for users who'd rather not put a profile on their phone.

mitmproxy only sees HTTPS. Realtime game channels (matchmaking, arena combat, voice) usually run over UDP or non-443 TCP, which mitmproxy can't decode. To capture those, you need a packet capture tool reading the raw network interface.

1. Install Wireshark (GUI) or tcpdump (command line).
2. Set up the same Wi-Fi proxy as in the laptop recipe above so your phone's traffic flows through the laptop.
3. Pick the laptop's active network interface and start a capture. A useful filter:

   tcpdump -i <iface> -s 0 -w arena.pcap \
     'host <phone-ip> and not (tcp port 443 or tcp port 80)'

4. Play arena. Stop the capture. Send us the .pcap file (Discord DM, or upload alongside an arena recording at /dashboard/upload).

The site itself runs tcpdump on the VPN interface for everyone, so if you capture through the VPN we already have the pcap on the server. The laptop recipe is for contributors who want a second, independent copy.