On Mon, Jul 02, 2001 at 04:37:28PM -0400, Rob Quinn wrote: > TODO: (for someone else): > Change a partition table with "fdisk" and test under Linux, and a DOS or > Windows only tool. Like Encase? This would be interesting, especially against an IDE disk which is advertised much smaller in the BIOS. > > Yes, they do have disklabels on disks containing *BSD-filesystems, > > no they will not automatically superimpose these on foreign disks, > > at least the *BSDs will not. > I didn't say the system writes (superimposes) the auto-generated > disklabel to the disk, only that it uses (interposes) this disklabel > to interpret the disk. Ah, then I misunderstood you, I thought you meant that a image of a disk always contains a disklabel, even when the original disk did not, which is of course incorrect. Yes, the disklabel is the datastructure used in the kernel to describe the geometry of the disk (bytes per sector, number of sectors/track, number of tracks etc) and partition information. For forensics, the most important value that is deduced from the geometry values in the disklabel is the maximum adressable sector, i.e. the size. The real question then becomes how these geometry values are determined and put into the _kernels_ disklabel structure. For OpenBSD, the following sequence is used: Get the systems notion of the geometry in the disklabel kernel structure For SCSI this is straightforward. For ATA this is messier. If the BIOS contains usable information, these values are used. If no or no usable information is available for the geometry values as reported by the disk are used. Using this geometry (which is not likely to differ w.r.t. the first few sectors), get the disklabel written on the disk. If one is available (i.e. it is a *BSD-native disk), its geometry and partition information is used for the kernel disklabel. If no disklabel is available on the disk, the information on the "foreign" filesystem is put in the _partition_ information, no geometry information is used (heck, none is available in a FAT32-partition table). For a Windows system on an ATA disk in an i386 system, this means that the geometry used by a *BSD is derived from the BIOS settings if available and from the disk itself if not. For what it is worth, the Windows system itself can only use the BIOS settings. This is why I contend that a 'dd if=/dev/rwd0c of=/some_image_file' is will capture all data that was accessable by the original system. > What is a raw disk? You're using the "raw disk" the OS presents to > you. The OS presents the disk to you after dividing it up according > to the disklabel, which is on the disk. Only with disks that contain a disklabel, i.e. BSD-native filesystems like FFS/UFS. Even then, the same principle holds: if the disklabel describes a geometry that is much smaller then the disk is, the native system cannot access it either. This is just like changing the BIOS settings to some lower number or for that matter using one of the newer ATA disks with configurable limitations on maximal accessable addresses. I elided your interesting tests with NetBSD and Solaris on systems with a too small disklabel written to disk. Again, this is on native *BSD- style systems, that cannot access the remaining data in normal use either. > I did not say the data blocks were ever changed by the OS. I said you > are not necessarily getting all of the datablocks. I said when you > go back and md5 checksum these blocks, they will still be seeing the > same set of (limited) datablocks, which will still have the same > checkum. md5 checksums do not prove you copied the entire disk, they > only show that the part you did copy hasn't changed from the > original. We are in agreement here, that is why I remarked 'completeness is provided by dd+rawdisk'. The MD5 provides proof of integrity of the image _after_ it has been taken, it provides no proof that the image is complete nor does it prove that the original disk was not tampered with prior to taking the image. These issues are solved with procedures. To approach the same problem from another side: Let's assume you have a device/piece of software that (attempts) to read all sectors by enumerating them. It reads the number of cylinders, heads, sectors etc, iterates over the them and writes each sector to an image file. Disregarding the new configurable disklimits, this is arguably the most complete image of the disk possible without vendor proprietary information or a cleanroom. You already missed any service tracks and automatically relocated bad sectors. This image will need to be interpreted (its filesystems scoured for incriminating evidence), so you will need to access the sectors in the image in the same order the original system did. This means you need to be able to recreate the adress translation done by the system, which seems to me like a tedious problem with all the slightly different schemes out there. You can also delegate this task to the original host system and use its translation, but then you are trusting it to provide a complete view of the disk. Where are you going to stop trusting it? BIOS settings? Any specific disk drivers (all those "BIOS limit" workarounds)? The OSes drivers? With kind regards, Wouter Slegers ----------------------------------------------------------------- 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 Jul 05 2001 - 09:42:51 PDT