unsupported basic file overlay descriptor file signature?

[KarelDemeyer]

Using vshadowmount fails on an image mounted with ewfmount+bdemount with "libvshadow_ntfs_volume_header_read_file_io_handle: unable to read NTFS volume header data at offset: 254862852096 (0x3b57028000)" The bde1 reports a size of 254862852096 byte (using ls -l "/mnt/1921/001/bde/bde1")

I constructed the following 3 line bfoverlaymount descriptor file named "1921_001_overlay" and placed next to the bfoverlaymount binary:

layer: offset=0 size=254862856192
layer: offset=0 size=254862852096 file="/mnt/1921/001/bde/bde1" file_offset=0
layer: offset=254862855680 size=512 file="/mnt/1921/001/bde/bde1" file_offset=0

This fails as follows:

# ./bfoverlaymount -v 1921_001_overlay /mnt/1921/001/overlay/
bfoverlaymount 20210717

Unable to open source descriptor file
libbfoverlay_descriptor_file_read: unsupported basic file overlay descriptor file signature.
libbfoverlay_descriptor_file_read_file_io_handle: unable to read descriptor file.
libbfoverlay_internal_handle_open_read: unable to read descriptor file.
libbfoverlay_handle_open_file_io_handle: unable to read from file IO handle.
libbfoverlay_handle_open: unable to open handle: 1921_001_overlay.
mount_handle_open: unable to open handle.

Please point me to a description of the needed file signature? Thank you for your numerous open source IT forensics tools.

[joachimmetz]

libbfoverlay_descriptor_file_read: unsupported basic file overlay descriptor file signature.

The first line is missing also see https://github.com/libyal/libbfoverlay/wiki/Examples#overlay-descriptor-file

[joachimmetz]

@KarelDemeyer can you give me some context about the image and how it was made? Is this a volume only image or a full disk image?

[KarelDemeyer]

Okay, re-adding the first line did the trick for mounting. Not getting much further yet but that might again be an issue between the keyboard and the chair. Thanks for the quick replies.

The image is a full disk image which contains:

Device                       Start       End   Sectors   Size Type
.../ewf/ewf1p1      2048    923647    921600   450M Windows recovery environment
.../ewf/ewf1p2    923648   1126399    202752    99M EFI System
.../ewf/ewf1p3   1126400   1159167     32768    16M Microsoft reserved
.../ewf/ewf1p4   1159168 498938176 497779009 237,4G Microsoft basic data
.../ewf/ewf1p5 498939904 500115455   1175552   574M Windows recovery environment

The 4th partition was mounted with bdemount which yields a 254862852096 byte NTFS volume image.

"file" on this results in: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 1159168, dos < 4.0 BootSector (0x80), FAT (1Y bit by descriptor); NTFS, sectors/track 63, sectors 497779008, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 0e4ba73e5ba73b322; contains bootstrap BOOTMGR

vshadowinfo results in:

libvshadow_ntfs_volume_header_read_file_io_handle: unable to read NTFS volume header data at offset: 254862852096 (0x3b57028000).
libvshadow_volume_open_read_ntfs_volume_headers: unable to read backup NTFS volume header.
libvshadow_volume_open_read: unable to read NTFS volume headers.
libvshadow_volume_open_file_io_handle: unable to read from file IO handle.
info_handle_open_input: unable to open input volume.

The image shows VSS's in other forensic tools.

[joachimmetz]

Maybe BDE+NTFS does not include the last sector in the unencrypted volume size. I'll have a look when time permits.

The image shows VSS's in other forensic tools.

1. What makes a tool a "forensic" tool in your perception?
2. Other tools do other things all the time, but does not mean that they are accurate or correct.

[KarelDemeyer]

I encountered this same issue before so that indeed might be the reason. In fact, because I encountered it before I tried to workaround it with bfoverlay to be able to script it.

The other tool I refer to is a commercial forensic suite that in this case identifies different "restore points" for the volume that have valid timestamps and show relevant/readable content.

[joachimmetz]

I encountered this same issue before so that indeed might be the reason.

Same issue as in, in combination with BitLocker ? Or otherwise. The same warning can have many different underlying reasons.

The other tool I refer to is a commercial forensic suite that in this case identifies different "restore points" for the volume that have valid timestamps and show relevant/readable content.

Ah, so no actual independent means of validation here, like a test image?

For the reason why I'm asking is see: https://osdfir.blogspot.com/2020/09/testing-digital-forensic-data.html

[KarelDemeyer]

I did some tests with a few MS Windows images and it seems the combination of bitlocker and vss when using bdemount/vshadowmount result in this issue, as if the volume bdemount yields is missing the last cluster with the NTFS backup volume header. Is this fixable in libbde? Would you like me to file an issue there?

I am using your tools as a way to validate/supplement the results of the commercial tool. Thank you for the link to your valuable blog resource.

I was able to add a workaround in my "mount evidence" workflow using bfoverlaymount:

#size of BDE image
bde_size = os.path.getsize(bde_location)
virt_img_size = bde_size+4096

#write overlay file descriptor
with open(overlay_file_location,'w') as of:
    of.write('# basic file overlay descriptor file\n')
    of.write("layer: offset=0 size={}\n".format(virt_img_size))
    of.write("layer: offset=0 size={} file=\"{}\" file_offset=0\n".format(bde_size,bde_location))
    of.write("layer: offset=-4096 size=4096 file=\"{}\" file_offset=0\n".format(bde_location))

In your example in the libbfoverlay documentation a full cluster is added to the virtual image and only the first sector is layered on the cluster boundary (the next 3 sectors are still filled with 0-byte). In my tests this allows vshadowinfo to list the VSS but doesn't allow to mount the VSS with vshadowmount. Therefor I needed to layer the whole cluster (see above).

Using your different tools (ewfmount/bdemount/vshadowmount) allows me to feel in control and add flexibility in dealing with edge cases. Thank you for the commitment.

[joachimmetz]

thx for doing a deeper dive here.

Is this fixable in libbde?

I would need to take a closer look, might be something BDE+NTFS specific versus BDE-Togo, not sure

I was able to add a workaround in my "mount evidence" workflow using bfoverlaymount:

Excellent, good to hear that the bfoverlay tooling was helpful in overcoming a blocker.

Would you like me to file an issue there?

Keeping this one open as a reminder is fine, I'll might create one later once I took a closer look

[joachimmetz]

Changes in https://github.com/libyal/libbde/commit/ac7bb8586041b69e56e3dbbcbeb0ccb19917c88e