A Câmara de Deputados pretende, até o final do ano, votar um conjunto de três projetos de lei que atualmente tramitam no Congresso Nacional, que estabelecerão a legislação da internet brasileira. Dois dos projetos tratam da tipificação de crimes e o terceiro regulamentará o provimento de acesso à internet, estabelecendo direitos e deveres aos provedores e usuários. É o PL 2126/2011, o Marco Civil da Internet. Quem trabalha com investigação e perícia de crimes cometidos com uso de tecnologia, sabe o quanto é importante termos este regulamento. Entretanto não pense que isso é novidade pois os projetos que deram origem ao Marco Civil da Internet são bem antigos. Um dos projetos de lei é de autoria do então Deputado Federal Antônio Carlos Pannunzio (PSDB/SP), o PL 3016/2000 que já previa o registro de acesso à internet. Após tantos anos este projeto foi apensado ao PL 2126/2011 do Executivo que tramita em regime de urgência e deverá ter o parecer do relator, o Deputado Federal Alessandro Molon (PT/RJ) até o dia 16.

Neste último post vamos abordar a finalização dos exames e a emissão do relatório final (o Laudo Pericial).

Finalizado os exames, é o momento da preparação do Laudo Pericial, que deverá conter os seguintes itens:

1. Informações sobre o solicitante da perícia, como nome, lotação e número do documento que requisita a perícia;
2. Citar de forma clara e concisa o objetivo dos exames. (Note que o expediente legal que requisita os exames deverá conter o objetivo da perícia bem definido);
3. Descrição dos objetos que serão periciados e seu estado atual;
4. Descrição da metodologia empregada nos exames;
5. Descrição dos exames em linguagem simples e de fácil compreensão (lembre-se que quem for ler o seu relatório pode não ter o seu conhecimento). Se houver necessidade da utilização de termos técnicos, coloque seu significado sob a forma de notas de rodapé;
6. Conclusão do relatório informando sucintamente aquilo que foi encontrado, encerrando o Laudo.

Após a emissão do relatório, todos os documentos gerados devem ser arquivados juntamente com uma cópia do Laudo Pericial e uma cópia da mídia que eventualmente acompanhe o relatório (Esta mídia pode conter arquivos extraídos do dispositivo analisado, principalmente quando as quantidades dos achados impossibilitem a impressão completa do material).

A documentação deverá conter o expediente que solicita a perícia, o mandado judicial (se houver), contagem e descrição das provas, cadeia de custódia, informações sobre o estado das mesmas e todo e qualquer documento que venha a ser acrescentado no decorrer da perícia.

Após a revisão final por um segundo perito, o Laudo Pericial estará pronto para ser encaminhado ao solicitante. Em caso de discordância por parte do revisor deverá ser adotado o procedimento da instituição para esse tipo de situação.

Este vídeo foi produzido pela Associação Baiana de Criminalística em conjunto com a TV Câmara Salvador, parte de uma série sobre a Perícia Criminal na Bahia. O vídeo original e outros sobre o tema você pode encontrar no canal da TV Câmara, no Vimeo.

Neste post vamos analisar com mais detalhes os campos de cabeçalho que podem fornecer informações importantes para a identificação de origem e autor, conhecidos como Trace Fields ou campos de rastreamento que são de grande importância na identificação real do remetente.

Continuaremos a utilizar o cabeçalho da figura 5 do post anterior como referência para os campos discutidos a seguir.

Figura 5 – Cabeçalho de uma mensagem resultante de um diálogo

X Headers são campos de cabeçalhos iniciados pela letra X maiúscula seguido de um hífen, de caráter informativo, que podem ser extremamente úteis na identificação da autoria de um e-mail. Os X Headers mais comuns são:

“X-Mailer:” Indica qual o cliente de correio foi utilizado para compor a mensagem.

“X-Yahoo-Post-IP:”, “X-AOL-IP:”, “X-Apparently-From:”, “X-SenderIP:”, “X-Originating-IP:”, etc. Indicam o endereço IP da conexão à internet que o usuário utilizou para o envio da mensagem. Se este usuário utilizou-se de um artifício qualquer para encobrir seu endereço IP real, o conteúdo não terá nenhum valor.

“X-OriginalArrivalTime:” Informa a data e hora do envio da mensagem no fuso (UTC) seguido dessa mesma informação no formato Windows Filetime, que consiste em um valor de 64 bits representado pelo número de intervalos de 100 nano segundos a partir de 01 de janeiro de 1601. Esse valor pode ser convertido para confirmação da hora real do envio e, associado ao endereço IP, indicarão o “quando” e “onde”.

“Message-ID:” Este campo contém um identificador único gerado pelo primeiro servidor de correio que submete a mensagem (MSA) e tem um formato parecido com “ID”@“HOST”, onde o ID constitui um identificador composto por uma sequência de caracteres (gerados por diversos algoritmos), inteligíveis ou não. HOST é o nome da máquina que gera o identificador. Se o host que gerou o ID fizer parte de um domínio, HOST será o nome do domínio. Se o Message-ID apresentar discrepâncias com o padrão A@B, como uma string vazia, ausência do “@” ou ainda apresentar um nome de host diferente do MSA, pode implicar na utilização de um servidor de correio eletrônico com open relay, diferente do domínio original do remetente ou uma mensagem forjada, como vimos na figura 3 do terceiro post.

Os campos “In-Reply-To:” e “References:” só aparecem quando uma mensagem é respondida ou encaminhada. O campo “References:” também pode ser utilizado para identificar uma conversação.

“In-Reply-To:” Contém o Message-ID da mensagem que está sendo respondida/encaminhada.

“References:” Contém o(s) Message-ID(s) da(s) mensagem(ns) que está(ão) relacionadas com a mensagem em análise.

Os campos “Received:” relacionam os servidores MTAs por onde passaram a mensagem, incluindo o MSA e o MDA (Ambos são MTAs). Este campo pode conter informações forjadas e se isso ocorrer, estas informações estarão sempre nos primeiros campos, já que há um empilhamento a partir do primeiro (base) até o último (topo) servidor.

O campo “Received:” possui a seguinte sintaxe:

Received: from “A” (Nome de A [IP de A])(Obs.) by B (Informações de B) via C with D id E for F; date-time

Onde A é o host de origem, B é o servidor que recebeu a mensagem e gera o campo “Received:“, C é o protocolo, D é o serviço, E é o id gerado pelo servidor B e F é a conta do destinatário. Date-time é o instante em que ocorre a entrega da mensagem à B. As variáveis A, B, C, D, E e F podem não estar todas no conteúdo do campo, variando de acordo com cada situação. Vejamos alguns exemplos.

Exemplo 1:

Figura 6: Campo “Received:” sem a variável “C”

Podemos dizer que neste caso a mensagem foi composta em um cliente de correio (Microsoft Outlook Express 6.00.2900.5931) instalado na “estação_remetente”. Podemos ver que a estação não faz parte de um domínio pois o Message-ID tem como “HOST” a “estação_remetente”. Caso a estação fizesse parte de um domínio (por exemplo: dominio_destinatario.org), o “Message-ID:” teria como valor <44206789192B4FB4ADA3D69390304921@dominio_destinatario.org>.

Exemplo 2:

Figura 7

Este campo “Received:” da figura 7 não apresenta o host de origem (A) porque o host de destino (B) está no mesmo domínio de A.

Exemplo 3:

Figura 8

O campo “Received-SPF:” indica que o servidor implementou o SPF (Sender Policy Framework). O SPF é um padrão aberto que especifica um método técnico para evitar a falsificação endereço do remetente (envelope), comumente chamado de return-path, que é utilizado pelos MTAs para enviar a mensagem de um para o outro especificando o endereço de retorno em caso de falha. O SPF dificulta a utilização de endereços forjados através de políticas de permissão de envio de mensagens oriundas de domínios confiáveis.

Veja que o campo “Received:” identifica o nome do host remetente através do comando HELO ou EHLO e o registra como “estação_remetente” e identifica o usuário que utilizou sua conta (“remetente”) para autenticar no domínio e enviar a mensagem. O host tem sua identidade registrada no campo “Received-SPF:” quando aponta o resultado do comando HELO.

No próximo post faremos uma análise em um cabeçalho de uma mensagem eletrônica.

Para saber nais sobre campo “Received-SPF:” visite o site do Sender Policy Framework

Apesar de já termos abordado o assunto em um post anterior, gostaria de aprofundar um pouco mais sobre os campos de metadados do sistema de arquivos, os MAC Times. Todo arquivo ou registro digital ao ser modificado, acessado agrega informações de data e hora associados à ação submetida, inerentes ao sistema de arquivos da mídia onde foram modificados ou acessados. Dessa forma todo evento relacionado a um arquivo digital possuirá uma referência que lhe situará em uma linha de tempo (timeline) de um determinado caso e sua localização nesta linha temporal poderá indicar sua relação com um fato analisado. A timeline é uma forma cronológica de apresentar informações relativas a um determinado evento. A análise da linha de tempo pode situar uma prova em um determinado instante associado a um evento ou colocá-la em um contexto não plausível para o caso estudado, inviabilizando-a. Informações mal interpretadas poderão gerar dúvidas quanto à confiabilidade da prova.

MAC Time Stamps

São chamados de MAC times stamps os campos que armazenam os registros relativos à data e hora de modificação/modification (mtime), acesso/access (atime) e mudança/change (ctime) dos arquivos. Em sistemas UNIX o ctime é o momento em que o metadado relativo à permissão ou propriedade de um determinado arquivo é alterado. Nos sistemas Microsoft Windows o ctime armazena o instante em que um arquivo é criado.

O mtime registra apenas o instante em que um arquivo foi modificado, ou seja, quando foi submetido à ação de salvar. Portanto mesmo que não haja alteração do seu conteúdo, apenas o ato de abrir e salvar um arquivo altera o registro do campo mtime.

O atime por sua vez registra o instante do acesso de um arquivo, ou seja, quando o mesmo foi aberto. Caso o arquivo fique aberto por muito tempo o conteúdo deste campo pode não refletir o instante preciso em que seu conteúdo foi lido.

FORMATO DE 32 BITS WINDOWS/DOS

A data e hora é armazenada em uma estrutura de 32 bits ou 4 bytes, onde:

Este formato é utilizado no sistema de arquivos FAT para gravar registros de data e hora como data de criação do arquivo (File Created Date), data de modificação do arquivo (File Modified Date) e data de último acesso (Last Access Date). Este formato é normalmente referido como Formato de Data e Hora MS DOS e gravado conforme o horário local ajustado no computador

FORMATO DE 64 BITS WINDOWS FILETIME

A data e hora é armazenada em um número de 64 bits ou 8 bytes, iniciado em 00:00:00 de 1 de janeiro de 1601 UTC e incrementado em intervalos de 100 nano segundos.

Este formato é utilizado na Master File Table (MTF) do NTFS para gravar registros de data e hora como data de criação do arquivo (File Created Date), data de modificação do arquivo (File Modified Date) e data de último acesso (Last Access Date). O sistema NFTS grava a data e hora no formato UTC.

FORMATO DE 32 BITS C/UNIX

A data e hora é armazenada em um número de 32 bits ou 4 bytes, com valor em segundos, iniciado em 00:00:00 de 1 de janeiro de 1970 UTC.

Este formato é utilizado comumente em sistemas Unix.

FORMATO DE 32 BITS HFS/HFS+

A data e hora é armazenada em um número de 32 bits ou 4 bytes, com valor em segundos, iniciado em 00:00:00 de 1 de janeiro de 1904 UTC.

Este formato é utilizado comumente em sistemas Apple

CUIDADOS COM METADADOS DE DATA E HORA

Primeiramente vimos que todo arquivo tem metadados que registram os momentos de criação, acesso e modificação dos arquivos e eles serão gravados de acordo com a hora do sistema em que foram criados, sendo assim é de fundamental importância verificar os ajustes de data e hora do equipamento que os produziu.

É necessário adotar um horário de referência para alinhá-lo a cada equipamento que tenha produzido evidências digitais em um caso. Assim teremos uma linha de tempo coerente, onde cada evidência estará situada em seu devido lugar.

As câmeras fotográficas digitais, inclusive aquelas presentes nos aparelhos de telefonia móvel, tablets, etc., registram imagens e também associam MAC Time aos arquivos criados, entretanto se os arquivos forem copiados para outras mídias, refletirão os momentos do sistema para onde copiados/movidos. Entretanto estas também criam metadados que são armazenados internamente no arquivo digital, também conhecidos como metadados EXIF (Exchangeable Image File Format) que entre outras coisas armazenam dados acerca da câmera/telefone, ajustes da imagem, data e hora de produção da imagem, geotags, copyright, autoria, etc. Logo se uma imagem tem seus metadados alterados em função de cópia ou de forma intencional, ainda temos a possibilidade de verificar o instante em que foi produzida pelo equipamento através dos metadados EXIF. Aqui vale um cuidado extra. As câmeras podem estar com horário desajustado ou os metadados EXIF podem ter sidos alterados com auxílio de editores EXIF. O conteúdo das imagens podem auxiliar nos mostrando posição de sombras, relógios, fatos conhecidos, etc.

Arquivos como os do Microsoft Office, Adobe Acrobat, Word Perfect, Open Office, Microsoft Works, etc., podem registrar data e hora da produção do conteúdo, autor e outras informações em metadados próprios dos seus arquivos.

Ao analisar um computador com sistema Windows Vista ou 7, lembre-se que por padrão eles não registram o acesso ao arquivo (atime). Isto se deve porque a chave HKEY_LOCAL_MACHINESYSTEMCurrentControlSet ControlFileSystem possui o valor NtfsDisableLastAccessUpdate igual a 1.

Figura 1 – “Valor NtfsDisableLastAccessUpdate=1”

Máquinas com Linux que montam dispositivos de armazenamento com a opção noatime, configurada em /etc/fstab, possuem o mesmo comportamento.

Figura 2 – Arquivo “fstab” com a opção “noatime”

Outro aspecto importante é verificar qual o fuso horário ajustado no equipamento examinado. Esta informação fica armazenada, no registro dos sistemas Microsoft Windows, na chave HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlTimeZoneInformation, no valor ActiveTimeBias, como vemos a seguir:

Figura 3 – O valor ActiveTimeBias contendo o número de minutos para o padrão UTC

Já o Linux guarda estas informações na pasta /usr/share/zoneinfo.

Por fim certifique-se se o arquivo da evidência possui metadados inerentes à aplicação que o criou e caso haja, compare-os aos metadados do sistema de arquivos, assim você terá uma visão mais ampla do que ocorreu com a evidência em questão. 

Saiba mais sobre…