sexta-feira, 29 de fevereiro de 2008

FDTK 1.0

Esse é o nome do mais novo LiveCD para Forense Computacional disponível na área. Fruto de um trabalho de TCC de dois alunos da UNISINOS, o FDTK tem interface em português, é baseado no Ubuntu 7.04 e conta com um interessante grupo de ferramentas.

Pretendo lançar uma avaliação em breve desse liveCD aqui no Blog. Por hora, tome cuidado se for usá-lo em uma aquisição forense. Reparei que ele está montando todos os discos que detecta, o que vai contra as melhores práticas e abre a possibilidade de alteração indevida em uma mídia, criando problemas de integridade. Tenho certeza de que os autores vão corrigir isso na versão 1.01.

Há um ponto que não pode passar despercebido aqui. Esse LiveCD é um marco para a Forense Computacional no Brasil. Espero que seja a primeira de muitas versões e que os autores possam trabalhar nesse projeto com seriedade e compromisso. Será de grande benefício para toda a nossa comunidade.

Até o próximo post !

sábado, 23 de fevereiro de 2008

Imagens Forenses VI

A Promessa do PyFlag

Em um dos artigos sobre imagens forenses, eu comentei sobre como poderíamos montar imagens raw (.dd) divididas em pedaços menores. Por exemplo, você pode manter 5 arquivos de 2Gb (imagem.dd1, imagem.dd2 e por aí vai) ao invés de um único arquivo de 10Gb (imagem.dd). Isso facilita nos backups para DVDs (imagens costumam ser muito grandes) e é fundamental quando estamos lidando com o sistema de arquivos FAT, que não suporta arquivos com mais de 2Gb.

O método mais conhecido é remontar as partes antes do uso. O comando cat pode fazê-lo:
# cat imagem.dd* > imgcompleta.dd

O problema é que esse comando demora para finalizar e requer no mínimo o mesmo tamanho do arquivo inteiro como espaço livre no HD.

Quem deu alguma esperança nesse assunto foi a turma que desenvolveu o pyFLAG. Esse pacote, desenvolvido inicialmente pela Polícia Australiana, internamente aceita imagens de vários formatos, incluindo imagens split raw e imagens no formato Expert Witness (.E01).

Nas suas versões mais novas, o pyFLAG passou a disponibilizar utilitários que conseguem montar as imagens e deixá-las acessíveis. Dessa forma, tendo o pyFLAG instalado, aumentamos as nossas possilibidades, já que podemos montar vários tipos através desses utilitários. De acordo com a documentação, fazemos:

# pyflag_launch /utilities/fuse_loopback_subsystem.py /mounting/point -i -filename

Para montar uma imagem ewf de nome imagem.E01 no mounting point /mnt:

# pyflag_launch /pyflaginst/utilities/ fuse_loopback_subsystem.py /mnt -i ewf -filename imagem.E01

Para montar a primeira partição de uma imagem raw física que está particionada em vários arquivos (imagem.dd1, imagem.dd2, imagem.dd3, ...). Supondo que a imagem começa no setor 63, o comando fica:

# pyflag_launch /pyflaginst/utilities/ fuse_loopback_subsystem.py /mnt -i advanced -filename imagem.dd* -offset 63s

Em todos os casos, logo após comando acima, você achará um arquivo chamado mountme em /mnt. Esse arquivo poderá ser montado normalmente como uma imagem raw, via loopback:

# mount -o ro,loop mountme /outro/mounting/point

A má notícia ...

Nem tudo são flores, não é mesmo ? A má notícia dessa técnica é que a versão do pyFlag instalada no Helix 1.9a é a 0.80, bastante antiga e não tem as funcionalidades comentadas acima. A versão atual do pyFLAG é a 0.86RC1, lançada em 31 de janeiro de 2008.

O FCCU 12 infelizmente não veio com o pyFLAG.

O FDTK, um live CD Forense lançado recentemente como trabalho de fim de curso por dois estudantes brasileiros, vem com a versão 0.84 do pyFLAG; eu fiz os testes desse utilitário lá e ele não rodou como esperado.

A esperança é que conversei no Forum do Helix com o Drew Farrey, o responsável pela compilação do Helix, e ele me garantiu que o Helix 2.0 está no forno e vai vir arrebentando com tudo, inclusive com a versão mais nova do pyFlag. Também pretendo conversar com os criadores do FDTK para ver o que está dando errado com o pyFlag.

Enquanto isso, nada de imagens raw splitted ou montagem do ewf ... Ou alguém tem a solução para esses problemas ? Compartilhe conosco nos comentários !

Até o próximo post !

terça-feira, 12 de fevereiro de 2008

Carving

Carving é o nome de um procedimento/técnica muito importante para a Forense Computacional. Através do carving, podemos conseguir acessar um arquivo de forma independente da sua tabela de alocação, ou endereçamento; O carving age de forma independente do sistema de arquivos.

Vamos a um exemplo prático:

Uma feira de negócios é montada em um grande pavilhão. Para demarcar o local destinado ao estande de cada empresa, os organizadores dividem o espaço útil (as vias e corredores não contam) pelo tamanho mínimo de um estande, e com isso determinam que quantos estandes terá a feira. O espaço útil é então separado e dividido nos blocos de estandes.

Para facilitar a localização de cada estande, a organização associa letras aos corredores, e um número crescente a cada estande. Assim, o quarto estande do terceiro corredor seria o estande C4, e foi comprado pela empresa XXX. Na porta do pavilhão há uma lista com o nome de cada empresa em ordem alfabética e sua respectiva localização. Observamos, inclusive, que há empresas que compraram 3 estandes, para poder exibir seu material com mais liberdade.

Nessa pequena analogia, temos o seguinte:

- O pavilhão é a mídia, o HD.
- Os organizadores fazem o papel do sistema operacional.
- A divisão do pavilhão em corredores e unidades de locação (os estandes) é a formatação do disco.
- Uma empresa expositora seria um arquivo.
- A associação das letras e números seriam um endereço alocável.
- Uma empresa comprando um estande seria um arquivo alocado.
- A lista colocada na porta do pavilhão é a tabela de alocação do sistema de arquivos.
- Um estande não alugado é um setor livre para ser alocado.
- Uma empresa que aluga 3 estandes é um arquivo que ocupa 3 setores.

Pois bem, se você chega ao portão do pavilhão a procura da empresa XXX, você a procura na lista, verifica o endereço dela (C4) e se dirige até o local. Esse é o mesmo processo, de maneira resumida, é o que acontece quando se quer acessar determinado arquivo.

Agora, imagine o que aconteceria se a tal lista da entrada se perdesse ? O processo normal de busca da empresa não funcionaria mais, já que a lista sumiu.

Em termos de sistema de arquivos, é possível que a tabela seja corrompida, ou ainda que apenas uma parte do HD seja recuperada, e essa parte não tem a tabela de alocação. Nesses casos, entra em ação a técnica de carving, para achar arquivos no que parece um monte de bytes.

Como isso é feito ?

A técnica mais usada é baseada nos chamados magic numbers, são sequências de bytes que estão sempre presentes no arquivo, em geral no seu cabeçalho. Esses bytes funcionam como uma assinatura: Se forem achados, alguns itens são verificados e a estrutura é confirmada. Em geral, os programas de carving extraem os arquivos identificados das imagens para um diretório, disponibilizando-os para uso. Os arquivos JPEG sempre começam com ffd8 ffe0, por exemplo. Uma vez identificado que é o início de um JPEG, o cabeçalho é dissecado e o fim do arquivo determinado.

O grande problema é que em um sistema de arquivos nem sempre um arquivo ocupa setores contíguos. Conhecido como fragmentação de arquivos, isso acontece, por exemplo, quando um arquivo cujo tamanho ocupa 5 setores está para ser escrito no disco e encontra 3 setores contíguos livres, um setor já ocupado por um outro arquivo, e em seguida mais dois setores livres. O sistema operacional vai alocar o arquivo nesses 5 setores, marcando na tabela que esse arquivo ficou fragmentado. Tal situação ficaria mais ou menos assim:
Arquivo 1: AAAAA
Arquivo 2: B
No disco: AAABAA
Seguindo a técnica, os bytes do arquivo 2 vão parar no meio do arquivo 1 recuperado, estragando tudo !

Várias técnicas vem sendo pesquisadas para reduzir ou eliminar esse problema, e inclusive há um concurso anual de algoritmos e desafios envolvendo carving.

Algo que com certeza vai ajudar bastante é a técnica de montar hashsets dos arquivos conhecidos por setor. Essa técnica é baseada na filtragem de arquivos conhecidos por reconhecimento de seus hashes, como a biblioteca NSRL, só que, nesse caso, cada arquivo conhecido teria associado a ele o hashset de cada setor que esse arquivo ocupa em um disco. Durante uma operação de carving baseada nessa técnica, os setores seriam separados e reconhecidos contra a base de hashsets pelos seus hashes. No exemplo acima, calcularíamos o hash de cada um dos 6 setores, e depois o algoritmo verificaria o seguinte:

- O setor 1 é o primeiro setor do arquivo conhecido A
- O setor 2 é o segundo setor do arquivo conhecido A
- O setor 3 é o terceiro setor do arquivo conhecido A
- O setor 4 é o primeiro setor (ou único, no caso) do arquivo conhecido B
- O setor 5 é o quarto setor do arquivo conhecido A
- O setor 6 é o quinto setor do arquivo conhecido A

Facilita bastante. Logicamente, essa técnica tem alguns problemas; Os arquivos que não ocuparem um setor inteiro, bem como o último setor de um arquivo, não terão como serem reconhecidos, pois o calculo do hash seria influenciado pelo slack space (aquele espaço do setor que o arquivo não ocupou). Outro problema é que os hashsets serão criados para arquivos de programas, e não teremos obviamente hashsets para arquivos de fotos do usuário do HD, ou os seus documentos criados no editor de textos, por exemplo. Isso ajudará a eliminar setores, mas ainda pode não ser uma técnica definitiva.

Alguém tem alguma novidade com relação a essa técnica, ou conhece alguma iniciativa de montar hashsets para isso ? Por favor, compartilhe conosco nos comentários.

Até o próximo post !

segunda-feira, 11 de fevereiro de 2008

Imagens Forenses V

Montando imagens no formato Advanced Forensic Format (aff)

O formato aff é disponibilizado pela Afflib. Essa lib instala vários utilitários, inclusive já comentamos sobre alguns nesse grupo de artigos sobre imagens forenses.

Para montar uma imagem .aff, usamos o utilitário affuse:
# affuse imagem.aff /mounting/point
onde:
imagem.aff é a imagem no formato AFF
/mounting/point é o mounting point, que já deverá estar criado.

Esse comando cria um no diretório /mounting/point um arquivo no formato raw chamado imagem.aff.raw, e a partir daí, é só montar usando o comando mount, como indicamos nos artigos anteriores.

O bacana dessa solução é que esse arquivo raw criado não ocupa espaço. Na verdade, isso é uma visualização provida pelo utilitário e pelo FUSE. Note bem, isso não é a mesma coisa que converter o arquivo .aff para um .raw. Verifique por si mesmo !

Para não dizer que tudo são flores, o affuse do Helix não funciona. Isso vale para as versões 1.9 e 1.9a do Helix. Isso acontece porque uma das dependências da afflib não estava instalada no Helix no momento de sua compilação, o que faz com que o affuse não funcione.

Como ele funciona muito bem no FCCU, uma das possibilidades é copiar o affuse do disco do FCCU para um pendrive ou HD externo formatado com ext2 ou ext3. Daí, quando estiver usando o Helix, você poderá chamar o affuse desse dispositivo que tudo funcionará normalmente.

Isso deve servir como solução de contorno até que o problema seja corrigido na próxima versão do Helix.

Até o próximo post !

sábado, 9 de fevereiro de 2008

Imagens Forenses IV

Montando imagens no formato Expert Witness EWF (E01)

Como você já pode acompanhar nos artigos anteriores, o formato EWF pode ser capturado através do ewfacquire ou da ferramenta Linen.

De acordo com o manual, um script Python chamado mount_ewf foi disponibilizado para poder montar a imagem no FUSE. Entretanto, esse utilitário não funcionou em nenhum dos testes que eu fiz.

Estar capacitado a montar imagens no formato ewf é interessante, pois você pode ser convidado a continuar uma investigação iniciada por uma equipe que trabalhava com o EnCase, e daí o único formato disponível pode ser o .E01.

Sem essa ferramenta estar funcionando, somente nos resta converter a imagem do formato E01 para o formato raw.

Eu fiz testes dessa ferramenta no Helix e no FCCU, ambos nas versões mais recentes. Postei esses resultados no forum do Helix e em algumas listas internacionais, mas até agora não recebi nenhuma resposta. A título de reforço, as imagens usadas foram conferidas e estão íntegras.

Você tem alguma experiência positiva nesse utilitário e poderia compartilhar nos comentários ?

Até o próximo post !

sexta-feira, 8 de fevereiro de 2008

Imagens Forenses III

Montando a Imagem para Análise


RAW


A imagem raw é aquela que é a cópia bit a bit do disco, e não possui qualquer compactação ou metadados. Para montá-la, usamos o loopback do linux. Entretanto, não temos como montar uma imagem raw física, pois o loopback só monta uma partição, e não consegue entender a tabela de partições que está logo nos setores iniciais de uma imagem raw.


Montando uma imagem raw lógica


Uma imagem raw lógica é aquela onde foi especificado uma partição específica no momento da aquisição. Vamos supor que um HD listado como /dev/hda possua 3 partições, e que na aquisição você tenha indicado como origem o /dev/hda2. O resultado disso é uma imagem raw da segunda partição desse HD. Veja:

# file imagem.dd

imagem.dd: x86 boot sector, code offset 0x78, OEM-ID "MSDOS5.0", sectors/cluster 32, root entries 512, Media Descriptor 0xf8, (... continua ...), unlabeled, FAT (16 bit)


A tentativa de ver a geometria do dispositivo através do comando sfdisk não gera resultados (os valores são todos confusos).


Para montar uma imagem raw lógica, use o comando mount. A partir do mesmo diretório onde está a imagem, execute:


# mount -o ro,loop,noexec imagem.dd /media/img

onde:

-o ro -> Monta a imagem read-only
loop -> usa o loopback - mecanismo que torna possível montar um arquivo como um dispositivo
noexec -> nenhum código executável contido na imagem pode ser acionado/executado.
imagem.dd -> é a imagem raw de uma partição.
/media/img -> é um diretório existente que serve de mounting point. Isso significa que a raiz da partição que a imagem contém vai aparecer em /media/img.


Montando uma imagem física


Uma imagem física não é montada pelo loopback. O que é feito, na verdade, é montar partições que estão em uma imagem física.
A primeira coisa a ser feita é conhecer a geometria do dispositivo (imagem). Faça isso com o comando sfdisk:


# sfdisk -luS imagem.dd


Esse comando vai informar a estrutura do dispositivo/imagem. Usando a imagem do meu pendrive como exemplo, obtemos:

bla bla bla ...
Units = sectors of 512 bytes, counting from 0


Device boot Start End #sectors Id System
imagem.dd1 * 32 1712127 1712096 6 FAT16
imagem.dd2 0 --- 0 0 Empty
imagem.dd3 0 --- 0 0 Empty
imagem.dd4 0 --- 0 0 Empty



Essa resposta nos mostra que essa imagem é uma imagem raw física de um dispositivo que tem apenas uma partição iniciando no setor 32, e que é uma partição FAT16. Repare que, se a partição inicia no setor 32, então os primeiros 32 setores (de 0 a 31) não fazem parte dessa partição (é onde a tabela de partições fica, nesse caso aqui) e ela não pode ser montada com o loopback. Isso significa 32*512 = 16384 bytes que devem ser "descartados" ou pulados para que consigamos montar a partição.


Método 1:


# dd if=imagem.dd of=imagem.part1.dd bs=512 skip=32


O comando acima pega a imagem física e copia ela para o arquivo imagem.part1.dd, indicando que o bloco tem 512 bytes e que a cópia deve pular os primeiros 32 blocos. Ou seja, o arquivo imagem.part1.dd é uma imagem raw que só tem a partição 1. Para montá-la, basta seguir o método indicado mais acima.

Esse método é fácil, mas não é prático, na medida em que exige espaço extra para ter uma partição inteira sendo disponibilizada (e duplicada, de certa forma).

Método 2



# mount -o ro,loop,noexec,offset=16384 imagem.dd /media/img


Repare que o comando é quase o mesmo. A diferença é que agora especificamos a quantidade de bytes que precisam ser desconsiderados para que a imagem possa ser montada corretamente.


Lembrete importante: O offset indicado é em BYTES. Sempre verifique a saída do comando sfdisk -luS, para saber qual o tamanho em bytes de cada setor e quantos setores tem que ser pulados.


O que fazer se nossa imagem física tem 3 partições e, digamos, queremos montar a partição 2 ???


Muito simples: Ache, através do comando sfdisk -luS qual o setor de início da partição que se deseja montar, e a quantidade de bytes em um setor. Para montar, execute o comando acima, especificando no offset o valor em bytes a ser "pulado".


Offset em bytes = (Setor onde a partição inicia - start) * (tamanho em bytes de cada setor)

Imagens divididas (split)

Por enquanto, não vou comentar sobre como montar imagens divididas (split). Conheço dois métodos de fazê-lo; um deles funciona, mas é ineficiente. O outro tem um pré-requisito do qual ainda não falei. Vamos discutir ambos em breve.

No próximo artigo, veremos como montar imagens no formato Expert Witness (ewf ou E01).

Até o próximo post !

terça-feira, 5 de fevereiro de 2008

Processo Litúrgico - Preservação de evidências, Ata Notarial e a Cadeia de Custódia

Imagine uma situação nada incomum: Você foi chamado para investigar um caso em uma empresa. Após as averiguações iniciais, você percebe que é importante realizar um processo litúrgico, pois tudo indica que haverá ações na justiça relativas ao caso.

Com isso em mente, você realiza a aquisição da imagem forense. Está sendo acompanhado por um ou dois membros da empresa, normalmente um executivo e um técnico, prestando as informações que você precisa.

Fim do processo de aquisição. Você, como bom investigador que é, e sabe da importância de se manter a integridade das mídias, requer que os HDs que foram capturados sejam lacrados, e que a cadeia de custódia seja mantida fielmente. Explica, então, para os dois membros que o acompanham, a importância desse procedimento, e que certamente a primeira coisa que a outra parte faria em um processo judicial seria tentar desacreditar as evidências. Ao lacrar os HDs, você consegue comparar futuramente os hashes da imagem com o HD respectivo e comprovar a integridade.

Sua indicação do lacre é aceita, você prepara o material, assina o lacre em conjunto com as testemunhas e deixa-o lá com a indicação de que ninguém rompa o lacre até que seja enviado um Perito pelo Juiz. Em seguida, você vai para casa satisfeito com a sensação de trabalho bem cumprido. Infelizmente, essa sensação só vai durar até a primeira audiência. Faltou alguém nessa estória ...

Liturgia

O procedimento litúrgico é, na verdade, um procedimento formal.

Digamos que você seja contratado por uma empresa para investigar se um de seus colaboradores está gastando seu tempo no computador corporativo com sites pornográficos. A empresa tem uma leve suspeita, mas não quer ser injusta. Porém, ela deixa claro que, se for comprovada a suspeita, demitirá o funcionário, sem justa causa. Para casos como esse, você pode realizar investigações diversas e mandar seu relatório para a empresa. Ela vai acatar o que você relatar. Entretanto, a situação muda completamente se o caso for parar na justiça. As evidências precisarão estar preservadas para que todos os seus procedimentos investigativos possam ser reproduzidos e suas conclusões verificadas por quem quer que seja.

É isso que faz o processo ser litúrgico. À sua investigação ficam agregados inúmeros processos formais com objetivo de garantir as evidências, e com isso, as conclusões.

Ata Notarial

A Ata Notarial é um instrumento realizado pelo tabelião (ou seus indicados) de cartórios de notas. Em resumo, é uma narração do que o tabelião vê, percebe, ou ouve, e materializa no documento. Como o tabelião tem fé pública, esse documento é amplamente aceito no judiciário. Uma pessoa pode, por exemplo, chamar um tabelião para realizar a Ata Notarial do conteúdo de um cofre. Antes do mesmo ser aberto, o tabelião estará a postos e vai registrar na Ata tudo que viu .

No caso de investigações computacionais, há um certo receio; alguns cartórios não se sentem à vontade nesse procedimento. Muitos sabem que e-mails podem ser forjados, páginas falsas podem ser exibidas, e o tabelião não quer afirmar algo que não tem certeza.

Eu recomendo mudar o foco do processo para evitar isso. Por exemplo, ao invés do investigador exibir um e-mail, imprimi-lo e o tabelião registrar na ata algo sobre ele (declarando, por exemplo, que o e-mail é de fulado ...), é mais indicado que o investigador possua um procedimento detalhado de como extrair o cabelhado do e-mail, e então, frente ao tabelião, siga rigorosamente cada passo de seu procedimento. No final, o tabelião irá registrar na ata que o investigador seguiu todos os passos indicados no procedimento, reproduzindo-o, e vai registrar também cada resultado obtido. Dessa maneira, fica mais fácil para nós e para eles.

A Ata Notarial é especialmente importante em casos de "live acquisitions", Forense de Rede e "live analysis".

Live Acquisition é quando fazemos a aquisição de uma imagem forense com o computador ligado. Por mais que pareça estranho, já que a análise post-mortem é a mais comum e estudada, em alguns casos precisamos investigar incidentes em servidores que não podem ser desligados (imagine uma empresa com 90% do faturamento vindo pelo seu web site). Outro motivo comum para o live acquisition é quando o servidor é um RAID e não temos condições de fazer a aquisição de cada um dos HDs para montagem posterior (casos quando o array não é reconhecido pela ferramenta de aquisição). Nesses casos, simplesmente a técnica de usar hash para validar a integridade não vai funcionar, já que o disco estará em uso. Será necessário validar a operação através de um procedimento e da Ata Notarial.

Na Forense de Rede, as técnicas não disponibilizam possibilidade de retirar a origem de uso. Veja o caso que já citei, sobre e-mails. Outra situação envolvendo Forense de Rede seria a investigação de um código malicioso através de monitoramento de pacotes em um determinado ponto. O arquivo resultante (um pcap, por exemplo), pode ser guardado segundo o processo de cadeia de custódia, mas isso é menos comum de encontrar. Validar essa captura com uma Ata Notarial é muito importante, já que ela não poderá ser reproduzida.

Live Analysis (ou Live Response) é quando evita-se desligar o computador (em geral, servidores) por redução do prejuízo ou ainda por reconhecer que, ao desligá-lo, importantes evidências voláteis desaparecerão. Nesse caso, faz se a captura da memória e de outras informações voláteis. A validação por hash, nesse caso, novamente não funciona, e será necessário uma Ata Notarial para validar o procedimento como um todo.

Cadeia de Custódia

A Cadeia de Custódia é um procedimento que surgiu nas investigações não-digitais, e tem por objetivo preservar a fonte de evidências (as mídias, no nosso caso) através do registro de todos que tiveram contato com o material. O processo pode ser exemplificado assim:

- O investigador realiza a aquisição da imagem forense, lacra o HD, inicia a lista da cadeia de custódia indicando a data/hora em que o HD foi lacrado, e o hash/algoritmo (md5/sha-1, etc) da mídia. O tabelião registra tudo na Ata Notarial.

- Qualquer pessoa que precisar, obviamente por motivo justificado, acessar novamente o HD, o lacre deverá ser rompido, e antes da mídia ser usada, sua integridade deve ser conferida, analisando seu hash atual com o registrado na cadeia de custódia. Após o uso, o HD volta a ser lacrado, a data/hora de retirada e devolução do HD são registrados na cadeia de custódia, e tacitamente essa pessoa está aceitando que o hash confirmou a integridade. Esse procedimento deve ser acompanhado também para a Ata Notarial.

- Se, em algum momento, a mídia for acessada e a integridade tiver sido violada, o responsável é o ultimo registro na cadeia de custódia.

Algo importante a se dizer é que nem a Ata Notarial nem a Cadeia de Custódia ou qualquer outro item que compõe o processo litúrgico consegue, sozinho, garantir a evidência ou a ausência de fraude. Em última análise, o que vai garantir mesmo isso é a realização de uma investigação bem fundamentada, apontando as hipóteses e, através da correlação de TODAS as evidências e artefatos (e não apenas a primeira encontrada), chegar a uma conclusão sólida. Tanto a Ata Notarial quanto os demais itens são pilares que sustentam o todo.

Comentários ?

Até o próximo post !

Referências:

O Ciberespaço e a Ata Notarial

ATA NOTARIAL

Ata notarial como meio de prova - uma revolução no processo civil

Ata notarial possibilita a produção de provas com fé pública do tabelião no ambiente eletrônico

Novidade na área

A versão 12 do Live CD do FCCU está liberada.

Dentre outras alterações, ele agora está baseado em Debian e está disponibilizando uma nova ferramenta gráfica de aquisição de imagens forenses, o GuyMager. Há também uma interface gráfica padrão, o que facilita bastante o seu uso.

Vá conferir aqui !

Comentários sobre a nova versão de quem já a testou ?

Até o próximo post !