Instalando o Volatility no Windows

Opa, e aí galera.

Tudo bem?
A ferramenta volatility é muito conhecida na forense de memória, aliás é uma das ferramentas mais populares de forense de memória no mundo open source.
Segundo o site desta ferramenta: The Volatility Foundation is an independent 501(c) (3) non-profit organization that maintains and promotes open source memory forensics with The Volatility Framework.

A questão é que muitas vezes nós encontramos o framework volatility em distribuições linux voltadas para forense computacional (e.g. CAINE, DEFT, SIFT, KALI, etc). E se eu quiser instalar em ambientes Windows? Como eu faço? É esse o propósito desse post: mostrar como instalar o volatility em ambientes Windows.

1) Instalando o Python
Muito bem, vamos lá. A primeira coisa a se fazer é baixar e instalar o python. O faq do volatility diz que pode ser o python 2.6 ou versões acima; mas não pode ser o python 3.x.
OBS: o wiki de instalação da ferramenta diz que podemos instalar pacotes adicionais (se formos usar certos plugins). Mas se instalarmos o básico, a ferramenta ainda irá funcionar. Nesse post, nós vamos instalar o básico da ferramenta.

Eu vou baixar e instalar a versão 2.7.0 do python.
Depois de instalar o python, eu preciso setar nas variáveis de ambiente do sistema.

Abro o painel de controle, clico na opção "Sistema e Segurança" e escolho a opção "Sistema". Depois disso clico na opção "Configurações avançadas do sistema"

Na janela que aparecer, eu escolho a aba "Avançado" e clico no botão "Variáveis de Ambiente"

Depois, no campo Variáveis do sistema, eu vou procurar pela variável "path" e clicar em "editar". Vai abrir uma nova janela para editar a variável do sistema; eu vou adicionar no fim da linha o sinal de ponto e vírgula (;) e o caminho completo de onde o python foi instalado (no meu caso, o python está no C:\Python27). Depois clico em OK



2) Instalando o Volatility
Eu vou baixar a última versão do volatility, que nesse momento é a 2.5. A versão do volatility é a 2.5 Windows Standalone Executable.zip
Eu vou criar uma pasta dentro do C:\ e vou renomeá-la para vol (C:\vol). E aí vou descompactar todo o conteúdo do arquivo volatility_2.5.win.standalone.zip lá dentro.

Depois, eu vou abrir o CMD do Windows e vou navegar até o diretório C:\vol (que é onde eu tenho o executável do volatility). E aí é só digitar no CMD: volatility.2.5-standalone.exe -h


3) Executando o Volatility
Eu vou mostrar a execução do volatility em um dump de memória de um CTF, o grrcon 2015. A linha de comando do volatility no windows é: volatility.exe -f [dump de memória a ser analisado] --profile=[profile que obtivemos usando o plugin imageinfo] [plugin que queremos usar]. Como exemplo, eu vou usar um dump de memória que tem o nome "Target1-1dd8701f.vmss". Portanto, a linha de comando para usar o volatility no windows fica assim: volatility.exe -f "c:\grrcon 2015\target1\Target1-1dd8701f.vmss" --profile=Win7SP0x86 pslist



Bom, é isso.
O volatility rodou numa boa, sem nenhum problema.
Espero que esse post seja importante
Um abração!

Algumas Dicas de Procedimentos Para Apresentar e Analisar Uma Evidência Digital Durante Um Processo Legal

Opa, e aí?

Tudo Bem?
Eu recebi um email com algumas dicas de como apresentar e analisar uma evidência digital diante de uma corte jurídica e de um processo legal.

Imaginem que estamos analisando uma evidência digital (e.g. uma imagem forense de um HD) e que o caso será apresentado para um juizado qualquer. A outra parte (consultoria jurídica da outra parte) pode duvidar do seu processo de aquisição da imagem forense.
Então essas dicas a seguir serve para mostrar como fazer a aquisição de uma imagem forense, minimizando os riscos de questionamento da outra parte.

Essas dicas são do Nick Klein:
Some tips from my experience:

- I’m not aware of any cases of a court mandating a forensic tool (interested to hear if anyone can quote a case). In fact, I’ve worked on cases where ‘experts’  have misinterpreted evidence they acquired using “court validated” forensic tools. As the old saying goes - just because you’re holding a scalpel, doesn’t make you a surgeon. Don’t be fooled by people who tell you evidence is by default inadmissible if you don’t use a particular tool or process.

- However you DO want your evidence to be strong in terms of integrity and authenticity. Document every step you take while acquiring. Take photographs. Use well established industry processes.

- Some excellent (free) tools include:

  -- Linux boot distros like Paladin / DEFT which don’t mount internal drives by default (therefore no changes to them) and have easy to use imaging tools.

  -- You could also make Windows read-only for USB devices by making a Registry change, then use a tool like FTK Imager. Note these only stop writes through the Windows API, but that should be sufficient unless you have programs that access the device raw. 

- To ensure you have the most amount of data for analysis, use a tool and process that captures the entire data area of the drive, not just live files. Tools like Ghost refer to “images” but they’re NOT the same as a full forensic image that include every sector of the original physical medium (which I assume you want).

- In my experience (in Australia) if the court accepts your evidence is what you represent (because you’ve followed these steps) the onus of proof falls to the other side to disprove its authenticity. I’ve never had a case where the other side has successfully won such an argument.

- If the other side are attacking your credibility or your process, then your evidence is probably strong.



Essas outras dicas são de uma pessoa chamada VSuen:
Your Question:
  • Are there free or open source tools that you can use in place of a hardware write blocker that is admissible in court?
Answer:
  • Yes. But your reference to the term "admissible in court" is a bit vague. See Nick's comment.
    • Don't let EnCase tell you they are the only court-verified tool. That's marketing FUD.
      • I like and use their product, but I don't like sales people that much. They make a good product, but there are a lot of good products out there.
    • You should be more concerned about your processes, documentation, and validation activities than the specific court-approved tool since there is no such thing.
      • Consider the possibility that what you write can be discoverable.

Examples:
For the following examples, I encourage you to test the process out with some other media BEFORE you attach your real evidence. Practice makes perfect-ish.
  • MS Windows:
    • There is a simple registry tweak that you can make to prevent writing to USB devices. Search for "Software USB Write Block" and you should have at least two results. One is Irongeek's Thumbscrew and another is DSI's USB Write Blocker
      • Both software and manual registry change work the same way.  It changes one registry value. I believe this functional from Windows XP and up. You will want to double check that.
      • Manual Registry Change: http://www.ghacks.net/2011/03/18/how-to-enable-write-protection-of-usb-devices-under-windows/
        • I don't recommend this method for those new to forensics. It is very easy to forget what write/read state you're in. If you go the software route, I encourage you to use an application that reflects the write state you are in.
    • I have used an IDE/SATA to USB adapter that you can purchase from Amazon for about $25
    • Once you have this properly working, you can use FTK Imager or EnCase Imager (or any imager) to create a forensic image.
      • I personally prefer a commonly used forensic file format like EWF, RAW, or AD1 over disk duplication because the impact of "accidentally" plugging in the drive to a read/write situation is significantly lower. A disk duplication scenario can result in you "altering" files.
    • If you already have EnCase Forensic Edition, I believe they have a Softblock feature that allows you to prevent writes to devices AFTER the feature has been enabled. It has been a while since I've used it. Consult with Guidance Software for confirmation.
  • Linux - Forensic Distributions Only:
    • You want to ask: Is the distribution specifically built for forensics or information security?
      • Some consumer distributions of Linux (such as consumer Ubuntu) will automatically mount file systems read/write (r/w) to be consumer friendly. You don't want that because there is a chance that something will write to the drive.
      • Forensics-oriented distributions such as CAINE, Kali, Paladin, SANS SIFT, etc. will recognize your drive is attached but typically will not automatically mount the device or its file systems.  This is good.
        • Distrowatch is a good place to start if you want to go this route. The link I embed drops you straight to the search feature with the "Forensics" category highlighted.
        • This method, effectively, is your "free open source write blocker"
        • Here are some commands to get comfortable with:
          • man [command] - manual for the binary you are executing
          • sudo - run the next command with elevated credentials (admin-level)
          • fdisk - this will show you what devices the OS has detected as attached to your computer
          • mount - this is the command you will run to mount the drive
            • Warning. This is the one you really want to be careful with.
              • Consider looking at these options via the man page:
                • -o ro (or -r): mount device as read only
          • umount - unmount device
          • without knowing what you are doing, you'll probably run these commands in this order:
            • sudo fdisk -l
              • Show me all the devices I've attached
              • This will give you the "/dev/sda#" I mention below.
              • Don't see anything? You probably didn't "sudo"
            • sudo mount -l
              • Show me what devices are mounted, if they are ro/rw, where are they mounted, etc.
            • sudo mount -o rw /dev/sda1 /media/sda1
              • Human: Mount in read only mode partition 1 on device "sda" to logical location/mount point /media/sda1
              • Complaints: You might get some errors regarding file system type. You will have to research that.
            • sudo mount -l
              • Show me the devices again AND confirm that the device you mounted is "ro"
        • "Easy" way?
          • Mount your target media as rw via command line or similar
          • Use Guymager, AIR, or whatever the forensic acquisition tool of choice is
          • Attach your original evidence; do not mount
          • Point Guymager (or similar) to the row that reflects that new device, right click, acquire to target media
            • Add notes appropriate for the image file format you use
              • I like evidence ID, custodian name, source metadata like make|model|SN, date of acquisition, forensics collection person responsible for the image, etc.
  • Mac OS X:
    • I don't really play in this area. Someone else might have a better suggestion. I won't validate these suggestions. I won't testify to the effectiveness either.
    • Not free, but have you looked at BlackBag Technologies' Softblock?
    • Command line use of diskutil?
      • Do not do this one:
        • One method you will see if Google for it is the use of diskutil to identify your UUID then alter your fstab file to always force the device to "rw". However, that's ridiculous because you will have already attached your device at that point and OS X would have had already attempted to mount the partition. At that point you have already placed your evidence at risk.
      • This *might* work:
      • Probably the better solution if you know what you are doing:

Basic Logic of Software-based Write Blockers:
  • Write blocking is only enabled for all devices attached _AFTER_ you have enabled the write blocking feature.
    • This suggests that all devices attached _BEFORE_ you enabled the write blocking feature will continue to be writable.
    • In theory, this also suggests that all devices attached _AFTER_ write blocking is disabled, all devices attached BUT NOT REMOVED prior to disabling software write blocking will continue to be not writable.
      • I wouldn't trust it. Just play it safe and attach all your "write to" media _BEFORE_ you perform a software write block and attach your "original evidence" media.


To expand a bit on Chris' comments...

Somethings you might want to do right away:
  • Evidence Control:
    • Did you create a chain of custody document and associate it with this piece of physical evidence?
      • If not, I highly suggest you properly document the life cycle of the media you received from the time you received it. You can easily search on the SANS reading room for a simple Chain of Custody form. Not having basic evidence history makes it challenging to defend that you have had positive control over the media at all times.
    • Where do you store this evidence when you are not using it?
      • Ideally you have a secure storage location that only you have access to.  A locked desk drawer is a starting point, but we can venture into multiple layers of significantly better storage controls. Start with what you can afford because it sounds like you are running on a budget. There's no shame in that.  Ideally, like any evidence management solution, you should clearly label the device and associate it with your evidence. You don't want to accidentally misplace it in your secure storage location and accidentally associate it with another case.
    • When you use the Evidence (for imaging or for investigation), what is your procedure?
      • Ideally you are checking out the evidence from your really great Evidence Management System.  If you are not so blessed, consider using the Chain of Custody form to indicate when you have moved it from storage to your work space for doing a task. It can be overkill, but you want to do this right. I've seen people do this on Excel too.
      • When you are manipulating the evidence, do you do this from a clean workstation and in a secure area that only you have access to?
        • Opposing counsel's view can include: "How do I know you this evidence wasn't tampered with if you aren't the only one who has physical access to this media?"
  • Forensic Preservation Procedures:
    • Do you have at least a Primary and Secondary Forensic copy of the evidence?
      • I'm jumping the gun on your question here obviously. However, if you decide to duplicate the media, I encourage you to make at least two copies.  One you keep as your "working" copy and another as your "backup" copy in the event something frustratingly happens to the working copy.  It happens all the time. Trust me. You want at least two copies.
        • If you are creating a copy for opposing counsel, make a copy but don't give away your two copies. Asking opposing counsel for a copy _after_ you damaged your only copy looks bad and can impact the timeliness of your response to discovery.
    • When you create your forensic copies, did you document other appropriate metadata?
      • You can probably google for a basic Computer Evidence Acquisition form.  You want to capture several things that you probably don't need immediately but can assist with the individual who will be performing your forensic investigation.  This isn't exhaustive, but I want to give you ideas of what would help:
        • Original Asset Information:
          • State of Asset
            • On, Logged in, Logged in & locked, Off, Other (BSOD, Frozen, etc.)
          • Make, model, and serial number of original asset; Make, model, serial number, and sectors of media.
            • Where did this hard drive come from? How do we know you didn't just grab the hard drive out of someone else's computer?
            • It helps to have a digital photo with a date/time stamp too. I typically do this with the evidence ID I assign it written on a post-it note along with the primary custodian name. This way if I'm hitting multiple computers with multiple people I can easily flip through pictures to find relevant items.
          • Who is/was the custodian associated with the original asset?
            • Location of the asset, the username(s), the given name of the user(s), etc.
          • BIOS/EFI Date/Time vs. Real Date/Time
            • If you're not working in the same time zone as you collected the evidence then this will really mess with your timelining process.
          • Notes?
            • What else does your form not include but should be documented?
            • Items that I commonly see: Company Asset Tag #, asset damage information, location of asset at time of preservation, symptoms reflecting physical media failure.
    • Did you mess up? Maybe you did. Don't freak out.
      • This is where your meticulous documentation skills kick into high gear. What did you do? What was the expected result? What actually happened? What time did this occur? What files were potentially altered?
      • Know when you are in over your head. If this is important, hire someone who knows a little bit more than you and won't put your case in jeopardy.
    • SUPER IMPORTANT: Do you know what you are doing? Can you explain why you chose to do X instead of Y to a jury?
      • Can you testify to the actions that you performed were best practice and did not impact the evidence?
        • If so, great.
        • If not, consider getting a professional forensics expert or have a forensics firm on retainer or MSA.
          • For forensic imaging services, you can typically see:
            • Billing method 1: time and materials
            • Billing method 2: fixed fee
            • Billing method 3: fixed fee and materials.
          • Rates and quality of work product vary by region. I'm sure those on this list can give you recommendations.
  • Forensic Analysis:
    • If you don't know what you are seeing, consider the possibility that you might be over your head in this phase.  Highly consider the need to employ a professional that can and has testified in court for digital forensics. Ideally, someone who has testified in a case similar to yours.
    • Consider the possibility that what you are seeing can be interpreted in more than one way.
      • Remove unfounded opinion from any statements you choose to document.
      • State only the facts that you can observe.
    • Note: Forensic Expert bill rates can be different from a Forensic Preservation bill rate.

There's a lot more. I see that Nick has responded too.  He knows his stuff.

Good luck and thanks for letting me stand on this soapbox.
V.

Eu recebi todas essas informações por email e resolvi colocá-las aqui.
São dicas muito boas.

Bom, é isso, galera
Um Abração!

Parsing da MFT

Opa, e aí galera.

Tudo bem?
Neste post falamos sobre como extrair a MFT de uma imagem forense. Hoje, nós vamos mostrar algumas ferramentas para fazer o parsing da mft extraída, e assim, poder analisá-la.

Vamos falar de 2 ferramentas para fazer o parsing da MFT: log2timeline e analyzemft.py. Existem outras ferramentas, mas vamos falar sobre essas 2. Se vocês quiserem ver outras ferramentas, podem acessar este link aqui.

1) Log2timeline
Esta ferramenta foi criada por Kristinn Gudjónsson como paper final para a certificação GCFA Gold. Ele criou esta ferramenta com o intuito de se criar uma super timeline do sistema a ser investigado. Isto traria uma melhor compreensão e uma visão holística dos eventos de um sistema a ser investigado. Super timeline significa ter um timeline de várias fontes de informação e artefatos do sistema operacional (e.g. histórico do I.E., timeline de informações do squid, apache, IIS, prefetch, evt, setupapi.log, userassist, etc); ou seja, podemos juntar todos os timelines de todos esses artefatos em um grande arquivo, e, assim, teremos um melhor contexto necessário para ter uma melhor visão do que realmente aconteceu no sistema comprometido.
O log2timeline funciona usando módulos. Cada módulo trabalha em cima de um tipo de artefato. Por exemplo, o módulo prefetch vai trabalhar em cima de artefatos do prefetch, o módulo IIS vai trabalhar em cima de artefatos do IIS, o módulo squid vai trabalhar em cima de artefatos do squid, o módulo mft vai trabalhar em cima de artefatos da MFT, e assim por diante.

"Versão 0.x do log2timeline tem sido extremamente útil, mas foi escrito em Perl e tem limitações de desempenho. Está em curso um grande esforço para reescrevê-la em Python, chamada Plaso. Alguns lançamentos alfa desta ferramenta forma liberados." (tradução livre, fonte: aqui).

Se você quiser instalar o plaso, pode seguir as instruções desta página. Mas, se você estiver tendo algum tipo de problema na instalação, pode seguir as instruções desta página.
Aqui neste post, nós não vamos falar do plaso; nós vamos falar do log2timeline mesmo. E vamos focar na análise da MFT. Se alguém quiser ver algum outro uso do log2timeline, você pode entrar aqui, aqui e aqui.

Podemos usar o log2timeline em um arquivo de imagem forense ou podemos montar a imagem forense e depois usar o log2timeline.
Para usar o log2timeline em um arquivo de imagem forense é bem simples. Nosso arquivo de imagem forense aqui se chama image.001. Eu vou ter como parâmetros o -f que indica qual módulo eu vou trabalhar. Neste caso, como eu vou analisar a mft, então eu vou usar o módulo para se trabalhar com a mft; este módulo, por curiosidade, se chama mft :). Por último, eu vou usar o parâmetro -w que vai me indicar qual será o outuput de escrita, ou seja, o parâmetro -w me indica qual arquivo ele vai armazenar o resultado depois de realizar o parsing. No nosso caso, a ferramenta log2timeline vai armazenar o resultado no arquivo timeline.csv. Assim, eu posso abrir o calc e analisar o resultado em uma planilha.

Se eu quiser, eu posso usar o parâmetro -z local. Assim, o timezone que ele vai analisar não será o UTC, e sim o timezone usado na máquina invadida (máquina esta à qual o log de eventos pertence), o que facilita a interpretação e contextualização dos acontecimentos.

A figura a seguir mostra o resultado do log2timeline. Como o resultado foi um arquivo do tipo .csv, eu abri o arquivo no calc.


2) Analyzemft.py
Outra ferramenta para analisar a MFT é um script em python, o analyzemft. O link para baixar a ferramenta é este aqui. Esta ferramenta é bem simples de trabalhar.
Vale lembrar que ela já vem instalada na SIFT.

O comando funciona assim: python analyzeMFT.py -f [mft extraída] -o [arquivo onde os resultados serão armazenados]
No meu exemplo a mft etraída se chama mft.raw e eu vou escrever os resultados no arquivo mftanalyzed.csv.
Portanto, a linha de comando fica assim: python analyzeMFT.py -f mft.raw -o mftanalyzed.csv
Essa é a linha de comando normal. Só que no meu caso, eu estou usando a SIFT 3.0, vai dar um erro:

Esse erro aconteceu porque eu preciso passar o caminho completo do script analyzemft. Então, a linha de comando correta é: python /usr/bin/analyzeMFT.py -f mft.raw -o mftanalyzed.csv.
Pronto, agora vai tudo normal como mostra a imagem a seguir:

O arquivo de output é do tipo .csv. Isso significa que podemos abrir e analisar o arquivo em um software de planilha, por exemplo, o calc ou o excel.
Quando abrirmos o arquivo no calc, vai aparecer a seguinte tela:

Esta tela mostra como o calc vai interpretar as informações. Nós vamos falar para o calc separar os dados através da vírgula. Assim, cada coluna (campo) será um tipo de dado.
Os campos são:

  • Record Number: MFT Entry
  • Good: se a entrada é válida
  • Active: se a entrada é ativa
  • Record type: mostra o tipo de registro
  • Sequence Number: o número de sequência do registro
  • Parent file record number
  • Parent file record sequence number: número de sequência de registro de arquivo pai
  • Filename: nome do arquivo/diretório
  • Algumas informações do Atributo Standard Information: mactimes referentes ao atributo Standard Information
  • Algumas informações do Atributo File_Name: mactimes referentes ao atributo File_Name
  • Object ID
  • Birth Volume ID
  • Birth Object ID
  • Birth Domain ID
  • e outros;
Podemos usar as teclas CTRL+F para procurar por um arquivo.
Na imagem a seguir, eu procurei pelo arquivo "satriani". Ele me encontrou o arquivo "satriani.jpg", cujo record number (MFT record) é 45931; assim, eu posso usar o icat para extrair o conteúdo referente a esta entrada MFT, ou qualquer outra entrada que eu queira.


Bom, é isso galera.
Mostramos um pouquinho sobre as 2 ferramentas. É claro que elas fazem muito mais do que isso, eu só quis "dar um empurrão". :)
Um abraço!






Referências Bibliográficas:

Extraindo a MFT de uma Imagem Forense

Opa, e aí galera

Tudo bem?
Hoje, nós vamos falar sobre como extrair a MFT de uma imagem forense. Obviamente que a MFT é um recurso do Windows. Então, nesse post aqui, nós estaremos analisando uma imagem forense do windows.

1) Introdução
Mas qual a importância da MFT para a análise forense de uma imagem? A MFT é o principal arquivo no NTFS. Nela estão armazenadas referências de todos os arquivos e diretórios do sistema operacional. A MFT armazena os timestamps de cada arquivo, o tamanho, o dono dos arquivos/diretórios, permissões de segurança do arquivo/diretório, etc.
Todas essas informações são armazenadas no que chamamos de MFT Entry.
Cada arquivo/diretório possui uma mft entry (entrada mft). Essa entrada mft (mft entry) é como se fosse um ponteiro, similar ao inode no mundo UNIX.
Portanto, a mft entry contém informações (metadados) sobre o arquivo ao qual ela aponta.

Normalmente, cada entrada mft (mft entry) possui 1024 KB de tamanho. Se olharmos cada entrada mft em um editor hexadecimal, vamos ver que ela começa com a string "file0" ou "file", seguida de informações específicas.
As primeiras 16 entradas da MFT são reservadas para arquivos do NTFS, por exemplo, $BitMap e $Log.

Para o NTFS, tudo é arquivo, inclusive a MFT (que contém informações sobre os arquivos). Portanto, a MFT possui uma entrada pra ela mesma. Este é o primeiro arquivo de toda MFT: uma entrada pra ela mesma, que é representada por $MFT (mft entry 0). O segundo arquivo da MFT é o arquivo $MFTMirr (mft entry 1). O objetivo de existir o $MFTMirr é se ocorrer algum tipo de problema com as primeiras entradas reservadas da mft, eu tenho o $MFTMirr. Ou seja: o $MFTMirr é um backup das 16 entradas reservadas da MFT.

2) Extraindo a MFT de uma Imagem Forense
Eu já vou partir do pressuposto de que vocês já tenham uma imagem forense de um Windows qualquer. E aí, como eu faço para extrair a MFT da imagem forense? Resposta: eu vou mostrar 2 maneiras de extrair a MFT de uma imagem forense:
  1. usando o FTK Imager
  2. usando ferramentas do sleuthkit
2.1) Extraindo com o FTK Imager
Uma maneira simples de se extrair a MFT de uma imagem forense é usar a ferramenta FTK Imager. A figura a seguir mostra um exemplo:

Depois de exportar a MFT, eu vou gerar um arquivo dela. Assim, eu posso escolher qualquer ferramenta que faça o parsing da MFT e analisá-la.
Muito simples, né? :)

2.2) Extraindo a MFT com o Sleuthkit
Uma outra forma de extrair a MFT é fazendo uso do sleuthkit.
Cabe ressaltar que o arquivo $MFT ocupa a primeira posição (posição 0) na MFT. Como eu sei disso? Basta digitar o comando fls "imagem". Assim, a linha de comando é: fls image.001

Neste exemplo, a minha imagem forense se chama image.001.
O utilitário fls lista os arquivos e os diretórios de uma imagem forense.
OBS: a imagem não está montada, por isso eu usei o fls. Se ela estivesse montada, eu poderia usar o comando ls com os parâmetros -lhi.

Depois de usar o utilitário fls, eu vou usar o utilitário icat. O icat serve para copiar um determinado arquivo da imagem forense, tendo como base um determinado inode/mft entry. Isso significa que temos que passar um endereço (número do inode/mft entry) correspondente ao arquivo que queremos copiar da imagem forense.
No nosso exemplo, eu vou copiar a MFT da imagem forense. Como o inode da MFT é 0 (zero), eu vou passar esse endereço na linha de comando do icat.
Portanto, a linha de comando do icat fica assim:
icat -i raw -f ntfs image.001 0 > MFT.raw

Que parâmetros são esses?
É simples. O parâmetro -i indica que a imagem original de onde vamos extrair a mft é uma imagem forense do tipo/formato raw. O parâmetro -f indica que o sistema de arquivos da imagem forense é NTFS. E esse parâmetro 0 (zero), como já dissemos anteriormente, é o endereço da entrada mft da própria mft. No caso, a mft possui como entrada o endereço 0 (zero). Ou seja, a mft entry da própria mft é 0 (zero).

OBS: Existem outras ferramentas que fazem esse trabalho de extrair a MFT de uma imagem forense. Como exemplo, vocês podem ver aqui.

Pronto, agora extraímos a MFT da imagem forense. Qual o próximo passo? É analisar a mft extraída.
Mas isso fica para os próximos capítulos. :)

Bom, é isso galera
Espero que seja útil para o estudo e trabalho de vocês
Um abraço!




Referências:
http://sysforensics.org/2012/01/sift-workstation-video-4-extracting-mft-using-mmls-icat-and-log2timeline/
https://whereismydata.wordpress.com/2009/06/05/forensics-what-is-the-mft/
https://whereismydata.wordpress.com/2008/08/22/file-system-mft-entries-basic/
http://www.cse.scu.edu/~tschwarz/coen252_07Fall/Lectures/NTFS.html
http://grayscale-research.org/new/pdfs/NTFS%20forensics.pdf
https://en.wikipedia.org/wiki/NTFS

Conversão de Imagens

Opa, e aí galera.

Tudo bem?
Hoje nós vamos falar sobre conversão entre alguns formatos de imagens forense. Lembrando que temos basicamente 3 tipos de formato forense: raw (dd), ewf/e01 e AFF. Existem outros, mas esses são os mais usados.
Então, a intensão deste post é falar sobre como fazer a conversão de um formato para outro formato.
Resumindo, o que nós vamos fazer nesse post é a conversão dos seguintes formatos:

1) Conversão do formato EWF/E01 para o formato RAW
Bom, falamos sobre o formato ewf/e01 aqui. Mostramos, inclusive, sobre como criar uma imagem forense nesse formato. Agora, nós vamos mostrar como eu posso converter uma imagem forense "ewf" para o formato "raw".
Mas você pode estar se perguntando: por que eu quero converter de e01 para raw? Qual o benefício disso? A minha resposta é: a partir do formato RAW, eu posso realizar várias técnicas como o file carving visando a recuperação de arquivos, eu posso usar ferramentas para analisar o timeline (e.g. log2timeline), eu posso fazer exame de evidências em geral (analisar o registro do Windows, analisar o histórico do browser, etc) fazendo uso de várias ferramentas forense (até mesmo ferramentas open source). Tudo isso eu consigo fazer quando analiso uma imagem no formato RAW.
E se eu não converter para RAW? Se eu quiser analisar a imagem no formato EWF mesmo? Quais ferramentas eu vou usar para analisar uma imagem no formato EWF? A minha resposta é: basicamente, você vai usar o EnCase, que é uma ferramenta paga/proprietária.

Bom, então vamos lá.
O que eu quero, neste momento, é converter uma imagem do formato ewf para o formato raw. Pra isso, eu preciso ter uma imagem no formato ewf, não é mesmo? :)
E aí vem a pergunta: Onde eu vou conseguir uma imagem .E01/EWF? Resposta: eu vou usar uma imagem forense criada para um exercício do Lance Mueller, o forensics_practical_3. Pra baixar a imagem referente a este exercício, basta ir neste link. No fim deste post, ele coloca o link para baixar a imagem forense.

Existem 2 maneiras de realizar a conversão do formato ewf para o formato raw:
  1. Usando o utilitário ewfexport (que faz parte da libewf)
  2. Usando o utilitário img_cat (que faz parte da suíte do sleuthkit)
Vamos mostrar as 2 opções.
A primeira opção que vou mostrar é usando o utilitário ewfexport.


O utilitário vai fazer algumas perguntas básicas. Vamos analisá-las:
  • na primeira pergunta, ele quer saber qual o formato depois da conversão. No caso, eu escolhi que após a conversão, a imagem vai ser no formato raw
  • na segunda pergunta, ele quer saber o caminho completo do diretório onde a imagem no formato raw será armazenada. Nisso, ele pede pra ser incluído o nome da imagem no formato raw (sem usar nenhuma extensão no nome). No exemplo aqui eu disse que a imagem no formato raw vai se chamar imagem (ele vai adicionar a extensão automaticamente). O path completo (caminho do diretório) onde a imagem será armazenada vai ser em /home/sansforensics/Desktop/cases/Forensics_practical. Lá dentro, vai ter um arquivo chamado imagem.raw.
  • na terceira pergunta, o tamanho do segmento. Esse segmento é quando queremos trabalhar com o chamado split image. E o que é isso? É quando queremos dividir o nosso arquivo de imagem forense em vários pedaços/segmentos. Aí então, se quiséssemos uma split image no formato raw, iríamos indicar qual o tamanho de cada segmento. Como eu não quero que a imagem no formato raw não seja "repartida" em segmentos, eu escolhi o valor zero (0). Isso significa que eu não vou querer "splitar" a imagem forense; eu vou querer somente um arquivo, mesmo que seja grande, para ser a minha imagem forense no formato raw.
  • na quarta pergunta, ele quer saber qual o primeiro byte que será exportado/convertido. Podemos notar que ele mostra um intervalo que vai de 0 até 7.9 EiB. Nesse caso eu indiquei que o primeiro byte a ser exportado/convertido é o byte 0, justamente porque eu quero converter toda imagem no formato ewf, desde o início. Como o início é no byte 0, então eu indiquei que ele vai começar a exportar/converter desde o início :). Isso parece até um pouco óbvio :)
  • na quinta pergunta, ele quer saber o número de bytes a ser exportado/convertido. Como eu quero converter toda a imagem forense, então eu optei por converter o número máximo de bytes da imagem, assim significa que eu vou exportar/converter o arquivo inteiro.
OBS: vale a pena observar que ele mostra os valores defaults entre colchetes. Se você quiser os valores default, é só apertar a tecla Enter.
Como dissemos no post anterior, o formato EWF permite a compressão de dados. Então, a imagem no formato EWF será bem menor do que a mesma imagem no formato RAW.

Outra alternativa que nós temos é usar o utilitário img_cat, que faz parte da suíte de utilitários do sleuthkit. O comando é: img_cat -v -i ewf "imagem.e01" > "imagem.dd"

Podemos notar alguns parâmetros na linha de comando. O primeiro parâmetro (-v) significa que ele vai jogar para o stderr uma saída detalhada de erros; o parâmetro (-i) indica qual é o tipo da minha imagem antes de ser convertida. Neste caso, eu disse que antes da conversão, a minha imagem original é do tipo/formato ewf. Por fim, eu tenho um redirecionamento para um arquivo de imagem forense do tipo raw (imagem.dd).

Podemos notar também a compressão de dados do formato EWF. A imagem no formato EWF é bem menor do que a imagem no formato RAW.


2) Conversão do formato RAW para o formato EWF/E01
E se eu tenho uma imagem forense no formato RAW e quero convertê-la para o formato EWF. Como eu faço isso? Resposta, eu posso usar um utilitário que faz parte da libewf, o ewfacquire.
No post sobre imagens ewf, eu comentei sobre esse utilitário (este utilitário serve para se criar uma imagem forense no formato ewf). Só que eu também posso usar este utilitário para converter uma imagem raw para uma imagem ewf/e01.
Como eu faço isso? Basta digitar: ewfacquire "nome da imagem no formato raw".
Para exemplificar, eu tenho uma imagem no formato raw chamada: imagem.raw. Se eu quiser convertê-la para o formato ewf/e01, basta digitar o comando: ewfacquire imagem.raw. Assim, eu vou converter o arquivo imagem.raw para o formato ewf/e01 (tornando assim imagem.e01).


Vocês podem notar que ele vai me pedir para responder algumas questões básicas. Essas questões são os metadados referentes à imagem no formato EWF (lembram que esse tipo de formato permite armazenar metadados?). Pois é, são algumas perguntas básicas, coisa rápida (nós já vimos sobre o ewfacquire aqui).
Lembrando que para responder as perguntas com as opções default, basta apertar a tecla "enter". Depois de responder essas perguntas, ele começa o processo de conversão. Ao fim, ele mostra quanto tempo durou essa conversão e o hash da nova imagem forense (imagem esta que está no formato ewf).
Agora, uma pergunta: o ewfacquire mostra o hash da nova imagem. Se eu digitar "md5sum imagem.E01", porque esse novo hash vai ser diferente do hash apresentado pelo ewfacquire? Resposta: o hash mostrado pelo utilitário ewfacquire é calculado somente em cima dos dados (isso significa que o hash não leva em conta os metadados da imagem.E01). Portanto, o hash mostrado pelo ewfacquire vai ser igual ao hash do arquivo imagem.raw

3) Conversão do formato AFF para RAW
Já falamos sobre imagens AFF aqui. Se alguém tiver alguma dúvida, basta acessar o link para ver como o aff funciona.
Agora, nós vamos falar sobre a conversão do formato aff para raw.
Eu tenho uma imagem física de uma pendrive. Esta imagem física está no formato AFF? Como eu faço para convertê-la para o formato Raw? Resposta: eu uso o utilitário affconvert (lembrando que nós falamos sobre o affconvert aqui).

E como o affconvert funciona para converter de um formato para o outro? Como ele funciona para converter uma imagem no formato AFF para RAW? É simples. O comando é: affconvert -r "imagem.aff". Neste exemplo, a minha imagem no formato AFF se chama "image.aff". Então, neste exemplo, a linha de comando fica assim: affconvert -r image.aff.

Podemos ver que usei o parâmetro -r. Ele serve para falar que após a conversão, a nova imagem será no formato RAW (-r vem de raw).
Simples, né? :)


4) Conversão do formato RAW para AFF
E se eu quiser converter do formato raw para aff? Qual ferramenta eu posso usar? Resposta: o próprio affconvert. O comando é: affconvert "imagem no formato raw". Como eu vou converter um arquivo de imagem que se chama "imagem.raw", a linha de comando fica assim: affconvert imagem.raw.

Notem que eu não tenho nenhum parâmetro na linha de comando.


5) Conversão do formato AFF para AFF
Agora que nós já falamos de algumas conversões, vamos falar sobre conversão do formato AFF para AFF. Mas como assim? Conversão de um formato para o mesmo formato? Não; o que eu quis dizer é que agora nós vamos falar sobre a conversão entre os vários formatos do container AFF. Lembra que no post passado, sobre imagens AFF, eu comentei que existem 3 métodos/formatos para o container AFF? Esses 3 métodos/formatos são o próprio AFF, o AFD e o AFM.
Então, o que nós vamos fazer agora é pegar uma imagem em um destes 3 formatos e converter para outro formato.

5.1) Conversão do formato AFF para o AFM
A primeira conversão será do formato AFF (armazena tanto os metadados quanto os dados em um único arquivo) para o formato AFM (os metadados são armazenados no arquivo .afm e os dados são armazenados no arquivo splitraw).

Notem que,depois do processo de conversão, eu vou ter 3 arquivos. O arquivo image.000 é o meu arquivo de imagem splitraw. O arquivo image.aff era a minha imagem original, antes da conversão. O arquivo image.afm é o arquivo que contém os metadados referentes a imagem splitraw.
Resumindo, em grosso modo, bem simplista, o que fiz foi o seguinte: eu peguei a imagem aff (arquivo image.aff, que contém os metadados e os dados juntamente em um único arquivo) e separei os metadados dos dados em si; os metadados foi para um novo arquivo (imagem.afm) e os dados foram para o arquivo image.000.
Se eu quiser acessar os metadados, basta digitar o comando "affinfo image.afm. Se eu quiser ver a geometria do disco da minha imagem, basta digitar "mmls image.000" ou "mmls image.aff", vai dar no mesmo.

5.2) Conversão do formato AFF para o AFD
Agora, nós vamos fazer a conversão da imagem no formato AFF para o formato AFD. Lembrando que no formato AFF a imagem e os metadados estão contidos em um único arquivo; e, no formato AFD, os metadados estão armazenados na própria imagem forense, porém, quebra-se a imagem forense em alguns "pedaços".

O nome da imagem forense no formato AFF é: image.aff.
Depois do processo de conversão, será criado um diretório para os arquivos AFD (o diretório recebe o nome da imagem com extensão AFD - image.afd). Nesse diretório estarão os arquivos da imagem splitraw. No meu exemplo, dentro do diretório image.afd, eu vou ter o arquivo file_000.aff (que é um arquivo AFF - img_stat file_000.aff). Se eu quiser, eu posso até montar o arquivo file_000.aff usando o utilitário affuse; já vimos esse procedimento aqui.

5.3) Conversão do formato AFD para o AFM
O processo é o mesmo. Eu vou usar o utilitário affconvert com o parâmetro -a.

Depois do processo de conversão, eu vou ter 4 arquivos:
  • image000: a imagem forense em si. Ela é do tipo splitraw.
  • image.afd: era a minha imagem no formato AFD antes da conversão
  • image.aff: é somente uma imagem no formato AFF, que não participou em nada no processo de conversão
  • image.afm: arquivo que contém os metadados referentes à imagem splitraw - metadados referentes ao arquivo de imagem image.000
5.4) Conversão do formato AFM para o AFD
O processo não é diferente. Vamos usar novamente o utilitário affconvert com o parâmetro -a.

Se eu quiser, eu posso até entrar no diretório "image.afd", que eu vou ver um arquivo de imagem AFF lá dentro. No meu exemplo aqui, a imagem AFF que vai estar dentro do diretório image.afd é o arquivo: file_000.aff.
Eu posso fazer o que quiser com o arquivo file_000.aff; eu posso montá-lo, e posso também exibir algumas informações (metadados) referentes à imagem forense, usando o utilitário affinfo file_000.aff

5.5) Conversão do formato AFM para o AFF
O processo para conversão do formato AFM para o formato AFF é o mesmo das outras conversões. Eu vou usar o utilitário affconvert com o parâmetro -a

5.6) Conversão do formato AFD para o AFF
Por fim, nós temos a conversão do formato AFD para o formato AFF. Novamente, eu vou usar o utilitário affconvert com o parâmetro -a.


Bom, é isso galera.
Espero que esse post tenha alguma importância para você, leitor.

Um abraço!





Referências:

Imagens AFF

Opa, e aí galera.

Tudo bem?
Nós já falamos sobre imagens no formato EWF/E01 aqui. Agora, nesse post, nós vamos falar sobre um outro tipo de formato de imagens forense: o formato AFF.

1) História
Pra começo de história, este formato foi idealizado pelo cientista Simson Garfinkel e a empresa Basis Technology. AFF significa Advanced Forensics Format. A versão mais recente do AFF foi implementado pela sua biblioteca, a AFFLIBv3, que pode ser encontrado em seu github. Não vamos confundir o formato AFF com o AFFv4. Este último foi um "redesenho" do formato AFF, ou seja, é um novo formato (Fonte: AFF4).

2) AFFLIBv3
Como já dissemos, para ter suporte ao formato AFF precisamos ter instalado sua biblioteca, a AFFLIBv3. Essa biblioteca permite ter suporte a algumas ferramentas que iremos falar mais adiante. Mas vamos falar primeiro sobre o AFF.

O formato AFF foi criado para ser um formato extensível e aberto para o armazenamento de imagens de disco e de seus metadados. Quando eu digo aberto, é porque qualquer um pode "integrar/acoplar" os utilitários da AFFLIB em seus próprios softwares, sejam eles abertos ou proprietários. Quando eu digo extensível, é porque novas características podem ser adicionadas mantendo, ainda assim, a compatibilidade (Fonte: aqui). Além disso, o formato AFF é livre de patentes.

Segundo o Luiz Rabelo, "AFF suporta dois algoritmos de compressão: zlib, que é rápido e razoavelmente eficiente, e LZMA, que é mais lento, mas muito mais eficiente. O zlib é o mesmo algoritmo de compactação usado pelo EnCase. Como resultado, arquivos AFF compactados com zlib são aproximadamente do mesmo tamanho que o arquivo  equivalente no formato EnCase. A grande vantagem é que arquivos AFF  podem ser "re-compactados" (!) utilizando o algoritmo LZMA. Esses arquivos tem um tamanho aproximado de 1/2 a 1/10 do tamanho do original AFF / arquivo EnCase."

As imagens no formato AFF podem ser armazenadas em um destes 3 métodos/formatos:
  • AFF: formato padrão. Neste método, um único arquivo de imagem forense contém os dados forense (que é a imagem forense em si) e os metadados embarcados.
  • AFD: Neste método, o metadado está armazenado na imagem forense. Porém, "quebra-se" a imagem forense em tamanhos fixos.
  • AFM: Neste método a imagem é armazenada no formato raw e os metadados são armazenados em um outro arquivo.

A biblioteca AFFLIBv3 possui algumas ferramentas que permite trabalharmos com imagens no formato AFF. Algumas dessas ferramentas são:
  • affconvert: permite converter imagens em todos os formatos suportados pelo formato AFF (RAW --> AFF; AFF --> RAW; AFF-->AFF). 
  • affuse: permite que os arquivos de imagens AFF (imagens AFF) apareçam como arquivos/imagens no formato RAW. Assim, o affuse permite que as imagens de disco sejam montadas.
  • affinfo: exibe algumas informações sobre a imagem AFF
  • affxml: exibe algumas informações sobre a imagem AFF como XML



3) Criando uma Imagem Forense AFF
Já fizemos uma introdução sobre o formato AFF, agora vamos ver como criar uma imagem forense no formato AFF. 

Para criar uma imagem forense no formato AFF podemos usar o software FTK Imager. Ele permite tanto criar uma imagem física quanto uma imagem lógica. Como dissemos no post sobre imagens ewf, o FTK Imager serve tanto para criar imagens de dispositivos atachados na minha estação forense (HDs, pendrives, etc) quanto também serve para criar imagens forense de uma máquina virtual (se eu tenho uma máquina virtual qualquer e quero criar uma imagem forense desta máquina, eu posso usar o FTK Imager pra isso) (Fonte: aqui).
OBS: Vale lembrar que para se criar uma imagem forense de uma máquina virtual no VMWare (considerando que esta máquina virtual está ligada e funcionando), precisamos primeiro suspender esta máquina virtual pra depois começar o processo de criação da imagem forense.

Se alguém tiver alguma dúvida de como se criar uma imagem forense utilizando o FTK Imager, pode entrar neste link.


4) Montando Imagens AFF
Agora que já temos nossa imagem no formato AFF, vamos montá-la. É um processo simples.
Precisamos primeiro ter o diretório para o ponto de montagem. Vamos montar a imagem no formato AFF no diretório /mnt/aff. Como a SIFT vem com esse diretório criado por default, não precisamos criá-lo. O próximo passo é usar o utilitário affuse para podermos montar a imagem no formato AFF no diretório /mnt/aff. Depois de usar o affuse e montando a imagem no formato AFF, vamos ver que ele é, na verdade, um container, e que carrega lá dentro dele uma imagem no formato raw. Então, se entrarmos no diretório /mnt/aff vamos ver que existe uma imagem no formato raw lá dentro. Depois disso, podemos montar a imagem no formato raw normalmente, utilizando o comando mount.

A imagem que eu montei foi uma imagem de uma pendrive, que não tinha nada armazenado lá dentro. Por isso que depois de montada, não apareceu nenhum arquivo com o comando "ls".

No post sobre imagens ewf, comentamos sobre o parâmetro offset. Se alguém tiver alguma dúvida, pode ir lá e ver a explicação sobre este parâmetro. Naquele post também comentamos a necessidade de se desmontar a imagem depois de analisá-la. O processo de desmontagem de imagens no formato AFF é o mesmo processo de desmontagem de imagens ewf (acontece em 2 passos).


Bom, é isso.
Um abração!





Referências:



Imagens E01/EWF

Opa, e aí galera?

Tudo bem?
Hoje nós vamos falar sobre imagens EWF/E01. Mas, primeiramente, vamos falar um pouco sobre a história de como surgiu esse tipo de imagem.

1) História
Bom, em 1998, a empresa Guidance criou um software inovador que viria a ser o líder de mercado na área de forense computacional. Na época, ou seja, em 1998, este software se chamava Expert Witness. Então, uma empresa chamada ASR Data, que já detinha a marca "expert witness" registrada, entrou com um processo contra a Guidance com o intuito de proibí-la a usar a marca "expert witness". No fim das contas, a Guidance mudou a marca para EnCase. E é por isso que o formato da imagem gerada pelo software EnCase se chama EWF (Expert Witness Format).

Acontece que este formato começou a ser também chamado de E01. Isso significa que o formato EWF pode ser também chamado de E01.

2) LibEWF
Uma das primeiras coisas a se falar é que para se manipular imagens no formato ewf/e01 (ler e escrever), precisamos de uma biblioteca chamada libewf. É ela quem permite fazer leitura e escrita no formato ewf/e01.
Os formatos suportados para leitura e escrita são:
  • SMART .s01 (EWS-S01), 
  • EnCase .E01 (EWF-E01) e Ex01 (EWF2-Ex01); 

Os formatos suportados somente para leitura são:
  • LEF (Logical Evidence File), .L01 (EWF-L01) e o formato Lx01 (EWF2-Lx01)

A biblioteca libewf possui algumas ferramentas que permite trabalharmos com as imagens forense. As principais ferramentas são:
  • ewfacquire: utilitário que cria uma imagem forense de algum dispositivo. Essa imagem será no formato EWF.
  • ewfinfo: utilitário que mostra os metadados da imagem. Estes metadados foram criados no momento da criação da imagem forense.
  • ewfverify: utilitário que verifica a integridade de cada pedaço da imagem forense. 
  • ewfexport: utilitário que exporta a imagem do formato EWF para o formato RAW
Existem outros utilitários que fazem parte do pacote libewf, mas creio que estes sejam os principais.


3) Características
O formato ewf/e01 é um formato interessante. Ele permite comprimir os dados da imagem forense, Assim, quando analisamos um arquivo de imagem do tipo "raw" (criado através da ferramenta DD) e o comparamos com a sua versão no formato ewf/e01, podemos notar que a imagem no formato do encase é bem menor. Ou seja: o formato do encase permite a compressão de dados.
A imagem a seguir mostra a diferença entre a imagem no formato e01 (comprimida) e a mesma imagem em formato raw (não comprimida):

Uma outra característica interessante é que agente pode dividir a imagem forense de um HD ou de uma partição em pedaços. Cada um desses pedaços serão renomeados da seguinte forma: imagem.Exx. Portanto, se eu tenho um HD de 20 gigas, e quero ter 2 pedaços no formato ewf, os meus arquivos de imagem forense ficam desta forma: imagem.E01 e imagem .E02. Se eu quero ter 3 pedaços no formato ewf, os meus arquivos de imagem forense ficam desta forma: imagem.E01, imagem.E02 e imagem.E03. Resumindo a história é que eu posso ter múltiplos pedaços que formam a imagem forense do meu disco/partição


4) Criando uma Imagem Forense E01
Já falamos sobre a história do formato ewf/e01, já falamos sobre a libewf, já falamos sobre algumas características do formato ewf/e01; agora é mão na massa. Nós vamos falar agora sobre como criar uma imagem forense no formato ewf/e01.

Uma das formas de criar uma imagem forense no formato ewf/e01 é usando o FTK Imager. E essa opção é boa se eu tenho, por exemplo, uma máquina virtual e quero criar uma imagem forense dessa máquina virtual. Basta carregar o FTK Imager e no momento de escolher qual o alvo, eu indico o disco virtual da máquina virtual em questão. Maiores explicações sobre como realizar uma imagem forense com o FTK Imager podem entrar neste link: http://periciadigitaldf.blogspot.com.br/2012/12/criando-imagens-forense-com-ftk-imager.html

Uma outra forma de criar uma imagem forense no formato ewf/e01 é usando distribuições linux voltadas para forense computacional. Como exemplo, nós temos as distribuições Helix, Caine, SIFT, e até mesmo a Kali Linux, etc.
Neste exemplo aqui, eu vou fazer uma imagem forense de um pendrive.
OBS: Se você tiver alguma dúvida persistente, existem alguns vídeos no youtube mostrando o processo. Um exemplo de vídeo é este aqui.

Bom, vamos para o primeiro passo: eu vou atachar o pendrive no SIFT. Depois eu digito o comando "fdisk -l" para ver se o pendrive foi reconhecido. Após isso, eu já posso começar a fazer a imagem da minha pendrive. O comando é: ewfacquire (dispositivo alvo que eu quero criar a imagem). Como no meu exemplo a pendrive foi reconhecida como o dispositivo /dev/sdc, a linha de comando fica assim: ewfacquire /dev/sdc.


Pode-se notar que o utilitário pergunta algumas informações. Basta responder; é muito tranquilo. Algumas perguntas ele já até coloca a opção entre colchetes; neste caso basta apertar a tecla "enter", ele já escolhe a opção default. Antes de iniciar o processo de realizar a imagem, ele mostra um resumo com as opções que você escolheu.



Quando ele terminar todo o processo de realização da imagem forense, ele mostra o hash e informa se o processo foi realizado com sucesso


Neste momento, em que todo o processo foi realizado com sucesso, eu posso ainda usar a ferramenta ewfinfo para ver algumas informações sobre a minha imagem forense. Estas informações são os metadados que nós informamos no momento que estávamos iniciando o processo dei magem forense (com a ferramenta ewfacquire). O comando é: ewfinfo (imagem.E01). No nosso exemplo aqui, a linha de comando fica assim: ewfinfo USB.E01


Outro utilitário que também posso usar neste momento é o ewfverify. O comando é: ewfverify (imagem.E01). No nosso exemplo aqui, a linha de comando fica assim: ewfverify USB.E01


5) Montando Imagens EWF
Um fato interessante é que quando temos imagens .e01, vamos notar que depois de montá-la, vamos ver que lá dentro dela existe uma imagem RAW. Ou seja: imagens .e01 funcionam como se fosse contêineres.

Agora, vamos partir para o próximo passo: montar as imagens.
Nesse momento eu não vou usar a imagem do pendrive; eu vou usar as imagens da digital corpora. O cenário que vou usar como exemplo é o M57-Jean. São dois arquivos no formato E01; estes arquivos são o "nps-2008-jean.E01" e "nps-2008-jean.E02".
OBS 1: sempre que temos uma imagem forense no formato EWF com mais de um arquivo (.e01, .e02, .e03 ...), é preciso que todos eles estejam no mesmo diretório. No nosso exemplo aqui, é necessário ter no mesmo diretório os arquivos "nps-2008-jean.E01" e o "nps-2008-jean.E02".
OBS 2: na hora de montar, eu não preciso montar os arquivos com extensão .e02, .e03, .e04, etc. Basta montar o arquivo com extensão .e01. Então, aqui no nosso exemplo, eu só vou montar o arquivo "nps-2008-jean.e01".

Eu vou usar 2 scripts para montar imagens no formato EWF: mount_ewf.py e ewfmount. Mas por que eu vou mostrar exemplos com esses 2 scripts? Porque na hora de montar a imagem, pode ser que um dê algum tipo de problema; então nós temos a outra opção. Além dessas 2, existem outras opções de scripts para se montar uma imagem; o xmount é uma dessas opções (eu não vou mostrar o xmount nesse post).

Para montar as imagens no formato EWF, precisamos realizar 2 passos (sequencialmente):
  1. O diretório /mnt/ewf é onde vai ficar a minha imagem RAW. Então primeiro eu vou montar a imagem .e01 usando o comando mount_ewf.py (ou ewfmount)
  2. O segundo passo é rodar o comando mount em cima da imagem RAW (e vou montar a imagem RAW no diretório /mnt/windows_mount).
5.1) Montando uma imagem usando o script mount_ewf.py
No exemplo a seguir, a imagem "nps-2008-jean.e01" está no diretório /home/sansforensics/Desktop/cases/Corpora/nps-jean-2008.e01.
Então, a linha de comando fica assim:
# mount_ewf.py /home/sansforensics/Desktop/cases/Corpora/nps-jean-2008.e01 /mnt/ewf


O que chama a atenção neste último comando (comando mount) é o parâmetro offset. Este parâmetro indica o offset da partição que vamos analisar dentro do disco virtual (lembrando que esta imagem é uma imagem do HD, ou seja, uma imagem física).
Toda vez que temos uma imagem de um disco virtual (e não de uma partição), precisamos usar este parâmetro offset e indicar justamente o offset do início da partição, que neste caso o offset é o setor 63. Como os setores são de 512 bytes, basta multiplicar o offset pelo tamanho do setor (63 setores * 512 bytes por setor = 32256). Ou seja, para montar partição com o filesystem NTFS, eu preciso passar o parâmetro offset=32256.
E se ao invés de 63, estivesse aparecendo 2048? Aí bastaria fazer o seguinte: 2048 * 512, que seria igual a 1048576. Assim, o parâmetro offset=1048576. Fácil, né? :)

Para desmontar a imagem, é preciso fazer 3 coisas.
  1. Sair do diretório /mnt/ (e consequentemente sair também dos seus subdiretórios). Por exemplo, eu fui para o diretório /home/sansforensics
  2. umount /mnt/windows_mount
  3. Por fim, o comando: umount /mnt/ewf



Se eu desmontasse somente o diretório /mnt/windows_mount, o diretório /mnt/ewf ainda estaria montado. Por isso é necessário desmontar os dois diretórios.

5.2) Montando uma imagem usando o script ewfmount
Este script tem a linha de comando igual ao mount_ewf.py. A diferença entre os dois é que o script ewfmount é produto de uma atualização do outro script. Isso significa que o ewfmount é mais atual que o mount_ewf.py. Mas os dois funcionam do mesmo jeito.
A linha de comando é:
# ewfmount /home/sansforensics/Desktop/cases/Corpora/nps-jean-2008.e01 /mnt/ewf


Para Desmontar, vamos fazer do mesmo jeito que fizemos com o mout_ewf.py: desmontamos primeiro o diretório /mnt/windows_mount (umount /mnt/windows_mount) e depois desmontamos o diretório /mnt/ewf (umount /mnt/ewf)

Bom, é isso galera
Um abração!



Referências Bibliográficas: