Quoting: Samsai

Quoting: pete910Oh come on, just about everyone knows it takes seconds to look for an apk and install it for andriod. And lets be honest, a cheater is going to know how to do basic things on any platform and there is no need for custom roms to be used. On IOS I would agree with your point.

Android is so sandboxed that you aren't going to be installing Fortnite cheats with an APK off the Internet, except if you somehow found a hacked Fortnite client that is still somehow respected by the Fortnite servers. Otherwise you'd at the very least need root in order to poke at the running processes from outside the official binary and although it can be done, it is not common knowledge. You are also still not acknowledging the other side of the issue, which is that the Android market is so unbelievably big that it's a great deal even if you have some cheaters. You just cannot equate the Android and Linux/Deck markets and assume the same risk calculus applies everywhere.

Wouldn't the much greater marker on Android make it that much more susceptible to cheaters and thus much more profitable for a cheat-dev to write an exploit for?

A quick google shows that cheats for Fortnite on Android is just a simple APK that you can sideload, what those do is apparently to replace the Fortnite launcher with one patched to load the cheats.

View this comment - View article - View full comments

Quoting: toorTo ensure that a program hasn't been modified is impossible to get totally right, it's always a fight between the pirates and the security experts.
I don't think that not having access to the source code of the kernel helps much with security. Security through obscurity is bad. The source code of the kernel can leak, or Microsoft servers can get hacked, or people can try to make sense of the binary, although "illegal", I doubt that the cheaters are concerned about it.
I guess the pirates just don't have the skill or the patience to modify the kernel, closed source or not…
Sure it would require more effort, but still, security through obscurity is a poor way to secure a system.

Also, you have to release under the GPLv2 only the modified kernel code, not the module itself.

And the entire source code for both Windows 10 and Windows XP have leaked over the years so they are out there for any one interested enough to find.

View this comment - View article - View full comments

Quoting: SamsaiEAC also contains a kernel-level component, which on Windows is installed as a kernel driver. This allows EAC code to run at a very privileged level and inspect essentially any and all parts of the system in order to detect tampering. This provides a very broad level of monitoring, which is also harder to bypass.

Yet cheaters today bypass this every single day. What they do is that they write their own kernel drivers that simply mess with the stuff that EAC looks at in order to make everything look as if the cheat wasn't there. The hard part here for the cheat-devs are not the Windows stuff, it's determining what the EAC driver is looking at, when it does it and what it expects to see.

Since the EAC driver is closed source this is a little bit harder than if they would have had access to the source code, but they have tools to make this work with the closed binary. In the end this is only a cat and mouse type of game where the cheat-devs releases version 1 of their stuff, EAC tries to detect how they do that and makes a new version of EAC to circumvent this at which time the cheat-devs have to do the same and they release v2 and it goes on and on in an infinite loop. The Operating system does not come into play here so this is independent on Windows vs Linux.

The main problem is as you write yourself that it's extremely hard for a closed sourced driver to keep up with a constant changing Linux kernel since Linux changes the internal API and ABI if something better is possible while Windows keeps constant API/ABI interface for kernel drivers. None of this is due to being open- or closed source, it's just down to the philosophical difference between the two systems.

Also note that this very problem would affect the cheaters as well, which is why IMHO cheating this way would be actually harder on Linux and the cheats would simply stop working much faster here than on Windows where the API/ABI would not change.

Quoting: SamsaiBut the problems don't end there. Since Linux is a fully open platform, there is technically nothing that would prevent a determined cheater from cracking open the Linux source code and making some tactical changes to how the kernel behaves, building the kernel and then making the EAC kernel module blind. On Windows the EAC developers can assume that the black box that is the NT kernel is at least somewhat difficult to modify by users. This means that in kernel-space they can assume some level of security through obscurity. On Linux this assumption does not hold.

Rewriting the entire Linux Kernel to make the EAC module blind (which of course would trigger EAC that something is happening) while making everything else work just fine is IMHO a much harder undertaking than what is presenting here. It's a theoretical attack vector that most likely will never happen in practice. Besides the massive undertaking of this fork, they would also have to carry on support for new kernel releases to support new hardware so the maintenance burden would way outweigh the support burden that the cheat-devs have to do today so I fail to see how this would be a chosen path for any of them. They would also have to have a way for their users to put external kernels into the Steam Deck of which we right now don't know how easy that would be.

IMHO one could just as easily argue that the cheaters could invest into ReactOS to make it Windows 11 compatible and then have cheaters replace the Windows kernel with the ReactOS one with added "make EAC blind" patches.

View this comment - View article - View full comments

Quoting: EagleDelta

Quoting: Samsai

Quoting: Lancabanwith everything saifd about the Linux kernel and different versions and hackabiltiy etc. yet it plays on Android, even on 3rd party Roms and Kernels just fine.

Would that not have the same exact issues and from a significantly larger player base than desktop Linux users?

Right now I can take my phone, root it, throw on a different Rom, and even use a different customized kernel, and still play Fortnite. This has been done, proven, viewed, tested, and seems to be OK.

Theoretically yes. I think the overriding issues are that Android is a market big enough to take the risk and generally speaking tech illiterate enough that the likelihood of someone installing a custom ROM to cheat in Fortnite is so unlikely, that it doesn't register as a realistic risk.

From everything I've read, they do try to prevent custom ROMs from playing the game. Even when those Custom ROMs do get it running, they have to have root disabled, play services must be installed, and safetynet must pass its checks, among other things.

So, it still requires a fairly locked down Android OS to run the game.

So in other words, they manage to implement some safeguards even when run under the evil Linux kernel :-)

View this comment - View article - View full comments

Quoting: Beamboom

Quoting: F.Ultrathere 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

Soooo... Your logic is that since they also have a challenge to tackle cheats on other platforms, they might just as well expand the attack vector?

I mean... That is what you are saying here.

No my logic here is that EAC is chasing an impossible goal and there is nothing that Windows gives them that is helping them in any way shape or form here. It's simply a huge waste to put the worlds most secure lock on a crappy thin door that every single person can kick in while at the same time arguing that you will refuse to install this lock on houses with a chimney because some very determined thief might climb down it (Santa). And we haven't even begun to talk about the presence of windows, how stable the door frame is and so on and on.

But to continue on what you IMHO falsely think is a logic fallacy, if it's so easy to cheat right now on Windows (and will continue to be for eternity) why would any cheater bother to switch to a Steam Deck where there at the moment exists zero working cheats? I agree with you that normally this would be a kind of logic fallacy, but in this case it is not because the original premise is a falsehood / red herring.

View this comment - View article - View full comments

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