This is a free and open peer to peer medium for digital and computer forensics professionals and students. Please help us maintain it by contributing and perhaps linking to us from your own website.
Posted: Mon Jan 04, 2010 3:15 pm Post subject: Usb Hard drive to file share with DD? good idea?
Hello... I'm new to this, so I'll let you know what I tried, and maybe someone can tell me where I went wrong or if there is a better way. I'm fairly new to linux.
I'm trying to rescue files from a 500 Gb Usb drive. I'm not sure happened, but the hard drive is now blank. Here is what I tried to do to fix it (again I'm learning as I go):
I have one Pc with Windows Home Server (basically a stripped down version of Windows Server 2003) and a file share open (1 Tb harddrive is installed.) What I tried is to boot from a Knoppix disk on another Pc with the Usb hard drive attached. Then I used smbmount to mount the Windows file share. Then I ran dd like this: dd if=/dev/sdb1 of=/mountedHomeServer/image.dd After a while dd errored out: "File too large 4194304+0 records in 4194303+1 records out ... (2.1 GB copied), ... 1.2 MB/s"
Any idea why it errored out? Is the size limit a function of dd? Is there a way to make dd split the image into smaller files?
I know this is a lot of questions... also the 1.2 MB/s seems really slow, is there a way to speed dd up?
Or am I going about this in the wrong way entirely?
Fyi, my intent if it had worked out was going to be using foremost to try and search for my files.
Posted: Mon Jan 04, 2010 6:03 pm Post subject: Re: Usb Hard drive to file share with DD? good idea?
pbass wrote:
I have one Pc with Windows Home Server (basically a stripped down version of Windows Server 2003) and a file share open (1 Tb harddrive is installed.) What I tried is to boot from a Knoppix disk on another Pc with the Usb hard drive attached. Then I used smbmount to mount the Windows file share. Then I ran dd like this: dd if=/dev/sdb1 of=/mountedHomeServer/image.dd After a while dd errored out: "File too large 4194304+0 records in 4194303+1 records out ... (2.1 GB copied), ... 1.2 MB/s"
You may have run into some size limit with the file system on the target drive. You may also have found a limitation or a bug in the SMB server or client you are using. It's usually best to avoid brinkmanship, so you want to split the files before you get even close to half the nominal file size. (If max file size is 4Gb, you try to avoid getting over 2Gb in situations where you haven't tested the components to work OK.)
dd is not good at this thing -- you need to manually do something on the line of
and so on, skipping past the parts you have already imaged, and then copying some suitable number of bytes from there on. (Note 1000 is used for illustration, not because it is the right number. You need to figure out what file size you are going for, how many blocks you need to count for that, and do all the arithmetics yourself.) Or try to use dcfldd or similar that does it for you.
Quote:
... also the 1.2 MB/s seems really slow, is there a way to speed dd up?
You could try setting bs to something larger than default 512. (i.e. bs=10240, say) It's not likely to be a major improvement in your case, though. In the setup you describe, the main bottlenecks are likely to be the SMB connection and perhaps also the USB connection.
Try a few different bs-settings and see how long it takes to image 10 megabytes or so -- you'll soon see if it makes any difference. (Remember - bs says how large blocks dd works with, and count and skip says how many blocks. You don't work with bytes here -- you have to adjust to blocks.)
If you want speed when you image hard drives, you try to go from HDD interface to HDD interface (e.g.. SATA to SATA) with as little as possible in between.
Otherwise, you find something useful to do while the inage is running.
Last edited by athulin on Tue Jan 05, 2010 5:34 am; edited 1 time in total
Is there a better solution than dd for what I am trying to do? I have used Ghost in the past, but as the drive appears to be erased, I'm afraid Ghost wont create the most accurate image.
I've been looking at various forensics cd's, ala Helix, Caine, Spada, so if there is a better solution I'm game (again very new to this.)
I guess the goal would be 1. an image format compatible with foremost and 2. it would be great if one way or another, I could save it to a fileserver
Is there a better solution than dd for what I am trying to do?
Not sure -- I do mainly forensics, and data recovery as such is not something I do often. The imaging step should fit how you plan to work with the image, but if you have no plan ....
Personally, I would have use LinEn or FTK Imager Light, which produce split image files, and then used EnCase to either recover files from, or to create a drive copy. But then that's my toolkit.
If I didn't have anything, I would take an image (as you are doing), and then restore it to a second drive, or 'soft'-mount it in a tool like Mount Image Pro in Windows or the loopback mounts in Unix to investigate what the damage is: is just the partition table gone, or have file systems in partitions been damaged as well?
Quote:
I have used Ghost in the past, but as the drive appears to be erased, I'm afraid Ghost wont create the most accurate image.
If I recall, there are ways of doing full sector images with Ghost, but they are not enabled by default. If you feel comfortable with Ghost, by all means use it. I'd expect that the only thing you can do with a Ghost image is to restore it to a new (real or virtual) drive. You just have to ensure that that drive can be worked on with the tools you want to use.
Quote:
I guess the goal would be 1. an image format compatible with foremost and 2. it would be great if one way or another, I could save it to a fileserver
Foremost is for data carving. You could use it in this case, but if you have any traces of the partitions and file systems left, it's probably more efficient to do a recovery based on those.
I would begin by checking the partition table on the copy drive (after imaging the original, and creating a copy drive). If that has been damaged in any way, the disk will appear empty. If you know how the drive was formatted, or if you can locate the file system, you should be able to recreate it (in the copy), and then, as long as the file system itself hasn't been damaged, the files will pop back into existence.
For example, if the drive held one single partition covering the entire drive, it may be as easy as running fdisk or equivalent partitioning tool, and accepting default settings, based on the physical size. (Note: if you restore your image on a drive of a larger size, you have to work with the original disk size, not the copy disk size)
If the drive contained multiple partitions, that would probably get you the starting point of the first partition -- then you would have to manually edit the partition table to reflect the remaining partitions, and that would need searching for boot blocks etc.
Brian Carrier's book File System Forensic Analysis contains a lot of the basic foundations for this work, and there are also several examples on recovering partition tables. You probably need to have this knowledge to the job.
There might be faster ways -- but that depends entirely on what you actually have left on the disk. Once you have an image, you should be able to apply any other tools you might like to try on that image, with the only cost being to recreate the image of something fails.
The 'data recovery for dummies' approach would perhaps be to restore a full image on a second drive, connect that to Windows, and throw some hard disk recovery software at it. (Don't know any -- but a Google search does come up with candidates like File Scavenger, Nucleus, Stellar Phoenix and others). As long as you have a reliable image that you can create working drive copies from, you can take your time and experiment with these and other options.
But as always -- if you need the job done quickly, go to data recovery professionals, and expect to pay for it.
Thanks for all the great pointers. I had been assuming data recovery and computer forensics were very nearly the same thing but I can see now that they are not, therefore the same rules don't really apply.
No, there is no rush and no real urgency. I had been looking for something interesting to do to teach myself linux and some of the cool things you can do with it, so I was looking at this as a good project to dive in with.
I have been busy with work the last couple days so I haven't done anything else, but I will write back later to let everybody know what I tried and how it worked. Thanks again.
Actually, there is a large amount of overlap in the skillsets of logical data recovery and forensics, but not all practitioners of either are necessarily comfortable working in linux at the command line.
The answer to the size issue with dd and samba is actually quite simple, and that is to use the linux "split" command. Simply, you read in the data with dd, and pipe it to split to produce chunks with a size of 2GB, (2000m) or whatever size you prefer.
As an example:
> dd if=/dev/sdb | split -d -b 2000m - image.part. _________________ Tony Patrick, B. Inf Tech, CFCE
Patrick Computer Forensics Inc.
Memphis TN, USA
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Forum FAQ
Search
Usergroups
Profile
Log in to check your private messages
Log in
