Você está na página 1de 63

UNIVERSIDADE FEDERAL DO PARÁ

INSTITUTO DE TECNOLOGIA
FACULDADE DE ENGENHARIA DA COMPUTAÇÃO E TELECOMUNICAÇÕES

DESENVOLVIMENTO DE UM SISTEMA DE ANÁLISE DE IMAGENS APLICADO


À PRÁTICA FORENSE

Felipe Farias Ozela

BELÉM - PARÁ
2013
ii

UNIVERSIDADE FEDERAL DO PARÁ


INSTITUTO DE TECNOLOGIA
FACULDADE DE ENGENHARIA DA COMPUTAÇÃO E TELECOMUNICAÇÕES

Felipe Farias Ozela

DESENVOLVIMENTO DE UM SISTEMA DE ANÁLISE DE IMAGENS APLICADO


À PRÁTICA FORENSE

Trabalho de Conclusão de Curso apresentado como re-


quisito parcial para obtenção do grau de Bacharel em En-
genharia da Computação da Faculdade de Engenharia da
Computação e Telecomunicações do Instituto de Tecno-
logia da Universidade Federal do Pará.
Orientador: Prof. Dr. Ronaldo de Freitas Zampolo.

BELÉM - PARÁ
2013
iii

DESENVOLVIMENTO DE UM SISTEMA DE ANÁLISE DE IMAGENS APLICADO


À PRÁTICA FORENSE

Este trabalho foi julgado adequado em para a obtenção do Grau de Enge-


nheiro da Computação, aprovado em sua forma pela banca examinadora que atribuiu o conceito
.

Prof. Dr. Ronaldo de Freitas Zampolo

ORIENTADOR

Prof. Dr. Adalbery Rodrigues Castro

Universidade Federal do Pará

Prof. MSc. Fábio Manoel França Lobato

Universidade da Amazônia

Prof. MSc. Rafael Oliveira Chaves

Universidade Federal do Pará

Prof. Dr. Ádamo Lima de Santana

DIRETOR DA FACULDADE
iv

“Agradeço todas as dificuldades que enfrentei;


não fosse por elas, eu não teria saı́do do lugar.
As facilidades nos impedem de caminhar.
Mesmo as crı́ticas nos auxiliam muito.”

Chico Xavier
v

Dedico este TCC à todos os que de alguma forma me


ofereceram a oportunidade de escrevê-lo, em
especial à minha famı́lia e namorada.
vi

Agradecimentos
Agradeço ao meu pai e a minha mãe, Paulo Ozela e Rosângela Farias, que me proporcio-
naram o dom da vida e, não só investiram em minha educação formal, como também me deram
a melhor forma de educação: a familiar.

Agradeço aos meus irmãos, Priscilla, Rodrigo e Paulo Vitor por estarem sempre ao meu
lado, sendo meu porto seguro, dando apoio e carinho.

À minha namorada, amiga e companheira, Marina Campos, por me dar amor, afeto, ca-
rinho, atenção e compreensão. Agradeço pelo apoio incondicional nesta vida, tanto pessoal,
como acadêmica, por sempre acreditar em mim, não me deixando desistir das coisas que são
mais importantes, por me ensinar a ter cada vez mais serenidade, por me fazer cada dia mais
apaixonado e seguro de nosso amor.

Aos meus avós, tios, primos e amigos por todos os momentos que passamos juntos. Prin-
cipalmente aos meus tios: Rosivaldo, Rosinaldo e Rosiwagner por terem colaborado com o meu
interesse pela computação, o que veio a se tornar minha profissão desde cedo.

Ao meu orientador, Professor Ronaldo Zampolo, por ter se dedicado durante todo o pro-
cesso de desenvolvimento deste trabalho. Agradeço pela confiança, paciência, preocupação e
prestreza.

Ao amigo Robson Valente que sempre me ajudou com sua sabedoria, amizade e solici-
tude. Agradeço pelos muitos momentos de diversão, de estudos e por ter incentivado a não
desistir durante momentos difı́ceis do curso.

Ao amigo Fábio Lobato pela amizade, por despertar meu interesse em Engenharia de
Software durante o meu primeiro estágio no LPRAD e pela experiência de vida passada no
inı́cio do curso.

À Katerinne por ter me dado atenção e sido esta grande amiga, incodicionalmente, pelos
últimos 12 anos de nossas vidas.

Aos colegas Hermeson Barbosa e Diego do Carmo, integrantes do projeto de extensão


Processamento Digital de Sinais Aplicado à Prática Forense: Verificação de Adulteração de
Provas Digitais e Assinatura de Sistemas de Aquisição de Imagem I e II, por terem me acolhido
e ajudado durante o desenvolvimento deste trabalho. Agradeço aos colegas de curso que, de
alguma forma, sempre me ajudaram a transpor os obstáculos da Engenharia.

Agradeço, também, à instuição UFPA que me proporcionou conhecimentos durante os


últimos anos de estudos.
vii

Sumário

Dedicatória v

Agradecimentos vi

Sumário vii

Lista de Figuras xi

Resumo xiv

Abstract xv

1 Introdução 1

1.1 Motivações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Metodologias e Materiais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3.1 Escolha do Modelo de Ciclo de Vida . . . . . . . . . . . . . . . . . . . 2

1.4 Fase de Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 Fase de Programação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.1 Linguagem de programação C++ . . . . . . . . . . . . . . . . . . . . 3

1.5.2 Framework Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5.3 Biblioteca OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4


viii

1.5.4 Ambiente de desenvolvimento Qt Creator . . . . . . . . . . . . . . . . 4

1.5.5 Doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.6 Organização do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 A Computação Forense 6

2.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Definições de Computação Forense . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 O Crime na Era Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3.1 Crimes cometidos com o uso de equipamentos computacionais . . . . . 8

2.4 A Legislação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 Pedofilia, a Exploração Sexual de Crianças e a Legislação . . . . . . . . . . . . 10

3 Engenharia de Software 12

3.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Conceitos em Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Engenharia de Software . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.2 Processos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.3 Modelo Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2.3.1 Modelo em Cascata . . . . . . . . . . . . . . . . . . . . . . 15

3.2.3.2 Modelo de Prototipagem . . . . . . . . . . . . . . . . . . . 15

3.3 Modelagem do Sistema Proposto . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 Análise de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1.1 Requisitos Não Funcionais . . . . . . . . . . . . . . . . . . 18

3.3.1.2 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . 19

3.3.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.2.1 Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 20


ix

3.3.2.2 Diagrama de Classes . . . . . . . . . . . . . . . . . . . . . . 23

3.3.3 Protótipos de Baixa Fidelidade . . . . . . . . . . . . . . . . . . . . . . 23

4 Linguagem de Programação, Framework e Bibliotecas 25

4.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2 Qt em Múltiplas Plataformas . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.2.1 Qt Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.2.2 Qt Quick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Biblioteca OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Biblioteca FFMPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.5 Biblioteca EasyEXIF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Resultado: SPID - Sistema de Perı́cias em Imagens Digitais 31

5.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2 Estrutura do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.1 Modularização do Sistema . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.2 Estereótipo Entity-Control-Boundary . . . . . . . . . . . . . . . . . . 32

5.2.3 Bibliotecas Externas . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.3.1 OpenCV (Análise da imagem) . . . . . . . . . . . . . . . . 33

5.2.3.2 FFmpeg (Análise de vı́deo - Funcionalidade em pesquisa) . . 33

5.2.3.3 EasyEXIF . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3 Funcionamento Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.3.1 SPID - Detecção da Fonte via PRNU . . . . . . . . . . . . . . . . . . 35

5.3.2 SPID - Detecção de Adulterações . . . . . . . . . . . . . . . . . . . . 38

5.4 Documentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.4.1 Doxygen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
x

5.5 Licença SPID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.6 Plataformas Compiladas e Testadas . . . . . . . . . . . . . . . . . . . . . . . . 41

5.6.1 Linux Ubuntu 13.04 - 64 bits . . . . . . . . . . . . . . . . . . . . . . . 41

5.6.2 Microsoft Windows 7 Professional - 64 bits . . . . . . . . . . . . . . . 41

6 Considerações Finais 42

6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Referências Bibliográficas 44

Apêndice A 46
xi

Lista de Figuras

2.1 Crime onde o computador é utilizado como ferramenta de apoio. Fonte: (ELEU-
TERIO; MACHADO, 2011b) . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Crime onde o computador é utilizado como meio para a realização do crime.
Fonte (ELEUTERIO; MACHADO, 2011b) . . . . . . . . . . . . . . . . . . . 9

3.1 Modelo Cascata e Prototipagem - Inspiração para Modelo Espiral - Fonte: (PRES-
SMAN, 2006a) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Modelo Espiral. Fonte: (PRESSMAN, 2006a) . . . . . . . . . . . . . . . . . . 17

3.3 Diagrama de Casos de Uso do sistema em desenvolvimento. . . . . . . . . . . 21

3.4 Protótipo da janela principal do Sistema de Perı́cia em Imagens Digitais. . . . . 24

3.5 Protótipo da janela Análise via PRNU - Sistema de Perı́cia em Imagens Digitais. 24

4.1 Qt Designer pronto para iniciar o desenvolvimento de uma interface de usuário 26

4.2 Interface de desenvolvimento Qt Quick . . . . . . . . . . . . . . . . . . . . . . 28

4.3 Exemplo de GUI em QML usando o Qt Quick. Fonte: http://www.nokiatividade.com/ 28

5.1 Organização das classes do SPID seguindo o padrão Entity-Control-Boundary. . 32

5.2 Interface gráfica inicial com destaque para a exibição de informações EXIF. . . 34

5.3 Interface gráfica inicial do SPID - GUI simples e facilmente usável. . . . . . . 35

5.4 Processo de estimação da PRNU a partir de imagens obtidas pela câmera sus-
peita. Fonte: (ZAMPOLO et al., 2011) . . . . . . . . . . . . . . . . . . . . . . 36
xii

5.5 Análise e identificação de câmera: imagem suspeita é processada e comparada


com a PRNU estimada. Fonte: (ZAMPOLO et al., 2011) . . . . . . . . . . . . 36

5.6 SPID - Detecção da Fonte via PRNU. . . . . . . . . . . . . . . . . . . . . . . 37

5.7 SPID - Detecção da Fonte via PRNU - Estimar PRNU. . . . . . . . . . . . . . 38

5.8 SPID - Detecção da Fonte via PRNU - Salvar PRNU. . . . . . . . . . . . . . . 38

5.9 SPID - Detecção de Adulterações. Imagem adulterada. . . . . . . . . . . . . . 39

5.10 SPID - Detecção de Adulterações. Imagem autêntica. . . . . . . . . . . . . . . 40

5.11 Declaração de licença LGPL na classe da janela principal do SPID . . . . . . . 41


xiii

Lista de Siglas

CASE Computer-Aided Software Engineering


CCD Charge-Coupled Device
CPCRC Centro de Perı́cias Cientı́ficas Renato Chaves
CCD Charge-Coupled Device
CPP Código de Processo Penal
CUDA Compute Unified Device Architecture
EXIF Exchangeable Image File Format
GUI Graphical User Interface
GPS Global Positioning System
GPU Graphics Processing Unit
IC Instituto de Criminalı́stica
LGPL Lesser General Public License
P2P Peer-to-peer
SPID Sistema de Perı́cias em Imagens Digitais
PRNU Photo Response Non-Uniformity
UML Unified Modeling Language
WWW World Wide Web
WYSIWYG What-You-See-Is-What-You-Get
xiv

Resumo

Este trabalho tem como objetivo apresentar a modelagem e o desenvolvimento de um sis-


tema de análise de imagens aplicado à prática forense por meio de verificações de informações
acerca da procedência e de eventuais adulterações de imagens digitais colocadas à prova, bem
como mostrar alguns embasamentos legais importantes a se consider ao longo de seu desenvol-
vimento.

Para o devido desenvolvimento deste sistema, faz-se fundamental a utilização de con-


ceitos de engenharia de software, sendo assim necessário um Processo de Software antes e
durante o desenvolvimento do sistema. Com isso, será possı́vel demonstrar o desenvolvimento
de um software, analisando os variados estágios da engenharia que estão envolvidos no pro-
cesso. Utilizaram-se diversas bibliotecas para a criação do sistema proposto. Para a criação da
interface visual foi utilizada a linguagem de programação C++ em conjunto com o framework
Qt.

Palavras-Chave: Engenharia de Software, Forense, UML, C++, QT, OpenCV, EXIF, Imagens
Digitais.
xv

Abstract

This work has as objective to present the modeling and development process of a system
for image analysis applied to forensic practice through verifications of information about the
origin and possible tampering of digital images put to the test, as well as to show some important
legal emplacements to consider during its creation.

For proper development of this system, it is essential to use software engineering con-
cepts, it is necessary a Process of Software before and during the course of building the system.
With it, demonstrating the development of a software, analyzing the various stages of engine-
ering that are involved in the process. Several libraries were used for building the proposed
system. To create the visual interface it was used C++ programming language with the Qt
framework.

Keywords: Software Engineering, Forensics, UML, C++, Qt, OpenCV, EXIF.


1

Capı́tulo 1

Introdução

1.1 Motivações

Com o aumento e a popularização de dispositivos eletrônicos, tais como câmeras digitais


- tanto fotográficas, como de vı́deo - crimes em que tais equipamentos estão associados também
cresceram. Por isto, a demanda por laudos periciais neste tipo de dispositivo aumentou (ZAM-
POLO et al., 2011). Os crimes relacionados à informática são variados e o Núcleo de Fonética
Forense dos Institutos de Criminalı́stica (IC) é a melhor indicada para averiguá-los. Assim,
verifica-se frequentemente que este Núcleo tem uma grande fila de perı́cias a serem realizadas
com prazos curtos a serem cumpridos.

Sabendo disto, este trabalho se aprofundou no problema enfrentado pelos IC’s e as medi-
das cabı́veis. A partir de então, verificou-se a possibilidade da modelagem e desenvolvimento
de uma solução de software que auxilie à prática forense nestes Institutos.

1.2 Objetivos

Este trabalho visa modelar e desenvolver um sistema de análise de imagens aplicado à


prática forense. Tal sistema deverá realizar testes e verificações de modo a obter informações
acerca da procedência e de eventuais adulterações de imagens digitais colocadas em prova
utilizando-se de técnicas desenvolvidas pelos projetos de extensão: Processamento Digital de
Sinais Aplicado à Prática Forense: Verificação de Adulteração de Provas Digitais e Assinatura
2

de Sistemas de Aquisição de Imagem I e II.

1.3 Metodologias e Materiais

Utilizaram-se conceitos de Engenharia de Software para a modelagem do sistema e na


criação do programa de computador em questão. Estes conceitos foram empregados visando
obter uma melhor organização e padronização do sistema.

1.3.1 Escolha do Modelo de Ciclo de Vida

A escolha de um modelo de ciclo de vida, também chamado de modelo de processo, é o


ponto de partida para a definição de um processo de desenvolvimento de software. Um modelo
de ciclo de vida organiza as macro-atividades básicas necessárias para o desenvolvimento de
um sistema, estabelecendo precedência e dependência entre as mesmas.

Têm-se modelos genéricos que podem ser usados com diferentes formas de abordagens
de desenvolvimento. Entre eles, destacam-se: Modelo em Cascata, Desenvolvimento Evolutivo
e Modelo de Processo Incremental. Sendo o Modelo em Cascata um dos primeiros modelos a
ser usado em Engenharia de Software.

O Modelo Espiral foi utilizado como padrão para o desenvolvimento do software neste
projeto. Por ser um modelo evolutivo, iterativo com prototipação, possuir estimativas e possi-
bilitar um controle de riscos a cada etapa, por isto acabou sendo naturalmente escolhido para a
implementação do sistema.

Mais sobre o Modelo Espiral será abordado no capı́tulo 3 deste trabalho, bem como o
Processo de Software.

1.4 Fase de Modelagem

Durante a fase de modelagem do sistema proposto, utilizaram-se de diversos recursos de


modo a documentar o mesmo.

A UML - Unified Modeling Language ou Linguagem de Modelagem Unificada - é uma


3

linguagem visual utilizada para modelar softwares que pode ser aplicada à todos os domı́nios
de aplicação.

Ferramentas CASE, do inglês “Computer-Aided Software Engineering”, que é uma classificação


abrangendo todas as ferramentas baseadas em computadores que auxiliam atividades de Enge-
nharia de Software.

Astah Community, anteriormente denominado JUDE, Java and UML Developers Envi-
ronment (Ambiente para Desenvolvedores UML e Java), o Astah é um software para modela-
gem UML desenvolvido na plataforma Java, o que garante a portabilidade entre diversos siste-
mas operacionais que utilizam-se da máquina virtual Java. A ferramenta foi usada na fase de
modelagem mais avançada de diagramação de classes e casos de uso.

1.5 Fase de Programação

Na fase de programação, utilizaram-se ferramentas de desenvolvimento tais como:

1.5.1 Linguagem de programação C++

C++ é uma linguagem de programação multi-paradigma de uso geral. Esta linguagem é


considerada de médio nı́vel, visto que possui tanto caracterı́sticas de linguagens de alto nı́vel
como de baixo nı́vel. Desde os anos 1990 é uma das linguagens comerciais mais populares,
sendo bastante usada também na academia por seu grande desempenho e base de conhecimento.

1.5.2 Framework Qt

Qt é um framework multiplataforma para desenvolvimento em C++ criado pela divisão


da Nokia Qt Development Frameworks, da empresa Norueguesa Trolltech, sua desenvolvedora
original. Com ele é possı́vel desenvolver aplicativos e bibliotecas uma única vez e compilá-los
para plataformas variadas sem que seja necessário alterar o código fonte.

Atualmente, este framework é mantido pelo Qt Project, uma iniciativa de software li-
vre, envolvendo desenvolvedores individuais e provenientes de empresas como Nokia, Digia, e
outras.
4

1.5.3 Biblioteca OpenCV

OpenCV (Open Source Computer Vision) é um conjunto de bibliotecas projetado para a


eficiência computacional e com um forte foco em aplicações em tempo real. O OpenCV possui
módulos de processamento de imagens e vı́deo (tanto de entrada, como de saı́da), estrutura
de dados, álgebra linear, GUI (Graphical User Interface, ou Interface Gráfica do Usuário, em
tradução livre) básica com sistema de janelas independentes, controle de mouse e teclado, além
de mais de 350 algorı́tmos de visão computacional como: filtros de imagem, calibração de
câmera, reconhecimento de objetos, análise estrutural e outros.

É uma biblioteca multiplataforma, sendo possı́vel de se utilizar, atualmente, em C/C++,


Java, Python e Visual Basic.

1.5.4 Ambiente de desenvolvimento Qt Creator

Qt Creator é uma ferramenta CASE utilizada para o desenvolvimento de interface de


usuário no framework Qt. Nela estão contidos o Qt Designer e Qt Quick, ferramentas para
criação de GUI, melhor explicadas nas seções 4.2.1 e 4.2.2

1.5.5 Doxygen

É uma ferramenta para documentação de softwares baseada nos comentários do código-


fonte.

1.6 Organização do Texto

O restante deste documento está dividido em capı́tulos seguindo o ordenamento abaixo:

• Capı́tulo 2: Analisa os aspectos forenses que devem servir de arcabouço e razões para o
desenvolvimento do software, bem como metodologias forenses aplicadas no processo.

• Capı́tulo 3: Define as informações obtidas acerca dos requisitos necessários ao software


e apresenta a modelagem do sistema.
5

• Capı́tulo 4: Apresenta a linguagem C++, Qt development framework e as bibliotecas


usadas no sistema.

• Capı́tulo 5: Demonstra o Sistema de Perı́cias em Imagens Digitais e seus resultados.

• Capı́tulo 6: Dispõe de considerações finais acerca deste documento e opções de trabalhos


futuros.
6

Capı́tulo 2

A Computação Forense

2.1 Introdução

Com o rápido desenvolvimento dos computadores, não tardou para que esses disposi-
tivos estivessem presentes em várias áreas desempenhadas pelo ser humano. Com tamanha
divulgação e popularização, os computadores estão presentes em várias esferas da vida humana,
seja nas empresas, nas casas, nos carros ou nas mãos das pessoas na forma de smartphones, ta-
blets, câmeras digitais, GPS1 , etc.

Assim como em qualquer outro campo de estudo, as inovações tecnológicas trazem uma
série de benefı́cios para as pessoas e a comunidade. Entretanto, também trazem consigo a
possibilidade de realização de práticas ilegais e criminosas.

2.2 Definições de Computação Forense

“Perı́cia Forense em Sistemas Computacionais é o processo de coleta, recuperação, análise


e correlacionamento de dados que visa, dentro do possı́vel, reconstruir o curso das ações e re-
criar cenários completos fidedignos.” (COSTA, 2003)

A palavra forense vem de foro, e podemos entender como meio policial onde é feita
uma análise minuciosa de todo material capturado em cena de crime. Computação forense é

1
Global Positioning System, ou Sistema de Posicionamento Global, em português.
7

então o ramo da criminalı́stica que compreende a descoberta, preservação, restauração e análise


de evidências computacionais. Computadores podem ser usados para cometer crimes, como,
por exemplo, aliciamento de menores; Podem ainda conter evidências de crimes, como dados
de contas bancárias fraudadas, ou ainda ser alvos de crimes, quando armazenam informações
sigilosas de grandes instituições (BULLE, 2008).

2.3 O Crime na Era Digital

É comum se dizer que “crimes sempre deixam vestı́gios!”. Segundo o dicionário Micha-
elis da Lı́ngua Portuguesa, vestı́gio é definido como:

“1 Sinal deixado pela pisada ou passagem, tanto do homem como de qualquer


outro animal; pegada, rasto. 2 Indı́cio ou sinal de coisa que sucedeu, de pessoa
que passou. 3 Ratos, resquı́cios, ruı́nas. Seguir os vestı́gios de alguém: fazer o que
ele fez ou faz; imitá-lo.”

Na computação, estes vestı́gios de crimes são digitais, uma vez que toda a informação
armazenada dentro de equipamentos computacionais é composta por bits (números zeros e uns),
em uma sequência lógica.

O Código de Processo Penal (CPP) determina em seu artigo 158 que: “Quando a infração
deixar vestı́gios, será indispensável o exame de corpo de delito, direto ou indireto, não podendo
supri-lo a confissão do acusado”. Dessa forma, surge a necessidade de um profissional qualifi-
cado, que examine vestı́gios e produza laudos de interesse à justiça na apuração de um delito,
conforme definidos nos caputs dos artigos 159 e 160 do CPP, que dizem, respectivamente:
“O exame de corpo de delito e outras perı́cias serão realizados por perito oficial, portador de
diploma de curso superior” e “Os peritos elaborarão o laudo pericial, no qual descreverão mi-
nuciosamente o que examinarem e responderão aos quesitos formulados”.

No caso da computação, quem realiza esse trabalho de forma oficial no âmbito crimi-
nal é o Perito Criminal em Informática. Entretanto, diversos outros profissionais podem ter a
necessidade de realizar exames em computação. São eles: peritos particulares, auditores de
sistemas, profissionais de TI e outros. Além disso, juı́zes, advogados, delegados, promotores
e demais profissionais da área de direito também devem conhecer como evidências e provas
8

digitais devem ser corretamente coletadas, apuradas e apresentadas.

Assim, a Computação Forense objetiva determinar a dinâmica, a materialidade e autoria


de ilı́citos ligados à àrea da informação, questionando principalmente a identificação e o pro-
cessamento de evidências digitais em provas materiais de crimes, através de métodos técnico-
cientı́ficos, conferindo-lhe validade probatória em juı́zo (ELEUTERIO; MACHADO, 2011b).

2.3.1 Crimes cometidos com o uso de equipamentos computacionais

Faz-se importante diferenciar se o equipamento é utilizado apenas como ferrramenta de


apoio à prática forense de delitos convencionais ou se é utilizado como meio para realização do
crime.

Nos crimes em que equipamentos computacionais são utilizados como ferramenta de


apoio aos crimes convencionais, o computador serve apenas de ferramenta para auxı́lio aos
criminosos na prática de crimes já conhecidos, como sonegação fiscal, compra de votos em
eleições, tráfico de entorpecentes, falsificação de documentos e outros. Na Figura 2.1, pode-
se notar a figura do criminoso utilizando-se do computador de modo forjar documentos para
utilizar, por exemplo, em uma instituição bancária.

Figura 2.1: Crime onde o computador é utilizado como ferramenta de apoio. Fonte: (ELEUTERIO;
MACHADO, 2011b)

Nos crimes em que equipamentos computacionais são utilizados como meio para sua
realização, o computador é a peça central para a ocorrência do delito, ou seja, se este dispositivo
não existisse, tal delito não poderia ser praticado. Diferindo da modalidade anterior, em que
crimes convencionais são tipificados, novas maneiras de cometer um delito surgem devido ao
mau uso do computador e da internet. Dentre elas, podem-se citar: ataques a sites, roubo de
9

informações, phishing2 , programas maliciosos para roubo de senhas e outros.

Se um cracker3 , em sua casa, desviar dinheiro de uma conta bancária a partir de acesso
não autorizado a um Internet Banking, o computador exerce o papel principal para o delito ser
cometido. Se ele não existisse, esse crime não poderia ser realizado dessa maneira. Na Figura
2.2, pode-se notar a figura de um cracker utilizando-se de um computador para acessar um
banco através de um computador.

Figura 2.2: Crime onde o computador é utilizado como meio para a realização do crime. Fonte (ELEU-
TERIO; MACHADO, 2011b)

2.4 A Legislação

O Código de Processo Civil pátrio estabelece em seu artigo 332:

“Todos os meios legais, bem como os moralmente legı́timos, ainda que não especi-
ficados neste Código, são hábeis para provar a verdade dos fatos, em que se funda
a ação ou a defesa.”

Pode-se constatar que a informação digital não é, em si, ilegal, tampouco ilegı́tima. Ela
contém condições técnicas que lhe garantem eficácia probatória. Além disso, cresce diariamente
o número de informações digitais disponı́veis, dada a quantidade de benefı́cios que podem tra-
zer, como: menor custo, maior agilidade, maior disponibilidade, melhor manuseio e segurança.
Daı́, verificam-se cada vez mais evidências eletrônicas.
2
Forma de fraude eletrônica, caracterizada por tentativas de adquirir dados pessoais de diversos tipos; senhas,
dados financeiros como número de cartões de crédito e outros dados pessoais.
3
Vândalo virtual que usa seus conhecimentos para invadir sistemas, quebrar travas, senhas e roubar dados
(MORIMOTO, 2005).
10

Isso não significa que uma informação digital não possa ser obtida de forma ilegal. No
caso de uma interceptação telefônica não autorizada, por exemplo, esse material teria seu valor
como elemento de prova descartado. Devido a fatores como esse, a investigação da Computação
Forense deve levar em conta algumas considerações, a saber:

• Toda busca e análise de evidências deve ser feita por meio de autorização judicial, caso
contrário o trabalho perderá sua validade;

• Toda a prova avaliada não pode sofrer nenhum tipo de alteração durante sua análise por
peritos, por isso é preferı́vel criar cópias dos dispositivos originais e realizar a análise
sobre as réplicas;

• Toda análise deve ter seu histórico de procedimentos formalmente descrito em um laudo
pericial, normalmente solicitado pelo delegado ou promotor de justiça. O perito é um
tradutor especializado de fatos que poderão auxiliar a decisão do processo, mas ele deve
ser alheio ao processo e aos resultados deste.

2.5 Pedofilia, a Exploração Sexual de Crianças e a Legislação

De acordo com Eleutério e Machado 2011a, um crime muito verificado na Computação


Forense é a exploração sexual de crianças, caracterizada pelo uso de equipamentos para produção,
visualização, edição, e divulgação de vı́deos ou imagens contendo pornografia infanto-juvenil
via internet.

Segundo Croce (1995), pedofilia pode ser definida como um “desvio sexual caracterizado
pela atração por crianças ou adolescentes sexualmente imaturos, com os quais os portadores dão
vazão ao erotismo pela prática de obscenidades ou de atos libidinosos”. Assim, pedofilia é um
desvio aplicado aos seres humanos e não deve ser confundido com pornografia infanto-juvenil.
Desta forma, não é correto dizer que um arquivo de vı́deo é pedófilo - esse é um erro bastante
popular na mı́dia e nos noticiários.

De acordo com Eleutério e Machado (2011a), a legislação brasileira não considerava


crime a posse de arquivos de pornografia envolvendo crianças ou adolescentes até 25 de no-
vembro de 2008. Apesar de o compartilhamento, a produção e a divulgação, entre outras ações,
já estarem contempladas pela legislação, a posse ainda não tinha previsão legal. Porém, isto
11

mudou com sua inclusão na lei 11.829, demostrando uma preocupação da sociedade com o
assunto e a mobilização do governo em combater esse tipo de delito.

A produção e propagação de conteúdo digital ilegal, especialmente imagens e vı́deos


envolvendo pornografia infanto-juvenil, tem crescido nos últimos tempos. Combinada com a
rápida evolução dos computadores e a popularização da internet, a produção e o consequente
compartilhamento de arquivos ilegais entre pessoas de todo mundo ocorre de maneira frequente,
principalmente por meio da World Wide Web (WWW), das redes peer-to-peer (P2P), de emails
e dos serviços de mensagens instantâneas, como Messenger e Skype, além da Deep Web4 .

Visando reprimir e desencorajar este crime, as polı́cias do mundo inteiro, incluindo a


Polı́cia Federal do Brasil, têm realizado uma série de operações, buscando a identificação de
pessoas que tenham compartilhado arquivos contendo pornografia infanto-juvenil por meio da
internet (ELEUTERIO; MACHADO, 2011b). Partindo desta identificação, faz-se possı́vel iden-
tificar também o produtor dos arquivos de imagens/vı́deos, bem como a identificação e posterior
recuperação psicológica da própria vı́tima (criança/adolescente). Esta identificação da fonte dos
arquivos é uma das possı́veis aplicações do sistema em desenvolvimento que será mostrado ao
longo deste trabalho.

4
Termo inicialmente cunhado por Mike Bergman que se refere ao conteúdo da World Wide Web que não faz
parte da Surface Web, a qual é indexada pelos mecanismos de busca padrão.
12

Capı́tulo 3

Engenharia de Software

3.1 Introdução

Neste capı́tulo, serão expostos os conceitos fundamentais sobre Engenharia de Software


e como ela pode ser aplicada visando uma organização do processo de desenvolvimento de
software.

3.2 Conceitos em Engenharia de Software

Software é um conjunto ou uma sequência de instruções projetadas por uma pessoa ou


empresa que tem um objetivo especı́fico (PRESSMAN, 2006a). Softwares são desenvolvidos
de acordo com linguagens de programação (C++, Java, PHP, entre outras) e funciona sobre uma
plataforma (Windows, Linux, Java Virtual Machine, etc).

3.2.1 Engenharia de Software

De acordo com Pressman (PRESSMAN, 2006a), Engenharia de Software é definida como:


“[...] um arcabouço que pode ser usado por aqueles que constroem software de computadores
[...] O arcabouço abrange um processo, um conjunto de métodos e ferramentas, que nós cha-
mamos de Engenharia de Software.

Para Somerville (2011):


13

“Engenharia de Software é a disciplina da engenharia que se ocupa de todos os


aspectos da produção de software, desde os estágios iniciais de especificação do
sistema até a manutenção desse sistema, depois que ele entrou em operação”.

O fato é que a Engenharia de Software existe desde o final da década de 1950 e tem como
objetivo melhorar o desenvolvimento de software, porém inicialmente ainda não se tinham os
modelos, técnicas e as ferramentas existentes hoje.

Ainda na década de 1950, verificou-se um grande avanço no hardware que não foi acom-
panhado pelos softwares produzidos naquela época. O desenvolvimento de software não conse-
guia acompanhar o desenvolvimento de hardware, por isto, até a década de 1980, a Engenharia
de Software passou pela chamada “crise do software”. Como falhas ocorridas nesta época,
podem-se citar:

• Projetos acima do orçamento;

• Atrasos na finalização do projeto;

• Softwares de baixa qualidade;

• Sistemas dificilmente manutenı́veis.

Visando solucionar estas dificuldades mencionadas anteriormente, foram desenvolvidas


técnicas, ferramentas e estratégias para produção de sistemas de software. Nos últimos 20 anos,
estas técnicas vem ficando cada vez melhores e mais eficientes. Podem-se destacar:

• A programação estruturada;

• A programação orientada a objetos;

• Ferramentas CASE;

• Documentação de software;

• Padrão de desenvolvimento de sistemas;

Com o avanço obtido ao longo dos anos, o processo de desenvolvimento de software se


tornou mais eficiente. Desta forma, mesmo os problemas continuando a existir, há a possibili-
dade de resolvê-los por meio de soluções existentes ou mesmo modificando-as de acordo com
a necessidade do sistema.
14

3.2.2 Processos de Software

De modo a criar um sistema, visando atender o prazo de conclusão e a qualidade esperada,


faz-se uso de uma sequência de passos que são conhecidos como “Processo de Software”.

De acordo com Pressman (2006b):

“Processo é um conjunto de atividades, ações e tarefas na criação de algum produto


de trabalho (work product). Uma atividade esforça-se para atingir um objetivo
amplo e é utilizada independente do campo de aplicação, do tamanho do projeto,
da complexidade de esforços ou do grau de rigor com que a engenharia de software
será aplicada. Uma ação envolve um conjunto de tarefas que resultam num artefato
de software fundamental. Uma tarefa se concentra em um objetivo pequeno, porém
bem definido”.

Pode-se dizer que Processo de Software é um modelo que pode ser adaptado à realidade
do projeto, assim, não é necessário ser seguido fielmente. Para que haja um processo de soft-
ware, é necessário o uso de uma metodologia (conjunto de atividades). Segundo Pressman
(PRESSMAN, 2006a), o seguinte arcabouço de processo genérico é aplicável à grande maioria
dos projetos de software:

1. Comunicação: abrange a comunicação e a colaboração com o cliente, abrange o levanta-


mento de requisitos e outras atividades relacionadas;

2. Planejamento: estabelece um plano para o trabalho de engenharia de software. Descreve


tarefas técnicas, os riscos prováveis, os recursos necessários, os produtos de trabalho a
serem produzidos e um cronograma de trabalho;

3. Modelagem: inclui a criação de modelos que permitam ao desenvolvedor e ao cliente


entender melhor os requisitos do software e o projeto que deverá satisfazê-los;

4. Construção: combina geração de código (manual ou automática) e os testes necessários


para revelar erros no código;

5. Implantação: o software é entregue ao cliente que avalia o produto e fornece o feedback


com base na avaliação.
15

Estas atividades genéricas de arcabouço podem ser usadas durante o desenvolvimento de


diversos tipos de sistemas de software. Os detalhes do processo serão muito diferentes em cada
caso, porém as atividades de arcabouço permanecem as mesmas.

3.2.3 Modelo Espiral

Para melhor entender o Modelo Espiral, faz-se interessante salientar aspectos nos quais
este se baseou. O Modelo Espiral, originalmente proposto por Boehm (BOEHM, 1988), é um
modelo evolucionário de Processo de Software que une os aspectos de controle e sistemático
do Modelo em Cascata com a Metodologia Iterativa da Prototipagem, unindo o que tem melhor
dos dois métodos.

3.2.3.1 Modelo em Cascata

O Modelo em Cascata, também chamado de ciclo de vida clássico, sugere uma abordagem
sistemática e sequencial para o desenvolvimento de softwares que começa com a especificação
dos requisitos pelo cliente e progride ao longo do planejamento, modelagem, construção e
implantação, culminando na manutenção progressiva do software acabado (PRESSMAN, 2006a).

Não seria recomendado o uso do Modelo em Cascata no sistema descrito neste trabalho,
pelas seguintes razões:

• Os requisitos podem sofrer alterações ao longo do projeto;

• Falta de maturidade no uso da linguagem de programação utilizada escolhida, o que pode


resultar em insegurança quanto ao funcionamento das funções;

• Não saber, inicialmente, como se dará a interação com o usuário do sistema.

3.2.3.2 Modelo de Prototipagem

É difı́cil para os usuários finais preverem como irão utilizar novos sistemas de software
para dar apoio ao seu trabalho diário. Se esses sistemas forem grandes e complexos demais,
deve ser impossı́vel fazer essa avaliação antes de o sistema ser construı́do e colocado em funci-
onamento (SOMMERVILLE, 2011).
16

Uma maneira de lidar com esta dificuldade é utilizar uma abordagem evolucionária para
o desenvolvimento do sistema. Ou seja, fornecer inicialmente um sistema incompleto e, a partir
disto, modificá-lo até que os requisitos do usuário se tornem claros.

(a) Modelo Cascata (b) Modelo de Prototipagem

Figura 3.1: Modelo Cascata e Prototipagem - Inspiração para Modelo Espiral - Fonte: (PRESSMAN,
2006a)

O Modelo Espiral fornece o potencial para o desenvolvimento rápido de versões mais


completas. Boehm (1988) descreve:

“O Modelo Espiral de desenvolvimento é um gerador de modelo de processo gui-


ado por risco usado para guiar a engenharia de sistemas intensivos em software
com vários interessados concorrentes. Ele tem duas principais caracterı́sticas dis-
tintas. A primeira é uma abordagem cı́clica, para aumentar incrementalmente o
grau de definição e implementação de um sistema enquanto diminui seu grau de
risco. A outra é um conjunto de marcos de ancoragem, para garantir o comprome-
timento dos interessados com soluções exequı́veis e mutuamente satisfatórias para
o sistema.”

Uma caracterı́stica importante deste modelo é que inclui o gerenciamento de risco, de


forma a diminuı́-los e controlá-los durante o desenvolvimento. Outras vantagens de se utilizá-
lo em relação ao Modelo em Cascata ou o Modelo Interativo, por exemplo, são: nem todos
os requisitos são previamente conhecidos, a inexperiência com a linguagem de programação
utilizada e não há como prever a interação com o usuário do sistema. Por estas razões, o
17

modelo espiral foi considerado interessante de se trabalhar para implementação do sistema em


desenvolvimento.

Uma idéia do funcionamento do Modelo Espiral pode ser visto na Figura 3.2. A partir
dela, é possı́vel constatar que o ciclo de vida de um projeto seguindo este modelo se inicia
no centro da espiral com a comunicação entre o solicitante do projeto e a equipe de desenvol-
vimento. Na segunda etapa, tem-se a fase de planejamento que compreende a estimativa do
projeto, cronograma e análise dos possı́veis riscos que possam comprometer o andamento do
desenvolvimento. Na terceira etapa é realizada a modelagem do sistema com a devida análise
do projeto. Em seguida, na quarta etapa, começa-se a construção do código e seus respectivos
testes. Após estes testes, na quinta etapa, tem-se a fase de implantação do sistema desenvolvido
e o retorno do solicitante sobre o sistema. Novas funcionalidades são implementadas seguindo a
mesma ordem de procedimentos de forma iterativa. É importante ressaltar que após o retorno do
solicitante, pode-se retornar para fases anteriores em caso de necessidade de ajustes no projeto.

Figura 3.2: Modelo Espiral. Fonte: (PRESSMAN, 2006a)

3.3 Modelagem do Sistema Proposto

Para desenvolver um software, se faz necessária uma análise bastante profunda dos requi-
sitos que o software deve possuir para viabilizar a passagem destas informações aos desenvol-
18

vedores.

3.3.1 Análise de Requisitos

A tarefa de coletar os dados para a criação de um sistema é bastante complexa, engana-


se quem pensa o contrário. Isto se dá, na maioria das vezes, pela falta de comunicação entre
desenvolvedor e cliente ou a falta de entendimento. Nesta seção serão apresentados os requisitos
do sistema proposto, desta forma, começando a dar “corpo” ao sistema.

Os requisitos foram obtidos por meio de reuniões entre equipe de desenvolvimento e um


representante do CPCRC após diversas demandas por perı́cias em imagens e vı́deos digitais.

O perito criminal foi indagado sobre as necessidades reais do dia-a-dia dos Institutos de
Criminalı́stica e a equipe de desenvolvimento sugeriu possı́veis opções de implementação em
software a partir de pesquisas realizadas pelo projeto de extensão Processamento Digital de
Sinais Aplicado à Prática Forense: Verificação de Adulteração de Provas Digitais e Assinatura
de Sistemas de Aquisição de Imagem I.

3.3.1.1 Requisitos Não Funcionais

Requisitos não funcionais são comportamentos que o sistema deve apresentar. Em geral,
estes se referem ao desempenho do sistema. De acordo com os requisitos não funcionais, o
sistema proposto deve conter:

• Usabilidade - Este sistema deve ser simples e intuitivo, apesar da complexidade de suas
funcionalidades internas;

• Agilidade - Deve realizar suas funções em máquinas comuns em um tempo aceitável;

• Robustez - O sistema deve cumprir com o solicitado, sem maiores travamentos;

• Permitir integração de futuras técnicas de análise de imagens/vı́deos digitais no âmbito


forense.
19

3.3.1.2 Requisitos Funcionais

Os requisitos funcionais para um sistema descrevem a função ou os serviços que o soli-


citante espera que o sistema forneça. Estes requisitos dependem do tipo de software que está
se desenvolvendo. Definem-se as funções como um conjunto de entradas, o comportamento
destas e suas saı́das. Dentre a lista de requisitos, pode-se inserir cálculos, detalhes técnicos,
manipulação de dados e de processamento, além de outras funcionalidades especı́ficas que de-
finem o que um sistema, idealmente, será capaz de realizar. Requisitos comportamentais, que
descrevem todos os casos em que o sistema utiliza os requisitos funcionais, são extraı́dos dos
casos de uso.

Como requisitos funcionais do sistema proposto, considerou-se:

• Inserir objetos (imagens) questionados como entrada;

• Selecionar métodos de avaliação do objeto questionado;

• Exibir metadados1 do objeto que podem conter indı́cios iniciais da fonte do objeto em
teste;

• Avaliar a não uniformidade da foto-resposta (PRNU) do sensor de aquisição de imagem


como recurso para identificação de dispositivo através de imagens em um diretório de
treinamento - mais sobre esta técnica será abordado na Seção 5.3.1;

- Permitir armazenamento de informações de PRNU para uso futuro;

- Confrontar PRNU com objetos questionados;

• Integrar ferramenta, previamente criada, para detecção de adulteração de fotografias di-


gitais por clonagem (MASUDA, 2012).

1
Exchangeable image file format (Exif). Especificação seguida por fabricantes de câmeras digitais que gravam
informações sobre as condições técnicas de captura da imagem junto ao arquivo da imagem propriamente dita na
forma de metadados etiquetados. A especificação usa os formatos de imagem JPEG, TIFF rev.6.0 e o formato de
áudio wave RIFF. O Exif não está suportado nos formatos JPEG 2000, PNG, GIF e BMP.
20

3.3.2 UML

A Unified Modeling Language (UML) ou Linguagem de Modelagem Unificada é uma


linguagem visual usada para modelar softwares baseados no paradigma da orientação a objetos.
É uma linguagem de modelagem de propósito geral que pode ser aplicada a todos os domı́nios
de aplicação. Essa linguagem tornou-se, nos últimos anos, a linguagem-padrão de modelagem
adotada internacionalmente pela indústria de Engenharia de Software (GUEDES, 2009).

A UML não é, porém, uma linguagem de programação, e sim uma linguagem de modela-
gem, uma notação, com o objetivo de auxiliar os engenheiros de software a definirem as carac-
terı́sticas do sistema, tais como seus requisitos, comportamento, estrutura lógica, a dinâmica de
seus processos e até mesmo suas necessidades fı́sicas em relação ao equipamento sobre o qual
o sistema será implementado. Estas definições podem ser feitas por meio da UML antes do
software começar a ser propriamente desenvolvido. Além disso, deve-se destacar que a UML
também não é um Processo de Software e tampouco está ligada a um exclusivamente, sendo
completamente independente, podendo ser utilizada por diversos processos de desenvolvimento
diferentes ou mesmo da forma que for considerada mais adequada.

3.3.2.1 Casos de Uso

O diagrama de casos de uso procura, através de uma linguagem simplificada, possibilitar a


compreensão do comportamento externo do sistema (em termos de funcionalidades oferecidas
por ele) por qualquer pessoa. Desta forma, ele tenta apresentar o sistema por meio de uma
perpectiva do usuário. É, entre todos os diagramas da UML, o mais abstrato e, portanto, o mais
flexı́vel e informal (GUEDES, 2009).

Este diagrama tem por objetivo apresentar a visão externa geral das funcionalidades
que o sistema deverá oferecer aos usuários, sem se preocupar com a questão de como tais
funções serão implementadas posteriormente no software. O diagrama de casos de uso é de
grande auxı́lio para a identificação e compreensão dos requisitos do sistema, possibilitando a
especificação, visualização e documentação das caracterı́sticas, funções e serviços desejáveis
pelo usuário do sistema. Ou seja, pode-se dizer que o diagrama de casos de uso, individu-
almente, descreve requisitos funcionais do sistema (como os descritos na seção 3.3.1.2 deste
trabalho). O diagrama de casos de uso do sistema proposto por este trabalho pode ser verificado
21

pela Figura 3.3.

Figura 3.3: Diagrama de Casos de Uso do sistema em desenvolvimento.

Caso de Uso Atores Descrição Pré-requisitos


Inserir Objeto Perito Permitir o carregamento de Não há
Questionado imagens no sistema
Selecionar Perito Possibilitar a seleção do Não há
Método de método de avaliação desejada
Avaliação
Avaliar via Perito Permite avaliar o objeto Selecionar Método de
PRNU inserido via comparação da Avaliação e Inserir Ob-
PRNU inserida ou calculada jeto Questionado
com o objeto
22

Confrontar Perito Permite realizar a Selecionar Método de


Objeto comparação entre a PRNU Avaliação, Inserir Ob-
Questionado x do objeto questionado com as jeto Questionado e Ve-
PRNU imagens de prova rificar PRNU
Verificar PRNU Perito Possibilita ao Ator escolher Selecionar Método de
entre Calcular PRNU ou Avaliação
Carregar a PRNU
pré-calculada
Calcular PRNU Perito Permite o cálculo da PRNU Selecionar Método de
por meio da inserção do Avaliação e Inserir Di-
diretório de treinamento retório de Treinamento
Carregar PRNU Perito Permite o carregamento de Selecionar Método de
um arquivo contendo Avaliação
informações de PRNU
pré-calculada
Extrair Dados Perito Possibilita a extração de Inserir Objeto Questio-
EXIF dados EXIF do objeto nado
Avaliar Perito Permite a análise em busca Inserir Objeto Questio-
Adulterações de adulterações no objeto nado
Avaliar via Perito Permite buscar adulterações Avaliar Adulterações
Fridrich et al. no objeto por meio do
método de Fridrich et al.
Avaliar via Kang Perito Permite buscar adulterações Avaliar Adulterações
et al. no objeto por meio do
método de Kang et al.
Avaliar via Luo Perito Permite buscar adulterações Avaliar Adulterações
et al. no objeto por meio do
método de Luo et al.
Tabela 3.1: Descrição dos Casos de Uso
23

3.3.2.2 Diagrama de Classes

É possivelmente o diagrama mais utilizado e um dos mais importantes da UML. Serve


para apoiar a maioria dos demais diagramas. Define a estrutura das classes utilizadas pelo
sistema, determinando os atributos e métodos que cada classe tem, além de estabelecer como as
classes se relacionam e trocam informações entre si.

O diagrama de classes do sistema proposto por este trabalho pode ser verificado no
Apêndice A.

3.3.3 Protótipos de Baixa Fidelidade

De acordo com Preece, Rogers e Sharp (2002), protótipos de baixa fidelidade são aqueles
que não se assemelham ao sistema final. Estes protótipos são úteis para explorar e testar possi-
bilidades durante a fase inicial de desenvolvimento do sistema. São produtos simples, baratos e
de fácil produção e alteração facilitando, assim, a exploração e teste de idéias. Estes protótipos
nunca são desenvolvidos com o objetivo de serem incorporados ao produto final. Na prototi-
pagem de baixa fidelidade, os principais compromissos pré-estabelecidos são: o sistema não
funciona e o protótipo não se assemelha com o sistema final. Exemplos de protótipos de baixa
fidelidade do sistema proposto podem ser vistos na Figura 3.4 e Figura 3.5.
24

Figura 3.4: Protótipo da janela principal do Sistema de Perı́cia em Imagens Digitais.

Figura 3.5: Protótipo da janela Análise via PRNU - Sistema de Perı́cia em Imagens Digitais.
25

Capı́tulo 4

Linguagem de Programação, Framework e


Bibliotecas

4.1 Introdução

Devido ao desempenho da linguagem de programação C++, sua compatibilidade total


com a biblioteca de eficiência computacional OpenCV (previamente descrita na seção 1.5.3) e
por ser multiplataforma, esta foi a linguagem de programação escolhida para o desenvolvimento
da aplicação referente aos estudos desenvolvidos nos projetos Processamento Digital de Sinais
Aplicado à Prática Forense: Verificação de Adulteração de Provas Digitais e Assinatura de
Sistemas de Aquisição de Imagem I e II.

Optou-se pela utilização do framework Qt pela sua robustez e, ao mesmo tempo, portabi-
lidade, razões que fizeram o framework ganhar espaço na comunidade de software livre, como
se pode verificar nos aplicativos desenvolvidos pela comunidade KDE1 .

4.2 Qt em Múltiplas Plataformas

Com o Qt, é possı́vel se reutilizar códigos de forma eficiente objetivando múltiplas pla-
taformas, utilizando-se de apenas um código fonte como base. As bibliotecas de classes mo-
1
Comunidade internacional de desenvolvimento de software livre, produtora de aplicativos multiplataforma.
Porém, mais conhecida pelo seu ambiente de trabalho em distribuições GNU/Linux.
26

dulares em C++ e ferramentas de desenvolvimento permitem que se criem aplicações para um


sistema operacional e facilmente sejam criados, depurados e executados em outros sistemas
operacionais ou, até mesmo, outras arquiteturas de processadores.

O Qt torna o desenvolvimento mais fácil e eficiente, através de variadas ferramentas de


desenvolvimento, agilizando a curva de aprendizado e diminuindo o tempo de entrega do pro-
duto em até 50% (DIGIA, 2012) para sistemas criados objetivando múltiplas plataformas.

4.2.1 Qt Designer

Qt Designer é a ferramenta Qt para projetar e construir GUI com Qt Widgets2 . Com ele,
pode-se compor e personalizar janelas ou caixas de diálogo na forma what-you-see-is-what-
you-get3 (WYSIWYG), e testá-los utilizando diferentes estilos e resoluções. Uma tela do Qt
Designer pode ser visualizada na Figura 4.1

Figura 4.1: Qt Designer pronto para iniciar o desenvolvimento de uma interface de usuário

Widgets e formas criadas com o Qt Designer se integram perfeitamente ao código progra-


2
Elemento gráfico de uma GUI que exibe um arranjo de informações mutáveis pelo usuário, como uma janela
ou caixa de texto.
3
O que você vê é o que você tem, em tradução livre, indica a capacidade de um software de permitir que um
documento, enquanto manipulado na tela, tenha a mesma aparência de sua utilização final.
27

mado, usando o mecanismo de sinais e slots do Qt, de modo que se pode facilmente atribuir o
comportamento de elementos gráficos. Todas as propriedades definidas no Qt Designer podem
ser alteradas dinamicamente dentro do código. Além disso, caracterı́sticas como a promoção de
widgets e plugins personalizados permitem que sejam usados componentes próprios com o Qt
Designer.

4.2.2 Qt Quick

O Qt Quick é a biblioteca padrão para escrita de aplicações QML4 . Enquanto o módulo


Qt QML fornece o motor e a infraestrutura da linguagem, o módulo Qt Quick fornece todos os
elementos básicos necessários para a criação da GUI com QML. É importante frisar que este
módulo não foi utilizado neste trabalho, porém é citado devido a uma boa parte dos aplicativos
serem desenvolvidos através da linguagem declarativa QML. Foi estudada a possibilidade da
criação do sistema proposto usando QML, isto traria opções de aparência completamente cus-
tomizáveis e elementos com reações ao toque e transições suavemente animadas e aceleração
através da API5 OpenGL6 , porém não foi continuada devido a maior parte das aplicações para
desktop utilizarem Widgets na época do inı́cio do desenvolvimento do sistema. A interface de
desenvolvimento Qt Quick pode ser vista na Figura 4.2 e um exemplo de aplicação desenvolvida
com QML pode ser visualizado na Figura 4.3.

4
Qt Meta Language ou Qt Modeling Language é uma linguagem declarativa baseada em JavaScript para a
criação de GUI, em sua maioria para aplicativos de dispositivos móveis.
5
Application Programming Interface ou, em tradução livre, Interface de Programação de Aplicativos, é uma
biblioteca de rotinas que indica como softwares devem interagir uns com os outros.
6
Open Graphics Library ou, em tradução livre, Biblioteca Gráfica Aberta, usada em larga escala para
renderização 2D e 3D.
28

Figura 4.2: Interface de desenvolvimento Qt Quick

Figura 4.3: Exemplo de GUI em QML usando o Qt Quick. Fonte: http://www.nokiatividade.com/


29

4.3 Biblioteca OpenCV

OpenCV é uma biblioteca de código aberto com licença BSD7 que inclui diversos algo-
ritmos de visão computacional. A OpenCV tem uma estrutura modular, o que significa que o
pacote possui diversas bibliotecas tanto estáticas como compartilhadas (OPENCV DEV TEAM,
2013).

Dentre as principais bibliotecas, podem ser citadas:

• core: módulo compacto que define estruturas básicas de dados, incluindo o vetor multi-
dimensional Mat e funções básicas usadas por todos os outros módulos;

• imgproc: módulo de processamento de imagem que inclui filtros lineares e não lineares
de imagens, transformações geométricas de imagem, histogramas e etc;

• highgui: uma interface simples de se utilizar para captura de vı́deos, codificadores e


decodificadores de imagens;

• gpu: algoritmos de aceleração via Unidade de Processamento Gráfico (GPU).

4.4 Biblioteca FFMPEG

FFmpeg é um projeto de software que produz bibliotecas e programas para manipulação


de dados multimı́dia. A FFmpeg contém, entre seus principais módulos, a libavcodec, uma
biblioteca para codificação e decodificação (codec) de áudio e vı́deo. A FFmpeg é publicada
sob a licença LGPL ou GPL, dependendo dos módulos habilitados. Licenciamento de produtos,
inclusive do Sistema de Perı́cia em Imagens Digitais será abordado na seção 5.5.

O projeto FFmpeg compreende componentes como:

• libavformat - biblioteca contendo multiplexadores e demultiplexadores para conteineres


áudio e is a library containing demuxers and muxers for audio/video container formats;
7
Uma famı́lia de licenças de código aberto bastante permissivas, impondo o mı́nimo de restrições na
redistribuição de sistemas. Inicialmente foi utilizada nos sistemas operacionais do tipo Berkeley Software Dis-
tribution (um sistema derivado do Unix)
30

• libavcodec - biblioteca que contém todos os codecs de áudio e vı́deo;

• libavfilter - biblioteca que permite que arquivos de vı́deo sejam modificados ou examina-
dos entre o decodificador e o codificador.

Faz-se importante mencionar esta biblioteca neste trabalho já que está sendo estudada a
viabilidade da aplicação da técnica de PRNU para avaliar vı́deos através de seus quadros e o
sistema proposto já está sendo testado com o uso destas bibliotecas para buscar incompatibili-
dades.

4.5 Biblioteca EasyEXIF

EasyEXIF é uma pequena e leve biblioteca em C++ que analisa informações básicas de ar-
quivos EXIF. Ela usa apenas a biblioteca std::string e, de resto, é puro C++. Passa-se o conteúdo
binário de um arquivo JPEG inteiro e ela analisa alguns dos campos EXIF mais importantes do
arquivo, bastando incluir o arquivo .h desta biblioteca.

Muitas vezes, só se precisa extrair rapidamente informações básicas de cabeçalhos EXIF
de um arquivo JPEG: a hora em que a imagem foi tirada, a exposição, a informação do GPS
embutido no arquivo EXIF, qual a marca e modelo da câmera, etc. Muitas bibliotecas EXIF não
são muito leves e fáceis de se integrar em sistemas, a EasyEXIF visa resolver esse problema
e é liberada sob a licença BSD o que possibilita seu uso em praticamente qualquer lugar e
é completamente compatı́vel com a licença adotada para o Sistema de Perı́cia em Imagens
Digitais, melhor explicada na seção 5.5 deste trabalho.
31

Capı́tulo 5

Resultado: SPID - Sistema de Perı́cias em


Imagens Digitais

5.1 Introdução

Este capı́tulo demonstra a fase de programação propriamente dita, a estrutura do sistema,


como as bibliotecas externas foram utilizadas no desenvolvimento do sistema proposto, como
as classes foram dispostas e devidamente modularizadas. Apresenta, também, as plataformas
em que o sistema foi compilado e testado.

Pelo fato do sistema estar em constante desenvolvimento e técnicas estarem sendo pesqui-
sadas e desenvolvidas, alterando assim os requisitos do sistema a cada nova técnica agregada, o
uso do Modelo Espiral foi o que melhor se adaptou ao modo de criação do sistema proposto. A
exemplo disto, temos as técnicas de análise de vı́deos que estão em pesquisa visando adicionar
mais recursos ao sistema.

5.2 Estrutura do Sistema

5.2.1 Modularização do Sistema

O Sistema de Perı́cias em Imagens Digitais (SPID) desenvolvido neste trabalho consiste


basicamente de uma interface gráfica inicial de fácil utilização para o carregamento de imagens
32

postas à prova, análise simplificada de dados EXIF e de dois módulos integrados para auxı́lio
à prática forense: Módulo de Detecção da Fonte de Imagens via PRNU e Módulo de Detecção
de Adulterações via Copy-Move, ambos descritos na seção 5.3, sendo completamente possı́vel
adicionar outros módulos seguindo o mesmo padrão através da reutilização das bibliotecas e
interfaces de usuário desenvolvidas com os recursos descritos neste trabalho.

5.2.2 Estereótipo Entity-Control-Boundary

De modo a separar as classes do sistema com o objetivo de organização, fácil acopla-


mento e permitir testes das classes, iniciou-se o desenvolvimento utilizando o estereótipo Entity-
Control-Boundary (ECB), que é uma simplificação do padrão Model-View-Control1 .

No estereótipo ECB, basicamente, as classes referentes à saı́da ou visão do usuário devem


ser classificadas como Boundary, as classes de controle de dados e funções devem ser classifi-
cadas com o estereótipo Control e, por fim, classes que representam dados do sistema devem
ser organizados como Entity.

Esta fase primária da organização do sistema pode ser visualizada na Figura 5.1.

Figura 5.1: Organização das classes do SPID seguindo o padrão Entity-Control-Boundary.

1
Modelo que isola a lógica da aplicação e a interface do usuário, permitindo desenvolver, editar e testar sepa-
radamente cada parte.
33

5.2.3 Bibliotecas Externas

5.2.3.1 OpenCV (Análise da imagem)

Para carregamento, análise e criação de imagens nos módulos de Análise via PRNU e
Análise de Adulteração, utilizou-se a biblioteca OpenCV que pode ser instalada através da
central de programas do Ubuntu (para a plataforma GNU/Linux Ubuntu) ou realizando down-
load em sua página oficial2 .

No módulo de Análise via PRNU, uma das aplicações da biblioteca OpenCV, em suma,
consiste no carregamento das imagens de treinamento em matrizes de dados para a estimação
dos valores de energia em cada ponto de cada uma das imagens. A partir disto, calcula-se
um padrão único de ruı́dos que um sensor de captura de imagens imprime na figura resultante,
deixando vestı́gios de sua fonte de captura. A esta matriz, com o padrão de ruı́dos, dá-se o nome
PRNU que é armazenada em um arquivo de extensão XML (eXtensible Markup Language),
juntamente com informações inseridas no arquivo sobre o dispositivo a partir do qual a mesma
foi adquirida. Esta matriz é utilizada para o confronto com a imagem posta à prova, afim de
reconhecer se o padrão calculado da PRNU é compatı́vel com o padrão da imagem de prova.

5.2.3.2 FFmpeg (Análise de vı́deo - Funcionalidade em pesquisa)

Utilizado em sua maioria nas funções, ainda em estudos e desenvolvimento, de análise de


vı́deo para captura de quadros de arquivos baseados em MPEG.

Esta biblioteca pode ser baixada e instalada a partir de sua página oficial3 e é, desde já,
necessária para o devido funcionamento do SPID, já prevendo os futuros módulos de análise de
vı́deo.

5.2.3.3 EasyEXIF

Devido a sua simplicidade e tamanho reduzido, a biblioteca EasyEXIF foi inserida dire-
tamente no programa em forma de pacote de modo que não há necessidade de instalação de
pacotes extras para o funcionamento desta funcionalidade do sistema.
2
Disponı́vel em: http://www.opencv.org/ - Último acesso em 06 agosto de 2013.
3
Disponı́vel em: http://www.ffmpeg.org/ - Último acesso em 06 de agosto de 2013.
34

Dados que podem ser extraı́dos pela biblioteca EasyEXIF: fabricante, modelo e versão do
software da câmera; largura, altura, descrição, orientação e licença da imagem; data e hora em
que a imagem foi capturada; tempo de exposição, sensibilidade fotográfica (ISO); GPS latitude
e longitude, entre outras informações do arquivo questionado. Este recurso utilizado no SPID
pode ser visualizado na Figura 5.2.

Figura 5.2: Interface gráfica inicial com destaque para a exibição de informações EXIF.

5.3 Funcionamento Geral

Ao se executar o programa, obtém-se a tela inicial do SPID, como na Figura 5.3. A


partir dela, pode-se carregar a imagem questionada para análise dos dados EXIF ou, direta-
mente, seguir para o módulo de Detecção da Fonte via PRNU ou para o módulo de Detecção de
Adulterações.
35

Figura 5.3: Interface gráfica inicial do SPID - GUI simples e facilmente usável.

5.3.1 SPID - Detecção da Fonte via PRNU

Para detecção de fontes de imagens, optou-se pelo uso da PRNU do sensor de aquisição
em função do seu potencial para ser adaptado a várias situações de análise forense da ima-
gem (FARID, 2009). A PRNU pode ser considerada impressão digital da câmera fotográfica,
presente em todas as imagens por ela capturadas.

A PRNU, decorrente do processo de fabricação de fotossensores, representa a diferença na


capacidade dos elementos que compõem esses fotossensores em converter luz em sinal elétrico.
A partir de imagens obtidas pela câmera suspeita (recomenda-se a utilização de 30 a 50 ima-
gens) e de um modelo simplificado do processo de aquisição de imagem, estima-se a PRNU
(Figura 5.4).
36

Figura 5.4: Processo de estimação da PRNU a partir de imagens obtidas pela câmera suspeita. Fonte:
(ZAMPOLO et al., 2011)

Na Figura 5.5, é representado o processo de análise que recebe como entradas: a imagem
suspeita e a PRNU estimada na etapa anterior. Da análise, resulta o pico de energia de correlação
(PCE, do inglês, peak to correlation energy) que, em suma, verifica se a PRNU foi ou não
detectada na imagem suspeita. Caso o valor do PCE esteja acima de um determinado limiar,
considera-se que a imagem testada foi capturada pela câmera associada à PRNU em questão
(FRIDRICH, 2009). Pequenas alterações no sistema de análise, permitem usar a PRNU em
verificação de adulteração de imagens digitais.

Figura 5.5: Análise e identificação de câmera: imagem suspeita é processada e comparada com a PRNU
estimada. Fonte: (ZAMPOLO et al., 2011)

Ao ser acionado, o botão referente ao módulo Detecção da Fonte via PRNU carrega uma
janela com opções para Estimar PRNU ou Carregar PRNU que já tenha sido previamente esti-
mada. Tendo uma PRNU e um objeto questionado carregados, faz-se possı́vel o confronto entre
37

imagem e PRNU. Tal janela pode ser vista na Figura 5.6.

Figura 5.6: SPID - Detecção da Fonte via PRNU.

Há também a janela de diálogo em que é selecionado o diretório de treinamento para a


estimação da PRNU (Figura 5.7), acessı́vel a partir da janela principal do módulo de Detecção
da Fonte via PRNU.

Após estimar a PRNU, é possı́vel salvar os dados obtidos em arquivo XML. São inseridos
pelo usuário do sistema como: Data de Criação, Autor, Marca da Câmera, etc. Esta tela de
diálogo é exibida na Figura 5.8.
38

Figura 5.7: SPID - Detecção da Fonte via PRNU - Estimar PRNU.

Figura 5.8: SPID - Detecção da Fonte via PRNU - Salvar PRNU.

5.3.2 SPID - Detecção de Adulterações

Ao se acionar o botão referente ao módulo Detecção de Adulterações, carrega-se a ja-


nela para análise de adulterações a partir de técnicas copy-move desenvolvidas por Masuda
(MASUDA, 2012). O programa já vem com parâmetros padrões pré-configurados, porém há
possibilidade de serem ajustados de acordo com a necessidade do perito.
39

O módulo de Detecção de Adulterações do SPID pode ser visto, na prática, na Figura 5.9,
onde foi executado o método Fridrich et al. visando detectar possı́veis adulterações em uma
imagem de prova adulterada e, em seguida, na Figura 5.10, testou-se o mesmo método em uma
imagem de prova autêntica.

Figura 5.9: SPID - Detecção de Adulterações. Imagem adulterada.

5.4 Documentação

Uma etapa importante de todo projeto de criação de software é a documentação, o que


possibilita que o código possa ser devidamente continuado e reutilizado.

5.4.1 Doxygen

Utilizou-se o gerador de documentação multiplataforma Doxygen para realizar a extração


da documentação do SPID através dos comentários de seu código-fonte.

Como a documentação é escrita dentro do próprio código, faz-se relativamente simples


mantê-la atualizada. O gerador Doxygen pode cruzar referências entre a documentação e o
código-fonte, assim facilitando ao leitor na hora de se referir ao código.
40

Figura 5.10: SPID - Detecção de Adulterações. Imagem autêntica.

Quanto melhor comentado for o código-fonte, mais rica será a documentação gerada pelo
Doxygen acerca do programa. A documentação do SPID foi gerada em html de modo a facilitar
sua disponibilização online.

5.5 Licença SPID

Tomou-se por base, para a criação do SPID, a GNU Lesser General Public License, versão
3.0 (LGPL-3.0) (STALLMAN; MOGLEN, 2007), uma licença de software livre, publicada pela
Free Software Foundation (FSF).

A LGPL permite que desenvolvedores e empresas utilizem e integrem softwares sob a


LGPL em seu próprio software (mesmo proprietário), sem que seja necessário liberar o código-
fonte de seu próprio software. Apenas as partes LGPL do sistema pode ser modificada por
usuários finais (via disponibilidade do código fonte). Assim, no caso do software proprietário,
as partes sob a LGPL geralmente são usadas na forma de biblioteca compartilhada (por exemplo,
DLL), para que haja uma distinção entre as partes proprietárias e as partes sob a LGPL.
41

Um exemplo de declaração desta licença pode ser visto na Figura 5.11.

Figura 5.11: Declaração de licença LGPL na classe da janela principal do SPID

5.6 Plataformas Compiladas e Testadas

5.6.1 Linux Ubuntu 13.04 - 64 bits

• GNU/Linux Ubuntu 13.04 - 64 bits - Kernel 3.8.0-19-generic

• Qt 5.0.1

• OpenCV 2.4.6

• FFmpeg 2.0

5.6.2 Microsoft Windows 7 Professional - 64 bits

• Microsoft Windows 7 Professional - 64 bits

• Qt 5.0.1

• OpenCV 2.4.6

• Zeranoe FFmpeg Build Version: git-f118b41 (2013-08-01)


42

Capı́tulo 6

Considerações Finais

Este trabalho abordou o desenvolvimento de um sistema que visa auxiliar à prática forense
por meio de técnicas aplicadas à imagens digitais que buscam a detecção da fonte das imagens,
bem como adulterações. Seu intuito é ajudar a identificar indı́cios de fraude de pessoas que se
aproveitam da tecnologia para cometer delitos no âmbito das imagens digitais.

Para o desenvolvimento da ferramenta SPID, realizou-se o acompanhamento dos estudos


de técnicas desenvolvidas pelos projetos Processamento Digital de Sinais Aplicado à Prática
Forense: Verificação de Adulteração de Provas Digitais e Assinatura de Sistemas de Aquisição
de Imagem I e II, bem como foi realizado o estudo de Engenharia de Software necessário à
documentação e aos requisitos para o desenvolvimento do sistema.

Devido ao fato do sistema estar em desenvolvimento e suas técnicas em fase de aperfeiçoamento,


optou-se por adotar conceitos de modelagem seguindo certos padrões de projeto que culminem
em boas práticas de criação, principalmente pelo fato dos requisitos serem dinâmicos.

Utilizou-se do Modelo Espiral, visto que foi o que melhor se adaptou ao sistema em
desenvolvimento. Com cada novo requisito, faz-se importante realizar uma nova iteração no
projeto e suas devidas análises de riscos agregados.

Definiu-se a linguagem de programação C++, o framework Qt e outras bibliotecas de


análise de imagens para o desenvolvimento do sistema devido à sua excelente integração e
desempenho. Além da possibilidade de compilação para múltiplas plataformas.

A principal dificuldade no desenvolvimento do sistema foi encontrar material recente so-


43

bre a utilização do framework Qt, além da documentação produzida pelo fabricante. Devido
ao pouco conhecimento sobre o framework, o desenvolvimento acabou levando mais tempo do
que esperado, visto a necessidade de pesquisa mais extensa. Também deve ser citada a dificul-
dade de integrar as ferramentas já desenvolvidas às que estão em desenvolvimento, buscando
padronizá-las.

6.1 Trabalhos Futuros

• Para que o sistema possa ser usado em perı́cias, faz-se necessária uma ferramenta de
impressão de resultados das análises obtidas pelos módulos do SPID. Recomenda-se
pesquisa e criação a partir das bibliotecas QPrinter do framework Qt. Idéias de mode-
los de laudos técnicos e procedimentos podem ser encontradas no livro “Desvendando a
Computação Forense” (ELEUTERIO; MACHADO, 2011b).

• Devido ao alto custo de processamento exigido para as análises realizadas pelos módulos
do SPID, faz-se interessante a realização de testes de compilação usando poder de pro-
cessamento de placas gráficas (GPU) através de bibliotecas NVIDIA Compute Unified
Device Architecture (CUDA).

• Pelo sistema estar em constante fase de testes e criação, torna-se aparentemente simples
os testes realizados pela comunicação direta entre as classes do estereótipo boundary e
entity. Porém, a longo prazo e de acordo com o aumento do sistema, a melhor separação
destas classes por meio do uso de classes do tipo control se fará importante para a devida
manutenção e expansão do SPID.

• É importante realizar mais estudos acerca do comportamento da PRNU após realizadas


modificações de imagens digitais, seja na resolução, mudança de formato ou corte. As-
sim, possibilitando o aprimorando das técnicas utilizadas no SPID.
44

Referências Bibliográficas

BOEHM, B. W. A spiral model of software development and enhancement. IEEE Computer,


p. 61–72, Maio 1988.

BULLE, F. Artigo sobre Computação Forense. 2008. Último acesso em 23/01/2013.


Disponı́vel em: http://grenoble.ime.usp.br/˜gold/cursos/2008/movel/
gradSemCorrecao/FelipeBulleC.pdf.

COSTA, D. Perı́cia forense aplicada à informática. [S.l.]: IBPI, 2003.

CROCE, D. Manual de Medicina Legal. [S.l.]: Saraiva, 1995.

DIGIA. QtDoc 5.0: Qt 5.0. Qt Project, 2012. Disponı́vel em: http://qt-project.org/


doc/qt-5.0/qtdoc/index.html.

ELEUTERIO, P. M. da S.; MACHADO, M. P. Computação forense e a perı́cia criminal - a


informática a serviço da justiça. SBC HORIZONTES, v. 4, n. 1, p. 19–23, Abril 2011a.

ELEUTERIO, P. M. da S.; MACHADO, M. P. Desvendando a Computação Forense. [S.l.]:


Editora Novatec, 2011b.

FARID, H. Image forery detection: A survey. IEEE Signal Processing Magazine, v. 26, n. 2,
p. 16–25, 2009.

FRIDRICH, J. Digital image forensics: Introducing methods that estimate and detect sensor
fingerprint. IEEE Signal Processing Magazine, v. 26, n. 2, p. 26–37, 2009.

GUEDES, G. T. UML2: Uma Abordagem Prática. [S.l.]: Novatec Editora, 2009.

MASUDA, H. K. T. Desenvolvimento de uma Aplicação para Detecção de Adulteração


de Imagens Digitais por Clonagem. 2012. Trabalho de Conclusão de Curso (Graduação em
45

Engenharia da Computação). Universidade Federal do Pará. Orientador: Ronaldo de Freitas


Zampolo.

MORIMOTO, C. E. Dicionário Técnico Hardware.com.br. 2005. Último acesso em


20/08/2013. Disponı́vel em: http://www.hardware.com.br/termos/cracker.

OPENCV DEV TEAM. OpenCV 2.4.6.0 documentation. [S.l.], 2013. Disponı́vel em:
http://docs.opencv.org/index.html.

PREECE, J.; ROGERS, Y.; SHARP, H. Interaction design: Beyond human-computer


interaction. NY: Wiley, 2002.

PRESSMAN, R. S. Engenharia de Software. 6a . ed. [S.l.]: Editora McGraw-Hill, 2006a.

PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7a . ed. [S.l.]:


Editora McGraw-Hill, 2006b.

SOMMERVILLE, I. Software Engineering. 9a . ed. [S.l.]: Editora Pearson, 2011.

STALLMAN, R.; MOGLEN, E. GNU LESSER GENERAL PUBLIC LICENSE.


Free Software Foundation, Inc, 2007. Último acesso em 23/01/2013. Disponı́vel em:
http://opensource.org/licenses/LGPL-3.0.

ZAMPOLO, R. F. et al. Projeto de extensão universitária em processamento de imagem na área


forense: relato de uma experiência em andamento. In: . [S.l.: s.n.], 2011.
46

Apêndice A
Diagrama de Classes - SPID
47
48

Você também pode gostar