not sure this is really realisitic - for example you say you don't want an OS but you will need some form of 'Operating System'. this is further complicated by the operation of copying sectors to sectors - there are a large number of drivers needed in that application - e.g. SCSI, ATA, etc not to mention a fairly difficult mapping, i mean without _identical_ disks how can you map 1 sector to another & at what level do you do it ? the idea is nice but i think the application may be far more complicated than it appears & certainly more than a few KB of code. On 19.03-10:28, Michael D. Barwise, BSc, IEng, MIIE, MBCS wrote: > Sorry to butt in- hope it's OK. > > For this very reason (uncertainty of image accuracy), I have been > lobbying for ages for a dedicated imaging system which does not rely > on an *operating system* or *architecture*. It's a ridiculously > simple problem to solve (probably a few kB of code and a couple of > interface cards). > > On 25th Jun 2001 I sent this to the forensics digest, and I still > believe it's the right answer. > ------------------------ > My ideal disk copier would be a very basic PC, probably one of those > compact industrial single-board ones, with a truly blank target disk > and a spare port, running nothing except a custom-written native > application which does nothing except read literal sectors from one > hard disk to another (no OS). This application would be booted from > floppy disk to start the copy process. The required code, if written > in assembler, would be so small that it *could* be verified and > certified by anyone competent to read the source code. > -------------------------- > The code could alternatively be ROM-based. > > So a dedicated tool that does just this job and has no other > function, which is simple enough to explain to the non-technical > would solve this once and for all. > > Michael D. Barwise, BSc, IEng, MIIE, MBCS > Computer Security Awareness > tel +44 (0)1442 266534 > http://www.ComputerSecurityAwareness.com > > Addressing the Human Equation in Information Security > > --------------------- > message from Matt Pepe > > Just a couple of points to note about this problem. First, the issue of > > using EnCase as an imaging solution. Since the "evidence" file created > > (the .enN files) is not a true image, searches against it can not be > > relied upon as being complete or accurate. You are forced to use EnCase or > > restore the image, where other issues come into play. Especially if you > > happen to be working on a unix filesystem. This is true of any proprietary > > imaging file format. Luckly, Guidance has finally incorporated the ability > > to load in raw image files ("dd", for instance). Most forensics *labs* > > stay away from using EnCase as an imaging solution. On the analysis side, > > it's great though. > > > > <opinion tag> > > I vote we lobby Guidance for a tool that can convert their proprietary > > file to a raw image. I have this funny feeling that if they don't offer it > > soon, other forensic processing suites may have the upper hand. </opinion > > tag> > > > > The second point is that Rob is entirely correct. If you have any > > suspicion that your results are not correct or complete, attempt to > > perform the operation with a different set of tools. Do not believe > > marketing material that states that collections of GNU or older (but > > reliable) DOS command line tools are not defensible in court. As long as > > you are familiar with the tools, aware of their shortcomings, and that the > > tools are acceptable (history of use, widely accepted by other experts) in > > this field, you should have few problems. > > > > One question though, Rob. Can you get the Unix port of these tools to run > > on a sterilized version of DOS? If not, the example you gave may have > > just modified your evidence (copy), given your DOS prompt and the fact > > that you are pointing to a physical device that we can only assume is a > > restored image. I'm sure that you could, but it would take a CD, or about > > 12 floppies to load the RAM disk with the libraries. I'm getting > > flashbacks to the 80's when my system didn't have a hard drive.. :) > > > > -- Matt > > > > Quoting "Lee, Robert T." <ROBERT.T.LEE-2at_private>: > > > > > Brandon, > > > > > > Another option may be to compare the results from your Encase search and > > > then run another search using the Unix port of "cat","strings", and > > > "grep" on that filesystem and see if it produces any hits. > > > > > > Example: > > > > > > C:\>cat \\.\PhysicalDrive0 | strings | grep test > > > > > > Or if you have multiple strings put them in a file and run > > > > > > C:\>cat \\.\PhysicalDrive0 | strings | fgrep -f file-with-patterns > > > > > > Or if you do not have the ports of these tools, mount the drive on > > > your > > > favorite Linux flavor or choice and run the same test. > > > > > > Just a thought... I would be interested to see if that produces the > > > hits you are looking for. > > > > > > --Rob > > > > > > > ----------------------------------------------------------------- > > 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 > > > > Michael D. Barwise, BSc, IEng, MIIE, MBCS > 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 -- Fergus Cameron Tel: +447779236010 Fax: +447980681864 ----------------------------------------------------------------- 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 : Thu Mar 21 2002 - 07:31:00 PST