sfc_os.dll第五号函数替换文件

Windows文件保护是个烦人的东西，我们在写小马的时候不可避免的想要干掉它。
流行的思路有以下几种：
1.远程注入Winlogon进程卸载sfc_os.dll
2.强制替换dllcache里的文件，监视弹窗，使用postmessage发送wm_close消息以关闭。
3.调用sfc_os.dll的第5号导出函数以替换文件

Windows File Protection is a waste,Solutions usually is:
1.Creae a remote thread to freelibrary sfc_os.dll
2.use postmessage to close WFP dialogs.
3.call SetSfcFileException function in sfc_os.dll

如果你使用第一种方法，那不好意思，因为你使用了CreateRemoteThread，所以你会死的很惨。你肯定过不了AVP。
但是第二种方法，似乎有点太小儿科了，而且弹窗有可能会闪一下，影响隐蔽性。
所以剩下的一种办法就是今天我要讲的了，我们可以通过调用在sfc_os.dll中一个undoc的h5号函数来实现在60秒内替换保护的文件，暂且叫它“5号门”吧，函数原型如下

Today, I will demonstrate third method to solve, Function is:

SetSfcFileException (DWORD param1, PWCHAR param2, DWORD param3);

param1: Always set to 0
param2: The full path of the file to modify later
param3: Always set to –1

在网上很容易可以搜索到C的示例代码，代码摘录如下

//c code demo
typedef DWORD(__stdcall *CPP) (DWORD param1, PWCHAR param2, DWORD param3);

void Disable_WFP()

{
HINSTANCE hmod=LoadLibrary("sfc_os.dll");
CPP SetSfcFileException;

// the function is stored at the fifth ordinal in sfc_os.dll
SetSfcFileException= (CPP)GetProcAddress(hmod,(LPCSTR)5);

SetSfcFileException(0, L"c://windows//system32//calc.exe",-1);

//Now we can modify the system file in a complete stealth.

}
所以既然有了函数原型还有C的示范代码，我们很容易就可以翻译成Delphi了。

{
Call "5th function" to close WFP
delphi code demo.
Develop by BinJian in sleepless.org.cn.
Thank Anskya for Correction.
}
procedure CloseWFP(DestFile: pwchar);
var
h: DWORD;
func: procedure(p1: Longint; p2: pwChar; p3: Longint); stdcall;
begin
h := LoadLibrary('sfc_os.dll');
@Func := GetProcAddress(h, lpcstr(5));
Func(0, DestFile, -1);
end;
但是，以上代码还过不了AVP，需要用一点小技巧就可以过AVP了。
其实AVP就是对“sfc_os.dll”做了特征码，只要想办法修改就可以过AVP了。
由于某些原因我就不放出完整代码了，请自己思考吧。

参考文献

Hacking 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 hacks.

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.

How the System File Checker monitors files for changes

The executable portion of WFP is called the System File Checker (SFC). It exists throughout SFC.DLL, SFC_OS.DLL, SFCFILES.DLL, and SFC.EXE.The contents of SFC.DLL and SFC_OS.DLL have changed between Windows 2000 and Windows XP. In Windows XP, SFC_OS.DLL contains all the core code and SFC.DLL is merely a proxy to it. The exports of SFC.DLL are forwarded on to SFC_OS.DLL. The SFCFILES.DLL module is simply a data holder that contains a list of all files protected by WFP.

At startup the winlogon service invokes the unnamed export ordinal 1 of SFC_OS.DLL, SfcInitProt. This API launches a new free thread called the ‘SFC Watcher Thread‘. This thread creates a series of directory change notification events, one for each folder that contains a protected file. The WaitForMultipleObjects API is then called within loop to wait for any of these events to be signalled. Upon event signaling, the modified file(s) are determined and replaced with copies found in the cache folder, if one exists there. If it doesn’t, the user is prompted to insert the Windows installation CD so that the file can be replaced from the copy found on it.

Therefore, SFC actually allows for files to be replaced or modified, then overwrites them. A few second delay is incorporated so that time is given for write operations to ’settle down’ before the affected file(s) are restored.

Knowing how SFC works means that one can easily disable it by terminating the watcher thread or by closing the directory change notification event handles. This leads us to methods 1 and 2:
The core of Windows File Protection
SFC.DLL WFP executable content. In XP only a proxy to SFC_OS.DLL.
SFC_OS.DLL WFP executable content.
SFCFILES.DLL Contains list of protected files. Exports SfcGetFiles API.
SFC.EXE System File Checker utility. Utility to scan WFP protected files for changes and replace altered versions.


Hack 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.

Hack 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).

Ordinal 2:
DWORD WINAPI SfcTerminateWatcherThread();

The return value is 0 if success, or 1 if an error occurred .

Hack 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.

Ordinal 5:
DWORD WINAPI SfcFileException(DWORD dwUnknown0, PWCHAR pwszFile, DWORD dwUnknown1);

dwUnknown0 Unknown. Set to 0
pwszFile Filename
dwUnknown1 Unknown. Set to -1

The return value is 0 if success, or 1 if an error occurred (usually that the file is not protected by WFP).

An example call to this API is:
SetSfcFileException(0, L”c://windows//notepad.exe”,-1);

Hack Method 4: Disable WFP permanently via patches and undocumented registry value

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:

For Windows 2000, the patch is applied to SFC.DLL.
For Windows XP and 2003, the patch is applied to SFC_OS.DLL.

Copy the target file to a temporary one.

Search for the bytes ‘83 F8 9D 75 07 8B C6′.
Replace the ‘8B C6′ with ‘90 90′.

You must correct the checksum of the image by using our PEChkSum utility. It can be obtained here.

Now set the temporary file to replace the original at boot-time by using our MoveLatr utility. It can be obtained here.

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 Protection
Value name: SFCDisable
Value: 0xFFFFFF9D

Hack 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.

-Jeremy Collake
jeremy@bitsum.com

The End