Solved - problems copying files to a Mac from PC disk

My data recovery is all done on PCs.  Often though, the original disk is a Mac HFS+ disk, and the customer wants the data back on a Mac Drive.  My process for doing this is to recover the files to a PC drive (NTFS or FAT32) which a Mac will read. By using the AppleDouble format (with hidden ._ files) all resource forks are retained.  I then copy the files, using a Mac on to a customer disk.  I could have used a program such as MacDrive, but the last version I had did not retain resouce forks.
Most files copy without problems, and the resource fork is correct, but sometimes an error such as - 
     "The operation cannot be completed because you do not have sufficient privileges for some of the items"

is displayed and the copying stops.  This is best described as a pain as the point of stopping has to be determined, and a copy restarted.  Eventually I tracked this down to the type of file and established the problem files had the file type 'slnk' or 'hlnk' in the resouce fork.  This was trying to associate the file with a program that may not present on the copying Mac.  The solution has been to remove this strings in the resouce fork and initial results now allow me to do a copy  in one stage.

Bye Bye Vista!

Doing software development it is essential that your product works on systems customers want to use.  This means keeping upto date with standard updates and a few years ago I purchased a Vista system.  It did thrown up a few compatibility problems so the purchase was worth while, but somehow the system never worked very well.  The PC was a reasonable spec, Core Duo, 2.4GHz with 2GB or RAM.

However, enough has been enough, and my Windows 7 systems seem very stable, so I decided it was time to update the Vista to Windows 7 - 32bit.  A search on Amazon brought up a reasonable price, and then a few more GBs or RAM to go to 4GB.  The fitting of RAM was easy, though of course, 32 bit Windows only sees 3GBs.

In theory, Vista can be updated to Windows and keep the system intact.  Obviously a full backup was done first, and the install was started.  At this point a problem arose.  The new Windows 7 package was less high end than the original Vista package, and this would not allow for a seamless upgrade. The notes implied that all data would be lost, and a clean install would be carried out.  The truth was actually not quiet so bad.  On starting the update, about 50GB of files were backed up to a windows.old directory, and this contained all programs and user directory.  Obviously the programs are not installed, but copies are made.  Unexpectedly, the rest of the hard drive was left unchanged, so all existing directories were left as original.  I now just need to clear down a lot of the unwanted 50GB backup.

Overall, the upgrade was very painless and after a bit of personal tweaking, I now have a nice Windows 7 machine which seems to work.

Defragmenting videos from mobile phones

Mobile / Cell phones typically store videos as .3GP, .MP4 type files.  These can be recognised easily in a hex viewer by looking at the start of the file. The second group of 4 bytes will be the string 'ftyp' followed by the exact type of file, eg '3gp5'.

If the files are to be recovered by data carving, then at times the data may be fragmented.  CnW is working on a solution to this problem.  Fortunately these Quick Time files have a fairly helpful data structure, and so it is possible to both verify, and hence reconstruct files from fragmented stored in different fragments.  The basic file struct is 3 main data areas,

    ftyp  moov  mdat

However, the order of moov and mdat can vary.  The moov segment stores all pointers and decoding details for the data area, mdat.  The mdat area basically contains frames of video and sound.  As video frames normally start with the same header string, by decoding the moov it is possible to examine a possible fragment and determine if it does have the correct headers in the correct location.  If a match is found then it is possible to apply this fragment to the new image.

The moov fragment is not normally very large and so the expectations are that the complete segment will be found in the first complete fragment, along with the ftyp header.  This will be true for the files that store moov straight after the ftyp tag.  For files which are ftype - mdat - moov sequence, it is necessary to examine the mdat for frame starts and hence calculate possible values that will be found in a moov segement.  The disk then has to be searched for a suitable moov fragment.

The current status of CnW Recovery is for recovery of a ftyp - moov - mdat file.  The second variation is under development.  http://www.cnwrecovery.com/ for more details of software

MP3 recovery

A recent job involved a corrupted MP3 player.  On plugging it into the PC it displayed as an music player, rather than as a hard drive.  A bit of reading the manual showed there were multiple modes for the USB interface to work, and once set in the appropiate mode, I could see the device as a storage device.  As expected it was a FAT32, but 6.5GB of it's 8GB capacity was in the FOUND.000 subdirectory, as the result of a chkdsk type command.

The files to be recovered were ones the customer had recorded which were no longer visible.  The first recovery attempt was a data carve of the disk and this showed a number of files, of the type required, but no file names or directories.  The second attempt was a logical read, but this only showed what was seen directly on the PC.  The third attempt was a scan of the disk for FAT directory stubs using CnW recovery software.  Interestingly this scan came up trumps.  All the files that had been lost (and captured on the chkdsk) were found with valid names and valid subdirectories.  When recovered the complete MP3 player was much as originally configured.

Overwritten MAC disk

I recently received a MAC disk for data recovery. The disk imaged without any sectors errors, and a scan of the disk indicated there was about 70GB of data. However, when I read it, only about 20MB was recovered. The fist thought is that all the daya had been deleted which is not good news for a MAC. When a MAC file is deleted, it also removes the metadata from the directory, making intelligent recovery impossible. The only recovery approach is data carving.However, looking through the disk, several files looked rather PC based, and there were also som FAT32 directory structures. A scan of the disk using the CnW Partition function showed there were about 300 FAT sub directories on the drive. This indicates that the drive was intially a FAT32 drive that had been reformatted as a MAC drive. A bit more examination also indicated that much (but not all) of the FAT was still intact.CnW was set to recognise the partition as a FAT32 and a very complete recovery was made. By examining the log (and sorting on start location) it was clear that the area that th MAC writes most directory information was one where only a few system files originally existed, and so it was likely that very few useful files were lost.Moral - when only a few files have bee found on a disk, it is always worth investigating if it has been reformattted, either to the same, or a different file system.

AVI data carving

Most data files are written sequentially which means that data carving can have a good guess that the data will typically be sequential. However, recently some AVI files have been found that do not seem to follow this pattern.

The file in question was written using a video camera and it appears that the first section was the data - a series of tagged chunks ofthe starting "00dc" or "00wb". An AVI file contains an index and in this version, the index was added to the first block after the main header information. Thus to carve the files it is necessary to read the header, and then in effect go back to find the blocks used. To make the job possible, the index does conatin the offset and length of each tag. It is therefore possinle to search the raw disk for a cluster that contains a '00xx' tag at a certain location within a block, with a defined length.

Recent developments with CnW Recovery software have added the automatic feature so that a trailier can be created if missing.  This means that even a partial fragment can be viewed.

xD Memory cards

Photo recovery from most camera memory chips is fairly straight forward. If deleted, then file can be recovered, largely with original names. Failing that, data carving can be used to extract the photos. The only remaining issue is recovering fragmented photos, something that CnW Recovery software can do with a moderate success rate.

For some xD memory chips, they can be formatted rather than deleted and the end result is every sector (after a blank directory) is full of 0xFF. ie there is absolutely no information left to recover photos from.

There are theories that if you examine each bit on the memory chip you may discover that it is only at 99% the standard level which means it was previously a different level. This would require the complete resources of the FBI, and probably only have a 25% success rate on each chip. It would be far cheaper, and more successful to pay for the holiday again.

The moral as ever is to make sure that when ever photos are taken, they should be transfered to a new source (ideally multiple locations) and verfied before deleting the camera memory. The other advice is not to delete individual photos as there can be two problems. A single mistake can delete all the photos, and also new photos can be fragmeted making future data recovery harder.

Disk drives fails on certain sectors

I received a disk drive today that often worked, but when it hit a few sectors it would fail, so the the only way forward was a power reset. My normal approach would be to do an incremental image, and restart after every failure. This disk was 1TB so an incremental image would take several hours which I did not have. By doing a partial image of the directory area, I couild determine that the required data, from a single subdirectory was stored over the complete disk.

My approach to save time was to do a selective restore of the required directory but at the same time, when a failed sector was found, change the program so that it would be skipped. The hope was that the requested data would not hit too many failed sectors, each requiring a program change and recover restart.

It will actually be a very useful feature to add to the software so that a hardware reset could be done, and recovery then continue.

Success with XFS deleted files

After a lot of hard work (and head scratching) it is now possible to recover deleted files from the problem XFS disk. This is a new development within the CnW data recovery software which will recover the file without doing any data carving. In other words, the files are recovered with correct names, original dates, and very largely, correct directory structure.

The process, by necessity is rather slow. It starts with a complete scan of the drive (or in this case, the RAID-0) to locate all existing iNode entries on the disk. These are then analysed, and regenerated to provide a list of possible directory entries. Once the disk structure is know, files can be recovered, including all files that have been deleted.

With all deleted files, there is always a danger that a new file written to the disk after the file was deleted, could overwrite critical data. However, if the recover process is started as soon as the error, or corruption is know, recovery levels will be good.

Another RAID problem

I rececently received three disks from an Apple RAID. One disk had hardware issues and the RAID was RAID 0, ie all the disks are striped so that 32K of data is written to one disk, then the next 32K to the second disk.

Within the Apple, some files could be recovered, and gthen the while system would hang.

The problem disk had a hardware issue so then when making an image of it, the drive would hang, and the only recovery path was a power cycle reset. By using incremental imaging it was possible to build up an adequate image of the drive. A few sectors had to be skipped, but probably 99.9% were imaged.

To receover the data it was necessary to emulate the Apple RAID. As is typical, the first section, actually a FAT partition was identical on all three disks, but the data section was spread over the three disks, starting at location sector 0x64028. It was necessary to work out both the stripe size and disk order. The stripe size was worked out by fortunately finding a sequential file that had line numbers marked in the text, It was therefore possible to see when there was a jump, in this case after 32K of data, and also the sequence of the disks. The sequence was slightly curious as the disks were marked 1,2,3 but the data in sector 0x6402A was on disk 2, and not disk 1. Thus the order of 2,3,1 was tried and the file system was the readable.

The result was that the CnW incremental imaging, and the RAID option recovered a very large amount of valuable data.