Re: More info on dd? -

From: Alvin Oga (alvin.secat_private-Consulting.com)
Date: Mon Oct 14 2002 - 01:28:38 PDT

  • Next message: Hauke Lampe: "Re: Time stamping securely"

    hi ya valdis
    
    On Sun, 13 Oct 2002 Valdis.Kletnieksat_private wrote:
    
    > On Fri, 11 Oct 2002 12:01:41 PDT, Alvin Oga said:
    > 
    > > -- dd also copies the entire partition  if you do
    > > 	dd if=/dev/hda1 of=/dev/hdc1
    > > 
    > > 	if the partition is 90% full or fully utilized, it makes sense
    > > 	for dd ... if on the other hand you had 10% used partitions,
    > > 	than you are wasting 90% of your time copying null from 
    > > 	the master to the slave
    > 
    > And if the file system tree says it's 10% full, but you're doing this
    > because 15 minutes ago it was 90% full of Something Evil And Bad, then
    > the very definition of "90% full" is open to discussion.
    
    think we're talking gods and fruits
    
    - if /root, /bin /sbin /lib /dev  /etc is 90% full....
      it will not arbritrarily change size...
    
    - if  /home is 90% full and shrinks to 10% full ...  you've got a problem
      no matter which partitions/directories is full
    
    -- am just saying dd is good for copying partitions that are mostly 
       full ... if the partition is 10% used... you'd be copying 90% of stuff
       that is never needed/used
    
    if youre using the hacked disks and it changed sizes on you... you're
    doomed ...
    	- you should not be booting it in the first place
    	- lots of mistakes in that case where things change..
     
    > > -- use tar to clone ...  you get a safe copy/clone of the master
    > > 	- if you need a inode-by-inode  clone of the master, than
    > > 	you have no choice but to use dd and hope that your clone
    > > 	does NOT have a bad block
    > 
    > What's good advice for backups is bad advice for forensics.  I know of
    
    yupp... backup and forensics is two different worlds
    
    > at least one person who has found a way to exploit the fact that 'tar'
    > won't even back up all the *allocated* space for a file (hint - this
    > isn't a tar issue, it's a generic filesystem issue).
    
    yup.... if one creates a file "this is a file"  in foo.txt
    
    the remaining 500 bytes of the block is left unused ... lots of
    room for hacking code to be piggy backed  and undetected
    
    > I've been at this for 20 years.  I've had to deal with recovering
    > disks that are undergoing hardware failure.  I've had to deal with doing
    > forensics on a disk.  I've *NEVER* in 2 decades heard of *anybody* who's
    > had to image a disk for forensic reasons who's gotten bit by a bad block
    > that hadn't been clearly signaled by "disk read error" or whatever messages
    > before the incident.
    > 
    > If you're having to forensics-image a bad disk, it's likely that BOTH
    > problems are because the sysadmin was WAY asleep at the wheel.  At that
    > point, all I can say is "Good Luck, you'll need it..."
    > 
    > And if you're imaging to a clone disk that you haven't even done the
    > equivalent of "dd if=/dev/zero of=/dev/hdb" to check it's writable first,
    > then good luck, you'll need it....
    
    i do NOT know anybody that does a bad-block check on tehir disks
    before they use it
    	- its just buy it at the local pc store
    	- isntall it...
    	- parition it... format it fast... and see what happens
    
    -- there is enough postings/questions from newbies when /dev/hda is
       smaller sized than the new clone /dev/hdb ... 
    	and vice versa...
    
    	dd is good ... if you know what you're doing and why and 
    	all the hidden assumptions about raw write vs block writes
    
    c ya
    alvin
    
    
    -----------------------------------------------------------------
    This list is provided by the SecurityFocus ARIS analyzer service.
    For more information on this free incident handling, management 
    and tracking system please see: http://aris.securityfocus.com
    



    This archive was generated by hypermail 2b30 : Mon Oct 14 2002 - 04:55:57 PDT