Matt, >>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.. << I too am eager to see the result's of Rob's method. But I am puzzled by several assertions in your previous post. First of all, I am puzzled by your reference to "DOS" and a "DOS prompt." I, personally, do not admit to being old enough to know what DOS is. But I have heard folks talk about it. I do not recollect them speaking of accessing a physical storage device using Rob's syntax. I am aware of another operating system that does open raw devices using Rob's syntax. But, this operating system has "Command Prompts" and "Console Windows," not DOS prompts. The only operating system that Rob explicitly mentions is Linux. Unlike most versions of Windows, Linux does permit mounting a logical volume in read only mode. But Rob is referring to opening a raw physical device (/dev/hdx), not a logical volume (/dev/hdx1). In this case there is no need to mount the volumes on the device at all. Surely you will concede that Rob's Linux option is a viable alternative even given the current (impoverished) state of technology. The other operating system, which I alluded to above, does mount a logical volume as soon as it is referenced. A logical volume may be referenced implicitly, moreover, for example by opening "My Computer," which references volumes by enumerating them. Once a new logical volume has been discovered, the mount manager attempts to mount the volume using all known file systems. The last file system to be attempted is the "raw" file system, which always succeeds. (Thus, even volumes that contain unsupported file systems like ext2 get "mounted.") Nevertheless, let us assume that Rob did not mount the logical volumes on physical device \\.\PhysicalDrivex (where 'x' refers to a number starting with 1) either implicitly or otherwise. Let us assume also that Rob, being the careful investigator that he is, ran md5sum \\.\PhysicalDrivex both before and after running cat \\.\PhysicalDrivex and that the checksums in both cases were identical to the checksum of the original image. Let us assume further that cat opens \\.\PhysicalDrivex for read only access (which may be verified by viewing line 513 of cat.c (UnxUtils distribution): "int file_open_mode = O_RDONLY;") Let us further assume that the runtime library O_RDONLY flag translates into GENERIC_READ access in the underlying OS (which may be verified by viewing line 243 of open.c in the November 2001 Microsoft SDK: "fileaccess = GENERIC_READ;"). What puzzles me is how the fact that Rob is using a console mode application and that he is pointing the application towards a raw physical device (which has been opened for read only access) will result in modifying the evidence. I can think of many other ways that the evidence may get modified on a running Windows system, e.g. by referencing the logical volumes contained on the physical device. But I am still struggling to understand how the precise scenario that you describe, console application pointing to raw device, will lead to the evidence on the device being changed. Perhaps someone can further explicate this for me. Regards, George. ----------------------------------------------------------------- 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 : Tue Mar 19 2002 - 07:28:09 PST