Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


fdv

Shutting off digsig checking in Win7

Recommended Posts

May be this could help....

To disassemble setupapi.dll with DuxDebugger, just create a new project "Test.exe" and load setupapi.dll, then debug "Test.exe", and save Module as .csv or double-click in each exported function to see the code.

Edited by Max222

Share this post


Link to post
Share on other sites

Hey, folks! :hello:

Take a look at this! :w00t:

Isn't it a starting point to become sort of the SYSTEM user in Vista+ NT-OSes? :unsure:

Share this post


Link to post
Share on other sites

The problem I have with this schema is that -80- signifies that TI is a service. It runs in isolated session 0. An interacive logon is going to be -21- and a group is -32- (I think -- it's what I read here? But yet 32 is print operator? Confused :unsure: )

In other words, Admins group is SID S-1-5-32-544 but TI is S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464

Wow, I started wanting to shut off digital signature checking in Win7 and I got SERIOUSLY sidetracked :lol:

Anyway, you saw my other msg but other folks mightn't've. What I think the only real possibility is, is to open the list of files that reference the TI SID and change it to the admin group, and then pad out the extra spaces in the binary with 90's (noop). TI then "becomes" an actual user, AND TI still continues to run as a service because the EXE is still running (i.e. the service is running).

I don't feel like trying it right now, but I might get to it at some point.

Edit: more on point, I have had a look in the DLLs... there is some very naughty stuff you can do that I shall shut up about, but a curiosity was seeing a call to LAYOUT.INF. Huh?! I thought Win 7 was "redone"!

Edited by fdv

Share this post


Link to post
Share on other sites

Anyway, you saw my other msg but other folks mightn't've.

It's not so much that I didn't see it, but more like I have no idea why I'd embark on a journey to dethrone the TrustedInstaller service. It's never gotten in my way or anything so far. And it's quite likely that it'll break something (not that I have any 32 bit OS to play with). I just don't think I understand what you're up against (how it works, what it does, etc) to be of any help unfortunately.

change it to the admin group, and then pad out the extra spaces in the binary with 90's (noop)

That doesn't make a whole lot of sense to me. The SID is a string, so it's zero terminated (just make the last byte a null). NOPs would be for overwriting code you don't want to execute, not for overwriting strings. Then again, I'd be tempted to patch the code instead (not that I have *any* idea of the inner workings of that subsystem)

a curiosity was seeing a call to LAYOUT.INF. Huh?! I thought Win 7 was "redone"!

They've "redone" the installer to use WIM images, but that doesn't mean they've gotten rid of every single piece of old code that might have been used by the old installer before. It's well known that there's LOTS of legacy stuff in the Windows code base (nevermind the design decisions dating from the Win3.1 era that they're stuck with now!)

Edit: as for well-known SIDs, here's a decent list

Share this post


Link to post
Share on other sites

a journey to dethrone the TrustedInstaller service

Yeah... I should get back to what this thread was really about shouldn't I :blink:

Thanks for the tip on padding out a SID's string.

I need to stop being distracted and get back on track. But first lots of sleep as usual. I made notes, not in front of me, and only got where I got because of your solid recommendation on a good decompiler :whistle:

Share this post


Link to post
Share on other sites

Session0Cmd

:o 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)

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...