The Back Orifice [Client/Server] Protocol

Introductory Notes

• This specification was obtained by examining at the source code for the BO client for Unix and in the development stage of NOBO. It probably doesn't cover all aspects of the protocol, and may contain incorrect information; such items are tagged with "(???)". If you find something missing or wrong in this document, please, let me know.
• All numeric values are represented in decimal notation or, if prefixed with a "0x" (e.g. "0x0f"), in hexadecimal, unless noted otherwise.

The Protocol

The exchange of data between the BO client and server is done using encrypted UDP packes. The format of these packes is simple, as is the cryptographic scheme used. The server normally binds to the UDP port 31337, but it may be configured to use another one. All BO packets -- from the server to the client and vice-versa -- have the same basic format. Notice that even if no password is set up on the server and client, BO packets are always encrypted.

Packet Format

Packets fields:

Header Fields

MAGIC - An eight bytes strings which indentifies the BO packet. The sequence of characters is fixed and must be the string "*!*QWTY?" (star, bang, star, "Q", "W", "T", "Y", question).

LEN - A 32 bit integer which contains the length of the entire packet, including the header. The value of this field cannot be less than 19 (the header length plus, at least, 1 byte data and 1 byte CRC).

ID - A 32 bit integer which contains the identification of the UDP packet. In fragmented packets, this field is used to keep track of the fragment sequence number (???). It's also used by the BO client to match an received packet with a previously sent packet.

The "32 bit integers" used in the header of BO packets aren't transmitted in network order, but with its least significant byte sent first. For example, the "integer" 0x11bb55ee is transmitted is this order: 0xee, 0x55, 0xbb and 0x11.

T - This field contains the operation type that the packet carries. In this field, the 2 most significant bits are used to flag some conditions about the packet, such as the fragmentation of a large packet. The remaining 6 bits are used to specify the actual BO operation.

BO Operations

Two most Significant Bits from the Packet Type Byte

These two flags usually are combined in "inner" packets. For example, a big packet fragmented in 4 smaller ones would be send with the following flags:

1. PARTIAL_PACKET
2. PARTIAL_PACKET | CONTINUED_PACKET
3. PARTIAL_PACKET | CONTINUED_PACKET
4. CONTINUED_PACKET

Data

The contents of the data field should be interpreted diferently if the packet goes from the server to the client, or if it goes in the opposite way (???). In packets going from the client to the server, up to two string sequences can be sent in the data field, as they're separated by a NUL character. In packets going from the server to the client, there is only one string (???) with the command response.

Data "Fields"

¹ If the second parameter is present, the application is made visible. Otherwise, it is run hidden.

² The type can be "B" for binary, "D" for a double word (DWORD) and "S" for a string of character. In binary fields, the value is a sequence of two hexadecimal digits (e.g. "ab 11 5f"); in double word fields, the value should be specified in decimal; in string fields, the value is the string.

CRC

Cryptography

The encryption is done applying a XOR (exclusive or) operation between each byte of the packet and the sequential value returned by a random number generator. This generator is initialized with a value which depends on the secret password being used in the communication. This way, having the same password, both random number generator (the server's and the client's one) will be initialized with the same seed, and they will return the same sequence of "random" numbers which will be used to encrypt/decrypt the packet.

This cryptographic scheme isn't strong. As all of the packet contents is encrypted, and they always contain a fixed sequence of characters (MAGIC) in the header, from an encrypted packet one can easily obtain the initial sequence of random numbers generated and use a brute force attack to discover the seed of the random number generator, as the range of possible values is somewhat small. The methods used to decrypt and encrypt a BO packet without knowing the password being used are out of the scope of this document, and are left as an exercise to the reader.

The Random Number Generator

BORAND(x) = (x * 214013) + 2531011

Where "A * B" denotes the multiplication of A by B, and "+" the usual sum operation.

The value of the initial parameter -- the seed -- is derived from the communication password (see below). The next value is always the result of the value returned on the last run. For example, a sequence of "random" numbers X1, X2, ..., Xn can be obtained in the following way:

X1 = BORAND(IV)
X2 = BORAND(X1)
X3 = BORAND(X2)
    ...
Xn = BORAND(Xn - 1)

Where IV is the seed and Xn is the n^th random number.

The Seed

X = 0
Y = length (number of characters) of S
Z = 0
WHILE X < Y
	Z = Z + S[X]
	X = X + 1
END

X = 0
WHILE X < Y
	IF X is odd
		Z = Z - (S[X] * (Y - X + 1))
	ELSE
		Z = Z + (S[X] * (Y - X + 1))
	END
	Z = Z % 0x7fffffff
	X = X + 1
END
Z = (Z * Y) % 0x7fffffff
IV = Z

Note: the random number generator is initialized with the seed for every sent/received packet.

Note: the variables X, Y and Z are all 32 bit integer. This mean that the most significant bits above the 32^nd one should be ignored when an overflow occurs.

Encrypting/decrypting

L = length of the BO packet
X = 0
Z = IV
WHILE X < L
	Z = BORAND(Z)
 	P[X] = P[X] ^ ((Z >> 16) & 0xff)
	X = X + 1
END

TCP file transfer

When the client sends a TYPE_TCPFILESEND packet, the server opens the file specified and start listening for a TCP connection on the specified TCP port. Then the client connects to that port and start sending the file.

When the client wishes to receive a file, it sends a TYPE_TCPFILERECEIVE packet specifying the desired file name and the TCP port. The server will then open the specified port and start transferring the file as soon as someone (probably the client) connects to it.

The TCP stream is not encrypted.

All this TCP file send/receive stuff is "(???)".

• BO client for Unix [ http://www.cultdeadcow.com/tools/ ]
• ISS Security Alert Advisory (X-FORCE)
  [ http://www.iss.net/xforce/alerts/advise5.html ]
• Flávio Veloso's program "NOBO" [ http://web.cip.com.br/nobo/ ]

You do assume all risk and responsability arising from the use of any information contained on this document. At no time shall the author warrant that this document is entirely correct, and he can not be held responsible if it is not. If you find any mistake in this document, or have some information you think will contribute to make it more precise, please mail me at flaviovs@centroin.com.br.

Any information which may help me to eliminate the questionable material: those "(???)"s (in the work above) is welcome!

Thanks

Markus <markus@?????????.nl>
J.M. Colàs <jmcolas@mx3.redestb.es>

-x-x-
Last updated on January 8^th, 1999.

---

[ Slight editorial work by The Starman on March 11, 1999. ]

---

Back to The Starman's 'BO' Page.