[ Back to Bitsum Technologies ]
Disclaimer: THIS ARTICLE IS FOR TRAINED PC TECHNICANS, DEVELOPERS, OR EXPERT USERS WHO NEED TO REPLACE A SYSTEM DLL FOR WHATEVER REASON. IT ALSO DESCRIBES ONE POTENTIAL 'EXPLOIT' IN WINDOWS XP THAT WERE LATER PATCHED UP (I THINK) - AN UNDOCUMENTED BACKDOOR REGISTRY VALUE TO DISABLE WFP. WE DISCOVERED AND PUBLISHED THIS INFORMATION MANY YEARS AGO. THIS ARTICLE IS NOW VERY OUT OF DATE THOUGH!
DO NOT TRY ANY OF THESE METHODS UNLESS YOU KNOW WHAT YOU ARE DOING. THE AUTHOR OF THIS DOCUMENT MAKES NO WARRANTIES, EXPRESSED OR IMPLIED. THE AUTHOR OF THIS DOCUMENT CAN NOT BE HELD LIABLE FOR DAMAGES RESULTING FROM USE OR MIS-USE OF THESE TECHNIQUES. USE AT YOUR OWN RISK. THIS DOCUMENT IS INTENDED FOR ADVANCED PROGRAMMERS ONLY. DO NOT ATTEMPT IF YOU DO NOT WISH TO LOSE ANY OR ALL DATA ON THE COMPUTER. THIS DOCUMENT MAY CONTAIN ERRORS. IF YOU DO NOT AGREE TO THESE TERMS, DO NOT READ FURTHER AND DO NOT USE THESE TECHNIQUES.
IF YOU USE THIS ARTICLE IN ONE OF YOUR OWN, PLEASE LINK BACK TO IT AS A REFERENCE.
UPDATE: MANY OR MOST OF THIS INFORMATION IS NOW OUT OF DATE. SOME UTILITIES ARE REMOVED FROM DOWNLOAD BECAUSE WE FEAR THEY MIGHT BE ABUSED (sad world we live in). HOWEVER, THEY CAN BE HAD ON REQUEST IF YOU AUTHENTICATE YOUR COMPANY FIRST. IN OTHER WORDS, IF YOU ARE LEGIT, AND CAN PROVE SUCH, WE CAN GIVE YOU A COPY. EMAIL US FROM YOUR COMPANY DOMAIN.
Windows File Protection
Windows File Protection (WFP) is a mechanism that protects system files from being modified or deleted. Introduced in Windows 2000, Windows File Protection was a leap forward in operating system stability since it protected the core modules from being corrupted or updated except by service packs or hotfixes sent from Microsoft.
A big problem prior to Windows 2000 was 'DLL Hell'. Applications would often update system modules with their own versions, regardless if other applications already installed were depending on a different version of that same module. Although Microsoft recommended that application programmers place modules into the program's folder instead of the system folder, few programmers did. WFP solved DLL Hell, along with many other issues.
In order to protect the integrity of the system, Microsoft did not document a way to disable WFP. If they had, programmers would surely begin to circumvent it and have their application installers overwrite system modules with their own versions. Booting to Safe Mode was the only way Microsoft provided for replacing a protected file. In theory, this was a good idea. However, programmers and power users sometimes desire the power to replace or delete protected modules without the cumbersome process of booting to safe mode and back.
Enter the mods.
In Windows 2000, a hidden registry value to fully disable WFP existed. Unfortunately, this didn't last long after I discovered and posted it to NTBugTraq. Microsoft soon tweaked their code so that the hidden registry value was neutralized (curiously, it wasn't completely removed from the code). I then created patches to re-enable this undocumented value. Appendix A describes the history of the discovery of the undocumented registry value and creation of the patches to re-enable it.
Since that time, many other techniques to disable or circumvent Windows File
Protection have been discovered.
Mod Method 1: Disable WFP for specific folders until the computer is next rebooted via manual handle manipulation
The first technique to disable WFP is to close the directory change notification handles by enumerating the handles that winlogon has opened, determining which ones correspond to the folder(s) we wish to deprotect by querying and comparing the handle names, then closing those handles via ntdll.NtDuplicateHandle (or kernel32.DuplicateHandle). This method is used by WfpAdmin.
Mod Method 2: Disable WFP completely until the computer is next rebooted via undocumented SFC API
The second technique is to terminate the SFC Watcher Thread that continually waits for and responds to the directory change notification events to be signalled. Doing this manually isn't very practical since it is diffucult to be sure the right thread has been located. Fortunately, the SFC_OS.DLL exposes a nice unnamed export at ordinal 2: SfcTerminateWatcherThread.. This API accepts no parameters and does exactly as its name implies. However, there is one caveat to using this function: It must be invoked in the process that created the SFC Watcher Thread: winlogon. To accomplish this, virtual memory needs to be allocated in the winlogon process space and a thread procedure that invokes SfcTerminateWatcherThread copied into that memory. The thread procedure should then be invoked using kernel32.CreateRemoteThread and WFP will be disabled until the winlogon process restarts (computer is rebooted).
The return value is 0 if success, or 1 if an error occurred .
Mod Method 3: Disable WFP on a specific file for 1 minute via undocumented SFC API
The SFC_OS.DLL module exports another very useful undocumented, unnamed API
at oridinal 5: SfcFileException. This handy API will register a
temporary SFC exception for specific file, allowing the file to be updated. The
period the exception is in place is currently one minute.
The return value is 0 if success, or 1 if an error occurred (usually that the
file is not protected by WFP).
Prior to Windows 2000 SP1 there was an undocumented registry value that would fully disable WFP. This is the famous 0xffffff9d value I discovered while reverse engineering SFC.DLL in Windows2000. Unfortunately, soon after its discovery Microsoft disabled it. Fortunately, the core code to disable WFP was left in SFC.DLL (later moved to SFC_OS.DLL). Therefore, a simple patch to SFC.DLL or SFC_OS.DLL will re-enable this value. I've created patches for 2K and XP and have generalized the patching procedure so the patch may be applied to all current and (hopefully) future versions of the SFC module without having to worry about a specific patch address.
General patch procedure:
Copy the target file to a temporary one.
Search for the bytes '83 F8 9D 75 07 8B C6'.
Set the SFCDisable value described below and then reboot the computer to complete the process.
Undocumented SFCDisable value:
Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File
Mod Method 5: Disable WFP permanently for specific files via patching the protected file list
More simple than patching executable code is simply patching the list of files contained in SFCFILES.DLL. First, copy SFCFILES.DLL to a temporary file. Using a hex editor (i.e. UltraEdit), search for files to disable protection on inside the temporary file. Once found, replacing the first character of the file name with 0 (that is: value 0 NOT ascii '0' character). After completing the modifications, correct the checksum using our PEChkSum utility and set the temporary file to replace the original at boot-time using our MoveLatr utility. Reboot the computer to finish the process.
Like this article? Please feed me by donating to [email protected] via paypal ;).
Appendix A: Original publication of undocumented registry setting to
fully disable WFP
W2k undocumented registry setting fully disables Windows File Protection
From: Jeremy Collake ([email protected])
Summary: Undocumented registry setting allows for
HowTo: Set the SFCDisable value (see Q222473) to
Ok, after spending 6 hours in the guts of sfc.dll, sfcfiles.dll,
76986A89 push 1
Ok, values 0, 1, 2, 3, and 4 are documented at
When booting with this value in the SFCDisable value in the WinLogon
All attempts to replace/delete protected system files succeeded,
Needless to say, this is not what Microsoft intended.
Well, it's now 6am, hopefully I haven't mucked this up too much in
Appendix B: Original publication of binary patches to SFC.DLL or SFC_OS.DLL
If you would like to re-enable the undocumented value to disable Windows File Protection, you may apply the appropriate patch and then replace the DLL in the 2k/XP recovery console (boot to CD). Be sure to set the checksum in the PE header by using Bitsum Technology's SetCSUM utility after patching.
How to find the patch offset yourself for
current and hopefully future version of SFC.DLL or SFC_OS.DLL:
Windows 2000 SP4: