Mobile forensics tools like UFED and XRY produce a forensic image of mobile phone in a .bin file in along with their proprietary format (.ufd and .xry)
Why are forensic images of mobile phones produced in a .bin file, whereas a forensic image of a hard drive is not?
Why do Encase, Ftk etc not produce forensic images in the form of .bin file if it is the same as a raw forensic image?
And finally is there any difference between forensic images as .bin file or raw file and dd image?
Regards
The .ufd file is not a forensic image. It's an administrative file - plain text actually - with information about the forensic evidence file.
Who says forensic evidence files for computers can't be .bin files? File extensions mean nothing. What matters is the underlying data. Files labeled .bin, .dd, .001, .raw, .img all have the same underling file format - none. They are bit-for-bit the same as the original evidence they were created from.
The E01, Ex01, and AFF formats are preferred by the tools you list because those file formats store the hash value of the acquired data, include checksums for blocks of data, and allow compression. In contrast, dd images have none of these features.
There is nothing stopping mobile forensics programs from saving acquired data as E01 files - except licensing issues. You can, however, take a .bin file created by Cellebrite and use something like FTK Imager to reacquire the .bin file as an E01.
Terry
Why are forensic images of mobile phones produced in a .bin file, whereas a forensic image of a hard drive is not?
The choice of file extension is, to a large extent, arbitrary. .bin doesn't really mean anything unless you know what tool actually produced it.
Why UFE or XRY name their files this way … well, that's up to them.
Why do Encase, Ftk etc not produce forensic images in the form of .bin file if it is the same as a raw forensic image?
Same answer. It's really up to them.
Proprietary image formats help lock a customer into a product family. That could be part of the reason.
A raw image is rarely good enough as a complete forensic image. You want additional metadata about that image. Some manufacturers create a separate file for that so that you have to keep the image and the metadata file together. Others keep the metadata in the image file so that it can't be accidentally lost.
And if you image a storage unit that fails (say, bad blocks), you usually want to keep track of those failures. A raw image doesn't do that.
And finally is there any difference between forensic images as .bin file or raw file and dd image?
.bin is not a file format. It's an file extension that may only hint that the file should not be loaded into a text editor.
.raw is not a file format. You can't base any interpretation on that extension alone.
.dd may hint that it was produced from the Unix dd tool – but again, unless you know exactly how it was invoked, you may not be able to interpret the data correctly, especially artifacts from selection of bs or conv etc.
For example, a .raw image need not be from a hard disk. It could just as well be from CD, in which case it may mean that it has 2352 bytes per sector, and include the low-level information that is not present in a user data image. If you know the tool that created the image, you know when it adds .raw. Or you know that it's up to the user to decide on file extension.
But if all you have is 'image.raw', you may face some problems interpreting it. Some time ago, I had an image which contained a MBR. So I interpreted it as a hard disk, with MS-DOS partitioning. And it did not make much sense. After a while I realized it was a CD image, in which sector 0 contained an MBR. And that made much better sense. If I had known the sector size, I would have got that image right the first time.
Thanks for your answers athulin and twjolson.
To sum up, regardless of file extension, dd, bin, raw, (x.001, x.002….) are all same, in that, they are sector-by-sectory copy of a media without checksum.
But then, why can we add - and do hashing- a raw image into Encase or FTK, but not an image in the form of .bin files?
Thanks for your answers athulin and twjolson.
To sum up, regardless of file extension, dd, bin, raw, (x.001, x.002….) are all same, in that, they are sector-by-sectory copy of a media without checksum.
But then, why can we add - and do hashing- a raw image into Encase or FTK, but not an image in the form of .bin files?
A "raw" image is a "dd image" and it is monolithic.
If the image is divided in more than one file it is not more an image, but rather chunks of an image.
Any given tool (usually GUI) may have limited extension options to open a given "monolithic" file or a particular convention for naming "chunks".
There is not an universal convention for these files extensions, outside forensics common extensions are .ima (for non-partitioned media, i.e. a volume such as a floppy or superfloppy image) and .img (for paritioned media, such as hard disk images), other common ones are as saud .raw or .bin, but none actually matters, still what matters is what inside the image, if it raw data representing an image of some media, it is raw data, on some softwares it may be needed to change the extension of the file(s) to respect the *whatever* convention for extensions the given software uses.
If you prefer "raw" is a particular file type that may have different file extensions, much like you can have a "plain text" file with extensions .txt or with *any* other extension, like .doc (which does not make it a Word file) or (say) .readme.
The Windows OS relies on the extension to manage associations and any software may "invent" for any given file format/MIME type a new file extension, there are tools, namely file on Linux
http//
and Trid on Windows
http//
that help to understand which type of file it is regardless the extension.
Time to cite xkcd
https://
jaclaz
There is nothing stopping mobile forensics programs from saving acquired data as E01 files - except licensing issues.
Terry
I thought the Expert Witness file format was an open format?
There is nothing stopping mobile forensics programs from saving acquired data as E01 files - except licensing issues.
Terry
I thought the Expert Witness file format was an open format?
Not to my knowledge, see http//
There is nothing stopping mobile forensics programs from saving acquired data as E01 files - except licensing issues.
Terry
I thought the Expert Witness file format was an open format?
Not to my knowledge, see http//
www.forensicswiki.org/wiki/Encase_image_file_format.
The E0 format is a standard by ASR Data, not GSI.
http//
Definitely the EWF is not an "open format", see also
http//
in the sense that there are not public specifications for it from the makers (Encase/Guidance), but this not necessarily implies that it cannot be freely used by other tools, the licensing of it (and of the following EWF2 is not AFAIK fully clear, most of what we have is by Joachim Metz who reversed engineered them), see also
http//
jaclaz