Engenharia reversa : TF1700 ZKTeco

Engenharia reversa

Estou trabalhando em um projeto que envolve visão computacional e inteligência artificial. Como estou no início, vou escrever sobre meus primeiros contatos com o OpenCV, mas em outro artigo. Esse artigo trata da engenharia reversa feita em um dispositivo de biometria, RFID e senha, cujo protocolo necessitava ser migrado para o Raspberry e assim livrar-se da palataforma Windows para intaragir com o dispositivo.

Quero também deixar claro que esse procedimento pode ter fins benéficos ou maléficos, dependendo de quem o usa, mas é um procedimento adotado legalmente em perícia forense digital para levantar comportamento de aplicativos etc.

Condição e procedimento

O dispositivo se comunica por RS485 ou por ethernet, utilizando o mesmo protocolo de comunicação. Como ele será utilizado sobre ethernet, fizemos um sniffing da comunicação, interceptando-a entre o host Windows e o dispositivo. Para fazer interceptação você pode utilizar mais de um modo, mas nada como um equipamento especialista como esse TAP Ethernet DWOS demonstrado nesse artigo onde interceptei minha smart TV Samsung e nesse outro, onde interceptei a comunicação de um Arduino para buscar por otimizações no código.

Não há um meio de adivinhar o que acontece se não for fazendo um passo-a-passo, um comando por vez, desde a comunicação. Não poderei abrir todo o protocolo aqui por se tratar de um produto da empresa, mas vou mostrar um ou dois.

A comunicação entre o dispositivo e o aplicativo é feita sobre UDP na porta 4370, então vamos ao primeiro pacote escolhido para esse artigo utilizando o tcpdump com o comando:

tcpdump -i any host not 127.0.0.1 and port 4370 -vvv -XX -s4192

Se não estiver familiarizado com o tcpdump e deseja saber mais, escrevi esse artigo exclusivo sobre o assunto.

Sobre o dispositivo alvo

Se você não conhece, o dispositivo em questão é esse:

O TF1700 é um leitor biométrico, leitor RFID e senha, tudo integrado. Ele possui relé para abertura de portaria e mais alguns recursos interassantes. Ele é IP65, portanto resistente a água e poeira. Não é a melhor opção, mas em relação custo/beneficio é o mais viável. Além disso, seu protocolo é bastante descomplicado, incluindo apenas um checksum base 64, o que facilitou em muito fazer a comunicação com ele, que inicialmente deu-se através de Python.

A primeira coisa notada é que o protocolo é genérico, para funcionar com outros dispositivos da linha com reconhecimento facial etc. Isso foi percebido através da troca de comandos onde o aplicativo requeria os valores para determinados recursos indisponíveis nesse dispositivo. Também, os primeiros 3 pacotes são uma tentativa de comunicação na mesma porta através de TCP, portanto deve haver algum dispositivo da linha que faça tal comunicação. Mesmo assim nada disso foi empecilho.

Por fim, esse dispositivo utiliza um processador MIPS rodando Linux:

Conceito do protocolo UDP

Para iniciar essa análise, é necessário saber o formato do protocolo UDP e da comunicação na rede. No mais alto nível, o UDP não estabelece conexão nem certifica a entrega do pacote. Nessa comunicação ele pode (ou não) receber uma resposta. Nós não precisaremos dominar a ciência por trás de cada um dos campos envolvidos na comunicação, mas precisaremos saber identifica-los.

Acredito que essa imagem irá ajudar no exclarecimento das próximas explicações:

Esse é o formato do encapsulamento do pacote. Não é fundamental decorar, mas é essencial que seja compreendido. Na engenharia reversa vamos descer ao mais baixo nível e vamos nos deparar com cada um desses campos. Prontos? Então vamos ao pacote capturado.

A linha que inicia com o horario e a linha seguinte são já um formato interpretado para conforto do usuário. Mas como estamos analisando o conteúdo no mais baixo nível, teremos que passar por essas informações através dos hexadecimais de qualquer modo.

0x0000

O campo em cinza dessa linha indica o MAC de origem, seguido pelo MAC de destino (campo rosa). Isso faz parte do header do protocolo ainda.

Depois em branco, temos o hexadecimal 0800, indicando o tipo de pacote. Tratando-se de big endian, deve-se lembrar de inverter esses valores, portanto o valor é 0008, que representa o pacote IPv4.

O último campo tem os valores 4500, já pertencendo ao IPv4, sendo:

4 -IP

5 -  tamanho do cabeçalho (5 palavras de 32 bits)

00 - TOS.

0x0010

o Primeiro campo (cinza) é o comprimento total da mensagem. O valor 0x28 é 40 decimal, portanto você pode confirmar no canto direito da primeira linha a correspondência.

o campo seguinte em branco, é o 0000. Ele é utilizado para enumerar os pacotes fragmentados, porém o dispositivo em questão sempre envia a flag [DF] (repare na primeira linha), que significa "don't fragment", ou seja, ele espera receber tudo de uma só vez. Como ele também envia tudo de uma só vez, ele sempre utiliza o ID 0.

4000 - O offset do fragmento, sendo o primeiro bit reservado.

b846 - checksum

C0A8 80D3 - 192.168.128.211 (src)

C0A8  805A - 192.168.128.90 (dst)

0x0020

Perceba que 805A já está nessa teceira linha dos hexadecimais, não se importe com isso.

1112 - Porta de origem, sendo 4370 (1112 em hexa é 4370, right?).

c01e - porta de destino (49182).

0014 - tamanho do pacote UDP (incluindo cabeçalho UDP). Tira-se o cabeçalho de 8 bytes e o restante é a mensagem. Nesse caso 0x14 = 20; 20-8 =12. Confirmado no fim da segunda linha (lenght 12).

AC16 - checksum do UDP.

F4 01 A8 18 00 04 00 00 55 8E 0E 53 -  A mensagem do dispositivo, propriamente dita. O primeiro campo (80d3) é o identificador do host, o segundo campo é o tipo de evento. 0004 é RFID.

0x0030

O valor 558E 0e53 é o número do RFID, de resto não posso mais dar detalhes.

Depois, deve-se ir separando cada comando em arquivos distintos para fazer a análise e ao final, bastará escrever o protocolo novamente!

Enfim, espero que esse artigo tenha atingido o objetivo de introduzir um processo de engenharia reversa através da comunicação em rede, assim como incentivá-lo a adquirir um interceptador de redes forense DWOS Tap, que é um produto criado por mim e minha equipe.

Inscreva-se no nosso canal Manual do Maker Brasil no YouTube.