Here’s a rare example of a situation where I was actually very close to contemplating a reformat before finally stumbling across an idea which led to its resolution.
The client was an employee of a large company whose laptop hard drives (like many) are encrypted using McAfee Safeboot (Endpoint Encryption). This is a great strategy for protecting against data theft in the event that the machine is stolen, but like all data encryption, any sort of problem whatsoever with regard to either data integrity or the encryption/decryption process can be potentially disastrous.
Since SafeBoot/EE is a boot sector encryption (“pre-boot authentication” it’s called) which applies to the entire storage volume, any problems relating to its boot partition information can completely break the entire system until either the information is repaired or the volume is manually decrypted. Fortunately, McAfee provides a method for decrypting volumes offline using a special boot CD (called SafeTech/WinTech, depending on your version) and a rolling Authorization Code which changes daily. Unfortunately, they only make these tools available directly to clients… meaning that us independent techs are completely out of luck, even if we have the decryption key (which the customer provided me).
While I was able to bypass the rolling Authentication Code by adjusting the system’s date to a specific day years back and using a code I found posted on an online forum, the built-in tools and even a SafeBoot Admin CD I located weren’t helpful in resolving the issue. We had already tried contacting the IT department, who says they had no such tools at their disposal and that a reformat would be necessary. Worse yet, my client was only in Louisville on a brief business trip, and there was data they needed on the encrypted volume.
The next morning, I had planned to contact the customer and suggest that we do just that: reformat. But on a last-minute whim, I stumbled across an idea which could perhaps explain the strange behavior we were experiencing.
If you Google the Safeboot 92h error, you’ll find a variety of reasons why it can occur, and plenty of situations where it was never properly resolved. Reverse-engineering the situation in my mind, however, led me to an important point which I had almost disregarded in the midst of my desire to quickly resolve the situation and return a working PC to my busy traveling executive: the possibility that malware had triggered the problem to begin with.
You see, the very first step I performed was a drive image of the encrypted data for safety. And I had noticed that, throughout the course of the imaging process, no read errors/bad sectors had been encountered. For surety, I even performed a hardware diagnostic subsequently, and no memory or hard drive errors were found. This means that the encryption probably had not failed due to a hardware issue, and that instead, some sort of software was likely to blame. Malware is the perfect culprit here; most notably, boot sector rootkits, which specifically alter the MBR and/or partition information of a victim’s machine to provide a filtering mechanism for the malware where it is also entirely undetectable.
One such rootkit you’ve already seen me write about in the past: Rootkit.Boot.Pihar.B. It creates a hidden, encrypted partition at the end of a drive and sets it as the main Active partition, after which it chainloads the operating system partition (which is set as Inactive by the rootkit). This effectively allows the rootkit to leave the MBR “clean” by storing all code in its encrypted partition and then loading the OS normally afterwards. While this rootkit wasn’t currently detected as active on my client’s system (using an offline TDSSKiller run), after booting to a partition management software, I found that the hidden/encrypted partition was present. And the OS partition, predictably, was Inactive.
It was just that simple. Setting the OS partition as Active and then booting normally did the trick. Following that, I had plenty of malware cleanup on my hands, most of it related to a rogue which had piggybacked on the rootkit. This was a lot of fun since the machine’s Administrator restrictions and policies stood in the way, but in the end, the machine was repaired, all data was recovered, and my client was happy. That is, until he returns to his hometown, where he’ll then request an updated Windows 7 machine to replace this dinosaur.