How to Hack Protected Windows XP Files

Before we go any further, always remember Rule Number One: Back Up!  Take the time to back up any files you plan on editing or replacing. If you can, create a full system backup such as a drive image.  Things can go wrong and it’s best to have a good recovery method in place if and when disaster strikes.

Rule Number Two is equally important.  Always do your homework.  Take the time to educate yourself about what you’re trying to accomplish.  The Windows Operating System is extremely integrated throughout several thousand system files.  Make sure you’re aware of what they do and what risks you run by changing them.

Finally, Rule Number Three is to take your time, especially if you are using a hex editor to edit binary files.  If you make mistakes there is a good chance you will render the file completely unusable right along with your system.

Any time you try to run Windows in a manner other than it was intended, you run the risk of causing instability and data loss.  We’ve all seen how “stable” Windows is on its own; imagine what you’re doing when you begin changing things.

It should also be noted that editing system files does violate the Windows EULA.  As such, you will no longer be eligible for technical support from Microsoft.  With that in mind, I don’t condone this type of activity by those who are not prepared to take on the responsibilities and consequences that may arise.

Windows File Protection is an integrated feature designed to protect your system against viral attacks and accidental deletions.  Essentially, it monitors certain system files and replaces them with backup copies whenever they are changed.

WFP is integrated at the OS level and also at the file level.  At the OS level file sizes are checked prior to file execution.  If a size is different from what Windows expects, the file is replaced with a clean backup.  Some files also include CRC headers that verify a file’s checksum prior to execution as well.

Some hack guides will recommend that you disable Windows File Protection completely.  For obvious reasons I don’t recommend that.  Instead, you can manually exclude individual files or folder trees.

There is a hidden file called filelist.xml in the Restore folder of your System32 directory.  You can open it in any basic text editor.

Insert a line in the <Exclude> section with the path to the file or folder tree that you would like to unprotect.  Format it exactly like the other lines in the file.  You may use environmental variables for special folders.  So to unprotect Explorer.exe you would use:

<REC>%windir%\Explorer.exe</REC>

Once a file has been excluded, you should delete or rename all of the backup files associated with it.

Depending on the Service Pack level of your system and whether or not you are using System Restore, there can be several layers of file backups.  WFP is a recursively designed system that tries to ensure file security by not only making original backups, but also by using the backups created by these other services to back up its own backups.

Needless to say, if you are intentionally trying to alter system files, you have several securities that you’ll need to navigate past.  Here’s how you’ll need to go about it.

The first thing you’ll need to do is remove any Service Pack backups.  If you’ve installed Service Pack 1 or 2 there will be a ServicePackFiles folder in your %systemroot%.  This directory contains an i386 directory full of backups.  Most retain the original filenames.  Some of them are shortened or spawned from larger DLL files, however.

Next, you’ll need to remove any System Restore backups.  These can be found in the Restore folder in your System32 directory.  These should have the same name as the backup in the ServicePackFiles directory.

With those out of the way, it’s time to take on another Windows line of defense—the Last Known Good Configuration.  Choosing the Last Known Configuration option on the Advanced Boot Menu will boot your computer using the last configuration that worked.  To remove this backup, head over to the LastGood folder in your %systemroot%.

At this point you’ll be ready to remove the final backup.  This one is used by both Windows File Protection and the System File Checker utility.  It’s located in the dllcache folder under System32. The dllcache folder is hidden by default so you’ll need to enable viewing hidden files and folders or enter it into the explorer address bar in order to access it.

Quite often you may be trying to edit files that are currently in use.  As is to be expected, you will not be able to save changes to these files.  At this point, you have two options.  You can attempt to unload these files from memory or you can schedule Windows to make the changes at the next reboot.

We’ll start with the first since it is typically the quickest and easiest method.  You should all be familiar with Task Manager.  Simply look at the Processes tab and end the task with the same name as the file you wish to save.

In some rare cases you may be attempting to edit critical tasks that cannot be ended.  In these cases you will have no choice but to resort to the reboot method.

In some rare cases, a process may be depending on a file you are trying to change.  I say rare because typically you can still make changes to most dependent files.  As a general rule, end all unnecessary tasks.  Chances are that you will release the file you are trying to edit in the process.

Don’t forget that ending all of those processes will cause a certain level of instability in your system.  Take the time to reboot after making your changes so that your system is returned to normal operation.

If you’ve ended all available tasks and your file is still in use you may be wondering how this is possible.  Let’s not forget about system services.  System services are not displayed as running tasks in Task Manager.

You can launch the Service MMC snap-in by entering services.msc in the Run… dialog box.  The Services window will show you the current state of all installed services.  You can stop any unnecessary services from the context menu.

I imagine you’re saying to yourself that you don’t want to take the time to end every one of those services, right?  There is a way to see at a glance what services are running and what resources they are using.

Head over to Microsoft’s Download Center and get a copy of Process Explorer.  This utility, originally created by Sysinternals, is not only a stand-alone task manager but also a service viewer.  It even has the ability to show you all dependencies associated with a particular task or service.

Navigate each of the processes until you find the one that lists your file as a dependency and end the parent process or service.  That should release the file in order for you to save changes.

If you are still unable to save your file, then you are most likely trying to edit one of the critical processes that cannot be ended.  It would be impossible for Windows to run without certain processes, such as the Windows kernel.  Therefore, there are a few select tasks that can never be ended.

Here’s another tip:

Many in-use files are associated with your hardware drivers.  Rebooting in Safe Mode may allow you to make changes to these files successfully because of the limited environment.

If you come to the conclusion that you’re stuck resorting to the reboot method—or just plain don’t feel like figuring out any alternative—then you’re going to need to use the Windows registry.

Windows understands that some program installations will be required to alter files that may be in use so it provides a method of doing just that.  It’s known as the PendingFileRenameOperations method.  It takes its name from the registry it uses to manage these pending changes.

Application developers should make use of the MoveFileEx() function in the Win32 API rather than editing the PendingFileRenameOperations key directly.

PendingFileRenameOperations is made available by the Windows Session Manager.  It is a multi-string (REG_MULTI_SZ) key that contains file name pairs for all files to be renamed (including move or deleted) upon the next reboot.

If this key does not exist, you can create it.  Enter regedit in the Run… dialog box to launch Registry Editor.  On the HKEY_LOCAL_MACHINE hive, navigate to CurrentControlSet, Control, Session Manager.

In the right pane, open the PendingFileRenameOperations key or create it by right-clicking and choosing New > Multi-String value.  Be sure that the key name does not contain any spaces.

Once you have the key open for editing, you can begin adding the changes that need to be made.  Each entry needs to be a two-line pair.  The first line should be the full path to the original file and the second should be the replacement, or what the file should be after the rename procedure.

To rename a file, simply enter the same full path with the new file name as the second entry.  Altering the path in the second entry will result in a move operation.  A new path AND file name would result in both a move AND a simultaneous rename.  Finally, to delete a file, simply use a blank line.

So an entry in this registry key might look something like the following:

C:\Windows\original.txt

C:\Windows\renamed.txt

C:\deleteme.txt

C:\original.file

C:\new directory\original.file

In the above example, I have the PendingFileRenameOperations key set to perform three actions.  The first two lines perform a simple file rename.  The second two—notice the blank line—perform a file delete.  And the last two lines perform a move operation.

Because each line is expected to contain only a single path, you may enter paths that contain spaces without having to enclose them in quotation marks.  Long file names are also supported.

If you are uncomfortable editing the registry, there are a couple of really nice command-line tools available that will create or edit the key for you.  You can get download details for PendMoves and MoveFile by visiting Microsoft’s TechNet site.

The operations in the PendingFileRenameOperations key will be performed at the next system startup, at which time they will be removed upon successful completion.  Note that this registry key is only supported on NT versions of Windows.  For older systems, you should use the Wininit.ini method.

Older Windows and DOS systems use a text file named Wininit.ini in the Windows directory for performing these operations.  This file uses a standard INI file setup.  Each operation appears on a single line in the [rename] section.  Our above example would look like this in a Wininit.ini file:

[rename]

C:\Windows\renamed.txt=C:\Windows\original.txt

NUL=C:\deleteme.txt

C:\newdir~1\original.file= C:\original.file

In a Winint.ini file, each operation is on a single line.  File name pairs are listed in reverse and separated by an equals sign.  In other words, the new file name or path is listed first. 

Note the use of the NUL indicator when performing a file delete.  Older DOS systems will require 8.3 formatted paths and names while newer systems supporting LFNs will have no issues with spaces.  The Wininit.ini file is also case insensitive.

Newer Windows versions supporting long file names will accept them in the Wininit.ini file; however, the rename operations will be written using the short file name equivalent.

While newer versions of Windows will support the Wininit.ini method for compatibility, it is highly recommended that you avoid this method whenever possible.  You should always use the PendingFileRenameOperations registry key whenever available.

One last scenario to consider is when you wish to edit a file that is absolutely necessary for Windows to boot such as NTDETECT.COM or ntldr.  There is no way to edit or replace these files from within the Windows operating system.  You will need to boot into an alternative environment that can provide you with hard disk access.

Well, that pretty much wraps it up.  You should now have all of the tools you need to edit or replace files that are either in use or protected by Windows.  Please use this information with caution as I am in no way responsible if destroy your system.

Also understand that editing such files may very well violate user agreements and void warranties.  Please be prepared to accept these responsibilities should you decide to attempt these changes.

I hope you’ve all had a chance to learn something.  In my opinion it’s always good to take a deeper look at how things work.  Until next time…