Hacker News new | past | comments | ask | show | jobs | submit login
Hiding execution of unsigned code in Windows system threads (secret.club)
87 points by jm1337 3 days ago | hide | past | favorite | 21 comments





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


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?

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?

Fortnite for example refuses to run if you boot in test mode. I don't play online much so I assumed it was standard behaviour in multiplayer games.

Well, in this case the user really wants to modify the system so they can either 1) run it with Secure boot disabled, 2) use poorly-coded or outdated kernel drivers such as the list mentioned by mckirk (https://news.ycombinator.com/item?id=25766871) to bypass NT policies, or 3) Install Windows in BIOS/CSM mode (so that the only hindrance is the generation of root certificates, unlike with UEFI installations which triggers the kernel to check if the drivers loaded is blessed by Microsoft).

"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 of locked-down iPhone and Android is a great example: sure some users wants to run other software on the device but the simple truth is vast majority of users prefers to trust Apple or Google to do their job properly as their main goal is not to run a computer but rather to do their own business (similar to how a company often contracts its electricity, water, network connectivity, waste management and others).

On a similar vein, the newer versions of Windows will run with the secure boot option enabled (which will ensure that the system is as intended by Microsoft). Again, some people wants the system to be easily modifiable, and in that case there are ways to lower the guardrails to allow you to a certain extent. But the vast majority of users trusts Microsoft to manage the system and let them just do work.

TLDR: Some users view a computer as something to tinker upon but most users see it as a tool to be used.


> The success of locked-down iPhone and Android is a great example

It's the example that everybody uses, but because of the nature of vertical integration and the network effect, you can't use popularity as an indication that people actually want any given individual aspect of those products.

Suppose it's 2010 and you need an app that only exists on iPhone. Well, you might not like that it's locked down, but you need that app. Then once you've had one for three years you're locked into their ecosystem indefinitely.

It's also a trap. When the lockdown first comes, they say they're just using it to exclude malware and other things you actually don't want. You have to get your apps signed, but they sign all the ones you care about, so what does it matter?

Only after mobile platforms that don't do this have reached negligible market share and have no network effect do they start excluding apps you might actually want. But by then it's too late.


Now, I do really want to agree to your analysis, but knowing how many Desktop Linux users are either just using a browser or Electron app (consistency) or Wine (consistency) and the fact that essential libraries (from the Gnome 2->3 debacle to systemd to unreliable semantic versioning) are much more unstable (which makes a non-consistent environment, and even Debian is discussing this very issue again), I am not sure if an average user really wants to have customisability versus consistency.

There is a difference between wanting the ability do something and actually doing it.

The former is important because it makes itself unnecessary. If 90% of people are installing some third party modification, the developers notice and incorporate it into the ordinary installation, and then they don't need to anymore.

But without the ability to do that, that doesn't happen, and then everything is worse because you not only can't install it as a mod, it also then can't become popular enough as a mod to be incorporated into the standard distribution.


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


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

Yep, the point of this post seems to be to get full access without turning off the safeties because that will trip anti cheat software.

Agreed, we can have both.

That's two separate mechanisms; PatchGuard protects against hooking and rewriting sections of the kernel, and the kernel only loads signed drivers (and since 2016-ish only Microsoft-signed).

APC means asynchronous procedure call, for anyone else unfamiliar with the term. https://docs.microsoft.com/en-us/windows-hardware/drivers/ke...



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: