nsrlsvr-bd

� � � � � ��� � � � � � � � ��� � ��� � � � � � � � � � ��� ��� � � � � � �
NSRLSVR-BD
RELATÓRIO DE PROJETO FINAL DA LICENCIATURA EM ENGENHARIA INFORMÁTICA
�����
Fábio André Soares de Freitas
� � � � � � � � � � � � � � António Alberto dos Santos Pinto
���
2014/06
����������������
Índice de conteúdo
Resumo.......................................................................................................................................... IV
1 - Introdução................................................................................................................................... 1
2 - Ficheiros conhecidos................................................................................................................... 2
2.1 – Identificação de ficheiros conhecidos......................................................................................2
2.2 Técnicas de identificação de ficheiros........................................................................................3
2.2.1 Assinaturas de ficheiros........................................................................................................... 3
2.2.2 Técnicas anti vírus...................................................................................................................5
2.2.3 Técnicas anti vírus avançadas................................................................................................7
2.2.4 Funções Criptográficas de Resumo.......................................................................................12
2.3 – NSRL..................................................................................................................................... 20
2.3.1 – NSRLLOOKUP................................................................................................................... 22
3 – Desenvolvimento do NSRLSVR-BD.........................................................................................24
3.1 – Requisitos.............................................................................................................................. 24
3.2 – Modelo Conceptual e Relacional...........................................................................................25
3.3 – Protótipo da aplicação........................................................................................................... 26
4 – Avaliação da aplicação............................................................................................................. 34
4.1 – Carregar dados para base de dados.....................................................................................34
4.2 – Testes do protótipo................................................................................................................ 37
4.2.1 – Requisitos a testar.............................................................................................................. 38
4.2.2 – Estratégia de testes............................................................................................................ 39
4.3 – Resultados............................................................................................................................ 42
5 – Conclusão................................................................................................................................ 45
I
Índice de tabelas
Exemplo de assinaturas de ficheiros [26].........................................................................................4
Exemplo do ficheiro conf................................................................................................................ 28
Exemplo da estrutura da base de dados........................................................................................28
Exemplo de inserção na base de dados.........................................................................................28
Exemplo de Código de inserção de dados.....................................................................................29
comando de ajuda.......................................................................................................................... 30
funcionalidades existentes na aplicação........................................................................................30
comando para iniciar o servidor......................................................................................................30
protocolo de comunicação com cliente...........................................................................................33
Exemplo de um ficheiro para carregar dados base de dados.........................................................35
Exemplo de um script para auxilio a carregar dados na base de dados.........................................36
Exemplo de registo log script......................................................................................................... 36
Registos da inserção de dados na base de dados.........................................................................37
Exemplo do script de registar ficheiros não conhecidos.................................................................38
Teste de integridade de dados e da base de dados.......................................................................40
Teste de Funções........................................................................................................................... 40
Testes da interface do utilizador.....................................................................................................41
Teste de Performance.................................................................................................................... 41
Teste de instalação......................................................................................................................... 42
Tempos de pesquisas..................................................................................................................... 43
II
Índice de ilustrações
Exemplo editor hexadecimal PDF....................................................................................................5
Sistema digital imune [16]................................................................................................................9
Duas funções de hash simples [16]................................................................................................15
Uma carta com 2^37 variações[2]..................................................................................................18
Modelo Conceptual........................................................................................................................ 25
Modelo Relacional.......................................................................................................................... 26
Comunicação Cliente-Servidor.......................................................................................................27
III
Resumo
A análise forense a equipamentos informáticos recorre frequentemente a técnicas de identificação
de ficheiros. Esta técnica permite que o analista forense ignore milhares de ficheiros (sistema
operativo, aplicações, etc) previamente identificados e considerados conhecidos, reduzindo-se a
quantidade de informação a analisar pelo analista. Uma aplicação que o permite fazer é o
NSRLSVR que, por carregar a totalidade da base de dados de identificação de ficheiros (resumos
criptográficos) para memória RAM é simultaneamente muito rápida e muito exigente em termos de
recursos de hardware.
O objetivo deste projeto consiste é fazer uma nova versão da aplicação NSRLSVR, de forma a
manter o seu funcionamento mas que guarde os dados numa base de dados em vez de carregar
para a memória RAM. Tal permitirá a sua execução em PCs com especificações de hardware
menores. Adicionalmente, pretende-se que a nova aplicação seja multi-plataforma.
O desenvolvimento deste projeto implicou a criação de uma base de dados, o estudar do
funcionamento da aplicação original, bem como do respetivo protocolo de comunicação. A
aplicação NSRLSVR é utilizada em conjunto com uma aplicação cliente. Funcionalidade esta que
também foi assegurada pelo atual projeto, podendo ser utilizada com a aplicação cliente do
NSRLSVR original.
Os resultados obtidos da comparação entre as duas versões da aplicação (NSRLSVR e
NSRLSVR-BD) resumem-se a uma execução 7,14 vezes mais lenta na pesquisa de resumos
(hashes) da aplicação NSRLSVR-BD, quando comparada com a aplicação original (NSRLSVR).
Não obstantes, o NSRLSVR-BD torna-se mais usável já que é multi-plataforma e não têm os
mesmos requisitos de RAM que a original.
IV
1 - Introdução
O projeto consiste no desenvolvimento de uma nova versão da aplicação NSRLSVR. O NSRLSVR
é uma aplicação que armazena resumos criptográficos de ficheiros conhecidos e possibilita a sua
comparação com ficheiros num qualquer suporte de armazenamento. Os ficheiros que existam
que sejam identificados como previamente conhecidos podem ser ignorados nos processos de
análise forense. Na prática, o NSRLSVR procura por um hash de um ficheiro, se esse hash for
encontrado quer dizer que o ficheiro é conhecido. O NSRLSVR, no seu arranque, carrega para
memória RAM a totalidade da base de dados da NSRL. Depois de carregada, recebe pedidos
para procurar hashes por intermédio da aplicação cliente (NSRLLOOKUP).
O contexto do atual projeto, em detrimento do uso de memória RAM, haverá recurso a uma base
de dados MySQL, porque o TXT a carregar para a memória RAM é muito extenso e ocupa
aproximadamente 30 GB. Tal torna a aplicação pouco usável num computador normal e serve de
mote para o projeto atual. A linguagem utilizada na aplicação original é o C++, tendo a mesma
sido desenvolvida unicamente para Linux. Neste projeto utilizar-se-á Java para, assim, tornar a
nova aplicação uma aplicação multi-plataforma.
A estrutura deste relatório está organizada em capítulos. O Capítulo 2 abordada a identificação de
ficheiros conhecidos, técnicas para a identificação de ficheiros conhecidos e NSRL que é um
armazém de software conhecido. O Capítulo 3 apresenta os requisitos necessários para o
funcionamento da aplicação, a criação de diagramas da base de dados e por um protótipo da
aplicação. O Capítulo 4 descreve a metodologia de trabalhado desenvolvida, os testes e seu
planeamento e, por fim, os resultados dos testes efectuados. O Capítulo 5 conclui o relatório.
1
2 - Ficheiros conhecidos
A identificação de ficheiros é um método muito utilizado pelos técnicos forenses quando
deparados com uma grande fonte de dados. Nesses casos, normalmente fazem uma cópia
fidedigna e autêntica. Quando fazem a análise a um sistema de armazenamento normalmente
fazem os seguintes processos recolha de informação, recuperação de dados perdidos,
identificação de ficheiros conhecidos estabelecimento de linhas temporais de eventos.
Quando chegarem ao processo de identificação de ficheiros conhecidos vão precisar de
técnicas que possam identificar ficheiro que sejam conhecidos, visto que este método permite
acelerar o processo quando temos que analisar um disco de armazenamento que tenha muitos
ficheiros. As técnicas de identificação de ficheiros passam pelo reconhecimento de ficheiros que,
por sua vez, permitem verificar se é um ficheiro conhecido, para isso usam-se assinaturas de
ficheiros, técnicas antivírus e funções criptográficas de resumo.
2.1 – Identificação de ficheiros conhecidos
É um procedimento muito comum, que permite acelerar o processo quando temos que analisar
um disco ou um suporte de armazenamento que contenha muitos ficheiros, reduzindo assim os
ficheiros a analisar. Nesta pesquisa pode se considerar qualquer sistema operativo existente, por
exemplo, qualquer sistema que vamos analisar é normal que seja constituído por muitos ficheiros
podendo ultrapassar as dezenas de milhar de ficheiros. Para tornar a pesquisa mais fácil podemse utilizar funções criptográficas de resumo tornando-se possível reconhecer um ficheiro e
averiguar que o seu conteúdo não foi alterado mesmo quando modificado o seu nome [24].
Quando estamos num procedimento de análise de suportes de armazenamento, cada vez
maiores, verifica-se que a informação de determinados ficheiros é comum, permitindo que o
analista forense possa se dedicar aos outros ficheiros, que podem ser potencialmente mais úteis
para a investigação. E cada vez mais usual encontrar-se base de dados de hashes de SHA-1, ou
outras, de ficheiros conhecidos disponíveis na Internet. Fazem parte desta base de dados
ficheiros tais como os ficheiros que compõem os sistemas operativos mais comuns (Microsoft,
Apple, Linux) permitindo passar rapidamente dezenas de milhares de ficheiros de um disco ou
suporte de armazenamento [24].
2
Na Internet existem várias base de dados que podem ser usadas por ferramentas forenses, no
entanto surge como ponto crítico o processamento de ficheiros porque este implica que se faça o
resumo (Ex: MD5) de todos os ficheiros, como também a sua comparação com resumos
previamente guardados numa base de dados. Ou seja, para se fazer esta tarefa, necessita-se de
duas componentes críticas: 1) a base de dados com hashes (resumos); 2) aplicações que
permitem a comparação com a informação guardada na base de dados [24].
2.2 Técnicas de identificação de ficheiros
2.2.1 Assinaturas de ficheiros
Uma assinatura de ficheiro é um número de identificação único, localizado no início de um ficheiro.
Esse número identifica o tipo de ficheiro, dando informações sobre os dados contidos no ficheiro
real. Esta informação pode ser usada para determinar que tipo de ficheiro está a ser lido ou
quando o utilizador tenha identificado erradamente a extensão do ficheiro como um tipo incorrecto.
A assinatura do ficheiro também pode conter informações que garantem que os dados originais
foram armazenados no ficheiro estão intactos e não foram modificados. A combinação destes
elementos permite uma assinatura de ficheiro que serve como uma importante forma de
verificação, especialmente contra vírus de computador [25].
O conceito de uma assinatura de ficheiro surgiu devido à necessidade de um cabeçalho de
ficheiro - um bloco de dados - define os parâmetros da forma como a informação é armazenada.
Parte da informação do cabeçalho é uma sequência de bytes que define o tipo de ficheiro que foi
originalmente criado. Isso pode ser um ficheiro de imagem, um documento de um programa
específico, ou até mesmo um tipo de protocolo quando um fluxo do ficheiro está a ser usado
como um método de comunicação entre um cliente e servidor. O cabeçalho do ficheiro não usa
um padrão definido, que, ao contrário, é propriedade de cada formato diferente, ou seja, um
programa ou sistema operativo precisa de uma base de dados de assinaturas de ficheiros para
determinar o tipo de um ficheiro desconhecido [25].
A assinatura de ficheiro real é, por vezes, referida como um número mágico. Ao olhar para um
cabeçalho do ficheiro para determinar o tipo desse ficheiro, isso significa que não há duas
assinaturas de ficheiro iguais, permitindo que, para cada tipo de formato possa ter uma sequência
3
de identificação distinta de bytes. Isto pode ser de uso particular quando se lida com a
transferência e interpretação de ficheiros on-line, onde a extensão de identificação de um ficheiro
pode ser arbitrária e incapaz de ser invocado como um identificador para um tipo de ficheiro [25].
Além do tipo de ficheiro, uma assinatura de ficheiro também pode conter informações que
permitam a verificação de erros quando é executada num ficheiro verifique que os dados que ele
está a guardar possam ser confirmados como sendo intactos. Isto é muitas vezes realizado
utilizando uma função conhecida como uma soma de verificação (checksum). A soma de
verificação é uma função que utiliza os valores inteiros dos dados do ficheiro para criar valores
matemáticos que podem ser replicados depois que um ficheiro é transferido ou carregado. Na
forma mais básica, o processo envolve a adição dos valores de uma série de bytes no ficheiro e,
em seguida, a gravação da soma, permitindo que o programa de descodificação do ficheiro
execute a mesma função. Se os resultados são diferentes durante a descodificação, o ficheiro
pode ter sido danificado e os dados tanto podem ser inválidos ou podem ter sido modificados para
fins maliciosos [25].
Alguns exemplos de assinatura de ficheiros:
Hex assinatura
ISO 8859-1
Deslocação
Extensão ficheiro
Descrição
00 00 00 nn 66 74 79 70
33 67 70 35
....ftyp
3gp5
0
MP4
File de vídeo MPEG-4
25 50 44 46
%PDF
0
pdf
Documento PDF
43 44 30 30 31
CD001
0x8001, 0x8801
or 0x9001
iso
ISO9660 CD/DVD ficheiro de
imagem
FF D8 FF
ÿØÿà
0
jpg, jpeg
JPEG
doc
Doc. Microsoft Office
78 01 73 0D 62 62 60
x.s.bb`
0
dmg
Apple Disk imagem file
52 61 72 21 1A 07 01 00
Rar!....
0
rar
RAR ficheiro v. 5.0
D0 CF 11 E0
Tabela 1: Exemplo de assinaturas de ficheiros [26]
Na Tabela 1 mostra alguns exemplos de ficheiros comuns, mostrando a sua assinatura
hexadecimal, a sua representação em ISO 8829-1 (caracteres que são legíveis), a posição que se
encontra em relação ao inicio do ficheiro, a sua extensão normal e uma descrição que o seu
conteúdo tem. Como exemplo, 5º linha apresenta o caso dos ficheiros JPEG que tem os seus
valores hexadecimais FF D8 FF no inicio do ficheiro devido há deslocação ser 0 e que tem como
extensão jpg e jpeg.
Será utilizado um editor hexadecimal, que é uma ferramenta muito recorrente em análise forense
4
a imagens de suportes de armazenamento para demonstrar alguns exemplos constantes da
Tabela 1. O editor hexadecimal adotado foi o Bless Hex Editor, um editor de ficheiros hexadecimal
em modo gráfico.
Figura 1: Exemplo editor hexadecimal PDF
Na Figura 1, mostra o hexadecimal de um ficheiro PDF, se analisar a primeira linha desse ficheiro
pode-se observar que os primeiros 8 dígitos a seguir à barra são os mesmos 8 dígitos que
aparecem na 3º linha da Tabela 1, o que significa que mesmo que a extensão seja alterada estes
números não se alteram podendo identificar a verdadeira extensão do ficheiro.
2.2.2 Técnicas anti vírus
Uma possível técnica ideal para a ameaça de vírus é a prevenção. Não podemos permitir que um
vírus entre no sistema, em primeiro lugar. De um modo geral, esse objetivo é impossível de se
conseguir, embora a precaução pode diminuir o número de ataques virais bem-sucedidos. Outra
técnica bastante eficaz atua através das seguintes componentes:
- Detecção: Depois de ter ocorrido uma infecção, localize o vírus.
- Identificação: Depois da detecção do vírus estar completa, verifique o vírus específico que
infeccionou o programa.
- Remoção: Uma vez que o vírus específico tenha sido identificado, apague todos os traços
do vírus do programa infetado e recupere a sua condição natural. Apague o vírus de todos o
sistemas afetados, para que não se propague mais[16].
5
Se conseguir detetar com sucesso ameaça, no entanto, caso o reconhecimento ou a remoção
não forem possíveis, então outra alternativa será apagar o programa infetado e recarregar uma
versão de backup limpa[16].
À medida que se dão avanços na tecnologia de vírus também há na tecnologia de antivírus, pois
seguem lado a lado. Os primeiros registos de vírus eram pedaços de códigos muito simples, e
podiam também ser reconhecidos e apagados com software antivírus muito simples também. Há
medida que os vírus evoluíram, tanto os vírus como os softwares antivírus, tornaram-se mais
complexos e sofisticados[16].
[14] Identifica na sua obra quatro gerações de software antivírus:
- Primeira geração: scanner simples
- Segunda geração: scanner heurístico
- Terceira geração: intercetações de atividades
- Quarta geração: proteção completa
Um scanner de primeira geração requer que um vírus seja identificado por uma assinatura. O
vírus pode ter algumas alterações, mas tem o mesmo esqueleto e padrão de bits em todos os
seus duplicados. Esses scanners exclusivos de rubricas estão limitados a encontrar vírus já
conhecidos. Outra característica dos scanners de primeira geração é manter um registo do
tamanho dos softwares e investigar se há modificações no tamanho[16].
Um scanner de segunda geração não está sobre dependência de uma rubrica exclusiva. Em vez
disso, o scanner utiliza regras heurísticas para investigar uma possível contaminação de vírus.
Uma classe que está nesses scanners investiga se existem pedaços de código que, normalmente,
estão associados a vírus. Como por exemplo, ele é capaz de pesquisar no início de um ciclo de
criptográfica utilizado num vírus polimórfico e decifrar a chave de criptográfica. No tempo em que
a chave é conhecida, o scanner pode descodificar o vírus para conhecê-lo, depois disso apaga a
contaminação e volta a executar o programa normalmente[16].
Outra técnica de segunda geração é a averiguação de integridade. Uma adição de averiguação
(checksum) pode ser agregada a cada programa. Se um vírus contaminar o programa sem alterar
6
a adição de averiguação, então a averiguação de integridade perceberá a alteração. Para
incapacitar um vírus refinado o suficiente para modificar a adição de averiguação que contamina
um programa, será utilizada uma função de hash codificada. A chave de criptografia é guardada
separadamente do programa, para que o vírus não produza um novo código de hash e o
codifique. Ao utilizar-se uma função de hash em vez de uma adição de averiguação mais vulgar, o
vírus é impossibilitado de regular o programa para criar o mesmo código de hash que tinha
anteriormente[16].
Programas de terceira geração são programas que habitam na memória, que reconhecem um
vírus por suas atividades, em vez do seu esqueleto num programa contaminado. Esses
programas têm a vantagem de que não precisam de evoluir rubricas e heurísticas para uma
diversidade de vírus. Em vez disso, é essencial somente reconhecer um baixo grupo de atividades
que apontam que uma contaminação está em curso e, então, interferir[16].
Produtos de quarta geração são pacotes formado por uma sequência de técnicas antivírus
utilizadas em conjunto. Estas abrangem elementos de procura e de interrupção de atividades.
Além disso, esse tipo de pacote abrange meios de fiscalização de entrada, que restringe a
competência dos vírus de introduzir-se num sistema e, por isso, inibe um vírus de modificar
ficheiros a fim de transitar a contaminação para outros ficheiros[16].
Com os pacotes de quarta geração, é aplicada uma estratégia de defesa mais abrangente, em
que se aumente o limite da defesa para medidas de proteção de computador de uso mais
pessoal[16].
2.2.3 Técnicas anti vírus avançadas
Continuam a aparecer técnicas e produtos mais avançados. Neste sub capitulo, vamos destacar
as duas técnicas mais relevantes[16].
Decifra genérica A tecnologia de decifra genérica (DG) deixa que o programa antivírus descubra
naturalmente até mesmo os vírus polimórficos mais difíceis, enquanto a rapidez na procura se
mantém [10]. Convém lembrar de que, quando um ficheiro contem um vírus polimórfico é
executado, o vírus para se ativar precisa de se descodificar. Para descobrir esse esqueleto, os
ficheiros executáveis são executados por meio de um scanner de DG, que engloba os seguintes
elementos:
7
- Emulador de CPU: “computador virtual baseado em software”. As tarefas num ficheiro
executável são interpretadas pelo emulador, em vez de ser executadas no principal processador.
O emulador contém versões de software de todos os registados e outro hardware do processador,
de modo que o processador principal não seja contaminado por programas interpretados pelo
emulador.
- Scanner de rubrica do vírus: módulo que procura rubricas de vírus já conhecidos no código
do destino.
- Módulo de controle de vírus: é um módulo para controlar a execução do código do
destino[16].
No começo de cada emulação, o emulador inicia a sua função ao interpretar processos no código
do destino, uma a uma. Consequentemente, se o código abrange um hábito de decifra que
descodifica e, desta forma, exibe o vírus, esse código é interpretado. Verdadeiramente, o vírus
executa a atividade para o programa antivírus, exibindo o vírus. Frequentemente, o módulo de
controle paralisa a interceção para percorrer o código do destino há procura de rubricas de
vírus[16].
No decurso da interceção, o código do destino pode não provocar estragos no ambiente de
trabalho do computador pessoal real, visto que está a ser interpretado em um ambiente totalmente
seguro[16].
O contratempo do plano mais árduo no scanner de DG é especificar por quanto tempo corre cada
interpretação. Normalmente, os componentes do vírus são acionados após que um programa
inicie a sua execução, mas isso não necessita de ocorrer. Quanto mais vezes o scanner emular
um programa em privado, terá mais hipóteses de descobrir vírus ocultos. Contudo, o programa
antivírus apenas vai utilizar um número escasso de tempo e recursos antes que os utilizadores
comessem a reclamar[16].
Sistema digital imune O sistema digital imune é uma abordagem envolvente para a defesa
contra vírus, que foi elaborado pela IBM [5] [6]. A justificação para esse crescimento é o aumento
do alastramento de vírus na Internet. Primeiro, iremos abordar o aumento de vírus na Internet e
em seguida iremos abordar resumidamente a técnica da IBM[16].
Normalmente, o aviso de vírus foi assinalada pela propagação lenta de novos vírus e novas
8
alterações. Usualmente, o software antivírus costumava ser remodelado todos os meses, isto
bastava para segurar o problema. A Internet também cumpriu um papel relativamente baixo na
propagação do vírus. Mas, como [1] aponta, duas direções significativas na tecnologia da Internet
que tiveram um embate progressivo na aceleração no contágio dos vírus nestes últimos anos:
- Sistemas de correio integrados: sistemas como Lotus Notes e Microsoft Outlook fazem com
que seja fácil enviar alguma coisa a qualquer pessoa e manusear os assuntos recebidos.
- Sistemas de programas móvel: Conhecimentos como o Java e ActiveX deixam que
programas se movimentem por sua conta de um sistema para outro[16].
Para responder ao aviso colocado pelas competências baseadas na Internet, a IBM concebeu um
protótipo de sistema digital imune. Este sistema alarga a utilização da emulação do programa que
foi descrita anteriormente e dá um sistema de emulação e de deteção de vírus de utilização mais
geral. O objetivo deste sistema é responder prontamente para que os vírus sejam apagados na
mesma hora que são introduzidos. Quando um novo vírus entra em funcionamento, o sistema
imune capta-o logo, analisa-o e aumenta a verificação e defesa contra ele, apaga-o e transmite os
conhecimentos desse vírus para os sistemas executando o IBM Antivírus, para que seja verificado
antes que consiga ter aprovação para ser executado noutro lugar[16].
Figura 2: Sistema digital imune [16]
A Figura 2 mostra as etapas do funcionamento do sistema digital imune:
9
1. Um programa de monitorização em cada PC utiliza uma diversidade de heurísticas
baseadas no desempenho do sistema, alterações duvidosas nos programas, ou famílias
de rubricas para concluir que um vírus pode estar presente. O programa de monitorização
envia um duplicado de qualquer programa apontado como contaminado para uma máquina
administrativa dentro da organização[16].
2. A máquina administrativa codifica a porção e a encaminha para uma máquina central de
análise de vírus[16].
3. Esta máquina concebe um ambiente em que o programa contaminado pode ser executado
com segurança para analisá-lo. As técnicas utilizadas para esse efeito incluem a
emulação, ou a elaboração de um ambiente defendido dentro do qual um programa que
seja suspeito possa ser executado e monitorizado. A máquina de verificação do vírus
executa então uma tarefa para reconhecer e apagar o vírus[16].
4. A tarefa consequente é encaminha de volta para a máquina administrativa[16].
5. A máquina administrativa remete a tarefa ao cliente contaminado[16].
6. A tarefa também é remetida a outros clientes na organização[16].
7. Os clientes que assinaram no mundo inteiro vão recebendo atualizações regularmente de
antivírus que os defendes contra novos vírus[16].
O exito do sistema digital imune vai depender das competências da máquina da análise do vírus
percebendo constituições novas e inovadoras de vírus. Estar sempre a analisar e monitorizar os
vírus que vão sendo encontrados em campo, deverá ser possível ter o software digital imune
sempre atualizado para que se mantenha preparado para as ameaças[16].
Software de bloqueio de comportamento
Ao contrário dos scanners de heurística ou baseados em impressão digital, o software de bloqueio
de comportamento junta-se ao sistema operativo de um PC e monitoriza a atuação do programa
em tempo real na procura de ações que prejudiquem. O software de bloqueio de comportamento
trava as ações maldosas antes que elas tenham a hipótese de contaminar o sistema. As ações
monitorizadas podem incluir o seguinte:
10
- tentativas de abrir, ver, apagar e/ou alterar ficheiros;
- tentativas de formatar unidades de disco e outras operações de disco que não possam ser
desfeitas;
- alterações na lógica de ficheiros executáveis ou macros;
- alteração de configurações que possam prejudicar o sistema, como configurações de
inicialização:
- scripting de e-mail e clientes de mensagens rápidas para evitar conteúdo executável; e
- inicialização de comunicações em rede[16].
Se o defensor de comportamento perceber que um programa está a iniciar atitudes que sejam
maldosas enquanto é executado, ele pode defender essas atitudes em tempo real e/ou terminar o
software nocivo. Isso dá-lhe uma vantagem crucial em relação a técnicas de localização de
antivírus estabelecidas, como impressão digital e heurística. Apesar de existirem muitas maneiras
distintas de enganar e reorganizar as ações de um vírus ou verme, muitas das quais são evitadas
pela identificação de um scanner de impressão digital ou de heurística, no fim o código maldoso
tem de fazer um pedido bem definido ao sistema operativo. Visto que o defensor de
comportamento pode capturar todos esse pedidos, ele pode descobrir e bloquear ações maldosas
independentemente de como a lógica obscura do programa pareça ser[16].
A competência de verificar o software enquanto ele é executado em tempo real nitidamente
certifica um grande proveito ao defensor de comportamento, porém, ele também possui
desvantagens. Como o código maldoso necessita ser executado na máquina de destino antes que
todos as suas ações possam ser distinguidos, ele pode provocar muitos estragos ao sistema
antes que seja descoberto e intercetado pelo sistema de bloqueio de comportamento. Por
exemplo, um novo vírus pode confundir variados ficheiros aparentemente não importantes pelo
disco rígido antes de contaminar um único ficheiro e ser impedido. Embora a contaminação real
seja impedida, o utilizador poderá ser impedido de encontrar os seus ficheiros, sendo a causa
duma perda na eficácia ou, eventualmente, algo pior[16].
11
2.2.4 Funções Criptográficas de Resumo
A função H, presente na fórmula seguinte, retorna o valor de hash h, para uma determinada
menagem M:
h=H (M )
M é uma mensagem que pode variar de tamanho, já h, que é igual a
H (M ) é um valor de
tamanho fixo. O valor de hash é acrescentado à mensagem original, no momento em que a
mensagem é classificada ou aprovada como sendo correta. O recetor valida a mensagem
voltando a calcular o valor de hash [16].
Irá começar-se por examinar os requisitos para uma função de hash que vai ser usada para
autenticar a mensagem. Como as funções de hash regularmente são complexas, é proveitoso
analisar algumas funções de hash simples. Depois, vamos ver as várias aproximações para o
projecto da função de hash[16].
Requisitos para uma função de hash
O objetivo de uma função de hash é produzir uma 'impressão digital' de um ficheiro, mensagem ou
outro bloco de dados. Para ser proveitoso para o reconhecimento de uma mensagem, uma função
de hash H tem de ter as seguintes propriedades(adaptadas da lista em [11]):
1. H pode ser aplicado a um bloco de dados seja qual for o tamanho.
2. H gera uma resposta que tem tamanho constante.
3. H(x) é simples de calcular para cada x, o que torna as execuções de hardware e software
práticas.
4. Seja qual for o valor de x dado, é computacionalmente impossível descobrir x tal que H(x)
= h. Isso às vezes é chamado na literatura como resistência à primeira inversão ou
propriedade unidireccional (one-way property).
5. Seja qual for o bloco dado x, é computacionalmente impossível descobrir x≠ y tal que
12
H ( y )=H (x ) . Isso às vezes é chamado como resistência à segunda inversão ou
resistência fraca a colisões (weak collision resistance).
6. É computacionalmente impossível descobrir seja qual for o par
(x , y )
tal que
H (x)=H ( y ) . Isso às vezes é denominado como resistência a colisões ou
resistência forte a colisões (strong collision resistence)[16].
As primeiras três propriedades são requisitos para a utilização prática de uma função de hash
para o reconhecimento da mensagem[16].
A quarta propriedade, a resistência à primeira inversão, confirma que é acessível gerar um código
dando uma mensagem, mas é praticamente improvável fazer o contrário que é gerar uma
mensagem dando uma código. Esta propriedade é útil se a técnica de reconhecimento fizer
utilização de um valor secreto. O próprio valor secreto não é encaminhado, no entanto, se a
função de hash não for unidireccional, um invasor pode sem grande dificuldade encontrar o valor
secreto: se o invasor poder analisar ou interromper uma transmissão, pode ter acesso à
mensagem M e ao código de hash
hash para ter
obter
C=H ( S AB∥M ) . O invasor, assim, inverte a função de
S AB∥M =H −1 (C) , como o invasor já tem o M e
S AB∥M , é um assunto simples
S AB [16].
A quinta propriedade assegura que dada uma mensagem, não se pode encontrar uma mensagem
alternativa que obtenha o mesmo valor de hash. Esse objeto evita a burla quando um valor de
hash codificado for utilizado. Para estes casos, o opositor pode ler a mensagem e, assim sendo,
criar seu código de hash. Mas, como o opositor não possui a chave secreta, ele não poderá ser
capaz de modificar a mensagem sem ser apanhado. Se essa propriedade não fosse verdadeira,
um invasor seria capaz de acabar a seguinte sequência: primeiro analisar ou interromper uma
mensagem mais o seu valor de hash codificado; segundo, criar um valor de hash não codificado a
partir da mensagem; terceiro criar uma mensagem alternativa com o mesmo valor de hash[16].
A sexta propriedade diz respeito à resistência da função de hash a um tipo de ataque descoberto
como o ataque de aniversário (birthday attack), que será examinado mais à frente[16].
Funções de hash simples
Todas as funções de hash actuam utilizando os seguintes princípios gerais. O input (mensagem,
13
ficheiro, etc.) é olhada como uma sequência de blocos de n bits. No input é executado um bloco
de cada vez, num padrão repetido para gerar uma função de hash de n bits[16].
Uma das funções de hash mais simples é o OU exclusivo (XOR) bit a bit de cada bloco. Pode ser
expressado da seguinte forma:
Ci =bi 1 ' +' bi 2 '+' ... ' +' b ℑ
onde
Ci =i−ésimo bit do valor de hash , 1⩽i⩽n
m=número de blocos de nbits na entrada
bij =i−ésimo bit no j−ésimo bloco
= operação XOR
Esta formula cria uma semelhança simples para cada posicionamento do bit e é conhecida como
uma verificação de redundância longitudinal. Ela é regularmente eficaz para dados incertos, como
uma pesquisa de integridade de dados. Cada valor de hash de n bits é também da mesma
maneira comprovável. Assim, a hipótese de que um erro de dados ocorra num valor de hash que
não pode ser alterado é
−n
2
. Com dados editados, a função é menos eficaz porque é mais
previsível. Por exemplo, na maioria dos ficheiros de texto normais, o bit com mais significado de
cada octeto é sempre o zero. Assim, quando um valor de hash de 128 bits for utilizado, em vez de
uma eficiência de
−112
2
−128
2
, a função de hash desse tipo de dados apresenta uma eficiência de
[16].
Uma maneira simples de aperfeiçoar as coisas é dar-se um deslocamento (shift) circular de um
bit, ou rotação, sobre o valor de hash a seguir a cada bloco ser processado. O processo pode ser
resumido da seguinte forma:
1- No início, fixe o valor de hash de n bits como zero.
2- Verifique cada bloco progressivamente de n bits de dados da seguinte forma:
a. Faça uma rotação do valor de hash actual para a esquerda num bit.
b. Execute o OU EXCLUSIVO (XOR) do bloco com o valor de hash.
Isso tem a consequência de tornar imprevisto o input de forma mais completa e desviar qualquer
regularidade que apareça no input. A Figura 3 mostra esses dois tipos de funções de hash para
valores de hash de 16 bits[16].
Embora o segundo processo oferece uma boa medida de integridade de dados, ele é
praticamente ineficaz para estabilidade dos dados quando um código de hash codificado é
utilizado com um mensagem de texto claro. Dada uma mensagem, é uma assunto fácil de gerar
14
uma nova mensagem que produza aquele código de hash: prepare a mensagem pretendida e,
depois, junte um bloco de n bits que faça com que a nova mensagem e o bloco produzam o
código de hash pretendido[16].
Embora um XOR simples ou XOR com rotação (RXOR) seja incapaz se somente o código de
hash estiver codificado, ainda dá a impressão de que essa função pode ser utilizável quando a
mensagem e o código estiverem codificados, mas é preciso ter algum cuidado. Uma técnica que
originalmente foi proposta pelo National Bureu of Standards utilizava o XOR simples, usado em
blocos de 64 bits da mensagem e depois, uma codificação da mensagem completa, que utilizava
o modo de encadeamento de cifra de bloco (CBC). Podemos definir o esqueleto da seguinte
forma: data uma mensagem baseada numa ordem de blocos de 64 bits
X 1, X 2, ... , X N , declare o
código de hash C como o XOR bloco a bloco de todos os blocos e junte o código de hash como o
bloco final[16]:
C=X N +1= X 1 '+ ' X 2 ' +' ... ' +' X N
Figura 3: Duas funções de hash simples [16]
15
Após, codifique a mensagem completa, mais o código de hash, utilizando o modo CBC para gerar
a mensagem codificada
X 1, X 2, ... , X N . Em [4] indica muitos modos através das quais o texto
codificado dessa mensagem pode ser trabalhado de maneira que não seja descoberto pelo código
hash. Por exemplo, pela descrição do CBC, temos
X 1=IV ' +' D( K , Y 1)
X i=Y i−1' +' D(K , Y i)
X N +1=Y N '+' D ( K ,Y N +1)
Mas
X N +1 é o código de hash[16]:
X N +1= X 1 ' + ' X 2 '+' ... ' +' X N
X N +1=[IV ' +' D(K , Y 1)]'+ '[Y 1 ' +' D(K , Y 2)]' +' ... '+' [Y N −1 ' +' D( K , Y N )]
Como na equação anterior podemos fazer o OU Exclusivo dos termos sem nos importarmos com
a ordem, avança-se para o código de hash que não se altera se os blocos de texto codificado
fossem trocados[16].
Ataques de aniversário
Pressupor que código de hash de 64 bits seja usado. Pode considerar-se que isso é
suficientemente seguro. Por exemplo, se um código hash codificado C for enviado com a
mensagem não codificada representante M, então um opositor necessita achar M' tal que
H ( M ' )= H ( M ) para trocar outra mensagem e burlar o receptor. Em média, o opositor tem
de estar mais ou menos
263 mensagens para achar uma que acorda-se com o código de hash
da mensagem interrompida[16].
Contudo, um ataque alterado é realizável, com base no paradoxo do aniversário. Yuval sugeriu a
16
estratégia seguinte [15][16]:
1. O início, A, é colocado para 'rubricar' uma mensagem juntando o código de hash adequado
de m bits e codificado esse código de hash com chave privada de A.
2. O opositor produz
2
(m /2 )
variedades sobre a mensagem, todas conduzindo um sentido
semelhante. O opositor arranja um número semelhante de mensagens, todas as
variedades da mensagem burlista a ser trocada pela mensagem real.
3. Os dois blocos de mensagens são confrontados para descobrir um par de mensagens que
gere o mesmo código hash. A probabilidade de êxito, pelo paradoxo do aniversário, é
maior do que 0,5. Se nenhuma acordo for descoberto, mensagens válidas e burladas
adicionais serão criadas até que seja descoberto um acordo.
4. O opositor concede a variedade a A para firma. Essa firma pode então ser junta à
variedade burlista para entregar ao destinatário. Como as duas variedades tem o mesmo
código hash, elas geram a mesma firma; o opositor tem garantias de êxito, embora a
chave de criptografia não seja publicada[16].
Assim, se um código de hash de 64 bits for utilizado, a proporção de empenho requisitado será
apenas na ordem
2
32
[16].
17
Figura 4: Uma carta com 2^37 variações[2]
A produção de muitas variedades que comunicam o mesmo sentido não é árduo. Por exemplo, o
opositor poderia introduzir uma sucessão de pares de caracteres 'espaço-espaço-backspace'
entre as palavras em todo o documento. As variedades poderiam ser produzidas permutar
'espaço-espaço-backspace' nas instâncias escolhidas. Como opção, o opositor poderia
unicamente reformular a mensagem, mas conservar o sentido. A Figura 4 [2] contém um
exemplo[16].
O desfecho a ser extraído disso é que o comprimento do código de hash deve ser
fundamental[16].
18
Técnicas de encadeamento em bloco
Diversificadas ofertas foram feitas para funções de hash baseadas na utilização de uma técnica
de encadeamento de cifra de blocos, mas sem a chave secreta. Uma das primeiras ofertas foi a
de Rabin [12]. Separe uma mensagem M em blocos de comprimento fixo
M 1, M 2,. .. , M N e utilize
um sistema de criptografia simétrica, como DES, para estimar o código de hash G da seguinte
forma[16]:
H 0=valor inicial
H i=E( M i , H i−1)
G=H N
Isso é idêntico à técnica CBC, mas, nesse caso, não existe chave secreta. Assim como em
nenhum código de hash, esse diagrama está sujeito ao ataque de aniversário, e se o algoritmo de
criptografia for DES e se somente um código de hash de 64 bits for gerado, então o sistema
estará frágil[16].
Além disso, outra variante do ataque de aniversário pode ser utilizada, mesmo que o opositor
tenha acesso somente a uma mensagem e sua rubrica válida, e não possa conseguir diversas
rubricas. Eis, o cenário, vamos considerar que o opositor interrompe uma mensagem com uma
rubrica na forma de um código de hash codificado e que o código de hash não codificado tem m
bits de tamanho:
1. Utilize um algoritmo marcado no começo desta subsecção para estimar o código de hash
não codificado G.
2. Construa a mensagem que desejar na forma
3. Estime
4. Crie
Q1, Q2, ..., Q N −2 .
H i=E(Qi , H i−1) para 1⩽i⩽(N −2) .
2(m /2 ) blocos incertos; para cada bloco X, estime
blocos incertos adicionais; para cada bloco Y, estime
E( X , H N −2) . Crie
2(m /2 )
D(Y , G) , onde D é a função de
criptografia correspondente a E.
19
5. Com base no paradoxo do aniversário, vai haver probabilidade alta de um X e Y tais que
E( X , H N −2)=D (Y ,G) .
6. Faça a mensagem
Q1, Q2, ..., Q(N−2) , X , Y . Essa mensagem tem o código de hash G e,
consequentemente, pode ser utilizada com a rubrica codificada interrompida[16].
Essa forma de ataque é chamada como ataque meet-in-the-middle. Diferentes investigadores
recomendaram melhorias com o propósito de fortificar a técnica básica de encadeamento de
blocos. Por exemplo, Davies e Price [2] relatarem a seguinte variação:
H i=E( M i , H (i−1) )' +' H (i−1)
Outra variação, proposta em [7][16].
H i=E( H (i−1) , M i )' +' M i
Entretanto, esses dois diagramas têm se revelado frágeis a uma série de ataques [9]. De um
modo geral, pode-se provar que alguma forma de ataque de aniversário terá êxito contra qualquer
diagrama de hash abrangendo a utilização do encadeamento de cifra de blocos sem uma chave
secreta, desde que o código de hash derivado seja bastante pequeno (por exemplo, 64 bits ou
menos) ou que um código de hash maior possa se partir em sub-códigos autónomos [3][16].
Igualmente, é necessário ter precaução à invenção de outras técnicas para o hash. Muitas delas
tem pontos fracos [8][16].
2.3 – NSRL
A National Software Reference Library (NSRL) providencia um armazenamento de software
conhecido, perfis de ficheiros, valores de hash de ficheiros para uso das aplicações da lei e outras
organizações com investigações forenses de computador. A NSRL é composta por 3 grandes
elementos [27]:
1- Uma biblioteca física de pacotes comerciais de software.
2- Uma base de dados de informação sobre cada ficheiro dentro de cada pacote de software.
20
3- Uma base de dados mais pequena sobre a informação que é mais amplamente utilizada e
que é actualizada e divulgada trimestralmente. A base de dados é chamada de NSRL Reference
Data Set (RDS) e é NIST Special Database #28 [17].
O projecto NSRL foi iniciado em 1999 a pedido do FBI, do DoD Cyber Crime Center e do National
Institute of Justice. Este projecto é uma parte do programa de ciências forenses no escritório da
NIST de normas de aplicação da lei. A primeira divulgação da NSRL RDS foi em 2001 [27].
Em Fevereiro de 2006, a NSRL consiste em mais de 7083 milhões de pacotes de aplicação de
software que incluem mais de 34 milhões de ficheiros. Como muitos dos ficheiros são usados
dentro de múltiplas aplicações, há muitos ficheiros duplicados dentro da NSRL. Actualmente, há
mais de 10 milhões de ficheiros únicos [27].
Durante uma investigação forense, centenas de milhares de ficheiros podem ser encontrados. O
NSRL é usado para identificar ficheiros conhecidos. Isto pode reduzir a quantidade de tempo na
análise de um computador. Correspondências para ficheiros do sistema operativo comum ou
aplicações que não precisam de ser procuradas, quer manual ou electronicamente, para
evidências. Por exemplo, se o examinador forense estivesse à procura de imagens num sistema
Microsoft Windows 2000, uma comparação contra o NSRL identificaria mais de 4000 ficheiros de
imagem que provém da normal instalação do Windows. Estes ficheiros específicos poderiam ser
excluídos de análises futuras, como o conteúdo é conhecido, e não contém evidências [27].
Adicionalmente, algumas das equivalências do NSRL são usadas para determinar quais
aplicações de software foram usadas num sistema. Isto pode fornecer informação para o
investigador determinar como e onde procurar por provas. Por exemplo, se um sistema operativo
contém aplicações para descobrir palavras passe, logins, ou pacotes de rootkit, isto pode levar a
investigações futuras para determinar se um sistema foi utilizado para piratear dentro de outros
sistemas operativos. Este tipo de correspondência pode também ser usado, para resolver uma
questão de propriedade intelectual se um sistema contivesse um sistema proprietário para o qual
o dono do sistema não tinha licença [27].
21
NSRL valores de hash de ficheiros
O NSRL usa uma técnica matemática denominada hashing para produzir valores de hash
ficheiros. Actualmente, o NSRL usa 3 métodos para criar valores de hash: 2 são algoritmos
criptográficos de hash e 1 é uma técnica de procura de erros intitulado verificação de redundância
cíclica (CRC) [18]. É importante notar que há limites conhecidos no uso de CRC para gerar
valores de hash de ficheiros e os valores de hash CRC dentro do NSRL não são únicas, dado que
o mesmo tipo de assinatura pode ser associado a mais de um ficheiro [27].
Algoritmos de hash começam por pegar num input, neste caso um ficheiro, e usar matemática
avançada para comprimi-lo para uma cadeia de comprimento fixo de zeros e uns. Os algoritmos
criptográficos específicos de hash usados para criar valores de hash de ficheiros são funções num
sentido: um input dado vai sempre produzir o mesmo output e o processo não pode ser revertido.
O output é chamado hash e, no contexto do NSRL, é referido como valores de hash de
ficheiro[27].
Uma importante propriedade exibida por estes tipos de algoritmos de hash é que os seus outputs
são distribuídos ao acaso através do alcance inteiro dos possíveis outputs. Esta propriedade
explica porque funções de hash num sentido são usadas frequentemente como blocos de
construção de geradores de números aleatórios [19][20][27].
Estes algoritmos específicos de hash usados pela NSRL para gerar valores de hash de ficheiros
são MD5 e SHA-1. O MD5 é um algoritmo de hash mais velho e é definido pela Internet
Engineering Task Force, Request for Comment 1321 [22]. O SHA-1 é um Federal Information
Processing Standard (FIPS) premulgado pelo NIST como FIPS PUB 180-4 47. A terceira técnica é
uma versão de 32 bit do CRC método de procura de erros, como definido por [21]. Tanto o MD5
como o SHA-1 são algoritmos criptográficos de hash [27].
NIST está a planear acrescentar ficheiros de assinatura adicionais gerados por outros algoritmos
de hash no futuro, incluindo aqueles identificados em FIPS PUB 180-4(SHA-256, SHA-384, SHA512) [23][27].
2.3.1 – NSRLLOOKUP
O NSRLLOOKUP é um combinado entre um cliente (NSRLLOOKUP) e um servidor (NSRLSVR)
22
que permite utilizar a base de dados NSRL RDS. O NSRLSVR permite montar um servidor que
vai procurar numa base de dados por um certo valor de resumo (hash), se encontrar esse valor
significa que o ficheiro já é conhecido. Uma das particularidades do servidor NSRLSVR é que
carrega para a memória RAM toda a base de dados de resumos do NSRL RDS. O NSRLLOOKUP
é um programa que os analistas forenses usam para interagir com o servidor (NSRLSVR), foi
desenhado para ser utilizado pela linha de comandos em combinação com aplicações que
calculem resumos criptográficos a ficheiros de forma recursiva. Para calcular resumos
criptográficos, o programador do NSRLLOOKUP recomenda a aplicação de resumos
criptográficos md5deep, que é uma aplicação que calcula resumos criptográficos md5. Uma das
particularidades do NSRLLOOKUP é mostrar apenas os resumos dos ficheiros que não formam
encontrados na base de dados [24].
Com este capítulo deve reter-se que: uma assinatura de ficheiro é um número de identificação
único, localizado no início de um ficheiro que identifica o tipo de ficheiro, dando informações sobre
os dados contidos no ficheiro real; que as pessoas devem-se prevenir contra os vírus, detectando,
identificando e removendo os vírus que é a técnica mais fácil para o utilizador usar; o NSRL
providencia um armazenamento de software conhecido, perfis de ficheiros, assinatura de ficheiros
para uso das aplicações da lei e outras organizações com investigações forenses de computador
e por fim que o NSRLLOOKUP é um combinado entre um cliente (NSRLLOOKUP) e um servidor
(NSRLSVR) que permite usar a base de dados NSRL RDS.
23
3 – Desenvolvimento do NSRLSVR-BD
No contexto da análise forense digital a discos rígidos, ou imagens bit-a-bit destes, é normal que
se encontrem milhares e milhares de ficheiros. Uma técnica possível para limitar a quantidade de
ficheiros a analisar pelo técnico forense é a de fazer resumos (ou hash) dos vários ficheiros em
MD5 ou SHA1 e de os guardar numa BD.
Já existe uma aplicação servidor que armazena os vários resumos e que permite a sua consulta.
Todavia, esta aplicação guarda a BD em memória RAM, que conta já com 30 GBS, tal restringe a
sua utilização, pois poucos são os computadores existentes com esse tamanho de memória RAM.
O projecto reside na criação duma nova versão desta aplicação open source (um fork) que utilize
um sistema de gestão de bases de dados em detrimento da memória RAM, possibilitando assim a
sua utilização em equipamentos com pouca memória RAM.
3.1 – Requisitos
Este sub-capítulo envolve o levantamentos de requisitos para a criação da base de dados, e todos
os requisitos que a aplicação original tem visto ser uma réplica da original. O NRSL tem um
software que calcula a assinatura de ficheiros ou hash para cada ficheiro e outras informações
descritivas sobre cada ficheiro que são armazenados no NRSL RDS.
Foram identificados os seguintes requisitos neste projecto:
1. Armazenamento de dados na base de dados: como O NRSL RDS tem a sua estrutura para
armazenar os dados, vai ser criada uma estrutura com base nessa para a elaboração da
base de dados para termos a maior compatibilidade de dados possível.
2. Reconhecer os mesmos ficheiros que a aplicação original: a aplicação desenvolvida tem
que conhecer os mesmos hash que a aplicação original.
3. Usar o mesmo protocolo de comunicação: como a aplicação original comunica com uma
aplicação cliente já existente e como a aplicação desenvolvida é uma replica tem de
comunicar da mesma maneira que a original.
24
4. Multi-plataforma: a aplicação desenvolvida pode ser utilizada em vários sistemas
operativos.
3.2 – Modelo Conceptual e Relacional
Modelo Conceptual
Figura 5: Modelo Conceptual
Na Figura 5 temos o modelo conceptual da base de dados, cada retângulo significa uma tabela da
base de dados e nome dentro do retângulo significa o nome da tabela na base de dados, agora
explicaremos como se lê o relacionamento entre as relações que se lê da seguinte maneira, o
número 1 junto à tabela lê-se um e o n junto à tabela lê-se muitos, o que significa que um
ProductRecord pode ter muitos FileRecord, os outros como são iguais leêm-se da mesma maneira
de 1 para n.
Modelo Relacional
Depois de ter sido feito o modelo conceptual, foi feito o mapeamento do diagrama entidaderelacional (DER) para o modelo relacional. Como o NRSL RDS já tinha uma estrutura de uma
base de dados, foi usada essa estrutura para fazer o modelo relacional, não se precisou de
normalizar as tabelas na criação do modelo relacional da base de dados porque já estavam
normalizadas.
Na Figura 6, eis o diagrama do modelo relacional da base de dados que foi construída para a
25
nova aplicação, agora vai ser explicado que o sublinhado indica a chave primária da relação e que
os pontos negros indicam que os atributos da tabela não podem ser nulos, os pontos brancos
indicam que podem ser nulos e que as chaves estrangeiras são os mesmos nomes que são chave
primária noutra tabela. A ligação entre as tabelas, a linha que liga as duas tabelas contem 1 e n
para representar que 1 linha da tabela pode estar ligada a várias linhas da outra tabela.
Figura 6: Modelo Relacional
3.3 – Protótipo da aplicação
Como foi descrito anteriormente, neste projecto só vai ser elaborado a aplicação do lado do
servidor, a aplicação do lado cliente vai se manter a mesma por isso antes de a aplicação ser
elaborada vai ser demonstrado como a aplicação anterior usava o seu protocolo de comunicação
para comunicar com a aplicação cliente visto que só a aplicação do servidor é que vai ser
replicada.
Na Figura 7, para se iniciar a comunicação com o servidor, o cliente envia a versão da aplicação
para o servidor saber as funcionalidades que tem acesso e responder consoante essa versão.
Depois de o servidor validar a versão o cliente vai lhe enviar a mensagem iniciada por “query”
mais todos os hashes que o servidor vai verificar se existe na base de dados. Quando o servidor
verificar todos os hashes vai enviar uma mensagem ao cliente começado por “OK” mais um
número binário que representa se os hashes existem ou não na base de dados, isto é, cada
26
número vai representar um hash, 0 se não existe e 1 se existe. Depois de receber a mensagem o
cliente manda a mensagem “BYE” para o servidor para cancelar a comunicação. Quando o cliente
se desconecta do servidor mostra na linha de comandos, visto que o cliente e o servidor são
comandos
executados no terminal, os hashes e os respectivos caminhos dos ficheiros que não
existem na base de dados.
Figura 7: Comunicação Cliente-Servidor
Protótipo inicial
A aplicação original foi estudada usando-se o Wireshark para se perceber como funcionava o
protocolo entre o cliente e o servidor, analisou-se as suas funcionalidades e as versões de
comunicação com o cliente (2 versões) percebendo o código fonte da aplicação cliente. Apenas foi
implementado o protocolo de comunicação mais actual, já que não foi necessário assegurar a
retro-compatibilidade.
A aplicação agora desenvolvida utiliza um ficheiro de configuração que contém o IP do
computador onde está a base de dados, o nome da base de dados, o utilizador e password para
aceder à base de dados e o caminho da estrutura da base de dados. A Tabela 2 apresenta um
exemplo de ficheiro de configuração.
27
ip=127.0.0.1
bd_name=db_Forence
user=root
pass=
caminho_estrutura=./bd_estrutura/db.sql
Tabela 2: Exemplo do ficheiro conf
Também foi criado um ficheiro SQL que contem a estrutura da base de dados que será criada
caso não exista uma base de dados com o nome contido no ficheiro de configuração. A Tabela 3
apresenta um exemplo da estrutura que o ficheiro SQL contém para a criação da base de dados.
CREATE TABLE VersionRecord (
SHA1 varchar(40) NOT NULL,
RDSVersion varchar(40) NOT NULL,
PRIMARY KEY (SHA1) );
Tabela 3: Exemplo da estrutura da base de dados
A primeira funcionalidade que foi elaborada foi uma funcionalidade que não existe na aplicação
original devido ao facto da aplicação original carregar os dados que estão num ficheiro txt para a
memória RAM e assim a aplicação usa os dados que estão na memória RAM para verificar se
existe as hashes que lhe são passadas, no caso que está a ser desenvolvido vai ser carregados
os dados existentes nesse ficheiro txt para a base de dados já criada.
Na Tabela 4 será mostrado um exemplo de um comando para carregar dados de um ficheiro txt
para a base de dados.
java -jar nsrlsvr-bd.jar -u ProductRecord /home/fabio/NetBeansProjects/nsrlsvrbd/dist/NSRLProd.txt
Tabela 4: Exemplo de inserção na base de dados
Como mostra na Tabela 4 o comando para inserir os dados na base de dados caso não existam
esses dados. Vamos passar agora a explicar o funcionamento desse comando. Este comando
recebe como parâmetros 3 elementos, o primeiro é “-u” que indica à aplicação que é para inserir
os dados, o segundo que neste caso é “ProductRecord” indica o nome da tabela da base de
dados que queremos inserir visto que existe 4 ficheiros com dados para inserir, temos que fazer
este comando mais 3 vezes para preencher as tabelas FileRecord, ManufacturerRecord e
OperatingSystemRecord da base de dados e por fim temos o terceiro parâmetro que é
“/home/fabio/NetBeansProjects/nsrlsvr-bd/dist/NSRLProd.txt”que indica o caminho do ficheiro com
28
os dados para a inserção.
Para o desenvolvimento desta funcionalidade foi preciso criar algumas classes nomeadamente a
classe new FicheiroConf que permite ler os dados do ficheiro conf descrito anteriormente, a classe
new FicheiroSQL que permite ler a estrutura da base de dados também descrita anteriormente, a
classe new Conecao que vai permitira ligação à base de dados e criar a base de dados caso esta
não exista, uma classe para cada tabela com os mesmos atributos da tabela da base de dados e
classes especificas para aceder a cada uma das tabelas da base de dados.
1 public void adicionarProduct(ProductRecord pr) throws SQLException,
2 ClassNotFoundException, 2IOException, FileException {
3
try {
4
abrirConecao();
5
boolean existe;
6
String sql = "INSERT INTO ProductRecord (ProductCode, ProductName, "
7
+ "ProductVersion, OpSystemCode, MfgCode, Language, ApplicationType)"
8
+ "VALUES(?,?,?,?,?,?,?)";
9
10
existe = verificarExiste(pr.getProductCode(), pr.getOpSystemCode(), pr.getMfgCode());
11
12
if (existe == false) {
13
PreparedStatement stmt = conecao.getConnection().prepareStatement(sql);
14
stmt.setInt(1, pr.getProductCode());
15
stmt.setString(2, pr.getProductName());
16
stmt.setString(3, pr.getProductVersion());
17
stmt.setString(4, pr.getOpSystemCode());
18
stmt.setString(5, pr.getMfgCode());
19
stmt.setString(6, pr.getLanguage());
20
stmt.setString(7, pr.getApplicationType());
21
stmt.execute();
22
stmt.close();
23
}
24
fecharConecao();
25
} catch (SQLException e) {
26
throw new SQLException("Aconteceu um erro na inserção!");
27
}
28 }
Tabela 5: Exemplo de Código de inserção de dados
Na Figura 5, tem-se um exemplo de como a aplicação insere dados na base de dados, passamos
à sua explicação, primeiro começa por fazer a ligação a base de dados, a seguir verifica se esses
dados já existem (linha 10), se já existirem apenas fecha a ligação senão vai preparar os dados
29
para serem inseridos na base de dados
Outra funcionalidade que foi elaborada foi a funcionalidade de ajuda que mostra todos os
comandos que a aplicação tem e uma pequena inserção de como se usa esses comandos. Na
Tabela 6 será mostrado a utilização do comando de ajuda e na Tabela 7 será mostrada o output
do comando de ajuda mostrando todas as funcionalidades da aplicação.
java -jar nsrlsvr-bd.jar -h
Tabela 6: comando de ajuda
-h : mostar parametros
-S : iniciar servidor
-u Nome_Tabela Caminho_Arquivo: atualização da tabela da base de dados
Tabela 7: funcionalidades existentes na aplicação
E por fim teremos a última funcionalidade implementada nesta aplicação. Nesta
funcionalidade será mostrado como esta aplicação comunicará com a aplicação do
cliente. Primeiro será mostrado o comando para utilizar esta funcionalidade de depois
será mostrado como comunica e explicado como foi desenvolvida.
Na Tabela 8 mostra a utilização do comando para iniciar o servidor e ficar a espera que a
aplicação cliente se conecte.
java -jar nsrlsvr-bd.jar -S
Tabela 8: comando para iniciar o servidor
Nesta funcionalidade tiveram de ser criadas 3 classes para o seu desenvolvimento que
são elas a classe new Protocol onde se encontra o protocolo de comunicação com a
aplicação cliente, a classe new Server que inicia o servidor para estar a espera que o
cliente se conecte e por fim a classe new ServerThread que corre o protocolo quando um
cliente se conecta.
Agora será mostrado como esta aplicação comunica, como está a ser desenvolvido uma
aplicação que já existe não será preciso explicar muito o funcionamento desta
funcionalidade porque já foi explicado no início deste sub-capítulo como funciona a esta
funcionalidade da aplicação original e como esta aplicação tem de usar a mesma
30
aplicação cliente, por isso tem de usar o mesmo protocolo de comunicação que a
aplicação original.
Depois de mostrar como a aplicação comunica com a aplicação cliente, será apresentado
um trecho de código com o protocolo que esta aplicação usa para comunicar com a
aplicação cliente. Na 9 Tabela será mostrada o trecho do protocolo de comunicação com
a aplicação cliente.
31
1 public String processInput(String theInput) throws FileNotFoundException, IOException,
2 SQLException, ClassNotFoundException, FileException {
3
4
if (state == WAITING) {
5
theOutput = "Welcome to the server online Forence system";
6
state = VERSION;
7
} else {
8
if (state == VERSION) {
9
String parts[] = theInput.split(":");
10
11
if (parts[0].equals("Version")) {
12
if (parts[1].equals(" 2.0")) {
13
theOutput = "OK";
14
state = QUERY;
15
} else {
16
theOutput = "NOT OK";
17
}
18
} else {
19
theOutput = "NOT OK";
20
}
21
} else {
22
if (state == QUERY) {
23
String parts[] = theInput.split(" ");
24
String data = null;
25
boolean encontrado;
26
27
theOutput="";
28
if (parts[0].equals("query")) {
29
if (parts.length == 1) {
30
theOutput = "NOT OK";
31
} else {
32
for (int index = 1; index < parts.length; index++) {
33
encontrado=false;
34
35
if (!ishexdigest(parts[index])) {
36
theOutput = "NOT OK";
37
}
38
encontrado=fR.procurarHashExiste(parts[index]);
39
40
if(encontrado){
41
theOutput+="1";
42
}else{
43
theOutput+="0";
44
}
45
}
46
theOutput="OK " + theOutput;
47
}
48
}
49
}
50
}
32
51
52
53
}
return theOutput;
}
Tabela 9: protocolo de comunicação com cliente
Na Tabela 9, para se iniciar a comunicação o protocolo tem de passar do estado
“WAITING” para o estado “VERSION”, só depois é que realmente começa a comunicação.
Ao receber a primeira mensagem do cliente o servidor vai verificar-se a versão do cliente
é “2.0” porque esta aplicação só clientes nessa versão. Estando nesta versão a aplicação
passa ao estado “QUERY” onde o cliente manda uma mensagem “query” seguido de
todas as hash para analisar, depois de verificar que a mensagem do cliente está bem
construída vai analisar hash a hash e adicionar “0” se não encontrou essa hash ou “1” se
encontrou essa hash há mensagem que vai responder ao cliente. Com a mensagem
completa o servidor envia a mensagem ao cliente e este envia a mensagem “BYE” para
se desconectar do servidor e por fim descarta os que estiverem a “1” da mensagem e só
mostra no terminal os que estiverem a “0”.
Com este capítulo deve reter-se como funciona a aplicação e também os comandos
necessários ao funcionamento da aplicação que são: java -jar nsrlsvr-bd.jar -h para
mostrar as funcionalidade, java -jar nsrlsvr-bd.jar -S para iniciar a aplicação e por fim java
-jar nsrlsvr-bd.jar -u Nome_Tabela Caminho_Ficheiro para carregar os dados para a base
de dados.
33
4 – Avaliação da aplicação
Neste capítulo serão tratados os resultados que se obteve com a utilização da aplicação
desenvolvida e também com a utilização da aplicação original para fazer a comparação das
aplicações e também a metodologia utilizada para a avaliação dos resultados.
Depois de concluída a aplicação será preciso carregar os dados para a base de dados porque
enquanto os dados não forem carregados para aplicação não poderá ser utilizada para a
comparação com a original.
Nesta secção vai ser descrita a metodologia utilizada durante o desenvolvimento deste projecto.
Para um melhor desenvolvimento do projecto, este foi desenvolvido em 3 fases.
Numa primeira fase foram feitas as seguintes actividades: levantamento de requisitos, elaboração
do modelo conceptual, conversão do modelo conceptual para o modelo relacional e escolha do
sistema de gestão de base de dados e implementação da base de dados. Na segunda só se
elaborou uma tarefa que foi elaboração da aplicação e na terceira e última fase foram executados
testes para serem realizados na aplicação.
4.1 – Carregar dados para base de dados
Começou-se por carregar todos os dados para a base de dados, mas logo se percebeu que ao
carregar todos os dados para a base de dados iríamos ter hashes repetidas devia ao facto de
existir o mesmo ficheiro para vários sistemas operativos, o que tornaria a consulta a esses dados
mais lenta e como não vai ser preciso ter esses dados todos visto que a aplicação do cliente só
lhe interessa os hashes e não outras características como o nome do ficheiro, a versão do sistema
operativo entre outras. Com isso foi optado em reduzir os dados para só ter na base de dados
hashes únicos, isto é, não ter hashes repetidos na base de dados.
Na Tabela 10 será mostrado uma parte de um ficheiro txt que contém dados para serem
carregados para a base de dados.
34
1 "MfgCode","MfgName"
2 "1","321 Studios"
3 "10","ADS Tech"
4 "100","Avantos"
5 "1000","Typeright Software"
6 "1001","UBI Soft Entertainment"
7 "1002","US Robotics"
8 "1003","Ubisoft"
9 "1004","Ulead Systems"
10 "1005","University"
11 "1006","Unknown"
12 "1007","Unreal Visions"
13 "1008","V Communications Inc."
14 "1009","VCR Inc."
15 "101","Avery Software"
16 ...
Tabela 10: Exemplo de um ficheiro para carregar dados base de dados
No exemplo que está na Tabela 10 podemos observar como os dados vêem para ser carregados
para a base de dados e também como vem os outros ficheiros que temos que carregar. Como foi
utilizado a estrutura da base de dados da aplicação original para guardarmos os dados, demorou
algum tempo a introduzir todos estes dados na base de dados por causa que são 4 tabelas que
tem que ser preenchidas, isto equivale a 4 ficheiros. Embora a aplicação não use todos estes
dados porque só lhe interessa o ficheiro onde está os hashes, que é o ficheiro que contem mais
dados e é o ficheiro que a aplicação original carrega para memória RAM.
Antes de os dados serem carregados foi feito um script para auxiliar no carregamento dos dados
para a base de dados, nesse script também mede o tempo que cada ficheiro demorou a ser
carregado para a base de dados, visto que o ficheiro que contém os hashes contém muitos dados.
Para isso o ficheiro, já vem partido em 4 ficheiros, mas mesmo assim torna-se muito custoso para
um computador carregar esses damos por isso cada um desses ficheiros foram partidos em
300.000 linhas dando há volta de 103 ficheiros, o que equivale a carregar só para a tabela
Filerecord 412 ficheiros, faltando as outras serem carregadas.
Na Tabela 11 será mostrado um exemplo de um script utilizado para o auxilio da introdução,
medição do tempo que demorou a ser introduzido que regista isso tudo num ficheiro de logs.
35
1 #!/bin/bash
2 for file in /home/fabio/NetBeansProjects/nsrlsvr-bd/InputBDT1/x*
3 do
4
date >> registosTempoUpdateT1.log
5
echo $file >> registosTempoUpdateT1.log
6
{ time java -jar nsrlsvr-bd.jar -u FileRecord $file ; } 2>> registosTempoUpdateT1.log
7
sleep 1
8 done
Tabela 11: Exemplo de um script para auxilio a carregar dados na base de dados
Como podemos observar no script, ele procura num determinado directório os ficheiros que tem
que carregar para ler os dados, enquanto esses ficheiros não acabarem o script vai registando a
data e hora, o caminho do ficheiro e o tempo que demorou a ser inserido para todos os ficheiros
que forem encontrados no directório.
Na Tabela 12 vai mostrar-se um exemplo do registo que o script faz quando insere os dados na
base de dados.
1 Sáb Mai 3 11:09:05 WEST 2014
2 /home/fabio/NetBeansProjects/nsrlsvr-bd/InputBDT1/xaa
3
4 real
63m28.214s
5 user
12m1.404s
6 sys
4m23.611s
7 ...
Tabela 12: Exemplo de registo log script
Como mostra na Tabela 12, o script regista a data e hora de quando foi executado o script, o
caminho do ficheiro que foi carregado e por fim o tempo que demorou a inserir os dados desse
ficheiro na base de dados. Este é um exemplo de um terminal a correr, como tínhamos 3 terminais
a correr ao mesmo tempo, são criados 3 ficheiros iguais a este, o que significa que foram
introduzidos 3 ficheiros em 63m28.214s.
Depois dos terem sido todos inseridos vai ser feito uma estimativa do tempo gasto para carregar
todos os dados para a base de dados. Na 13 Tabela vai ser mostra os tempos aproximados que
os dados demoraram a ser introduzidos na base de dados.
36
Nome das tabelas da base de
dados
Tempo de inserção na base de Dados a inserir
dados
ManufacturerRecord
0m49.922s
3527
OperatingSystemRecord
0m16.421s
1061
ProductRecord
8m42.850s
39951
FileRecord
≈ 8 dias
36.108.465
Tabela 13: Registos da inserção de dados na base de dados
Como se pode perceber ainda demorou alguns tempo a carregar os dados para base de dados,
convém descrever que estes dados foram introduzidos da seguinte maneira um computador
estava a executar a aplicação e outro computador estava a guardar os dados na base de dados,
isto é, os dois pcs estavam ligados por um cabo de rede onde que executava a aplicação
carregava os dados do ficheiro e os enviava para o outro pc guardar os dados na base de dados.
Se fosse tudo feito no mesmo computador demoraria muito mais tempo e tempo era algo que não
tínhamos devido ao facto de termos perdido tempo a fazer testes para introduzir todos os dados
existentes na base de dados da NSRL.
4.2 – Testes do protótipo
Depois de os dados estarem devidamente todos introduzidos na base de dados, vai começar-se a
fazer testes a aplicação desenvolvida.
Primeiro, será feito um script para que o cliente guarde todos os hashes e os caminhos dos
ficheiros desses hashes num ficheiro txt para mais tarde ser avaliado para verificar se a aplicação
desenvolvida e a aplicação original devolvem os mesmos ficheiros não conhecidos. Também
mediremos os tempos da análise da aplicação original e da aplicação desenvolvida para analisar
se compensa usar a aplicação desenvolvida.
Para a validação desta aplicação vamos fazer alguns testes para verificar se aplicação
desenvolvida está a comportar-se como a original.
Na Tabela 14 será mostrado o script que foi elaborado para guardar os hashes e os caminhos
desses hashes num ficheiro para facilitar na comparação que vai ser feita entre a aplicação
37
elaborada e a aplicação original.
#!/bin/bash
md5deep -r /bin/ | nsrllookup -s 127.0.0.1 >> registosFicheiros.log
Tabela 14: Exemplo do script de registar ficheiros não conhecidos
Na Tabela 14 é mostrado o script que foi desenvolvido para ajudar a ver os ficheiros que a
aplicação desenvolvida ou a aplicação original não conhecem, visto que como as aplicações são
executadas num terminal podem não mostrar todos os ficheiros não conhecidos. Por isso foi
desenvolvido este script para facilitar essa visualização dos ficheiros, agora passaremos a
explicação o funcionamento do script que funciona da seguinte maneira, o md5deep é um
comando que foi instalado para gerar os hashes md5 de todos os ficheiros existentes num
determinado directório, “-r” indica que é recursivo e que vai a sub-directórios e a seguir ao “-r” vem
o caminho do directório. O “|” indica que vai usar o resultado do comando anterior para o novo
comando que neste caso vai devolver todos os md5 calculados para o comando nsrllookup. O “-s”
do comando nsrllookup indica que a seguir a esse parâmetro deve vir o ip do servidor, onde a
aplicação servidor a correr. Por fim temos “>>” que vai indicar que escrever os resultados do
comando nsrllookup no ficheiro registosFicheiros.
4.2.1 – Requisitos a testar
Agora vai ser feito uma lista que identifica os itens – use cases, requisitos funcionais e não
funcionais – que serão identificados como alvos de teste. Essa lista vai representar o que vai ser
testado.
Testes da base de dados
- verificar se o sistema introduziu os dados correctamente;
- verificar se o sistema é capaz de ir buscar os dados;
Teste funcional
- verificar se a aplicação comunica bem com a aplicação cliente;
38
Teste da interface do utilizador
- verificar através de todos os uses cases, que os comandos são os mais simples para o
utilizador perceber a sua utilização rapidamente;
Teste de performance
- verificar o tempo de inserção dos dados na base de dados;
- verificar os tempos que a aplicação demora a pesquisar os hashes num determinado
directório;
Testes de Instalação
- verificar se a instalação da aplicação desenvolvida ocorre normalmente em todos os
sistemas operativos;
4.2.2 – Estratégia de testes
Agora, serão demonstrados os testes referentes às transacções lógicas de negócio. Essas
transacções vão ser definidas como funções específicas que o utilizador final da aplicação vai ser
suposto de executar ao usar esta aplicação.
Tipos de Testes
39
Objectivo do teste:
Garantir que os métodos e processos de acesso à base de dados
funciona correctamente e sem corrupção de dados.
Técnica:
- Invocar cada método e processo de acesso à base de dados, usando
cada um com dados válidos e inválidos.
- Inspecionar a base de dados para garantir que os dados foram
preenchidos como pretendido, que todos os eventos da base de dados
ocorreram apropriadamente.
Critério de
Finalização:
Todos os métodos e processos de acesso à base de dados funcionam
como planeado e sem nenhuma corrupção de dados.
Considerações
Especiais:
- O teste pode necessitar de um ambiente de desenvolvimento ou um
SGBD para inserir ou modificar os dados diretamente na base de dados.
- Processos devem ser invocados manualmente.
- Número de registos limitados devem ser usados para aumentar a
visibilidade de elementos não-aceitáveis.
Tabela 15: Teste de integridade de dados e da base de dados
Na Tabela 15 será mostrado um teste que foi desenvolvido para ser garantido que na aplicação
que vai ser entregue ao cliente, os métodos e processos de acesso à base de dados funcionam
corretamente, visto é uma funcionalidade muito importante porque sem isso a aplicação fica
praticamente impossível de ser usada.
Objectivo do teste:
Garantir que as funcionalidades são alvo de testes.
Técnica:
Executar cada funcionalidade, usando dados válidos e inválidos para
verificar o seguinte:
- Os resultados esperados ocorrem quando dados válidos são usados.
- As mensagens de erro ou aviso apropriadas são exibidas quando dados
inválidos são usados.
- Cada regra de negócio é aplicada corretamente.
Critério de
Finalização:
- Todos os testes planeados foram executados.
Considerações
Especiais:
Nenhum
- Todos os defeitos identificados foram tratados.
Tabela 16: Teste de Funções
Na Figura 16 será exposto um teste que foi desenvolvido para ser garantido que na aplicação que
vai ser entregue ao cliente, as funcionalidade principais nomeadamente o protocolo de
comunicação entre o servidor e cliente funcione nas melhores condições possíveis, porque
também é uma funcionalidade muito importante para a aplicação desenvolvida, visto que se a
aplicação desenvolvida não comunicar com a aplicação cliente, esta aplicação não terá muito
40
interesse.
Objectivo do teste:
Garantir que os comandos da aplicação desenvolvida estão o mais
simples possível e de fácil perceção.
Técnica:
- avaliação por uma pessoa que vá usar a aplicação desenvolvida.
Critério de
Finalização:
- Depois de os comandos estarem simples e estarem fáceis de perceber.
Considerações
Especiais:
Nenhum
Tabela 17: Testes da interface do utilizador
Na Tabela será exibido um teste que foi desenvolvido para ser garantido que na aplicação que vai
ser entregue ao cliente, a interface do utilizador seja a mais simples possível, que seja de fácil
perceber e que seja intuitivo para que cliente esteja à vontade para usar a aplicação desenvolvida.
Objectivo do teste:
Verificar a performance da pesquisa de hashes nas seguintes condições:
- directório com poucos ficheiros.
- directório com muitos ficheiros.
Verificar a performance da inserção de dados na base de dados.
Técnica:
- Usar procedimentos de teste desenvolvidos para os Teste de Funções.
- Usar procedimentos de testes desenvolvidos para os testes à base de
dados.
Critério de
Finalização:
- Finalização com sucesso de todos os testes feitos aos diretórios.
Considerações
Especiais:
Nenhum
- Finalização com sucesso de todos os testes feitos à performance de
inserção de dados
Tabela 18: Teste de Performance
Na Figura 18 será indicado um teste que foi desenvolvido para ser garantido que na aplicação que
vai ser entregue ao cliente, a aplicação desenvolvida tenha a melhor performance nas pesquisa
que faz à base de dados à procura dos hashes e também se se pode otimizar a inserção de dados
na base de dados.
41
Objectivo do teste:
Verificar que os testes são alvo de instalação apropriadamente em cada
sistema operativo nas seguintes condições:
- uma nova instalação, num novo computador, que nunca fora
anteriormente instalada a aplicação desenvolvida.
Técnica:
Começar ou executar a instalação.
Critério de
Finalização:
Quando as instalações funcionem em todos os sistemas operativos.
Considerações
Especiais:
Nenhum.
Tabela 19: Teste de instalação
Na Tabela 19 estará evidenciado um teste que foi desenvolvido para ser garantido que na
aplicação que vai ser entregue ao cliente, a aplicação desenvolvida possa ser instalada em todos
os sistemas operativos como foi previsto.
4.3 – Resultados
Neste sub-capítulo vai ser mostrado os resultados que foram obtidos na comparação entre a
aplicação desenvolvida e aplicação original. Como foi descrito em cima foi elaborado primeiro o
carregamento dos dados para a base de dados, visto que sem isto não se podia testar a aplicação
desenvolvida, já que a aplicação original carrega o ficheiro para memória RAM. À medida que os
dados foram introduzidos, o script criado para apontar os tempos, foi guardando todos os nomes
dos ficheiros introduzidos e os seus respectivos tempos, para agora poderem ser avaliados, para
que o cliente final tenha uma ideia do tempo que demorou a carregar os dados, nas condições
especificadas em cima.
Depois de os dados terem sido introduzidos, vai ser passado a fase de testes descritos no subcapítulo anterior. Começou-se pelo teste da verificação se a aplicação desenvolvida tinha
introduzido os dados correctamente na base de dados, enquanto este teste não tivesse concluído
a 100% não se podia avançar para outros testes.
Estando os dados introduzidos correctamente na base de dados, passou-se para o teste se a
aplicação desenvolvida conseguia aceder aos dados que estavam na base de dados, visto ser
importante conseguir aceder aos dados sem problemas nenhuns. Conseguindo-se aceder aos
dados já se estava pronto para passar ao teste seguinte que era o teste funcional, isto é, são os
42
testes das funcionalidades da aplicação desenvolvida, visto que só temos uma funcionalidade
principal que é o protocolo de comunicação entre o servidor e o cliente, só vai ser feito o teste a
essa funcionalidade. Antes de este teste ser elaborado foi preciso perceber como a aplicação
original comunica com o cliente porque a aplicação desenvolvida tinha de comunicar no mesmo
protocolo que a aplicação original. Percebido o seu funcionamento foi elaborados alguns testes
para verificar-se se a aplicação desenvolvida estava a funcionar como a aplicação original.
Estando a aplicação desenvolvida a usar o protocolo de comunicação correctamente, passou-se
para os testes da interface do utilizador, visto que a aplicação desenvolvida não tem parte gráfica,
só foram feitos testes para deixar os comandos da aplicação desenvolvida mais simples para o
utilizador usar e que os comandos sejam de fácil percepção.
Os testes que serão feitos a seguir a estes vão ser os testes da performance, que indicaram os
tempos de inserção de dados na base de dados e tempos das pesquisas de hashes nos
directórios, para que se possa avaliar se pode ser optimizado o tempo de inserção de dados na
base de dados ou o tempo das pesquisas de hashes na base de dados.
Como já se falou num sub-capítulo deste capítulo sobre os tempos de inserção de dados na base
de dados e que foram optimizado o mais possível dentro das condições que tínhamos para a
inserção porque podia ser mais se tivéssemos um computador computacionalmente mais potente.
Agora será abordado o tempo que foi nas pesquisas de hashes tanto na aplicação desenvolvida
como na aplicação original. Na Tabela 20 vai ser mostrado alguns exemplos de pesquisas de
hashes da aplicação desenvolvida e da aplicação original do mesmo directório para se poder
comparar os tempos que demoram a pesquisar os mesmos hashes.
Pasta
Aplicação desenvolvida
Aplicação original
/bin
20m12.075s
0m1.474s
/home/fabio/Transferências
31m53.890s
7m16.178s
Tabela 20: Tempos de pesquisas
Como pode ser visto a aplicação desenvolvida demora mais tempo que aplicação original, o que é
normal visto que a aplicação usa a memória RAM.
Por fim, serão mostrados os últimos testes, os testes de instalação que nos mostrará se a
43
aplicação desenvolvida poderá ser instalada em todos os sistemas operativos. A aplicação foi
desenvolvida numa linguagem portável.
Com este capítulo é importante reter que a aplicação desenvolvida demora algum tempo para
introduzir os dados na base de dados, outra parte importante deste capítulo são os testes que
foram desenvolvidos para garantir que a aplicação desenvolvida funciona de acordo com o
previsto e por fim os resultados com a descrição relativamente aos testes desenvolvidos.
44
5 – Conclusão
A análise forense a equipamentos informáticos requer frequentemente a técnicas de identificação
de ficheiros. Uma aplicação que o permite fazer é o NSRLSVR que, por carregar a totalidade da
base de dados de identificação de ficheiros (resumos criptográficos) para memória RAM o que
torna a aplicação muito rápida, mas muito exigente em termos de recursos de hardware.
O objetivo deste projeto consistiu no desenvolver de uma nova versão da aplicação NSRLSVR, de
nome NSRLSVR-BD, para, mantendo o seu funcionamento, guardar os dados numa base de
dados. Tal permitirá a sua execução em PCs com especificações de hardware menores.
O desenvolvimento deste projeto implicou a criação de uma base de dados, o estudar do
funcionamento da aplicação original, bem como do respetivo protocolo de comunicação. A
aplicação NSRLSVR é utilizada em conjunto com uma aplicação cliente. Funcionalidade esta que
também foi assegurada pelo atual projeto, podendo ser utilizada com a aplicação cliente do
NSRLSVR original.
Os resultados obtidos com este trabalhado demonstram que a aplicação desenvolvida é 7,14
vezes mais lenta a pesquisar hashes que a aplicação original, algo já esperado. A aplicação
desenvolvida torna-se, no entanto, mais usável pois pode ser utilizada em todos os sistemas
operativos e em PCs com menores recursos de memória RAM. A aplicação original foi
desenvolvida na linguagem C++ e apenas para execução em sistemas Linux. Neste projeto foi
utilizado a linguagem Java para tornar a aplicação desenvolvida numa aplicação multi-plataforma.
45
Referências
[1] D. Chess. “The future of viruses on the Internet,” Virus Bulletin International Conference, San
Francisco, Califórnia,USA, Outubro de 1997.
[2] D. Davies and W. Price. Security for computer networks, Wiley, 1989.
[3] R. Jueneman, “Electronic document authentication,” IEEE Network, Abril de 1987.
[4] R. Jueneman and S. Matyas and C. Meyer, “Message authentication,” IEEE Communications
Magazine, Setembro de 1988.
[5] J. Kephart and G. Sorkin and D. Chess and S. White, “Fighting computer viruses”. Scientific
American, Novembro de 1997.
[6] J. Kephart and G. Sorkin and B. Swimmer and S. White. “Blueprint for a computer immune
system,”, Virus Bulletin International Conference, San Francisco, Califórnia,USA, Outubro de 1997.
[7] C. Meyer and M. Schilling. “Secure program load with modification detection code,”
SECURICOM 88, 1988.
[8] C. Mitchell and F. Pipper and P. Wild. “Digital signatures,” Em [13].
[9] S. Miyaguchi and K. Ohta and M. Iwata. “Confirmation that Some hash functions are not
collision free”, EUROCRYPT '90, 1990; publicado por Springer-Verlag.
[10] C. Nachenberg. “Computer virus-antivirus coevolution,” Communications of the ACM, Janeiro
de 1997.
[11] J. Nachvatal. “Public key cryptography,” Em [13].
[12] M. Rabin. “Digitalized signatures”. Em Foundations of Secure Computation, R. DeMillo and D.
Dobkin and A. Jones and R. Lipton. eds. Nova York: Academic Press, 1978.
[13] G. Simmons, ed. Contemporary cryptology: the science of information integrity. Piscataway:
IEEE Press, 1992.
46
[14] P. Stephenson, “Preventive medicine”. LAN Magazine, Novembro de 1993.
[15] G. Yuval. How to swindle rabin. Cryptologia, Julho de 1979.
[16] W. Stallings. Criptografia e segurança de redes Princípios e práticas. São Paulo, Pearson
Prentice Hall, 2008.
[17] National Institute of Standards and Technology, NIST Special Database #28, National
Software Reference Library, http://www.nist.gov/srd/nistsd28.cfm, (Fevereiro 2000) [Último Acesso:
Maio 2014].
[18]
T.
Boland
and
G.
Fisher,
Selection
of
Hashing
Algorithms,
http://www.nsrl.nist.gov/Technical_papers.htm, (Junho 2000) [Último Acesso: Maio 2014].
[19] National Institute of Standards and Technology, Digital Signature Standard (DSS),
FIPS 186-4, http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf, (Julho 2013) [Último
Acesso: Maio 2014].
[20] B. Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C,
John Wiley and Sons, New York (1996).
[21] International Standards Organization, Data Communications: High-level Data Link
Control Procedures--Frame Structure (ISO 3309), IS 3009 (3rd Edition), (10-1- 1984).
[22] R. Rivest, RFC 1321: The MD5 Message-Digest Algorithm, http://ietf.org/rfc/rfc1321.txt, (Abril,
1992) [Último Acesso: Maio 2014].
[23] National Institute of Standards and Technology, Secure Hash Standard, FIPS PUB 180-4,
http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf, (Março 2012) [Último Acesso: Maio
2014].
[24] A. Pinto, “Guião 2 – Análise Forense Digital a Sistemas de armazenamento de dados”,
Setembro de 2013.
[25] P. Eugene, What Is a File Signature?, http://www.wisegeek.com/what-is-a-file-signature.htm,
47
(Maio 2014) [Último Acesso: Maio 2014].
[26] Wikipedia, List of file signatures, http://en.wikipedia.org/wiki/List_of_file_signatures, (Maio
2014) [Último Acesso: Maio 2014].
[27]
S.Mead,
Unique
File
Identification
in
the
National
Software
Reference
Library,
http://www.nsrl.nist.gov/Documents/analysis/, (Maio 2006), [Último Acesso: Maio 2014].
48