This is taken directly from the EAC dll:
Linux is ridiculously powerful & versatile as I'm sure we all know...and having that much opportunity to mess with all the net/visual/input subsystems in a way the game can't even see (since it's trapped in WINE) is a major issue cheat wise.
Not ideal but I can totally see why a company might from a practical/commercial point of view just block it outright. Especially given player numbers of WINE players vs upsetting your entire user base due to cheaters.
If I wanted to aimbot in an FPS, I would just analyze the HDMI output from my computer (via an FPGA) and have it directly create the necessary USB transactions to move my mouse to the target's head. I would introduce randomness, "input lag", jitter, and even some misses, so that people looking at the kill cam wouldn't immediately think "aimbot" as they are apt to do whenever they die. (You also don't want to make your mouse movements statistically different from anyone else's, or it's the server that will pick up on your cheating... or at least a well-crafted MapReduce. Do game companies have MapReduce? I hope so.)
Executed well, the developer of the game could do nothing about it; maybe I'm really good, or maybe I'm aimbotting. My computer is completely normal, down to the device descriptors on my mouse and monitor. There's no wine, no virtualization, no additional software running.
In the end, trusting the client is crazy. If you want to decide win/loss based on things computers can do easily, your game is probably bad. And aiming is something computers can do in their sleep.
This is actually a major component of bot use for f2p games. A lot of companies try really hard to prevent anything that looks like playing in virtual envs. Having these bots fill up your games and play terribly is a bad look for any game that depends on multi-player interactions to keep people involved.
I believe you can get pretty affordable Windows VMs these days, however. I'm not sure that blocking wine really accomplishes a lot. (There are also companies that sell access to consumer Windows PCs on consumer ISPs these days. If you don't play Hearthstone, you probably don't mind $10/month in free money for letting someone bot Hearthstone on your computer. And it's not like Blizzard is going to say "look, enough Comcast, shut these people down or else we lock all Comcast customers out of battle.net". It's pretty tough to run a gaming client these days, I would imagine. So so much stuff is totally out of your control. I do not envy their engineers at all!)
Besides having to rely on real-time computer vision which is more expensive/resource consuming and harder, the results wouldn't be as good as with other techniques (although this might fit your argument of having some misses and jitter/lag/etc... to act as cover).
(I see two flagged posts asking the same question)
...pretty comfortable in saying that you're not up to speed on 2004 era hax.
It definitely it. Read up on anti cheating stuff...the windows stuff is down-right rootkit grade....to the point where there are privacy concerns from every the privacy tone-death crowd.
Very very different ballgame from "runs in a WINE container with no visibility beyond that".
It's an arms race, but whatever they can check, you can patch. Worst case, you can still virtualise everything.
There isn't a general way to prevent cheating on open platforms with this kind of game, so it ends up being a kind of cat and mouse game. Think of an aimbot (instantly moves your mouse cursor to an enemy as soon as the enemy is seen) or a wall hack that makes enemies visible behind obstacles. The only way to detect those is to check if your runtime environment is being modified by known methods. Opening a wine front (where you'd somehow have detect Linux processes/a modified wine or even a modified kernel etc.) is probably too costly compared to the number of non-cheating players on Linux.
The slippery slope of giving companies higher access is also seen in CSGO where (Faceit/ESEA, dont remember who exactly) put a bitcoin miner in their anti-cheat. Capcom put a rootkit into Street Fighter V to check for cheaters. Is that acceptable?
Incompetent, or rational decision in terms of bang-for-buck to reduce cheats?
Like another comment says, maybe it's easier to cheat using Wine, and thus banning the platform is faster/cheaper, even though they might end up catching a lot of legit users in this broad dragnet.
[1] e.g., https://en.m.wikipedia.org/wiki/NProtect_GameGuard
Of course, it's possible (if much harder) to go in and hack up the DLLs on Windows. Anti-cheat addresses that by whitelisting known-good MS hashes and/or requiring some type of signing. There's a lot more overhead involved in doing something like that for WINE, since every distro's build would be different, it's common for users to have their own builds with game-specific patches enabled, etc.
I've been out of the WINE scene for a while, but I'll say that I don't believe many WINE users are trying to exploit the platform to cheat. I think it's purely a cost-benefit tradeoff. The vendor doesn't feel supporting a legitimate WINE use case is worth the expense of figuring out a reasonable way to validate behavior, handle integration with distro builds, support debugging/custom patchsets, etc.
I would imagine Wine is in a similar predicament.
It seems far more likely to that most players are just using Wine for its intended purpose—to play Fortnite on Linux.
their method (blocking Wine) is questionable though. it reminds me of websites that block Central/Eastern European IP's "because of bots" (yeah, it happens). the goal is nice, but the method hurts many honest users.
Contradictory sentiments like these are what lead me to believe this grant is mostly for marketing purposes. (tin-foil hat mode)
However, I don't see the contradiction in Sweeney's statement. One can appreciate the advantages of open tools, libraries and platforms, and still want to publish a proprietary game on top of that technology.
It's kind of like an omnivore chef joining a forum full of vegans to work on improving seasonings for braised veggies. They might not be pleased when they find out that she wants to make a side dish to be served with steak; but that in itself doesn't mean her goal is exploitation or sabotage, rather than mutually beneficial cooperation.
..or Google or Apple. Or Nintendo. Or Sony.
https://www.polygon.com/2018/12/6/18129978/epic-games-store-...
"I don't give a rip whose money it is, mate" - Steve Irwin, when asked about accepting money from "unethical" groups and using it for conservation. https://youtu.be/-1gVkTFam1w?t=753
If it helps a good goal, what does it matter?
If it's done anonymously, then sure: you're quite right. But if it isn't then there is, in fact, a price. And it's not always a great deal.
But by accepting the donation you may be signaling that you're ok with how the donor made their money. By turning it down, you may also have a PR opportunity to spread a positive message.
I am merely pointing out that Epic's list of bad things outweighs their list of good things, regarding the open source community.
Assuming there are tax benefits for donating, it becomes a win-win.
I think he's operating with a different understanding of the word "open" than the rest of us.
Also, there's Wine and ReactOS, no? Aren't those two alternative (even if somewhat incomplete) implementations of Win32?
https://www.theguardian.com/technology/2016/mar/04/microsoft...
Using the word "standard", which he never does in that article, is quite misleading.
As it is, he argued that Win32 is more open than UWP or Android; regardless of whether you think the API is a standard or a platform.
Yes, it's not totally black and white. Android does kinda allow side-loading with shitty usability. MS did start its own store and lets not get into telemetry. Classical windows still gives the user a lot of control, though.
Further if the Oracle v Google suit does not get overturned MS could put an end to both Wine and ReactOS in a heartbeat
With UE4 they have created an engine that was extensible only via C++ and via their graphical scripting language. With the notorious instability and incompatibilities of ABIs of different C++ compilers, Epic didn't have a lot of options other than releasing the engine source so that their customers could recompile the whole engine with a single compiler version. And with Unity eating away at the indie market at that time, Epic needed a successor to the free, closed source UE3 UDK to keep a foot in that market. I don't think that Epic had a lot of other options at that point.
EGS doesn't have DRM, it is up to each game to implement their own if they want, but the store itself doesn't provide any.
Which is great since most games do not bother :-P (although i'd prefer it if they had a DRM-free stance like GOG, but Epic is too publisher-friendly to allow that).
https://news.ycombinator.com/item?id=19844241