Jump to content

Shutting off digsig checking in Win7


fdv

Recommended Posts

Any of y'all want to try something for me?

I aim to repeat my SETUPAPI.DLL hack that I did for Windows 2003 to allow for an install that shuts off signature checking. The idea is to be able to modify binaries and not have Windows complain or throw a terminal error.

This is a theory. I don't have time to try it right now. (I am sick with an ear infection and have a burst eardrum and spent about four hours carefully mapping this out last night so I am not in the mood to check it right now, I have had enough for now, but I suppose you younger and more enterprising folks could try).

You need to mount the INSTALL.WIM image and load a hex editor and take ownership of SETUPAPI.DLL and then open it in the hex editor.

replace byte sequence

8B FF 55 8B EC

with

33 C0 C2 0C 00

Should be the same for both the 32 and 64 bit SETUPAPI.DLLs. There is only one such sequence in both DLLs so there is no offset to worry about finding.

The digsig check began with

MOV EDI,EDI

PUSH EBP

etc etc in the Win Xp and 2003 binaries. The hack for those was simply to change it to

XOR EAX,EAX

RETN [whatever]

The routine in the win7 followed the same pattern, but it was WAY earlier in the binary. Still, it does follow the pattern, so it's worth a shot.

I have other ideas if this doesn't work.

Anyway save and use modifype.exe to 'fix' the DLL and then put it back into your mounted directory.

There is also a TrustedInstaller bit in the dll that I intend to explore as well, later. I get that TrustedInstaller is necessary but it would be nice if it didn't take ownership of my entire registry too...

Thanks, whoever wants to give it a try

fdv

Link to comment
Share on other sites


:thumbup Now, that's an interesting project!

I'd give it a shot myself, but I've got no machine using Win 7 ATM, although I've bought Win 7 and intend it to be one of the OSes of my next machine (which ATM is just a bunch of parts which assembly I can still assign no ETA, unfortunately).

Anyway save and use modifype.exe to 'fix' the DLL and then put it back into your mounted directory.

Just a heads up: modifype.exe is not a good idea anymore, since it refuses to work right under Vista and 7. n7Epsilon's PEChecksum.exe should be used instead, in all cases.

Link to comment
Share on other sites

I aim to repeat my SETUPAPI.DLL hack that I did for Windows 2003 to allow for an install that shuts off signature checking. The idea is to be able to modify binaries and not have Windows complain or throw a terminal error.

I'm trying to understand here. You want the installer not to complain only? Or does that affect the installed OS as well?

I'll probably mount install.wim later (don't have the WAIK installed or anything), but those bytes definitely aren't in the installed setupapi.dll (i.e. from a Win7 install, in Windows\System32). Or is there somehow two different binaries with the same name (one for setup, one for a running install)?

This is very interesting. Win7 x64 is rather well protected from tampering, and the way Win8 looks right now ( :puke: ) I feel we might be running Win7 for quite some time, so tweaks, patches and changes might come in handy later on.

Edit: 7zip seemingly opens wim files. So I extracted setupapi.dll from Windows\System32\, from a Win7 x64 image with SP1 and I can't find those bytes in there either. However, the 32 bit setupapi.dll from \Windows\SysWOW64 does contain them. The matching bytes are the very first bytes of the dll entry point @ 0x734b17e7. I thought you'd be patching an exported function instead. Not that I ever peeked at the old patch or dll.

Again, I'm not quite sure what functionality we're patching here, and there seems to be many layers to take care of (patchguard, sfc, signatures, etc)

Link to comment
Share on other sites

I think fdv was referrring to Win 7 x86, since that's the OS displayed in his profile. And your finding it in the 32-bit version in SysWOW64 tends to confirm it. The byte pattern in x64 should be different, and probably use 64-bit registers instead.

Link to comment
Share on other sites

I think fdv was referrring to Win 7 x86, since that's the OS displayed in his profile

Probable. I just assumed that

Should be the same for both the 32 and 64 bit SETUPAPI.DLLs

meant he had found it in both or something.

The byte pattern in x64 should be different, and probably use 64-bit registers instead.

Well, the entry point sure is different. 64 bit registers is one thing, but the calling convention is completely different on x64 too (how args are passed, how the stack is used, who cleans it up, etc). For the record, in the x64 DLL the entry point is at 0x000007FF79A21010 and it starts with 48 89 5C 24 08 48 89 74 24 10 57 48 83 EC 20 49 8B F8 8B DA 48 8B F1 (it takes a LOT more bytes for it to be unique, it's @ 0x610 in the file). Either ways, that would be easy to patch as well. I'm just not sure why we'd make the entry point return zero instead of patching some export that's used to check signatures. Again, not that I ever toyed with installed with invalid digital signature or whatever before.

Oh, and this:

MOV EDI,EDI

a.k.a. the 2 byte NOP.

Either ways, disabling the other parts might be quite involved. See this code/article for how to bypass PatchGuard :(

Link to comment
Share on other sites

Well, I have no experience whatever with x64 code but the link you provided about PatchGuard shows it really is complex.

However, I have sufficient experience with patching x86 code to agree that it would be better to patch the x86 code below the 2-byte NOP, to avoid surprises. But, as far as making the entry-point return 0, on x86 at least, it's a good bet. The least the patch the better chance it has of working right. Of course, here the idea of making things simple enough, but not any simpler, fits like a glove.

Link to comment
Share on other sites

@dencorso, thanks for the new PE fix. I am very behind the times!

"The byte pattern in x64 should be different, and probably use 64-bit registers instead. "

Whoops, yeah, I am a retard :blushing:

@coffeefiend - "You want the installer not to complain only? Or does that affect the installed OS as well?"

It should skip the check. More than just not complain. I think I must have loaded the wrong binary. It was pretty late ;-)

I thought patchguard was only for the kernel??

I gotta think this through and switch to the 64 bit version. I read the info on patchguard, I can't see that it applies to a setup DLL.

I am wondering, is this DLL now only driver signature checking?

I stumbed upon the following this morning:

7252A07A |. 68 C8504D72 PUSH setupapi.724D50C8 ; UNICODE "S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464"

(direct paste but which DLL I don't know. it's been a long day and I have been looking at all of them, the x86, the sxs, the wow64 so ignore that address?)

This is the SID for Trusted Installer. I need to go to bed and haven't done anything with it but in this case I'd like to not only shut off digsig checking (sfc would be nice too) but I'd love to prevent TrustedInstaller from making itself the sole owner of my registry!

This technique worked for the earlier OS's BTW and for a short while, before 7imo modified SYSSETUP, Nuhi was using this little trick in nLite to keep the OS from complaining about unsigned binaries (of any kind, drivers or OS files).

So, much more work remains :sneaky:

If anyone has any tips, clue me in! Many eyes looking can make this quick work. Provided the 64bit dll can be modified without Patchguard problems.

What do you guys recommend for a 64bit debugger thx

God this stuff takes so **** long...

Note to self - click here to log in (since it's gone from the pages now?)

Edited by fdv
Link to comment
Share on other sites

It should skip the check. More than just not complain.

That's the part I'm trying to understand (it won't copy any modified files otherwise? even if the PE checksum is fixed?). Again, I never tried making install discs with modified files so you can call me a n00b :)

I thought patchguard was only for the kernel??

Probably. If you just want to copy modified files, it's probably not an issue. I was thinking of the scenario where Win7 is the last usable version of Windows ever, and we want to patch stuff (much like the Win9x'ers are doing now). Patchguard would likely get in the way here.

I am wondering, is this DLL now only driver signature checking?

I was thinking you'd be the one to answer this ;) I've written code that uses the SetupAPI to detect hardware and such things, but patching the entry point makes no real sense to me (it's typically the initialization code for the dll). Unless this specific DLL checks signatures of files when it's first loaded (that'd be weird really)

7252A07A |. 68 C8504D72 PUSH setupapi.724D50C8 ; UNICODE "S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464"

(direct paste but which DLL I don't know. it's been a long day and I have been looking at all of them, the x86, the sxs, the wow64 so ignore that address?)

The 64 bit setupapi.dll also references it in a few places, namely inside the pSetupIsUserTrustedInstaller export which is not very well documented:

.text:000007FF79AA1989 48 8D 0D 30 B1 04 00 lea rcx, StringSid ; "S-1-5-80-956008885-3418522649-183103804"...

.text:000007FF79AA1A0A 48 8D 0D AF B0 04 00 lea rcx, StringSid ; "S-1-5-80-956008885-3418522649-183103804"...

then later on here:

.text:000007FF79AD6337 48 8D 0D 82 67 01 00 lea rcx, StringSid ; "S-1-5-80-956008885-3418522649-183103804"...

A string 6 instructions above loads the string d:\\w7rtm\\base\\subsys\\sm\\sfc\\wrpdisable\\"..., then followed by "[%ws] is not protected.\n", "Error %08d taking ownership of [%ws]\n", "Error %08d setting write privileges of ".., "Success removing protection on [%ws]\n", etc. That's quite likely the SFC protection or rather WRP which also protects a lot of stuff (it's called by the PnpRepairWindowsProtectedDriver function)

And it's referenced (the trusted installer SID) in a few more places, being contained inside of other strings.

Link to comment
Share on other sites

In some contexts subverting is much more handy than disabling... :angel

If a way is found to log in as the TrustedInstaller, or to become it (just as one can become the SYSTEM user in XP), that would be a huge step in the right direction, IMHO. :D

Link to comment
Share on other sites

In some contexts subverting is much more handy than disabling... :angel

If a way is found to log in as the TrustedInstaller, or to become it (just as one can become the SYSTEM user in XP), that would be a huge step in the right direction, IMHO. :D

There's some wisdom in there :)

Well, I have no experience whatever with x64 code

It's mainly the calling convention that's different (besides the registers being wider, obviously). It's kind of like the 32 bit fastcall in that you pass some args in registers instead of on the stack (still right to left). Except that there are more registers (rcx, rdx, r8, r9 -- it almost feels like the 32 bit MIPS arch which uses $0 to $3), FP stuff does in xmm0 to xmm3 and the rest on the stack. Oh, and the caller cleans the stack, not the callee. Otherwise it's very much the same. You'd adapt in mere minutes.

Link to comment
Share on other sites

What is a good 64 bit debugger?

I tried the Microsoft one and it's HORRIBLE. Tried DuxDebugger and it will not load DLLs.

?

thx all

yes btw I really need to look at exported functions, posting the entrypoint was in error. I need sleep

Link to comment
Share on other sites

IDA Pro is great, if you can afford it. It's a fantastic disassembler (not just for x86 or x64 -- it supports lots of other architectures) but it can also make use of several debuggers (several included, plus WinDbg, GDB, Bochs...). You just put breakpoints in the disassembly then start the process or attach to an already running process. You can even debug processes on other OS'es or platforms remotely (via TCP/IP). It's pretty easy to use as well. It's a fantastic tool to use (arguably the best by a long shot) but yeah, it's expensive.

Edit: as dencorso said, there's an older (from 2006) free version. It lacks a LOT of really nice and modern features (x64 support, most debuggers, support for a lot of platforms and architectures, hex-rays, new signatures, plugins, etc). But that's sadly still much better than most of the others.

Link to comment
Share on other sites

Well, it has no 64-bit support, and lacks a lot of bells and whistles, but let's not forget IDA Freeware. It's now difficult to get to it in the Hex-Rays page, but it remains in existence. This post is for the benefit of anyone who comes to this thread and gets interested by the above post, then discouraged by IDA's prices. While I do agree that the future lies in 64-bits, I reckon there's still much to be done in 32-bit yet, as of now. ...and ther is the IDA Palace, of course.

Link to comment
Share on other sites

I feel like I'm at a full stop without a solid 64 bit debugger.

I ran a list of exported functions but I don't see a reason to get into 32 bit. (I am using amd64 now and as it's been pointed out, it's the future).

I tried ollydebug with a 64 bit plugin but it didn't work.

IDA is amazing but wow, a thousand bucks!! I wish I could con my employer into buying it ;-)

I don't know anything about x64 so I am wondering if I (we? I think you guys are in on this too I hope :D ) should bother with 32 bit and would any of that apply to the 64 bit dll? In other words, could we use the findings or would it be like starting from scratch?

Edited by fdv
Link to comment
Share on other sites

Indeed, Olly is worthless on 64 bit systems (not that I really cared much for Olly in the first place). And it's also just a debugger. I typically do a large part of my work with a disassembler (yet again, nothing comes close to IDA), and I use the debugger to figure out certain tricky parts (e.g. setting a HW BP on memory access on some data to see where else it gets used again, or setting a BP after a custom hashing function to see what hash was generated for some hardcoded password that's used later as a key to perform symmetric encryption, etc).

I don't know anything about x64 so I am wondering if I (we? I think you guys are in on this too I hope :D ) should bother with 32 bit and would any of that apply to the 64 bit dll? In other words, could we use the findings or would it be like starting from scratch?

If you successfully patch the 32 bit DLL I should be able to patch the 64 bit DLL in a few minutes of work. The code should be quite similar (they're doing the same job, calling the same functions, etc -- larger registers and a different calling convention don't really change the big picture all that much).

Even just knowing what bytes you changed, I could easily track that down in the disassembled x86 DLL, see in which function/export it is, what's being done at that point in time (things like specific strings help too), and find the same code in the x64 DLL and patch it similarly. That usually does the trick.

My main problem is that I have no idea what program makes the calls, what function is called and so on (where/how the checks are being made). Not understanding how this undocumented system works and not having time to devote to researching that (I've got WAY too much work here), it's hard to just come up with a patch on my own.

So yes, it would be extremely helpful if you patched the 32 bit version.

Link to comment
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...