Hiding execution of unsigned code in Windows system threads • Hacker News Board

Re: Hiding execution of unsigned code in Windows system threads

#21

Post by eznzt » Thu, Jan 14, 2021, 12:27 AM UTC

freeone3000 wrote: post #20

eznzt wrote: post #18

Earlier quoted context omitted.

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.

Re: Hiding execution of unsigned code in Windows system threads

#22

Post by SulfurHexaFluri » Thu, Jan 14, 2021, 12:27 AM UTC

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

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.

Re: Hiding execution of unsigned code in Windows system threads

#23

Post by AnthonyMouse » Thu, Jan 14, 2021, 7:12 AM UTC

zinekeller wrote: post #9

AnthonyMouse wrote: post #8

Earlier quoted context omitted.

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

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…

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.