.dd file conversion in Windows

Can you get more info on the .dd files? How they were made? Do the image files match the size of the original drive and partitions?

Another tool you could try is TestDisk to mount the image. This tool can also recover lost partitions in the image:
http://www.cgsecurity.org/wiki/Image_Creation

Two more links to look at

http://www.tomshardware.com/forum/281354-32-restore-disk-image-file-testdisk

http://forum.cgsecurity.org/phpBB3/how-to-restore-dd-disk-image-t88.html

The second link is referenced by the first link.

Essentially you are using TestDisk or Photorec to examine the image and recover the files.

I am thinking .dd is alike .iso file and if use qemu or kvm, it may load this raw image file as input file and run as it is assuming the file is not corrupted. if that is alright then conversion can be further done to clone into usb drive. The LiveUSB gives steps from iso into a bootable USB (below in article there is windows approach and tools mentioned and also mention of using (sdc is the USB)  >> # dd if=/path/to/image.iso of=/dev/sdc bs=8192k
https://wiki.gentoo.org/wiki/LiveUSB/Guide

Unlike .iso, .dd is not a standard extension. It seems the vendor invented it to give some idea that he created the files using dd.

looks like if this is non standard, not even the raw image we expected esp when most of the tool cannot recog it including testdisk than probably only the vendor should advice in this...

@Duncan Roe , while .dd is not an official standard extension, it is in use to refer to raw image files.

Forensics Wiki lists it as a file extension used for raw image files:
http://forensicswiki.org/wiki/Raw_Image_Format

OSFMount also mentions it on the feature chart:
http://www.osforensics.com/tools/mount-disk-images.html


It does sound like the files aren't standard raw image files though. Perhaps knowing the exact utility used to make the image files, and the settings used for that utility, would help figure out either how to read/mount the image files, or write them to a new drive.

From TestDisk, if it is true .dd image expected then this should be applicable

How to open the image.dd file ?
An image is interesting if the original disk has physical problem (ie. bad sectors) or if you really need a copy.
linux.png mount -o loop,ro image.dd directory
mac.png macosx.png rename image.dd to image.img or image.dmg and double-click on the file
Specify the image pathname in parameter to run TestDisk or PhotoRec on the disk image.

http://www.cgsecurity.org/wiki/TestDisk_FAQ#How_to_open_the_image.dd_file_.3F
Also TestDisk can work with disk images including forensics images created by EnCase and FTK imager.

Suppose the partition files are called part1.dd & part2.dd (for disk partition 1 and disk partition 2). Then on a Linux system, as root proceed approximately as follows (from the directory containing part1.dd & part2.dd)

mkdir -p /mnt/part1 /mnt/part2
mount -oro,loop part1 /mnt/part1
mount -oro,loop part2 /mnt/part2

Select allOpen in new window

A modern Linux system will probe the file system type or you can give it explicitly, e.g. mount -oro,loop -tvfat part1 /mnt/part1.
If you suspect the image is ntfs, you could also check it with ntfs-3g.probe

if the vendor claims those files are fat16 based then good to verify provided as well it is standard raw image (which may not). In short,  FAT is mainly used on memory cards from digital cameras and on USB keys. VFAT can be found mainly on external harddisks formated under Windows. Command such as  (watch out for the "System" column)
e.g. fsstat <device> to display more detail about the layout of a particular file system in the device
e.g. fdisk -ul <device>. The option -ul means list the partitions on the device and assume a unit size of 512 byte or can just use -l option to list the partion tables for the specified device only

more example in http://blog.creativeitp.com/posts-and-articles/linux/disk-analysis-with-fdisk-mmls-fsstat-and-fls/

There will only be a partition table on the complete disk image. The partitions are just that.
In case you don't have it, fsstat is part of The Sleuth Kit (TSK)

I guess I'm still not clear about the solutions being offered by the group, so I guess I will investigate them from the top down as time permits today. I gather that a Debian kernel will not be new enough to address this via Linux. I know very little about the Linux environment.

This is what came with the read me file:

"The files in this folder contain exact images taken from the hard drive
inside the industrial controller, serviced for <company>
in February 2015.

This specific controller may be identified by a label on the rear od the chassis:

Cutler-Hammer IDT
Model: D735SVSP16SDW31
S/N: A1154-001
70VA 110/230V 50/60HZ

The geometry of the hard drive itself, as reported by the GNU/Linux fdisk utility:

1082 MB, 1082253312 bytes

34 heads, 61 sectors/track, 1019 cylinders, total 2113776 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Each of the files were created using the dd utility."

"Each of the files were created using the dd utility."

What was the specific command used to run the dd utility? They must have run it at least 3 times, using three different commands.


I'm not sure what you mean by "Debian kernel" and how it relates to your disk image issue. It's true that Debian releases don't use the most recent versions of the Linux kernel, but you should still be able to restore disk images using it.


You can also try writing the raw image to disk in Windows. Some free utilities include rawrite32 and Win32 Disk Imager
http://www.netbsd.org/~martin/rawrite32/ 
http://sourceforge.net/projects/win32diskimager/
http://hddguru.com/software/HDD-Raw-Copy-Tool/

To add is what if we fdisk -ul those .dd files since it states only fdisk, good to under what system type it is running (really FAT16?) for this controller HDD..

NOT a Linux guy at all. At one time, I was going to use Linux clients in the factory, as always, instructed to do so at no cost. I was able to find a "free" Linux version called Debian Etch (Debian 4.0). The Mob didn't let it go very far, long story.

The firm that made these .dd files made them on a Red Hat system. I recall hitting a few bumps in the Debian Etch world that always pointed to the Debian flavor, and kind of like Darwin in Mac OS X Jaguar last I used it, as being just different enough on the command shell side to be non standard to Red Hat. Red Hat appears to be what most of the Linux people use, and not all Linux are the same, or so it appears?

But here is where it gets scary/frustrating for me. I open up testdisk only to see what you see on the attachment, or what I call the Great Command Prompt Mystery. So yes, there is my C partition showing, and a proceed/quit button. If I hit proceed, do I get to browse to the .dd files, or is just going to fall into creating an image of the C drive? Hell, I don't know...

Yes, there are differences between Linux "distributions," such as Debian and Red Hat, but dd is a standard tool and is going to behave the same way regardless of distribution.

As for TestDisk, you have the explicitly tell the program to load the image file. You can either do that via the command-line, or by dragging the image file over the TestDisk executable. The command line would look something like:

testdisk_win.exe image.dd

Select allOpen in new window

This was detailed in the link I provided:
http://www.cgsecurity.org/wiki/Image_Creation


Be sure you're working with a copy of the disk image, as TestDisk can make changes to the file.

Work on the copy version and not the original .dd file - better still have the hash (e.g. md5summer or equv) to make sure integrity checks ..

"better still have the hash (e.g. md5summer or equv) to make sure integrity checks .."

I have no idea what that means.

those file to examine can be hashed using a tool called md5summer. That is supposed to be like a checksum to make sure after those examination the file are not tainted. but come to think of it I suspect each .dd file is too huge for really to hash like any other smaller files ... wonder if the vendor gives assurance to .dd file if it is not tainted with some sort of checksum etc (otherwise we are "climbing on the wrong tree")

testdisk returns:
INVALID NTFS and EXFAT partitions.
I might be dealing with a proprietary rewrite of the NT 4 kernel by Cutler-Hammer. I have seen this before on machining centers like this. The machine is booted and running on the floor at current, and these images were made from that image. Maybe these programs are expecting something more "standard." in Wintel terms?
Frustrating...

ExFAT is a newer file system, and not the same as FAT or FAT32.  If the machine went with a proprietary file system or partition arrangement, then the imaging tools may not be able to detect and recover from them properly.

PhotoRec can bypass the file system entirely and search for file types. Choose the "whole" partition option when using it, again loading the image file the same way you did for TestDisk:
http://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step


There's really no file size limit for creating a md5 checksum. You can use free Windows tools like HashMyFiles or WinMD5 to create one:
http://www.winmd5.com/
http://www.nirsoft.net/utils/hash_my_files.html

Photorec actually brings up the directory structure that testdisk will not, but then recovers everything as text files. Unlike the screen shots on the example, I don't get that output to the screen, and the folders that are recovered to the target directory are titled recup_dir.1 etc.

Win32DiskImager is another matter. It odes not see the .dd files. OSFMount allows me to make them into .img files that it can see, I guess I'll try that now.

And...Win32Diskimager runs successfully only to not deliver files to the disk, but just cause the target disk to be unformatted.

I think PhotoRec may go through one file type at a time starting with txt files. So you'll see it recovering all the txt files it can find before moving on to recovering other file types. If there's a specific file type you're looking for, you can just check that and uncheck the others. You can see all the file types PhotoRec can recover on this page:
http://www.cgsecurity.org/wiki/File_Formats_Recovered_By_PhotoRec

Only when PhotoRec says "Recovery Completed" has it recovered all it could find. Also, PhotoRec will recover files, but not the original filenames or directory structure. You haven't specified what files you're trying to recover or why, so I don't know how important these factors are.


For Win32Diskimager, which image file did you use? Only the "full disk" image would likely contain the MBR needed for proper partitioning and recognition of the drive in Windows.

HDDGURU also returns an unformatted target result.

The fact that I'm not getting anything close to a result tells me there is something wrong with the source drive that these images are made from and/or a proprietary rewrite of the MBR is a problem. I'll need to get a hold of the vendor to find out what this "easy" recovery process would be with these .dd files and test it on an actual PATA drive.

I can't think of anything else. All the resources given should have returned something viable, I would think.

You could try and use VIrtualBox tool vboxmanage to convert your .dd file to a .vdi image using:

vboxmanage convertfromraw copy_of_your_file.dd output.vdi

Create a virtual machine (linux for example) and attach that converted vdi as an additional disk.

This?

https://www.virtualbox.org/wiki/VirtualBox

QEMU supports mounting a raw disk image directly, so running something like...

qemu -hda image.dd -m 256

Select allOpen in new window

...with the full disk image may work in booting to the NT 4 partition. Be sure to test using a copy of the image file.

See here:
http://superuser.com/questions/299227/how-to-boot-dd-image-in-qemu


QEMU can also convert to other virtual disk formats:
https://en.wikibooks.org/wiki/QEMU/Images#Converting_image_formats

That virtualbox, yes.

Note that I'm not suggesting to boot from that image, just mounting it as a secondary disk. Booting may work although I never tested booting a WinNT4 disk image in virtualbox.

Given that each solution offered has failed on the .dd file format in one way or another, it's either a bad image that these programs can't see, a proprietary configuration inside the image that the programs don't expect, or something "different" that the vendor(s) have done, both machine company that created the kernel and/or the company that imaged it.

Please see attachment. Only Win32DiskImager returned a possible working solution. While it was able to "mount" both of the logical drives of the image on to a USB disk that show up in Disk Management, accessing them in Explorer returns the unformatted drive condition.

Huh. The Chinese can walk freely among the United States data stream, but I can't crack a silly .dd file...
I'm am open to suggestions as to how to assign points on this one.

The Chinese had it easier, as they were accessing information that was meant to be easily readable, just not by them. You're dealing with something that nobody but the original manufacturer was intended to touch.

Did you try running TestDisk on the removable drive you wrote to with Win32DiskImager ? I'm wondering if it'd work better on detecting the file system on a physical drive.

As for assigning points, if you feel nothing provided an "answer", you could delete the thread. If you want to reward effort though, you could reward the post or posts that you felt helped you the most in narrowing down the issue, i.e that something is up with either the image files or the formatting of the original drive.  So suggestions for tools or techniques that you wouldn't have thought of on your own would be good candidates for points.

Thanks for the suggestions. I believe that people should be rewarded on both good faith effort as well as results.

Honestly, I didn't really document everything I tried, but I believe testdisk, as the others, could not see the .dd file directly until it was converted to an .img file with OSFMount first. None of the solutions offered seemed to handle the .dd file well without some manipulation first, but, I should disclaim that by saying, in a Windows environment. Perhaps if I had both a working kernel and a working knowledge of Linux, this wouldn't be an issue.

But, as they say with 20 of 500 laps to go, "Ya got, what ya got!"

OK! More to try.
WinDD was recommended by the vendor. Failed.
I'll try Clonezilla and a bootable flavor of Linux as well.
Give me some time on this one.

My gut feel, after seeing the drive scheme on the USB stick, it that it's "there," but the configuration is weird. That's pretty common in machining centers like this when they use an actual Windows kernel. Our Mazaks are all 95b, this machine NT4, and our Schutte tool grinder was a DOS/XP dual boot. Our chip processor ran in Windows ME as the front for an A-B ladder logic program. I think it was Windows CE that worked the best for embedded OS, found on many of our Swiss machines now.

Great suggestions all. I am learning things, if nothing else.

Of course. You really should try a live CD - much less trouble than installing  Ubuntu or any other Linux distribution.
I recommend Knoppix. I have found over many years that it "just works".
Try the loop mounts from the command line. If they don't work, you should get a useful message telling you why.

just a head up, or you may already know, Clonezilla do not run off WIndows so either have its iso (download available in its site) on CD to boot and use it on there is a Live USB http://clonezilla.org/liveusb.php

actually I was thinking you can get UltimatebootCD (UBCD - https://www.ultimatebootcd.com/) which has testdisk, PhoteRec, Clonezilla etc. It comes in handy as an all in one Boot CD for your use case testing ...

Update.
I used and booted to the rescue CD as recommended.
Now, the painful process of learning the commands needed to navigate around and do what I need to do. All new to me.

Another toe stubber is that when Win32DiskImage did put the image on the USB stick, it cut it up into three partitions, and neither disk management in Windows nor diskpart at the command line can correct this. diskpart does not "see" it as it is removable media.  Note that the Delete Partition option is greyed out.

Another day, another search for a utility...

Techincally it's two partitions and an area of unallocated space. The diskpart "clean" command should wipe the whole partition table off the drive, and then you can create a new single partition on it, once you're done using the drive. You may want to try accessing it via Linux first though.

diskpart list disk command doesn't even bring it up.

"You may want to try accessing it via Linux first though."

Have to learn how to do that...

Why not just hire a Linux guy for half a day?

I think what I will do at this point is close this question and award points accordingly.

Thanks for all the help!

I will open a new question to deal specifically with the expansion recovery of the .dd files in the Linux environment now that it appears I have all the moving parts in place to do that. Now, I need the Expert Linux help, and I believe that to be well beyond this question and far more specific.

Again, thank you.