A write blocker does also give me the ability to more quickly explain why I am sure the drive was not written to during the imaging process, so I'll add that to my list of previously listed reasons for using one.
I really don't care much about the speed hit since the imaging is being done in an office, not on scene.
As far as writing to the drive; I'm confident ILooKIX will not write to the source drive. I am less confident that a human would never accidentally confuse target and source. The write blocker provides protection against such a serious accident. I'm sure it would never happen though… Right?
Good ) , so to sum up IXimager (as well as all the other mentioned and not mentioned "read only" imaging solutions) is completely unneeded as the WriteBlocker will take care of preventing the writes, i.e. there is not any advantage of any kind in using any of these read only softwares since anyway a WriteBlocker is used in practice.
jaclaz
Sorry Jaclaz,
but you are trying to find a "golden rule" for any situation and that's not possible. Write blockers surely have an eligibility, but software solutions like IXImager make a lot of sense, too. There are a lot of situations for LEO officers, where you can't dismount the hard drive(s) for the image creation. And I am more than happy when I know for sure, that the software will protect the data from any changes.
Same for sanitizing (wiping) hard drives. Even though it's not really necessary to wipe the drive before starting to write the image containers to it, it makes sense to wipe every hard drive in stock. We wipe every single drive, when a case is finished and the data is not needed any more and so every drive in stock is prepared for any waiting task, such as creating a drive clone.
Always remember Usually there are many ways to reach the same goal!
The answer is given by you yourself
In theory there is no difference between theory and practice, but in practice there is.
No need to be sorry, I am - as you noticed from my signature - trying to make things as clear as possible, both in theory and practice.
I am not trying to find any "golden rule", I am simply trying to separate the "needed" from the "optional".
The established procedure to "secure wipe" has been for years to do (unneededly) multiple passes, and actually long after the NIST has changed their standards, lots of people have continued using that approach (and I believe that still in many countries the multiple passes myth is still within the official norms).
The wiping (single 00's pass) and hashing of a disk intended to host an image or "clone" is unneeded in theory but advisable in practice for the given reasons (spend more time in the lab to save time in court explaining the procedure). The reasons are far from being "scientific" or "technical" they simply represent a choice (that makes sense as long as those questions will be asked).
The use of "read only" software is/was (in my perverted mind) an alternative to using *any* software through a writeblocker.
If a writeblocker is used anyway (as a "personal choice" or because of similar non-technical reasons), it makes no sense to prefer a given software (read only) over any other.
The preference might pivot on different features of the software, like ease of use, speed, whatever, but not necessarily to it's "read only" capabilities.
This unless - of course - there is a chance - even remote - that a hardware writeblocker doesn't actually block writes. 😯
I have never seen such a report, but in theory I guess it is possible that some particular hardware malfunctioning of the device lets some writes go through.
This could be another interesting topic.
jaclaz
Good ) , so to sum up IXimager (as well as all the other mentioned and not mentioned "read only" imaging solutions) is completely unneeded as the WriteBlocker will take care of preventing the writes, i.e. there is not any advantage of any kind in using any of these read only softwares since anyway a WriteBlocker is used in practice.
jaclaz
That's a giant leap of logic.
How does the foregoing discussion lead you to believe that the only advantage to using a read only software is to not have to use a writeblocker?
This unless - of course - there is a chance - even remote - that a hardware writeblocker doesn't actually block writes. 😯
I have never seen such a report, but in theory I guess it is possible that some particular hardware malfunctioning of the device lets some writes go through.
This could be another interesting topic.jaclaz
This did occur, with a Tableau, but it wasn't a hardware malfunction, it was firmware.
http//
Fixed a serious bug in the T35es which made it possible to modify the contents of a subject drive by sending a WRITE(16) command through the forensic bridge over its USB host interface.
Debbie
That's a giant leap of logic.
How does the foregoing discussion lead you to believe that the only advantage to using a read only software is to not have to use a writeblocker?
Because I have no other idea of the possible advantages, and unless I missed them here, no additional ones were provided.
As I see it a Read Only software tool is highly preferrable over a hardware writeblocker from a logical standpoint, if you have one no write command is ever sent, whilst when using the other write commands need to be detected and blocked.
The Tableau incident you mentioned is a "proof" of the possibility that some writes are not catched, thanks for finding that reference.
Since it affected the USB interface only (which I guess is never used for imaging largish disks) most probably the effect, as the good Tableau guys say, was never encountered in practice, but still it is IMHO a proof of the vulnerability of the "model".
By the same token, you anyway put a "black box" midway between source and destination and pray the gods of Tableau (or Wiebetech or whatever) that the thingy will catch all write commands and additionally doesn't (for a malfunctioning of some kind) ever generate itself a write command.
I see it - in theory - as an additional risk, not as an additional safety.
Once an OS/software tool is verified to never send a given command it makes to me little sense - in theory - to add a further filter supposed to "catch" that never sent command.
I do understand how in practice having BOTH may be preferred by the investigator, but it is evident how this can only derive by either wanting to protect the "procedure" (similarly to the talked example of the preventive wiping/hashing) from possible attacks in court or because neither of the two approaches can actually be trusted fully (and in the case of the hardware blocker at least we do have an example of this actually happening).
jaclaz
So in reading through the many postings to this thread of this forum it seems this topic has digressed. What started out as a question about iLookIX turned into questions about IXImager and eventually digressed in to examiner policy and practice with some debate as to logic of using more than one write blocker and preference.
Maybe Jamie should just start a debate forum where one can provide a response to a question only to be told they are illogical.
With regard to the intent of the thread one of the most versed people to answer questions is Debbie. If you can deal with eccentricity you may wish to reach out to Jim Baker. You may also contact Sumuri to be put into touch with Fred who teaches the iLook certification course.
I was an EnCase user then migrated to FTK once EnCrash 7 was released. I started to look for alternatives when Guidance's response to a poor product was more training on how to use a tool which did not function. AccessData seemingly is starting to follow this business model. I can tell you I am working to migrate to XWF and iLookIX. I have spent more time with iLookIX, IXImager, and iSeekImager.
iLookIX is a pretty fantastic piece of software whether anyone wants to accept it or not. Sure XWF may lack a few superlatives from the company but their followers sure throw them out - look at the new book and blog. By the way I think it's fantastic!
Anybody see the recent AD ad's? They took number from a poll and blasted EnCase. Then there is the "numbers don't lie" ad. Is there really much difference? Their tool works great but it also could be better.
What does iLook do poorly? Reporting. It works and is online with others but it could be better. So, I emailed Jim with ideas and now they are working on better reporting. The interface could be a little easier to deal with at time for specific artifacts like registry keys, attributes, and metadata. But what they offer now blows away EnCase 6 and 7, and FTK 4 when it works. FTK still works well. XWF is pretty good from what I know from the free trial I used. So, every suite has a problem and usually does something better than the other. You can't say there is one perfect suite or you would worry about automated verification of artifacts.
"So, every suite has a problem and usually does something better than the other. You can't say there is one perfect suite or you would worry about automated verification of artifacts. "
Amen to that brother. Show me the perfect tool that does everything better than anything else and I'll let you take a ride my unicorn.
And beyond all the tech related arguments, emotions usually win out as we each choose the tool we prefer using the most, even if it might not be "better" than another tool.
Because I have no other idea of the possible advantages, and unless I missed them here, no additional ones were provided.
Well, to be fair, no one asked.
IXImager has many other uses, and many advantages over other imaging software, and some things that can be preceived as drawbacks, depending on your perspective.
Other uses obtaining info (and capturing it to a log file) about devices attached to the booted computer, basic disk operations, preview a device, clone a device or restore a device from an image file, and others.
Advantages - does not require writeblocker, fast, able to be used on multiple computers at one time, able to span the image file on an adhoc basis over multiple devices, ironclad image file, great log of what occurred during boot, device detection and imaging. ILOOKix works best and fastest when using it's own image files but can use other image files.
Disadvantages - proprietary image file - but capable of being converted to a dd or a vmdk from within ILOOKix.