Hi Dan Yes, that's a perfectly good point. I was really trying to get a dialogue going here more than anything, and it worked! However, I generally feel that the simplest and most transparent solution is the first port of call (Occam's razor). I have some reservations about the validity of slack and "deleted" space copying, and also feel that the preservation of *disk layout* might be an issue on which a challenge could be mounted. Above all, though, I am keen to see "forensics" workers pay more attention to *forensics* (i.e. the legal side of things), as there seems to be a tendency to concentrate on the technical details of procedures at the expense of the objective. The content of this list shows this up rather well. Thanks for your input. Mike Barwise Computer Security Awareness "Addressing the Human Equation in Information Security" > Mike, > > Ok, you make a good point about the desirability of having a > does-one-thing-transparently tool. And it would probably work fine, > especially if you could be sure you had a target disk with the right > geometry. > > I am less convinced however, that this is really key issue. True, it is > critical that a correct copy be made. But this can be demonstrated using > things like checksums. yes, that may be more challenging to explain to a > jury, but if a jury isn't going to accept that concept then we are all in > a lot of trouble. After all, there are many technologies (DNA sampling > comes to mind) that are not transparently simple yet are accepted as > evidence. Also, once you make your disk copy, you will still need to > analyze it. That will almost certainly be done by software running on top > of some OS, for which the same issues that you identified earlier will > arise. So while the tool that you describe would reduce the scope for > questioning the evidence, it would not eliminate it. > > "Michael D. Barwise, BSc, IEng, MIIE" wrote: > > > Hi Dan > > > > Yes, my idea (and it's only a suggestion) is that the copying engine > > does absolutely nothing except read sector X from disk A and write the > > data read to sector X of disk B, using a tiny native machine code > > routine. For IDE interfaces, this would be truly trivial. This reasoning > > is based on the possibility of a legal challenge to the concept of > > "exact copy". It would seem possible to cast doubt on the exactness of a > > disk copy if any "high level" process is used to perform the copying or > > it is performed over a complex OS, simply because a technically inexpert > > counsel or jury will be required to take this exactness on trust. > > However, the simple mechanism outlined would be explicable without > > ambiguity even to such an audience. The reason I thought of this was the > > numerous references to "stream copying". Of course, we are *not* really > > dealing with a stream here: we are transferring consecutive finite data > > blocks (sectors). Hence the suggestion. > > Michael D. Barwise, BSc, IEng, MIIE Computer Security Awareness tel +44 (0)1442 266534 http://www.ComputerSecurityAwareness.com Addressing the Human Equation in Information Security ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Sun Jul 01 2001 - 10:55:37 PDT