Replace hardcoded WotLK protocol constants with a data-driven architecture
supporting Classic 1.12.1, TBC 2.4.3, and WotLK 3.3.5a. Each expansion
has JSON profiles for opcodes, update fields, and DBC layouts, plus C++
polymorphic packet parsers for binary format differences (movement flags,
speed fields, transport data, spline format, char enum layout).
Key components:
- ExpansionRegistry: scans Data/expansions/*/expansion.json at startup
- OpcodeTable: logical enum <-> wire values loaded from JSON
- UpdateFieldTable: field indices loaded from JSON per expansion
- DBCLayout: schema-driven DBC field lookups replacing magic numbers
- PacketParsers: WotLK/TBC/Classic parsers with correct flag positions
- Multi-manifest AssetManager: layered manifests with priority ordering
- HDPackManager: overlay texture packs with expansion compatibility
- Auth screen expansion picker replacing hardcoded version dropdown
Added MD5 hashing and extensive testing documentation for future attempts
at supporting strict Warden servers like Warmane.
Enhancements:
- Added MD5 hash support to Crypto class (OpenSSL-based)
- Tested 6 different module ACK response formats against Warmane
- Analyzed module packet structure (37 bytes: opcode + seed + trailing)
- Enhanced debug logging for plaintext and encrypted Warden data
Documentation:
- WARDEN_IMPLEMENTATION.md: Complete implementation guide with all attempts
- WARDEN_QUICK_REFERENCE.md: Quick troubleshooting and testing guide
Test Results (Warmane):
- Empty ACK (0 bytes): Server silent
- XOR/MD5 checksum (18 bytes): Server silent
- Single byte (1 byte): Server disconnects (rejected)
- Echo trailing (20 bytes): Server silent
- Result + SHA1 (21 bytes): Server silent
Conclusion:
- Current implementation works with permissive/disabled Warden servers
- Warmane requires module execution or undocumented response format
- Full documentation provided for future reverse engineering attempts
Next steps documented:
1. Capture packets from real WoW client (protocol analysis)
2. Implement module execution engine (months of work)
3. Test with local AzerothCore server
Save SHA1(UPPER(user):UPPER(pass)) hash to login.cfg instead of the
plaintext password. On subsequent logins, use the stored hash directly
with a new authenticateWithHash() method that bypasses password hashing.
The password field shows a placeholder when using a stored hash.
Game name uses big-endian (not reversed), platform/os/locale use
little-endian with chars reversed and null at end (not beginning).
Protocol version is 8 for WoW 3.3.5a, not 3.
Account for PIN/matrix/authenticator extra data in packet size
calculation to prevent receive buffer corruption. Add hex dump
of raw auth packets and show actual server error codes.
TrinityCore/AzerothCore's UpdateBigNumbers uses BN_num_bytes (natural
size without padding) when hashing values for u and M1. Our code was
using fixed 32-byte padding which produces different hashes when any
value (salt, A, B, N) has leading zeros in big-endian representation.
Two bugs that caused the server to always reject our login proof:
- N was hashed as 256 bytes (2048 bits) instead of 32 bytes (256 bits),
producing completely wrong H(N)^H(g) and therefore wrong M1
- Session key computation B-k*g^x could go negative; OpenSSL's
BN_mod_exp doesn't handle negative bases. Add k*N before subtracting
(standard TrinityCore approach) to keep the value positive
Three critical bugs fixed:
- LOGON_CHALLENGE request: set protocol byte to 0x03 (was 0x00) and
reverse FourCC strings (game/platform/os/locale) to match real client
- Response parsers: remove double-read of opcode byte that shifted all
field reads by one, preventing successful auth with real servers
- LOGON_PROOF response sizes: success=32 bytes, failure=4 bytes to match
TrinityCore/AzerothCore format
Also adds missing auth result codes (0x13-0x20, 0xFF) including
IGR_WITHOUT_BNET (0x17) which Warmane was returning.
