Bin vs RAW in terms...
 
Notifications
Clear all

Bin vs RAW in terms of forensic imaging

9 Posts
5 Users
0 Reactions
5,532 Views
(@yunus)
Estimable Member
Joined: 17 years ago
Posts: 178
Topic starter  

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


   
Quote
(@twjolson)
Honorable Member
Joined: 17 years ago
Posts: 417
 

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


   
ReplyQuote
(@Anonymous 6593)
Guest
Joined: 17 years ago
Posts: 1158
 

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.


   
ReplyQuote
(@yunus)
Estimable Member
Joined: 17 years ago
Posts: 178
Topic starter  

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?


   
ReplyQuote
jaclaz
(@jaclaz)
Illustrious Member
Joined: 18 years ago
Posts: 5133
 

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//linux.die.net/man/1/file
and Trid on Windows
http//mark0.net/soft-trid-e.html
that help to understand which type of file it is regardless the extension.

Time to cite xkcd
https://xkcd.com/1301/

jaclaz


   
ReplyQuote
(@codyf)
Active Member
Joined: 10 years ago
Posts: 7
 

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?


   
ReplyQuote
(@twjolson)
Honorable Member
Joined: 17 years ago
Posts: 417
 

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.


   
ReplyQuote
(@codyf)
Active Member
Joined: 10 years ago
Posts: 7
 

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//www.forensicswiki.org/wiki/ASR_Data's_Expert_Witness_Compression_Format


   
ReplyQuote
jaclaz
(@jaclaz)
Illustrious Member
Joined: 18 years ago
Posts: 5133
 

Definitely the EWF is not an "open format", see also
http//pyflag.sourceforge.net/Documentation/articles/forensic_format.html
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//www.digitalpreservation.gov/formats/fdd/fdd000406.shtml

jaclaz


   
ReplyQuote
Share: