SOCKS5 proxying broken with official Windows viewers about hippolyzer

[SaladDais]

Looks like the pcap in that bug isn't representative of the issue Windows hits now. I'm seeing an almost immediate FIN being sent by the viewer after it sends the SOCKS handshake, so it's not a timeout like that bug. Not seeing the trailing null bytes either. Don't see any way to work around on our end if the connection gets immediately closed, so will have to investigate circuit IP rewriting. Hoped to avoid that because of how messy it is.

[SaladDais]

Probably need to extract these details out into a TrransportManager class that can be tied to a Session and used for the open_circuit() calls, with hooks for rewriting the login response and the EQ messages that have sim IPs. The TransportManager would have an internal mapping of internally-bound UDP ports<->real sim UDP ports. The TransportManager should return an abstract Transport object that would wrap either the sim IP rewriting or SOCKS5 strategy used for that session, and that would be used in ProxiedCircuit rather than explicitly calling ProxiedUDPPacket.serialize().

The proxy could choose which strategy to use at the time of the login request based on whether or not there's active SOCKS5 UDP associations without sessions tied to them, falling back to IP rewriting if not.

Something like https://github.com/basil00/Divert/blob/master/examples/streamdump/streamdump.c might be nice to transparently force windows viewer traffic through the SOCKS proxy based on src or dest matching a known circuit, but they haven't implemented UDP association and it'd be more work than just doing IP rewriting.

[SaladDais]

Started a rewrite that would allow plugging in a transport manager that knows how to rewrite IPs and bind alias IPs on demand, but not happy with how deep the hooks have to go. Might try writing a Detours hook for non-DNS sendto / recvfrom that does transparent SOCKS5 first.