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 ________________________________ From: Stewart Robertson <stewar...@aliencamel.com> To: Peterborough LUG - No commercial posts <peterboro@mailman.lug.org.uk> Sent: Sun, 20 December, 2009 18:40:34 Subject: Re: [Peterboro] NTFS formatted as ext3 Have just found this information at the following address. Has anyone else tried it or can confirm it as an effective method? http://www.softpanorama.org/Tools/dd.shtml Getting around file size limitations using split When making images, it's quite easy to run up against various file size limitations. One way to work around a given file size limitation is to use the split command. # dd if=/dev/hda1 | gzip -c | split -b 2000m - /mnt/hdc1/backup.img.gz. 1. This example is using dd to take an image of the first partition on the first harddrive. 2. The results are passed through to gzip for compression * The -c option switch is used to output the result to stdout. 3. The compressed image is then piped to the split tool * The -b 2000m switch tells split how big to make the individual files. You can use k and m to tell switch kilobytes and megabytes (this option uses bytes by default). * The - option tells split to read from stdin. Otherwise, split would interpret the /mnt/hdc1... as the file to be split. * The /mnt/hdc1... is the prefix for the created files. Split will create files named backup.img.gz.aa, backup.img.gz.ab, etc. To restore the multi-file backup, do the following: # cat /mnt/hdc1/backup.img.gz.* | gzip -dc | dd of=/dev/hda1 1. Cat recombines contents of the compressed and split image files to stdout, in order. 2. Results are piped through gzip for decompression. 3. And are then written to the first partition of the hard drive with dd. Stewart Robertson wrote: > >Thanks for the analogy Richard. > >>Thankfully I was using a Live CD so in theory no robots managed to get >to the town and start re-building while thinking it was available space >which is why I have my fingers and toes crossed. I am however >beginning to accept that the phonebook is long gone. > >>I purchased a 1TB external HD and mounted it while using System Rescue >CD but it would only mount read only because it was formatted as NTFS. >I connected it up to Linux Mint and used GParted to format it as FAT 32 >then remounted it on the laptop. > >>I want to create an image of the drive in case I cause further damage >so have been using dd but it keeps falling over at 4.3GB and reporting >'File too large'. > >>Various searches suggest that dd can be used to image whole drives but >some places suggest there is a file size limit for FAT32. If I >reformat the external as ext3 it should handle the larger file size but >can I then use it to store any files found by photorec before >transferring them back on to Windows (i.e. can Windows mount an ext3 >formatted drive and access files on it)? > >>Stewart > >
_______________________________________________ Peterboro mailing list Peterboro@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/peterboro
