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
