Category Archives: Recovery

SOLUTION: “The requested system device cannot be found” on UEFI systems

Posted on by
40

With GPT disks and UEFI all the rage now, it’s not uncommon to encounter a scenario where boot parameters need to be repaired in order to reach the operating system.  Generally speaking, it’s often easy enough to accomplish this by executing the command bcdboot X:\windows (where X is the system drive letter) from a recovery environment.

However, other times, even in spite of this command properly completing, the system still will not boot.  In many cases the failure is evident when attempting to perform bcdedit /enum and receiving a message such as this one:

The boot configuration data store can not be opened.
The requested system device cannot be found.

Performing bootrec /fixboot also provokes the following error:

Element not found

This is bad news on a GPT disk using UEFI rather than BIOS.  Essentially, the system is looking for the EFI partition, which in this case is either missing or corrupt.

If it’s corrupt but still exists, you can simply enter diskpart, select the system partition (usually around 500 MB in size and with an ID of “EFI”) and assign it a letter, exit diskpart, and then perform a chkdsk command on the new partition assignment.  This sometimes will correct it.  Other times, forcibly removing the EFI and boot folders from the EFI partition and then executing the bcdboot command with a specific system partition parameter (e.g.: bcdboot X:\windows /s E:, where X: is the Windows partition and E: is the EFI paritition) works.

But let’s say the partition is missing altogether.  This is most often the case following a drive image using imaging tools to a new SSD for example.  Sometimes the tools (especially if executed externally on another system rather than live within the target OS) will remove the EFI partition and only image the Windows partition.

If this happens, most people will tell you that you will need to reinstall Windows from scratch.  However, all is not yet lost!  It’s fixable — but in order to accomplish it, you must recreate the EFI partition manually and then reload the boot parameters from there.

Here’s how it’s done at a command prompt from a recovery environment.  I’ve bolded the commands I typed to make it easier to read — hold on tight:

X:\windows\system32>diskpart

Microsoft DiskPart version 10.0.10240

Copyright (C) 1999-2013 Microsoft Corporation.
On computer: MININT-3A416N9

DISKPART> list disk

Disk ### Status Size Free Dyn Gpt
——– ————- ——- ——- — —
Disk 0 Online 489 GB 0 B *

DISKPART> sel disk 0

Disk 0 is now the selected disk.

DISKPART> list part

Partition ### Type Size Offset
————- —————- ——- ——-
Partition 1 Primary 489 GB 1024 KB

DISKPART> sel part 1

Partition 1 is now the selected partition.

DISKPART> shrink desired=1024

DiskPart successfully shrunk the volume by: 1024 MB

DISKPART> create partition efi size=260

DiskPart succeeded in creating the specified partition.

DISKPART> format quick fs=fat32

100 percent completed

DiskPart successfully formatted the volume.

DISKPART> exit

Leaving DiskPart…

X:\windows\system32>bcdboot c:\windows
Boot files successfully created.

Following these steps, the machine should now be bootable.  If it’s not, it’s probably time to call a professional!

Good luck!

 

CryptoLocker: UNdecryptable file ransom—How to recover

Posted on by
1

For some time now, malware authors and attackers buying licenses for use of their programs on the black market have been making a killing off of file recovery ransom schemes.  The most widespread of these was the “Windows File Recovery” style rogues that hit a couple of years ago, where a rogue recovery program named something of the sort would appear on an infected system in an attempt to convince the user that they had lost all of their data due to some catastrophic event (i.e., a hard disk failure) and that they would need to pay to have those files retrieved.  More recently, these were followed up by the still-rampant FBI Moneypak Trojans, which display a message at Windows startup explaining that the FBI has locked the PC due to its use for illegal activities and that the user will need to pay $300 via Moneypak to have it unlocked.

None of these initial attempts were very difficult to thwart unless the user or technician was completely unfamiliar with them.  The Windows Recovery rogues simply hid the files, which could easily be unhidden following their removal.  The most sinister thing they ever did was moved the user’s shortcuts to a hidden temporary folder.  The FBI Moneypak is a cinch to kill once you know of its loading points (though it does often come bundled with the ZeroAccess rootkit).  Some of the later iterations of these ransom rogues took this a step further by actually encrypting the user’s data, but even these could be beaten with special decryption tools.  Eventually, they were assigned the title of Ransomware, which technically could be used to classify any of these specimens.

In case you haven’t heard, there’s a new form of this malware, however, and it’s much, much nastier.  It’s called CryptoLocker, and it also encrypts the user’s data—but it does so using a fusion of AES and RSA encryption that is literally impossible to reverse without the possession of a private key.  That private key resides on a remote server that is only accessible once the user actually pays to have the decryption performed (and it doesn’t always work, either).  By the time the user knows they’ve been infected, all of their precious data has usually already been encrypted.  Needless to say, this is disastrous, especially for businesses.

Over the course of the past few weeks, I’ve had two different customers with this infection.  While it’s true that there is no possible way to decrypt the data, fortunately, there are still ways to recover some or even all of the data (albeit, slightly older versions of the files) if you know just one simple trick.

Windows Vista and beyond include a little-known feature called Volume Shadow Copy.  It’s closely-related to System Restore, of which many people are familiar already, but most people are not aware of the fact that Volume Shadow Copy (unlike System Restore) actually includes management of versioned snapshots of the user’s data as well.

This is a valuable tool in data recovery, of course, provided the system is bootable and the Volume Shadow Copy functionality is accessible/unbroken.  But it also happens to work with current versions of the CryptoLocker Trojan.

Here’s the process you’d need to follow:

  • Remove the CryptoLocker Trojan first or all recovered data will also be encrypted.
    • This is actually pretty easy to do; you can find a plethora of information about it across the internet.  The Trojan loads from an executable in the user’s AppData\Roaming folder (Documents and Settings\Application Data on XP) which can simply be removed to kill it.
    • However, CryptoLocker also has been bundled with Zbot very frequently, so also be sure to check for a randomly-named folder in AppData\Roaming or AppData\Local as well containing a single randomly-named executable and remove it as well.
  • Either right-click on a folder and choose Restore previous versions in Windows 7 to reveal dated snapshots of the contents of that folder, or in any version of Windows (XP SP2 and beyond), download ShadowExplorer to assist in the browsing and copying of these versioned copies.
  • Copy the data from the most recent unencrypted snapshot to a safe location.

If you need help locating all of the files which were encrypted, you can download ListCrilock from Grinler, which is a tool that lists the contents of the HKEY_CURRENT_USER\Software\CryptoLocker\Files registry key (the location CryptoLocker records the files it has encrypted).

While this is a very fortunate oversight by the authors of the malware, I wouldn’t expect it to last.  All that would need to be added is a quick routine to clear all restore points or the contents of the System Volume Information folder to prevent this recovery from taking place, and the authors know this—something which is probably in the works already as this solution has begun to spread throughout the security communities.  Ultimately, what this should do is remind everyone of the importance of regular (preferably versioned) backups offsite or to a drive which is disconnected in between backups (to prevent the files from being encrypted upon the next connection).

Thanks to Grinler for much of the information used to assemble this post, for his excellent tool, and for running a terrific website in the process.

SOLUTION: Recover/import Windows Live Mail Contacts to new computer

Posted on by
32

So today I was tasked with recovering a client’s contacts stored in a Windows Live Mail edb database for the first time.  At first, it seemed like a daunting task–primarily because I could not get a (previously) popular solution involving the now-deprecated EseDbViewer to work.  That’s because, as I later discovered, the process must be performed on the original PC in order for it to work; if you try it using the recovered files on another machine, it simply fails.

Update: A reader, Chris Siddons, has posted an alternate method to accomplish this for those with a great number of contacts.  Feedback indicates that it works quite well.  Thanks, Chris!  Here is his method:

1) On my old PC, I Located the folder “C:\Users\{Username}\AppData\Local\Microsoft\Windows Live\Contacts\Default” (obviously, replacing your user name as appropriate)

2) I copied the entire contents of this folder to a temporary location (memory stick, or another way of transferring the data to the new PC.

(NB This folder contains three folders, 15.4 15.5 and W4CR1, which appear to be empty but contain various hidden folders and files, including several versions of contacts.edb, so you may appear to be copying empty folders, but don’t worry about this, just follow these instructions as they worked for me!)

3) I located the folder “C:\Users\{Username}\AppData\Local\Microsoft\Windows ive\Contacts\Default” on the new PC and deleted the contents, then replaced them with the contents of the Default folder from the old PC.

Following is the remainder of the original blog entry:

Fortunately, as is usually the case, there is another way around this problem, and it’s actually quite easy.  The goal is to get the contacts from the edb into a readable .csv (Comma Separated Values) file for import into Windows Live Mail.  And a company known as Nirsoft (who makes a number of helpful tools, often of forensic nature) has a program that works perfectly.

It’s called LiveContactsView, and it’s designed for viewing Windows Live Messenger contacts.  However, Windows Live Mail uses the same format for storing its contacts, so it works here, too.

Here’s the full process:

  1. Download LiveContactsView.
  2. Recover the original Windows Live Mail contacts database files from the failed PC/original drive:
    • They’re located in %LOCALAPPDATA%\Microsoft\Windows Live Contacts\{GUID}\DBStore, where %LOCALAPPDATA% is an environment variable equivalent to \Users\{USERNAME}\AppData\Local\ on the drive, and {GUID} is a random string assigned to the original user’s profile.
  3. Using LiveContactsView, open the contacts.edb file from the DBStore folder.
  4. Select all fields within the list view.
  5. Export the items to a .csv file.
  6. Import the .csv file into the mail client of your choice.

That’s it!  It’s actually remarkably simple, and it is the best (and only) method I’ve found to accomplish this to date.

SOLUTION: “This is Microsoft Support” telephone scam – Computer ransom lockout

Posted on by
219

A trend of the past couple of years has been for scammers to contact computer owners directly via telephone in the United States in an effort to convince them that there is a problem with their PC and they’ll need to pay to have it fixed.  In general, these people cannot fix anything, and instead they merely charge exorbitant fees for absolutely nothing. In other words, they scam you.

The call generally goes something like this:

  1. A foreigner with a thick Indian accent identifies himself as a member of Microsoft Support or similar.
  2. He informs you that you have a number of critical problems with your PC and that you will need to have it fixed.
  3. To convince you, he offers to connect remotely and pulls up your Event Log (eventvwr.msc).  He then filters for Warnings, Errors, and Critical events and uses that as evidence that your PC will soon fail to work correctly if you do not pay him to correct it.

The astute among you have probably already sensed that something here is seriously wrong, and it’s not your PC. It’s the fact that someone is calling you to tell you there is a problem with your computer. No one will ever do that. The only way they could possibly know there is a problem is by hacking or guessing.

In this case, it’s mere guesswork, and it’s not even correct most of the time. The Event Log is supposed to log warnings and errors, and even on the healthiest of PCs there are plenty of Error Events that can be safely ignored, as they often don’t amount to anything. The important thing to remember is to never trust someone who calls you about a problem with your PC, and never, EVER let them connect remotely to your PC.

If you do make the mistake of letting them connect, but then you happen to get cold feet and refuse to pay the $180+ they request via credit card, the next thing that happens isn’t pretty. This scammer proceeded to actually follow through on his promise of the PC “not working” if they don’t agree to have him fix it, and so in a few quick steps, behind the user’s back, he enacted what is known as SysKey encryption on the SAM registry hive.

SysKey encryption is a little-known feature of Windows which allows administrators to lock out access to the Security Accounts Manager (SAM) registry hive so that login specifics cannot be stolen and the PC cannot be accessed without knowing the proper credentials. The problem is, unlike other scams, there is no way around the problem; you can’t simply remove the password, as the actual SAM hive has been encrypted entirely by the process. If your Windows installation has had SysKey activated, you’ll see the following message:

Startup Password

This computer is configured to require a password in order to start up. Please enter the Startup Password below.

The window which appears looks like this:

This computer is configured to require a password in order to start up. Please enter the Startup Password below.

The ONLY solution is to find a clean copy of the registry hives from before this occurred. This scammer knew this, however, and as such, he took an extra step to block any repair or recovery attempts: he deleted all System Restore points on the machine, which normally house backup copies of the registry hives.

Unfortunately for him, I’m a much better technician. When the customer suspected foul play and decided to call me instead of proceeding, I immediately instructed them to power off the PC. Here’s how I fixed the problem without having to reinstall Windows.

FIRST, ensure you don’t have any Restore Points to work with:

  1. Check to ensure that the folder %SYSTEMROOT%\system32\config\RegBack exists.  This is the folder which contains the last known good backup of the hives following a boot.  If it exists, continue.  If not, stop and consider contacting a technician instead.
  2. Reboot the PC and repeatedly press F8 to reach the Advanced Startup Options menu.
  3. Choose Repair your Computer from the menu.
  4. Cancel the automatic repair attempt and instead instruct the system to perform a System Restore to a date prior to the incident occurring.

If no Restore Points exist, your scammer intentionally removed them to prevent this from occurring.  If this happens to you, follow these additional steps to resolve the problem:

  1. POWER OFF your PC immediately.
  2. Boot to external media of some sort (NOT your Windows installation) and navigate to the %SYSTEMROOT%\system32\config folder.
  3. Backup the registry hives in this folder to a temporary location. The files are:
    1. SOFTWARE
    2. SYSTEM
    3. SAM
    4. SECURITY
    5. DEFAULT
  4. Navigate to %SYSTEMROOT%\system32\config\RegBack as mentioned earlier.
  5. Copy all registry hives from this folder (the same files as listed above) into the %SYSTEMROOT%\system32\config folder.
  6. Reboot the PC.

This solution only works if you have not already tried to reboot the PC subsequently.  If you have, it may still work, but that is entirely dependent upon whether or not Windows created a new RegBack copy following a successful boot.

In the case of my customer, it worked, and they were back in Windows, just like it never happened.  Nice try, scammer.  You’ll have to try harder to beat me though. 🙂

Addendum A (update 6/26/2015):

Thanks to FUScammers for pointing out this more involved, alternate method of actually removing the SAM encryption.

  1. Download this file and burn the .iso to a CD.
  2. Boot to the CD on the affected system.
  3. Follow the instructions to select the proper system drive and partition (NTFS is the partition type you are looking for).
  4. Type the path to the registry files (it’s most likely Windows/system32/config).
  5. Choose option 1 for Password reset (sam system security).
  6. Choose option 2 for Syskey status & change.
  7. Confirm that you wish to disable Syskey, then quit and confirm writing the new changes to the hive.
  8. Reboot the PC and check.

For more detailed instructions, check out this link (scroll down to “How to disable Syskey startup password”):

http://computernetworkingnotes.com/xp-tips-and-trick/remove-administrator-password.html

In Windows 8, the GPT partition type makes the use of this utility impossible.  However, you can still manually copy the hives to a supported filesystem (NTFS or FAT32), mount that filesystem instead, and follow the steps from there, then copy the hives back over the originals.  I can confirm that this method does work and that even in Windows 8.1 recovery is possible using it.

Solution: Recover an Outlook 2007 Business Contact Manager Database from a failed PC

Posted on by
1

Computer dead?  Don’t have a good backup of your Business Contact Manager data?

This is a serious problem.  It’s not an easy thing to find a solution to, either; those that exist only seem to work for some people, and only under particular circumstances, too.  So in this post, I’ve set out to provide a solution that should work for everyone–hopefully.

Just one preliminary note: this only pertains to the 2007 version of Outlook. While it may work in other versions, I haven’t tested it there.

Okay.  So you’ve got a dead computer (maybe yours, maybe your client’s), and you have the files recovered from the drive–perhaps from a backup.  But unfortunately, as simple as it ought to be, recovering a Business Contact Manager database is far from it.  You can’t simply retrieve the files and then import them somehow.  In fact, from my recent experience, you can’t even make it work unless you follow a very specific order of operations.

Here’s how it’s done:

  1. You first need the *.mdf and *.ldf files from within the Business Contact Manager Local Application Data/%LocalAppData% directory.  Be sure to copy only those files which correspond to your current database (probably those with the most recent Modified date).  You can retrieve those from the failed drive (or backup) by navigating here:
    • On XP, they’re in %USERPROFILE%\Local Settings\Application Data\Microsoft\Business Contact Manager
    • On Vista/7, they’re in %LOCALAPPDATA%\Microsoft\Business Contact Manager
  2. Copy these files to the new PC and place them in a temporary location on the new PC (such as the user’s Windows Desktop).
  3. Install Office 2007 (if it isn’t already installed), along with the Business Contact Manager.
    • If Office is already installed and you’ve already configured Business Contact Manager, you have no choice but to completely remove everything related to Business Contact Manager.  That means everything: Business Contact Manager 2007, and all listed software related to SQL Server 2005. 
  4. Install Microsoft SQL Server 2005 Service Pack 3 (you’ll need the very latest version just in case the files are from a later version than the freshly-installed one, which is likely).
  5. Open Outlook 2007.  Start the Business Contact Manager wizard and instruct it to create a new database with the same name as the old database.  If you’re unsure what the old database was named, it’s easy to tell: simply take whatever text comes before the .mdf and .ldf (it should be identical), and that’s your database name.  It’s very important that the names match!
  6. Immediately close Outlook after the database creation is complete.
  7. Stop the MSSQL$MSSMLBIZ service.
    • You can either use the services.msc interface to do so or open a Command Prompt and type sc stop “MSSQL$MSSMLBIZ” at the prompt (then press ENTER).
  8. Copy the .mdf and .ldf files from the old PC (wherever you saved them) to the Business Contact Manager working directory on the new PC, overwriting the new files with the old ones.
    • It should be obvious where the working directory is located.  If you’re unsure, re-read the sub-points on Step 1.
  9. Set permissions on the .mdf and .ldf files to allow Full Control to Everyone.  Here’s a helpful page on the subject in case you aren’t familiar with this process.  Be sure you set the permissions correctly!
  10. Restart the MSSQL$MSSMLBIZ service.
    • Again, you can use services.msc or type sc start “MSSQL$MSSMLBIZ” at a Command Prompt.
  11. Finally, start Outlook 2007 and verify that all data has been successfully recovered.

Congratulations, you’ve done the impossible!