Skip to content

Obfuscated server logins can advertise redundant callback crypto flags and require extra attempts

Summary

Current main always advertises SRVCAP_REQUESTCRYPT and SRVCAP_REQUIRECRYPT in the server login tag whenever those prefs are enabled, even if the main server socket is already connected through obfuscation.

The eMuleAI tree carries a narrow fix that keeps the login advertisement conservative on an already obfuscated server socket. Its stated user-visible failure mode matches a plausible current-tree networking bug: fully obfuscation-capable server lists can still require multiple attempts before login succeeds.

Current Mainline Status

Done in main via commit f9bb14b (BUG-030 harden obfuscated server login crypt flags).

The landed fix keeps SRVCAP_SUPPORTCRYPT unchanged and only suppresses SRVCAP_REQUESTCRYPT / SRVCAP_REQUIRECRYPT when the established server socket is already obfuscated.

Evidence In Current Tree

  • srchybrid/ServerConnect.cpp
  • ConnectionEstablished(...) builds dwCryptFlags
  • current main sets:
    • SRVCAP_SUPPORTCRYPT
    • SRVCAP_REQUESTCRYPT
    • SRVCAP_REQUIRECRYPT directly from preferences with no check on the already-established server socket state
  • analysis\emuleai\srchybrid\ServerConnect.cpp
  • keeps SRVCAP_SUPPORTCRYPT
  • suppresses REQUESTCRYPT / REQUIRECRYPT when sender->IsServerCryptEnabledConnection() is already true
  • includes an inline note: "Keep server callback negotiation conservative when the main server socket is already obfuscated."

Why This Looks Real

The server-login packet is not just capability metadata; it also influences callback / follow-up negotiation. Advertising "please obfuscate the callback path" again while the main socket is already obfuscated is unnecessary at best and can trigger extra retry or fallback behavior on some servers.

This is a narrow protocol-behavior fix with minimal drift:

  • no new wire fields
  • no new preference surface
  • no broader server-connect policy rewrite

Likely Fix Shape

In CServerConnect::ConnectionEstablished(...):

  1. keep SRVCAP_SUPPORTCRYPT tied to the local preference as today
  2. only advertise SRVCAP_REQUESTCRYPT / SRVCAP_REQUIRECRYPT when the established server socket is not already obfuscated
  3. leave all other login tags unchanged

Do not port the adjacent eMuleAI IPv6 tag additions or any broader server-list behavior as part of this bug.

Validation Target

  • connect against a server list that fully supports obfuscation
  • verify that first-attempt obfuscated login succeeds consistently
  • verify fallback from obfuscated to plain still behaves as today when obfuscation is not available
  • compare current main vs fixed build on verbose server-connect logging