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 requisito parcial para obtenção do grau de Bacharel em Engenharia da Computação da Faculdade de Engenharia da Computação e Telecomunicações do Instituto de Tecnologia da Universidade Federal do Pará. Orientador: Prof. Dr. Ronaldo de Freitas Zampolo. BELÉM - PARÁ 2013
DESENVOLVIMENTO DE UM SISTEMA DE ANÁLISE DE IMAGENS APLICADO À PRÁTICA FORENSE iii Este trabalho foi julgado adequado em para a obtenção do Grau de Engenheiro 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 proporcionaram 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, carinho, 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. Principalmente 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 processo 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 solicitude. 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
3.3.2.2 Diagrama de Classes...................... 23 3.3.3 Protótipos de Baixa Fidelidade...................... 23 ix 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 suspeita. 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 CCD CPCRC CCD CPP CUDA EXIF GUI GPS GPU IC LGPL P2P SPID PRNU UML WWW WYSIWYG Computer-Aided Software Engineering Charge-Coupled Device Centro de Perícias Científicas Renato Chaves Charge-Coupled Device Código de Processo Penal Compute Unified Device Architecture Exchangeable Image File Format Graphical User Interface Global Positioning System Graphics Processing Unit Instituto de Criminalística Lesser General Public License Peer-to-peer Sistema de Perícias em Imagens Digitais Photo Response Non-Uniformity Unified Modeling Language World Wide Web What-You-See-Is-What-You-Get
xiv Resumo Este trabalho tem como objetivo apresentar a modelagem e o desenvolvimento de um sistema 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 desenvolvimento. Para o devido desenvolvimento deste sistema, faz-se fundamental a utilização de conceitos 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 processo. 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 concepts, 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 engineering 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 medidas 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 possibilitar 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 Engenharia de Software. Astah Community, anteriormente denominado JUDE, Java and UML Developers Environment (Ambiente para Desenvolvedores UML e Java), o Astah é um software para modelagem UML desenvolvido na plataforma Java, o que garante a portabilidade entre diversos sistemas 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 livre, 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ódigofonte. 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 dispositivos 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, tablets, câmeras digitais, GPS 1, 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 recriar 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 Michaelis 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 qualificado, 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 minuciosamente o que examinarem e responderão aos quesitos formulados. No caso da computação, quem realiza esse trabalho de forma oficial no âmbito criminal é 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 processamento de evidências digitais em provas materiais de crimes, através de métodos técnicocientí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, podese 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, phishing 2, programas maliciosos para roubo de senhas e outros. Se um cracker 3, 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 especificados 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 trazer, 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 novembro 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 Web 4. 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 identificar 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 chamamos 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 acompanhado pelos softwares produzidos naquela época. O desenvolvimento de software não conseguia 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 possibilidade 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 software, é 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 levantamento 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 funcionamento (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 guiado por risco usado para guiar a engenharia de sistemas intensivos em software com vários interessados concorrentes. Ele tem duas principais características distintas. 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 comprometimento 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 desenvolvimento. 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 requisitos 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, enganase 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 solicitante 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 definem 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 metadados 1 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 digitais 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 modelagem, uma notação, com o objetivo de auxiliar os engenheiros de software a definirem as caracterí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, individualmente, 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 Objeto Questionado x PRNU Perito Permite realizar a comparação entre a PRNU do objeto questionado com as imagens de prova Verificar PRNU Perito Possibilita ao Ator escolher entre Calcular PRNU ou Carregar a PRNU pré-calculada Calcular PRNU Perito Permite o cálculo da PRNU por meio da inserção do diretório de treinamento Carregar PRNU Perito Permite o carregamento de um arquivo contendo informações de PRNU pré-calculada Extrair Dados Perito Possibilita a extração de EXIF dados EXIF do objeto Avaliar Perito Permite a análise em busca Adulterações de adulterações no objeto Avaliar via Perito Permite buscar adulterações Fridrich et al. no objeto por meio do método de Fridrich et al. Avaliar via Kang et al. Perito Permite buscar adulterações no objeto por meio do método de Kang et al. Avaliar via Luo Perito Permite buscar adulterações et al. no objeto por meio do método de Luo et al. Tabela 3.1: Descrição dos Casos de Uso Selecionar Método de Avaliação, Inserir Objeto Questionado e Verificar PRNU Selecionar Método de Avaliação Selecionar Método de Avaliação e Inserir Diretório de Treinamento Selecionar Método de Avaliação Inserir Objeto Questionado Inserir Objeto Questionado Avaliar Adulterações Avaliar Adulterações Avaliar Adulterações
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 possibilidades 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 prototipagem 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, portabilidade, razões que fizeram o framework ganhar espaço na comunidade de software livre, como se pode verificar nos aplicativos desenvolvidos pela comunidade KDE 1. 4.2 Qt em Múltiplas Plataformas Com o Qt, é possível se reutilizar códigos de forma eficiente objetivando múltiplas plataformas, 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 produto 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 Widgets 2. Com ele, pode-se compor e personalizar janelas ou caixas de diálogo na forma what-you-see-is-whatyou-get 3 (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 QML 4. 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 customizáveis e elementos com reações ao toque e transições suavemente animadas e aceleração através da API 5 OpenGL 6, 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 BSD 7 que inclui diversos algoritmos 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 multidimensional 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 Distribution (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 examinados 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 incompatibilidades. 4.5 Biblioteca EasyEXIF EasyEXIF é uma pequena e leve biblioteca em C++ que analisa informações básicas de arquivos 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 pesquisadas 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 acoplamento 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-Control 1. 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 classificadas 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 separadamente 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 download em sua página oficial 2. 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 oficial 3 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 diretamente 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, diretamente, 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 imagem (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 imagens) 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 estimada. 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 janela 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ódigofonte 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 dificuldade 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 modelos 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 processamento 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. Assim, 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. 6 a. ed. [S.l.]: Editora McGraw-Hill, 2006a. PRESSMAN, R. S. Engenharia de Software: Uma Abordagem Profissional. 7 a. ed. [S.l.]: Editora McGraw-Hill, 2006b. SOMMERVILLE, I. Software Engineering. 9 a. 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.
Apêndice A Diagrama de Classes - SPID 46
47
48