OSFMount and very large E01 images?

[LordMike]

Hi. I discovered OSFMount today, and I'm quite pleased. It seems to work great, as I've had some issues mounting E01 images using FTK Imager.

I have an E01 image of a 6 TB drive, and when I mount it - it appears as a 5.5 TB device, but R-Studio (recovery tool) detects it as a 1.46 TB device.
When I read beyond the 1.46 TB point, it fails reading.

Does OSFMount have a limit to its sizes?

Mike.

[David (PassMark)]

No limit that we are aware of (except the file system limits, which for example, for FAT32 is 2TB).

Can other tools like OSForensics use the image?
If using OSForensics, you don't need to mount the E01 to a drive letter, you can just read the E01 file directly and remove a layer translation code.

How big is the E01 file itself?

[LordMike]

The E01 is a 5.240.676.355.521 byte file, or 5.24 TB / 4.76 TiB.
When opened in OSFMount (which also takes a while - but FTK does this too, so that's probably just E01 for me)..

In picture 1, we can see it detects partitions, one of which is 5.45 TB. The disk i GPT partitioned. In step 4, I choose defaults, and then I mount it.

In picture 2, it's been mounted and browsed in R-Studio. R-Studio indicates its size (top right) as 1.46 TB. It does however, see a partition sized 5.45 TB - but when I browse this partition in R-Studios hex editor, and move towards the end, I get the error output shown below the listing. It basically reports back "Parameter is incorrect" for each sector being read.

I'm not sure if OSForensics can open it, as I've never used that tool before ..

FTK Imager, however, can. It can open it, and mount it (I was able to browse the partition after I wrote the first post). It successfully lets me browse the end of the image.

OSFMount also successfully shows the first part of the disk. According to R-Studio, it's reported as 1.46 TB, or 3.131.110.576 Sectors. If I browse to that offset, I begin getting errors. Until then, it seems to work fine. When mounted with FTK, it is 11.721.045.168 Sectors long instead.

[David (PassMark)]

If the error just appears with R-Studio we aren't in a position to debug it.
If possible can you test with OSForensics to see if you can read to the end of the E01 image (or really any other tool to start with to narrow down the problem).

[Vald]

I can confirm the issue with large E01 images.
On the pictures below you can see two "physically" mounted disk images (4TB and 3TB) which are recognized by Windows as 1678,02 GB and 746,52 GB harddisks respectively.
They are part of RAID6 set so RAW/unallocated space is generally fine.

Disk images were taken with Guymager (3TB) and FTK Imager (4TB) with best compression option, got nearly the same effect.

[keith]

Thanks for letting us know. We suspect it may be related to issues we found related to Encase images.

If possible, can you use our OSForensics tool (which we have made fixes to reading Encase images) and see if you can load the large Encase images.

https://www.osforensics.com/download.html



If we can confirm it works OK, we can apply the same fix to OSFMount.

[Vald]

The OSForensics v8 loads my images and I can verify them successfully.
However, I see no entries in RAW disk browser and cannot browse files (which seems logical as my images contain no partitions except split 16TB GPT from ofiginal 8-disk raidset).

Are there any requirements to the test image and specific actions to check for me in OSF?

[David (PassMark)]

Yes, if you only have 1 disk from the 8 disk RAID set, you won't be able to browse the files.

There is an option in OSF to merge RAID disks into a single volume. But in this case you'll need a lot of free disk space to write the merged output file.

We'll put out a patch release for OSFMount next week.

[keith]

However, I see no entries in RAW disk browser and cannot browse files (which seems logical as my images contain no partitions except split 16TB GPT from ofiginal 8-disk raidset).

If you select the image in Raw Disk Viewer and select Disk Info, you can verify whether the total sectors and size of the disk is correct.

Are there any requirements to the test image and specific actions to check for me in OSF?

In the Verify / Create Hash module, you can calculate the disk hash to verify the integrity of the disk (if you have the hash of the original disk stored somewhere).

However, since the disk is large it might take a while to complete.

[Vald]

Thank you for your replies.
I'm not exactly getting the correct sequence of my actions to execute RAW and Verify functions on my images.

If I got the idea correctly, the "Add device" function does not open any images inside the OSF to be used by internal tools, it just collects evidence.
So, I should mount my images with OSFMount supplied with OSF to use "RAW disk browser" and "Verify|Create Hash" option.

But. The version of OSFMount supplied with latest available OSF is 3.0.1005 while standalone OSFM version with mount issues is 3.0.1006.
The OSF binary version is 8.0.1005.0.

Will earlier version of OSFM inside OSF be helpful to check for the new fixes you mentioned, or I missed something in the middle (like an updated/beta version of OSF)?

[keith]

If I got the idea correctly, the "Add device" function does not open any images inside the OSF to be used by internal tools, it just collects evidence.

'Add Device' will open the image in OSF. Once added, you can analyze the image like any drive within OSF (but not in Windows).

Mounting the image using OSFMount will make the drive available in Windows (ie. using the drive letter). This drive can be analyzed in OSF, but can also be used as any other drive in Windows.

The reason for adding the device in OSF to confirm whether or not the Encase image opens properly, is that OSF builds are updated more often than in OSFMount.
So if we can confirm that it opens properly in OSF, then the fix for OSFMount is simply to release a new build with updated Encase code.

On the other hand, if it fails to load properly in OSF as well, we need to debug further.

Will earlier version of OSFM inside OSF be helpful to check for the new fixes you mentioned, or I missed something in the middle (like an updated/beta version of OSF)?

No, OSF and OSFMount are separate applications and may not have the same code for reading Encase images. OSF will always have the most updated code for reading Encase images.

[Vald]

OK, I added 5 images which I made so far as "entire disks" and none of them is available in RAW disk viewer. Image checksum verification passses succesfully in "Manage case" tool.

[keith]

OK, I added 5 images which I made so far as "entire disks" and none of them is available in RAW disk viewer.

Are you running OSF with administrative privileges?
The above may happen if you run without admin rights.

What also might help is running in Debug Mode and uploading a copy of the log file.
OSForensics - Tutorial - Running in Debug Mode

[Vald]

In elevated UAC mode I see all my images and RAW disk browser shows correct disk size for each image.

"Verify/Create Hash" passed on first disk, I'll check the rest in a few days.

[Vald]

Finaly, all five Encase images passed checksum validation in OSF via "Verify/Create Hash".
All good.