Grupo 3 - Rafael - Validacao Da Seguranca em Rede Com Engenharia Reversa

VALIDAÇÃO DA SEGURANÇA EM REDE COM
ENGENHARIA REVERSA
Universidade Paulista
Jundiaí - SP RESUMO
O artigo aborda a problemática da proteção inadequada em

Autor(es): sistemas de computador e comunicação entre cliente e ser-
Andrew Herculano da Silva
andrew.silva13@aluno.unip.br
vidor, destacando a extensão dos problemas resultantes da
Leonardo Augusto Bisetto interceptação de dados e engenharia reversa. Com base em
Missiano
contatobisetto@gmail.com estudos e projetos existentes, o estudo utiliza métodos adap-
Leonardo Vitorino Baptista tados para reconstruir completamente o servidor-alvo e criar
leonardo.baptista1@aluno.unip.br
trapaças que manipulam o tráfego entre cliente e servidor.
Lucas Henrique Rodrigues
lucas.rodrigues75@aluno.unip.br Como resultados tivemos a reconstrução parcial do servidor-
William Rodrigues Bueno
alvo e a manipulação do tráfego por meio de proxy. Conclui-
william.bueno1@aluno.unip.br
se que a proteção contra tais ataques é desafiadora, dada a
Orientador(a):
Prof. Rafael Gross
localização dos dados no lado do cliente, exigindo atenção
rafael.gross@docente.unip.br especial à criptografia e à validação rigorosa das respostas
do cliente. O estudo destaca a complexidade da implemen-
tação de defesas eficazes e enfatiza a importância crucial da
segurança na comunicação para desenvolvedores.
Palavras-Chave: Redes. Engenharia reversa. Segurança.

Protocolos. Proxy. Servidor. Cliente. Jogo.
ABSTRACT
Demonstration of the problem involving inadequate

protection of computer systems and communication between
client and server, applying reverse engineering to network
protocols that transmit without encryption or any other type
of protection. Reconstruction of the distribution system
(server) for unprotected applications as a final proof of
concept. In addition, addressing small introductions to basic
security concepts.
Keywords: Networks. Reverse. Engineering. Security.

Protocols. Proxy. Server. Client. Game.
1
2
1. INTRODUÇÃO
A comunicação de sistemas entre plataformas e dispositivos é de fundamental

importância para o conceito de sistemas distribuídos. Os sistemas utilizam pro-
tocolos de comunicações específicos para determinados fins, além de protocolos
proprietários criados pela própria desenvolvedora do sistema. O problema é que
nem sempre medidas de segurança como criptografia, compressão de dados e
ofuscação são usados de forma adequada, ou sequer são usadas, tornando as-
sim a comunicação suscetível a intervenções por meio de análise de pacotes,
que tem como objetivo compreender a comunicação e a estrutura pela qual da-
dos são enviados e recebidos entre o cliente e o servidor.
Segundo James Forshaw:

Se você puder analisar um protocolo de rede inteiro apenas olhando
os dados transmitidos, então sua análise é bastante simples. Mas nem
sempre é possível com alguns protocolos, especialmente aqueles que
usam esquemas personalizados de criptografia ou compressão.
(APPLICATION..., 2017, p. 136)
“Use engenharia reversa dinâmica tanto quanto possível para inspecionar tipos
em tempo de execução para determinar para que eles são usados”. (Application,
2017, p. 174).
Num cenário empresarial dinâmico, a engenharia reversa emerge como uma

ferramenta estratégica para muitas organizações, impulsionando melhorias
contínuas em produtos e serviços, além de fornecer insights valiosos sobre as
práticas dos concorrentes. Contudo, essa prática também abre uma porta para
usos indevidos, onde indivíduos mal-intencionados exploram métodos de
engenharia reversa para falsificar conteúdos, disseminando ilegalmente
softwares ou serviços, como os infames “cracks” (Programas alterados ilegais)
ou emuladores de programas (Programas reconstruídos). Este estudo examina
de que maneira a ausência de criptografia pode comprometer não apenas a
integridade, mas também o valor intrínseco de um sistema, o que destaca a
importância crucial de salvaguardas eficazes para proteger contra tais
explorações indevidas.
Unip – Jundiaí – SP - 2023

3
1.1 QUESTÃO PROBLEMA
É possível recriar um sistema que se comporte igual ao original sem saber seu
código fonte, apenas analisando os pacotes trafegados sem o devido tratamento?
1.2 OBJETIVO GERAL
Investigar os impactos da engenharia reversa na segurança de sistemas de

comunicação, com ênfase na análise de pacotes de dados, visando compreender
como a ausência de criptografia pode comprometer a integridade e a
confidencialidade das informações, bem como explorar estratégias para mitigar
essas vulnerabilidades.
1.3 OBJETIVO ESPECIFICO
• Analisar as práticas de engenharia reversa adotadas por empresas para apri-

morar produtos e serviços, bem como por indivíduos mal-intencionados na
propagação ilegal de softwares.
• Desenvolver uma compreensão abrangente das técnicas e ferramentas uti-

lizadas na engenharia reversa, com foco na análise de pacotes de dados em
busca de vulnerabilidades.
• Propor estratégias eficazes para mitigar os riscos associados à engenharia

reversa, com ênfase na implementação de criptografia e outras medidas de
segurança para proteger a integridade dos sistemas.
Ao definir esses objetivos, busca-se não apenas compreender os desafios

inerentes à engenharia reversa, mas também fornece soluções práticas para
fortalecer a segurança dos sistemas em ambientes propensos a essas práticas.

4
1.4 METODOLOGIA
Pesquisa e análise das tecnologias de proxy transparente em Java, protocolos

de comunicação e métodos de interceptação de dados, para desenvolver uma
ferramenta de proxy transparente em JAVA capaz de interceptar os dados entre
cliente e servidor, com isso submeter dados obtidos da comunicação para ana-
lise manual, avaliar alterações de comprimento e caracteres baseados em ações
no sistema, para então adicionar regras que estruturem o conteúdo ao proxy afim
de mapear e torná-lo legível a humanos.
Recriar o sistema servidor simplificado (Login e Word) na linguagem JAVA repli-

cando a comunicação compreendida com a ajuda da ferramenta de proxy, no
mesmo protocolo usado originalmente, que possibilite a comunicação com o cli-
ente de forma semelhante a original.
Ao final analisar os resultados obtidos e documentar todo o processo.
1.5 JUSTIFICATIVA
A relevância busca entender a necessidade em aprimorar a segurança em

aplicações, um requisito inalienável em um cenário cibernético permeado por
constantes ameaças. A engenharia reversa, uma prática recorrente tanto para
otimização de produtos quanto para atividades ilícitas, destaca a importância de
estratégias de defesa inovadoras. Ao explorar a falta de criptografia e suas
implicações na integridade dos sistemas, este trabalho visa preencher uma lacuna
crítica no entendimento das vulnerabilidades associadas à comunicação entre
cliente e servidor. Além disso, a concepção e implementação de uma ferramenta
de proxy transparente em Java, aliada à recriação do sistema servidor, não
apenas fornecem um quadro prático para análise, mas também estabelecem uma
fundação sólida para o desenvolvimento de contramedidas eficazes. Ao final, esta
pesquisa busca contribuir para o avanço contínuo no campo da segurança
cibernética, oferecendo insights tangíveis para o desenvolvimento de aplicações
mais resilientes e seguras contra as complexas ameaças da engenharia reversa.

5
2. DESENVOLVIMENTO
2.1. FUNDAMENTAÇÃO TEÓRICA
A análise de pacotes entre outras técnicas não são uma coisa nova na
engenharia reversa. Temos muitos casos de empresas que usaram engenharia
reversa em produtos da concorrência para garantir versões próprias de
funcionamento semelhante. Uma prova disso foi a época dos clones de consoles
feitos no Brasil, que na sua grande maioria não passavam de copias do consoles
originais das grandes empresas.
Esses consoles eram incentivados pelo governo para proporcionar um

crescimento da indústria brasileira de eletrônicos no país como explicado na
matéria da Redbull, que afirma:
Os consoles criados no Brasil eram únicos e especiais. Cada clone bolava

uma gambiarra nova para se destacar dos concorrentes, que abusavam de
engenharia reversa pra descobrir e copiar os segredos dos grandes consoles
oficiais. (ATAQUE dos clones, 2017)
O uso da engenharia reversa para analisar produtos se estende as camadas de

redes com ferramentas próprias ou difundidas no mercado como as citadas em
Análise de tráfego de rede 2.2.2, que com o compreendimento do tráfego é
possível desvendar os segredos da comunicação entre partes de um sistema.
Em 2011 o pesquisador Efim Bushmanov conseguiu por meio de engenharia
reversa recriar o código de protocolo do Microsoft Skype, também recriou uma
versão funcional do aplicativo Skype. Segundo ele “O Skype utiliza forte
criptografia AES e RSA com infraestrutura de chaves públicas”
(PESQUISADOR..., 2011).
Como dito por Efim Bushmanov a respeito do Skype, as comunicações entre

sistemas normalmente são criptografadas ou ao menos deveriam ser. Mas
porque ela deveria ser criptografada? A falta de criptografia facilita o
compreendimento do tráfego e permite interações direta com tudo que está
sendo trafegado, abordado em Protocolos e segurança de rede 2.2.1.

6
2.1.1. Protocolos e segurança de rede
Uma das tecnologias usadas para criptografia ou troca de informações de forma

segura é a SSL/TLS.
O Transport Layer Security (TLS), e seu antecessor Secure Sockets Layer (SSL)
foram desenvolvidos para criptografar comunicações na rede de computadores,
sendo usados atualmente em todos os sites que se comunicam através do
protocolo HTTPS.
Seu sistema de criptografia é composto de uma combinação de criptografia

simétrica e assimétrica, a criptografia assimétrica é usada para negociar a chave
secreta da criptografia simétrica que será usada durante a troca de dados. Isso
proporciona uma comunicação eficiente, uma vez que a criptografia simétrica é
geralmente mais rápida do que a criptografia assimétrica em conexões TCP que
se mantém ativas o tempo todo.
Os certificados digitais usados no servidor de login são baseados em criptografia
assimétrica, que envolve o uso de chaves públicas e privadas, para cada pessoa
ou entidade que deseja utilizar um certificado digital é gerado um par de chaves:
uma chave pública e uma chave privada, sendo a chave pública compartilhada
e adicionada ao certificado digital que é obtido durante o acesso pelo usuário, já
a chave privada é apenas de uso proprietário da pessoa ou empresa e é usada
para assinar e validar tráfego recebido e enviado, quando alguém se comunica
com o sistema que usa o certificado, usa a chave pública contida no certificado
para criptografar os dados que quando chegam ao sistema usa a chave privada
para decriptar o conteúdo, como no seguinte fluxo.

7
(Fluxo de transferência de dados TCP usando certificado digital)
Ao inspecionar o tráfego com a ferramenta de análise Wireshark, pode-se ver os

dados passados nos campos de login e senha em texto claro de um site com o
protocolo HTTP, que não possui criptografia.
(Comunicação HTTP capturada pelo Wireshark, autoria própria)
Já em comunicações com HTTPS como protocolo, a compreensão se torna

inviável.
(Comunicação HTTPS capturada pelo Wireshark, autoria própria)
O jogo base para esse projeto, e que é feito para testes, contém dois exemplos
de servidores, um servidor de autenticação com comunicação criptografada

8
TSLv1 e certificado digital válido da empresa distribuidora do jogo e outro apenas

com TCP que se comunica em um padrão de dados proprietário que será
abordado em Análise na prática 2.2.2.3.
Quando falamos de TSL temos três abordagens para poder analisar a

comunicação neste caso, sendo duas delas viáveis.
A primeira é o uso de um proxy transparente no meio da comunicação quando a

aplicação não faz questão de validar se o certificado emitido é válido e de
propriedade da empresa a qual espera receber esta comunicação.
É possível validar esse exemplo na própria WEB onde temos sites que usam
certificados digitais assinados, neste caso o navegador não faz questão de
validar se o certificado é realmente da origem esperada, apenas se ele é
confiável e está na lista ou no diretório de certificados confiáveis do
sistema/navegador.
Quando usamos um proxy para interceptar esta comunicação temos o seguinte

fluxo.
(Fluxo de comunicação interceptada TCP por proxy transparente)
Quando o proxy no meio tem o certificado ou chave pública compatível com a

qual foi usado para criptografar a comunicação, podemos realizar o processo
inverso e ler o conteúdo trafegado, encripta-lo novamente e enviar para seu

9
destino original, como isso podemos modificar qualquer conteúdo que seja
acessado, por exemplo se alguém estiver em uma rede de uma empresa ou rede
pública, é possível ter os dados visualizados ou alterados em tempo real por
outra pessoa, para exemplificar melhor é possível realizar um teste na WEB
usando um proxy no meio para alterar os dados recebidos do banco Itaú.
(Pagina original Itau 02/09/2023)
Com a ferramenta de proxy Charles proxy versão 4.6.4, pode-se alterar todo o
conteúdo enviado para o navegador.
Com algumas regras simples, é possível alterar o texto exibido no botão “abra
sua conta” além de modificar para onde ele aponta.

10
(Ferramenta Charles proxy versão 4.6.4, regras de alteração de conteúdo.)
Ao acessar o site com a ferramenta de proxy no meio, acontece a alteração tanto

do texto quanto da URL para onde o botão direciona, mantendo o ícone de
segurança (cadeado) que as pessoas confiam, contudo foi usado um certificado
digital próprio, auto assinado, dessa forma é necessário que o mesmo esteja
instalado no repositório de certificados confiáveis no sistema alvo.

11
(Site do banco Itau como HTML editado em tempo real pela ferramenta Charles proxy)
Uma segunda técnica viável é extrair o certificado usado para criptografia dos
dados direto do cliente da aplicação, isso é possível a partir de engenharia
reversa como exemplificado no tópico Engenharia reversa de software 2.13,
ao fazer a análise da aplicação, que pode ter passado por processos de
ofuscação criptografia e compactação de dados, o que dificultaria o processo,
mas não o impossibilitaria, uma vez que os dados do lado do cliente sempre
poderão por meio de interferência serem alterados como é o caso de cracks
(Programas alterados) de jogos e aplicativos.
A terceira forma seria quebrar por força bruta da criptografia TSL por meio de
fatoração de primos, o que é praticamente inviável então não será abordado
nesse artigo.
No caso do servidor de login que usa TSLv1 ainda existem ataques como
POODLE que permitem o rebaixamento de conexões permitindo a leitura dos
dados trafegados, mas que também não abordaremos já que este não é o foco
do projeto.

12
Como o jogo base foi criado para testes existe o certificado digital original
disponível e não será necessário passar por nem um destes processos, uma vez
que o objetivo deste projeto é mostrar o problema derivado da interceptação do
tráfego desprotegido ou mal protegido.
2.1.2. Análise de tráfego de rede.
Como citado anteriormente, a análise do tráfego de rede objetiva em entender a

comunicação entre dois pontos, busca por ameaças de segurança ou determinar
padrões de comunicação.
A ferramenta Wireshark é uma das mais usadas atualmente na área de redes,

possibilita a captura e análise de pacotes trafegados pela rede além de ser
comumente usada por profissionais da área, com o intuito de solucionar
problemas de diversos, e é uma das principais ferramentas que usaremos para
mostrar pacotes neste projeto.
O autor Robert Shimonski diz o seguinte em seu livro guia:

Por mais de duas décadas, a necessidade de compreender a análise
de protocolos tem aumentado enquanto as redes com as quais
contamos para conectar nossos computadores, os dispositivos moveis
e os sistemas para usar a Internet, acessar a nuvem e trabalhar em
nossas redes corporativas também vem se expandindo.
(Wireshark... 2013, p. 17).
Nas imagens anteriores, ao usar a ferramenta Wireshark, foi possível visualizar

a comunicação encriptada HTTPS além do conteúdo em texto claro em HTTP
que não possui uma camada de criptografia adicional.
No caso do jogo base que usamos existem duas formas de comunicação: uma
usando TSL e outra sem proteção, apenas com tráfego TCP, em Análise na
prática 2.2.2.3 será mostrado o processo usado para compreensão dos dados
trafegados, mas de forma resumida, qualquer dado trafegado depende de uma
análise normalmente manual, isto é, analisar variações dos conjuntos de dado
obtidos a fim de identificar padrões de comportamento em determinadas

13
situações, como: ao tomar uma ação dentro do jogo, qual pacote é enviado?
Quais campos ele contém? E como esses campos se alteram ao ponto que se
muda o ângulo, direção, habilidade ou outras coisas, assim é possível por meio
de tentativa erro descobrir o que se trata em cada campo transmitido, sem dúvida
a análise manual é um trabalho longo que requer experiencia e tempo, uma vez
que os dados podem estar em diversos tipos e formados diferentes como
inteiros, floats entre outros, que alteram os resultados de saída para cada um
deles.
Mas além de criptografia existem outros recursos usados na tentativa de proteger

os dados trafegados que devem ser levados em conta, como ofuscação e
compressão de dados.
2.1.2.1. Ofuscação de dados
Ofuscar um código, uma mensagem ou qualquer outra coisa, nada mais é do

que dificultar para outa pessoa ou máquina possa entender o real conteúdo e
proposito dos dados ao inserir conteúdo desnecessário, trocar campos de
identificação por valores aleatórios, remover endentação, entre outros. Após um
processo de ofuscação o conteúdo ainda está lá, no caso de um código sua
execução ainda resulta na saída esperada, mas para os humanos tentar
entender um código ofuscado é muito complexo, uma vez que seria necessário
passar por todo processo de execução manual do código para determinar o que
realmente é importante e o que é “lixo” colocado com propósito de dificultar a
compreensão
Abaixo um exemplo simples de um código feito em JavaScript antes de passar

por ofuscação e após o processo de ofuscação.

14
(Código simples em JS sem ofuscação, autoria própria)
(Código simples em JS após processo de ofuscação, autoria própria)
Neste caso foi ilustrado usando um código simples em JavaScript para facilitar a
compreensão, mas da mesma maneira isso pode ser aplicável a pacotes de
rede, que não necessariamente aumentam o seu tamanho, mas podem trocar
informações de lugar ou usar pedaços de diferentes partes do conteúdo do

15
pacote para obter a informação necessária. Este é um processo que pode ser
bem simples e fornece um bom resultado, porém temos que lembrar que uma
pessoa treinada com uma base de experiência conseguiria reverter este código
próximo ou igual a sua forma original, uma vez que as informações de execução
ainda estão contidas nele, e que diferente da criptografia não necessita de chave
ou qualquer outro processo para reverter sua informação ao estado original.
2.1.2.2. Compressão de dados
A compressão dos dados transmitidos por pacotes de rede, além de otimizar o

custo de transmissão, dificulta sua compreensão por parte de pessoas
inexperientes ou até por pessoas experientes se o algoritmo de compressão for
proprietário e não público.
O tema de compressão de dados é extremamente amplo, a compressão está em

constante evolução e é comumente usada hoje para transmissão de dados,
streaming de áudio e vídeo em alta resolução, dados de satélites entre diversas
outras coisas. Não teria como abordar todo conteúdo sobre compreensão de
dados, então para ter uma compreensão melhor, recomendamos o vídeo do
influenciador Fabio Akita (De 5 Tera a 25 Giga, 2022) que apesar de abordar
compressão de vídeo nos dá uma ideia da amplitude deste tema.
Para facilitar a compreensão, existe um exemplo muito simples de compressão

abaixo.
Imagine as seguintes mensagens enviadas (já em texto claro).
• Pacote 1: (olá, como você está?)

• Pacote 2: (olá, estou bem. E você?)
• Pacote 3: (estou bem, Obrigado!)
Pacote 1 em hexadecimal:
“6F6CE12C20636F6D6F20766F63EA20657374E13F”

16
imagine que aja uma solução em ambos os lados que de forma progressiva gere
um dicionário, que acumula as palavras mais usadas. Sendo possível trocar as
palavras por referências a este dicionário que ficaria assim:
• olá -> 1;
• como -> 2;
• você -> 3;
• está -> 4;
• estou -> 5;
• bem -> 6;
• obrigado -> 7.
Então agora para enviar essas mesmas mensagens seria usado muito menos
recursos, porque sua saída seria:
• Pacote 1: (1, 2 3 4?)

• Pacote 2: (1, 5 6. E 3?)
• Pacote 3: (5 6, 7!)
Pacote 1 em hexadecimal: “312C2032203320343F”
Com este exemplo pode-se ter uma ideia mínima de como funciona uma
compressão de pacotes, obviamente existem muitos métodos de compressão
para determinadas situações que podem ter uma maior ou menor compressão
com e sem perda de dados. Esse exemplo é simples e apesar de terem métodos
de compressão que usem dicionários, esse exemplo não aborda uma situação
real.
2.1.2.3. Análise na prática
Ao olhar novamente para o Wireshark agora pronto para analisar a aplicação do

jogo base testado, existe o seguinte pacote enviado constantemente ao servidor:

17
(Pacote trafegado entre cliente e servidor. Autoria própria)
Este pacote contém um conteúdo mostrado em hexadecimal que não passou por
nem um dos processos mencionados anteriormente e contem alguma
informação referente ao estado atual do jogo de forma limpa.
Ao movimentar o personagem dentro do jogo, o pacote que é enviado

constantemente, agora tem um valor em hexa diferente do anterior:
(Pacote trafegado entre cliente e servidor. Autoria própria)
Ao analisar e separar estes dados podemos compreender o padrão.

Normalmente em aplicações que se comunicam via rede, os pacotes são
identificados um ou dois bytes iniciais chamados de “magic number” ou “magic
byte”, isso é usado para que o sistema possa tratar o pacote da forma correta.
Se dividir os dados do pacote em pedaços de 4 bytes após o identificador, o

conteúdo fica assim:
(Comparação de código transmitido entre cliente e servidor. Autoria própria)
Neste caso foi separado em pedaços de 4 bytes apenas para facilitar o trabalho
e por suposição de que a maioria dos primitivos usados para esse pacote tenham
4 bytes de tamanho como inteiros, por exemplo.
Como dito antes, o novo pacote foi gerado ao movimentar o personagem, então
não é difícil de acreditar que possa se tratar de um pacote de coordenada do
jogador. Após os 2 bytes de identificação, existem 3 conjuntos de 4 bytes que se
alteraram, é sabido que um jogo normalmente utiliza coordenadas X, Y, Z
respectivamente para sua posição, fica fácil associar esses conjuntos de bytes
que se alteraram a essas coordenadas. É possível dizer então que este pacote

18
é de coordenas, mas qual seria seu tipo de variável? Inteiro, double, float ou
proprietário?
Esse novo pacote foi gerado ao mover o personagem apenas um pouco
para frente, e mesmo assim os 3 conjuntos de bytes mudaram muito, isso
é um sinal claro de que estamos lidando com float ou double de 4 bytes,
uma vez que permitem valores com casas decimais, o que faz mais sentido
nesse caso.
Se pesquisar sobre desenvolvimento de jogos é fácil encontrar a

informação que esse tipo de variável usada para coordenadas é float,
nesse caso é viável tentar realizar a conversão e ver se o resultado obtido
bate com o esperado:
(Mapeamento do conteúdo trafegado entre cliente e servidor. Autoria própria)
Nota-se que a variação dos dados após a conversão faz total sentido com
a forma com a qual eles foram gerados, o que confirma tanto a suposição
inicial de que os 3 conjuntos de 4 bytes pertenciam as coordenas quanto
de que suas variáveis eram float e estavam certos.
Essa é apenas uma pequena amostra de como o processo de análise do

tráfego de um jogo funciona. Logicamente esses dados estão
representados de maneira “limpa” sem passar por ofuscação, compressão
ou criptografia, o que torna o trabalho muito mais fácil.
2.1.3. Engenharia reversa de software

19
Existem diversas formas para realizar engenharia reversa em software, não

seria impossível abordar todo o assunto, então será abordado algumas
formas e técnicas usadas neste projeto.
Para Canhota Junior (2005), a Engenharia reversa de software pode ser

efetuada por vários métodos. Tendo três grupos principais.
2.1.3.1. Análise de fluxo de dados
A análise do fluxo de dados é o ato de “ouvir”, analisar e compreender

dados trafegados por diversos lugares como os próprios barramentos de
um computador, ao acessar e escutar os dados trafegados entre a própria
memória e o processador. Algumas trapaças em jogos fazem uso de uma
FPGA (Field-Programmable Gate Array), é basicamente uma placa
programável que ao ser conectada em entradas PCI-e passa a ter acesso
a endereços da memória que os usuários comuns não teriam acesso, como
posição de jogadores, pontuação ou dados trafegados entre máquinas
virtuais virtualizadas em cima de um host, por exemplo.
Normalmente este tipo de hardware é usado para analisar a comunicação

de diversos dispositivos e drives na tentativa de recriá-los para outros fins.
Além disso é possível capturar informações em diversas outras partes da
máquina, como por exemplo portas de entrada e saída de dados. Nesse
caso, como dito antes, o fluxo principal que será usado para monitorar
comunicação será o de rede.
Análise através da observação da troca de informações que envolvem
“analisadores de bus” e “pacotes de sniffers” por exemplo, para "ouvir"
dentro do bus de um computador ou uma conexão de rede, revelando
o tráfico de dados "escondidos". O comportamento dos dados no bus
ou na rede podem então ser analisados para produzir uma nova imple-
mentação do software que imita o mesmo comportamento. Isto é es-
pecialmente utilizado na engenharia reversa de drivers de dispositivos.
(Canhota Junior, ENGENHARIA..., 2005)

20
2.1.3.2. Disassemble
O disassemble ou “desmontar” em português é o ato de decompor o

programa em suas instruções assemble. Existem vários programas para
fazer isso, alguns deles muito conhecidos o Ghidra, IDA Pro, OllyDbg entre
outros.
O processo é feito ao ler o código como o processador o executaria, só que

em vez de executa-lo ele é mostrado na forma de texto para o usuário. Esse
tipo de recurso pode ser muito útil para entender como um software executa
determina função, como ele interpreta cada tipo de entrada e computa uma
saída válida.
Pode-se usar este tipo de recurso no caso de criptografia, compressão ou

protocolo proprietários, onde não se conhece a forma como o os dados que
serão enviados pela rede são formados, nesse caso o disassemble pode
ser muito útil, uma vez que com o código que será executado pelo
processador em mão é possível ver a chamada responsável por criar,
encriptar ou modelar determinado dado a ser enviado, desta forma facilita
fazer o processo inverso para conseguir os dados originais, modificá-los e
compilá-los novamente para continuar seu envio.
Usando um desassembler, conseguimos obter a linguagem de má-
quina diretamente do programa. Este código é lido e entendido nos
seus próprios termos, apenas com a ajuda de “mneminics” da lingua-
gem de máquina. Isto funciona em qualquer programa de computador,
mas pode levar um bom tempo, especialmente para alguém que não
esteja acostumado ao código de máquina. (Canhota Junior,
ENGENHARIA..., 2005)
Abaixo existe um disassemble de um programa simples em C que apenas

executa uma saída na tela com a frase “Hello, World!” visto no programa
Ghidra.

21
(Disassemble de um programa em C, “Hello, World!” usando Ghidra, autoria própria)
2.1.3.3. Decompilação
A decompilação, diferente do disassemble que apresenta o código em baixo

nível, tenta recriar um código em uma linguagem de mais alto nível para facilitar
a compreensão do seu funcionamento.
Normalmente um código em baixo nível em assembly é convertido para C que é

considerada de mais alto nível.
Segundo Canhota Junior, (2005) “Neste método utiliza-se um decompilador, um

programa que tenta recriar o código-fonte em uma linguagem de alto nível, tendo
disponível apenas o código de máquina”.
A conversão de códigos mais complexos não resulta no código exato usado no

programa, mas dão uma boa noção para compreender determinados pontos do
programa, além de ser possível “editá-los” para uma melhor organização e
compreensão de nomes de variáveis e funções que compõem o software.
É necessário lembrar que alguns programas podem ter passado por processos
de ofuscação que já foi explicado antes, o que torna o processo muito mais
complexo, uma vez que primeiramente seria necessário compreender qual o tipo
de ofuscação foi usado para depois reverte-la e só então iniciar a interpretação
do programa original, literalmente analisar para poder analisar.

22
Abaixo mostra o mesmo programa em C com a saída da frase “Hello Word”

visto com a função de decompilação do programa Ghidra convertendo o código
de baixo nível assembly para alto nível C, quase da mesma forma que a origi-
nal.
(Decompilação do assemble de um programa em C “Hello, World!” no Ghidra, autoria própria)
2.2. Desenvolvimento na prática.
2.2.1. Mapeamento de pacotes.
Para realizar o mapeamento dos pacotes, foi criado um proxy transparente

que recebe dados enviados pelo cliente ou servidor antes de serem
encaminhados para o destino.
Esses dados são exibidos na tela em formato hexadecimal, como mostrado
na logo abaixo. Com esses dados em mãos inicia-se o processo de analise
como visto em Análise na prática 2.2.2.3, que é um processo
relativamente simples de tentativa e erro.
(Imagem 1 pacote de disparo dentro do jogo enviado pelo cliente. Autoria própria)

23
Na imagem acima pode-se ver um pacote enviado pelo cliente do jogo após uma
ação de disparo, esse pacote não possui criptografia, ofuscação, ou
compressão, nele é possível encontrar todas as informações que o cliente quer
informar ao servidor divididos em campos.
Como vimos em Análise na prática 2.2.2.3, é necessário aplicar variações no
jogo para identificar campos que se alteram, como quando é realizado um
disparo com outra arma.
(Pacote de disparo contendo campos em hexa explicados. Autoria própria)
Com um pouco de prática é possível apenas de observar alterações, identificar

campos que se alteram e qual tipo de dados eles carregam, em campos de texto
como o tamanho é variável normalmente existe um pequeno campo antes do
texto de 2 bytes para definir o tamanho que a Sting a seguir terá. Apesar de
existirem campos mais complexos com tipos proprietários ou valores que exigem
conhecimentos específicos de rotação e cálculos de ângulos, com esse tipo de
lógica é possível mapear a maioria dos pacotes sem muitos problemas.
Ao longo do processo de mapeamento dos pacotes foram criadas regras dentro

do proxy para “traduzir” cada um dos campos que já tinham sido identificados, o
que torna a saída compreensiva para humanos.
As regras foram aplicadas dentro de uma classe JAVA que é compilada em

tempo de execução e ficam assim.

24
(Função para tradução do pacote de habilidade cliente. Autoria própria)
Caso o pacote possua outros pacotes associados a ele, um processo recursivo

é acionado até que o último pacote seja resolvido, o resultado final é o seguinte.
(Pacote enviado pelo cliente e respondido pelo servidor após tradução. Autoria própria)
Alguns campos como rotação ou ângulo não foram traduzidos porque exigem um
conhecimento no desenvolvimento de jogos que não é necessária para prova de
conceito.
Como foi compreendido o comportamento dos pacotes e os valores de cada

campo, é possível tentar injetar pacotes falsos tanto para o servidor quanto para
o cliente. No caso do cliente existe a possibilidade injetar monstros em lugares
que não existem, claro que eles não terão nem uma ação porque o servidor não
sabe da existência dele então ele é apenas visualizado do lado do cliente.
Para realizar isso o pacote original de um monstro que existe no jogo é capturado
no lugar onde ele realmente deveria estar.

25
(Pacote capturado de um monstro no seu lugar correto de spawn. Autoria própria)
Altera-se o valor de coordenada do pacote adicionado a coordenada de outro

lugar no mapa e injeta esse novo pacote no cliente pelo PROXY com o comando
“S_”, que falsifica um pacote enviado e simula ser o servidor.
(Injeção de pacote falso usando o proxy com o comando “S_” com o valor de um pacote original. Autoria própria)
Como resultado o monstro aparece no lugar que o personagem está, que é longe
de onde ele deveria estar, já que o cliente acha que isso veio do servidor.

26
(Monstro injetado no lado do cliente apenas, não tem ações. Autoria própria)
Pode-se fazer isso de forma automática ao criar um modulo para o PROXY,

quando um monstro é morto ele deixa cair um item, para pegar esse item é
necessário passar por cima dele, ou seja, ir até o local onde o monstro morreu.
Quando o servidor envia um pacote que diz onde está o item que o monstro
deixou cair, o proxy intercepta e enviar automaticamente para o servidor um
pacote de interação falsificado como se que o personagem tivesse interagido
com o objeto que ele acabou de enviar, o resultado é o item vir automaticamente
para o personagem sem necessidade de ir até o local.

27
(Item recebido automaticamente após o mostro ser morto. Autoria própria)
Essa pequena explicação é apenas da ferramenta em cima do servidor que

controla o mapa do jogo, o servidor de login possui uma criptografia TSLv1, como
este jogo é próprio para teste é possível obter acesso ao certificado digital usado
para criptografar a comunicação então é possível ver o conteúdo trafegado, caso
não existisse acesso a esse certificado, seria necessário alterar o executável do
jogo para trocar a chave que ele usa para se comunicar com o server, isso não
é um processo difícil neste caso, porque o cliente não possui nem uma proteção,
mas como o objetivo é apenas analisar a comunicação, não será feito isso.
2.2.2. Criação do servidor
Como já foi identificado a estrutura dos pacotes e já é possível falsificá-los para

interagir com o cliente, por que não recriar um servidor que se comunique com
o cliente de forma similar ao original? Com os mesmos pacotes que já foram
mapeados, uma vez que a falsificação do pacote nada mais é que uma resposta
de um suposto servidor.
Com isso foi redirecionado a conexão do PROXY para apontar o servidor

alternativo criado.

28
O servidor alternativo responde de forma simples, ele recebe os pacotes do

cliente sendo baseado no identificador do pacote recebido e responde com a
criação de um pacote do zero com os dados esperados pelo cliente.
(Pacotes esperados pelo servidor alternativo. Autoria própria)
Quando por exemplo um pacote de recarga de arma é enviado ao servidor ele

simplesmente valida a quantidade de munições que o usuário tem no inventário,
valida a quantidade de munições na arma, tira a diferença do total permitido e
envia o pacote com o total de munições atual, o tipo de munição usado e a
quantidade usada. Pronto, realmente é só isso, o servidor não é nada mais que
um programa que recebe pacotes enviados do cliente, executa alguns cálculos
e devolve um retorno.

29
(Função do servidor alternativo responsável por recarregar as armas do jogo. Autoria própria)
(Função responsável por criar o pacote de recarga que será retornado ao cliente. Autoria própria)
3. RESULTADOS, ANÁLISE E DISCUSSÃO
Claro que existem mais recursos criados para esse servidor, como banco de
dados para armazenar valores de monstros e itens obtidos, além de contas dos
jogados e personagens criados. Usando a criptografia TSLv1, o servidor de
autenticação (login) funciona da mesma maneira, reponde a pacotes enviados
pelo cliente, processa e grava no banco de dados.

30
O resultado final é um servidor parcialmente implementado, que responde

de forma similar a original, com os pacotes implementados de disparo,
monstros, movimentação, localização, troca de armas, criação de
personagem, contas entre outros. vistos na apresentação deste projeto.
(Imagens das telas de criação de conta/personagem e mapa usando servidores alternativos. Autoria própria)
(queda de itens, uso de habilidades, comandos/chat e movimentação de monstros semelhante ao servidor original.
Autoria própria)

31
Essa prova de conceito se objetiva em mostrar que é possível não só obter

vantagens no sistema como realizar a cópia completa do produto apenas ao
analisar a comunicação desprotegida assim como foi feito, todas as imagens
tiradas são da própria versão do servidor alternativo criado para esse projeto,
todo conteúdo apresentado dentro do jogo estava funcionado dentro do servidor
alternativo. Isso possibilita a distribuição irregular do produto por terceiros ou a
criação de produtos semelhantes que geram concorrência no mercado.
Analisar protocolos de rede pode não ser uma coisa simples, por mais que neste
caso não tiveram as proteções normalmente encontradas, não se pode
considerar tal facilidade ao realizar teste em um ambiente real, isso exige um
grande conhecimento por parte do pesquisador como citado por Forshaw (2017)
“Ao analisar um protocolo, você deve ter um conhecimento sólido das
tecnologias e algoritmos envolvidos para que possa detectar e até explorar
fraquezas graves.”
Sem o conhecimento necessário em um caso real não teria como prosseguir,

imagine se todas as comunicações fossem quebradas com tanta facilidade, bom,
não teríamos condições de navegar ou usar serviços e aplicativos como usamos
hoje.
4. CONSIDERAÇÕES FINAIS
O projeto foi iniciado com o intuito de demonstrar os problemas da falta de

proteção dos dados trafegados, e terminamos com o nosso objetivo cumprido
uma vez que conseguimos atingir todos os possíveis problemas citados ao longo
do artigo, ao inserir trapaças e manipulação do conteúdo mostrado ao cliente,
por fim para respondermos à pergunta tema, foi pirateado o serviço por completo,
o que mostra que sim, é possível recriar um sistema apenas ao analisar sua
comunicação.

32
O projeto se finaliza com um software desenvolvido do zero que por lei pode
ser usado sem problemas legais, por ser totalmente desenvolvido sem o
conhecimento do código original que resultaria em plágio.
Para os autores deste artigo, a proteção dos dados atualmente é

adequadamente confiável, se usada da maneira correta, as empresas e
desenvolvedores de serviços e aplicações devem entender que a
tecnologia evolui em uma velocidade muito alta, o que leva a quebra das
proteções que são atualmente eficientes, mas que não passam por
atualizações ou remodelagem.
O objetivo deste artigo mostrou que é possível por meio de engenharia

reversa analisar até os sistemas mais complexos apenas sendo questão de
tempo para os problemas de criptografia serem resolvidos.
Como parte importante para compreensão deste artigo e de outros

semelhantes, é recomendado a leitura do livro ATTACKING network
protocols do escritor James Forshaw. Todos os livros desta série são muito
bons e de fácil compreensão.
E para pesquisadores que queiram escrever ou realizar um projeto

semelhante, recomendamos a utilização de aplicativos atuais como maior
nível de proteção, para demonstrar etapas necessárias para lidar com um
ambiente real, empresarial ou governamental.
REFERÊNCIAS
James Forshaw, APPLICATION reverse engineering. In: ATTACKING network

protocols: A Hacker’s Guide to Capture, Analysis, and Exploitation. [S. l.: s. n.], 2017. cap.
6.
NETWORK PROTOCOL SECURITY. In: FORSHAW, James. ATTACKING network

protocols. [S. l.: s. n.], 2017. v. 1, cap. 7, p. 175-175.
ATAQUE dos clones: os grandes consoles brasileiros. Games, [s. l.], 30 mar. 2017.
Disponível em: https://www.redbull.com/br-pt/ataque-dos-clones-os-grandes-consoles-
brasileiros-paralelos. Acesso em: 5 maio 2023.
Efim Bushmanov. PESQUISADOR independente faz engenharia reversa do protocolo

Skype. Celular e Tecnologia, [s. l.], 6 jun. 2011. Disponível em:

33
https://extra.globo.com/noticias/celular-e-tecnologia/pesquisador-independente-faz-
engenharia-reversa-do-protocolo-skype-1967430.html. Acesso em: 5 maio 2023.
HOW to analyze IPsec Traffic with Wireshark. [S. l.], [2022]. Disponível em:
https://www.golinuxcloud.com/wireshark-analyse-ipsec-traffic/. Acesso em: 5 maio 2023.
Fabio Akita. DE 5 Tera a 25 Giga | Compressão de Dados. Produção: Fabio Makoto

Akita. [S. l.: s. n.], 2022. Disponível em: https://www.youtube.com/watch?v=j4a1SgUWh1c.
Acesso em: 8 maio 2023.
Robert Shimonski. SOBRE o Wireshark: Introdução. In: WIESHAK guia prático: Análise
e resolução de problemas de tráfego de rede. [S. l.: s. n.], 2013.
Canhota Junior, Antonio Jorge Sapage da. ENGENHARIA reversa. 2005. Artigo
(Bacharelado em Ciência da Computação) - UFF – Universidade Federal Fluminense, [S.
l.], 2005. Disponível em:
http://www2.ic.uff.br/~otton/graduacao/informaticaI/apresentacoes/eng_reversa.pdf.
Acesso em: 10 maio 2023.
PWN Adventure 3: Pwnie Island. Direção: LiveOverflow. Produção: LiveOverflow. Roteiro:

LiveOverflow. [S. l.: s. n.], 2018. Disponível em:
https://www.youtube.com/playlist?list=PLhixgUqwRTjzzBeFSHXrw9DnQtssdAwgG.
Acesso em: 29 set. 2023.

Grupo 3 - Rafael - Validacao Da Seguranca em Rede Com Engenharia Reversa

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Grupo 3 - Rafael - Validacao Da Seguranca em Rede Com Engenharia Reversa

Enviado por

Direitos autorais:

Formatos disponíveis

VALIDAÇÃO DA SEGURANÇA EM REDE COM

O artigo aborda a problemática da proteção inadequada em

Palavras-Chave: Redes. Engenharia reversa. Segurança.

Demonstration of the problem involving inadequate

Keywords: Networks. Reverse. Engineering. Security.

A comunicação de sistemas entre plataformas e dispositivos é de fundamental

Segundo James Forshaw:

Num cenário empresarial dinâmico, a engenharia reversa emerge como uma

Unip – Jundiaí – SP - 2023

1.1 QUESTÃO PROBLEMA

1.2 OBJETIVO GERAL

Investigar os impactos da engenharia reversa na segurança de sistemas de

1.3 OBJETIVO ESPECIFICO

• Analisar as práticas de engenharia reversa adotadas por empresas para apri-

• Desenvolver uma compreensão abrangente das técnicas e ferramentas uti-

• Propor estratégias eficazes para mitigar os riscos associados à engenharia

Ao definir esses objetivos, busca-se não apenas compreender os desafios

Unip – Jundiaí – SP - 2023

Pesquisa e análise das tecnologias de proxy transparente em Java, protocolos

Recriar o sistema servidor simplificado (Login e Word) na linguagem JAVA repli-

Ao final analisar os resultados obtidos e documentar todo o processo.

A relevância busca entender a necessidade em aprimorar a segurança em

Unip – Jundiaí – SP - 2023

2.1. FUNDAMENTAÇÃO TEÓRICA

Esses consoles eram incentivados pelo governo para proporcionar um

Os consoles criados no Brasil eram únicos e especiais. Cada clone bolava

O uso da engenharia reversa para analisar produtos se estende as camadas de

Como dito por Efim Bushmanov a respeito do Skype, as comunicações entre

Unip – Jundiaí – SP - 2023

2.1.1. Protocolos e segurança de rede

Uma das tecnologias usadas para criptografia ou troca de informações de forma

Seu sistema de criptografia é composto de uma combinação de criptografia

Unip – Jundiaí – SP - 2023

(Fluxo de transferência de dados TCP usando certificado digital)

Ao inspecionar o tráfego com a ferramenta de análise Wireshark, pode-se ver os

(Comunicação HTTP capturada pelo Wireshark, autoria própria)

Já em comunicações com HTTPS como protocolo, a compreensão se torna

(Comunicação HTTPS capturada pelo Wireshark, autoria própria)

Unip – Jundiaí – SP - 2023

TSLv1 e certificado digital válido da empresa distribuidora do jogo e outro apenas

Quando falamos de TSL temos três abordagens para poder analisar a

A primeira é o uso de um proxy transparente no meio da comunicação quando a

Quando usamos um proxy para interceptar esta comunicação temos o seguinte

(Fluxo de comunicação interceptada TCP por proxy transparente)

Quando o proxy no meio tem o certificado ou chave pública compatível com a

Unip – Jundiaí – SP - 2023

(Pagina original Itau 02/09/2023)

Unip – Jundiaí – SP - 2023

(Ferramenta Charles proxy versão 4.6.4, regras de alteração de conteúdo.)

Ao acessar o site com a ferramenta de proxy no meio, acontece a alteração tanto

Unip – Jundiaí – SP - 2023

Unip – Jundiaí – SP - 2023

2.1.2. Análise de tráfego de rede.

Como citado anteriormente, a análise do tráfego de rede objetiva em entender a

A ferramenta Wireshark é uma das mais usadas atualmente na área de redes,

O autor Robert Shimonski diz o seguinte em seu livro guia:

Nas imagens anteriores, ao usar a ferramenta Wireshark, foi possível visualizar

Unip – Jundiaí – SP - 2023

Mas além de criptografia existem outros recursos usados na tentativa de proteger

2.1.2.1. Ofuscação de dados

Ofuscar um código, uma mensagem ou qualquer outra coisa, nada mais é do

Abaixo um exemplo simples de um código feito em JavaScript antes de passar

Unip – Jundiaí – SP - 2023