Engenharia reversa : TF1700 ZKTeco

DWOS TAP
DWOS TAP

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:

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:

tf1700
tf1700

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 impecílio.

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

ZKLinux
ZKLinux

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 identificá-los.

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

udp
udp

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.

interceptação de pacotes
interceptação de pacotes

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!

separando comandos
separando comandos

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 newsletter, alí em cima à direita e receba novos posts por email.

Siga-nos no Do bit Ao Byte no Facebook.

Prefere twitter? @DobitAoByte.

Inscreva-se no nosso canal Do bit Ao Byte Brasil no YouTube.

Nossos grupos:

Arduino BR – https://www.facebook.com/groups/microcontroladorarduinobr/
Raspberry Pi BR – https://www.facebook.com/groups/raspberrybr/
Orange Pi BR – https://www.facebook.com/groups/OrangePiBR/
Odroid BR – https://www.facebook.com/groups/odroidBR/
Sistemas Embarcados BR – https://www.facebook.com/groups/SistemasEmbarcadosBR/
MIPS BR – https://www.facebook.com/groups/MIPSBR/
Do Bit ao Byte – https://www.facebook.com/groups/dobitaobyte/

Próximo post a caminho!

Agregador de Links - Loucuras da Net

 

Comments

comments

Djames Suhanko

Djames Suhanko é Perito Forense Digital. Já atuou com deployer em sistemas de missão critica em diversos países pelo mundão. Programador Shell, Python, C, C++ e Qt, tendo contato com embarcados ( ora profissionalmente, ora por lazer ) desde 2009.

Um comentário em “Engenharia reversa : TF1700 ZKTeco

Comentários estão encerrados.