Lost data on a mounted drive

[Dana Kerdesky]

Hello all, 

I was using BitCurator for the first time on an old Mac. I was attempting to mount and browse an exFat-formatted hard drive full of E01 files we had created for us by a vendor. Using the Step-by-step guide, I mounted one of the drives unsuccessfully, unmounted it, and then attempted another using the same steps. The second was also unsuccessful. When I attempted to go back to select a third file, everything was gone, the entirety of a 16TB drive. I checked to see if an additional partition was made or something, but there was no indication that the data was on the drive at all. 

Has anyone experienced something like this or have any idea where I could have gone wrong? 

I will note that I was not using a write blocker at the time, which will NOT happen again. With this inquiry, I am more interested in learning what could have led to such a massive data loss without prompting.

Any insight is greatly appreciated, 

Dana Kerdesky 

[Kam Woods]

A bit of potentially relevant background: Ubuntu 18.04LTS has not had exFAT support until quite recently (due to exFAT being proprietary and not fully supported in the mainline kernel until 5.4) and even in recent BitCurator releases (2.2.12 and up) that are based on Ubuntu 18.04.5 with the 5.4 kernel, it may be required to install the exfat-fuse and exfat-utils before exFAT drives can be read. I'd need to test to be sure.

That said: if you plugged in an exFAT drive via USB *without* updating the kernel or installing these packages, and attempted to mount it, Ubuntu would typically pop up a dialog that said "Unable to access USB" followed by some addition information about the specific device, and would not allow you to read anything from it. Since it appears you were able to mount the physical drive, it's possible that the drive was incorrectly formatted to begin with, or was somehow recognized as a regular FAT drive. It's not easy to say without additional info on the specific version of Ubuntu (BitCurator) that was being used, whether any updates had been applied to it, and how the drive was physically plugged in and mounted.

Acknowledging that data recovery procedures were *not* the question you posed here, it's unlikely that your data is actually lost (overwritten), but rather that the information that describes the file system on the disk is in an inconsistent state or damaged. A potential recovery procedure would be to make a sector-by-sector (raw) copy of the drive to an identical 16TB drive, and run an exFAT file system repair (or in the worst case, a file carving tool) on that.

Kam

--
You received this message because you are subscribed to the Google Groups "BitCurator Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcurator-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/90b39604-be5e-4d39-91fe-87f2909642f3n%40googlegroups.com.

[Dana Kerdesky]

Kam, 

 

Thank you- all of this is super helpful. 

For added context, I did install the exfat-fuse and exfat-utils after the first attempt to mount the drives was unsuccessful. Mounting the individual E01s after that is where I ran into the issue. 

And thank you for adding the bit about recovery- my instinct is that the data was hidden or unreadable somehow rather than overwritten. Thankfully, we've got some support in that effort, so I'll find out soon. 

Dana 

[Kam Woods]

Noted, and a short follow up that may or may not be helpful. When you right-click on an E01 disk image and select the mount script, the system does exactly one thing - it calls a script called "fmount" with sudo privileges. This script (which you can see at https://github.com/BitCurator/bitcurator-distro-salt/blob/master/bitcurator/env/usr/local/bin/fmount) uses functionality from sleuthkit, xmount, and pytsk to attempt to find mountable volumes within the image. Any correctly identified volumes are then mounted in independent locations under /media on the boot volume.

There are two potentially relevant things here. First, the script itself *should* never write to the source disc that contains the individual E01 image files (unless that disk happens to be the boot drive where the mount is being created), so if that disk becomes unreadable I'd suspect it's unrelated to the attempts to mount the E01 files. I can try to do some additional testing to verify this explicitly with an exFAT USB drive (if only to determine whether there are potential changes required). Second, if the E01 files failed to mount, it's usually one of two issues: either the E01 file was created using a version of the EWF format that libewf cannot read, or the E01 file does not contain any volumes that can be recognized by the system. I could provide more detail with information about which tool was used to create the E01 files, and what type of disks (physical and file system format) they were created from.

BitCurator includes a range of command-line tools that can be used to poke around inside E01 files to determine what the partition layout looks like, particularly if the automated script fails, and potentially allow you to mount specific volumes the script may not have found. There are many guides online that describe how to do this, but one (with an example of specific mount commands for Windows volumes) can be found here: https://dfirmadness.com/mounting-case001-e01-files/

Kam

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/067cb34f-1700-4b8f-86ff-f0586ab033b7n%40googlegroups.com.

[dana kerdesky]

This brings me to another issue I've encountered, which is what brought me to BitCurator in the first place. Now reading through this thread, I think it may be relevant to add to see if I overlooked anything or need to add anything further (similar to the exfat-fuse exfat-utils install). 

The drives that contain the E01 files are exFAT drives, but the E01 images were made from hard drives that contain almost all HFS and HFS+ filesystems. So, when I started off mounting and browsing the E01 files, Icould use FTK Imager with an HFS+ tool that could read those filesystems. The problem is, anything that is older than HFS+ is only mounting at about a 50% success rate. I have seen that BitCurator has an HFSExporer application. Do I need to open or add that application manually before attempting to mount the E01s in the future? Could this have had an impact on what happened during mounting in my original inquiry? 

Thanks again!

[Kam Woods]

The complete answer to this is somewhat involved, and there are others on-list who have more expertise than I do. But the short version is that read-only mounting of HFS+ is supported in Ubuntu, and HFS+ is supported in sleuthkit, but HFS is not in either case. For HFS+, the ability to mount and read depends on the specific version and configuration of the HFS+ volume. Recent BitCurator releases ship with variants of tsk 4, which has improved functionality for analyzing HFS+ drives over earlier releases (see https://wiki.sleuthkit.org/index.php?title=HFS for a slightly more in-depth explanation). This allows the analysis tools to parse them, but actually mounting the image may require manually exporting the raw image and passing the hfsplus type flag to the mount command (rather than using the automated helper script). It's been a few years since I looked at this, I'd have to go back and check.

For HFS volumes, BitCurator includes the hfsprogs package and (as you noted) HFSExplorer, which can open raw disk image files and parse the volume. The simplest way to start using that tool is to use the ewfexport command line utility to export a raw disk image from the E01 file, as HFSExplorer cannot introspect into E01 files. This approach is decent if you simply need to copy files out of the disk, but my understanding is that there are certain HFS volumes that HFSExplorer will not read. You may also wish to search old posts to this and the digital-curation lists, as I recall there have been some in-depth discussions of these issues before.

Kam

To view this discussion on the web visit https://groups.google.com/d/msgid/bitcurator-users/e8866f53-c67a-4424-8ad3-f602ad931a3cn%40googlegroups.com.