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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]