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
This archive was generated by hypermail 2b30 : Tue Mar 19 2002 - 07:34:27 PST