Technology Notebook

Windows 2000::Windows File Protection::Disabling

From GROUPS.GOOGLE.COM:
---------- Forwarded message ----------
Date: Sat, 24 Jun 2000 06:16:46 -0400
From: Jeremy Collake
Reply-To: Windows NTBugtraq Mailing List
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
Subject: W2k undocumented registry setting fully disables Windows File
Protection

6:13am 6/24

Summary: Undocumented registry setting allows for
Windows File Protection (aka System File Checker)
to be fully disabled.

HowTo: Set the SFCDisable value (see Q222473) to
0xffffff9d.

Ok, after spending 6 hours in the guts of sfc.dll, sfcfiles.dll,
and winlogon.exe I have *finally* discovered how to permanently
disable windows file protection. The more I dug into the internals
of SFC, the more I began to think that it would not be as easy as
I first thought it would be - and indeed Microsoft does not want it
to be easy. Windows File Protection, while annoying, does provide
a good degree of system stability and even some level of virus/trojan
protection by preventing system files from being modified without
at least notifying the user. Therefore, I was *very* shocked when
I was looking through a disassembly of sfc.dll and came to the code
that checks the value of the SfcDisable in the WinLogon key.
I see in the code of ordinal 2 (which is the initialization function
that winlogon calls), sticking out like a sore thumb, this:

76986A89 push 1
76986A8B cmp eax, ebx
76986A8D pop esi
76986A8E jz loc_76986B97
76986A94 cmp eax, esi
76986A96 jz loc_76986B7A
76986A9C cmp eax, 2
76986A9F jz loc_76986B69
76986AA5 cmp eax, 3
76986AA8 jz short loc_76986AE0
76986AAA cmp eax, 4
76986AAD jz short loc_76986ACF
76986AAF cmp eax, 0FFFFFF9Dh
76986AB2 push ebx
76986AB3 jz loc_76986B86
76986AB9 push offset byte_76981898
76986ABE push edi
76986ABF call sub_7698877D
76986AC4 mov dword_769901D4, ebx
76986ACA jmp loc_76986B97

Ok, values 0, 1, 2, 3, and 4 are documented at
http://support.microsoft.com/support/kb/articles/Q222/4/73.ASP , but
what the heck is this 0ffffff9dh value that it accepts?! As you can
see, any value other than 0,1,2,3,4 and 0ffffff9dh are assumed to be
zero, which is the default of SFC enabled with popups enabled. So,
without further delay, I went and plugged 0ffffff9dh into the SfcDisable
value to see what was up. Rebooted. I'll be darned, Microsoft provided
a very,very simple way to fully disable WFP!

When booting with this value in the SFCDisable value in the WinLogon
key (HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon), an
event is written to the system log, ID 64032 from Windows File
Protection, with the description:
"Windows File Protection is not active on this system. ".

All attempts to replace/delete protected system files succeeded,
just as if I were in safe mode :). I rebooted a few more times and
verified that it is the one value (other than 4=popus disabled) that
is not reset to 0 after the first boot.