• Please review our updated Terms and Rules here

1 plus 1 DOES NOT equal 2. well not using dc3dd in Linux to image 2 XP hd's onto 1 hd

inotarobot

Veteran Member
Joined
Feb 7, 2014
Messages
1,090
Location
Melbourne, Australia
1 plus 1 DOES NOT equal 2.

well not using dc3dd in Linux to image two XP loaded 1TB hard drives (not raided) onto a single 2TB hard Drive

Let me explain, and I hope someone can tell me what I did wrong.
*actually think I came to realize why by time i wrote this full post*

Task I got asked to make an image backup of pair of hard drives in an old machine running only XP.

Some background:

around 4 years ago the original C: 500GB hd was replaced with new Seagate ST31000528AS 1TB drive.
and about 3 years ago the original D: 250GB hd was replaced with a new Western Digital WD10EVDS-63N581 1TB drive.

6 Days ago the old Win XP machine failed into a reboot loop after the owner had downloaded and installed a new fandangled program to read some old floppy disks.

Reading online various posts and what a pain this error could be to fix, it was decided to back up the HD before attempting the repair to registry and config files.

Using my schoolboy arithmetic I decided that it was easy and price effective to buy one 2TB Hd and image both 1TB to it.

So I go and get a brand new Seagate Barracuda 2TB ST2000M008 with a DOM 28th MARCH 2020. Nice 3.5" SATA drive


{{FIY As I am doing a low lever Cyber course I decided for practice to use dc3dd under Karli Linux Live USB boot in the Forensic mode.
I have a Pentium Dual-core E6300 2.8G set up in an older tower box with a inboard 685watt PSU connected to an external UPS for copying and or transferring data etc, that has SATA hot-swap cradle, IDE & SCSI plugin cradles, 1x 5.25" & 1x 3.5" Floppy drives.}}

so installed the new 2TB drive and the original C: 1TB drive in box and powered up USB Karli Linux in Forensic mode. Both drives recognized.

Then started copy process as follows

fdisk -l {to find drives} {1TB was sdb and 2TB was sda}

dc3dd if=/dev/sdb hof=dev/sda hash=sha512 verb=on

{I could have added to end of string} log=usb3_evidence.log {log=> Path of the log file of the process}

i choose hof verses of so I can watch the copy process real time. I gather I could use hof and log.

Now all went fine with image copy. Original HD had 3 bad sectors that got replaced with all ZERO's on the image.

By now its 10.02 and bed called. BTW the 1TB forensic imaging took from 16.44:29 till 22:02:46 thats a little over 5 hrs. you can see details in my last pic here

so next day I replaced the original 1TB C: drive for the 1TB D: and repeated the process

fdisk -l {to find drives} {1TB was sdb and 2TB was sda1 and sda2}

dc3dd if=/dev/sdb hof=dev/sda2 hash=sha512 verb=on

about 4.8hrs later the process completes with an error not enough space on target hd. It was 1am and I was that tired I just turned system off, forgetting to take pics. If I recall it was saying something like target disk was about 9000 sectors short in capacity.


NEXT time I am going to use the log command as well and get all on in a log file.

If it does not take as long I would delete all on the 2TB drive and repeat the process just to get some logged data to be able to analysis what happened.

If I had spare cash I also go and buy another 2TB Seagate Barracuda ST2000DM008 just to see if its totally empty when I started.

dc3dd should be doing lowish level sector copy as it starts writing sector 1 of the target disk anyways. However looking at 2TB drive with fdisk -l (per the photo below ) i note dc3dd had made the image start at sector 63 and this raised the error
Partition1 does not start on a physical sector boundary
mmm me wonders why?



As I was writing this post I thought I can get info on drives so ran Linux with all 3 drive installed and using fdisk cmd got the following:-

Seagate ST31000528AS 1TB drive as having - 1,000,203,804,160 bytes
Western Digital WD10EVDS-63N581 1TB drive 1,000,203,804,160 bytes
-------------------------------------> thus sum 2,000,407,680,320 bytes

Seagate Barracuda 2TB ST2000M008 2TBbrive 2,000,397,852,160 bytes

that leaves the 2TB drive short by 9,756,160 bytes capacity. So this appears to be why 1+1 is greater than 2

Having just mentioned this to Maria, she said David your such a dummy :stupid: at times, as many people have know this fact for 1000's of years, as often 1+1 = 3 or more

dWRrp3E.jpg


DQ0TM1R.jpg


Sk3Ilkh.jpg
 
Last edited:
This reminds me of the time a friend asked me for help after a Sun Enterprise server at his office threw a disk in in its RAID and he couldn't get it to rebuild after putting in another expensive "36 Gig" SCSI hard disk. Long story short, the drives that were in the raid were something like a couple hundred K (seriously, it was *really close*) larger than the replacement disk, which was a newer revision of the same brand drive, and whoever had created the RAID container had used 100% of the capacity so a smaller disk wouldn't do. I had access to some similar size SCSI hard drives at my office from different manufacturers so I went through them to see how big they were, and it turned out that the dead drive was bigger than any of them.

Fun times.
 
Is this thread just a long way of saying 1TB or 2TB on a disk drive label does not mean any particular number of user visible sectors?

From some Seagate manuals online:
ST31000528AS 1,953,525,168 Guaranteed sectors (1,000,204,886,016‬ bytes)
ST2000DM008 3,907,029,168 Guaranteed sectors (2,000,398,934,016‬ bytes)

1,953,525,168 * 2 = 3,907,050,336‬ sectors (2,000,409,772,032‬ bytes)
 
I can only assume that this exercise was for either copying a drive from a RAID setup or Windows. There are more efficient ways to copy over a Linux system.
 
You trust stuff developed by the DoD? Why not plain old dd?

Well, Chuck to be straight with you I actually trust Mulder & Scully much more than DoD.

Correct me if I am wrong please, it is my understanding the gent and lady inside DoD, stated it of their own volition as they saw a need and that they coded dc3dd as a patched dd specifically for advanced forensic tests. I and the greater majority of Cyber Security Professionals trust Karli Linux for Cyber researching and the fact they include dc3dd in their release adds credence to it being a stable non-invasive tool.

per https://tools.kali.org/forensics/dc3dd

dc3dd is a patched version of GNU dd with added features for computer forensics:

on the fly hashing (md5, sha-1, sha-256, and sha-512)
possibility to write errors to a file
group errors in the error log
pattern wiping
progress report
possibility to split output
 
Last edited:
I know what it is--I spent more than 10 years in that racket. What DoD (and the Bureau) want is something that's cheap and non-proprietary.
 
Is this thread just a long way of saying 1TB or 2TB on a disk drive label does not mean any particular number of user visible sectors?

From some Seagate manuals online:
ST31000528AS 1,953,525,168 Guaranteed sectors (1,000,204,886,016‬ bytes)
ST2000DM008 3,907,029,168 Guaranteed sectors (2,000,398,934,016‬ bytes)

1,953,525,168 * 2 = 3,907,050,336‬ sectors (2,000,409,772,032‬ bytes)

Gslick your correct in that it was a long way to say what you have just written.

The point you make about looking up online manuals to see data as you show is a GOOD point, that under non pressured situation one would do.

The only downside was in my case I had no way of knowing what brand and what exact model the 2TB drive was until I got to the wholesaler I purchased it from.

With the current issues of Covid-19 limiting movement and number of people in a shop, this my nearest Computer parts wholesaler had

1. limited staff serving,
2. time constraint to be at the serving counter,
3. no online detailed data of their products so you had to ask to be shown item. In pre Covid-19 times I often asked for the various model/brands they stocked and they would bring them out and you could "stand to the side" and Google the info to aid in choosing.

Thus it was not possible to get guaranteed sector detail in advance for this purchase of the 2TB drive.

Also, I had a 3min window to decide as also they had reduced their opening hours and I arrived just as they were closing. Sigh Had I not got the one I got, it would have been a wasted 2hr round trip journey for me; that I would have had to repeat the next day.

I wrote the thread as long and in as much detail as I did, more for the newer folk to upgrading Hard Drives in Computing.
 
Last edited:
This reminds me of the time a friend asked me for help after a Sun Enterprise server at his office threw a disk in in its RAID and he couldn't get it to rebuild after putting in another expensive "36 Gig" SCSI hard disk. Long story short, the drives that were in the raid were something like a couple hundred K (seriously, it was *really close*) larger than the replacement disk, which was a newer revision of the same brand drive, and whoever had created the RAID container had used 100% of the capacity so a smaller disk wouldn't do. I had access to some similar size SCSI hard drives at my office from different manufacturers so I went through them to see how big they were, and it turned out that the dead drive was bigger than any of them.

Fun times.

been a problem for years getting a replacement for many objects of technology that is FORM,FIT & FUNCTION compatible.

thanks for sharing your story. So what ended up happening with your friends system?
 
thanks for sharing your story. So what ended up happening with your friends system?

The easy fix would have been to buy the next size up drive, but server-grade SCA drives that large cost and arm and two legs at the time and his company was having... cash-flow issues. So I volunteered to stay up late and help them build up a rotgut Linux computer with a RAID of IDE drives (a trip to Fry's and about $40 bought the necessary secondary PCI controllers to hang the drives off of) which we then copied the contents of the Sun box to so we could resize the RAID container.

Ever since that adventure I made a point of pro-rating RAID containers to about 98% of the size of the drives when I set them up so there'd be a better chance that a disk labeled as a particular size would work as a replacement. I don't suppose that's so much of an issue anymore now that OSes are much better about letting you resize file systems, but there's still something to be said about not having to perform a resize operation on a degraded RAID.
 
Back
Top