Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hiding execution of unsigned code in Windows system threads

secret.club

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Hiding execution of unsigned code in Windows system threads

#11

Post by passivate »

zinekeller wrote: post #7
userbinator wrote: post #6

Earlier quoted context omitted.

"tamper". That connotation is intentional. MS wants to take control away from users and owners, so uses such language. How about "modify" or "customise"? No, because that wouldn't fit their authoritarian narrative.

Noted and changed. > MS wants to take control away from users and owners, so uses such language. I wanted to clarify this issue in logner detail but obviously outside of enterprise settings (which the owner does not trust the user). Now, I'm writing to HN here, which really likes its freedoms (and I also want it). But the general pattern nowadays is that people value the consistency over customisability. The success…

> But the general pattern nowadays is that people value the consistency over customisability.

Personally, I value both. I want all the modern so-called 'tamper proof' features that an OS has, but I also want myself to be in control of all of them. I am fine with switching them on so that only signed code is executed and let the OS maker handle certificate revocation and all that. But if I want to use it as a dev box, I also want the option to turn it off.

Ditto for customization - I want the ability to tweak and change tuning/configuration parameters for performance reasons, for productivity reasons, for aesthetic reasons, but I also want a 'force defaults' and/or disable customizations option for when I'm setting up the computer for a family member, etc.

Re: Hiding execution of unsigned code in Windows system threads

#12

Post by eznzt »

mckirk wrote: post #4
londons_explore wrote: post #2

I thought the windows kernel was locked down to signed code only by Microsoft's patchguard? Wouldn't any opportunity to run your own code in the kernel be worthy of a bug bounty? Are the protections nowhere near as strong as intended?

There is so many ways of running your own code in the kernel (mainly thanks to signed, but terribly written drivers [1]) that PatchGuard really is only a nuisance if you need to overwrite some kernel functionality, e.g. for hooking functions. So a rootkit needs to worry about PatchGuard, but if you only want to run code at kernel level, you generally don't. [1]: https://www.unknowncheats.me/forum/anti-cheat-bypass/33…

Can I install those drivers and do they run even if I don't own the pertinent hardware?

Re: Hiding execution of unsigned code in Windows system threads

#13

Post by freeone3000 »

eznzt wrote: post #12
mckirk wrote: post #4

Earlier quoted context omitted.

There is so many ways of running your own code in the kernel (mainly thanks to signed, but terribly written drivers [1]) that PatchGuard really is only a nuisance if you need to overwrite some kernel functionality, e.g. for hooking functions. So a rootkit needs to worry about PatchGuard, but if you only want to run code at kernel level, you generally don't. [1]: https://www.unknowncheats.me/forum/anti-cheat-bypass/33…

Can I install those drivers and do they run even if I don't own the pertinent hardware?

Drivers don't require any particular hardware to function -- they can be triggered to autoload on hardware detection, but you can also trigger them on demand, or on startup. As an example, ProcExp uses a driver to list open handles.

If you're interested in running kernel code on your own device, it's simpler to just write your own driver.

Re: Hiding execution of unsigned code in Windows system threads

#14

Post by eznzt »

freeone3000 wrote: post #13
eznzt wrote: post #12

Earlier quoted context omitted.

Can I install those drivers and do they run even if I don't own the pertinent hardware?

Drivers don't require any particular hardware to function -- they can be triggered to autoload on hardware detection, but you can also trigger them on demand, or on startup. As an example, ProcExp uses a driver to list open handles. If you're interested in running kernel code on your own device, it's simpler to just write your own driver.

You can't run unsigned kernel drivers unless you boot the operating system in test mode, right?

Re: Hiding execution of unsigned code in Windows system threads

#15

Post by freeone3000 »

passivate wrote: post #11
zinekeller wrote: post #7

Earlier quoted context omitted.

Noted and changed. > MS wants to take control away from users and owners, so uses such language. I wanted to clarify this issue in logner detail but obviously outside of enterprise settings (which the owner does not trust the user). Now, I'm writing to HN here, which really likes its freedoms (and I also want it). But the general pattern nowadays is that people value the consistency over customisability. The success…

> But the general pattern nowadays is that people value the consistency over customisability. Personally, I value both. I want all the modern so-called 'tamper proof' features that an OS has, but I also want myself to be in control of all of them. I am fine with switching them on so that only signed code is executed and let the OS maker handle certificate revocation and all that. But if I want to use it as a dev box,…

Windows developers develop for Windows on Windows, including kernel developers. The guardrails are lowerable - you can disable SmartScreen, Protected Boot, even Kernel Driver Signing Verification. Nothing prevents you from making your system as insecure as you'd like

Re: Hiding execution of unsigned code in Windows system threads

#16

Post by freeone3000 »

eznzt wrote: post #14
freeone3000 wrote: post #13

Earlier quoted context omitted.

Drivers don't require any particular hardware to function -- they can be triggered to autoload on hardware detection, but you can also trigger them on demand, or on startup. As an example, ProcExp uses a driver to list open handles. If you're interested in running kernel code on your own device, it's simpler to just write your own driver.

You can't run unsigned kernel drivers unless you boot the operating system in test mode, right?

Correct. It's advisable to do it on a VM or another computer you own, rather than your main computer.

Re: Hiding execution of unsigned code in Windows system threads

#17

Post by passivate »

freeone3000 wrote: post #15
passivate wrote: post #11

Earlier quoted context omitted.

> But the general pattern nowadays is that people value the consistency over customisability. Personally, I value both. I want all the modern so-called 'tamper proof' features that an OS has, but I also want myself to be in control of all of them. I am fine with switching them on so that only signed code is executed and let the OS maker handle certificate revocation and all that. But if I want to use it as a dev box,…

Windows developers develop for Windows on Windows, including kernel developers. The guardrails are lowerable - you can disable SmartScreen, Protected Boot, even Kernel Driver Signing Verification. Nothing prevents you from making your system as insecure as you'd like

Agreed, we can have both.

Re: Hiding execution of unsigned code in Windows system threads

#18

Post by eznzt »

freeone3000 wrote: post #16
eznzt wrote: post #14

Earlier quoted context omitted.

You can't run unsigned kernel drivers unless you boot the operating system in test mode, right?

Correct. It's advisable to do it on a VM or another computer you own, rather than your main computer.

Sure, but this is in the context of wanting to run kernel code to cheat in a video game (which is what that forum post is about)

Re: Hiding execution of unsigned code in Windows system threads

#19

Post by [deleted] »

eznzt wrote: post #18
freeone3000 wrote: post #16

Earlier quoted context omitted.

Correct. It's advisable to do it on a VM or another computer you own, rather than your main computer.

Sure, but this is in the context of wanting to run kernel code to cheat in a video game (which is what that forum post is about)

[deleted]

Re: Hiding execution of unsigned code in Windows system threads

#20

Post by freeone3000 »

eznzt wrote: post #18
freeone3000 wrote: post #16

Earlier quoted context omitted.

Correct. It's advisable to do it on a VM or another computer you own, rather than your main computer.

Sure, but this is in the context of wanting to run kernel code to cheat in a video game (which is what that forum post is about)

I feel like I'm missing something here. You can run games in test mode. Anticheat code will obviously trip, hence, the hiding... But anticheat also trips if you have the wrong brand of mouse. The context is informative, but doesn't really change anything?
Post reply on HN