I too am thinking about going the Mac Pro route for lab use. I'd like to get some more input from those that currently use the Mac Pro. I'd be using it with FTK 1/2 and more than likely Encase Forensic, as long as it supports 64 bit OSes.
For OSes, I'm thinking Leopard and Vista 64 bit Ultimate via Boot Camp, as long as it works. Again, I'd be interested in hearing how current forensic examiners are using the Mac Pro.
I'm thinking about getting an eSATA card for the Pro and going that route, using a Tableau eSATA IDE/SATA write blocker and writing to a eSATA storage device, or NAS if I can find one cheap enough.
Again..just looking for experiences/setups using the Mac Pro…
I much prefer a desktop workstation in a huge case
I do think the macbook pro would make a great mobile unit for acquisitions and previewing.
The reason for going with the Mac Pro (I'd like to get the MacBook Pro in the future for on scene acquisitions) is that it's one beefy machine for the price. Granted, you don't want to buy RAM/Hard Drives/Video Cards (unless you like the feeling of your wallet being raped), but for the base system, I'd be hard pressed to custom build a system with those specs for the same price, although I've tried. Xeon processors with the 1600 FSB aren't cheap, and the two models on Newegg that I saw would set me back at least 2300…with the 2.8 ghz Mac Pro going for less than 2800 and assuming about $600 more for RAM and a couple of hard drives, I'm still well within the ball park.
As my shop is quite small (just me), and we process maybe a half dozen cases per year, I'm not assigned Forensics full time (though I'd really love to). So my time working on exams is limited. The less time it takes to preprocess in FTK, the sooner I can complete the exam.
I did look at the Silverstone cases when I was playing with custom builds..they are definitely a very nice case.
Chris
New Intel macs can run XP natively… You use bootcamp to simplify the driver installation process. Because they are Intel based, they run true XP, not emulation or VM. I think parallels is more like a VM.
I tried imaging a 40GB Western Digital (Model WD400BD-60JPA0) SATA HDD over different ports and have the following times
Mac book VMWare (USB2.0)- 2hrs 35mins
Macbook Bootcamp (USB2.0) - 1hr 35mins
Macbook Bootcamp (FW800, daisy chain tableau to evidence drive) - 0hrs 37mins
Lenovo T60 (USB2.0) - 1hr 23minsDid you try to image the drive in OS X using dd? The time for that would be interesting.
I've been performing some transfer rate tests lately, and found the following, rather odd results, depending on wether or not I was reading from the raw device or from a file on the mounted filesystem.
The results were identical when using a tableau T35es as bridge, or when connecting a Pleiades case with the harddisk build in as bridge (so it is not Tableaus fault)
System Mac Pro, quad Xeon, 8GB RAM, OS X 10.5.8
I was using the command
dcfldd if=XX* of=/dev/null bs=1024k count=1000
XX* The source is specified below
1) Reading from fast SATA Harddisk, connected to a tableau T35es
- Tableau via FW800 reading from /dev/disk6 16MByte/s
- UPDATE (see ebelow) Tableau via FW800 reading from /dev/rdisk6 80MByte/s
- Tableau via FW800 reading from a file on filesystem 75 MByte/s
- Tableau via FW400 reading from /dev/disk6 16MByte/s
- Tableau via FW400 reading from a file on filesystem 35 MByte/s
- Tableau via USB2.0 reading from /dev/disk6 10MByte/s
- Tableau via USB2.0 reading from a file on filesystem 32 MByte/s
2) Reading from fast SATA Harddisk directly connected via SATA
- reading from /dev/disk1 30MByte/s
- reading from a file on filesystem 220MByte/s (on a Raid0)
Does anyone have an explanation for the poor performance when reading from a raw device in OS X? ?
UPDATE Thanks to indur, I've just tested again, this time reading from /dev/rdiskX instead of /dev/diskX. And it works as expected - now I get 80 Mbyte/s from a harddisk connected via FW800 through Tableau T35es. GREAT!
Another interesting thing to see is that OS X is caching lots of data in memory, as long as you have sufficient -)
The 1000MB I was reading from a file got completely cached, giving quite impressing speeds during the second run when performing the same test twice.
Really you need tools that DO NOT cache data in memory.
for forensics you need to come directly from the device to the image file, you do not need any stupidity of the hash being calculated on data in ram that may be corrupted. There is ZERO protection checks built in.
I.E the data reads from the Hard drive cleanly…
The data goes into ram and has a bit flipped
the system generates a Hash on the data with a bit flip
Walla , your checksummed " bit image is NOT the same as your device.
This is why I don't like imaging software , it is not 100% foolproof even if it DOES a hash of the data.
This is why I don't like imaging software , it is not 100% foolproof even if it DOES a hash of the data.
What forensic hard disk imaging device does not use firmware (which is software burned to memory)? Sure, a single purpose hardware device could be engineered to be less prone to occasional error than, say, a multitasking OS which is running 30+ processes. But you're still running a system that keeps part of its process in memory so it seems to me to be a distinction without a difference.
Also, what is to keep a "software" based imaging system from comparing the hashes and if they don't match, redo the copy and rehash?
If your memory is flipping bits on you, you're likely to end up with incorrectly-computed hash whether you use cached data or not. All of the data to be hashed has to be read in to memory one way or another.
Marek The /dev/diskX device is not really the "raw" device. It is a cooked interface that is also cached by the OS. You should try the same tests using /dev/rdiskX.
indur, thanks a lot. Shame on me that I didn't realize this already.
I've now tested again, this time reading from the rdisk-device, and now I get the maximum data transfer rates of FW800, around 80 Mbyte/sec.
Again, THANKS! D
I don't understand the need to use a MacBook Pro for forensics.. Keep it simple..If you used a Mac Based forensic software use it..if you us a Windows based Forensic software then use a PC.. the less Stuff running the less complicated it get's and the less problems you will have.
I remember when having a Sterilized target drive was in Vogue and now we have Windows running on another OS… Anyone questioned the idea of cross contamination between one OS and another running a Forensic program.. I know it it can be documented that it doesn't happen.. but you've just added another mystical concept (VM's) into the Mix.. Why bother?