Why a C Struct Can Produce a Bad SOCKS Request
Inspect explicit field widths, byte order and stream I/O instead of treating compiler layout as the wire format.
A valid proxy address does not make a handwritten SOCKS message valid. Sending a C or C++ struct can send padding or host-order integers that the protocol never requested.
For a SOCKS5 domain-name CONNECT request, serialize this sequence explicitly after method negotiation and any selected authentication:
- Version, command, reserved byte and address type
- Domain length and domain bytes
- The two-byte destination port in network byte order
Address lengths depend on the SOCKS version and address type. Fixed-width numeric fields need their specified representation; domain strings have their own length encoding. A C string terminator is not a general instruction to append a zero to the wire message.
| Implementation shortcut | Problem to check |
|---|---|
| Assigning a 32-bit value through an 8-bit pointer | It does not emit all four bytes |
| Casting a buffer to a larger integer pointer | Alignment and byte order still need handling |
| Assuming one read or write is one message | TCP can transfer only part of the protocol sequence |
Compare each field with the intended destination and handle partial I/O. Receiving two bytes does not establish that the entire reply arrived. Inspecting those boundaries can distinguish a malformed request from a server refusing a correctly described connection.