Transcrição da Apresentação do TCC – Proteção de Código Fonte via Ofuscamento
Olá, eu sou aluna do curso de Desenvolvimento de Sistemas Mainframe da ULT e esta é a apresentação do meu trabalho de conclusão de curso.
Vamos começar! Vou falar um pouquinho sobre o meu trabalho, que é sobre ofuscamento de código. Então, vou abordar um pouco sobre direito autoral, engenharia reversa, mecanismos de proteção contra engenharia reversa, as técnicas de ofuscamento de código (que é o foco do trabalho) e as conclusões que podemos tirar.
Proteção de software no Brasil
O que temos hoje para proteção de software no Brasil? Existem leis para proteger o código como obra literária. Você tem o direito de autor assegurado por lei: quem fez o programa tem o direito autoral sobre aquela obra que produziu.
Você também pode proteger programas juridicamente por meio de patentes. É possível patentear um programa de computador, gerando um pedido de patente no INPI. Após todo o trâmite, se aceito, seu software se torna patenteado. Esses dois sistemas de proteção (direito autoral e patente) funcionam no Brasil e resolvem disputas sobre cópias não autorizadas e execuções de código sem autorização do desenvolvedor.
O que cada proteção abrange
O direito autoral assegura proteção para telas, interfaces, estruturas do programa, código fonte e elementos literais. Compara-se o código-fonte para identificar cópias. Já a patente pode proteger fluxogramas inéditos, arquivos de banco de dados, algoritmos novos, funcionalidades específicas e inéditas. Se você criar um algoritmo novo e o patentear, ninguém pode usar sem sua autorização.
Tanto pelo direito autoral quanto pela patente, é possível fazer contratos para cessão de direitos ou pagamento de royalties.
Outras formas de proteção
Mesmo com registro de patente e direito autoral, a proteção não é absoluta. Se alguém copiar seu programa, você pode provar a autoria, mas o processo é burocrático e caro.
Outro caminho para proteger programas é dificultar a cópia através da engenharia reversa. A engenharia reversa tenta entender como um programa funciona a partir do executável, reproduzindo o código-fonte original ou funcionalidades similares. É uma técnica controversa, pois alguém pode se apropriar do trabalho de desenvolvimento sem permissão.
Engenharia reversa: quando é usada
A engenharia reversa pode ser útil se você perdeu o código-fonte original, mas ainda tem a aplicação. Em alguns casos, é justificável, mas na maioria das vezes é usada para obter código sem permissão do proprietário.
Mecanismos de proteção via software
Além da proteção jurídica, existe a proteção via software, que é dificultar a engenharia reversa. Uma das técnicas mais utilizadas é o ofuscamento de código, muito comum na internet e em linguagens como JavaScript. O objetivo é dificultar o entendimento do programa, tornando a engenharia reversa mais trabalhosa.
Técnicas de ofuscamento de código
- Remover comentários e informações redundantes: Deixa o código mais enxuto e difícil de entender.
- Renomear variáveis: Trocar nomes significativos por nomes aleatórios, dificultando a leitura.
- Reordenar o código-fonte: Fazer saltos no fluxo do programa para embaralhar a lógica.
- Trocar comandos e estruturas por equivalentes: Substituir comandos simples por outros mais complexos ou equivalentes.
- Inserir código redundante: Adicionar trechos que não fazem nada, confundindo quem lê o código.
Essas técnicas são especialmente úteis em programas legados, como os escritos em COBOL para mainframe.
Exemplo prático: programa de tabuada
No trabalho, foi criado um programa de tabuada em COBOL. O código original é claro, bem comentado e fácil de entender. Após aplicar as técnicas de ofuscamento, o código ficou com variáveis sem significado, comandos reordenados e trechos embaralhados, mas o resultado da execução é idêntico ao original. Para o usuário, não há diferença, mas para quem tenta entender o código, fica muito mais difícil.
Conclusão
Não existe método 100% seguro para ofuscamento de código. As técnicas dificultam o entendimento e a engenharia reversa, mas não garantem proteção total. O custo-benefício deve ser avaliado: quanto mais rebuscado o código, mais difícil de entender, mas também mais difícil de manter. O ofuscamento é uma técnica interessante, fácil de aplicar e que pode proteger bem o código-fonte contra cópias e engenharia reversa.
Transcrição adaptada e formatada a partir do vídeo de apresentação do TCC sobre ofuscamento de código.
WALTER
RAMOS
NETO
PROTEÇÃO
DE
CÓDIGO
FONTE
VIA
OFUSCAMENTO
UNIÃO
LATINO
AMERICANA
DE
TECNOLOGIA
JAGUARIAÍVA,
2016
WALTER
RAMOS
NETO
PROTEÇÃO
DE
CÓDIGO
FONTE
VIA
OFUSCAMENTO
Monografia
apresentada
à
Banca
Examinadora
do
Curso
de
Pós-Graduação
Desenvolvimento
de
Sistemas
Mainframe
da
ULT
como
exigência
para
sua
conclusão,
sob
a
orientação
da
Professora
Maristela
Regina
Weinfurter
Teixeira.
UNIÃO
LATINO
AMERICANA
DE
TECNOLOGIA
JAGUARIAÍVA,
2016
BANCA
EXAMINADORA
Jaguariaíva,
____
de____________
de
2016
Dedicatória
Ao
meu
filho,
Vinicius
e
minha
companheira
de
longa
data,
Juliana.
Amo
vocês.
Agradecimentos
A
todos
profissionais
envolvidos
na
elaboração,
manutenção,
controle
e
logística
do
curso
de
especialização
em
Desenvolvimento
de
Sistemas
Mainframe
da
ULT.
Ao
Acir
Mandello
Junior
por
sua
ajuda
imprescindível
nos
momentos
de
problemas
e
inconsistências
no
sistema.
Ao
Juscelino
Niano
Lindolm
por
todo
apoio
administrativo
ao
longo
do
curso.
A
professora
Maristela
Regina
Weinfurter
Teixeira
agradeço
a
ajuda
na
elaboração
desse
trabalho
e
paciência
ao
longo
de
todo
o
curso.
A
todos
que,
de
uma
forma
ou
de
outra,
colaboraram
para
a
realização
e
finalização
deste
trabalho.
where
COBOL
maintenance
programming
is
considered
a
pleasant
alternative
to
growing
rice
or
raising
pigs."
-Edward
Yourdon
Resumo
No
desenvolvimento
de
software,
principalmente
em
aplicações
da
era
da
internet,
o
ofuscamento
de
código
é
algo
importante
devido
ao
resguardo
da
proteção
intelectual,
mesmo
assim
o
assunto
é
pouco
conhecido
e
estudado
nas
universidades
pobre
em
referências
acadêmicas.
A
legislação
em
vigor
no
país
não
fornece
um
nível
de
proteção
adequado
para
que
o
desenvolvedor
de
um
software
se
sinta
seguro
contra
cópias
ilegais,
modificações,
usos
não
autorizados
do
conteúdo
de
seu
programa
e
a
pirataria,
como
proteção
adicional
pode-se
utilizar
técnicas
de
ofuscamento
de
código.
Neste
trabalho
foram
apresentadas
técnicas
com
o
objetivo
de
proteger
o
software
contra
engenharia
reversa,
oferecendo
ao
desenvolvedor
resguardo
dos
danos
que
não
são
contemplados
nas
leis
de
software
em
vigor,
através
da
transformação
do
programa
original
em
ofuscado.
Muitos
sistemas
versam
sobre
ou
se
relacionarem
com
sistemas
legados,
especialmente
em
mainframes;
tais
sistemas
não
possuem
documentação
suficiente
ou
até
mesmo
inexistente.
Os
conceitos,
exemplos
e
partes
de
código
ilustram
as
desvantagens
e
as
vantagens
do
uso
de
cada
técnica
de
proteção
frente
a
tentativas
de
entendimento
de
programas
através
do
uso
da
engenharia
reversa.
Esse
trabalho
acabou
sendo
também
uma
referência
para
que
futuras
gerações
não
repitam
os
erros
do
passado
e
que
possam
conscientemente
proteger
seu
código
quando
necessário
ou
mesmo
auxiliar
no
entendimento
de
algum
programa
que
acabou
sendo
ofuscado
ao
longo
dos
anos
sem
que
essa
tenha
sido
a
intenção.
Palavras-chave:
Ofuscamento;
código
fonte;
mainframe;
engenharia
reversa;
prote
ção;
patente;
direitos
autorais;
COBOL;
código
redundante.
Abstract
In
software
development,
especially
in
the
era
of
internet
applications,
code
obfuscation
is
usual
its
use
in
Java
programs
a
market
practice,
yet
it
is
little
known
and
studied
in
universities
lacking
academic
references.
In
mainframe
environment,
the
source
code
is
accidentally
obfuscated
and
is
very
well
used
in
COBOL
programs
of
legacy
systems.
The
law
does
not
provide
an
adequate
level
of
protection
for
developer
feel
secure
against
copying,
modification
and
unauthorized
use
of
the
content
of
their
program,
the
use
of
obfuscation
techniques
provides
a
complementary
additional
protection.
In
this
work
were
presented
techniques
to
protect
software
against
reverse
engineering,
providing
additional
layer
of
protection
against
damages
that
are
not
covered
by
software
laws,
by
transforming
the
original
program
in
obfuscated
program.
Many
systems
deal
with
or
relate
to
legacy
systems,
especially
in
mainframes;
such
systems
do
not
have
sufficient
documentation
or
are
nonexistent,
the
source
code
is
not
commented,
their
complex
structures,
there
are
portions
that
are
no
longer
executed,
finally,
some
programs
are
almost
unintelligible.
In
many
source
codes
existing
today
on
mainframes
can
be
said
that
the
source
code
is
obfuscated
because
they
present
characteristic
elements
of
protection
techniques
used
in
obfuscation.
The
concepts,
examples
and
code
portions
illustrate
the
disadvantages
and
advantages
of
using
each
protection
technique
against
the
attempts
of
reverse
engineering.
This
work
can
be
used
as
a
reference
so
that
future
generations
do
not
repeat
past
mistakes
and
can
consciously
protect
your
code
when
necessary
or
even
help
to
understand
some
program
that
was
eventually
obfuscated
over
the
years
without
being
the
intention.
Key
Words:
Obfuscating;
source
code;
mainframe;
reverse
engineering;
protection;
patent;
copyright;
COBOL;
redundant
code.
Lista
de
ilustrações
Figura
-Processo
de
Engenharia
Progressiva
x
Engenharia
Reversa
Figura
Figura
-Trecho
de
código
fonte
com
dead
code
Figura
-Trecho
de
código
fonte
original
Figura
-Programa
HelloWorld
em
COBOL
Apêndice
A
Figura
-Programa
HelloWorld
em
COBOL
ofuscado
Apêndice
B
Figura
-Execução
do
programa
TABUADA
Lista
de
tabelas
Tabela
1
-Patente
x
Direito
autoral
Lista
de
abreviaturas
AMD
Advanced
Micro
Devices
CEE
Comunidade
Econômica
Europeia
COBOL
COmmon
Business
Oriented
Language
ER
Engenharia
Reversa
IBM
Internacional
Business
Machines
INPI
Instituto
Nacional
da
Propriedade
Industrial
OMPI
Organização
Mundial
da
Propriedade
Intelectual
TRIPS
Trade-Related
Aspects
of
Intellectual
Property
Rights
WWW
World
Wide
Web
Sumário
PROTEÇÃO
DE
CÓDIGO
FONTE
VIA
OFUSCAMENTO....................................................................
1
PROTEÇÃO
DE
CÓDIGO
FONTE
VIA
OFUSCAMENTO....................................................................
2
Dedicatória
.............................................................................................................................................
4
Agradecimentos
....................................................................................................................................
5
Epigrafe
..................................................................................................................................................
6
Resumo
..................................................................................................................................................
7
Abstract
..................................................................................................................................................
8
Lista
de
ilustrações...............................................................................................................................
9
Lista
de
tabelas....................................................................................................................................
10
Lista
de
abreviaturas
..........................................................................................................................
11
Introdução
............................................................................................................................................
13
Capítulo
1
-Direito
autoral
e
Ofuscamento
em
programas
de
computador
.................................
15
1.1.
Direitos
autorais
e
programas
de
computador
......................................................................
15
1.2.
A
Origem
do
Ofuscamento
de
código
de
Programas
de
Computador
.................................
18
Capítulo
2
Engenharia
Reversa
......................................................................................................
20
2.1.
As
Origens
da
Engenharia
Reversa.....................................................................................
20
2.2.
É
correto
utilizar
a
engenharia
reversa
?
..............................................................................
23
2.3.
Questões
Econômicas
da
Engenharia
Reversa
...................................................................
25
Capítulo
3
Mecanismos
de
Proteção..............................................................................................
27
3.1.
Mecanismos
de
Proteção
Jurídica
........................................................................................
27
3.2.
Mecanismos
de
Proteção
via
Software
.................................................................................
28
Capítulo
4
-Técnicas
de
ofuscamento..............................................................................................
31
4.1.
Auto
documentação...............................................................................................................
33
4.2.
Minificação
de
código
............................................................................................................
35
4.3.
Minificação
e
ofuscamento....................................................................................................
37
4.4.
Compilação
e
link
edição
......................................................................................................
39
4.5.
Código
redundante
................................................................................................................
40
4.6.
Geração
de
dumb
code.........................................................................................................
43
4.7.
Revisão
de
código
e
padronização
.......................................................................................
44
Conclusão
............................................................................................................................................
46
REFERÊNCIAS.....................................................................................................................................
48
ANEXO
A
FOLHETO
DE
DIVULGAÇÃO
SOFTWARE
DE
OFUSCAMENTO
................................
53
APÊNDICE
A
-CÓDIGO
FONTE
PROGRAMA
COBOL
HELLO
SEM
OFUSCAMENTO.................
57
APÊNDICE
B
-CÓDIGO
FONTE
PROGRAMA
COBOL
HELLO
OFUSCADO
.................................
58
APÊNDICE
C
-CÓDIGO
FONTE
PROGRAMA
TABUADA
SEM
OFUSCAMENTO
.........................
59
APÊNDICE
D
-CÓDIGO
FONTE
PROGRAMA
TABUADA
OFUSCADO..........................................
62
APÊNDICE
E
EXECUÇÃO
DO
PROGRAMA
TABUADA
................................................................
63
Introdução
A
proteção
de
código
fonte
vem
sendo
uma
grande
preocupação
das
corporações
ao
longo
das
últimas
décadas
por
inúmeros
fatores
que
serão
expostos
ao
longo
desse
trabalho,
uma
das
maneiras
existentes
para
tal
processo
é
o
ofuscamento.
Segundo
AURÉLIO
2001,
ofuscar
tem
o
significado
de
ocultar,
encobrir,
impedir
de
ver
ou
de
ser
visto,
turvar,
tornar
menos
claro
ou
menos
perceptível,
empanar,
fazer
diminuir
a
intensidade,
toldar,
turvar
a
vista,
perder
o
brilho.
Observa-se
que
o
objetivo
principal
do
ofuscamento
é
o
de
dificultar
a
visualização
de
algo,
assim
sendo,
a
técnica
que
será
apresentada
nesse
trabalho
visa
proteger
os
códigos
fontes
de
programas
através
da
implantação
de
elementos
que
turvem
a
leitura
do
código.
Uma
das
formas
de
proteção
existente
é
a
proteção
de
software
através
do
depósito
de
patente
e
registro
de
programas
junto
aos
órgãos
competentes,
no
caso
do
Brasil
o
INPI
-Instituto
Nacional
da
Propriedade
Industrial,
essa
caracteriza
abordagem
jurídica
para
a
proteção
a
outra
forma
é
através
de
alterações
no
código
fonte
do
programa.
No
capítulo
I
serão
abordados
temas
relacionados
ao
direito
autoral
aplicado
a
códigos
fonte
de
programas
de
computador
suas
implicações
e
consequências.
Além
do
direito
do
autor
será
apresentada
uma
abordagem
que
visa
proteger
tais
programas
através
de
técnicas
computacionais
conhecidas
como
ofuscamento
de
código.
O
capítulo
II
traz
uma
discussão
sobre
a
origem
da
engenharia
reversa,
realiza
uma
análise
sobre
ser
correto
ou
não
o
uso
de
tal
abordagem
sob
o
ponto
de
vista
jurídico,
suas
implicações
e
como
ela
é
vista
pelas
leis
brasileiras
e
pela
comunidade
internacional,
aborda
também
as
questões
econômicas
associadas
ao
uso
da
engenharia
reversa.
Já
no
capítulo
III
são
apresentados
os
mecanismos
de
proteção
de
programas
de
computador.
São
discutidas
as
bases
para
a
proteção
de
programas
de
compu
tador
através
de
modificações
no
código
fonte
e
retoma-se
a
discussão
sobre
o
direito
autoral,
mas
agora
com
um
viés
de
proteção
diferente
do
capítulo
I
que
apresentava
a
legislação
vigente.
No
capítulo
IV
são
abordadas
diversas
técnicas
de
ofuscamento
de
código
segundo
uma
sequência
de
mais
fácil
entendimento
iniciando-se
pela
auto
documentação,
seguida
pela
minificação
de
código,
uma
abordagem
um
pouco
mais
complexa
e
necessária
é
o
processo
de
compilação
e
link
edição,
são
apresentadas
para
finalizar
o
capítulo
e
as
técnicas
de
ofuscamento
conhecido
o
código
redundante
e
a
geração
de
dumb
code
ambas
de
alta
complexidade
e
difícil
entendimento
e
aplicação.
Para
finalizar
o
capítulo
apresenta-se
a
revisão
de
código
fonte.
Na
conclusão
são
considerados
todos
os
aspectos
levantados
ao
longo
do
texto
e
são
apresentadas
as
conclusões
sobre
o
ofuscamento
de
código
que
podem
ser
obtidas
desse
trabalho.
Capítulo
1
-Direito
autoral
e
Ofuscamento
em
programas
de
computador
1.1.
Direitos
autorais
e
programas
de
computador
O
software
tornou-se
um
bem
no
início
da
década
de
70
(Pereira
dos
Santos,
1997).
Desde
então
iniciou-se
uma
série
de
medidas
internacionais
para
protegê-lo.
No
Brasil
apenas
em
1987
foi
promulgada
a
lei
do
software
que
protege
o
direito
do
autor
de
programas
de
computador.
Em
1990
a
União
Europeia
através
da
Diretiva
91/250/CEE
definiu
um
padrão
mínimo
de
proteção,
complementados
pelos
acordos
TRIPS
(Acordo
sobre
os
Aspectos
dos
Direitos
de
Propriedade
Intelectual
Relacionados
ao
Comércio)
de
1994
e
Tratado
de
direito
de
autor
da
OMPI
de
1996.
Em
2000
os
tratados
internacionais
sobre
o
tema
passaram
a
diferenciar
a
tecnologia
empregada
como
um
adicional
a
ser
protegido,
visto
que
a
funcionalidade
de
um
programa
não
é
objeto
de
proteção
através
do
direito
autoral
e
sim
através
de
patentes.
(Pereira
dos
Santos,
1997).
O
código
fonte
em
tese
não
circula,
pois
é
no
código
fonte
que
contém
o
trabalho
intelectual
e
a
tecnologia
do
programa
de
computador.
O
que
se
tem
é
a
patente
de
invenção
implementada
pelo
programa
de
computador,
o
código
não
é
protegido
por
patente
e
sim
por
direito
autoral,
porém
é
algo
extremamente
complicado
defender
que
um
programa
não
foi
copiado
de
outro
ou
qual
foi
produzido
primeiro.
Em
vista
disso
a
utilização
de
técnicas
computacionais
auxilia
o
direito
no
que
diz
respeito
à
cópia
indevida,
pois
se
o
código
fonte
for
ininteligível,
possuir
marcas
únicas
e
características
(marca
)
fica
facilitado
o
processo
de
garantia
de
propriedade
intelectual.
Pode-se
patentear
a
solução
técnica
que
o
software
implementa,
não
suas
funcionalidades,
afinal
a
solução
é
uma
invenção
e
uma
forma
de
corrigir
algum
problema,
entretanto
o
código
e
os
melhoramentos
não
podem
ser
patenteados
sendo
protegidos
apenas
por
direito
de
autor
o
qual
apresenta
dificuldades
em
sua
defesa
isto
porque
as
leis
vigentes
segregaram
o
direito
do
autor
e
a
propriedade
intelectual
conforme
ilustra
a
tabela
1.
Direito
do
autor
Propriedade
Intelectual
(patente)
Interfaces/Telas
Fluxograma
Estrutura
Formato
de
arquivos
e
banco
de
dados
Código
Fonte
Algoritmo
Elementos
Literais
Funcionalidade
Tabela
1
-Patente
x
Direito
autoral
Com
a
proteção
pelo
sistema
de
patente,
protege-se
o
objeto
com
a
funcionalidade
que
o
programa
introduziu.
Para
tanto,
o
software
deve
preencher
as
condições
necessárias
para
solicitação
do
patenteamento,
que
são:
resolução
de
um
problema
técnico
encontrado
no
estado
da
técnica,
resultar
em
aplicação
prática
e
ter
efeito
técnico
novo.
(Lei
nº10.196,
2001)
No
Brasil
temos
uma
sistemática
bem
específica
sobre
a
proteção
autoral.
Em
1987
a
lei
7646
apresentava
duas
partes
distintas,
o
regime
de
proteção
e
a
comercialização,
ela
reservava
mercado
para
produtos
e
empresas
nacionais
desde
que
existisse
a
tecnologia
e
empresas
no
Brasil
que
suprissem
as
necessidades.
O
mainframe
podia
ser
vendido
pela
IBM
pois
não
existia
nem
a
tecnologia
nem
empresas
que
o
fabricassem.
Já
em
1998
com
a
promulgação
da
lei
9609
foram
estabelecidos
o
tratamento
igualitário
para
produto
estrangeiro
e
nacional
e
o
fim
da
reserva
de
mercado.
Previu-se
também
o
programa
de
computador
como
obra
intelectual
protegida.
Atualmente
o
regime
básico
do
programa
de
computador
é
o
da
lei
especial,
com
a
aplicação
subsidiária
da
legislação
do
direito
de
autor
podendo
dessa
forma,
o
autor,
reivindicar
a
paternidade
do
programa
de
computador
e
o
de
opor-se
a
alterações
não
autorizadas
quando
impliquem
deformação,
mutilação
ou
outra
modificação
em
seu
programa
(Pereira
dos
Santos,
1997).
O
prazo
para
a
proteção
é
de
50
anos
e
em
termos
jurídicos
a
lógica
central
do
programa
é
de
domínio
público.
Os
direitos
sobre
os
programas
de
computador
são
regidos
pela
lei
7646/87
que
basicamente
diz
que
salvo
disposição
em
contrário,
o
empregador
ou
contratante
do
serviço
é
dona
dos
direitos
desse
programa.
As
boas
práticas
do
mercado
reforçam
essa
prerrogativa
nos
contratos
de
trabalho
e
prestação
de
serviço,
sendo
recomendável
a
entrega
do
código
fonte,
que
é
a
tecnologia
propriamente
dita.
(Murta,1998)
Como
diversos
programas
podem
realizar
a
mesma
função
e
possuírem
códigos
fontes
distintos
o
direito
do
autor
que
é
baseado
em
elementos
literais
deixa
de
proteger
esse
software
uma
vez
que
apenas
o
código
fonte
(estrutura
geral,
telas
e
interfaces
de
usuários)
e
o
código
objeto
(carga
ou
executável)
são
protegidos
pelo
direito
autoral.
Uma
alteração
um
pouco
rebuscada
no
código
fonte
original
já
faz
com
que
um
perito
não
consiga
classificar
o
novo
código
fonte
(ou
objeto)
como
uma
cópia
do
original.
A
proteção
apenas
pelo
direito
autoral
contra
cópia,
plágio,
aproximação,
aproveitamento,
clonagem,
reutilização
é
insuficiente
pois
a
confirmação
dessas
práticas
é
extremamente
complexa
e
por
vezes
não
pode
ser
afirmada
com
precisão,
embora
seja
uma
cópia
se
não
for
descarada
não
é
um
processo
simples.
É
indicado
o
uso
de
patente
para
complementar
a
proteção
do
código
protegendo
assim
o
algoritmo
utilizado,
a
funcionalidade,
o
fluxograma,
parâmetros,
estrutura
de
dados
e
arquivos.
(Dragoni,
2014)
Dois
ou
mais
programas
podem
ser
semelhantes
em
dadas
situações
e
totalmente
diferentes
em
outras
embora
possam
possuir
funcionalidades
equivalentes
a
comprovação
da
cópia
é
extremamente
trabalhosa.
Muitas
vezes
a
semelhança
de
funcionalidade
gera
a
semelhança
na
forma
de
expressão,
seja
por
causa
da
observância
de
conceitos
normativos
e
técnicos
ou
mesmo
pelas
características
funcionais
da
aplicação,
por
vezes
a
implementação
de
determinado
algoritmo
só
pode
ser
feito
de
uma
forma
e
se
ambos
programas
o
utilizarem
eles
serão
iguais,
e
mesmo
assim
não
serão
cópias.
Para
casos
de
plágio,
segundo
as
leis
vigentes,
não
é
violação
de
direito
de
autor
quando
ocorrer
semelhança
entre
programas
que
se
derem
por
força
das
ca
racterísticas
funcionais
de
sua
aplicação,
da
observância
de
preceitos
normativos
e
técnicos,
ou
de
limitação
de
forma
alternativa
para
sua
expressão.
(Art.
6,
III,
Lei
9609/98,
previsão
idêntica
ao
art.
7,
III,
da
lei
7646/87)
Em
síntese,
o
sistema
do
Direito
Autoral
é
muito
bom
para
cópia
servil,
mas
quando
se
trata
de
proteger
tecnologia
e
evitar
o
plágio
não
é
o
melhor
sistema.
1.2.
A
Origem
do
Ofuscamento
de
código
de
Programas
de
Computador
Devido
à
maneira
como
foi
concebida
a
tecnologia
utilizada
na
World
Wide
Web,
leia-se
internet,
não
há
como
proibir
o
acesso
a
determinados
códigos
fontes,
como
os
javascripts
por
exemplo.
A
saída
encontrada
pelos
profissionais
de
TI
foi
fazer
códigos
nos
quais
mesmo
o
usuário
tendo
acesso
a
ele
não
consiga
entender
o
que
ele
faz.
Uma
sacada
sensacional
que
recebeu
o
nome
de
ofuscamento,
essa
técnica
é
uma
das
formas
mais
fáceis
e
baratas
para
proteger
um
software
contra
engenharia
reversa.
(Collberg
et
al,
2002)
A
técnica
do
ofuscamento
tem
como
objetivo
principal
tornar
códigos
ininteligíveis,
mesmo
quando
não
esse
objetivo
não
é
atingido,
a
sua
simples
utilização
produz
um
considerável
aumento
na
dificuldade
de
leitura
do
código.
O
processo
é
simples
em
seu
conceito
e
sua
utilização
é
justificada
pela
preservação
da
propriedade
intelectual
do
desenvolvedor
do
software.
(Somekawa,
2012)
Simples
transformações
de
layout
são
suficientes
para
dificultar
a
compreensão
de
um
código,
tais
alterações
associadas
com
transformações
no
fluxo
do
processamento,
inclusão
de
variáveis
sem
sentido
e
definições
não
usuais
completam
o
ferramental
básico
para
dificultar
a
análise
e
entendimento
de
um
código
fonte.
(Collberg
et
al,
1997)
De
carona
no
ofuscamento
veio
uma
prática
que
há
muito
já
é
de
conhecimento
do
programador
COBOL
que
não
segue
muito
os
padrões
de
sua
firma
e
prefere
a
velocidade
no
desenvolvimento
do
código
em
detrimento
a
clareza
para
o
entendimento
das
futuras
gerações.
Ofuscação
de
código
tem
sido
utilizado
majoritariamente
em
3
grandes
áreas,
na
manutenção
evolutiva
de
sistemas
na
qual
a
nova
versão
do
programa
tenha
recebido
apenas
alguns
ajustes
ou
uma
nova
funcionalidade
o
código
fonte
é
totalmente
diferente,
na
integridade
do
programa
visto
que
o
código
fonte
sendo
de
difícil
compreensão
sua
modificação
é
muito
mais
complicada
e
para
a
proteção
de
direitos
como
no
caso
dos
algoritmos.
(Cohen,
1993)
As
técnicas
de
ofuscação
abordadas
nesse
trabalho
são
classificadas
como
estáticas,
isto
é,
após
o
código
ter
sido
ofuscado
ele
não
mais
sofrerá
alterações.
Existem
as
dinâmicas
que
fogem
ao
escopo
desse
trabalho
nas
quais
alterações
continuam
a
ocorrer
no
programa
(geradas
e
mantidas
por
ele
mesmo)
em
seu
próprio
funcionamento
muito
utilizado
em
vírus
de
computador
(VírusBrasil,
2016).
Nesse
capítulo
foi
apresentado
um
estudo
sobre
a
legislação
brasileira
e
sobre
tratados
internacionais
que
apresentam
como
tema
a
proteção
de
programas
de
computador,
desde
o
programa
pronto
até
seu
código
fonte
que
é
o
artefato/insumo
para
a
produção
de
todo
e
qualquer
software.
As
diferenças
básicas
entre
o
que
pode
ser
e
é
protegido
por
lei
de
autor
e
por
patente
é
apresentada
na
tabela
1
e
discutida
ao
longo
do
texto.
Da
análise
da
legislação
e
do
programa
de
patentes
verifica-se
que
os
meios
jurídicos
não
fornecem
a
proteção
necessária
para
uma
completa
blindagem
dos
softwares
sendo
necessária
a
aplicação
de
uma
camada
extra
de
segurança
nos
programas
que
é
fornecida
através
do
ofuscamento
de
código.
Capítulo
2
Engenharia
Reversa
2.1.
As
Origens
da
Engenharia
Reversa
A
expressão
é
originária
do
direito
norte-americano
de
conhecida
na
indústria
de
hardware,
bélica,
automação
e
de
semicondutores.
Por
que
utilizar
engenharia
reversa
de
software?
O
programa
é
comercializado
em
código
objeto.
O
registro
de
programas
resguarda
o
sigilo
do
código
fonte.
O
código
fonte
é
tratado
como
segredo
empresarial.
A
utilização
da
engenharia
reversa
é
indicada
em
algumas
situações:
Quando
se
possui
o
código
fonte
do
sistema,
mas
não
existe
sua
documentação.
Existência
de
código
duplicado.
Dificuldade
de
manutenção
do
sistema.
Erros
gerando
outros
erros.
Processos
que
possuem
comportamento
desconhecido
e
imprevisível.
Os
objetivos
principais
da
engenharia
reversa
são:
Interoperabilidade
Clonagem
Suporte
técnico
Em
relação
a
interoperabilidade
a
engenharia
reversa
objetiva
o
desenvolvimento
de
interfaces
lógicas
(compatibilidade
entre
programas),
por
sua
vez
a
clonagem
objetiva
apenas
cópia
das
funcionalidades
do
programa,
por
vezes
estendendo-
se
até
mesmo
a
interfaces
de
uso
do
usuário,
finalizando
o
suporte
técnico
é
uma
vertente
que
visa
a
correção
de
erros,
introdução
de
modificações
e
desenvolvimen
to
de
adaptações,
sendo
por
vezes
autorizado
e
dessa
maneira,
lícito
do
ponto
de
vida
jurídico.
(Fetrim,
1999)
A
engenharia
reversa
pode
gerar
diferentes
níveis
de
abstração,
sendo
que
cada
nível
requer
uma
determinada
quantidade
de
esforço
por
parte
do
investigador.
Quanto
maior
o
nível
de
abstração
melhor
a
compreensão
e
facilidade
do
entendimento
do
funcionamento
do
programa.
O
processo
de
análise
e
compreensão
de
um
programa
já
existente
e
funcional
com
o
objetivo
de
entender
o
seu
funcionamento
é
o
que
melhor
define
a
engenharia
reversa.
(Fetrim,
1999)
A
obtenção
dos
elementos
do
código
fonte
de
um
programa
de
computador
a
partir
do
seu
código
objeto
é
um
dos
objetivos
preconizados
pela
engenharia
reversa.
Os
passos
para
obtenção
do
código
fonte
são:
(a)
Análise
do
funcionamento
do
programa
(black
box
analysis
em
inglês),
e
(b)
Descompilação
ou
desassemblagem
que
é
o
processo
inverso
ao
da
com-
Compilar
é
transformar
o
código
fonte
em
objeto,
o
processo
inverso
chama-
se
descompilação
que
é
o
ato
de
converter
um
arquivo
inteligível
apenas
para
os
computadores
em
um
código
fonte
que
pode
ser
interpretada
por
detentores
de
co
nhecimento
de
determinada
linguagem
de
computação.
A
engenharia
reversa
e
código
a
partir
do
programa
compilado
em
seu
objeto
que
é
o
entendimento
do
programa.
(Boccardo,
2010)
que
é
a
visualização
do
ecuperação
d
2.1.
A
abstração
como
ato
transformador
Atos
destinados
a
obter,
a
partir
de
um
produto
acabado,
o
código
fonte
que
deu
origem
ao
programa
é
um
processo
extremamente
trabalhoso
que
envolve
quase
que
todas
as
áreas
do
conhecimento
relacionadas
ao
desenvolvimento
de
softwares.
Entretanto
nenhuma
disciplina
versa
sobre
a
abstração,
que
é
a
habilidade
primordial
para
que
esse
tipo
de
processo
logre
êxito.
A
abstração
apresenta
diversos
níveis
sendo
que
cada
passo
no
processo
de
desenvolvimento
de
software
seria
um
refinamento
do
nível
anterior
contendo
um
maior
detalhamento
das
funções
que
serão
realizadas
por
esse
nível.
(Lynn,
2004)
Informações
numa
forma
mais
global
possuem
alto
grau
de
abstração
sendo
que
seu
extremo
oposto
seria
a
forma
mais
detalhada
que
apresenta
baixo
grau
de
abstração.
Nos
passos
ou
estágios
iniciais
do
ciclo
de
vida
de
um
software
as
informações
possuem
alto
nível
de
abstração
e
nos
estágios
finais
baixo
nível
de
abstração
Figura
1
-Processo
de
Engenharia
Progressiva
x
Engenharia
Reversa1
A
engenharia
progressiva
é
o
processo
tradicional
de
desenvolvimento
de
um
software
é
regida
pela
disciplina
de
engenharia
de
software
e
é
caracteriza-se
por
desenvolvimento
em
cascata
no
qual
partindo
de
um
nível
de
abstração
alto
chega-
se
a
um
nível
baixo.
Em
contrapartida
a
engenharia
progressiva
temos
a
engenharia
reversa
que
partem
de
um
baixo
nível
de
abstração
para
um
alto
nível
e
tem
como
objetivo
a
descoberta
de
como
um
programa
foi
feito
e
de
como
ele
funciona.
Extraido
de:
Valéria
Delisandra
Fetrim,
Apoio
à
Documentação
de
Engenharia
Reversa
de
Software
por
Meio
de
Hipertextos,
Dissertação
de
Mestrado,
USP-São
Carlos,
1999,
p.
9.
2.2.
É
correto
utilizar
a
engenharia
reversa?
Duas
correntes
em
1980
surgiram
para
estudar
a
lógica
de
um
programa.
Uma
delas
defendia
que
a
engenharia
reversa
deveria
ser
livre
e
praticada
sem
qualquer
tipo
de
intervenção
ou
de
regras.
A
outra
corrente
por
sua
vez
afirmava
que
o
estudo
de
um
programa
através
da
engenharia
reversa
não
devia
ser
permitido.
(Pereira
dos
Santos,
1997).
Menos
de
uma
década
depois
do
início
dos
debates
sobre
a
possibilidade
de
se
estudar
um
programa
através
da
engenharia
reversa
ser
uma
pratica
livre
ou
não.
A
corrente
de
pensamento
que
prevaleceu
e
está
em
vigor
até
a
atualidade
foi
a
de
proibir
a
engenharia
reversa.
O
que
se
discute
no
direito
é
o
processo
da
engenharia
reversa
e
não
o
que
se
faz
depois
que
se
obtém
o
pseudocódigo
fonte.
Do
ponto
de
vista
da
compatibilidade
com
o
sistema
de
Direito
de
Autor
existem:
(a)
Exclusão
da
proteção
de
ideias,
conceitos,
etc.
Todos
que
utilizam
um
algoritmo
de
um
programa
já
existente,
mas
que
gerariam
seu
programa
de
uma
forma
essencialmente
diferente
não
seria
responsável
por
violação
de
direitos
autorais.
(ULMER
&
KOLLE,
1983)2
Basicamente
entende-se
que
a
utilização
de
um
algoritmo
não
pode
ser
considerada
uma
violação
de
direito
autoral.
(b)
A
proibição
pela
Lei
de
Direitos
Autorais
equivale
a
criar
um
regime
de
segredo
do
conteúdo
do
programa
inaplicável
às
obras
tradicionais.
direitos
de
autor
para
o
software
permite,
pela
primeira
vez
na
história
das
propri
(BERNARD,
1993)3
Da
tradução
livre
observa-se
que
o
direito
do
autor
no
âmbito
do
software
é
considerado
um
segredo.
(c)
A
engenharia
reversa
pode
implicar
a
realização
de
atos
atentatórios
contra
a
exclusividade
do
autor.
A
reprodução
e
transformação
da
forma
de
expressão
do
programa
de
computador
obtido
através
da
engenharia
reversa
do
código
objeto
para
extração
do
pseudocódigo
transitória
ou
incidental
está
prevista
e
proibida
pelo
Art.
30,
§
1o
da
Lei
Direito
Autoral.
Segundo
as
leis
vigentes
(Lei
9.609/98
Lei
do
Software)
não
é
necessária
a
autorização
do
titular
dos
direitos
quando
a
reprodução
do
código
e
a
tradução
da
sua
forma
forem
indispensáveis
para
obter
as
informações
necessárias
à
interoperabilidade
de
um
programa
de
computador
criado
independentemente,
com
outros
programas,
uma
vez
preenchidas
as
seguintes
condições:
(a)
esses
atos
serem
realizados
pelo
licenciado
ou
por
outra
pessoa
que
tenha
o
direito
de
utilizar
uma
cópia
do
programa,
ou
em
seu
nome
por
uma
pessoa
devidamente
autorizada
para
o
efeito;
(b)
não
se
encontrarem
já
fácil
e
rapidamente
à
disposição
das
pessoas
referidas
as
informações
necessárias
à
interoperabilidade;
(c)
esses
atos
limitarem-se
a
certas
partes
do
programa
de
origem
necessárias
à
interoperabilidade.
O
Art.
6,
IV
da
Lei
9.609/98
(Lei
do
Software)
cita
possibilidades
de
estudo
que
não
constituem
ofensa
aos
direitos
do
titular
de
programa
de
computador,
sendo
a)
Integração
de
um
programa,
mantendo-se
suas
características
essenciais,
a
um
sistema
aplicativo
ou
operacional,
tecnicamente
indispensável
às
necessidades
do
usuário,
desde
que
para
o
uso
exclusivo
de
quem
a
promoveu.
Dessa
forma,
a
descompilação
segundo
a
lei
vigente
sobre
softwares
de
computador
brasileira
seria
livre,
embora
não
seja
legal,
ela
pode
ser
realizada
sem
punição.
Segundo
Oliveira
Ascensão
(Direito
Autoral,
1997,
p.
671)
orquanto
a
integração,
requerendo
ato
de
transformação
ou
adaptação,
pressupõe
a
descompilação,
ou
seja,
a
proteção
não
é
legal,
mas
todas
as
licenças
de
uso
de
software
proíbem
a
engenharia
reversa.
2.3.
Questões
Econômicas
da
Engenharia
Reversa
O
benefício
fundamental
da
tecnologia
de
ER
(Engenharia
Reversa)
é
o
aumento
do
entendimento
de
um
sistema
o
que
facilita
a
atividade
de
manutenção
e
consequentemente
aumento
da
produtividade
(vantagens
financeiras).
As
partes
do
sistema
que
vão
sofrendo
a
engenharia
reversa
já
são
funcionais
e
podem
ser
utilizadas
em
outras
aplicações.
O
aumento
da
produtividade
na
etapa
de
desenvolvimento
de
software
através
do
reuso,
garantindo
a
qualidade
já
existente
no
aplicativo
original
torna
o
sistema
mais
fácil
de
ser
mantido,
suportado
e
evoluído.
(Penteado,
2009)
Baseado
nas
características
do
sistema
que
sofrerá
o
processo
de
Engenharia
Reversa
não
se
pode
no
início
da
análise
quantificar
com
precisão
quanto
trabalho
será
necessário
para
obter
o
sistema
funcional
desassemblado,
isto
é,
seu
código
fonte.
Em
vista
disso,
nas
aplicações
da
Engenharia
Reversa
os
custos
podem
ser
invariavelmente
difusos
dependendo
de
como
foi
concebido
o
software,
podendo
ser
facilmente
analisado
e
gerado
um
código
fonte
novo
com
iguais
funcionalidades
ou
extremamente
complexo
a
ponto
de
inviabilizar
a
ER
mas
qualquer
que
seja
o
caso,
apenas
depois
de
iniciada
a
análise
é
que
será
conhecida
a
complexidade
do
desafio.
(Ayres,1987)
A
ER
pode
facilitar
novos
desenvolvimentos
pelo
exame
de
como
sistemas
similares
foram
construídos
e
assim
as
equipes
de
projetistas
podem
obter
mais
informações
para
as
decisões
a
serem
tomadas
nos
novos
projetos,
como
foi
o
notório
caso
apresentado
a
quem
estuda
essa
área
que
é
a
do
bombardeiro
da
segunda
guerra
mundial
o
Tupolev.
(Gordon,
2002)
Todo
projeto
que
vá
utilizar
a
ER,
além
das
implicações
econômicas,
deve
sempre
levar
em
consideração
as
implicações
legais.
Os
japoneses
no
pós-guerra
adotaram
a
ER
de
maneira
massiva,
o
que
contribui
positivamente
em
sua
indústria
até
1960
quando
deixaram
de
simplesmente
copiar
produtos
e
tecnologias
e
passaram
a
desenvolvê-las.
(Sicsu,
1989),
No
episódio
russo
do
avião
bombardeiro
Tupolev,
os
russos
optaram
por
realizar
a
engenharia
reversa
de
um
avião
já
pronto
e
funcional
ao
invés
de
criarem
um
projeto
novo
para
seu
novo
bombardeiro,
no
caso
dos
russos
eles
conseguiram
realizar
uma
análise
que
os
fez
optar
pela
engenharia
reversa
ao
processo
tradicional,
mesmo
que
os
custos
dessa
operação
fossem
bem
mais
elevados
o
prazo
estimado
para
a
execução
da
ER
foi
bem
inferior
ao
do
projeto
tradicional.
Nesse
capítulo
foi
apresentado
um
estudo
sobre
a
engenharia
reversa
seus
aspectos
legais
analisando-se
diversos
estudioso
do
tema
os
quais
chega-se
à
conclusão
que
a
engenharia
reversa
embora
seja
algo
ilegal
do
ponto
de
vista
jurídico
pode
ser
considerada
uma
pratica
livre.
Foram
elencados
motivos
e
os
objetivos
para
a
utilização
da
engenharia
reversa.
Os
passos
que
são
seguidos
no
processo
da
análise
do
funcionamento
até
sua
desassemblagem
e
obtenção
do
código
fonte
também
foram
citados.
Traçou-se
um
paralelo
entre
o
processo
comum
de
engenharia
progressiva/tradicional
e
a
engenharia
reversa
(figura
1)
E
para
finalizar
foi
citado
um
episódio
de
engenharia
reversa
utilizada
durante
a
segunda
guerra
mundial
na
qual
os
custos
do
projeto
de
ER
superaram
em
muito
o
da
engenharia
tradicional,
mas
foi
escolhido
devido
ao
curto
prazo
para
implantação
do
produto.
Capítulo
3
Mecanismos
de
Proteção
Existem
apenas
dois
tipos
de
proteção
aos
programas
de
computador
que
podem
ser
utilizadas,
a
proteção
jurídica
através
de
registro
de
obra
intelectual
e
de
patentes
ou
via
software
com
modificações
nos
programas
evitando
seu
entendimento
e
possíveis
cópias.
A
proteção
do
software
como
um
problema
de
âmbito
global
tratado
pelo
direito
surgiu
há
mais
de
três
décadas
e
sempre
foi
tratado
com
duas
vertentes,
o
direito
do
autor
e
a
patente,
sendo
que
ambos
sistemas
de
proteção
coexistem
em
harmonia
e
são
complementados
pela
proteção
via
software.
3.1.
Mecanismos
de
Proteção
Jurídica
Existe
uma
natureza
dualista,
ou
híbrida,
do
software
como
sendo
uma
criação
utilitária
como
um
processo
ou
como
uma
forma
de
expressão.
Sob
a
ótica
estritamente
funcional
uma
criação
técnica
que
vise
a
solução
de
problemas
específicos
(caráter
utilitário)
deve
ser
enquadrada
como
um
processo,
já
sob
a
ótica
da
geração
de
saber,
o
software
seria
uma
forma
de
expressão
pois
envolve
a
implementação
de
um
processo
lógico,
isso
é,
o
software
é
um
conjunto
organizado
de
instruções
para
a
realização
de
funções
determinadas.
(Pereira
dos
Santos,
1997).
O
software
possui
aspecto
simbólico
e
textual
da
mesma
forma
que
uma
criação
intelectual
que
se
exterioriza
pelo
modo
expressivo
(obra
intelectual),
dessa
forma
o
programa
de
computador
é
implementado
utilizando
uma
linguagem
natural
e
codificada.
(Lei
nº10.196
sobre
Propriedade
Industrial
de
2001)
Justamente
por
apresentar
essa
natureza
hibrida,
de
obra
intelectual
e
de
inovação,
o
software
pode
ser
protegido
tanto
pelo
direito
do
autor
como
através
de
patentes.
Sob
a
tutela
do
direito
autoral
a
criação,
como
natureza
jurídica
de
obra
intelectual,
protege
apenas
e
unicamente
o
código
fonte
e
seus
elementos
literais
e
não
literais,
a
tutela
legal
fica
então
sujeita
ao
critério
de
originalidade,
caso
o
código
so
fra
algumas
modificações
que
descaracterizem
sua
origem,
o
direito
do
autor
não
consegue
proteger
esses
casos.
Por
sua
vez
no
caso
da
patente,
como
a
natureza
jurídica
é
de
invenção
-sendo
que
a
tutela
legal
incide
basicamente
sobre
a
solução
técnica
(especificações),
critérios
de
novidade,
atividade
inventiva
e
aplicação
industrial
-a
inovação
é
protegida.
Então,
proteção
de
software
é
um
problema
universal
que
todos
os
países
têm
de
lidar.
Proteção
de
Software
é
também
um
velho
problema...
Eu
digo
velho
novo
problema,
porque
a
questão
agora
data
de
cerca
de
trinta
anos,
pelo
menos
nos
países
onde
a
computação
conheceu
seus
primeiros
desenvolvimentos.
No
entanto,
é
uma
questão
tópica.
E
esse
é
o
caso,
porque,
mesmo
que
o
acordo
TRIPS
diz
em
seu
artigo
7º:
"Os
programas
de
computador,
quer
seja
o
código
fonte
ou
objeto,
serão
protegidos
como
obras
literárias
conforme
a
Convenção
de
Berna
(1971)",
a
pergunta
que
perdurou
por
dez
ou
quinze
anos,
de
acordo
com
os
países,
da
patente
na
abordagem
da
"protegibilidade".
Na
verdade,
a
história
da
proteção
de
software
é
uma
história
caótica.
E
a
questão
da
proteção
de
software
aparece
hoje
como
uma
questão
de
"oscilação"
entre
os
dois
polos
que,
por
um
lado
é
copyright
(direito
autoral)
e,
por
outro
lado,
é
patente,
com
o
que
implica
em
termos
de
complexidade.
É
necessário
saber
sobre
ao
direito
do
autor
do
software
e
sobre
a
sua
patenteabilidade,
mas
também
sobre
a
coexistência
de
dois
sistemas
de
proteção.
(VIVANT,
2009)4
Pode-se
inferir
que
devido
as
características
intrínsecas
dos
programas
de
computador,
mais
especificamente
pela
sua
inovação
e
por
sua
maneira
de
ser
expresso
como
uma
obra
intelectual;
os
softwares
podem
ser
protegidos
juridicamente
tanto
pelo
sistema
de
patentes
como
por
direito
autoral.
3.2.
Mecanismos
de
Proteção
via
Software
As
técnicas
de
proteção
de
um
software
visam
dificultar
a
engenharia
reversa,
assegurando
que
o
software
executa
como
esperado
e
protegendo
o
software
de
pirataria.
(Collberg
et
al,
1998)
Existem
algumas
técnicas
para
esconder
informações
em
programas
de
computador,
o
presente
trabalho
focará
em
3
tipos
que
além
de
esconder,
protegem
o
código
e
lhe
fornecem
uma
grande
capacidade
de
incompreensão.
Técnicas
de
ofuscação
de
código
dificultam
engenharia
reversa
através
de
um
aumento
no
grau
de
ininteligibilidade
do
código.
Este
aumento
se
caracteriza
por
modificações
sintáticas
que
dificultam
a
compreensão
do
software
mantendo,
porém,
as
funcionalidades
originais
do
programa
(sua
semântica).
(Boccardo,
2010)
Avanços
incrementam
o
poder
dos
software
para
engenharia
reversa
com
o
objetivo
de
descobrir
vulnerabilidades,
realizar
alterações
indevidas,
ou
furtar
propriedade
intelectual...
Atualmente,
existe
pouco
conhecimento,
entre
os
desenvolvedores
de
software,
sobre
a
importância
do
uso
destas
(BOCCARDO,
2010)
A
engenharia
reversa
em
programas
de
computador
envolve
geralmente
duas
fases:
análise
e
modificação.
Na
análise,
é
objetivado
compreender
como
funciona
o
programa,
a
modificação
por
sua
vez
se
dá
quando
já
se
possui
o
conhecimento
adequado
do
software
e
então
pode-se
criar
um
novo
a
partir
do
que
foi
compreendido.
A
utilização
de
técnicas
de
ofuscamento
de
código
tenta
dificultar
o
entendimento
do
software
através
da
modificação
de
alguma
parte
do
programa,
da
extração
de
algoritmos
e
sua
substituição
por
outros,
alteração
nas
rotinas
de
cálculos,
mudanças
no
fluxo
seguido
pelo
programa.
Para
implementar
essas
técnicas
o
programador
vai
adicionando,
alterando
e
modificando
diversos
elementos
em
um
programa
fazendo
com
que
ele
se
torne
o
mais
rebuscado
possível
sem
alterar
seu
funcionamento.
Zaytsev
(2005)
Ofuscar
um
programa
refere-se
entre
outros
aspectos
a
geração
de
um
novo
programa
funcionalmente
equivalente
no
qual
a
coleta
de
dados
de
funcionamento
por
engenharia
reversa
é
extremamente
mais
complexa
que
no
programa
não
ofuscado.
É
recomendável
que
o
programa
que
será
ofuscado
já
esteja
pronto,
testado
e
funcionando
conforme
as
especificações
que
lhe
foram
propostas,
pois
as
altera
ções
implementadas
para
ofuscar
o
código
não
devem
de
maneira
alguma
alterar
o
funcionamento
original
do
software.
Do
ponto
de
vista
da
propriedade
intelectual,
essas
técnicas
utilizadas
pelos
analistas,
desenvolvedores,
programadores
visam
esconder
informações
sobre
tópicos
que
não
podem
possuir
propriedade,
como
é
o
caso
dos
algoritmos
-seja
esse
algoritmo
uma
novidade
ou
uma
versão
aprimorada
de
algum
já
existente
que
depois
de
muito
investimento
para
implementá-lo
percebe-se
que
não
é
muito
lucrativo
distribui-lo
livremente.
A
ofuscação
de
código
fonte
tem
se
mostrado
uma
técnica
bastante
útil
para
esconder
informações
valiosas
dentro
de
um
programa.
(Collberg
et
al,
1997)
O
ofuscamento
do
código
fonte
eleva
a
dificuldade
de
compreensão
do
código
levando
o
programador
espião
a
desistir
da
análise
visto
a
alta
complexidade
do
programa.
Essa
análise
de
um
código
a
fim
de
determinar
suas
funcionalidades,
características
visando
o
entendimento
do
programa
como
um
todo
recebe
o
nome
de
engenharia
reversa.
A
dificuldade
no
entendimento
do
código
ofuscado
se
baseia
na
quantidade
de
dinheiro
e
tempo
que
serão
gastos
na
análise
do
programa
(Collberg
et
al,
1997)
Um
efeito
secundário
e
positivo
que
o
ofuscamento
acaba
produzindo
é
o
aumento
da
segurança
do
programa
contra
tentativas
de
ataque,
popularmente
conhecido
como
hackea-lo,
isto
é,
contra
tentativas
de
descobrimento
de
vulnerabilidades,
uma
vez
que
estando
o
programa
praticamente
ilegível,
a
dificuldade
para
encontrar
erros
e
falhas
é
altamente
elevada,
afinal,
o
adversário
ou
invasor
sequer
entende
o
que
o
programa
está
fazendo.
Os
mecanismos
de
proteção
via
software
são
técnicas
utilizadas
para
ofuscar
um
sistema
de
computador
as
quais
versam,
em
sua
grande
maioria,
sobre
alterações
na
estrutura
do
código
fonte
do
programa
através
da
inclusão
de
artifícios
que
possuem
a
finalidade
pura
e
simples
de
confundir
e
dificultar
o
entendimento
do
que
o
programa
é
e
do
que
o
programa
faz
de
verdade.
Capítulo
4
-Técnicas
de
ofuscamento
Conforme
explicitado
nos
capítulos
anteriores,
como
mecanismos
para
proteger
um
programa
de
computador
existem
a
via
jurídica
e
a
via
do
software,
dando
continuidade
e
aprofundando
os
conhecimentos
relativos
à
proteção
via
softwares
temos
as
técnicas
de
ofuscamento
de
código.
Dentre
as
técnicas
estáticas
existem
alguns
grupamentos
de
acordo
com
as
transformações
a
serem
realizadas
no
código,
como:
-Alterações
apenas
na
estrutura
do
código
que
não
geram
diferença
no
código
objeto
/
programa
final
e
que
versam
sobre
a
remoção
de
informações
redundantes
ou
desnecessários,
em
inglês
minyfi
e
a
renomeação
de
identificadores
e
variáveis.
4
Figura
2
-
Alterações
no
fluxo
de
processamento
do
programa
que
geram
diferença
no
código
objeto
/
programa
final
causando
um
maior
consumo
de
CPU
que
o
programa
gerado
pelo
código
original
tais
como
dificultar
a
análise
do
fluxo
de
controle
pela
inserção
de
saltos
condicionais
ou
não
durante
o
processamento
do
programa
além
da
eliminação
de
sessões
do
programa
e
reordenação
do
código
fonte.
-
-code
ou
códigos
espúrios
na
qual
o
programador
insere
trechos
de
código
que
podem
ou
não
ser
executados
de
acordo
com
determinadas
situações
fazendo
com
que
o
estudante
que
estiver
analisando
o
programa
sequer
saberá
se
determinado
trecho
será
executado
ou
não.
(COLLBERG
et
al,
1998).
Essas
alterações
da
mesma
maneira
que
as
alterações
no
fluxo
de
processamento
geram
diferenças
no
programa
final
causando
um
maior
consumo
de
CPU
que
o
programa
gerado
pelo
código
original
Figura
3
-Trecho
de
código
fonte
com
dead
code
A
figura
3
acima
ilustra
um
trecho
de
um
programa
que
possui
um
dead
code,
isto
é,
um
trecho
de
código
que
jamais
será
executado.
No
exemplo
temos
que
to
-
das.
Nesse
caso
pode-se
inferir
que
o
programador
realizou
a
manutenção
do
código
e
não
se
atentou
para
retirar
as
linhas
que
ficaram
mortas
no
código.
-Alterações
estruturais
para
comandos
equivalentes
como
a
troca
de
um
laço
enquanto
por
um
laço
até,
utilização
de
claúsulas
unitárias
de
cálculos
decompondo
um
cálculo
mais
rebuscado,
inserção
de
IFs
encadeados
ou
troca
de
situações
de
igualdade
por
outras
possibilidades,
a
alteração
de
estruturas
de
controle
e
contadores
e
uma
infinidade
de
estruturas
que
podem
ser
decompostas,
alteradas
ou
incluídas
contendo
as
mesmas
funcionalidades,
mas
com
um
grau
de
compreensão
muito
rebuscado.
(COLLBERG
et
al,
1997)
Essas
alterações
podem
ou
não
gerar
diferença
no
código
objeto
/
programa
final
depende
da
linguagem
de
programação
e
das
opções
de
compilação.
Deve-se
sempre
lembrar
de
inserir
comandos
similares
e
utilizar
variáveis
espelho
ou
mesmo
a
própria
variável
sendo
seu
valor
armazenado
antes
de
modificações
e
recuperado
após
elas
mantendo
seu
valor
original
em
trechos
.
Inserção
de
instruções
sem
função
dentro
do
código:
Geralmente
são
utilizadas
expressões
que
verificam
determinados
valores
de
uma
dada
variável
e
alteram
o
fluxo
do
processamento
ou
processam
partes
do
programa
que
não
geram
nada
de
útil
apenas
gastam
processamento
e
levam
o
analista
a
loucura
tentando
entender
determinado
trecho
do
programa.
ZAYTSEV
(2005)
Essas
alterações
causam
mudanças
no
fluxo
de
processamento,
utilizam
CPU
para
realizar
tarefas
sem
relação
ao
objetivo
do
programa
e
com
isso
acabam
gerando
um
programa
bem
diferente
do
original.
A
utilização
das
técnicas
estáticas
listadas
acima
visa
tornar
o
mais
difícil
possível
a
tarefa
de
descobrir
de
onde
veio
e
para
onde
seguira
a
execução
do
programa
e
se
o
trecho
a
ser
executado
ou
que
foi
executado
é
útil
ou
não.
Não
há
sentido
em
incluir
um
trecho
para
dificultar
o
entendimento
do
analista
adversário
se
o
trecho
destoar
por
completo
do
restante
do
programa,
portanto
os
do
código
fonte.
4.1.
Auto
documentação
Uma
das
grandes
vantagens
da
linguagem
COBOL
é
que
ele
é
auto
documentável,
essa
característica
predominante
do
COBOL
ocorre
pois
em
sua
concepção
foram
utilizados
termos
e
semânticas
da
língua
inglesa
que
facilitou
muito
o
aprendizado
da
linguagem
e
também
sua
disseminação.
(Wojciechowski,
2010)
Por
se
assemelhar
muito
ao
modo
da
escrita
inglesa
muitos
códigos
fonte
de
programas
escritos
em
COBOL
podem
ser
entendidos
até
mesmo
por
pessoas
totalmente
leigas
com
apenas
algum
conhecimento
de
lógica
e
um
pouco
de
inglês.
Segue
baixo
um
comando
simples
da
linguagem.
ADD
VALOR-1
TO
VALOR-2
O
comando
acima
é
uma
adição,
ao
ler
o
comando
automaticamente
o
leitor
consegue
interpreta-lo,
qualquer
pessoa
com
um
mínimo
de
discernimento
da
língua
inglesa
e
que
conheça
um
pouco
de
matemática
deve
ter
entendido
algo
como
Adicione
o
valor-1
ao
valor-2
Entretanto
o
comando
também
pode
aceitar
uma
outra
sintaxe
ADD
VALOR-1
TO
VALOR-2
GIVING
VALOR-3
A
qual
não
apresenta
nenhum
segredo,
seria
adicione
o
valor-1
ao
valor-2
e
de
o
resultado
(GIVING)
no
valor-3.
Uma
outra
maneira
de
fazer
a
mesma
operação
e
que
talvez
até
mais
fácil
de
ser
compreendida
pois
se
assemelha
a
uma
formula
matemática
e
não
a
um
texto
é
COMPUTE
VALOR-3
=
VALOR-1
+
VALOR-2
Ambos
comandos
ADD
ou
COMPUTE
podem
gerar
erros
e
o
COBOL
os
trata
de
maneira
bem
parecida
utilizando-se
um
ou
SIZE
ERROR
ADD
VALOR-1
TO
VALOR-2
GO
TO
ENCERRA-EXECUCAO
END-ADD
O
leitor
mesmo
que
desavisado
entenderá
que
se
acontecer
algum
erro
será
exibida
uma
mensagem
de
erro
e
o
processamento
seguira
para
o
encerramento
(GO
TO
ENCERRA-EXECUCAO)
Esse
tipo
de
situação
gerou
muito
conforto
para
os
analistas
e
programadores
que
por
vezes
acabaram
se
acostumando
a
não
documentar
o
código.
Como
nos
exemplos
acima
pode-se
ver
que
mesmo
sem
qualquer
comentário
sobre
o
que
o
comando
realiza
é
possível
o
seu
entendimento
sem
grandes
esforços.
Uma
vez
que
os
códigos
fontes
são
bem
guardados,
os
programas
são
compilados
e
o
usuário
não
tem
acesso
a
nenhum
desses
componentes
nunca
houve
preocupação
com
a
facilidade
do
entendimento
do
código.
Em
linguagens
de
programação
mais
atuais
principalmente
em
aplicações
WEB
esse
tipo
de
situação
é
completamente
desaconselhável
e
indesejado,
nesses
sistemas
o
usuário,
um
concorrente,
um
adversário,
vulgo,
hacker
ou
qualquer
pessoa
tem
acesso
ao
código
fonte
que
está
em
execução,
isso
gera
um
novo
cenário
e
uma
vasta
gama
de
problemas
que
os
programadores
de
COBOL
sequer
um
dia
ousaram
pensar.
(Somekawa,
2012)
Os
problemas
advindos
da
proliferação
dos
códigos
fontes
em
claro,
especificamente
no
COBOL
é
muito
bem-vindo
ainda
mais
que
os
sistemas
costumavam
ter
pouca
ou
nenhuma
documentação,
porém
na
era
da
internet,
os
analistas
de
sistemas
WEB
precisam
que
o
código
seja
inteligível
somente
para
eles
próprios,
o
usuário
final
não
precisa
e
não
é
recomendável
que
tenha
acesso
e
entenda
o
funcionamento
do
código.
(Venkatesan,
2002)
4.2.
Minificação
de
código
Em
português
criou-se
um
estrangeirismo
ou
neologismo
vindo
do
inglês
minify,
que
nada
mais
é
que
reduzir.
A
palavra
equivalente
existe
em
português,
mas
no
meio
das
pessoas
que
trabalham
com
informática,
mais
especificamente
com
programação,
optou-se
pelo
uso
de
minificação
de
código.
A
minificação
é
processo
de
retirar
os
comentários,
elementos
acessórios,
unir
os
comandos
e
tornar
o
código
o
mais
enxuto
ou
reduzido
possível.
(WU
et
al.,
2010)
Além
do
código
fonte
do
programa
não
possuir
comentários
muitos
elementos
excluídos
do
código,
identidade
visual,
espaços,
tabulações
e
outros
elementos
são
suprimidos
do
código,
por
exemplo
Esse
trecho
de
código
fonte
acima
encontra-se
minificado,
se
comentado
e
utilizando-se
a
sintaxe
completa
dos
comandos
de
acordo
com
as
boas
práticas,
esse
mesmo
código
se
torna:
Figura
4
-Trecho
de
código
fonte
original
5
A
minificação
não
deve
ser
entendida
como
uma
técnica
de
proteção
quando
utilizada
sozinha,
pois
a
lógica
do
programa
ainda
continua
exposta
e
de
fácil
compreensão,
o
estudante
apenas
encontrara
um
pouco
de
dificuldade
em
remontar
ou
expandir
o
código
minificado.
Ao
reduzir
um
código
fonte
suas
funcionalidades
permanecem
inalteradas.
Para
o
computador
que
executará
o
programa
pronto
não
existe
qualquer
diferença
entre
o
programa
original
sem
sofrer
o
processo
de
redução
e
o
programa
reduzido,
isto
é,
não
existe
diferença
nenhuma
no
programa
executável,
apenas
em
seu
código
fonte.
4.3.
Minificação
e
ofuscamento
Do
ponto
de
vista
analítico
o
ofuscamento
é
algo
mais
elaborado
que
a
minificação,
pois
requer
um
pouco
de
esforço
do
programador
e
do
analista
para
que
seu
código
se
torne
mais
difícil
de
entendimento.
Vamos
ao
exemplo
clássico
do
primeiro
programa
de
computador
que
todos
deveriam
aprendem
quando
começam
a
programar
em
uma
nova
linguagem,
que
é
o
HelloWorld,
no
COBOL
ele
seria
algo
como
o
exemplo
abaixo:
Figura
5
-Programa
HelloWorld
em
COBOL
Apêndice
A
Entre
as
partes
da
figura
acima
numeradas
entre
1
e
2
o
leitor
não
precisa
se
deter
muito
a
tentar
compreender
o
significado
de
cada
linha
existente
no
código
fonte.
Nesse
primeiro
momento
digamos
apenas
que
todas
as
instruções,
comandos,
identificadores
existentes
fazem
parte
do
que
é
considerado
um
cabeçalho
padrão
sendo
utilizado
em
todos
os
programas
COBOL
com
pouca
ou
nenhuma
variação.
Atualmente
nas
versões
do
mainframe
e
de
seu
sistema
operacional
quase
nada
agregam,
ainda
existem
por
razões
históricas
e
de
compatibilidade,
algo
que
a
IBM
jamais
abriu
mão.
Existem
muitas
razões
pelas
quais
programas
e
aplicativos
existentes
não
podem
ser
alterados.
Talvez
a
aplicação
foi
comprada
em
um
pacote,
de
modo
que
você
não
tem
acesso
ao
código
fonte.
Talvez
alguém
possui
o
aplica-tivo;
talvez
ele
roda
em
sistema
de
outra
pessoa.
Talvez
a
fonte
foi
perdido,
e
não
há
ninguém
que
conhece
o
programa
muito
bem.
Talvez
a
lógica
do
programa
é
tão
complexa
que
as
alterações
são
consideradas
muito
perigosas
(IBM,2014)6
O
que
interessa
no
processo
de
ofuscamento
é
o
próprio
código
gerado
após
a
utilização
de
alguma
das
técnicas.
Um
simples
comando,
DISPLAY
com
a
frase
como
o
da
figura
5
pode
ser
ofuscado
fazendo
com
que
o
entendimento
do
que
o
programa
fique
bem
complicado.
Figura
6
-Programa
HelloWorld
em
COBOL
ofuscado
Apêndice
B
Uma
das
poucas
informações
que
podem
ser
extraídas
do
código
acima
é
que
será
emitida
uma
mensagem
(comando
DISPLAY),
mas
para
descobrir
o
conteúdo
que
ser
exibido
será
necessário
dispender
um
pouco
mais
de
tempo
e
analisar
o
que
existe
dentro
das
variáveis
utilizadas
no
comando.
Nesse
exemplo
foi
utilizado
ao
invés
da
frase
em
claro
'Hello
World!'
foram
utilizadas
três
variáveis
sendo
seus
nomes
não
contém
qualquer
significado
e
seus
conteúdos
encontram-se
inicializados
em
hexadecimal.
Antes
do
comando
para
exibição
da
mensagem
foi
executada
uma
movimentação
com
subscritor
MOVE
1C
TO
1D
(6:7)
para
despistar
o
adversário.
Ao
código
podem
ser
implementadas
outras
movimentações,
cálculos
diversos,
outras
variáveis,
enfim,
uma
infinidade
de
artifícios
para
que
o
código
fique
o
mais
ininteligível
possível.
O
ofuscamento
de
código
(Code
Obfuscation
em
inglês)
é
um
método
muito
seguro
e
de
fácil
aplicação.
Atualmente
existem
no
mercado
inúmeros
software
para
realizar
a
tarefa,
uma
simples
pesquisa
na
internet
em
sites
de
busca
obtém
diversos
resultados,
tanto
pagos
como
gratuitos,
mas
para
a
linguagem
COBOL
não
existem
muitas
opções,
mais
especificamente,
foram
encontrados
apenas
um
software
para
a
linguagem
que
é
o
Redvers
Cloaking
Device
(ANEXO
1).
4.4.
Compilação
e
link
edição
No
processo
para
fazer
com
que
um
programa
funcione,
isto
é,
execute,
algumas
etapas
devem
ser
seguidas
para
que
seu
código
fonte
se
transforme
em
um
executável.
Basicamente
e
de
maneira
simplista
seriam
compilação
e
link
edição.
Na
etapa
de
compilação
o
seu
código
fonte,
por
exemplo
em
COBOL,
é
convertido
para
uma
montagem
assembler,
que
recebe
o
nome
de
código
de
máquina,
essa
listagem
contém
seu
programa
convertido
para
a
linguagem
mais
básica
dos
computadores,
necessitando
apenas
sua
link
edição
ou
bind.
(AHO;
SETHI;
ULLMAN,
2007)
Caso
um
adversário
resolva
atacar
o
código
depois
do
programa
já
finalizado
e
pronto
para
uso
(depois
de
link
editado)
e,
portanto,
executável.
O
trabalho
dispendido
para
tentar
entender
como
é
o
funcionamento
do
programa
é
de
extrema
dificuldade
e
só
se
justifica
em
casos
excepcionais,
embora
possível
esse
tipo
de
abordagem
para
a
engenharia
reversa
é
muito
dispendioso
e
geralmente
impraticável.
Pode-se
adicionar
uma
camada
extra
de
proteção
ao
se
utilizar
o
ofuscamento
também
no
código
de
máquina
gerado
pelos
compiladores
ou
montadores
antes
da
link
edição
para
geração
do
programa
executável
(módulo
carga
no
caso
do
mainframe),
nesses
casos
o
acesso
ao
código
fonte
do
programa
não
é
possível
e
se
quer
faria
sentido
pois
o
programa
que
estava
no
código
fonte
original
teve
seu
funcionamento
alterado
(embora
mantido
o
processo
de
entrada
e
saída)
pelo
ofuscamento
de
seu
código
de
máquina,
sendo
a
engenharia
reversa
de
desmontar
o
programa
ofuscado
segundo
Wroblewski
uma
tarefa
inútil
embora
100%
de
proteção
jamais
será
alcançada.
(Barack
et
al,
2001)
4.5.
Código
redundante
Outra
técnica
empregada
para
dificultar
o
entendimento
é
a
utilização
de
código
redundante,
que
nada
mais
é
do
que
uma
parte
de
código
sem
qualquer
utilidade
prática
ou
funcional,
serve
única
e
exclusivamente
para
dificultar
o
entendimento
e
atrapalhar
a
análise
do
código.
A
situação
de
código
redundante
ocorre
por
vezes
de
maneira
totalmente
despretensiosa
e
sem
qualquer
cuidado
por
parte
do
programador,
muitas
vezes
partes
de
código
sem
qualquer
função
continuam
a
existir
pois
em
algum
momento
da
história
de
vida
daquele
programa
foi
utilizado
uma
outra
linha
de
execução
e
esqueceu-
se
de
retirar
essa
parte
do
código
do
módulo
ou
mesmo
de
simplesmente
comentar
sua
inutilização.
(BODÍK;
GUPTA,
1997)
Um
código
redundante
em
inglês,
é
inserido
em
um
programa
por
alterações
no
código,
qualquer
um
pode
escrever
um
programa
que
acabe
possuindo
dead
code,
uma
função
antiga
que
deixa
de
ser
utilizada
e
se
torna
obsoleta,
as
variáveis
que
eram
utilizadas
por
essa
função
também
se
tornam
redundantes,
pois
assim
como
a
parte
do
código
que
deixou
de
ser
referenciado
essas
variáveis
também
o
serão.
Esse
tipo
de
alteração
ou
mudança
ocorre
devido
a
evoluções
no
código
nas
quais
o
analista
não
prestou
muita
atenção
que
em
sua
mudança
partes
do
código
deixariam
de
ser
referenciadas
e
simplesmente
as
deixou
no
programa.
(AIVOSTO,
2016)
Uma
outra
causa
muito
comum
e
talvez
a
mais
proeminente
para
a
existência
de
código
redundante
seja
a
reutilização
de
programas,
em
outras
palavras,
o
conhecido
copie
e
cola,
vulgo
Control
+
C,
Control+
V.
Ao
copiar
um
programa
esqueleto,
modelo,
similar,
padrão
ou
qualquer
outra
nomenclatura
que
possa
existir
muitas
partes
do
código
fonte
desse
módulo
não
servirão
para
o
novo
programa;
variáveis,
sessões,
comentários
do
programa
original
continuarão
a
existir
no
código
novo
sendo
que
só
servirão
para
confundir
e
dificultar
o
entendimento,
sempre
que
for
reutilizar
um
módulo
para
servir
de
modelo
para
um
novo
programa
é
recomendável
uma
análise
do
código
fonte
depois
de
finalizada
a
codificação
a
fim
de
detectar
a
existência
de
dead-code
no
programa.
(Wojciechowski,
2010)
Os
compiladores
COBOL
mais
atuais
possuem
análise
desses
elementos,
indicando
no
relatório
de
compilação
a
ocorrência
de
pedaços
do
código
fonte
que
nunca
serão
executados.
(AIVOSTO,
2016)
No
mercado
existem
produtos
específicos
para
análise
desse
tipo
de
situação,
muitos
deles
detectam
e
otimizam
o
código
automaticamente,
sendo
a
parte
desnecessária
simplesmente
suprimida
no
momento
da
compilação
e
o
analista
tendo
que
não
se
preocupar
muito
com
o
que
aquele
código
fazia,
afinal
ele
foi
ignorado,
porém
algumas
situações
nem
o
melhor
dos
produtos
pode
detectar
ou
prever
e
nesses
casos
o
programador
fica
horas
analisando
um
trecho
do
programa
até
descobrir
que
ele
não
serve
para
absolutamente
nada.
Por
exemplo:
Caso
o
programador
simplesmente
se
esqueça
de
comentar
a
sessão
2000TRATA-
REJEICAO
inteira
ou
de
excluir
suas
linhas
de
código
ela
se
tornou
automa
ticamente
e
sem
o
menor
propósito
um
código
redundante,
isto
é,
ela
consta
no
código
fonte,
porém
jamais
será
referenciada
ou
executada.
Embora
nos
compiladores
atuais
uma
mensagem
seja
gerada
informando
que
determinada
parte
do
código
não
será
executada
e
consequentemente
não
será
considerada,
o
programador
mais
desavisado
ou
mesmo
pela
correria
da
rotina
simplesmente
ignora
esse
aviso
e
o
código
sem
utilidade
continuará
a
existir.
A
existência
de
linhas
de
código
sem
utilidade
é
um
desserviço
para
o
sistema
como
um
todo,
ao
se
deparar
com
essa
situação
o
programador
ou
analista
deve
prontamente
retirar
essa
parte
do
programa.
O
código
limpo
contendo
comentários
e
possuindo
apenas
elementos
válidos
e
executáveis
no
fluxo
normal
de
processamento
torna
o
trabalho
de
análise
muito
mais
fácil,
o
analista,
programador
ou
quem
quer
que
esteja
lendo
o
código
realizará
uma
leitura
muito
mais
fácil,
conseguirá
um
entendimento
mais
linear
do
código
e
suas
funcionalidades
e
nos
casos
de
manutenções,
sejam
elas
evolutivas,
corretivas
ou
emergenciais
-principalmente
nas
emergenciais)
a
tarefa
fica
muito
mais
simples.
(MANTOAN,
2011)
Os
fabricantes
de
software
de
análise
de
código,
entre
eles
Aivosto,
Semantic
Designs,
Asetechs,
Modern
Systems,
CA,
MicroFocus,
são
categóricos
em
afirmar
que
cerca
de
30%
a
40%
das
linhas
de
códigos
de
programas
do
legado
do
mainframe
em
COBOL
são
código
redundantes.
(Microfocus,
2012)
A
simplicidade
do
código
deve
ser
sempre
levada
em
consideração
ainda
mais
em
se
tratando
de
linguagem
de
programação
estruturadas
como
no
caso
do
COBOL.
Ao
encontrar
um
código
muito
rebuscado,
utilizando
algoritmos
complexos,
sem
comentários
ou
com
comentários
que
vieram
de
outros
programas
e
não
significam
nada
para
a
análise
do
programa
em
estudo
ou
mesmo
programas
muito
extensos
(mais
de
3000
linhas
de
código)
o
analista
tende
a
perder
muito
tempo
para
tentar
entender
para
que
serve
cada
variável
utilizada
e
qual
o
seu
domínio
(valores
que
podem
ser
aceitos),
o
que
cada
parte
do
programa
realmente
faz,
se
determinada
parte
do
programa
realmente
é
executada
ou
se
é
simplesmente
um
código
redundante.
4.6.
Geração
de
dumb
code
Existem
alguns
momentos
que
são
cruciais
para
a
geração
ou
não
de
código
redundante,
são
eles:
Antes
de
reutilizar
um
código
fonte
já
existente:
-Ao
comprar
um
código
pronto
ou
customizável
pois
o
vendedor
por
não
ter
tomado
os
cuidados
necessários
para
lhe
entregar
um
código
limpo,
uma
análise
minuciosa
do
código
deve
ser
realizada
antes
do
fechamento
da
compra
ou
do
contrato.
-Ao
solicitar
a
construção
do
código
para
uma
fábrica
de
software
pois
os
padrões
podem
não
ter
sido
seguidos
à
risca,
o
modelo
utilizado
possuir
inconsistência
ou
ainda
o
módulo
entregue
não
ter
sido
revisto
com
os
critérios
necessários.
A
revisão
de
programas
oriundos
de
terceiros
DEVE
ser
sempre
realizada
antes
da
aceitação
do
serviço.
Quando
um
novo
membro
começa
a
trabalhar
com
uma
nova
sigla
ou
novo
sistema
deve-se
atentar
para
que
o
novato
entenda
e
aprenda
como
funciona
o
sistema
antes
de
iniciar
suas
codificações,
para
isso
a
análise
dos
códigos
fontes,
fluxos,
estudo
de
manuais
é
essencial,
no
momento
da
análise
dos
programas
o
novato
pode
detectar
pedaços
de
código
sem
uso
e
deve
realizar
sua
eliminação.
(BODÍK;
GUPTA,
1997)
Novas
versões
de
programas,
em
muitas
situações
a
simples
evolução
de
versão
do
programa
já
não
é
mais
possível
devido
a
sua
complexidade
ter
alcançado
o
grau
mais
elevado
possível
o
não
entendimento.
Nesses
casos
o
programa
precisa
ser
reescrito
e
nesse
processo
para
que
todas
as
funcionalidades
ainda
em
uso
do
programa
antigo
continuem
a
existir
e
funcionar
novos
módulos
são
criados.
A
detecção
manual
e
remoção
de
código
redundante
é
muito
trabalhosa
e
só
é
recomendada
nos
casos
de
um
novo
membro
integrou-se
à
equipe
e
precisa
adquirir
os
conhecimentos
daquele
sistema
ou
mesmo
na
reescrita
de
programas,
nos
demais
casos
o
uso
de
ferramentas
automatizadas
é
mais
aconselhável.
(Modern
Systems,
2016)
Existem
no
mercado
inúmeras
ferramentas
para
remoção
de
dead
code,
todas
elas
funcionam
basicamente
da
mesma
forma
analisando
e
inspecionando
o
código
fonte
a
fim
de
encontrar
partes
não
utilizadas,
para
isso
cada
fabricante
utiliza
seu
próprio
algoritmo,
mas
todos
geram
um
relatório
da
análise
e
disponibilizam
opções
para
que
o
usuário
decida
o
que
fazer
com
as
partes
que
não
são
utilizadas,
desde
uma
simples
marcação
nas
colunas
de
numeração
indicando
um
dead
code,
passando
pelo
comentário
dessas
linhas
ou
mesmo
simplesmente
apagando
essas
partes
do
código.
(Ca
Tecnologies,
2011)
Um
dos
maiores
problemas,
se
não
um
dos
únicos
que
a
automatização
da
remoção
de
código
redundante
pode
gerar
é
a
deleção
de
código
bom,
por
esse
motivo
as
ferramentas
informam
no
relatório
que
embora
tenham
detectado
determinado
pedaço
de
código
como
redundante,
algumas
dessas
porções
não
são
certeza,
são
potencias
e
recomendam
a
análise
manual
do
trecho
do
programa
para
evitar
a
exclusão
de
código
utilizável
e,
portanto,
bom.
Essa
situação
caso
ocorra
pode
acarretar
no
não
funcionamento
do
programa
ou
nos
casos
mais
graves
em
comportamento
anômalo
gerando
resultados
totalmente
imprevisíveis
e
geralmente
catastróficos.
4.7.
Revisão
de
código
e
padronização
Um
tópico
merece
atenção
especial
que
é
a
revisão
do
código,
a
revisão
além
de
servir
para
garantir
que
o
que
foi
solicitado
realmente
foi
entregue,
fornece
uma
documentação
adicional
para
o
sistema
e
auxiliam
a
minimizar
os
riscos
envolvidos
no
projeto,
a
detecção
de
erros
no
programa,
funcionalidade
ou
mesmo
do
sistema
como
um
todo
antes
do
envio
para
a
produção,
gera
uma
economia
significativa
de
tempo
e
dinheiro
sem
deixar
de
mencionar
em
todos
os
contratempos
que
um
código
com
problemas
gera
ao
ser
baixado
em
produção.
Ao
se
rever
um
código,
o
nível
de
conhecimento
do
sistema
é
aumentado,
novos
membros
podem
aproveitar
a
oportunidade
e
se
inteirar
das
novas
funcionalidades
e
de
como
estão
interligados
e
se
inter-relacionam
os
novos
componentes
do
sistema,
a
preferência
à
revisão
deve
ser
dada
aos
membros
que
não
foram
os
codificadores
dos
programas,
encontrar
uma
anomalia
em
um
código
que
a
própria
pessoa
gerou
é
uma
tarefa
de
titãs,
as
boas
práticas
de
mercado
e
padronizações
de
desenvolvimento
de
software
preconizam
que
esse
tipo
de
situação
seja
evitada
sempre
que
possível.
(Asetechs,
2016)
A
padronização
e
os
bons
costumes
de
um
dado
sistema
devem
ser
levados
em
consideração
quando
da
revisão
do
código,
porém
caso
o
programa
tenha
sido
desenvolvido
baseado
no
padrão
mais
atual
da
organização
e
precisa
ser
integrado
aos
códigos
já
existentes
(mais
antigos
e
com
outros
modelos)
não
é
recomendável
que
o
código
seja
aderente
ao
padrão
antigo
do
sistema.
Os
novos
módulos
que
forem
desenvolvidos
e
as
manutenções
corretivas
ou
evolutivas
no
sistema
devem
sempre
seguir
os
manuais
e
padrões
mais
atuais
da
instalação.
(Semantic
Designs,
2016)
Conclusão
Ao
longo
do
texto
nos
capítulos
1
e
3
foram
discutidos
os
aspectos
jurídicos
da
proteção
de
software,
suas
origens,
leis
e
tratos
internacionais
além
de
ilustrado
os
dois
tipos
de
proteção
existentes
por
patente
ou
por
direito
autoral.
Como
complementação
às
leis
e
para
garantir
uma
proteção
efetiva
de
suas
criações
os
profissionais
que
trabalham
com
desenvolvimento
de
softwares
inventaram
o
ofuscamento
de
código.
O
ofuscamento
de
código
protege
os
programas
de
computador
contra
os
ataques
da
engenharia
reversa,
técnica
elaborada
que
visa
a
obtenção
de
segredos
do
cerne
dos
softwares,
seja
o
próprio
código
fonte
ou
apenas
um
algoritmo
novo.
Alguns
questionamentos
sobre
a
utilização
ou
não
da
engenharia
reversa,
questões
econômicas
e
exemplos
de
seu
uso
foram
levantados
no
capítulo
2.
As
ferramentas
utilizadas
para
ofuscar
um
código
fonte
foram
trabalhadas
ao
longo
de
todo
o
capítulo
4.
Foram
apresentados
exemplos
de
minificação,
emprego
de
código
redundante,
dumb
code
e
discutidos
os
aspectos
da
revisão
e
da
padronização
dos
programas.
As
técnicas
apresentadas
como
meios
de
proteção
de
código
são
passíveis
de
ataques
e
não
garantem
a
proteção
total
do
código,
isso
não
tem
como
acontecer,
não
existe
(Boccardo,
2010)
uma
proteção
100%
segura.
É
impossível
proteger
sua
criação
contra
a
engenharia
reversa,
pode-se
sim,
dificultar
bastante
o
trabalho
de
um
eventual
adversário.
O
mercado
de
espionagem
industrial
é
um
fomentador
da
engenharia
reversa,
mesmo
empresas
e
industrias
renomadas
como
a
AMD
(Info
World,
1992)
já
se
utilizaram
ou
ainda
utilizam
dessa
técnica
para
observar
o
desenvolvimento
dos
produtos
de
seus
dos
concorrentes
e
porque
não
criar
novos
produtos
e
serviços
que
utilizem
alguma
ideia
que
acabou
de
ser
descoberta
por
engenharia
reversa.
As
técnicas
de
transformação
dos
programas
sejam
por
ofuscamento,
redução,
código
espúrio
adicionam
camadas
de
proteção
extra
ao
código
proporcionando
uma
maior
tenacidade,
resiliência
e
robustez
contra
uma
possível
tentativa
de
análise
do
código
(engenharia-reversa).
No
apêndice
C
encontra-se
um
programa
de
cálculo
de
tabuada
completo
e
funcional,
com
comentários,
estruturado
e
de
fácil
entendimento,
por
sua
vez,
no
apêndice
D
o
mesmo
programa
sofreu
alterações
utilizando-se
as
técnicas
de
ofuscamento
e
seu
entendimento
é
bem
complexo.
A
execução
de
ambos
os
programas
tem
o
mesmo
resultado
e
o
usuário
não
consegue
perceber
qual
versão
estaria
em
execução.
(Apêndice
E)
O
ofuscamento
de
código
fonte
degrada
o
desempenho
e
possui
custo
relativamente
baixo
e
fácil
implementação,
mesmo
que
as
técnicas
a
serem
seguidas
não
façam
parte
de
um
cadastro
prévio
elas
são
facilmente
codificadas
e
podem
ser
reutilizadas
sem
muito
trabalho,
porém
toda
e
qualquer
modificação
no
código
fonte
original
implicará
em
um
maior
consumo
de
processamento.
A
técnica
implementada
no
programa
não
deve
jamais
prejudicar
o
usuário
final
do
sistema,
a
preocupação
em
demasia
com
o
não
entendimento
do
código
fonte
pode
levar
a
um
problema
grandioso
para
o
usuário
caso
algum
procedimento
que
o
usuário
tome
leve
a
um
ponto
do
programa
que
não
foi
previsto,
portanto
testes
são
essenciais
em
programas
ofuscados
para
detectar
e
corrigir
eventuais
falhas
que
foram
geradas
pelo
próprio
processo.
A
relação
custo
x
benefício
deve
ser
analisada
com
bastante
critério
pelo
analista
desenvolvedor
juntamente
com
o
time
de
performance
para
que
os
custos
adicionais
incluídos
por
ventura
do
ofuscamento
não
sejam
proibitivos
do
ponto
de
vista
computacional.
Se
no
código
do
programa
existam
segredos,
tecnologias
inovadoras,
algoritmos
inéditos
ou
aperfeiçoados
a
utilização
das
técnicas
aqui
apresentadas
é
uma
boa
sugestão
para
proteção
desse
software.
Referências
1.
Acordo
sobre
Aspectos
dos
Direitos
de
Propriedade
Intelectual
Relacionados
ao
Comercio
Trade-Related
Aspects
of
Intelectual
Property
Rights.
Tratado
internacional,
integrante
do
conjunto
de
acordos
assinados
em
1994
que
culminou
na
criação
a
Organização
Mundial
do
Comércio
(WTO).
2.
AHO,
Alfred
V.;
SETHI,
Ravi;
ULLMAN,
Jeffrey
D..
Compilers:
principles,
techniques,
and
tools.
2.
ed.
Boston:
Addison-wesley
Longman
Publishing,
2007.
1038
p.
3.
AIVOSTO.
Dead
code
detection
and
removal.
2016.
Disponível
em:
.
Acesso
em:
06
out.
2016.
4.
AKEMI,
Nim
Bus.,
-Virus.
VírusBrasil,
ed,
1.
Disponível
em:<
http://virusbrasil.8m.com/>.Acesso
em:
15
ago.
2016.
5.
ASCENSÃO,
José
de
Oliveira,
Direito
autoral.
2
ed.
ref.
e
ampl.
Rio
de
Janeiro:
Renovar,
1997.
p.
671
6.
ASETECHS
Consulting,
KRIS
applications
and
services
Disponível
em:<
http://asetechs.com/NewSite2016/Products/KRIS_Solutions.htm>.Acesso
em:
20
ago.
2016.
7.
AYRES,
Robert
U.
º
57,jul.set
1987.
8.
,
Paris,
Dalloz,
1993,
p.
290.
9.
BOAZ
Barak,
Oded
Goldreich,
Russell
Impagliazzo,
Steven
Rudich,
Amit
Sahai,
Salil
Vadhan,
Ke
Yang,
On
the
(Im)possibility
of
Obfuscating
Programs,
Advances
in
Cryptology
Computer
Science
vol.
2139,
pp.
1-18,
Santa
Barbara,
CA,
November
2001
10.BOCCARDO,
Davidson
Rodrigo
;
MACHADO,
Raphael
Carlos
Santos
;
CARMO,
Luiz
Fernando
Rust
da
Costa.
Transformações
de
código
para
proteção
de
software.
In:
SIMPÓSIO
BRASILEIRO
EM
SEGURANÇA
DA
INFROMAÇÃO
E
DE
SISTEMAS
COMPUTACIONAIS,
10.,
2010,
Fortaleza.
Anais...
Fortaleza:
Universidade
Estadual
do
Ceará,
Universidade
Federal
do
Ceará,2010.
Disponível
em:
http://www.insert.uece.br/sbseg2010/anais/04_minicursos/minicurso_03.pdf
11.BODÍK,
Rastislav;
GUPTA,
Rajiv.
Partial
dead
code
elimination
using
slicing
transformations.
In:
ACM
SIGPLAN
1997
CONFERENCE
ON
PROGRAMMING
LANGUAGE
DESIGN
AND
IMPLEMENTATION,
97.,
1997,
New
York.
Conference.
New
York:
Acm,
1997.
v.
32,
p.
159
-170.
12.BRASIL.
Lei
nº
10.196,
de
14
de
fevereiro
de
2001
-Altera
e
acresce
dispositivos
à
Lei
n°
9.279,
de
14
de
maio
de
1996,
que
regula
direitos
e
obrigações
relativos
à
propriedade
industrial,
e
dá
outras
providências..
Diário
Oficial
da
União.
Brasília,
DF,
16
fev.
2001.
Seção
1,
p.
4.
13.BRASIL.
Lei
nº
9.609,
de
19
de
fevereiro
de
1998
-Dispõe
sobre
a
proteção
da
propriedade
intelectual
de
programa
de
computador,
sua
comercialização
no
País,
e
dá
outras
providências..
Diário
Oficial
da
União.
Brasília,
DF,
20
jan.
1998.
Seção
1,
p.
1.
14.BRASIL.
Lei
nº
7646,
de
18
de
janeiro
de
1987.
Dispõe
quanto
à
proteção
da
propriedade
intelectual
sobre
programas
de
computador
e
sua
comercialização
no
País
e
dá
outras
providências..
Diário
Oficial
da
União.
Brasília,
DF,
22
jan.
1987.
Seção
1,
p.
22221.
15.Ca
Tecnologies,
Product
Sheet:
CA
Optimizer®/II
r8.5
Disponível
em:
.
Acesso
em:
25
ago.
2016.
16.COHEN
F.
.
theory
and
experiments".
In:
IFIP-TC11,
Computers
and
Security,
pages
22
35,
1987.
17.
Current
trends
in
computer
viruses".
In:
International
Symposium
on
Information
Security,
1991.
18.
C
Operating
system
protection
through
program
evolution".
Computer
Security,
12(6):565
584,
1993.
19.
A
short
course
on
computer
viruses"(2nd
ed.).
John
Wiley
&
Sons,
Inc.,New
York,
1994.
20.COLLBERG,
C.;
THOMBORSON,
C.;
Low,
D.
.
ing
transformations".
Technical
Report
148,
Department
of
Computer
Science,
The
University
of
Auckland,
New
Zealand,
July
1997.
21.COLLBERG,
C.;
THOMBORSON,
C;
Low,
D.
.
In:
ACM
SIGPLAN-SIGACT
Sym
posium
on
Principles
of
Progra
uary
1998.
22.COLLBERG,
C.;
THOMBORSON,
C;
Low,
D..
In:
Proc.
1998
IEEE
International
Conference
on
Computer
Languages,
pages
28
38.
23.COLLBERG,
C.,THOMBORSON,
C.
and
dynamic
embeddings",
In:
Principles
of
Programming
Languages
1999,
24.COLLBERG
C.;
THOMBORSON
C.
-proofing,
and
obfuscation
tools
for
software
protection
hnical
Report
TR00-03,
The
Department
of
Computer
Science,
University
of
Arizona,
February
2000.
25.COLLBERG
Christian
S.,
THOMBORSON
Clark.
Watermarking,
tamperproofing,
and
obfuscation
-tools
for
software
protection.
In
IEEE
Transactions
on
Software
Engineering,
volume
28,
pages
735
746,
August
2002.
26.COMUNIDADE
ECONÓMICA
EUROPEIA.
Diretiva
nº
250,
de
14
de
janeiro
de
1991.
Relativa
à
protecção
jurídica
dos
programas
de
computador.
Conselho
das
Comunidades
Europeias.
Bruxelas,
14
jan.
1991.
27.DRAGONI,
Matteo,
al
Dilemma
.
Tese
de
obtenção
de
título
de
pós
doutorado,
Universidade
de
Macerata,
Departamento
de
Jurisprudência,
2014.
28.FERREIRA,
Aurélio
Buarque
de
Holanda.
Novo
Dicionário
Eletrônico
Aurélio.
Curitiba:
Positivo,
2010.
CD-ROM.
29.FETRIM,
Valéria
Delisandra.
Apoio
à
Documentação
de
Engenharia
Reversa
de
Software
por
Meio
de
Hipertextos,
Dissertação
de
Mestrado,
USP-São
Carlos,
1999.
30.GORDON,
Yefin.;
Rigmant
Vladimir.
Tupolev
Tu-4:
Soviet
Superfortress,
Midland
Publishing
Limited,
2002.
31.IBM.
CICS
Transaction
Server.
Disponível
em:
.
Acesso
em:
03
set.
2016.
32.INFO
WORLD.
São
Francisco:
Idg
-International
Data
Group,
v.
14,
n.
49,
7
dez.
1992.
33.LYNN,
B.,
M.
Prabhakaran
and
A.
Sahai,
Positive
results
and
techniques
for
obfuscation,
Computer
Science
(2004),
pp.
20
39.
34.MANTOAN,
Fernando.
Simplicidade
de
Código.
2011.
Disponível
em:
.
Acesso
em:
25
jun.
2016.
35.MICROFOCUS.
Transforming
the
Elephant
in
the
Room:
a
Mainframe
Story.
Disponível
em:
.
Acesso
em:
05
jun.
2016.
36.MODERN
SYSTEMS.
What
They
Seem.
Disponível
em
<
http://modernsystems.com/cobol-codeassessment-
things-arent-always-what-they-seem/
Acesso
em
05
out.
2016.
37.MURTA
FILHO,
Antonio.
Aspectos
Penais
Inovadores
da
Recente
Lei
9.609,
de
19.2.98.
In
Revista
da
ABPI,
No.
29,
Jul-Ago
1997.
p.
29-33
38.ORGANIZAÇÃO
MUNDIAL
DA
PROPRIEDADE
INTELECTUAL.
Acordo
de
Direitos
Autorais,
20
dezembro
1996.
Disponível
em:
.
Acesso
em:
27
jun.
2016.
39.PENTEADO,
Rosângela.
Engenharia
reversa
e
reengenharia.
01
mar.
2009,
01
jul.
2009.
18
p.
USFCar,
Notas
de
Aula.
40.PEREIRA
DOS
SANTOS,
Manoel.
A
Nova
Lei
de
Software
-aspectos
controvertidos
da
protecão
autoral,
In
Revista
da
ABPI,
No.
29,
Jul-Ago
1997.
p.
29-33
41.PEREIRA
DOS
SANTOS,
Manoel.
Licença
de
Software.
In
Revista
da
ABPI,
No.
25,
Nov-Dez
1996,
p.
39-46
42.Semantic
Designs,
COBOL
CloneDR.
Disponível
em:
http://www.semanticdesigns.com/Products/CloneDR/COBOLCloneDR.html?
Home=COBOLTools>.
Acesso
em:
15
jul.
2016.
43.SICSÚ,
Abraham
Benzaquen.
Em:
Abraham
Benzaquen
SICSÚ
,
Orgs.,
Política
Científica
e
Tecnológica:
no
Japão,
Coréia
do
Sul
e
Israel.
1989,
CETEM
/
CNPq,
Rio
de
Janeiro.
44.SOMEKAWA,
Daniel
Marques.
Ofuscamento
de
Código
para
Proteção
de
Programas
Java
contra
Engenharia
Reversa,
Monografia
de
especialização,
Universidade
Tecnológia
Federal
do
Paraná,
2012.
45.ULMER
E,
KOLLE
G,
"Copyright
Protection
of
Computer
Software",
Syracuse
Journal
of
International
Law
and
Commerce,
Vol.
14,
No
2,
1983.
46.VIVANT
Michel,
"Software
Protection",
International
Forum
for
the
Union
of
the
Mediterranean
and
the
Challenges
of
Information
Technology
(IFUMCIT),
Egito,
19.11.2009
47.VENKATESAN,
Ashwini,
"Code
Obfuscation
and
Virus
Detection",
Tese
de
obtenção
de
título
de
mestre,
Department
of
Computer
Science,
San
Jose
State
University,
2008
48.
Linguagem
de
Programação
COBOL
para
,
2ª
ed.,
Rio
de
Janeiro,
Ciência
Moderna.,
2010.
49.WROBLEWSKI,
Gregory,
neral
Method
of
Program
Code
Obfusca-
Tese
de
obtenção
de
título
de
pós
doutorado,
Wroclaw
University
of
technology,
Institute
of
Engineering
Cybernetics,
2002.
50.WU,
Zhenyu;
GIANVECCHIO,
Steven;
XIE,
Mengjun.
Mimimorphism:
a
new
approach
to
binary
code
obfuscation.
In:
CCS
'10
PROCEEDINGS
OF
THE
17TH
ACM
CONFERENCE
ON
COMPUTER
AND
COMMUNICATIONS
SECURITY,
17.,
2010,
Nova
Iorque.
Nova
Iorque:
ACM,
2010.
p.
536
-546.
51.ZAYTSEV,
Vadim
V..
A
Different
Perspective
on
Code
Obfuscation.
In:
WORKSHOP
ON
LANGUAGE
DESCRIPTIONS,
TOOLS,
AND
APPLICATIONS
(
)
2005,
Edinburgh,
Scotland,
Uk.
Artigo
para
apreciação.
Universidade
de
Amsterdam,
2005.
p.
1
-12.
Anexo
A
Folheto
de
divulgação
software
de
ofuscamento
Apêndice
A
-Código
fonte
programa
COBOL
HELLO
sem
ofuscamento
Programa
de
Hello
World
em
COBOL
da
figura
5:
Apêndice
B
-Código
fonte
programa
COBOL
HELLO
ofuscado
Programa
Hello
Ofuscado
da
figura
6:
Apêndice C - Código fonte programa TABUADA sem ofuscamento
Apêndice D - Código fonte programa TABUADA ofuscado
Apêndice
E
Execução
do
programa
TABUADA
Figura
7
-Execução
do
programa
TABUADA
