Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account


Photo

Shutting off digsig checking in Win7


  • Please log in to reply
25 replies to this topic

#1
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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


How to remove advertisement from MSFN

#2
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

#3
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag

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)
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#4
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.

#5
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag

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 :(
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#6
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.

#7
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • OS:Windows 7 x64
  • Country: Country Flag
@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, 12 February 2012 - 02:03 AM.


#8
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag

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.
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#9
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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

#10
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag

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.
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#11
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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

#12
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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.
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#13
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.

#14
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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, 13 February 2012 - 11:27 PM.


#15
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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.
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#16
Max222

Max222
  • Member
  • 1 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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, 14 February 2012 - 07:04 AM.


#17
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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:

#18
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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, 17 March 2012 - 12:00 AM.


#19
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag

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
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#20
fdv

fdv

    MSFN Expert

  • Developer
  • 1,111 posts
  • OS:Windows 7 x64
  • Country: Country Flag
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:

#21
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,038 posts
  • OS:none specified
  • Country: Country Flag
Maybe useful :unsure: (or maybe completely NOT like so :ph34r: ), Session0Cmd:
http://reboot.pro/16550/

jaclaz

#22
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag

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)
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#23
joakim

joakim

    Member

  • Member
  • PipPip
  • 154 posts
  • OS:none specified
  • Country: Country Flag
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..

#24
CoffeeFiend

CoffeeFiend

    Coffee Aficionado

  • Super Moderator
  • 5,399 posts
  • OS:Windows 7 x64
  • Country: Country Flag

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.
Coffee: \ˈkȯ-fē, ˈkä-\. noun. Heaven in a cup. Life's only treasure. The meaning of life. Kaffee ist wunderbar. C8H10N4O2 FTW.

#25
dencorso

dencorso

    Adiuvat plus qui nihil obstat

  • Super Moderator
  • 5,782 posts
  • OS:98SE
  • Country: Country Flag

Donator

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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users



How to remove advertisement from MSFN