catastrophic failure (CCTV Drive)

[Larry Pham]

Hi Jay,

My understanding of low level hardware is limited so I appreciate the 
pointers and advice you have given me.
Trust me, I totally realize what kind of mistake I have made and the 
fact that the police are waiting on me to get them the videos has 
contributed to this realization :(

I'm completely drained so I'm off to bed and hopefully I can rethink my 
approach in the morning with the wonderful info you have given me.

Cheers,

Larry 

Jay Vaughan wrote:
>> One of the first things I tried was making a backup of the drive in  
>> case these recovery programs messed it up even further. However  
>> that was when I knew I was in trouble since no platforms were even  
>> able to to detect it to even mount the drive.
>>
>> I've tried a bunch of linux distros for data forensics and I can't  
>> even get the drive to detect so I can't moun it and so i have not  
>> been able to even back it up.
>>
>>     
>
>
>
> okay, you know the difference between the device being detected by  
> your system, and the device being *mounted* by your system, right?
>
> in linux, when you hook up a drive, it will only auto-mount if your  
> system is configured to do so, *and* if it knows the filesystem  
> format of the drive by reading a few key bits of data from the drive  
> (which in your case are now irretrievably lost since you  
> 'initialized' it), *and* if there is a filesystem driver that allows  
> the filesystem to be recognized in the context of the linux kernel.   
> other than that, you should still get a raw device node in /dev  
> somewhere that points to the physical device itself - it is from this  
> raw device (.e.g /dev/sda) that you can do a raw sector copy in order  
> to back it up.  mounting has nothing to do with it: and in fact,  
> there is evidence that the original disk used a highly proprietary  
> filesystem format in the first place, so it wouldn't necessarily have  
> been mountable anyway.  hint: there are about 30 different filesystem  
> types out there in la-la-land, and only a handful of them are  
> consumer-grade and thus 'normal' for your average PC user.  there are  
> tons, and tons, of proprietary filesystem formats out there, too ..
>
> mounting is the *last* stage in a device enumeration effort under  
> linux.  there are a couple other stages before that, which you might  
> be misinterpreting if you're not familiar with it.  as 'root  
> user' (either by sudo or whatever), do an fdisk -l on your system  
> *before* you plug the drive in, then do it again afterwards, and note  
> the difference.  if in fact your system is recognizing the new device  
> as a storage device on your IDE (is it IDE?  SCSI?) bus, then you  
> will see a new devnode added to /dev that indicates this fact.  only  
> when this node is available will you be able to mount the filesystem  
> - and only *then* if there is a filesystem driver for the particular  
> filesystem thats physically on your disk.  but you do not have this  
> luxury any more, since you have initialized the drive and overwritten  
> the filesystem entry table (or partition map, or boot block, or ..  
> depending on what the actual real original filesystem was all about).
>
> you still have a chance, if your system detects the drive as a  
> storage device, to do a raw block copy to a locally mounted  
> filesystem and make a backup upon which to do a recovery effort.  but  
> i must stress: do not do this if you do not know the difference  
> between device enumeration and /dev availability, and *mounting a  
> filesystem*.  very different things.  train yourself on this before  
> you go any further, and definitely *DoubleCheck* what you are doing  
> if you get as far with this that you are at the point of being about  
> to do a 'dd if=/dev/sdc of=/home/me/mybackupofbaddisk.dd bs=1024'  
> sort of command, to build a disk image to operate on ..
>
> btw, in case you don't know this about me, i've been a filesystems  
> guy since 1985.  i once recovered a 640meg database that was worth  
> millions before it was corrupted by an idiot system administrator  
> doing something very similar to what you've done, but it took me  
> weeks and i had to write custom filesystem code to extract things out  
> of it.  i did the same thing for the Yamaha SFS filesystem being used  
> in various of their products (disky), and i've had far too many burnt  
> fingers from this experience: i've been in the position you're in.   
> i'm quite willing to help you understand just how much of a mess you  
> are in, and give you clues how to get out of it ; but you must listen  
> to this bit of hard-won advice: be very, very careful, in making  
> assumptions about your understanding of whats going on.  you got into  
> a mess with such assumptions already.  you should be questioning  
> yourself more than you are questioning the system in front of you;  
> only with such an attitude can you make progress.
>
> the one glimmer of hope that you have, beyond all other problems, is  
> that when you initialized the drive (horribly) it probably only  
> overwrote a couple of blocks worth of data - 4 at the maximum  
> (1024bytes per block, or 512, depending on your drive geometry),  
> which means that there are all the old blocks, with the old data,  
> still on the disk - just inaccessible to you, because the drive has  
> had its maps reset.  if you can get the /dev node entry, and do a raw  
> block copy, you may still be able to extract *some* info from the  
> disk image .. but this is a really long process, and you will have to  
> write code - or hire me, or someone like me - to do the grunt work. ;)
>
> ;
> --
> Jay Vaughan
>
>
>
>
> _______________________________________________
> Shelter mailing list
> Shelter at lists.music-bar.org
> http://lists.music-bar.org/listinfo.cgi/shelter-music-bar.org
>
>
>