Last Updated on August 17, 2022 by rudyooms
In this blog, I will try to explain the Technical flow behind the Push Button Reset. I was intrigued to do so after writing my blog about the lingering user files in your Windows.Old folder. Hopefully, you could tell me what’s safer after reading this blog. Is it safer to perform a remote wipe on a BitLocker encrypted device when it gets stolen or just leave it be?
While performing multiple resets and gazing at the “Resetting this Pc” screen, I began to wonder what really happens behind the curtains. So let’s find out!
I will divide this blog into multiple parts
- Where to find those events
- The 5 Phases
- What happens during those phases
- Something… bad … again?
- Looking at the MS-Docs
When searching for more information about this wonderful topic, I spend some time reading these MS Docs
When looking at the last link above, you could have noticed a sort of technical flow in it, telling you what happens when performing a Push Button Reset (PBR)
Looking at all of those steps above… “if requested by the user“… I am wondering how a remote wipe is handling those requests. So I was again intrigued to dig further
2. Where to find those events?
But how are we getting a better look at what’s happening? Because when performing a Remote Wipe it could be hard to log everything that was happening during the reset. Luckily when you have performed a remote wipe on a device, a nice hidden folder will be left on the device. When opening the $Sysreset folder in the root, you will stumble upon a folder with the name: Logs… I guess we know what’s in it!
The file you are looking for would be the SetupAct log. I will guide you through this log file and what’s happening on the device. Also on the same screenshot above, a nice ETL file is also in that same folder. You could use the WPA tool to check it out.
3. The 5 most important Phases
When trying to interpret that Setupact log file, you could notice there are in total 13 Phases!
I will explain the 5 most Important Phases in it. Downlevel, Pre-Finalize, Finalize, End and after a reboot, it will start with the SafeOS Phase. In this blog, I am only explaining the first 4, because I was just curious when the “wipe” would occur and when the Bitlocker protection was removed.
Of course, there is a lot more happening during these phases but I choose to pick out the most important ones because I guess you are not interested if the pagefile is enabled yes or no.
4. What’s happening during those 4 phases
As told before, I am only showing you the background info for what’s happening during the “resetting this pc” screen
So the SafeOS Phase isn’t going to be a part of it. After the device is done resetting the pc it will reboot and start the SafeOS phase aka Installing Windows phase
I could just throw the whole setupact.log in this blog and be done with it, but I am trying to keep it a little bit light. I will divide this part into 4 subparts.
4.1 Down Level
In my opinion, this phase is all about reconstructing the NewOS, but before I am going to show you what’s happening during this phase, let’s take a look at Bitlocker action and some archiving operations first.
When the device reboots after receiving the Wipe command it will keep Bitlocker enabled because WinRE is trusted by BitLocker on OS, so there is no need to suspend Bitlocker on OS
Of course, I tried to stop the reset process at all different times at different stages to check out Bitlocker. Luckily at each try, Bitlocker was still enabled and I needed to enter my recovery key to unlock it! As it should be!
Archiving the OldOS
Now we are pretty sure Bitlocker is keeping our data safe, let’s find out what happens next. After the BitLocker check, all of the old (not necessary data) will be moved to the c:\$sysreset\OldOS folder. Of course, the most important folders are exceptions! As shown below they will NOT be moved at this moment.
After the archive operation, a new copy of the Os is going to be constructed in a temporary location: c:\$windows.~BT\NewOs
Looking at this step, this reconstruction will take most of the time. With all of the tests, I have done this step took about 9 a 10 minutes.
As mentioned before, there are more operations that need to be executed in this phase, so let’s take a look at a brief summary of what else is happening.
This small Driver phase is all about injecting some drivers into the NewOS
Looking at the timestamps, on my test devices, this process was done within a minute but then again, my test environments are mostly clean installed virtual machines.
In this third phase, we will be moving some data back and forth. Looking at my last blog about the lingering user data, I was really intrigued with this phase!
Looking at all the steps in this phase, this is the part in which the data will be moved.
But before it will relocate OS from c:\$windows.~BT\NewOS to the root it will first “MOVE” the old data to the c:\Windows.old folder
I wiped a lot of VMs to exactly pinpoint the percentage when the move was going to happen.
At that exact time, after those folders were moved, I pressed the shutdown button to take a look at the contents of the Hard Disk itself. As shown below, just like I showed you above, all of the old folders are moved to the c:\windows.old folder!
Again… moved… Not deleted! but moved!
“The Windows volume is never formatted, as the files needed to rebuild the OS are on it. Instead, user data files are deleted individually“
As stated here in the MS-Docs:
Please Note: Bitlocker is still enabled at this point! Leave Bitlocker, untouched!
After it moved all the old data to Windows.old folder it’s now time to move the nice newly constructed NewOS folder back to the root!
4.4 The End
Almost done now, but we still need to do some cleanup before we can reboot the device to start the SafeOS Phase. Do you remember the not necessary data that was moved to the $sysreset\OldOs folder? We still need to remove it! As shown below, the DeleteUserData operation will make sure the OldOS folder is cleaned!
But we are not done yet, because we also have some important stuff that needs to be deleted from the windows.old folder when we have chosen to not retain the data!.
As shown below, the “DeleteOldOs” operation kicks in to “normally” remove all of the contents from the c:\windows.old folder!
Now everything is safe and cleaned, the disk decryption will start and BitLocker is removed
This final operation will occur at about 98% percent and will be complete at 100%
After the decryption is successful it will reboot the device and will start the SafeOS phase.
As shown earlier… The data is not removed and the hard drive is not being wiped!! All of the data is just moved and just before the decryption kicks in, the data is deleted from that Windows.old folder.
After the decryption is completed the device will reboot…..so what happens when we shut down the VM just after it finishes the decryption operation? Because when pulling the plug at that point we can make sure the device isn’t going to install stuff and maybe overwrite our sensitive data. Let’s attach the virtual hard disk to a different device and start some recovery. It’s always nice to see these kinds of tools showing up in the Microsoft Store itself.
As shown above, I downloaded a nice simple command-line utility: Windows File Recovery. I guess we all know where to look? Maybe we need to look in the windows.old folder?
so I entered this command: Winfr e: c:\temp\temp /regular /n \windows.old\users\rudy\
As shown below, the file recovery will start and will drop all of the files in the c:\temp\temp folder even with the old folder structure in it, and opening those files is no problem at all!
Please Note: I know I am not telling you something new here! I know perfectly well that a not totally zeroed hard disk will always have readable data. Maybe not all of the files are 100% readable but it still shows you the names and some information about them.
6. Looking at the official MS-Docs
I went through almost all of the official Microsoft documentation and there is “almost” not a single line telling us this remote Wipe is going to be a secure wipe. Except for this one, in “my opinion”. These sentences below COULD be very confusing!
It’s telling us two things here.
- A wipe is useful when you give the device to a new user or when the device has been lost or stolen. I guess they need to add an additional sentence: “Except when the device was previously encrypted with Bitlocker” In my opinion, it’s definitely way safer to keep the hard drive encrypted with Bitlocker than performing a remote wipe!
- Be careful about selecting wipe because the data on the device cannot be recovered. This sentence could sound like a secure wipe but that would just be a bad assumption! As I showed you earlier, the data on the device is recoverable! (easily recoverable in my opinion, but ey apparently I am an It pro?). Maybe Microsoft needs to change the sentence to “Data on the device cannot easily be recovered” but then again that doesn’t sound quite safe :). When adding the word “easily” Microsoft could give the expectation that everyone could recover the data within a few seconds and I guess that’s also not true.
Hopefully, this blog will show you which phases the Remote Wipe process goes through. I guess I need to finish it off with the main conclusions:
- Whatever you do, don’t wipe your device when it gets stolen when BitLocker was configured on the device (even when the MS-Docs are advising it!) In my opinion, a hard disk encrypted with BitLocker is way more secure!
- I know the word “wipe” could bring up some confusion or misconception but it just “wipes” some of the data and nothing more… A better word would be: “Resetting”… ow wait.. that sounds familiar right?
3. I know… I know, when looking at the MS-Docs it’s easy to comment about it. Every word in the MS-Docs could easily be misinterpreted and I guess the doc I showed you above is a great example!
4. If you want to make sure your hard drive is securely wiped, you need to go down another path!