You'd be surprised to know that this strategy works quite well! Pixel bots require a hardware fake display when faced with kernel anti-cheat. They also depend on color/pattern recognition, as AI is not yet capable of operating at the frame rates required for competitive games. That allows the bait to be seen by a bot, but invisible to the eye.
If you are successfully baited and detected, you also get HWID banned, so it only takes once. This makes cheating via pixel bot unviable.
On the contrary, DMA is so desired because it eliminates this risk.
> "How come replay analysis doesn’t catch more cheaters?"
1) There's too many players.
2) Closet cheaters are extremely subjective: automated & manual moderation would be full of false positives. In these cases, functional anti-cheats actually serve to vindicate these players.
At least in Valorant, DMA is becoming impossible due to IOMMU / Memory Integrity enforcement. The only option is becoming pixel bots.
As for faking the input device: I'm sure it's possible, but I'm also sure that perfectly spoofing an input device is much easier said than done.
Even if it is possible, all they have to do is make it hard enough to where the percentage of players cheating is at the point where you will rarely if ever encounter a cheater in your matches. As far as I'm aware, Valorant is one of the only games that has accomplished that.
In my opinion, the debate about kernel anti-cheat on Windows is disingenuous fear-mongering. I'm confused why Hacker News of all places misrepresents the technical details.
You can already completely compromise the average user's privacy with an underprivileged process (nearly all of your personal information is accessible with zero privileges!), and you can already persist with administrator privileges (that is routinely given on Windows).
In regard to the "RCE attacker risk", attackers can RCE to escalate just as easily into vulnerable Windows services (there's too many to count). Kernel drivers aren't that special.
In regard to the "CrowdStrike risk", that's not privacy related and is extremely overblown.
What exactly does a kernel driver change regarding privacy? Nothing I can think of.
It's this simple: If games want your personal data, they don't need a kernel driver to get it.
I don't disagree. Clarifying, I personally don't think this exploit is a backdoor, but rather that the negligence is enough to appear malicious.
Just for fun (not saying I believe this!): Did you ever consider that a malicious Microsoft employee may have intentionally planted this exploit? They don't have access to signing keys. They aren't able to make custom firmware. However, what they can do is leave innocent looking code in Windows that they and their co-conspirators can exploit later. Completely possible (-:
If the device does not have BitLocker, WinRE already by default provides full Administrator access to the unencrypted disk via Command Prompt.
> I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.
If you look in the other threads about this, it's much more obvious. Look for brand new users. There's comparatively few in this thread, but the pattern is there: if the user's name is green, they're downplaying this.
If the device doesn't have BitLocker, this exploit is pointless because you can already boot any OS USB and immediately have full access to the unencrypted disk.
This exploit is only ever relevant with BitLocker enabled (as a method to "bypass" BitLocker's security premise [categorically classifying this as, dare I say, a "BitLocker bypass"]).
To avoid typing 1)2)3)4) a bunch of more times, I'll just say 2/3/4) all still fit the definition of downplaying the situation.
1) Except that the entire premise behind BitLocker TPM's security relies on the login screen as a hard security boundary, and thus any attack on the login screen is an attack on BitLocker. It is semantics to dispute this and certainly fits "downplaying."
2) I'm sure many organizations are thankful that the researcher has decided not to release that exploit chain at this time. I am hopeful that Microsoft will not be as dismissive and will resolve it before it is publicly released.
3) It distracts from the point. The point is that Microsoft's security record is so bad that many of the vulnerabilities appear deliberate and obvious enough to be backdoors.
4) Yes, this also fits the definition of downplaying.
Considering the researcher had already reported these to Microsoft, and delayed releasing them publicly until Microsoft "pulled every childish game possible" (quote) instead of patching them, it's not unreasonable for the researcher to be withholding another exploit from the public to limit harm.
I also disagree that the PIN bypass would be "10 times more impressive," but that's just my professional opinion.
But it doesn't. Full authentication bypass exploits are extremely rare and unheard of among tech giants. Maybe account takeover/recovery, sure, but full bypass? It just never happens.
Microsoft goes beyond that: they've managed to have a critical vulnerability in almost every authentication product they have ever created. It's exceptional.
I knew there was another incident that I was forgetting, insanity... I don't understand how Microsoft keeps getting away with this and everyone just forgets.
Microsoft has never been good at security, and that is why their centralization to cloud is absolutely terrifying.
I'm reminded of Storm-0558 [1] where a stolen signing key was able to forge authentication tokens for any MSA / Azure AD / Government AD user. They downplayed the severity. Just imagine if that level of access was used to pull a Stryker on a nation-wide scale. That is an economic disaster waiting to happen.
I'd use WireGuard in that case. The main reason WireGuard is popular at all is because it is approachable. IPsec is much more complicated and is designed for network engineers, not users.
That's a large packet benchmark, not mixed packet size, and it just barely hits it. If you need consistent 10Gbps for a business use case, I would not consider that sufficient.
> "To me, the bulk of Tailscale's overhead comes from the fact that the dataplane is running between user and kernel space."
Yes and no, it's more complicated. DPDK is the industry standard library for fast packet processing, and it is in entirely user space. The Linux kernel netstack is just not very fast.
If you are successfully baited and detected, you also get HWID banned, so it only takes once. This makes cheating via pixel bot unviable.
On the contrary, DMA is so desired because it eliminates this risk.