I was wondering if anyone could explain what exactly is happening when Emergency boot is performed.
This is usually used when there is some corruption in the Preboot file system - in order to get in Windows and eventually recreate the PBFS on synchronization.
But what exactly is happening before you login in Windows - how does the DETech skip the corrupted PBA environment?
According to some official documentation provided by McAfee we have the following situation -
"The McAfee Drive Encryption Master Boot Record replaces the standard Master Boot Record (Sector 0 of the boot disk) during activation.
The McAfee Drive Encryption MBR is referred to as the EPEMBR. The control is passed to the EPEMBR following BIOS initialization and the code contained in the EPEMBR is executed. The EPEMBR contains a pointer to the first sector of a sector chain that hosts the BootCode (safeboot.rsv), which is executed straight after the EPEMBR. It also contains a pointer to the first sector of a sector chain of the Drive Encryption file system (Safeboot.fs), which hosts the Windows OS original MBR that is executed after successful authentication.
It is important that the two files (Safeboot.rsv, Safeboot.fs) and the EPEMBR are maintained on the disk and are never moved at a sector level. The files are sector chains and copying the file from one place to another does not work as they are not real files. They appear in this way inside the operating system to prevent it from being moved or overwritten."
So since the PBFS is corrupted (safeboot.fs) the machine cannot boot normally and returns some error. What information is used by the DETech Emergency Boot procedure in order to boot?
As far as I know the partition table is not altered in any way during the DE encryption/activation. So does it use the information in the partition table to find the active boot partition and jump there directly (this information should also be available in the recovery XML file - original MBR backed up there).
When a system is Emergency Booted several things occur:
As you state, the partition table is not altered but the boot process is during the activation process. The MBR is entirely replaced except for the partition table and disk signature. The boot strap in the MBR contains the sector that points to the boot code for the Preboot 16 bit RTOS in the PBFS that which protected by Safeboot.fs and Safeboot.rsv. Those two files are mostly meaningless acting simply as place holders marked as sys files to protect the sectors in which the PBFS exist from modification. Once the system has been booted to preboot and a successful authentication occurs loading the key into the driver, the original Windows MBR and the hardware is passed to the BIOS and the BIOS performs a sector chain to the Windows boot loader which now can be access due to the encryption driver decrypting the disk data stream.
This is just off the top of my head so I may have missed something but this is the basic outline of how it works. This of course is unique to systems booting with Legacy BIOS mode. UEFI works completely different.
Thanks for the information, jhall2.
However I don't clearly understand how the encryption key is passed to the encryption filter driver if the PBA environment is corrupted.
If I am correct it seems that there should be two filtering drivers/mechanisms -
I am not quite sure if you can provide such information here but how the is the initial filtering driver loaded? After some research I found the following statement - "Encryption drivers are usually registered as a lower filter driver for the disk drivers. The encryption driver initializes itself by copying the encryption key used by the INT13 hook function." So is the actual code in the PBA the one that is implementing this?
Additionally would it be possible to provide more details of the operation of the following drivers -
As far as I can see the "MfeEpePC.sys" and "MfeEpeOpal.sys" are registered as "Upper-Level Filter Drivers" on one of my encrypted systems - do these implement the filtering functionality and are they related in some way to the actual boot process?
If we go back to my original post regarding the "Emergency boot" what will happen if we have a corruption in the PBA (and if the code there is responsible for handling the key, implementing hooks, etc) - how it will be able to work with it and boot the machine in Windows to rebuild the PBFS?