Re: Where are greater risks?

From: Michael H. Warfield (mhwat_private)
Date: Tue Jun 26 2001 - 10:39:13 PDT

  • Next message: dan mares: "Maresware training"

    On Tue, Jun 26, 2001 at 11:42:44AM -0400, dave.goldsmithat_private wrote:
    > When you use the dd command to copy the source disk, does the destination
    > disk need to be the same size/geometry or just as large or larger.
    
    > If it is larger, how do the MD5 checksums end up being the same? Wouldn't
    > there be additional data bits (in the remaining space) that would cause the
    > hash to change?
    
    	What I would generally do is dd from a raw disk to a disk image on
    a target file system.  That allows me easier access for post recovery
    analysis.
    
    	This is also how I rapidly rebuild my honey pots.  I have a CD
    with the BBC as a front end and my disk partitions as compressed files
    as payloads on the rest of the CD.  I boot the target system from the
    CD and restore the entire drive by gunziping the images into dd and
    onto the raw drive.  It's bit for bit identical to when I made the
    images.  It don't get much better than that.
    
    	If I wanted, for some reason, to dd to another raw disk, I
    would have to make sure the geometry was the same (or the partition tables
    would not work) and that the drive was as large or larger than the source
    drive.  To match the md5 sums with a large target drive, you would then
    have to use dd to extract the correct number of blocks (determined by
    the block count when the original dd was finished) and pipe it to stdout
    and from there to stdin on md5sum.
    
    > Dave Goldsmith
    > 
    > -----Original Message-----
    > From: Michael H. Warfield [mailto:mhwat_private]
    > Sent: Monday, June 25, 2001 5:18 PM
    > To: mail@computer-security-awareness.co.uk
    > Cc: svetlikat_private; forensicsat_private
    > Subject: Re: Where are greater risks?
    > 
    > 
    > On Mon, Jun 25, 2001 at 04:04:45PM +0100, Michael D. Barwise, BSc, IEng,
    > MIIE wrote:
    > > My ideal disk copier would be a very basic PC, probably one of those 
    > > compact industrial single-board ones, with a truly blank target disk and a
    > 
    > > spare port, running nothing except a custom-written native application 
    > > which does nothing except read literal sectors from one hard disk to 
    > > another (no OS). This application would be booted from floppy disk to
    > start 
    > > the copy process. The required code, if written in assembler, would be so 
    > > small that it *could* be verified and certified by anyone competent to
    > read 
    > > the source code.
    > 
    > > The reason we don't use disk imaging software is probably that we don't 
    > > know and can't find out what it is doing in detail (that's proprietary 
    > > information). Many disk imagers compress their archives in an unspecified 
    > > manner, and many use file-level copying, which both alters the layout of
    > the 
    > > copy and omits free and deleted space, losing a useful source of evidence.
    > 
    > 	Boot the system from a Linux "Bootable Business Card" CD and
    > use the "dd" application to copy between the raw devices (root device
    > like /dev/hda or /dev/sda, not partitions like /dev/hda[1234567]).  It
    > doesn't get much more basic than that unless you want to do magnetic domain
    > analysis or include the low level drive sync patterns (I think not).
    > When done, use md5 on both the source and the destination to verify.  Since
    > it's all open source, you've got the sources to audit and verfy to your
    > heart's content.  Since it's done on the raw devices, all the deleted
    > space, trailing space, sparce files, and inter-partition gaps and tables
    > are all preserved bit for bit.  If they weren't your md5 sums would fail.
    > 
    > > Mike Barwise
    > > Computer Security Awareness
    > 
    > > "Addressing the Human Equation in Information Security"
    > > > 
    > > > >Thanks Marian
    > > > >
    > > > >At last someone is asking the right questions.
    > > > >
    > > > >My view is that one should ideally *never* try to carry out a disk
    > > > >imaging
    > > > in
    > > > >place on a suspect computer.
    > > > 
    > > > Yes, you are right, but you know it is not possible in many cases.
    > > > 
    > > > >I would go equipped with a dedicated clean
    > > > >"imager" PC onto which the suspect drive can be connected. This need be
    > > > >no more than a simple PC with a spare IDE (and possibly a spare SCSI)
    > > > >port and a power cable splitter. As it would never be used for anything
    > > > other
    > > > >than imaging, it could be kept clean and certified.
    > > > 
    > > > This is the right place for the next "right" question:
    > > > 
    > > > What is the "clean and certified" computer?
    > > > 
    > > > Computer is allways "sophistical" machine and each program, driver,
    > > > system,...
    > > > must be cerified to clearly state that all computer is cerified.
    > > > Certification in forensic science is not only technical,
    > > > but the juridical proces. I have some (not pleasant) experience with
    > > > certification ;-(
    > > > The best way for success cetification (no matter what certificaction
    > > > criteria you have)
    > > > is to certificate as simple device as possible. For this reason I have
    > > > next (may be) "right" question:
    > > > 
    > > > Why a HW disk imaging tools (HW disk duplicators) are not used?
    > > > 
    > > > They have all advantages (except price ;-).
    > > > Simplicity, speed, safety, electronic signature, they need not so high
    > > > qualify oeration and handling...
    > > > 
    > > > >
    > > > >Michael D. Barwise, BSc, IEng, MIIE
    > > > >Computer Security Awareness
    > > > >tel +44 (0)1442 266534
    > > > >http://www.ComputerSecurityAwareness.com
    > > > >
    > > > >Addressing the Human Equation in Information Security
    > > > 
    > > > ____________________________________
    > > > Marian Svetlik
    > > > Principal Consultant
    > > > 
    > > > Risk Analysis Consultants
    > > > Narodni 9,      110 00 Praha 1
    > > > Czech Republic
    > > > 
    > > > Tel.:   +420 2 220 75 352    Fax:    +420 2 242 28 273
    > > > mail:   svetlikat_private           http://www.rac.cz
    > > 
    > 
    > -- 
    >  Michael H. Warfield    |  (770) 985-6132   |  mhwat_private
    >   (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
    >   NIC whois:  MHW9      |  An optimist believes we live in the best of all
    >  PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
    
    -- 
     Michael H. Warfield    |  (770) 985-6132   |  mhwat_private
      (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
      NIC whois:  MHW9      |  An optimist believes we live in the best of all
     PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
    
    
    -----------------------------------------------------------------
    
    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 : Tue Jun 26 2001 - 16:50:11 PDT