O Protocolo do Back Orifice (BO)

Notas Introdutórias

• Esta especificação foi obtida através da observação dos fontes do cliente BO para Unix e nos testes feitos enquanto desenvolvia o NOBO. Ela provavelmente não cobre todos os aspectos do protocolo e pode conter informações erradas; tais ítens estão marcados com um "(???)". Se você descobrir alguma informação faltando ou errada neste documento, por favor, entre em contato.
• Todos os valores numéricos estão representados em notação decimal, ou, se precedidos por "0x" (e.g. "0x0f"), em hexadecimal, a não ser que seja indicado o contrário.

O Protocolo

Formato dos Pacotes

Campos do pacote:

Campos do Cabeçalho

MAGICA - É uma sequência de 8 bytes que identifica o pacote do BO. Esta sequência é fixa e deve ser o valor "*!*QWTY?" (asterisco, ponto-de-exclamação, asterisco, "Q", "W", "T", "Y", ponto-de-interrogação).

TAM - É um inteiro de 32 bits com tamanho total do pacote, incluindo o cabeçalho. Este valor deste campo não pode ser menor que 19 (o tamanho do cabeçalho mais pelo menos 1 byte de dados e o CRC).

ID - É um inteiro de 32 bits contendo a identificação do pacote UDP. Em pacotes divididos, ele é usado para numerar seqüencialmente as partes (???). Também é usado pelo cliente BO para sincronizar pacotes de respostas com o pedido enviado.

Os "inteiros de 32 bits" usados no cabeçalho de pacotes do BO não são transmitidos na "ordem de rede", mas sim com o byte menos significativo primeiro. Por exemplo, o "inteiro" 0x11bb55ee é transmitido nesta ordem: 0xee, 0x55, 0xbb e 0x11.

T - É o tipo de operação que o pacote carrega. Neste campo, os 2 bits mais significativos são usados para sinalizar algumas condições do pacote, como a divisão de pacotes grandes. Os 6 bits restantes identificam uma operação do BO.

Operações do BO

Dois Bits mais Significativos do Tipo do Pacote

Estes dois flags são normalmente combinados nos pacotes "internos". Por exemplo, um pacote grande que é fragmentado em 4 pacotes seriam enviados com os seguintes flags:

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

Dados

O conteúdo do campo de dados merece interpretação diferente, dependendo se o pacote vai do cliente para o servidor ou se é o contrário (???). Em pacotes do cliente para o servidor, até duas seqüencias podem ser enviadas, sendo estas separadas pelo caracter NUL. Em pacotes do servidor para o cliente, há apenas uma seqüencia (???) com a resposta do comando.

"Campos" de dados

¹ Se o segundo parâmetro estiver presente, a aplicação é feita visível. Do contrário ela executa escondida.

² O tipo pode ser "B" para binário, "D" para palavra-dupla (DWORD) e "S" para uma seqüencia de caracteres ("string"). Em campos binários, o valor é uma sequência de dois-a-dois dígitos hexadecimais (e.g. "ab 11 5f"); em campos palavra-dupla, o valor é o próprio em decimal; no tipo "S", o valor é a própria seqüencia de caracteres.

CRC

Criptografia

A criptografia é feita aplicando a operação XOR (ou exclusivo) entre cada byte do pacote e o valor seqüencial retornado por um gerador de número aleatórios. Este gerador é inicializado com um valor dependente da senha secreta utilizada nas comunicações. Desta forma, de posse da mesma senha, tanto o gerador de números aleatórios do cliente como o do servidor vai ser alimentado com o mesmo valor inicial, fazendo com que estes gerem a mesma seqüencia que poderá, então, ser usada para criptografar/decriptografar o pacote.

Este esquema de criptografia não é forte. Como todo o conteúdo de um pacote é criptografado e este sempre contém uma seção fixa (MAGICA) no cabeçalho, de posse de um pacote criptografado pode-se deduzir facilmente a seqüencia de número aleatórios gerados e utilizar-se de força bruta para descobrir o valor inicial do gerador de números aleatórios já que a faixa de valores que este pode assumir é pequena. Os métodos utilizados para decriptografar um pacote do BO sem a senha geradora estão fora do escopo deste documento e não serão cobertos nele, sendo deixados como exercício para o leitor.

O Gerador de Números Aleatórios

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

L = tamanho do pacote BO
X = 0
Z = IV
ENQUANTO X < L
	Z = BORAND(Z)
	P[X] = P[X] ^ ((Z >> 16) & 0xff)
	X = X + 1
FIM

Transferência de Arquivos via TCP

Quando o cliente envia um pacote TYPE_TCPFILESEND, o servidor abre o arquivo especificado e inicia a espera de uma conexão TCP na porta especificada. Então, o cliente conecta naquela porta TCP e inicia o envio do arquivo.

Quando o cliente quer receber um arquivo, ele envia um pacote TYPE_TCPFILERECEIVE especificando o nome do arquivo desejado e a porta TCP. O servidor então abre a porta e começa a enviar o arquivo assim que alguém (provavelmente o cliente) conecta nela.

O fluxo de dados TCP não é criptografado.

Todo este papo sobre envio/recebimento de arquivos via TCP é "(???)".

Referências

• Cliente BO para Unix
• ISS Security Alert Advisory (X-FORCE) -- "Cult of the Dead Cow Back Orifice Backdoor"

Copyright/disclaimer

Este documento e seu conteúdo, ou partes, pode ser copiado, utilizado ou ser tomado como base para outros documentos/trabalhos livremente sem necessidade de autorização do autor, desde que o crédito de autoria seja dado ao mesmo. Também, quaisquer cópias deste documento podem ser alteradas, traduzidas, corrigidas, etc., sem a necessidade de autorização do autor desde que a(s) alteração(ões) seja(m) mencionada(s) explicitamente (o que não elimina a necessidade de crédito ao trabalho do autor).

Você assume todo o risco e resposabilidade ao usar qualquer informação obtida neste documento. Em nenhum momento o autor pode garantir que este documento está totalmente correto e não poderá ser responsabilizado se este não estiver. Se você descobrir alguma falha neste documento, ou tiver alguma informação que possa contribuir para aprimorá-lo, fale comigo no endereço flaviovs@centroin.com.br. Qualquer informação que ajude a eliminar algum dos "(???)" será muito bem-vinda!

Agradecimentos

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

-x-x-

Última atualização em 8 de janeiro de 1999