O site do DEFT anunciou há alguns dias o lançamento de uma nova release do seu famoso live CD. A nova release (4.2.1) não traz nenhuma novidade em termos de utilitários nem de ferramentas. Traz o acerto de um bug bastante sério que foi descoberto na versão 4.2
Um dos maiores cuidados ao trabalhar com a imagem forense é manter sua integridade. Essa integridade pode ser verificada por uma função hash aplicada antes e depois de manipulá-la. Se os valores forem iguais, tudo em paz.
Para manter a integridade, as ferramentas forenses precisam ter alguns cuidados. Entre eles, nunca montar os dispositivos e imagens automaticamente. Isso faz com que o investigador tenha o controle exato de como e quando montar a imagem, dessa forma protegendo a integridade através de comandos e parâmetros específicos. Ainda assim, há um certo inimigo da integridade: O journaling.
Essa é uma funcionalidade presente em alguns sistemas de arquivos, incluindo o NTFS e os ext. Sendo bastante simplório, o journaling é como um log de transações. As operações de escrita vão primeiro para o journaling, e depois são efetivadas pelo SO. É possível que um sistema, ao ser desligado de forma abrupta, possua transações ainda não efetivadas no disco. No próximo boot, em algum momento o SO vai detectar isso e promover as operações, de forma que tudo fique como deveria. Esse mecanismo pode se tornar um problema para os peritos se estivermos com uma imagem forense de um sistema de arquivos cujo journaling ainda possui transações pendentes. Se essa imagem for montada sem os devidos cuidados, uma das primeiras coisas que o SO vai fazer é ler o journaling, detectar as transações pendentes e mandar efetuá-las. Ou seja, adeus integridade: a sua imagem forense, mesmo aberta como read-only, vai sofrer alterações.
Para evitar isso, os live CDs normalmente compilam código do kernel do Linux com pequenas alterações. A parte que trataria do journaling, efetuando as transações, é eliminada.
É aqui que mora o perigo.
Em alguns casos, essa alteração do kernel não é tão simples e pode apresentar bugs. Volta e meia uns desses acontecem e causam bastante alarde na comunidade de usuários da ferramenta. Por volta do ano passado, se não me engano, o Helix apresentou um problema desses no HFS+. A bola da vez é o DEFT 4.2, com os sistemas ext3 e ext4.
Conseguiram detectar que o DEFT estava lendo e efetivando transações em journaling pendentes de imagens forenses baseadas nos sistemas ext3 e ext4. Embora isso só aconteça em condições bastante específicas, alguns podem ter sido prejudicados na questão integridade da imagem. Não chega a ser desesperador justamente porque, para o problema acontecer, várias condições precisam estar presentes. O investigador precisa estar trabalhando com uma imagem forense ext3 ou ext4 (pelo menos no Brasil, o mais comum são imagens NTFS) e ter o azar de haver transações incompletas no journaling. Isso aconteceria, por exemplo, em uma dead acquisition, se a máquina foi desligada sem os procedimentos normais, não dando ao SO a oportunidade de aplicar as ultimas transações do journaling. Em uma live acquisition, há ainda mais chances de acontecer, já que várias transações podem estar acontecendo no disco no exato momento em que a parte do journaling no disco está sendo capturada para a imagem.
O que fazer caso o bug tenha afetado uma imagem ? Bem, as boas práticas forenses mandam que nós trabalhemos sempre em uma cópia da imagem forense. Se o hash não bateu, por esse ou outro problema, pegue a imagem original e faça nova cópia, tendo antes o cuidado de entender como a integridade foi quebrada.
Não estavas trabalhando com uma cópia da imagem ??? Vais ter mais trabalho. Terás que fazer a aquisição da imagem novamente, rompendo o lacre da mídia original e efetuando a operação. Documente tudo, pois o acesso à mídia original terá de constar da cadeia de custódia.
Alguém já teve problemas relativos a isso e gostaria de comentar ?
Até o próximo post !
domingo, 1 de novembro de 2009
sexta-feira, 30 de outubro de 2009
Caine 1.0
Ainda está quentinho do forno. Acabou de sair a versão mais nova do mais promissor live cd de Forense Computacional disponível no momento. O Caine 1.0, agora sob liderança de Nanni Bassetti, traz algumas novidades:
- WinTaylor, interface para uso no Windows, com vários utilitários úteis em Resposta a Incidentes
- Página HTML para executar os utilitários do Windows (útil quando por alguma razão o WinTaylor não funcionar)
- Atualização do Ntfs-3g para a versão 2009.1.1
- Nova opção de boot: text mode.
- Atualização dos pacotes do Ubuntu 8.04
- Firefox 3.0.14
- Gtkhash, interface gráfica para cálculo de hash de arquivos
- Novidades nos relatórios: Adicionado campos de nome do investigador e caso
- Relatório traduzido em vários idiomas: italiano, inglês, alemão, francês and português (minha contribuição ao projeto)
- Documentação dos utilitários em formato html, exibida no start do Firefox
- Novas ferramentas
Já estou baixando o arquivo .iso, e tão logo possa, eu postarei aqui uma análise dessa nova versão.
Alguém já está usando-a ?
Até o próximo post !
- WinTaylor, interface para uso no Windows, com vários utilitários úteis em Resposta a Incidentes
- Página HTML para executar os utilitários do Windows (útil quando por alguma razão o WinTaylor não funcionar)
- Atualização do Ntfs-3g para a versão 2009.1.1
- Nova opção de boot: text mode.
- Atualização dos pacotes do Ubuntu 8.04
- Firefox 3.0.14
- Gtkhash, interface gráfica para cálculo de hash de arquivos
- Novidades nos relatórios: Adicionado campos de nome do investigador e caso
- Relatório traduzido em vários idiomas: italiano, inglês, alemão, francês and português (minha contribuição ao projeto)
- Documentação dos utilitários em formato html, exibida no start do Firefox
- Novas ferramentas
Já estou baixando o arquivo .iso, e tão logo possa, eu postarei aqui uma análise dessa nova versão.
Alguém já está usando-a ?
Até o próximo post !
terça-feira, 27 de outubro de 2009
Treinamentos - Novas turmas
CFPF - Novas turmas
Trago boas notícias. O nosso treinamento em Forense Computacional - CFPF - está com novas datas e possibilidades. Além de turmas em horário integral e horário noturno, conseguimos expandir e agora oferecemos o treinamento em várias capitais.
Falando um pouco do treinamento, ele é baseado em software livre, em várias distrôs forenses como Helix, Caine e outros. Ministramos tanto a parte teórica quanto muitas práticas, além de abordar conteúdos de Forense Computacional e Resposta a Incidentes.
Clique no banner ao lado (ainda bem que não tento ganhar a vida como designer, hein ? hehehe) e verifique as datas e opções. Caso você tenha interesse, mas não tenha opções de datas interessantes, entre em contato comigo e podemos ver outras possibilidades, inclusive de treinamento on-site, para equipes inteiras de TI/InfoSec.
Até o próximo post !
Trago boas notícias. O nosso treinamento em Forense Computacional - CFPF - está com novas datas e possibilidades. Além de turmas em horário integral e horário noturno, conseguimos expandir e agora oferecemos o treinamento em várias capitais.
Falando um pouco do treinamento, ele é baseado em software livre, em várias distrôs forenses como Helix, Caine e outros. Ministramos tanto a parte teórica quanto muitas práticas, além de abordar conteúdos de Forense Computacional e Resposta a Incidentes.
Clique no banner ao lado (ainda bem que não tento ganhar a vida como designer, hein ? hehehe) e verifique as datas e opções. Caso você tenha interesse, mas não tenha opções de datas interessantes, entre em contato comigo e podemos ver outras possibilidades, inclusive de treinamento on-site, para equipes inteiras de TI/InfoSec.
Até o próximo post !
segunda-feira, 26 de outubro de 2009
PeriBr
Tive uma grata surpresa ao ler um dos comentários no Forum Perícia Forense sobre o PeriBr, um live cd desenvolvido como trabalho de final de curso na UCB. Segundo Marcel Carvalho, que também é marido da criadora do PeriBr, Jaqueline Carvalho, o novo live CD possui as seguintes características:
* Estão embutidas ferramentas como PyFlag, PTK , Autopsy, Guymager e Dhash;
* O menu está todo categorizado de acordo com as fases de uma perícia;
* Embutido o menu USP (Ubuntu System Panel), traduzido para o pt_BR;
* Foram criados scripts para cada uma das ferramentas que exibe uma ajuda sobre elas;
* Não monta automaticamente dispositivos, e quando o faz por padrão fica com RO (read-only);
A grata surpresa vem pelos comentários, que transcrevo abaixo:
"Cabe aqui uma menção ao trabalho escrito da monografia em questão, que mostra um grupo de distribuições que foram usadas como base para o trabalho, entre elas o FDTK.
Uma diferença básica, e que está descrita como um problema da versão atual do FDTK, é o toolkit PyFlag que existia em versões anteriores e que na atual versão não está funcionando por problemas de incompatibilidade, outra diferença é o toolkit PTK que encontra-se
instalado no PeriBR e não no FDTK, mais algumas ferramentas da distribuição DEFT que foram incluídas no PeriBR e também não existem no FDTK.
Uma inclusão agradável, na minha opinião, foi o menu USP (ubuntu System Panel), que foi a base do MintMenu para quem conhece. Foi feita uma tradução para o pt-BR desta ferramenta, o que não existia ainda, e ela foi incluída no PeriBR. O MintMenu é muita mais agradável de se
operar, porém ele muda muito o Ubuntu, tentando transformá-lo no LinuxMINT ;)
Porém como disse anteriormente e é citado no trabalho escrito, a distribuição FDTK foi usada como base, além do DEFT, Helix, BackTrack, FCCU e o Caine. Também é feita uma referência elogiosa ao blog do Tony Rodrigues e ao seu trabalho em http://www.slideshare.net/tonyrodrigues/computacaoforense0800tony-rodriguesv1 de onde várias idéias foram tiradas.
A idéia de divisão por etapas da perícia foi baseada no trabalho do Aderbal e Neukamp, criadores do FDTK.
O trabalho de pós-graduação realizou a idéia dada por Tony Rodrigues: "Faça o seu". Ou seja, faça a sua distribuição com as ferramentas que te interessam. O objetivo final era criar uma distribuição com as ferramentas que o perito deseja ter. Mostrar que isso não era uma tarefa impossível, e passar um caminho a ser seguido aos que desejam criar seu próprio
conjunto de ferramentas."
Algo que eu disse e digo já faz algum tempo é que esse blog nasceu para ajudar. Ver que isso está de fato acontecendo, ao ponto de ser usado como referência para uma nova distrô forense e um trabalho de monografia, é mais que gratificante. É sentimento de missão cumprida.
O trabalho que foi referenciado pelo Marcel é uma compilação de vários estudos que fiz e coloquei aqui no blog. Ele acabou virando uma palestra, que inicialmente foi criada em inglês para uma conferência marcada para junho de 2009 em Lisboa, mas acabou não acontecendo. Por fim, eu a utilizei no CNASI do Rio de Janeiro, em março de 2009.
Eu aproveitei para enviar ao Marcel algumas sugestões para a versão 1.1:
O projeto está hospedado no SourceForge. Clique aqui para baixar o arquivo .iso.
Em breve vou postar aqui uma análise do mais novo live cd brasileiro.
Comentários ? Algumas idéias a mais para o projeto ?
Até o próximo post !
* Estão embutidas ferramentas como PyFlag, PTK , Autopsy, Guymager e Dhash;
* O menu está todo categorizado de acordo com as fases de uma perícia;
* Embutido o menu USP (Ubuntu System Panel), traduzido para o pt_BR;
* Foram criados scripts para cada uma das ferramentas que exibe uma ajuda sobre elas;
* Não monta automaticamente dispositivos, e quando o faz por padrão fica com RO (read-only);
A grata surpresa vem pelos comentários, que transcrevo abaixo:
"Cabe aqui uma menção ao trabalho escrito da monografia em questão, que mostra um grupo de distribuições que foram usadas como base para o trabalho, entre elas o FDTK.
Uma diferença básica, e que está descrita como um problema da versão atual do FDTK, é o toolkit PyFlag que existia em versões anteriores e que na atual versão não está funcionando por problemas de incompatibilidade, outra diferença é o toolkit PTK que encontra-se
instalado no PeriBR e não no FDTK, mais algumas ferramentas da distribuição DEFT que foram incluídas no PeriBR e também não existem no FDTK.
Uma inclusão agradável, na minha opinião, foi o menu USP (ubuntu System Panel), que foi a base do MintMenu para quem conhece. Foi feita uma tradução para o pt-BR desta ferramenta, o que não existia ainda, e ela foi incluída no PeriBR. O MintMenu é muita mais agradável de se
operar, porém ele muda muito o Ubuntu, tentando transformá-lo no LinuxMINT ;)
Porém como disse anteriormente e é citado no trabalho escrito, a distribuição FDTK foi usada como base, além do DEFT, Helix, BackTrack, FCCU e o Caine. Também é feita uma referência elogiosa ao blog do Tony Rodrigues e ao seu trabalho em http://www.slideshare.net/
A idéia de divisão por etapas da perícia foi baseada no trabalho do Aderbal e Neukamp, criadores do FDTK.
O trabalho de pós-graduação realizou a idéia dada por Tony Rodrigues: "Faça o seu". Ou seja, faça a sua distribuição com as ferramentas que te interessam. O objetivo final era criar uma distribuição com as ferramentas que o perito deseja ter. Mostrar que isso não era uma tarefa impossível, e passar um caminho a ser seguido aos que desejam criar seu próprio
conjunto de ferramentas."
Algo que eu disse e digo já faz algum tempo é que esse blog nasceu para ajudar. Ver que isso está de fato acontecendo, ao ponto de ser usado como referência para uma nova distrô forense e um trabalho de monografia, é mais que gratificante. É sentimento de missão cumprida.
O trabalho que foi referenciado pelo Marcel é uma compilação de vários estudos que fiz e coloquei aqui no blog. Ele acabou virando uma palestra, que inicialmente foi criada em inglês para uma conferência marcada para junho de 2009 em Lisboa, mas acabou não acontecendo. Por fim, eu a utilizei no CNASI do Rio de Janeiro, em março de 2009.
Eu aproveitei para enviar ao Marcel algumas sugestões para a versão 1.1:
1) Coloque o Wine e, a partir disso, vários utilitários Windows interessantes (nem todos funcionam; eu estou com uma idéia de um projeto para isso, seria bastante útil)
- Já falei aqui em um artigo recente de como o Wine pode ser usado com sucesso para permitir o uso de ferramentas Windows em ambientes Linux e, com isso, podermos unificar o conjunto de ferramentas de análise.
- Já falei aqui em um artigo recente de como o Wine pode ser usado com sucesso para permitir o uso de ferramentas Windows em ambientes Linux e, com isso, podermos unificar o conjunto de ferramentas de análise.
2) Compilar o SleuthKit com vários tipos de imagem (formatos) e sistemas de arquivos. O HFS está crescendo em uso e nem todas as ferramentas o compilaram
- A versão mais nova do Helix deu uma melhorada nisso, mas até bem pouco tempo, só se conseguia analisar imagens no formato AFF e Expert Witness no Caine.
- A versão mais nova do Helix deu uma melhorada nisso, mas até bem pouco tempo, só se conseguia analisar imagens no formato AFF e Expert Witness no Caine.
3) Voltar com o SAMBA para o pacote. A maioria dos novos Live CDs o retirou.
- É muito útil nas trocas de arquivo via rede. Não é indispensável, mas sem ele ficamos sem uma opção interessante de captura de imagem para locais remotos.
- É muito útil nas trocas de arquivo via rede. Não é indispensável, mas sem ele ficamos sem uma opção interessante de captura de imagem para locais remotos.
4) Drivers de wireless. Isso vem sendo um problema para notebooks, já que na maioria das vezes nos conectamos via Wi-fi.
- É um grande problema. A maioria não carrega rede wireless.
- É um grande problema. A maioria não carrega rede wireless.
5) Perl e Python + RegRipper e Volatility com plugins atualizados
- Nesses tempos modernos, Forense de Registry e de Memória são bastante úteis para um investigador.
Vou incluir mais uma que não coloquei no email: Suporte a teclado ABNT2. Quem comprou laptop no Brasil tem sempre um problema para ajustar o teclado ...- Nesses tempos modernos, Forense de Registry e de Memória são bastante úteis para um investigador.
O projeto está hospedado no SourceForge. Clique aqui para baixar o arquivo .iso.
Em breve vou postar aqui uma análise do mais novo live cd brasileiro.
Comentários ? Algumas idéias a mais para o projeto ?
Até o próximo post !
quinta-feira, 15 de outubro de 2009
Anti-Anti-Forense
Esse é o tema sobre o qual estarei falando na 6a edição do mais importante evento Hacker do Brasil - o H2HC - Hacker-2-Hacker Conference. O evento será no final de semana de 28 e 29 de novembro, em São Paulo.
Já faz algum tempo que venho olhando esse assunto com atenção. A primeira vez que li sobre esse termo foi em uma palestra feita pela turma do projeto Metasploit. A palestra procurava expor fraquezas em algumas técnicas ou ferramentas usadas em Computação Forense.
Depois dessa palestra, anti-forense entrou para o abstrato. Tudo seria resolvido por anti-forense, e os peritos estavam com os dias contados. Não levaria muito tempo e todos aplicariam os conceitos que, por hora, apenas alguns Hackers Jedi conheciam. Com o passar do tempo, chegamos ao ponto de perceber uma certa disputa, quase um clima de guerra. Hackers que escrevem sobre o assunto desdenham dos investigadores e colocam as técnicas como imbatíveis. Os peritos, por outro lado, usam de grande ironia e expõem a questão como se fosse brincadeira de criança resolver qualquer coisa relacionada a isso. Vi muitos desses textos enquanto pesquisava alguns detalhes para a palestra.
Nem "rocket science" nem algo trivial. Anti-Forense deve ser visto como crítica construtiva e pode ajudar (e muito !) no combate aos crimes, uma vez que tira o perito de sua posição de conforto e o faz repensar nas suas técnicas e ferramentas. É com esse intuito que venho pesquisando algumas técnicas, principalmente como poderiam ser detectadas ou revertidas. O ponto comum nas técnicas de "contra-ataque" é que, em algum momento, algo aparece. Harlan Carvey costuma usar uma analogia com técnicas militares, onde mesmo o melhor e mais prudente snipper precisa fazer alguns movimentos, comer, dormir ... É nessa hora que ele pode se expor, e de forma análoga, quando o malware, o atacante ou o utilitário são usados, marcas e vestígios importantes aparecem. É só estar bastante atento a elas.
Espero vê-los por lá. Será uma boa oportunidade para conhecer a turma que acompanha o blog.
Até o próximo post !
Já faz algum tempo que venho olhando esse assunto com atenção. A primeira vez que li sobre esse termo foi em uma palestra feita pela turma do projeto Metasploit. A palestra procurava expor fraquezas em algumas técnicas ou ferramentas usadas em Computação Forense.
Depois dessa palestra, anti-forense entrou para o abstrato. Tudo seria resolvido por anti-forense, e os peritos estavam com os dias contados. Não levaria muito tempo e todos aplicariam os conceitos que, por hora, apenas alguns Hackers Jedi conheciam. Com o passar do tempo, chegamos ao ponto de perceber uma certa disputa, quase um clima de guerra. Hackers que escrevem sobre o assunto desdenham dos investigadores e colocam as técnicas como imbatíveis. Os peritos, por outro lado, usam de grande ironia e expõem a questão como se fosse brincadeira de criança resolver qualquer coisa relacionada a isso. Vi muitos desses textos enquanto pesquisava alguns detalhes para a palestra.
Nem "rocket science" nem algo trivial. Anti-Forense deve ser visto como crítica construtiva e pode ajudar (e muito !) no combate aos crimes, uma vez que tira o perito de sua posição de conforto e o faz repensar nas suas técnicas e ferramentas. É com esse intuito que venho pesquisando algumas técnicas, principalmente como poderiam ser detectadas ou revertidas. O ponto comum nas técnicas de "contra-ataque" é que, em algum momento, algo aparece. Harlan Carvey costuma usar uma analogia com técnicas militares, onde mesmo o melhor e mais prudente snipper precisa fazer alguns movimentos, comer, dormir ... É nessa hora que ele pode se expor, e de forma análoga, quando o malware, o atacante ou o utilitário são usados, marcas e vestígios importantes aparecem. É só estar bastante atento a elas.
Espero vê-los por lá. Será uma boa oportunidade para conhecer a turma que acompanha o blog.
Até o próximo post !
sexta-feira, 9 de outubro de 2009
Tempos modernos
Esse post é quase off-topic. É um grande elogio e agradecimento à proximidade que a Internet nos trouxe.
Estava escrevendo um material para apresentar no H2HC quando tive uma dúvida. Postei a pergunta em dois fóruns internacionais que faço parte; Em um deles, fui atendido por um dos pesquisadores do NIST, Doug White, que entre outras coisas é responsável pela NSRL. A minha pergunta era exatamente sobre a NSRL oferecer ou não uma base de hashs fuzzy, já que eu tenho a base corrente, e só tem MD5 e SHA1 nela. Ele me informou que eles já tem os valores calculados, mas o hashset não está publicado por pouca demanda. Nós "conversamos" sobre isso e acho que vamos ter a base publicada. Comentei com ele sobre alguns detalhes da minha palestra e ele entendeu a importância e a relevância que a base terá. É só aguardar ...
Na outra lista, nova resposta ilustre. Quem me escreveu foi nada mais nada menos que Jesse Kornblum, o próprio criador do ssdeep e dos outros inúmeros "deeps" que temos. Além desse trabalho, Jesse também é o autor da Primeira Lei da Forense Computacional, que já tratamos aqui no blog.
Tanto um quanto o outro foram extremamente gentis e dispostos a ajudar. Não faz muito tempo, eu também estava trocando emails com Matthieu Suiche, autor de inúmeros utilitários de Forense de Memória, tais como o Sandman e o win32dd. Emails com o Harlan Carvey (o papa do Windows Registry) já se tornaram comuns e já escrevi aqui sobre ter consultado diretamente o pesquisador que quebrou o MD5 em um certificado digital.
Isso não é sensacional ? Ter ao alcance do teclado a opinião de verdadeiros gênios da nossa ciência ? A Internet faz mesmo o mundo ficar menor ...
Comentários ?
Até o próximo post !
Estava escrevendo um material para apresentar no H2HC quando tive uma dúvida. Postei a pergunta em dois fóruns internacionais que faço parte; Em um deles, fui atendido por um dos pesquisadores do NIST, Doug White, que entre outras coisas é responsável pela NSRL. A minha pergunta era exatamente sobre a NSRL oferecer ou não uma base de hashs fuzzy, já que eu tenho a base corrente, e só tem MD5 e SHA1 nela. Ele me informou que eles já tem os valores calculados, mas o hashset não está publicado por pouca demanda. Nós "conversamos" sobre isso e acho que vamos ter a base publicada. Comentei com ele sobre alguns detalhes da minha palestra e ele entendeu a importância e a relevância que a base terá. É só aguardar ...
Na outra lista, nova resposta ilustre. Quem me escreveu foi nada mais nada menos que Jesse Kornblum, o próprio criador do ssdeep e dos outros inúmeros "deeps" que temos. Além desse trabalho, Jesse também é o autor da Primeira Lei da Forense Computacional, que já tratamos aqui no blog.
Tanto um quanto o outro foram extremamente gentis e dispostos a ajudar. Não faz muito tempo, eu também estava trocando emails com Matthieu Suiche, autor de inúmeros utilitários de Forense de Memória, tais como o Sandman e o win32dd. Emails com o Harlan Carvey (o papa do Windows Registry) já se tornaram comuns e já escrevi aqui sobre ter consultado diretamente o pesquisador que quebrou o MD5 em um certificado digital.
Isso não é sensacional ? Ter ao alcance do teclado a opinião de verdadeiros gênios da nossa ciência ? A Internet faz mesmo o mundo ficar menor ...
Comentários ?
Até o próximo post !
segunda-feira, 5 de outubro de 2009
Bad Sectors
Li uma matéria bastante interessante na revista Digital Investigation. A matéria nem é tão nova assim (é de 2007) mas o assunto vale um reforço.
O sonho de todo Perito é chegar, depois de longas horas fazendo uma imagem forense, a uma tela informando que tudo terminou bem. Topar com bad sectors e/ou bad clusters pode ser uma grande dor de cabeça. O hash do dispositivo não vai bater com a cópia e ainda tem a possibilidade da operação parar e nos obrigar a fazer tudo de novo.
O artigo trata exatamente de um estudo a respeito do comportamento de algumas ferramentas de captura de imagem forense quando encontram bad sectors. O estudo foi feito por dois pesquisadores do NIST e usaram os seguintes critérios nos testes de ferramentas:
1) A ferramenta deve capturar todos os setores que não estejam ruins;
2) Ela deve identificar os setores que estão ruins na imagem;
3) Ela deve preencher com dados documentados os setores da imagem que são relativos aos setores ruins do dispositivo. Por exemplo, se um HD estiver com os setores 10,11 e 12 ruins (bad sectors), então esses mesmos setores da imagem deverão ser preenchidos com padrões reconhecidos e bem documentados.
Com esses critérios, a pesquisa realizou uma série de aquisições de imagens usando HDs com bad sectors devidamente mapeados. Vários utilitários foram usados nessas aquisições, e a forma de conectar o HD à estação forense também foi documentada (por firewire ou diretamente). O resultado não foi muito animador ...
Apesar de terem testado poucas ferramentas, fica nítido a falta de capacidade do dd e seus genéricos atenderem ao que foi especificado. Os que melhor saíram no teste foram o IXimager, do iLook e o dd do BSD. Os outros todos deixaram de ler setores bons que estavam nas proximidades dos setores ruins. Além disso, os setores da imagem relativos aos setores ruins do HD foram preenchidos com lixo pelo dd do FreeBSD (os utilitários dd baseados no Linux preenchem com zeros, corretamente).
A questão de não ler setores bons nas proximidades de setores ruins tem relação com tamanho do bloco de leitura. Imagine que o dd foi configurado para ler blocos de 4k e o HD sendo capturado possui um setor danificado de 512 bytes. Em determinado momento, a requisição de leitura irá falhar porque dentro do bloco de 4k lido estará o setor defeituoso de 512b. No fim das contas, todo o bloco de 4k na imagem receberá zeros, e não apenas os 512b realmente defeituosos. Dos oito setores dentro de um bloco, apenas um estava defeituoso mas todos os outros sete ficaram desperdiçados. Nesses sete blocos desperdiçados podemos ter dados importantíssimos para o caso, definindo-o.
O estudo não contemplou outras ferramentas, mas gostaria de citar que há um conjunto especialmente desenvolvido para tratar erros de leitura em bad sectors:
- RDD
- DD_Rescue
- ddrescue
Além de realizarem as operações normais de captura (dd), essas ferramentas podem trabalhar com tamanhos de blocos de leitura que podem variar, se encontrarem um bad sector. Dessa forma, no exemplo anterior, a ferramenta tentaria ler o bloco de 4k e ao receber o erro de leitura, ela tentaria novamente, agora com um bloco da metade do tamanho (2k). Se conseguir, ela avança com o processo; se não, continua a dividir o tamanho do bloco até que tenha sucesso na leitura ou chegue no tamanho mínimo de 512b. Pela lógica, a ferramenta não lerá apenas os setores que realmente estiverem danificados.
Além disso, as ferramentas podem ser configuradas para iniciarem a operação em sentido inverso, dos últimos setores para o primeiro. Em alguns casos, mesmo alguns setores ruins conseguem ser lidos dessa forma.
Comentários ? Alguém quer compartilhar suas experiências com essas ferramentas ou com bad sectors ? Participe !
Até o próximo post !
Assinar:
Postagens (Atom)
