I am clearly missing something. 😯
Test Machine Dell Vostro 3450, Core i5, 4GB RAM
HDD Samsung 320GB HM320HJ Platter Drive. Total bytes 320072932864 bytes.Ballistic connected to 2 x USB2.0 ports, and 2 x USB3.0 ports. Drive imaged in 3511sec (58mins 31secs). Average speed of 5.469GB/min.
The source drive is the 320 GB Samsung.
The target(s) are connected to two USB 2.0 ports+2USB 3.0 ports, right?
What are the the target(s)?
Which device/disk/whatever?
One port is used to boot the machine to the WinFE that runs the Ballistic software. (I would presume one of the two USB 2.0 ones) what is connected to the other 3 ports?
Three disks?
Three SSD's?
Something else?
If I get this right, there are multiple "targets" each of which will receive a part of the image?
If yes how is the hash calculated?
Then some time will be needed in the lab (or headquarters, etc.) to reassemble these parts?
jaclaz
Hello,
It works on a live machine, or WinFE environment. Once WinFE has loaded via USB, I can remove the WinFE boot device as everything is in RAM at that point.
Ballistic splits the physical image file over as many 'collectors' as you have inserted into the machine. In this case I had 2 collectors in both USB2.0 ports and 2 in both USB3.0 ports. I could have added an additional express adapter for more USB3.0 ports, or used the eSATA port.
My collectors, or target drives are listed above. 2 x Kingston HyperX drives, and 2 x Samsung SSD's.
Source SHA1 hash is calculated on the fly (you can also do MD5, SHA1, MD5 + SHA1, or none), and is recalculated once the image is stitched back together. To be fair, we don't worry about hashing anyway, a lot of our data won't even be looked at evidentially. There's a log file written to each collection device with all the details.
Some time is required in the lab to stitch it together, but we run HP Z820's that are spec'd up with CPU's and RAM, so a 320GB image file didn't take that long to glue back together. I'll do it again and see exactly how long it took.
For us, getting the physical image on target is a priority. It doesn't matter how long we take to process it back at the FOP. If we've spent £2million getting a soldier in front of a PC in hostile territory, then they need to be able to image as much as possible, in the shortest time possible.
Before leaving an onsite job we like to either open the images we have made in EnCase or mount using FTK to make sure what we have got works and makes sense etc
Is there anyway to do a check like this if the parts are spread over several drive?
@markl1975
Thanks, now the procedure is clear. )
I had missed that the WinFE with the software is loaded entirely in RAM, once booted from USB, so, if for any reason it doesn't boot from the stick, booting it from a CD or DVD should also be possible, though a tadbit slower.
Though this brings however us back to the generic issue that if the PC has a BIOS password and it is set to boot from internal hard disk only you have anyway to take the disk out of the PC.
The idea is however very nice, and I am sure that it can represent a "life saver" in those peculiar scenarios you described.
jaclaz
Yup, BIOS passwords are still a problem! You can boot WinFE from a CD/DVD as well, though I use a Zalman VE400 to boot images via a virtual CD ROM drive.
As for previewing the data on target, this is something we don't do. I think you would have to rebuild the image first, however you can carve the hex in the individual image files. You might want to ask the vendor about this, we tend to image drives and worry about the data back at base.
So what is written to the (various) target devices are plain "disk chunks" or partial dd images of contiguous space?
I guess it would be nice (if possible in any way) to have a driver recreating a "virtual" filesystem from these chunks without needing to "reassemble" them.
Something not entirely unlike what spanned volume on dynamic disks under windows or LVM storage under Linux look/behave. ?
jaclaz
Thanks for all the comments, apologies for lack of correspondence (holidays). We are always looking at speeding the process up for Ballistic and we have an interesting roadmap. We have made the process as simple as possible and as quick as possible. In my last career we had many scenarios "in the field operations" where we decided to migrated from drive removal to live boot (about 3 years ago). The field operator now carries less kit, can image devices at lightening speed and requires little training. This tool will not be for everyone, although I have shown this to Forensic Labs (with interest and sales as there is need to save time), yes you need to carry more than one drive as the image is split between 2 or more drives.
The 4.5 mins for a 120GB SSD (with 9gb free space) was running at 453mb/s (27gb/min) over 3 collectors (Samsung Pro - Esata, Kingston HyperX - USB 3.0 and express adapter USB 3.0). The rebuild on this, back at the lab or in the field was 5 min 28 secs. Therefore I imaged and rebuilt in under 10 minutes.
Ballistic will also image RAM on a switched on machine - 8 GB in 18 seconds.
Log files pers acquisition are created on each inserted device showing disk details, image details and hash values, running times etc.
Ballistic can also have drives inserted and ejected whilst running.
I am in the process of collecting (and will post) a few running speed examples on varying disks.
Many Thanks.
How fast would ballistic be to a RAID connected via USB3 or eSata - how does this compare to using DD/encase to a similarly connected RAID.
Not knocking ballistic as I can see where it could be useful (although not for me) just wondering whether for a proportion of scenarios (how many machines do you see with fast interfaces) whether there are existing solutions that are equally fast.
@Paul Sanderson
We haven't tested RAID as a collector. If Ballistic were to be tested like this, then you would need 2 or 3 RAID attached to separate USB3.0 or eSATA ports, which is a lot of kit to carry around for the field guys which we are trying to get away with. Not to say it's not an option.
Paul can you suggest a small RAID, USB3.0 type / trusted/ reliable etc, and we will get one in, test and get back yo you?
@Paul Sanderson
We haven't tested RAID as a collector. If Ballistic were to be tested like this, then you would need 2 or 3 RAID attached to separate USB3.0 or eSATA ports, which is a lot of kit to carry around for the field guys which we are trying to get away with. Not to say it's not an option.
Paul can you suggest a small RAID, USB3.0 type / trusted/ reliable etc, and we will get one in, test and get back yo you?
If I may, this is not the actual idea.
Generally speaking the data
- can be read as fast as <put here max, top speed of READing the source disk>
- can "go through" a bus as fast as <put here max, top achievable speed of the actual bus used, let's say USB 3.0>
- can be written as fast as <put here max, top speed of WRITing the target device>
Now, since usually the READ speed of the source is
a) unknown without knowing which specific make/model of disk (or SSD) is in the machine and/or which chips are used in it's motherboard etc.
b) fixed/unmodifiable
One can operate in two ways to (hopefully) speed up the imaging
1) IF the slowest item is the BUS use a faster bus/connection (if available) or - as I believe the Ballistic thingy does - "widen" the BUS making parallel transfers over more than one connection and thus "deliver" the data to two or more separate devices (which conversely has also the "side effect", by dividing the amount of data over two of more devices to increase the overall WRITing speed) .
2) IF the slowest item is the "target device" use a faster "target device" such as a RAID 0 (strictly speaking not a RAID as there is no redundance)
The overall idea is not completely different, in both approaches the data is split over two or more devices, in the case of the Ballistic this split happens right after the READing of the source and the data is sent through different BUSes/interfaces to different devices, in the case of a RAID 0 the data is split after having been delivered through the BUS over two devices.
The Ballistic approach seems like a way to shorten the time "on site" at the cost of some more time needed "in the lab" and as we have seen this may be a great advantage in some scenarios and maybe no-so-needed (or desired/appropriate) in other ones.
The RAID approach has it's merits as well as what you get is actually a single "data store", divided over two physical disks.
The convenience of choosing the one or the other approach (or even a more traditional one with a "plain" 11 imaging/cloning) depends IMHO from a number of reasons that anyone should judge by himself/herself.
Let's make a few completely fictional examples.
Let's say that we have
1a) a source capable of an average sequential read of 100 units (express this 100 in whatever units of data transfer speed you see fit, let's say Mbytes per second) let's call this SRS or Source Read Speed
2a) a BUS capable of an average sustained effective transfer rate of 200 units, let's call this BSS or Bus Sustained Speed
3a) a target capable of an average sustained sequential WRITE speed of 400 units, let's call this TWS for Target Write Speed.
In this case, unless the Ballistic solution (as it was hinted before) has some *magic* that allows it to "suck" data at a higher speed than what the source device allows, there is NO need whatsoever of splitting the data over several connections, NOR to split it through a RAID 0.
In another case
1b) SRS = 300
2b) BSS = 200
3b) TWS= 400
It makes a lot of sense to split the data at the BUS level as using the Ballistic approach we have (using two connections)
1c) SRS=300
2c) BSS= 200 x 2 = 400
3c) TWS= 400 (of which actually only a 200 speed is needed for each device, so that you can afford to use slower target device)
In yet another case
1d) SRS = 300
2d) BSS = 400
3d) TWS= 250
Using a RAID 0 as target makes sense as you would have
1e) SRS=300
2e) BSS=400
3d) TWS= 250 x 2 = 500 (in real life a RAID 0 doesn't really-really double write speed but it goes near it enough for this simplified example, and in any case the speed of the source limits the theoretical time to 300)
As well in the same case above it would make sense to use the Ballistic approach as
1f) SRS = 300
2f) BSS = 400 x 2 = 800 (of which actually only around 150 are used for each connection)
3d) TWS= 250 x 2 = 500 (of which actually only around 150 are used for each connection)
So, more generally, the "ideal" solution is to have
SRS <= BSS <= TWS
The SRS is "fixed and unmodifiable" and depends on the actual machine to be imaged.
The BSS is also "fixed and unmodifiable"as above, but since there may be more than one bus and/or the posiibility to add to the PC a fast add-on card it is possible in some cases to "widen" artificially (using the Ballistic split) the bus (thus enhancing the data transfer speed).
The TWS is entirely dependent on the choices/possibilities of the forensic examiner, obviously the faster it is, the better it is, no matter if using the Ballistic split or not, the advantage of splitting the data earlier may be that even slower devices can be used without affecting overall imaging speed.
The Ballistic approach can increase at the same time BSS and TWS (unless of course you choose to use really "slow" Buses and Targets), whilst a RAID 0 would affect only TWS.
What need to be seen are what "real" values for SRS, BSS and TWS one can find on the field.
Just as an example, if the PC to image has a fastish source disk, but only USB 2.0 interfaces (and no possibilities to add "fast" USB 3.0 card through a PCIe slot or similar) removing the disk and imaging it directly would probably be faster, as well, if it has a slowish disk but a good USB 3.0 (or other fast BUS interface) the splitting over more than one bus might not provide any advantage over having the faster possible target device.
jaclaz