Mount image of encrypted drive to enter in password

What is encryption?

Is the on-board controller or a special encryption hardware in the target machine asking for the password?

How do you know it is full disk, versus full partition or volume?

It is Becrypt and we have been informed it is full disk encryption and software only.

Thanks.

have you tried restoring it to a physical hdd?

First, some clarification.
The vendor may call it full disk, but it is not - when it comes to primary boot device. Note that this is a non-issue when it comes to any other, non-boot device.

Let us recall what is the boot process at a very high level.

1. BIOS is started from motherboard firmware
2. POST
3. Read sector 0 from boot device
4. sector 0 code (MBR) )executed
5. If exist volume boot code executed (VBR)
6. OS is loaded

[/listo]

If you notice, if all of the drive is encrypted, and there is no firmware to translate the encryption, the BIOS cannot understand the encrypted sector 0.

It is possible that, as many other "full disk encryption" solutions do, Becrypt replaces the MBR with their own version - which is often called the "pre-boot" authentication.

Now, to assist you - in my experience, almost all "full disk" encryption solutions allow you to "slave" a drive to a host machine, which also has the software.

That is, remove the target, encrypted drive, attach it to an other machine (forensic workstation), that happens to have the Becrypt encryption. The drivers for the encryption, & therefore the OS, should recognize the drive and request the PIN, pass or whatever the authentication is. This is how BitLocker, Utimaco, SafeBoot, etc. work.

The method of the physical connection should not matter. You can slap it in a USB caddy, and connect it that way.

Now, since you have an E01 instead of an actual drive, that is a bit of an issue. First, I would make a raw or dd image. This is because a disk en/decryption will not understand the image format - plus it will be faster.
Here is the pain - try various mounting tools to mount the image on a (virtual forensic) machine where the Becrypt is loaded. If my above hunch is correct, one solution will allow Becrypt to recognize the mounted image and prompt you for the authentication.

If you cannot find such solution - clone the E01 to a drive, then attach it as described above.

Good luck and fill us in how it went.

@jhup
To be picky #5 and #6 only apply to "standard" MBR code, a "special" MBR may well behave differently, as an example like the grub4dos MBR does, i.e. execute the grub4dos loader in sectors 2-18.

@randomaccess
Once there is a "dd-like" or RAW image, you need to find a virtual disk software capable of mounting the "whole" disk (as an example IMDISK or the derived OSforensics OFSmount won't probably be of use as they mount only the volume).

You may want to try VMDK (which is not however "as low or possible")
https://sites.google.com/site/chitchatvmback/vdk
in which case you might also need to make a .pln or .vmdk descriptor file with the appropriate geometry
http//www.forensicfocus.com/Forums/viewtopic/p=6518434/#6518434
http//sanbarrow.com/vmdk/disktypes.html
or either among the MS VSS driver
http//reboot.pro/topic/6492-virtual-storage-driver/
or Total Mounter
http//www.kernsafe.com/product/totalmounter.aspx

these two latter ones integrate on a windows NT system at the lowest level possible and allow accessing the whole disk.
Total mounter is also Windows 7 compatible and both 32/64 bit version.

jaclaz

Agreed, and it does not need to be MBR (PXE, RIPL/RPL, NetBoot, for example), this is why I placed it in parenthesis. Still the "special" MBR needs to be unencrypted. Further down I pointed out that the MBR is often replaced by these "full disk encryption" vendors with their own to provide their "pre-boot" authentication.

I made the presumption that the evidence most likely came from a FAT or NTFS system with partitions and volumes. I made this presumption because Becrypt Disk Protect only runs on Windows (XP, 7, Servers 2003 & 2008).

Irrelevant of the the solution or what is called (MBR or not), the first set of bytes read from the device must not be encrypted, and must be executable by the CPU. That is what I was trying to get across.

This is also why I asked if there was hardware/firmware. You can do full disk encryption, but there must be some code to decrypt it. To get the part that is decrypting the rest of the drive it must come from somewhere unencrypted/decrypted to the CPU.

[rabbit hole]
I can imagine a full disk encryption with a PXE-like stub of sorts for example.

The device drivers and decryption code is downloaded each and every time from the (TFTP) server, possibly providing some additional authentication to it too.

The code would assist on the decryption of the drive and continue from thereon the boot process.
[/rabbit hole]

[rabbit hole]
I can imagine a full disk encryption with a PXE-like stub of sorts for example.

The device drivers and decryption code is downloaded each and every time from the (TFTP) server, possibly providing some additional authentication to it too.

The code would assist on the decryption of the drive and continue from thereon the boot process.
[/rabbit hole]

[deeper rabbit hole] 😯
I can imagine a full disk encryption that only decodes if an inbuilt GPS device is providing the correct geolocalization (out of a list of set "allowed" places) AND that initiates self destruction if the geolocalization provides data in a 100 m radius from any place in a blacklist (digital forensics laboratories, Police buildings, Government buildings, etc.) or if the gps device is not connected.

[/deeper rabbit hole]

P

jaclaz

Hmmm… I can see those devices self destructing as soon as they are taken inside, deeper recesses of a building mrgreen

But, I like it. How about hermetically sealed case with some alkali metals backed inside? Opening the case would work only under a liquid bath or such. Have to still figure out the cooling though…