Hiding execution of unsigned code in Windows system threads

Re:Hiding execution of unsigned code in Windows system threads by freeone3000 on Wednesday January 13, 2021 @07:01PM (#25769804)

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.

[ Parent | on HN ]

Re:Hiding execution of unsigned code in Windows system threads by eznzt on Wednesday January 13, 2021 @07:03PM (#25769822)

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

[ Parent | on HN ]

Re:Hiding execution of unsigned code in Windows system threads by freeone3000 on Wednesday January 13, 2021 @07:06PM (#25769851)

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

[ Parent | on HN ]

Re:Hiding execution of unsigned code in Windows system threads by eznzt on Wednesday January 13, 2021 @07:09PM (#25769872)

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)

[ Parent | on HN ]

Re:Hiding execution of unsigned code in Windows system threads by freeone3000 on Wednesday January 13, 2021 @07:18PM (#25769961)

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?

[ Parent | on HN ]

Re:Hiding execution of unsigned code in Windows system threads by eznzt on Wednesday January 13, 2021 @07:27PM (#25770057)

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.

[ Parent | on HN ]