Quoting: CreakDisclaimer: sorry didn't have the courage to read the 8 pages ^^'

So.... I don't see the link between the kernels and the anti-cheat?! I don't know much about the ins and outs of Anti-Cheat software, so I'm doing some reading right now. Of course, I am no expert because I've read a few pages about it. But I am still an experienced developer, and have a pretty good knowledge of security overall.

I am intrigued to understand why the kernel variations are an issue for an anti-cheat software. I mean... Is EAC storing all the hashes of all the Windows DLLs, their variants, and the graphics drivers, for each releases, including the DLLs/drivers that are currently in development so that developers can test them? Seems like a daunting task.

From what I've read, the solution is more to have a unique signature send frequently to the server, proving that you are not running a different code and thus not cheating. A kernel (whichever variation you have) is basically a set of functions to talk to your hardware. I would understand that an AC software would need a very specific set of features and so the solution would be to support kernels starting from a very specific version. I'm trying to understand how modifying the kernel source code becomes an issue.

Also, security by obscurity has never been a solution. Take a look at HTTPS, it allows to have a secured connection even though everything is out in the open. There are mathematicians and researchers working on these problems (and finding solutions) since the beginning of the computer science.

So I'm confused mainly, and the answers Tim Sweeney is giving us doesn't convince me (I'm not sure Twitter is the appropriate medium for this kind of explanation, but it is what it is...)

EAC needs a kernel driver so that they can override the WIN32 function CreateFile, LoadLibrary and a few others so that they can from the supervisory view of the kernel create runtime checksums of every DLL and EXE that the game loads to see that they have not been changed. Most likely they also just like anti-virus programs have signatures for some well known anti cheats and check if they are being loaded.

So basically their claim here is that only EAC can write Windows kernel drivers but on Linux every single person and their mother can write Linux kernel drivers. The idea here seams to be that the closed nature of the Windows kernel makes it harder to write drivers (which is not true since Microsoft provides tons of open documentation for how to do this) and that only EAC can do this due to the signature model that Microsoft have implemented for Windows drivers (which is not true since any one with money can buy such a certificate [I own one] and it's not illegal to write cheat software so there are no reason to not just purchase a certificate in your own name).

Their third argument looks to be that the Linux kernel changes so often so that EAC cannot create their own closed source kernel driver that works with all possible kernels out there. This one is of course true and is why e.g AMD in the end decided to open source their drivers so that they would be sure that every single new kernel would work with their drivers and they could stop the constant "chase the changes" that they did before and which nVidia have to do still (at some level since they created an open shim between the kernel and their binary blob to have a more stable API for their blob).

View this comment - View article - View full comments

So did a quick google (since Fortnite is not a game that I have ever played, and since I don't use cheats) and the first response was to https://www.iwantcheats.net/fortnite-hacks-cheats-glitches-aimbot/ [External Link] which have a long list of cheats for Fortnite, that works on Windows 10 and Windows 11.

The cheats are sold for money so there are monetary incentives to break EAC which points back to my earlier post that Windows is open source if you are a hacker. Not only does the closed source of Windows help it in any way possible, we can also see that Epic is lying out their teeth, there is no need for cheaters to force Fortnite to work on the Steam Deck in order to cheat, they can cheat right now using Windows (and they also carry cheats for consoles).

EAC only keeps out the amateurs, and the amateurs wouldn't know where to begin to create Linux kernel drivers in the first place either so this is all moot.

View this comment - View article - View full comments

Quoting: ZlopezStrange how the insecure Windows, which is targeted by every malware out there is actually more secure for anti-cheat :-D

It's not strange, it's just a lie from Epic. Windows being close source is a red herring, nothing more. For every single hacker out there Windows is as open source as Linux, it's only in the sense that you want to create a patch legally and submit it upstream that Windows becomes closed source.

View this comment - View article - View full comments

Quoting: Alm888Well, he is right.

WINE allows dll side-loading, so one can easily use a modded d3dx100500.dll with some functions (like drawing of walls or other effects) dummied-out and a modified custom Linux kernel would report everything is fine. User's access to kernel is a 0-level vulnerability in the "trust-chain". That is why WINE/Linux is not, and shall never be treated as "secure" platform. All hopes that a "client-side" anti-cheat will be a thing on WINE are just pipe dreams.

Linux and client-side anti-cheat systems are antithetical to each other as the very ideology of client-side anti-cheat measures is to strip user of any control of one's personal computer. From "trusted computing", through cryptographic measures down to "security through obscurity" concept. And Linux in particular and Open Source in general are against it all (see "libdvdcss").

How is this a WINE problem when WINE only does it because Windows does it as well? This is how windows gamers "patch" old games to support e.g wide screen.

The entire premise is wrong, the closed source nature of Windows gives it zero advantages over Linux here, there is nothing in the closed source nature that prevents the cheaters from bypassing EAC on Windows so his talk about Linux being a problem for being open is just hand waving. The truth is that EAC does not work on Windows (unless the cheater does not have access to google).

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.Ultra

Quoting: Guest

Quoting: F.Ultra

Quoting: Guest

Quoting: anewson

Quoting: BielFPsThere's one thing that saddens me about this game is that, back then when they attempt to make a native version, they didn't had vulkan and the linux graphics were in a sorrow state. That resulted in a (opengl) poor performant native version specially compared to the later Proton that made use of a more performant API.
...

Interesting, I've been wondering why for some titles using proton performs better than some native ports; this explanation makes sense to me.

It performed so bad that it can't be due to the api or the bad drivers because:
1 there are examples of opengl games that perform much better
2 Drivers now are fine, but it still performs bad.

Much of the first opengl ports were just bad coded or badly wrapped.

That the first Dying Light performed bad on Linux is news to me, now I don't know how much different it would run on Windows on my hw since I don't have Windows anywhere, but I have 117 hours into the first game and performance for me is extremely good (RX480).

https://m.youtube.com/watch?v=kKdT3RuL9jQ [External Link]

So compared with the Windows version the performance is worse but the actual performance is still not horrible but completely fine. Well that matches my experience.

The performance is very bad compared to windows and proton.
Everything would run well if you have enough cpu and gpu cycles, ofc.

The game having potential for 72fps does not matter much when my screen is 60fps anyway. Now I don't know this is due to the game, the recording, or if it's just YouTube or on my end but the linked video for DL2 stutters from time to time, this I never experienced in DL1 and I would take 30fps over that every single day.

View this comment - View article - View full comments

Quoting: Guest

Quoting: F.Ultra

Quoting: Guest

Quoting: anewson

Quoting: BielFPsThere's one thing that saddens me about this game is that, back then when they attempt to make a native version, they didn't had vulkan and the linux graphics were in a sorrow state. That resulted in a (opengl) poor performant native version specially compared to the later Proton that made use of a more performant API.
...

Interesting, I've been wondering why for some titles using proton performs better than some native ports; this explanation makes sense to me.

It performed so bad that it can't be due to the api or the bad drivers because:
1 there are examples of opengl games that perform much better
2 Drivers now are fine, but it still performs bad.

Much of the first opengl ports were just bad coded or badly wrapped.

That the first Dying Light performed bad on Linux is news to me, now I don't know how much different it would run on Windows on my hw since I don't have Windows anywhere, but I have 117 hours into the first game and performance for me is extremely good (RX480).

https://m.youtube.com/watch?v=kKdT3RuL9jQ [External Link]

So compared with the Windows version the performance is worse but the actual performance is still not horrible but completely fine. Well that matches my experience.

View this comment - View article - View full comments

Quoting: Guest

Quoting: anewson

Quoting: BielFPsThere's one thing that saddens me about this game is that, back then when they attempt to make a native version, they didn't had vulkan and the linux graphics were in a sorrow state. That resulted in a (opengl) poor performant native version specially compared to the later Proton that made use of a more performant API.
...

Interesting, I've been wondering why for some titles using proton performs better than some native ports; this explanation makes sense to me.

It performed so bad that it can't be due to the api or the bad drivers because:
1 there are examples of opengl games that perform much better
2 Drivers now are fine, but it still performs bad.

Much of the first opengl ports were just bad coded or badly wrapped.

That the first Dying Light performed bad on Linux is news to me, now I don't know how much different it would run on Windows on my hw since I don't have Windows anywhere, but I have 117 hours into the first game and performance for me is extremely good (RX480).

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: F.Ultra

Quoting: kaiman

Quoting: F.UltraI remember the days when GUI:s used color:

That pretty much changed with Workbench 2.x, however.

To protect your privacy, external media requires approval to load.

Source: i.ibb.co

View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

Guess grey never gets old for me :-)

Yeah unfortunately they changed the default to all grey, thankfully there where lots of projects like MagicWB that changed it up a bit:

To protect your privacy, external media requires approval to load.

Source: i.ytimg.com

View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

I love MagicWB. Still prefer it over the new icons that the 3.1.+/3.2 come with. Do find it awesome that 3.2.1 came out recently.

Amiga lives forever :), I have to fix my A4000 someday, it has the famous leaky battery and have been stored for over 20 years since I found that it leaked so huge change the whole MB is ruined...

View this comment - View article - View full comments

Quoting: kaiman

Quoting: F.UltraI remember the days when GUI:s used color:

That pretty much changed with Workbench 2.x, however.

To protect your privacy, external media requires approval to load.

Source: i.ibb.co

View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

Guess grey never gets old for me :-)

Yeah unfortunately they changed the default to all grey, thankfully there where lots of projects like MagicWB that changed it up a bit:

View this comment - View article - View full comments

Quoting: kaiman

Quoting: lectrode(shown on left in following image [External Link])

To protect your privacy, external media requires approval to load.

Source: i.ibb.co

View cookie preferences.
Accept & Show Accept All & Don't show this again   Direct Link

Given those three alternatives, I'm still quite fond of the regular old Windows 2000 era look (the middle one). Good contrast, easy to see what's a button/tab/etc. and what's just text. Luckily, with my usage of Wine exclusively for gaming I don't really have to deal with Windows user interfaces.

At work, where I can't avoid them I always have to jump through hoops to get something that's halfway palatable.

I remember the days when GUI:s used color:

View this comment - View article - View full comments