Atlas-OS
[BUG REPORT] - Corrupts EFI Partition and Removes Bitlocker Key material
Description
After running on a clean laptop which had Windows 10 Pro installed and bitlocker enabled on the install by the OEM (in this case Microsoft Surface Pro 7 and a Asus ROG G14 Laptop), upon rebooting you're presented with the enter Bitlocker Recovery key screen to be able to decrypt the main drive and continue the boot.
At some point in the process of install, the EFI partition with all the required elements for booting with a Bitlocker encrypted drive are corrupted and the TPM of the machine wiped.
The EFI space is so corrupted that the only way to recover is once the system is up, turn off Bitlocker if you can and then re-enable if required. Which if it is a laptop you require it.
Steps to reproduce (add screenshots if applicable)
See Description.
Expected behavior
And the machine left in a bootable state, that doesn't require you to re-enter the Bitlocker Recovery Key on every reboot.
Actual behavior (add screenshots if applicable)
System unable to boot due to corrupted EFI, TPM wiped and key material for Bitlocker removed from the machine thus preventing normal boot.
In the case of the Microsoft Surface Pro it required the machine to be reinstalled with the OEM image and bitlocker disabled after install install and before Atlas is used.
Atlas Version
Atlas 10 22H2
Desktop information
Asus ROG Zeyphrus G14 Microsoft Surface Pro 7
Requisites
- [X] This is not a support issue or a question. For any support, questions or help, join our Discord server.
- [X] I performed a cursory search of the issue tracker to avoid opening a duplicate issue.
- [X] I checked the documentation to understand that the issue I am reporting is not normal behavior.
- [X] I understand that not filling out this template correctly will lead to the issue being closed.
Additional content
No response
Hi, so I have a feeling, but I'm not 100% sure after I was looking through the playbook yesterday, I think I saw in there some about make a change to the boot loader or something else on the UEFI partition. Basically I think again you guys know you're tool better but if that is the case, in that process it maybe overwrites, or damages some part of the on disk keymaterial, secured bootloader components that used to unlock the disk, in the process, resulting in the first boot after the TPM is wiped as the disk is assumed compromised. Basically, something was done that tripped a Bitlocker countermeasure, as outlined in the list of countermeasures detailed here: https://learn.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-countermeasures
Try the latest release from https://github.com/Atlas-OS/Atlas/actions. Let us know.
Hi, sorry, not had chance to been travelling this last week or so. I'm planning to have a look over this weekend, I've a couple of Surface Pros to mess with..