Expert Reverse Engineer & Python Developer for Fifa 17 Online Services Deadlock

We run a reimplementation of ea's dead fifa 17 online services: reverse-engineered blaze protocol + the fut http api. Login, clubs, transfer market, SBCs, Draft and matchmaking all work. Two real clients pair, build their mesh both ways, load each other's clubs and reach the kit/side-select screen. Then the match never kicks off and the client shows "Your opponent has left the match."

what the code shows
our pre-game gate advances blaze gamestate 130 (pre_game) to 131 (in_game) only when both players send matchready. But frame-to-log alignment proves the kit screen renders only when the server pushes 131 - and MatchReady is sent from that screen. It is a deadlock by construction. In 43 MB of logs no retail client has ever sent an online MatchReady, and 415 of 418 gate holds name exactly that. Ghidra on the decrypted, Denuvo-protected Cardsdll gives us the ready serialiser (rva 0x1205e0: matchid, opponentpersonaid, items) but not the preconditions that trigger it. Three alternative release paths existed and were each removed after producing 104 kickoffs that DNF'd. Separately our UDP relay rebuilds an ARC4 cipher per datagram, so RTT climbs 34ms to 1300ms and ~35% of packets drop within two minutes - every A/B test so far ran over a ruined link.

what we need
- windows re: ghidra/ida, x64dbg, frida. Walk the callers of the READY serialiser and tell us what gates it.
- Blaze protocol: TDF encoding, Gamemanager notifications, peer-hosted (ntop=130) topology, exip=0 / nat relaying.
- Python 3 server work: binary protocols, async networking, profiling (py-spy).
- Nice to have: native DLL patching, Wireshark, prior EA/private-server experience.

Stack: Python 3 on Ubuntu, SQLite, systemd, private GitHub, Windows test clients.
Remote, paid. When you apply, tell us the hardest binary you have reversed and how.