OSFMount question

[SupaSpy]

Hi All,

I had an IT member in another country capture an image of a laptop HDD utilizing OSForensics. I noticed when I received the .AFF file, there was an .INFO file and Drivers folder attached (3 files instead of 1). Is this something new? Normally, I would just receive an .AFF file that could be easily mounted. I attempted to mount the .AFF file and it showed "N/A" as the file system type. Normally, it would say "NTFS". Maybe the image was not copied correctly? Any help would be appreciated. I have been using OSF for about a year now and feel comfortable with my knowledge of it's operations. Thanks again.

[David (PassMark)]

My guess would be that the image was made with OSFClone. This tool creates an INFO file. This is a text file with details of the image. The file content normally looks something like this,

===================
Image source: /dev/sdc
Image file name: iou.img
Image file size: 1977614336
Image created on Nov 2, 2010 8:29:16

Checksum method: md5
Checksum source( /dev/sdc ): 21b30b7d241985c3510124fdc0deded7
Checksum image ( iou.img ): 21b30b7d241985c3510124fdc0deded7

Case #: 34278
Evidence #: 239847
Examiner Name: Richard
Description: UFD stick, nothing special
Location/Place: Redwood City, CA
===================

As for the drivers folder, we aren't sure. It certainly isn't required in order to use the image. We suspect it might be part of the Linux operating system that was incorrectly included.

As for why the image doesn't mount. Does the AFF file look about the right size? You should be able to check the hash from the INFO file. Was it an NTFS file system to start with? Did it have any partitions that you know about? After mounting it (and it not finding a NTFS file system), can you use the raw disk viewer in OSF to view to first few sectors, and see what data is in the image.

[SupaSpy]

On closer inspection of the INF file, the MD5 hashes are missing. There is a message that sates the MD5 information can be obtained in the AFF file.

The AFF file size is 20.4 GB, but when trying to mount the needed partition, the size is 24.41 GB-NTFS or HPFS. Once mounted, the image says "24.41 GB Read/Write File System N/A.

I am unable to chek the raw disk image for the mounted drive as the OSF program says (Not Responding) after 10 minutes of waiting.

[David (PassMark)]

I had forgotten about the MD5 thing. For AFF images the MD5 is stored in internal meta data. Because there is compression of the image, taking a hash of the AFF image file will not match the internal MD5 value that corresponds to the MD5 of the unpacked data.

What you can do however is to go to the http://afflib.org/ site and get the afinfo tool. There is a pre-compiled Windows Executable available.

Using the afinfo tool you can check the hash value and dump out a lot of other data about the AFF image.

Also in both the OSFmount and afflib tools, you should be able to covert the image back to a straight dd raw image. Might be worth doing to see if it is a general AFF image mounting problem, or a problem just with this particular image.

Was it an NTFS file system to start with? Did it have any partitions that you know about?

The AFF file format has some serious performance issues (by this I mean all implementations of it, not just with OSF). In general dd is much better from a performance point of view.

So,
1) Check the image with afinfo.
2) Try conversion to raw dd image.
3) Get back to us. We might be able to get a copy of the image and investigate further.

[SupaSpy]

Thanks. I will try that later today. I let the OSF program continue in the "Not Responding" mode for about 45 minutes and was able to see the raw disc image for a minute. It said that the NTLDR was missing and then the OSF program crashed, citing a Visual C++ "assertion error".

[SupaSpy]

Sorry, yes this is an NTFS file system with 2 partitions. I wasn't aware that the OSFMount could convert the AFF to a raw disk image. Is there a guide or something similar?

[David (PassMark)]

Should be able to convert the image from the OSFMount Menu,
Drive Actions / Save to Image file.

We'll have a look at the crash.

[David (PassMark)]

We just tested making and mounting a ~20GB AFF image here. But didn't see any problem. We are suspecting a messed up MFT at this point. But it is only a guess.

We are thinking it might be a slow process to investigate the crash without being able to reproduce it here. If there any chance we could get access to the image. Could do a NDA if required.

[SupaSpy]

Thanks for your help. I think the issue was with the capture. A fresh image has been completed and I am currently indexing after a positive mount. So far so good.