Re-enable SFC after install?

[johnhc]

In order to install some modified system DLLs, I specify Disable SFC in nLite. I think it would be better to re-enable it after installation so that I have the protection offered by it.

Google told me about the registry key and the SFC module modification. I have restored the sfc_os.dll to its pre-disable state and set the key as required as follows:

Windows Registry Editor Version 5.00

;Re-enable WFP
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"SFCDisable"=dword:00000000

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon]
"SfcDisable"=dword:00000000

There are two keys as I am running XP x64. Only the 64 bit version of sfc_os.dll has been restored since the 32 bit version was not altered.

I'm hoping I have found all the alterations need to fully restore SFC(WFP) to operation.

I would appreciate any comments and advice on the restoration.

Thanks, John.

[TranceEnergy]

This isn't a bad idea. You could have sfc disabled during windows installation then in nlite's guirunonce you could re-enable it by setting sfc enabled. Saving time on installation and possible sfc interrupts.

I seem to recall that it is a good idea to also do a sfc /revert or something. I would google re enabling of sfc and see what that came up with.

Personally i just permanently disable it and forget about it.

[johnhc]

TranceEnergy,

Thanks for your response. I was hoping someone (perhaps nuhi) could/would tell me exactly what nLite has changed so I could change it back. What I have implemented (via WPI) seems to work but I am afraid I may have missed something. I will do some more searching.

Thanks, John.

[jaclaz]

I think that nlite uses the "empty" .dll trick, originally developed by Damian Bakowski and bettered by Fred De Vorck:

http://www.vorck.com/windows/about.html

http://www.msfn.org/board/Nlited-XP-post-i...3.html&st=6

http://www.msfn.org/board/enable-file-protection-t71256.html

jaclaz

[TranceEnergy]

As i recall nlite sets some hex code that is applied to sfc_os.dll, i think you could find that from the nlite.inf or such.

However, reverting sfc patch is easy.

you need to revert f.ex

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]

"SfcDisable"=dword:ffffff9d

perhaps one could simple delete that value. Sfc_os.dll in itself, just extract the file from your windows source. It's not been modified since sp2 (x64 xp), so no trouble there.

Then perhaps you need to run sfc /revert or something as i was also thinking about.

This all should be fairly easy. I dont do WPI though, i much like true unattended.

[johnhc]

jaclaz, thanks for your reply. I will spend some time looking at the links.

EDIT: I have looked at your links and I don't believe that nLite is using the 'empty dll trick'. I think you will see why I believe this below.

TranceEnergy, thanks. By Googling, I was able to find how to disable SFC for XP (hex edit sfc_os.dll, change key). I then assumed that nLite probably did it the same way. I compared hashes between sfc_os.dll in an nLited ISO (SFC disabled) with the ones in my host machine (XP x64, SP2). The 64 bit one was different (exact same length), but I was surprised to see that the 32 bit one (SysWoW64) was the same. The keys for both (see my first post) were both altered. After restoring the 64 bit sfc_os.dll and both keys, both 32 and 64 bit functions seem to work. If I rename or replace a dll (shell32 for instances), in a few seconds a new one appears having the hash of the original. The 32 bit will yield a dialog if the needed dll is not available (insert CD). If this is canceled, then the 32 bit dll can be changed.

Thanks for the comments.

Enjoy, John.

Edited October 12, 2008 by johnhc

[TranceEnergy]

I think the key here is knowing when do you do what in what order. Because if sfc is enabled, it must certainly not will allow you to overwrite itself, i would assume.

So i dont know what order your did things in, but i know i have successfully enabled sfc again after having it patched etc with nlite. However im quite happy with it disabled. I'm confident you will find a way.

[jaclaz]

Really I cannot say, I usually disable SFC/WFP and let it be disabled.

But really it doesn't apply as I run Win2k.

I wonder how it can work though.

I mean, normally the SFC_OS.DLL checks the files listed in SFCFILES.DLL.

If you hexedit adequately SFC_OS.DLL, it checks NOT the files in SFCFILES.DLL

If you have an empty SFCFILES.DLL, the SFC_OS.DLL check the files listed in it i.e. zero files.

The referenced post by fdv explains the above better:

http://www.msfn.org/board/HFSLIP-Test-rele...279#entry492279

Now, if you re-enable the SFC_OS.DLL with an unmodified list of files (original SFCFILES.DLL), it will start re-checking the listed files, and if any has been modified or is missing it will pop-up asking you to insert the CD.

jaclaz

[johnhc]

All responders, thanks for your responses.

I just looked at the hashes for the sfcfiles.dll in my nLite processed files (SCF Disabled) and the copy in my System32 folder on my host. They are both the same, so changing this file is not the method nLite uses as I said before. If you will look at my previous posts you will see that the sfc_os.dll file is altered.

Enjoy, John.

[jaclaz]

They are both the same, so changing this file is not the method nLite uses as I said before. If you will look at my previous posts you will see that the sfc_os.dll file is altered.

Sure, I got that.

What I was wondering was how, once you reenable WFP, it behaves for files that you deleted (if they are within the list inside SFCFILES.DLL) .

jaclaz

[johnhc]

jaclaz,

What I was wondering was how, once you reenable WFP, it behaves for files that you deleted (if they are within the list inside SFCFILES.DLL) .

They re-appear, see my post above.

I am looking at scffiles.dll in a resource editor right now and have not made sense of it yet.

My reason for opening this topic was to try to determine if I had done all the things I needed to do to restore SFC(WFP) to full function.

Enjoy, John.