Emergency boot - Inner workings

[georgi_ar]

Hello all,

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).

Thank you.

[jhall2]

When a system is Emergency Booted several things occur:

• The key in the Recovery XML is passed to the encryption driver rather than the key being pulled from the user in the PBFS. Because the system is authenticated with the XML rather than a user, there is no user loaded and no password changes will be synced to the PBFS during this boot.
• The MBR is replaced with a copy correcting any corruption of the MBR. Both the original MBR and MDE MBR are stored in the Recovery XML in most cases however the disk will be scanned looking for the copies stored in the PBFS. This is because if you export an old key there is no MBR information in the Recovery XML.
• A flag is set to inform the Windows MDE software that the system is in recovery mode
• Once booted to Windows, upon the next ASCI the system will reactivate downloading all of the users from ePO and rebuild the PBFS.

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.

[georgi_ar]

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 -

•      DE PBA code that should hook the INT 13H interrupt and use the key (either obtained from the user or from the XML) in order to allow transparent disk access and eventually proceed with the next steps of the boot process. This way it can access critical system files that lie within the encrypted area of the disk.
•      Encryption disk filter driver that should provide transparency for the regular file operations once the system is booted in Windows.

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 -

Mfeccde.sys

MfeEpePC.sys

MfeEpeOpal.sys

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?

[McDuff]

Nice informative thread, thank you