Stewart
"I should 'reconstitute'
them back on to another drive in another computer so I can boot from
System Rescue and attempt to recover files"
That is certainly one option however I am not sure how much mileage you'll get
from doing it that way, as you will have overwritten at least part of the MFT
when you did the format. I would work from the images you have created in this
scenario.
The first thing you want to do is grab an image of the whole device. "dd" is
fine for this although as you have found out it does not give you any progress
status and leaves you a bit in the dark as to how things are going. I would
recommend "dcfldd" which is a variant of "dd" which lets you monitor the
progress of the imaging phase. If you are on "Mint" you should be able to get
it by running:
sudo apt-get install dcfldd
Then grab the image using:
dd if=/dev/<source> of=/mnt/<target>/image.raw bs=512 conv=noerror,sync,notrunc
This will copy each bit from the source (your broken drive) to your target
(your new external hdd) in blocks of 512 bytes. The end string deals with bad
sectors and the alignment of sectors on the image. "notrunc" simply makes sure
that the image finishes cleanly and doesn't end up truncated (because you are
invariably imaging to a larger volume than the original).
Once you have the first image it is always worth creating backup copy of it in
case something goes badly wrong during your recovery attempts.
From this point you then either work with the raw data of the whole disk image
or mount individual partitions in order to see what you have got left. Using
"dcfldd" you create images of the various partitions in the same way as the
disk which is useful as they will vary in size and you can eliminate some of
the smaller partitions from your search as the processes you run on them will
be completed much faster than on the larger volumes.
Once you have the image. it would be useful if at some stage you could install
"sleuthkit":
sudo apt-get install sleuthkit
and then post the results of running:
mmls image.raw
If you don't fancy giving the commandline imaging tools a go there is a very
good (free (as in beer)) graphical imager known as "FTK Imager". You should be
able to download it from the "Access Data" who are the developers. This tool
only runs on Windows though.
Regards
Stu
________________________________
From: Stewart Robertson <stewar...@aliencamel.com>
To: Peterborough LUG - No commercial posts <peterboro@mailman.lug.org.uk>
Sent: Sun, 20 December, 2009 21:14:03
Subject: Re: [Peterboro] NTFS formatted as ext3
Thanks Stuart.
You're definitely right about the whole learning curve thing - dare I
call it a blessing in disguise?
Sorry for checking the obvious (I'm doing that a lot now after causing
this mess by typing sda1 instead of sdb1!) but are you saying that once
I have all the 3.5GB image parts created by dd (it has been going for
two hours now and is still trudging through) I should 'reconstitute'
them back on to another drive in another computer so I can boot from
System Rescue and attempt to recover files.
I just want to check in case there is a way of working on the image
without having to find a spare computer with a spare HD of equal or
greater capacity.
Stewart
P.S. It also sounds like I need to hope she has defragmented the drive
recently because if things like photos (3MB) are spread out they will
be corrupted because the MFT entry is likely to be missing.
Stuart Bird wrote:
>
>Hi Stewart
>
>>You appear to be on the right track and should continue to concentrate
>on getting a copy of the whole drive before attempting any sort of
>recovery processes. The first rule of forensics is never work on the
>original data unless absolutely necessary.
>
>>As you have formatted an NTFS file system with EXT3 you will have done
>some damage and will have undoubtedly lost some files however there
>should be plenty left on the disk for you to have a go at once you have
>a copy. The NTFS file system is very different to the various FAT
>variants. FAT stores its file data in a table (called the FAT table
>surprisingly) while NTFS uses a database like file called the Master
>File Table (MFT).
>
>>For simplicity a FAT table stores its data in a series of containers.
>Each container holds information regarding the location of a file or
>part of a file on the file system. When a file is stored in a FAT
>system each container is used to register the location of a clusters
>worth of data so you end up with a chain of containers which all
>contain part of the address of a file. Obviously if you remove just one
>of the links in the chain the file becomes corrupt because the whole of
>the file cannot be reconstructed and presented to the user.
>
>>NTFS on the other hand uses a database like Master File Table which by
>default occupies 12.5% of the available disk space. An MFT can grow
>during use but it will never shrink. The MFT is treated as a file in
>it's own right by the file system. The MFT is made up of a series of
>blocks of data, each 1024 bytes in size. These blocks work in two ways,
>resident and non resident data. Resident data is that which is less
>than 1024 byres in size and will basically fit in an MFT block. So a
>small text file of say 40KiB will actually be written into the MFT
>block. Non resident data is files larger than 1024 bytes. In this case
>the MFT entry will contain co-ordinates, in the form of data runs, to
>the various parts of the file in question. Each MFT block contains lots
>of data about the file it relates in the form of attributes such as MAC
>times, length, deleted or not markers etc etc
>
>>As I said, the main thing for now is to get a copy (forensic image) of
>the disk in question. Once you have that, copy it again so that you
>never have to re-visit the original and put the original data at risk.
>The next thing would be to do a bit of research on the file systems
>that you are dealing with. Both NTFS and EXT3 have been several
>versions and each version will have one or two subtle differences from
>the previous incarnation. Knowedge is power so read, read and then read
>a bit more if you have to.
>
>>Once you have achieved the above you can then confidently start having
>a look around the file system to see what you have left. You can use
>"dd" and "xxd" for a quick and dirty look at the raw data:
>
>>dd if=/dev/sd? bs=512 skip=63 count=1 | xxd
>
>>will get you a look at the boot sector (62 sectors in (counting from 0)
>and read one sector)
>
>>Play about with the "skip" and "count" numbers to have a mooch round
>the device. Try and get a feel for where recoverable data may be
>located. Pipe a few sectors through "strings". You might surprised what
>it turns up. Once you find something that looks like a file then read a
>bit more and see of you can carve it out in readable format.
>
>>There are serveral tools available under Linux for this type or work.
>The main one is called "sleuthkit" which is command line however it
>comes with a seperate browser based GUI called "Autopsy". There are
>lots of other: afflib, libewf, photorec, scalpel, formost, hashdeep,
>pasco, rifiuti and so on...
>
>>What you are attempting is not easy, and you will need to do a lot of
>reading and testing, and trying and failing during your adventures. You
>will probably recover a lot of useful data and you will certainly have
>a greater knowledge of the various file systems and forensic processes
>by the time you have satisified yourself that there is nothing else
>useful to be had from the disk.
>
>>Good luck, keep us posted on how you progress.
>
>>Regards
>
>>Stuart
>
>
_______________________________________________
Peterboro mailing list
Peterboro@mailman.lug.org.uk
https://mailman.lug.org.uk/mailman/listinfo/peterboro
