General Encase Ques...
 
Notifications
Clear all

General Encase Questions.

21 Posts
9 Users
0 Reactions
2,925 Views
(@patrick4n6)
Honorable Member
Joined: 16 years ago
Posts: 650
 

Helix a viable option, but you might want to make yourself up2date on the subject as well, e.g. http//www.forensicswiki.org/wiki/Forensic_Linux_Live_CD_issues

From an academic point, citing an entry on a wiki as proof of anything where the article is entirely written by a single author, who expresses his opinion throughout the article rather than sticking to the facts is sub-par.

The author extensively discusses mount flags but quite seriously, who actually mounts a drive that they are about to acquire? And furthermore, the creators of linux live CDs don't rely on RO mounting, they rely on hdparm.

Sorry for the deviation from the OP, but this continual misinformation about forensic live CDs is aggravating.

For the OP, if in doubt
Acquire the drives
THEN
Acquire the RAID logically

This takes longer, but it covers the vast majority of potential issues. As for drive size, I always have a kit full of big drives. I haven't used a destination drive less than 500GB in over 3 years. Plan for bigger and forget about compression unless your outbound IO method is really slow, or you unexpectedly get much more data than you planned for.


   
ReplyQuote
Jamie
(@jamie)
Moderator
Joined: 5 years ago
Posts: 1288
 

From an academic point, citing an entry on a wiki as proof of anything where the article is entirely written by a single author, who expresses his opinion throughout the article rather than sticking to the facts is sub-par.

Um, it's early in the morning over here (so I'm still only half awake) but surely that's a little harsh? I don't think joachimm was citing anything as proof, the point was simply to do a bit of background reading, no?

Jamie


   
ReplyQuote
(@joachimm)
Estimable Member
Joined: 17 years ago
Posts: 181
 

From an academic point, citing an entry on a wiki as proof of anything where the article is entirely written by a single author, who expresses his opinion throughout the article rather than sticking to the facts is sub-par.

Partick4n6 from an academic point you're absolutely right. I also would like to ask you to contribute your point on the discussion part of page of the wiki as well. Your feedback will help to improve the information.

But as Jamie correctly pointed out, I intended it mainly as some background material on the subject. Some concerns regarding live CF distros di.al might be aware of.

The author extensively discusses mount flags but quite seriously, who actually mounts a drive that they are about to acquire?

(Not intended to discuss the approach) I know that for some investigators it is a common practice to mount file systems to determine if a volume/partition contains a valid file system, e.g. in case of volume encryption, or that they are imaging the right disk/volume. Or in situations where you're not allowed to make an image and want to do file copies with more preservation then by a live copy (so-to-speak).

And furthermore, the creators of linux live CDs don't rely on RO mounting, they rely on hdparm.

I'm not sure what point you are trying to make here. Isn't this (slightly) addressed the last section of the article ? But again please contribute your input to the article, IMHO that is what the wiki is all about.

Off topic Perhaps it would be interesting to start a separate discussion of the validity and objectivity of information. This is something we often take for granted. IMHO this is only possible through opening up this information.


   
ReplyQuote
(@xaberx)
Estimable Member
Joined: 17 years ago
Posts: 105
 

Wiki is a great source of information, though its best to validate sources whenever possible however sometimes it is more useful to find an overview rather than reading a massive whitepaper. "some people just want the bird house, not the instructions on how to build it".

@Joachim - Thanks for the great post and information, I hope you liked my illustration I sent you on the multi-threaded indexer…though the time i spent on that image i probably could have had it halfway done already.

-Ryan


   
ReplyQuote
(@joachimm)
Estimable Member
Joined: 17 years ago
Posts: 181
 

@Joachim - Thanks for the great post and information,

Noprob.

I hope you liked my illustration I sent you on the multi-threaded indexer…though the time i spent on that image i probably could have had it halfway done already.

That's another topic of discussion, I'll continue with you outside this thread 😉


   
ReplyQuote
(@farmerdude)
Estimable Member
Joined: 20 years ago
Posts: 242
 

1. If you want to acquire a 80GB hard disk, how much space will you need in your forensic's machine local hd?

Without compression you will need 80GB on your destination to acquire an 80GB target.

With compression you may need something less than 80GB on your destination to acquire an 80GB target. The compressed output size written will depend upon A) the input data and B) the compression algorithm used to compress the data.

Give consideration as to the pros and cons of using compression in your image files. Recovering data from a corrupt compressed image file can be painstaking at best and futile at worst. Recovering data from a corrupt uncompressed image file can be a joy at best and a pain at worst (although there does exist the possibility of futile).

2. While i was searching about scsi hd drives acquisition i read that if the drives are on a raid array it is better to use helix to acquire an image.

I would not concern myself with any specific acquisition utility regarding possible RAID acquisitions but instead would concern myself with the proper methodology for acquiring RAID arrays. I teach my students to always, wherever possible, acquire each individual disk in its entirety and not the RAID array. By acquiring the individual disks you guarantee;
- all drives within the hardware case have been acquired in their entirety (minus any I/O errors), including those drives that are not in the RAID array
- all data on the hard drives is accessible for analysis in the lab, including any data outside of the RAID array

By acquiring only the RAID array you may miss;
- data stored on a hard drive that is a member of the RAID array but written outside of the RAID array
- data stored on former RAID array member hard drives
- data stored on hard drives located in hardware case but not a member of RAID array

Cheers!

farmerdude

www.onlineforensictraining.com

www.forensicbootcd.com


   
ReplyQuote
(@farmerdude)
Estimable Member
Joined: 20 years ago
Posts: 242
 

I know that for some investigators it is a common practice to mount file systems to determine if a volume/partition contains a valid file system, e.g. in case of volume encryption, or that they are imaging the right disk/volume. Or in situations where you're not allowed to make an image and want to do file copies with more preservation then by a live copy (so-to-speak).

Why would a forensic practitioner mount a file system to determine if it is a valid file system? I can only guess because they do not possess the knowledge of how to identify a file system without mounting it. A competent forensic practitioner should have all the tools and knowledge available to quickly identify the partition map and jump to the offset on the storage device to identify the file system type within that partition without having to mount that target file system. Same for identifying whether or not the storage device is the correct target or not.

With respect to copying files - why would a forensic practitioner mount a file system to copy files?

Cheers!

farmerdude

www.onlineforensictraining.com

www.forensicbootcd.com


   
ReplyQuote
(@joachimm)
Estimable Member
Joined: 17 years ago
Posts: 181
 

Why would a forensic practitioner mount a file system to determine if it is a valid file system?

Don't get me wrong I do not think it is a good practice either, but I know it happens.

With respect to copying files - why would a forensic practitioner mount a file system to copy files?

One could argue about if this is the correct forensic approach;
In case of a legally restraint scope of evidence seizure, e.g. in case of Legal Professional Privilege (LPP).


   
ReplyQuote
(@joachimm)
Estimable Member
Joined: 17 years ago
Posts: 181
 

Without compression you will need 80GB on your destination to acquire an 80GB target.

In case of RAW (dd) I agree but with EWF/E01 you'll need more than 80GB, due to the overhead.

Copy of the same floppy image input in both formats, EWF no compression
name, byte size
floppy.raw, 1474560
floppy.E01, 1478501


   
ReplyQuote
(@jwshaw)
Active Member
Joined: 15 years ago
Posts: 12
 

Since my employer uses 80GB disks in their systems, I have done more than a few acquisitions of those types of drives. Typically, my images with best compression are about 36GB in size, but that is because at least half of the drive is usually empty on the machines I image. Also, the majority of the data on the system is not compressed graphics images like jpegs. The EnCase dialog says that compression is slower, but in my experience, it is only marginally so. It takes my FRED approximately 105 minutes to acquire an 80GB hard drive image without compression and another 30 minutes to validate it. Acquisition with best compression of the same drive takes usually less than 10 minutes more, and usually no more than 5 minutes if I remember correctly, and saves a considerable amount of disk space. Of course, most of my cases are single-disk in nature, so if I was having to image a lot of disks over time I might opt for no compression if the trade-off in speed of acquisition was worth the price in extra storage space for images.

Also, calculating total space needed for an uncompressed image taken with EnCase is dependent upon the size of the source device as well as the split file size you choose. The default 640MB per file, which would require much more total overhead for the header and footer with case info, CRC values and MD5 hashes on each E01 file than say a 1, 2 or 4GB file size since there would be more total files.

And as others have stated, I would acquire each drive of the raid individually instead of trying to acquire logical volumes from the RAID.


   
ReplyQuote
Page 2 / 3
Share: