- srp: name kEphemeralBytes (19 = 152 bits, matches Blizzard client)
and kMaxEphemeralAttempts (100) with why-comment explaining A != 0
mod N requirement and near-zero failure probability
- warden_module: add why-comment on 0x400000 module base (default
PE image base for 32-bit Windows executables)
- warden_module: name kRsaSignatureSize (256 = RSA-2048) with
why-comment explaining signature stripping (placeholder modulus
can't verify Blizzard's signatures)
std::toupper(int) and std::tolower(int) have undefined behavior when
passed a negative value. These sites passed raw signed char without
casting to unsigned char first, unlike the rest of the codebase which
already uses the correct pattern. Affects auth (account names), world
packets, and mount sound path matching.
Replace ~37 remaining C-style casts with static_cast across 16 files.
Extract named color constants (kColorRed/Green/Yellow/Gray) and dialog
window flags (kDialogFlags) in game_screen.cpp, replacing 72 inline
literals. Normalize keybinding_manager.hpp to #pragma once.
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.
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
