[jaclaz]

Maybe useful (or maybe completely NOT like so ), Session0Cmd:
http://reboot.pro/16550/

jaclaz

[CoffeeFiend]

jaclaz, on 18 March 2012 - 07:13 AM, said:

Session0Cmd

The last time I've been that "worried" is when I stumbled across a tool that would give you admin rights by using the stored LMHash of a previously logged in admin user to authenticate. It's surprisingly simple to do as well...

Anyway. fdv's reappearance in this thread got me curious so I had a quick peek around a couple binaries from Win7 x64:

sfc.exe has nothing interesting in the IAT. Some calls to sqmapi.dll which is the Software Quality Management lib (which ends up into ntdll functions e.g. WinSqmStartSession), and some to SSShim.dll too (a shim for the same "servicing stack" that DISM uses). It also makes a few calls to wrpint.dll (Windows Resource Protection Interface -- the "WRP Integrity Check And Repair DLL" as MS puts it) which only has SfpInitialze and SfpFinalize listed in its exports section (it's probably hiding something)

wrpint.dll in turns makes calls to the Setup API's Pnp* functions (e.g. PnpIsFileContentIntact or PnpRepairWindowsProtectedDriver).

and finally, wrpintapi.dll. There's very little in its exports section too (2 boring functions), but it definitely does more. It has a few interesting interfaces like ISFPIntegrityCheckAndRepair, ISFPProgressCallback and ISFPRebootCallback (there are valid pointers to them, but nothing obvious that seems to use the said pointers in the code). It's referenced by the registry as the "SFP Interface Class".

As for the Setup API dll, since it does a LOT of different things it exports loads of funtions and it calls a LOT of different stuff, *large* amounts of which could be related (from ntdll, API-MS-Win-Core-ProcessThreads-L1-1-0, API-MS-Win-Security-Base-L1-1-0, drvstore, API-MS-Win-Security-SDDL-L1-1-0, API-MS-WIN-Service-winsvc-L1-1-0, API-MS-WIN-Service-Management-L1-1-0, ADVAPI32, CRYPT32, SCECLI, WINTRUST, SPINF and SPFILEQ).

Edit: BTW, sfc_os.dll and sfc.dll are still around, and they're quite different. sfc.dll is pretty much empty now, and sfc_os.dll has some new and renamed functions. Some (old?) functions in there just return directly i.e. xor eax, eax + ret. More stuff you could look at... For what it's worth, the function that people patched to disable SFC on XP (the one where there's the infamous cmp eax, 0FFFFFF9Dh where people patch the following jump -- BTW there is no trace of that value in any of the new DLLs, nor the SFCDisable string for that matter) wasn't in the exports table either.

There's probably some unexported (hidden, likely findable as a fixup in a relocation table) functions in some of them (like there were in the SFC subsystem of XP) which can be quite a pain to find out. Like I was saying, this is just a quick glance at the overall system. And since I don't really understand how the system works as a whole (nor what parts are related to WRP/SFC/TrusteredInstaller and what not) then that's about as far as I'll go. I'm not going to try randomly patching stuff without even knowing so much as what I'm trying to accomplish (nor do I have the free time)

[joakim]

What exactly are you trying to patch/fix here? The thread title implies the digital signature, for which certain components will check against during boot. WRP is not dependant on the digital signature, but rather file-hash focused. Patchguard is a driver-only protection, and does not bother with anything else..

[CoffeeFiend]

joakim, on 19 March 2012 - 01:48 PM, said:

What exactly are you trying to patch/fix here?

Just in case you were asking me (but it sounds more of a question for fdv): I have absolutely NO idea whatsoever. I don't really plan on patching anything actually (I'm just poking around), nor do I know what even needs "deprotecting" or for what reason. I have yet to encounter something Windows won't let me do (while running elevated) since Vista so I never looked into it.

[dencorso]

Try installing karyonix's DiskMod on 7 x64, and you'll be stuck with /TESTSIGNING for good. Whenever you decide to use any unusual, (but perfectly legitimate) driver, like the one I just mentioned, you'll have a motive to want to get rid (preferably reversibly) of digsig checking. That's why.

[joakim]

If you want to use an "alternative/non-standard" driver without using TESTSIGNING, then you for sure need to look into patch guard (unless you just want to remove the TESTSIGNING watermark..). Some people apparently managed to fix patch guard some time ago, but that method no longer works. Bypassing patch guard is not an easy task.