George,

>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.
>
  No sweat. Remember that just because your tool opens a device as
read-only does not mean that the operating system will do the same. As
you are quoting source code from the Devloper Kit, this should be
apparent.

>
> 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.

 I am not sure if you are kidding here or not. Here is what his command
line looked like:

C:\>cat \\.\PhysicalDrive0 | strings | grep test

The C:\ prompt is indicative of a DOS, or NT/2000 command shell
environment. Note that the command line is made up of Unix-like
commands. There are a few products on the market that will emulate the
Unix environment - enough so that a small subset of Unix utilities may
execute under Win32. These suites also come with libraries that provide
the Unix utilities the ability to interact with hardware, filesystems, etc
through the Win32 API.

> 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.

Remember that commands passed to each executable need not make
sense in the context of the operating system. Looking back at the
command line in question:

C:\>cat \\.\PhysicalDrive0 | strings | grep test

The "cat" command is passed the argument "\\.\PhysicalDrive0". This
argument is handled entirely by the "cat" command and the libraries it is
compiled to refer to for core functionality of the Unix tools suite. For all we
care, the command to point to the the *physical* hard drive may be
"\\FuzzySuperBunny". I am not sure if you are attempting to make a
distinction between "physical device" and "raw device" with your
statement. That aside, the utilities I am familiar with that use similar
syntax run under an NT/2k command shell. More on that in a second.

> > The only operating system that Rob explicitly mentions is Linux.
<snipped for brevity>

Linux is used on a regular basis (and has been for many years) for
forensic analysis of many filesystems, including NTFS because the
behavior of the filesystem drivers can be controlled.

> 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.")

And therin lies the problem. The operating system family that you seem to
be referring to, Winnt/2k, will mount familiar filesystems, without operator
control. In fact, there is no way to prevent this from occuring under a
forensic processing situation. Remember that we are processing things
under a forensic investigation, we aren't computer security guys checking
for unauthorized software, or some other random issue ( which in reality
may warrant a forensically sound review).

<other code snippets deleted>
Yes, you make an excellent point that opening a file or device with the
read only flag in fact opens it in a read only manner.
Like you pointed out earlier in your post, the Operating System will get to it
before you do. Just because you didn't personally change the filesystem's
mount flag and last integrity check flag doesn't mean it didn't happen.

Many things were assumed by me in the post, based off of observations
of the thread, for example Rob said:

>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

This implies that the forensic image had been restored to another piece
of media. Rob is stating that he has these Unix tools available to him. The
Unix tools that I was referring to run under an NT/2K command shell.
When processing evidence (looking at restored volumes) under a
Microsoft operating system, it is done using slightly modified versions of
Dos 6.22 or 7.0 (from Win98, for VFAT and large filesystem support)

The original poster mentioned that it was an NTFS formatted drive. As you
pointed out George, Window systems that can identify an NTFS volume
will mount the volumes at boot time. This in unacceptable, as the volume
is modified when it is mounted.

Check out Rob's response. He posted good solutions.

Rob : Item 5 there is new to me - When did Restorer2000 come out?

- Matt

-----------------------------------------------------------------
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 ]