W2k undocumented registry setting fully disables Windows File Protection (fwd)

[ah1 () SECURITYFOCUS COM (Al Huger - Mail Account)]

---------- Forwarded message ----------
Date: Sat, 24 Jun 2000 06:16:46 -0400
From: Jeremy Collake <collake () CHARTER NET>
Reply-To: Windows NTBugtraq Mailing List <NTBUGTRAQ () LISTSERV NTBUGTRAQ COM>
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.

Needless to say, this is not what Microsoft intended.

Well, it's now 6am, hopefully I haven't mucked this up too much in
my delerium.

Jeremy Collake
collake () charter net
http://www.collakesoftware.com