Windows hibernation and BitLocker are two technologies that are quite interesting on their own, and some might say even more interesting (or, frustrating) when combined. A key concept you should be aware of before we continue is that unlocking a BitLocker-protected volume essentially results in encrypted data being decrypted as needed. In other words, unlocking a BitLocker volume does not result in the BitLockered data being decrypted in place, but the decryption of that data in memory and passage “up the stack.” Accordingly, if you are on a live Windows system with its BitLocker volume unlocked and obtain a logical copy of its hibernation file (thereby invoking BitLocker decryption), you will see the hibernation data you expect followed by “junk” which is the result of BitLocker decrypting the remnants of in-file TRIM… but if you obtain a “physical” copy (bypassing BitLocker decryption), you will only see encrypted data.
Many digital forensics practitioners are aware of the impact of what we will refer to as “in-file TRIM” on SSDs (we recommend learning about SSD concepts which include garbage collection and “deterministic read zero after TRIM” (DZAT), if you are not familiar with them already).… for example, what happens to hibernation files when in-file TRIM is run against them. Digital forensics practitioners may not be aware of the nuances of what happens when introducing various BitLocker activities into the mix of hibernation and in-file TRIM.
I’m going to keep this Insights article very brief by relying on the screenshots you are about to see.
Let’s have a screenshot we shared long ago speak for itself:
Remnants of In-File TRIM on BitLocker Volumes
I began writing this article when I realized the screenshot above was not sufficiently accounting for all the situations in which our customers using Hibernation Recon were sending us “broken” or “encrypted” hibernation files.
So, let’s get to it!
Our first situation involves exporting the hibernation (hiberfil.sys) from a live Windows system whose BitLocker-protected volume has been unlocked. We can see the expected hibernation data (essentially just the header, because this is a modern Windows system that has resumed from Fast Boot hibernation and in-file TRIM has occurred) followed by the “junk” data I referred to above which is the result of BitLocker decrypting the zeroed-out remainder.
Logical View of Hiberfil.sys on Unlocked BitLocker Volume
Hibernation Recon Processing Hiberfil.sys from Unlocked BitLocker Volume
Our second situation involves logically exporting the hibernation from a live Windows system whose BitLocker-protected volume has just been fully decrypted. Some might find this next screenshot surprising, in the sense that BitLocker is no longer in play but the “junk” data remains. It appears that during the full BitLocker decryption, the “junk” data has been made official in the sense that it has been committed to the hibernation file on disk.
Logical View of Hiberfil.sys on Fully Decrypted BitLocker Volume
Hibernation Recon Processing Hiberfil.sys Extracted Logically from Fully Decrypted BitLocker Volume
Our third situation involves physically exporting the hibernation from a live Windows system whose BitLocker-protected volume has just been fully decrypted… which confirms our previous finding.
Physical View of Hiberfil.sys on Fully Decrypted BitLocker Volume
Hibernation Recon Processing Hiberfil.sys Extracted Physically from Fully Decrypted BitLocker Volume
Our fourth situation involves exporting the hibernation from a disk image which was obtained after the Windows system, whose BitLocker-protected volume was just fully decrypted, was shutdown. You may find this screenshot the most interesting, as you are now looking at a valid Fast Boot hibernation followed by many gigabytes of the “junk” data. Remember, the “junk” data is the result of BitLocker earlier (possibly, much earlier) decrypting zeroes (in-file TRIM) with a nice salt and then that data being committed to the hibernation on disk (hiberfil.sys) during the full BitLocker decryption. This is one of the situations brought to us by our customers which we felt was worthy of writing this article.
Hiberfil.sys Extracted from Disk Image After BitLocker Volume Fully Decrypted and Windows Shutdown
Hibernation Recon Processing Hiberfil.sys Extracted from Disk Image After BitLocker Volume Fully Decrypted and Windows Shutdown
Finally, our fifth situation involves exporting the hibernation from a live Windows system whose BitLocker-protected volume was fully decrypted, then shutdown, then started up again. All is well in the world of hibernation again, as we see exactly what we would expect if BitLocker had never been in play – the hibernation header which indicates the hiberfil.sys has been used for a resume followed by zeroed-out data per in-file TRIM.
Physical View of Hiberfil.sys after BitLocker Volume Fully Decrypted and Windows Rebooted
Hibernation Recon Processing Hiberfil.sys Extracted Physically from Fully Decrypted BitLocker Volume after Windows Reboot
Here are the MD5 and SHA1 hash values for these various hibernation files which you may find useful as you contemplate their state across various BitLocker actions:
Hash Values of all Hiberfil.sys Files Mentioned in this Insights Article
I hope you enjoyed this Insights article and that you find Windows hibernation and BitLocker as interesting as we do!
Did you know that Arsenal Image Mounter (AIM) makes interacting with BitLocker-protected volumes reliable and efficient? Whether moving between various BitLocker states as a disk image is mounted by AIM in write-temporary mode or fully decrypting BitLocker-protected volumes and saving new disk images, you will find AIM indispensable in your casework. Please keep in mind that AIM’s Professional Mode also has many other powerful and unique features, which include launching virtual machines (even in the most challenging situations) and bypassing Windows authentication within them.