Steamをインストール
ログイン
|
言語
简体中文（簡体字中国語）
繁體中文（繁体字中国語）
한국어 (韓国語)
ไทย (タイ語)
български (ブルガリア語)
Čeština（チェコ語）
Dansk (デンマーク語)
Deutsch (ドイツ語)
English (英語)
Español - España (スペイン語 - スペイン)
Español - Latinoamérica (スペイン語 - ラテンアメリカ)
Ελληνικά (ギリシャ語)
Français (フランス語)
Italiano (イタリア語)
Bahasa Indonesia（インドネシア語）
Magyar（ハンガリー語）
Nederlands (オランダ語)
Norsk (ノルウェー語)
Polski (ポーランド語)
Português（ポルトガル語－ポルトガル）
Português - Brasil (ポルトガル語 - ブラジル)
Română（ルーマニア語）
Русский (ロシア語)
Suomi (フィンランド語)
Svenska (スウェーデン語)
Türkçe (トルコ語)
Tiếng Việt (ベトナム語)
Українська (ウクライナ語)
翻訳の問題を報告
ルールとガイドライン
この投稿を報告する
Of course there will always be cheaters, there are even cheaters in games using kernel level anticheats, so whats the point then?
Im thinking about going over to Linux in the near future. Or maybe buy a new PC where I install Linux and keep all my personal files and projects, and on my other PC I just install Windows and games only, without any personal stuff.
The privacy concern is a lesser concern wrt kernel modules.
There are greater problems with kernel modules, esp. poorly maintained ones.
Firstly, any programming error in kernel space can corrupt kernel memory and cause a kernel panic - the typical "Blue Screen of Death" (BSoD) on Windows. Over the years many anti-cheat and DRM kernel modules have been identified or indicted as causing such system crashes.
On top of that, the things anti-cheats are doing in kernel space: hooking into all kinds of other things to monitor, cloaking themselves from other software, etc. are all using very precarious techniques - none of which follow any kind of best practice or any kind of guarantee that they'll work correctly when paired with any other kernel modules present on the system, and often they'll be intentionally over-complicated by attempts to obfuscate what the anti-cheat is doing. All of this is brittle as all heck. And the tiniest of slip-ups can readily snowball into a full-on hard crash or system hang, along with causing data corruption on any live storage drives.
And of course the odds of such problems being patched out of older versions of an anti-cheat delivered with a certain older game, are basically zero - unless you're dealing with a centralized installation of an anti-cheat that keeps itself up-to-date. (In which case, you also have to ask yourself how it does that securely...)
Secondly, any programming error in kernel space opens up the possibility of exploitation. If communication from user space to the kernel module is not properly secured and authenticated, and if input from user space is not properly sanitized, it can give rise to all manner of scenarios where attackers can use specially crafted input to get the kernel module to execute arbitrary code in kernel space. This would bypass all protections including token split administrator rights offered by Windows' User Access Control (UAC) and basically gives them direct access to hook in a system-wide rootkit. Worse, already running in kernel space means they can use system calls to directly access UEFI and flash modified infected firmware, that's made capable of reinfecting an installed operating system with the same rootkit in perpetuum.
As anyone can tell you:
to prevent becoming a target for this kind of thing, you want to keep your software up-to-date and patched up against any discovered exploits. And as mentioned before, this is exactly what tends to not happen with anti-cheats and games - in particular older games.
Which is worthless, because cheats can also reside one level further up in a hypervisor OS that is loading the real OS with a transparent passthrough.
Friendly reminder: Black Lotus exists and SecureBoot, which is supposed to provide a guarantee that the bootloader chain hasn't been tampered with, is already compromised and will never be fixed because doing so involves rotating cryptographic keys which would break SecureBoot and prevent booting up of any existing system already out there in the wild.
It's security theater and selling snake-oil to big-wigs in suits-&-ties that don't understand technology for big money. It's basically a small step-up in how tough it is to work around, that's being sold as if it's the golden hammer to end all problems.
Or perhaps you use cheats that do rootkit behavior like that?
Some will attempt to hide themselves and what they're doing on a system to frustrate and prevent reverse-engineering efforts. Others take a more ... pro-active stance, such as killing kernel-level debuggers outright if they spot any. Mostly though, nowadays they just refuse to start if the Windows options for unsigned drivers or kernel level debugging are enabled; or if SecureBoot is disabled on Windows 11. (Since Windows 11 formally is only supported on machines that support SecureBoot, they can take it as a requirement to have it enabled.)
Classy. Can't bother to formulate a proper counter-argument in response, so let's resort to ad hominem and character assassination. Even using the classic "if you're not with us; you're against us" binary rhetoric.
Kindly keep your baseless slander to yourself.
A program that runs in user-space has less access to your computer than a program that runs in kernel-space.
That doesn't matter for the anticheat itself. People are not worried (or at least should not be worried) about the anticheat destroying their computer.
What people should be worried about is that a piece of malware could use the anticheat kernel driver as a means to get more access to the system it normally wouldn't be able to get on its own.
It's the same reason that running some antivirus programs actually makes your system less secure. Now instead of the virus trying to infiltrate your system, they can try to infiltrate the antivirus software itself, which already has a very wide range of permissions to access things on your system.
There's also been documented cases where antivirus software introduced vulnerabilities or bugs into other software made by other companies. For example, Chromium wanted to give the browser's render processes less access to the computer to increase its safety. Certain antivirus software caused this reduced permission set to crash the browser because it was injecting code into the browser.
The reason you should be worried about giving a program you might partially trust increased access to your computer isn't that that program is going to try to hurt you. It's that some program that gets in through a vulnerability in some software will have more routes towards getting access it wouldn't normally have to mess with your stuff.
Steam's Windows service (that's a much smaller attack space than a driver already) will only respond to commands it knows are really from game developers who uploaded those commands to the game's depots. That's why you need to be online the first time you start a lot of games. It can't verify that the signature is valid without talking to Steam's servers that are provably run by Steam because they have a cryptographic certificate from a globally trusted certificate authority saying so.
There's a lot of very complicated stuff going on and most of it is going on specifically to try to keep you safe. When a program has more access to your computer, that means there's more of a risk of it letting something else have a dangerous amount of access by accident.
This isn't just a problem for people who already have a virus on their computer - you can run Steam commands from a website - for example, accessing steam://run/480 in your browser will start SpaceWar on your computer. If there was some vulnerability in SpaceWar, that could be an entry point for a virus to get into your system.
Precisely.
Well -- with the added note that while people shouldn't be worried about anti-cheat outright destroying their computer, they should be aware that any time a kernel module fails, it's not like a normal program which fails. A normal program will just crash back to desktop. A kernel module failing might, and more often than desired actually does, result in the entire system hanging, requiring a hard reboot and suffering potential data loss and data corruption on hard drives.