At work I recently implemented a Socks V5 interface to a proprietary network gateway server. Anyhow, facing one side is a Socks V5 server that lives up to the standard set in RFC 1928. On the other side is our fancy network stuff. The protocol is quite simple and can pretty much be implemented just from the RFC.

One part threw me for a loop though. When Socks V5 retrieves the port number from the client application. Here is what the protocol looks like in the RFC:

The SOCKS request is formed as follows:

        +----+-----+-------+------+-- --------+----------+
        |VER | CMD |  RSV  | ATYP | DST.ADDR | DST.PORT |
        +----+-----+-------+------+----------+----------+
        | 1  |  1  | X'00' |  1   | Variable |  2       |
	+----+-----+-------+------+----------+----------+
 Where:

o  VER    protocol version: X'05'
o  CMD
o  CONNECT X'01'
o  BIND X'02'
o  UDP ASSOCIATE X'03'
o  RSV    RESERVED
o  ATYP   address type of following address
	o  IP V4 address: X'01'
	o  DOMAINNAME: X'03'
	o  IP V6 address: X'04'
o  DST.ADDR       desired destination address
o  DST.PORT desired destination port in network octet order

The DST.PORT field is a little tricky to encode / decode. The protocol takes an Integer port number and jams it into a two-byte field. I suspect there is some simple windows sdk function to do this, but I chose to go the hard way.

The socks server needs to Decode it. I needed a DWORD:

DWORD dwPort = ((((DWORD)portBuffer[2]) << 8) | (DWORD)portBuffer[3])

Then how the heck do you encode it, just in case you want to simulate a client? Try this:

int highByte = remotePort >> 8; //shift right to drop the bottom 8 digits
int lowByte  = remotePort & 0xFF; //mask with 255 to drop the high 8 digits
recvdPort[2] = highByte;
recvdPort[3] = lowByte;

See the bit-shift by 8? That is the same as 2^8=256. 0xFF = 255