Volume-as-a-file in data source not identified

Autopsy Help
1

Autopsy 4.19.3 running on Windows 10.

I’ve add a data source to my case.

At least one of the files in that data source is (I think) an image of a volume, i.e. a raw “dd” image. The file utility identifies it as:
Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=...

Autopsy doesn’t seem to be able to detect it as a volume containing a file system, the MIME Type is shown as:
application/octet-stream

I can manually add the file as a data source and Autopsy processes it just fine (i.e. correctly parses the file system).

My questions are:

  1. Am I doing it wrong? Would Autopsy be expected to identify this file as a volume?
  2. Is there a module that would help?

:zap: My concern is that I might be missing other such files in the original data source.

Thanks!

2

Autopsy will not identify files as being part of a file system using file type identifier. If you are looking for virtual machine files you can run that ingest module but to just search files that could have a File system Autopay does not do. You could write a plugin that will do that though.

3

Thanks for the comments @Mark_McKinnon.

Although I will almost certainly end up writing a plugin, I wanted to try some more native things.

I added a Custom MIME Type (Tools → Options → File Types), entering the signature (in hex) and the offset of that signature from the start (in decimal).

However, if I run the File Type Identification module (right-click data source → Run Ingest Modules) the MIME type of my volume-as-a-file does not get updated to my custom MIME type - it remains application/octet-stream.

I understand my custom MIME type should take precedence, so do I need to do anything particular to “refresh” the MIME type?

I couldn’t spot anything in the log to help.

4

Can you post what the custom mime type was that you created as well as a sample file?

5

The files in question (ext2, volume-as-a-file) are trivial to make:

$ dd if=/dev/zero of=1GB.bin bs=10M count=100  # Create a 1G file
$ mkfs.ext2 1GB.bin  # Create the ext2 file system
# Let's validate...
$ file 1GB.bin  # Check the file "magic"
1GB.bin: Linux rev 1.0 ext2 filesystem data, UUID=bb... (large files)

The “magic” used by the file command can be seen on github:

# ext2/ext3 filesystems - Andreas Dilger <adilger@dilger.ca>
# ext4 filesystem - Eric Sandeen <sandeen@sandeen.net>
# volume label and UUID Russell Coker
# https://etbe.coker.com.au/2008/07/08/label-vs-uuid-vs-device/
0x438   leshort         0xEF53          Linux
>0x44c  lelong          x               rev %d
>0x43e  leshort         x               \b.%d

So, a simple signature could be defined as: “little-endian 0xEF53 at offset 0x438”, which can be seen in my demo file:

$ xxd 1GB.bin | grep -m1 "^00000430:"
00000430: 045b ac63 0000 ffff 53ef 0100 0100 0000  .[.c....S.......
                              ^^^^

Because I wasn’t sure how Autopsy deals with endian-ness in the signatures, I defined two MIME types:

20221228_autopsy
20221228_autopsy1397×528 47.7 KB

(1080d == 438h)

However, even after rerunning the File Identification module, as can be seen from the “MIME Type” column, the file remains application/octet-stream when I’d expect it to be application/x-filesystem-ext2-[AB].

6

I was able to get it to work and this is what I did.

image

image

I also created an interesting file rule and it showed up there as well. Did you just try and rerun the file type id again after creating the new mimetype? Autopsy will not go back and check files that already have their mime type identified. Try creating a new case and adding the same data source to it and running File Type Id and see if it now works.

7

That’s solved it! Thanks @Mark_McKinnon!

I was assuming (always dangerous), that by rerunning the File Type Identification module, Autopsy would recheck, but, as you say, evidently not.

Adding a new data source or creating a new case, and then running the File Type Identification module, the files were assigned the expected MIME type :+1: