1

Engenharia reversa de software: uma breve revisão bibliográfica sobre o tema

Software reverse engineering: a brief literature review on the topic

Fabricio Mazzola Rateiro – fabriciorateiro@hotmail.com

Fatec Taquaritinga – Taquaritinga – São Paulo – Brasil
Orientador: Prof. Ms. Felipe do Espírito Santo

RESUMO

O presente trabalho tem por objetivo apresentar a engenharia reversa de software, uma
prática existente dentro da engenharia de software para análise e compreensão de programas.
A engenharia reversa tem suas origens na análise de hardware e é frequentemente usada para
obter um projeto finalizado, visando entender como ele funciona e melhorar o produto de um
concorrente ou empresa. O presente artigo apresenta os conceitos básicos da engenharia de
software e faz uma revisão bibliográfica de seus principais termos para apresentar a técnica e
seus conceitos, além de propiciar uma introdução para pesquisas futuras relacionadas ao tema
e sua aplicabilidade no mercado de trabalho. Ao analisar como a engenharia reversa atua em
softwares para encontrar possíveis falhas e melhorar seu desempenho, constata-se que ela se
mostra uma ferramenta muito útil para a indústria e que sua utilização pode ser explorada de
forma mais detalhada nas disciplinas de engenharia das graduações na área da computação.

Palavras-chave: Engenharia reversa de software. Engenharia de software. Desenvolvimento

de software.

ABSTRACT

The present work aims to present software reverse engineering, an existing practice
within software engineering for analyzing and understanding programs. Reverse engineering
has its origins in hardware analysis and is often used to get a finished design to understand
how it works and improve a competitor's or company's product. This article presents the basic
concepts of software engineering and makes a bibliographic review of its main terms to
present the technique and its concepts, in addition to providing an introduction for future
research related to the topic and its applicability in the job market. When analyzing how
reverse engineering works in software to find possible flaws and improve its performance, it
appears that it is a very useful tool for the industry and that its use can be explored in more
detail in the engineering disciplines of undergraduate courses in computing area.

Keywords: Software reverse engineering. Software Engineering. Software development.

 2

1. INTRODUÇÃO

O atual processo de globalização torna essencial a aquisição e manutenção da

competitividade de empresas e nações, ao passo que acelera os processos de mudanças
tecnológicas. Para que tais ações logrem êxito é necessário que, de uma maneira, haja um
mecanismo que atue como aperfeiçoamento de softwares e demais componentes tecnológicos.
E um desses mecanismos é a Engenharia Reversa de Software. A engenharia reversa de
software auxilia o desenvolvedor a entender como o software funciona internamente
permitindo, a partir do produto final, estudar e aprender sua estrutura e lógica, além de
auxiliar a efetuar testes de softwares mais profundos, obter o conhecimento perdido em casos
de indisponibilidade ou perda do código-fonte, incluir e alterar funções de um software pronto
e melhorar a qualidade do software tanto na questão segurança quanto desempenho. Assim
sendo, este trabalho tem por objetivo estudar a engenharia reversa de software demonstrando,
a partir de suas técnicas de monitoramento e análise.

A engenharia reversa tem como objetivo entender como um software funciona e

melhorar o produto de um concorrente ou empresa. Normalmente, seu objetivo é entender o
sistema em um nível maior de abstração.
Segundo Dias (1996), a ER comporta uma larga diversidade de definições, devido aos
empregos e processos adotados. Não há uma definição consensual do que seja Engenharia
Reversa, mas dentre as definições variadas há duas que agem diferentemente. Uma primeira
se constitui na obtenção de informação que caracteriza e especifica o objeto da ação,
identificando seus componentes e seu padrão de inter-relacionamento, e na segunda, o objeto
é representado com um nível mais elevado de abstração. Essa prática não altera o objeto da
ação sendo um processo não destrutivo, mas de exame que não ocorre modificação do objeto.
Enquanto a engenharia convencional transforma conceitos e modelos em objetos,
produtos ou sistemas reais já existentes, a ER transforma conceitos e modelos em engenharia.
Desse modo, ela consiste em analisar estes conceitos e modelos para identificar seus
componentes e como se relacionam para criar representações diferentes do sistema ou em
mais alto nível de abstração (VARADY, 1997; ARAÚJO, 2010; CHIKOFSKY, 1990).
A engenharia reversa propicia uma importância maior no entendimento de sistemas,
através de um estudo dos processos de forma inversa, partindo de um objeto pronto. Salienta
 3

também sua importância para utilização em correção e/ou adaptação de software de terceiros,
recuperação de dados em sistemas inutilizados, como também análise de vírus, trojans e
malwares (HOGLUND, 2006).
Conforme o mercado de Software cresce, aumenta à demanda de manutenção e
criações de software mais completo, a manutenção do software torna-se um problema, uma
vez que sua documentação foi criada e associada ao software, na grande maioria não está de
acordo com seu código fonte. Diante dessas condições e da necessidade de manutenção, a
equipe de desenvolvimento encontra uma documentação incompleta não refletindo ao
software existente.
Rugaber (1996) afirma que a maior parte do esforço de desenvolvimento de software é
gasto na manutenção de sistemas existentes e não no desenvolvimento de sistemas novos.
Rugaber (1996) afirma que a maior parte do desenvolvimento de software é gasto na
manutenção e não no desenvolvimento e grande parte do processo de manutenção é dirigida
ao entendimento do software. Sendo assim, se é desejável melhorar o processo de manutenção
de software, é necessário facilitar o processo de sua compreensão. A engenharia reversa
aborda diretamente o problema de compreensão do software.

2. METODOLOGIA

O presente artigo foi elaborado mediante pesquisa bibliográfica, através de leitura de

artigos científicos, monografias, periódicos e internet. Buscou-se primar pela linguagem
objetiva, clara e embasada. O artigo foi estruturado pela introdução do tema, seguido da
motivação pelo estudo do tema, a fundamentação teórica, o tema em si, além de explanar
sobre engenharia reversa e análise de software.

3. FUNDAMENTAÇÃO TEÓRICA

De acordo com o dicionário online Significados (2022), Engenharia significa:

Engenharia é a aplicação de métodos do conhecimento científico ou

empírico destinados à utilização de recursos materiais e naturais para o
benefício do ser humano. É a área do conhecimento que aborda os conceitos
de projeção, desenvolvimento, construção, análise e manutenção de
alternativas que auxiliem e facilite a vida da sociedade nas atividades
cotidianas.
 4

Logo, Engenharia consiste também em aplicar métodos e conhecimentos sobre a

matéria-prima, de qualquer espécie, com a finalidade de elaboração de produtos mais
sofisticados (manufatura).

Figura 1. Esquema engenharia

Fonte:https://fluxoconsultoria.poli.ufrj.br/blog/engenharia-reversa-5-passos-para-replicar-sua-maquina-no-
mercado/

O conceito de engenharia reversa é o mesmo, porém logicamente, inverso. Partindo da

manufatura, esta é decomposta e detalhadamente analisada na finalidade de conhecer, decifrar e
entender seus componentes, funcionamento e organização.

Figura 1.2. Esquema engenharia reversa na informática.

 5

Fonte: https://www.beltsysplus.com.br/engenharia-reversa-de-software/

A Engenharia Reversa é a obtenção de conhecimento sobre o funcionamento e estrutura

do software a partir de sua exploração e descompilação, resultados estes expressados em forma
de código-fonte. Sobre este código-fonte, o engenheiro tem a possibilidade de criar programas
baseados no conhecimento adquirido ou modificar o programa existente, tanto para incremento

de funcionalidade quanto correção de bugs. (McGRAW, 2006).

Algumas outras razões para utilização da Engenharia Reversa são: aquisição de

conhecimento; correção de defeitos de software e produtos de terceiros. Além de outras razões,
a Engenharia Reversa normalmente é utilizada para obtenção de conhecimento, ideias e design
perdidos ou indisponíveis. Em alguns outros casos, o engenheiro pode aplicar seus
conhecimentos para edição de software de terceiros quando estes não estão dispostos a fornecer
atualizações ou o código-fonte deles (McGRAW, 2006).

3.2 Linguagem de programação

As linguagens de programação são divididas em níveis de linguagens – baixo, alto e

muito alto nível –, além de serem divididas em 05 gerações. Os termos “baixo”, “alto” e “muito
alto” nível não se referem à inferioridade ou superioridade das linguagens, mas sim ao nível de
abstração da linguagem à linguagem de máquina. (FOTOPOULOS, 2001). Conforme define
EILAM (2005), linguagens de baixo nível são aquelas que fornecem pequena ou nenhuma
abstração às instruções do processador, ou seja, linguagens próximas ao hardware. Linguagens
de alto nível são mais abstratas em comparação às linguagens de baixo nível, sendo assim, de
mais fácil uso e entendimento. Nestas, ao invés de tratarmos diretamente com registradores,
endereços de memórias e pilhas de chamadas como é feito em linguagens baixo nível, é
trabalhado com expressões, variáveis, vetores e fórmulas aritméticas. Isto facilita e acelera em
muito o processo de implementação. (EILAM, 2005).

De acordo com McGraw (2006, p. 85-89), a programação de muito alto nível possui,
assim como está definido em sua classificação, um alto nível de abstração, sendo basicamente
utilizada como uma ferramenta de produtividade. Normalmente estas linguagens são limitadas a
um propósito específico e, na maioria das vezes, são encapsuladas, internas e próprias de
softwares. Quanto às gerações das linguagens, existem:
 6

1ª geração ou 1GL: é a linguagem de máquina, baixo nível, constituída apenas de “1”

(um) e “0” (zero), dispensando o uso de compiladores.

2ª geração ou 2GL: é a linguagem Assembly. Linguagem de baixo nível “convertida”

por um simples mapeamento do código Assembly em linguagem de máquina (opcode).

3ª geração ou 3GL: linguagens de alto nível, estruturadas e projetadas para um mais fácil
entendimento e utilização. Suporta programação orientada a objetos (POO) tornando-a
extremamente mais flexível e poderosa.

4ª geração ou 4GL: estas linguagens possuem sintaxe similar à fala humana, sendo
geralmente utilizadas em banco de dados via scripts de consulta e programação. Objetivam a
redução de custo e de tempo de desenvolvimento.

5ª geração ou 5GL: ao invés de programadas por algoritmos, são linguagens baseadas na

solução de problemas através de inteligência artificial. São lançados problemas ao software que
os analisa e processa via IA.

Conforme Fotopoulos (2001), na medida em que se sobe o nível (geração) da linguagem

de programação, maior a abstração e, consequentemente, menor o número de LOC para
execução de um programa. Esta tendência faz com que, com o avanço das linguagens de
programação, cada nova linguagem tenha funções mais genéricas e operacionais, facilitando a
programação. 

3.3 Análise de Software

Existem diversas maneiras de avaliar softwares via Engenharia Reversa. Os métodos

variam de acordo com a disponibilidade de acesso ao código-fonte e ao código binário do
aplicativo, define McGraw (2006). Apesar de distintos pelas abordagens diferentes, todos os
métodos procuram entender o software examinando algumas áreas fundamentais para
localização de vulnerabilidades:

• Funções que verificam os limites suportados das variáveis (range) incorretamente ou

simplesmente não os verificam;

• Funções que passam por dados fornecidos pelo usuário ou os utilizam em uma string
de formato (format string);
 7

• Rotinas que obtém entradas de usuários utilizando loop; Operações de baixo nível de
cópia de bytes; Rotinas que utilizam aritmética de ponteiro em buffers fornecidos pelo usuário;
chamadas de sistema confiáveis que aceitam entradas dinâmicas.

Dentre os pontos comuns de verificação de vulnerabilidade, estes são os mais

frequentes, devido a maior possibilidade de exploração e por serem pontos que não recebem a
atenção devida por parte do programador ao implementá-las, já que muitos deles pressupõem
(equivocadamente) que o sistema operacional irá gerenciá-las. Os métodos empregados para
estes exames são as análises de Caixa-Branca (White Box), Caixa-Preta (Black Box) e Caixa-
Cinza (Gray Box).

3.3.1 Análise de Caixa-Branca

A análise de Caixa-Branca se refere ao estudo e compreensão do código-fonte, sendo

muito eficiente para localização de erros de programação e de implementação no software. Esta
análise pode ser auxiliada e automatizada por um analisador estático, efetuando testes de
comparação de padrões, no entanto, uma das desvantagens desse tipo de teste é o alto índice de
obtenção de falso-positivos. (McGRAW, 2006).

Muitas vezes problemas descobertos em análises Caixa-Branca podem não ser

exploráveis em um sistema real e distribuído. Outras ferramentas de segurança podem, por meio
de filtros e detecções de intrusos como Firewalls e IDS, bloquear estes ataques. Entretanto,
análises Caixa-Branca são úteis para testar como um sistema irá se comportar em distintos
ambientes e condições. Das ferramentas existentes, elas se distinguem em 02 tipos: analisadoras
de código-fonte e aquelas que automaticamente convertem o arquivo binário em código-fonte
para posterior análise. Como no segundo tipo, em casos de indisponibilidade de código-fonte,
pode ser feita a reversão do software e estudado o código-fonte obtido, ainda assim será
caracterizado como análise de Caixa-Branca.

3.3.2 Análise de Caixa-Preta

A análise de Caixa-Preta examina um programa em execução sondando-o com várias

entradas, sem a necessidade de acesso e, consequentemente, estudo do código-fonte ou código
binário do aplicativo. McGraw (2006) destaca que este tipo de análise se torna interessante
justamente por este fator, já que abre a possibilidade de exame e exploração remota do
 8

aplicativo. E, como nem sempre é possível ter acesso ao código-fonte ou binário do aplicativo,
este tipo de análise faz com que invasores reais frequentemente adotem-na.

Neste método, entradas maliciosas são fornecidas a um sistema em funcionamento no

intuito de quebrá-lo, sendo esta uma maneira de validar e avaliar problemas de negação de
serviço (DoS). Caso o programa quebre, um problema de segurança pode ter sido descoberto.
Esta análise ainda serve para determinar se uma possível área vulnerável é realmente
explorável, pois como citado anteriormente, nem sempre é possível explorar todas as
vulnerabilidades devido às proteções externas fornecidas por outros dispositivos, como
Firewalls e IDS. Apesar de muito mais fácil e de requerer menos habilidade que a análise de
Caixa Branca, a análise de Caixa-Preta, normalmente, não é tão eficiente quanto ao
reconhecimento de comportamento e funcionamento, afirma McGraw (2006).

3.3.3 Análise de Caixa Cinza

A análise de Caixa-Cinza combina técnicas de Caixa-Branca e teste de entradas de

Caixa-Preta, requerendo normalmente a utilização de diversas ferramentas em conjunto. Um
exemplo seria a execução e fornecimento de entradas de um programa-alvo diretamente dentro
de um depurador, analisando e detectando quaisquer possíveis falhas ou comportamentos
defeituosos. (McGRAW, 2006).

3.3.4 Qualidade na análise

Hoglund e McGraw (2006) consideram que um dos maiores problemas de segurança de

software é a negligência das software houses na etapa de testes. Devido às restrições de tempo e
de orçamento, a maioria das fabricantes se restringe ao teste funcional, empregando pouco
tempo para procurar e entender os riscos à segurança. Indiferente do método de análise
utilizado, maior ênfase deve ser - e ultimamente até tem sido – dada ao gerenciamento da
qualidade de software, identificando e gerenciando seus riscos desde o ponto mais inicial de seu
ciclo de vida e desenvolvimento. (HOGLUND e McGRAW, 2006).

3.3.5. Segurança de Software

Segurança de software é compreender como funciona o software, entender seus riscos e

saber como gerenciá-los. Boas práticas de segurança de software alavancam boas práticas de
engenharia de sistemas, levando esta preocupação para os níveis iniciais do ciclo de vida de
 9

software, conhecendo e entendendo problemas comuns e considerando, já nesta etapa, todas as

possíveis situações que possam implicar risco ao projeto.

Um aspecto central e crítico dos problemas referentes à segurança de software é

justamente a existência de bugs, sejam eles aplicados à segurança ou meros bugs de rotinas de
software. Defeitos de software, desde bugs de implementação (como estouros de buffer) a
falhas de projetos (como manipulações inconsistentes de erros), são comuns em qualquer tipo
de software tornando-os, na maioria das vezes, sistemas exploráveis. (McGRAW, 2006)

A alta conectividade proporcionada pela Internet também aumenta este risco. Estima-se
que o número de vulnerabilidades tende a aumentar cada vez mais. Pesquisadores e acadêmicos
de segurança afirmam que mais da metade das vulnerabilidades atuais provêm de estouros de
buffer. Porém, outros problemas mais sutis podem ser igualmente perigosos, mesmo sendo
considerados apenas meros bugs. (McGRAW, 2006)

Sobre estes dados, nota-se claramente a necessidade de mudança no modo de tratamento

do quesito segurança e na maneira de desenvolver disciplinadamente softwares.

3.3.6 Engenharia Reversa versus Cracking

O conceito de Engenharia Reversa pode ser confundido com o conceito de Cracking.

Tipicamente, a aplicação da Engenharia Reversa visa à melhoria, correção ou desenvolvimento
de aplicativos de maior qualidade e robustez. Como em qualquer técnica, existe a aplicação
ilegal ou fora-da-lei desta técnica, denominada Cracking. (SCHNEIER, 2000) Segundo
Schneier (2000), o cracking surgiu junto com a programação de softwares em si e basicamente
se resume no método de rastrear, identificar e burlar métodos de proteção e validação de
softwares comerciais, ativando-os e permitindo a execução integral de seus recursos. Programas
Shareware (distribuídos livremente, porém com restrições de recursos) requerem algum tipo de
validação, seja ela uma chave de registro ou uma senha codificada. Nestes casos, um cracker
pode ser apropriar dos métodos de Engenharia Reversa com a finalidade de burlar essas
proteções. O cracker pode estudar o software até adquirir conhecimento do software a tal nível
que se possível sobrepor, redirecionar ou nulificar as restrições e validações do software,
provendo, de maneira ilegal, acesso irrestrito a todo software mesmo sem este ser registrado ou
validado legitimamente.
 10

4. RESULTADOS

A engenharia reversa é considerada uma ferramenta eficaz para a garantia da

segurança de sistemas de alta criticidade, pois por meio de suas técnicas pode explorar o
código dos programas a fim de averiguar se há códigos maliciosos, averiguar se o código
original de um software não sofreu alterações como injeção de rotinas ocultas ou se há
códigos de desenvolvimento esquecidos pelos idealizadores. As técnicas de engenharia
reversa podem ainda ser de grande utilidade na recuperação de desastres com dados. Por
exemplo, um sistema de arquivos criptografado pode ser compreendido e sua decodificação
ser fundamental para a recuperação de dados perdidos. Nesse sentido, a Engenharia Reversa
elimina ou diminui drasticamente a necessidade de pesquisa e desenvolvimento.
A importância da reengenharia está em possibilitar que todo conhecimento agregado
ao software não seja perdido, o que aconteceria se a opção fosse pelo desenvolvimento de um
novo software. O processo de extração do conhecimento de um softwar é realizado pela
engenharia reversa, que fornece visões mais abstratas do que o código do sistema e/ou alguma
outra documentação possivelmente existente. Com essas visões é possível compreender o
software e o sistema em que está inserido, possibilitando a produção de modelos de análise
que servirão à reengenharia.
Da reengenharia de um software resulta uma nova versão, que agrega toda a
informação do software, as inovações tecnológicas e novas funcionalidades desejadas. Dessa
forma, a reengenharia de software não trata apenas de modernizá-lo, mas também adaptá-lo
de acordo com as novas necessidades do processo em que está inserido.
 11

5. CONSIDERAÇÕES FINAIS

Engenharia reversa é um termo que pode ser usado em uma vasta amplitude, tanto da
engenharia como atividades de design. Além disso, é uma estratégia comum de design na
indústria. Sua estratégia de aplicabilidade deve ser observada, a fim de verificar se é adequada
ou não sua utilização. É muito importante observar os princípios que aumentam a dificuldade
ou o investimento dos produtos de engenharia reversa, uma vez que o seu entendimento será
benéfico para todos os envolvidos em suas atividades. Existem várias razões para empregar a
engenharia reversa como uma tática de design de engenharia, tais quais: para comparar
produtos através de um benchmarking competitivo, na preparação para imitar um produto,
para obter informação técnica que não existe, para obter informação técnica que o fabricante
não mais tenha ou não deseje compartilhar, dentre outras.
Tais exemplos mostram a diversidade do uso de engenharia reversa, que pode ajudar o
desenvolvedor a produzir algo mais difícil de ser replicado ou ter suas informações extraídas
com o objetivo de obter uma vantagem comercial em cima de seus concorrentes, e, também,
usando as informações para determinar quais projetos terão sucesso.
Para isso, são identificadas as barreiras, que nada mais são que algo que impedem a
extração de informação do produto dele mesmo. Tais barreiras existem nas áreas de software,
hardware, dentre outras, e são importantes pois obrigam os competidores a gastarem tempo
desenvolvendo sua própria tecnologia ou investir em engenharia reversa com tempo e
recursos a fim de extrair informações, permitindo que o produto fique com uma fatia maior do
mercado por mais tempo. Cabe salientar que alguns produtos, devido ao seu baixo custo ou
baixa margem de lucro, não são alvo da engenharia reversa, pois seria um desperdício.
Pesquisas futuras podem partir da presente revisão para revisitar o tema e discutir a
importância dele no mercado, além de compreender como o assunto é abordado durante a
graduação e outras etapas do ensino de computação.
 12

REFERÊNCIAS

EILAM, E. Reversing: Secrets of Reverse Engineering. Indianápolis, Estados Unidos da

América: Wiley Publishing, Inc., 2005. 589p.

ESTEFANELLI, Eduardo. Engenharia Reversa: Discussão sobre validade e legalidade desta

prática. Disponível em: https://www.stefanelli.eng.br/engenharia-reversa-validade-
legalidade/. Acesso em: 10.jul.2022.

FOTOPOULOS, F. Reverse Engineering: In Computers Applications. Estados Unidos da

América: MIT Lecture Notes, 2001.119p.

HOGLUND, G.; McGRAW, G. Como quebrar códigos: A Arte de Explorar (e Proteger)

Software. São Paulo: Pearson Education do Brasil, 2006. 424p.

McGRAW, G. Software Security: Building Security In. Estados Unidos da América:

Addison-Wesley Professional, 2006. 448p.

RUGABER, S. e WILLS, L. M. Creating a Research Infrastructure for Reengineering.

In: Proceedings of Third Working Conference on Reverse Engineering, Monterey,
EUA, 1996, p. 98-102.

SIGNIFICADOS. Disponível em: https://www.significados.com.br/engenharia/. Acesso em

06.jul.2022.

SCHNEIER, B. Secrets and Lies: Digital Security in a Networked World. Estados Unidos
da América: John Wiley & Sons, 2000.

VARADY, T., MARTIN, R. R.; COXT, J. "Reverse Engineering of geometric models – an

introduction". Computer-Aided Design. v. 29, p. 255-268, 1997.