I was just reading a bit about how blizzard does it. They have an anticheat called Warden, which is usermode.
This is probably part of the reason why it is hard for them to stop botting.
Keep in mind, a big part of the reason bits are so prolific in WoW is because there is no financial incentive to get rid of them.
The bot accounts generate more revenue than the people that leave the game due to bots. Blizzards stance is (and I don't actually fault them for this), if players don't care enough to leave the game, why should we spend money to reduce our subscription numbers?
Won't Ashes have the same incentive structure then? Just get big guilds with bots in their nodes and they can guard for them. Why would Intrepid want to come down hard on their big guilds?
So the only thing that kernel level anticheat stops is what, addons? Pretty steep price to pay to try and combat addons. I've always thought that rule was a lost cause TBH, practically unenforceable.
I was just reading a bit about how blizzard does it. They have an anticheat called Warden, which is usermode.
This is probably part of the reason why it is hard for them to stop botting.
Keep in mind, a big part of the reason bits are so prolific in WoW is because there is no financial incentive to get rid of them.
The bot accounts generate more revenue than the people that leave the game due to bots. Blizzards stance is (and I don't actually fault them for this), if players don't care enough to leave the game, why should we spend money to reduce our subscription numbers?
Won't Ashes have the same incentive structure then?
Potentially.
Realistically, it is up to us players to ensure developers work to keep bots out of their games - and the way we do that is by not playing games that have botters, making sure to tell developers that is the sole reason we are leaving.
Where Ashes "may" have a point of difference in this regard is in not being publically traded. It means the developers answer to Steven, not shareholders. Shareholders want money, and so want bots dealt with in the way that makes them the most money. If Steven wants a bot free game, then it is up to Intrepid to make a bot free game.
As to EAC only really being useful for stopping addons - I know it won't stop my combat tracker, but it also won't stop anything running on MSI's MEG 321URX.
The only real effect EAC has is that it makes some people feel as if they developer is trying. It's effectively a placebo in the eyes of anyone competent and also wanting to play the game in a way that isn't strictly within the TOS.
As a cybersecurity professional myself i fully support this.
A great example of non-intrusive software combined with innovation is https://anybrain.gg/.
It is run client-side and tracks movement on a pixel level. one of the features is that it builds a 'behavioral profile'. When you activate a bot, it will detect that the movement is different then that off your profile.
It will detect common bots based off the profiles off the bots. It can do a lot more.
Definitely worth to check it out!
so if its client side, its even easier to crack...
I was just reading a bit about how blizzard does it. They have an anticheat called Warden, which is usermode.
This is probably part of the reason why it is hard for them to stop botting.
Keep in mind, a big part of the reason bits are so prolific in WoW is because there is no financial incentive to get rid of them.
The bot accounts generate more revenue than the people that leave the game due to bots. Blizzards stance is (and I don't actually fault them for this), if players don't care enough to leave the game, why should we spend money to reduce our subscription numbers?
Won't Ashes have the same incentive structure then?
As to EAC only really being useful for stopping addons - I know it won't stop my combat tracker, but it also won't stop anything running on MSI's MEG 321URX.
The only real effect EAC has is that it makes some people feel as if they developer is trying. It's effectively a placebo in the eyes of anyone competent and also wanting to play the game in a way that isn't strictly within the TOS.
I was just reading a bit about how blizzard does it. They have an anticheat called Warden, which is usermode.
This is probably part of the reason why it is hard for them to stop botting.
Keep in mind, a big part of the reason bits are so prolific in WoW is because there is no financial incentive to get rid of them.
The bot accounts generate more revenue than the people that leave the game due to bots. Blizzards stance is (and I don't actually fault them for this), if players don't care enough to leave the game, why should we spend money to reduce our subscription numbers?
Won't Ashes have the same incentive structure then?
As to EAC only really being useful for stopping addons - I know it won't stop my combat tracker, but it also won't stop anything running on MSI's MEG 321URX.
The only real effect EAC has is that it makes some people feel as if they developer is trying. It's effectively a placebo in the eyes of anyone competent and also wanting to play the game in a way that isn't strictly within the TOS.
So you will install EAC.
I will - but only because I happen to have a computer that is only used for gaming. If there were a data breach, the only thing they could get on me is my Steam info.
If I was using that computer for work or finances, there is no way in hell EAC would be installed on it.
I was just reading a bit about how blizzard does it. They have an anticheat called Warden, which is usermode.
This is probably part of the reason why it is hard for them to stop botting.
Keep in mind, a big part of the reason bits are so prolific in WoW is because there is no financial incentive to get rid of them.
The bot accounts generate more revenue than the people that leave the game due to bots. Blizzards stance is (and I don't actually fault them for this), if players don't care enough to leave the game, why should we spend money to reduce our subscription numbers?
Won't Ashes have the same incentive structure then?
As to EAC only really being useful for stopping addons - I know it won't stop my combat tracker, but it also won't stop anything running on MSI's MEG 321URX.
The only real effect EAC has is that it makes some people feel as if they developer is trying. It's effectively a placebo in the eyes of anyone competent and also wanting to play the game in a way that isn't strictly within the TOS.
So you will install EAC.
I will - but only because I happen to have a computer that is only used for gaming. If there were a data breach, the only thing they could get on me is my Steam info.
If I was using that computer for work or finances, there is no way in hell EAC would be installed on it.
Makes sense. All who plan to upgrade their PC should do the same and keep the old PC running, separated from gaming software and anything they do not trust.
Players who payed for Alpha 2 maybe can afford 2 computers.
At the official release subscribers will have to decide if they play AoC or not, and any of the other games using such protections. https://levvvel.com/games-with-kernel-level-anti-cheat-software/
As a cybersecurity professional and a passionate gamer, I feel it’s my responsibility to address the growing trend of kernel-level anti-cheat solutions in the video game industry. While the intention behind these measures may be to ensure fair play, their implementation raises serious concerns regarding privacy, security, and user rights.
First and foremost, the idea of a kernel-level anti-cheat system sends shivers down my spine. Granting a piece of software such extensive access to your system is akin to handing over the keys to your digital kingdom. It's invasive and opens up Pandora's box of potential vulnerabilities.
From a cybersecurity standpoint, this approach is a disaster waiting to happen. Kernel-level access means these anti-cheat solutions have unfettered access to sensitive parts of your operating system, making them prime targets for malicious actors. One small slip-up in code or a security flaw could expose players to a myriad of risks, ranging from data breaches to full-blown system compromises. This isn’t just a distant fear. This has happened before (see, e.g., August 2022 report that ransomware actors abused a Genshin Impact anti-cheat driver to uninstall antivirus software on end-user machines). This isn’t about trusting the game development studio, the publisher, or even the owners of the anti-cheat itself…all it takes is one malicious actor or disgruntled employee to cause irreversible damage, harm end users directly through their hardware, or indirectly through the fraudulent use of their personal information.
Moreover, the deployment of kernel-level anti-cheat solutions demonstrates a blatant disregard for the privacy of players. By its very nature, such software can monitor and collect vast amounts of data from your system, including personal information that has nothing to do with cheating. While I recognize that, in some cases, the organizations implementing the software may explicitly state that they have no intention of invading your privacy, if you grant them this access, you can do nothing to stop them. This disturbing disregard for privacy sets a dangerous precedent for the erosion of digital rights.
As gamers, we should not have to sacrifice our security and privacy for the sake of fair play. Plenty of alternative approaches to combating cheating do not require such drastic measures. Not to mention, kernel-level anti-cheat isn’t a be-all-end-all solution to the problem. There will still be cheaters. Game developers should prioritize solutions that uphold both the integrity of the game and the rights of the players.
Accordingly, I urge game developers to reconsider their approach and prioritize solutions that strike a balance between security, privacy, and fair play. Our digital rights depend on it.
Seems like this is something that should be brought up in this month's Q&A. See if we can get an official answer on it.
I am excited about the engagement Dulcibel's post is receiving. Thanks for being a part of the conversation. Sorry about the late response; I have been busy with final exams. I will respond to a few points in this comment. I'm new to the forums, so please be patient if my formatting could be better. I apologize and will learn from my mistakes.
One small slip-up in code or a security flaw could expose players to a myriad of risks, ranging from data breaches to full-blown system compromises.
Presumably this would make Intrepid legally responsible, and liable for a multitude of compensation cases?
You are striking at the heart of an essential issue here: maybe it should. But it likely would not today because you would have consented to install the software.
I am sure that there are some readers of this thread who would appreciate a straightforward definition of "kernel-level anti-cheat system".
This is a great point and also strikes at the problem's heart. While this was already answered effectively, I'll dive deeper for anyone who cares to read into it. Anti-cheat is a technical topic and, hence, is not easy to understand if you are not a technical person. I think that the industry is probably (intentionally) obfuscating the invasion of end-user privacy under the guise of "something... something... eradicating cheaters to save you" and "something... something... that you have nothing to worry about if you aren't a cheater yourself!" In my opinion, it is akin to a police officer having no probable cause to search your home, but you nevertheless consent because "you have nothing to hide, right?" But I digress. To your question, I will do my best to provide a straightforward definition of "kernel-level anti-cheat," but first, let's break down the startup process.
The startup process of a computer involves a few steps:
1. Power on Self Test (POST): When you turn on your computer, the basic input/output system (BIOS) or the newer Unified Extensible Firmware Interface (UEFI) initiates the POST, a diagnostic test to ensure that the hardware components are functioning properly.
2. Boot Loader: After the POST, the BIOS or UEFI locates and loads the boot loader. The boot loader is responsible for loading the operating system into memory.
3. Operating System Kernel: Once the boot loader finishes its job, it transfers control to the operating system kernel. The kernel is the core component of the operating system and is responsible for managing system resources and providing essential services to user applications.
4. User Mode: After the kernel initializes, it launches user-mode processes and applications. In user mode, applications run with limited access to system resources and are isolated from each other for security reasons.
Now, let's discuss how different anti-cheat methods fit into this framework, from least privileged access to most privileged access as it pertains to end-user privacy:
A. User-Mode Anti-Cheat: User-mode anti-cheat software operates within the user space of the operating system. It monitors the behavior of applications and processes running in user mode to detect cheating activities, such as unauthorized modifications to game files or memory.
This type of anti-cheat software typically employs various techniques such as code injection, DLL (Dynamic Link Library) scanning, and heuristic analysis to detect cheating behavior. However, since it operates in user mode, it's inherently limited in preventing cheating at a deeper level.
B. Kernel-Level Anti-Cheat: Kernel-level anti-cheat software operates within the kernel space, giving it deeper access to system resources and processes. This allows it to monitor and intercept system calls, memory access, and other low-level operations to detect and prevent cheating more effectively.
Kernel-level anti-cheat solutions can implement techniques like driver-based hooks, system call interception, and kernel-mode code injection to detect and block cheating attempts that may bypass user-mode anti-cheat measures.
C. Secure Boot Anti-Cheat: Secure Boot is a feature provided by UEFI firmware to ensure that only trusted operating system components are loaded during the startup process. It verifies the digital signatures of bootloader and kernel files to prevent unauthorized or tampered code loading.
While not directly an anti-cheat mechanism, Secure Boot indirectly contributes to cheat prevention by ensuring the integrity of the operating system and its components. Requiring users to enable Secure Boot prevents unauthorized modifications to the boot process, making it more difficult for cheaters to inject malicious code or modify game files at the bootloader or kernel level.
Comparison:
(a) User-mode anti-cheat primarily focuses on monitoring and detecting cheating activities within user-space applications.
(b) Kernel-level anti-cheat operates at a deeper level within the operating system, allowing it to detect and prevent cheating attempts that may bypass user-mode anti-cheat measures.
(c) Secure Boot enhances system integrity by ensuring that only trusted components are loaded during the boot process, indirectly contributing to cheat prevention by preventing unauthorized modifications to the system.
Something worth noting here is while the industry standard used to be to implement anti-cheat at the user-mode level, over time, hackers have thwarted these defenses because the hackers learn how to run their "cheats" at a higher privilege level than the anti-cheat is running at. In reality, this is the nature of the cyber threat landscape. And it always will be. That is why the developers want to get consent from the end-user to place their defenses at a more privileged/deeper level of access to the system to run in spaces of the machine that are deeper/behind/more privileged than where the cheats would be running at. The problem becomes, by nature of cyber warfare, that the hackers eventually thwart the defense. With enough time, this is always the case, and no data is evincing otherwise. This is one reason the technologies you use every day regularly update: to patch the constant threats to its security. I digress... again.
To the point, why do we care? Well, that's because, one day, user-level anti-cheat became no longer effective at preventing cheaters. Some day after that, kernel-level anti-cheat, as explained here, will (has) become increasingly ineffective at preventing cheaters. So, now, the industry standard aims to make use of the Secure Boot setting, like Riot's Vanguard does on VALORANT (they elected not to require users be running their system in Secure Boot for League of Legends due to the older hardware that comprises its userbase and compatibility issues). To be clear, Secure Boot has even deeper access that sees past the kernel. To my knowledge, Easy Anti-Cheat has a Secure Boot requirement. This is at least what I have surmised from player discussions on Steam and whatnot for games that use EAC. If anyone has any information on this (maybe @Dulcibel can learn more insider knowledge from another conversation with support staff ), I would be interested to know. And contrary to what was said in this user's post...
As a cybersecurity professional and a passionate gamer,
...
, the idea of a kernel-level anti-cheat system sends shivers down my spine.
Sounds like risk vs reward
There are no UEFI level anti cheat solutions yet?
...this is a UEFI level solution. The question becomes, what would be the next secure step to take when the firmware level anti-cheat inevitably (by nature) fails? I imagine it'd be an "Ashes Box" of sorts, i.e., some console running an OS proprietary to Intrepid. Or maybe we could all play on Local Area Networks at Intrepid-sponsored Internet cafes. I'm not being sarcastic–these would be the next logical solutions Intrepid could take to secure their game by completely controlling the environment in which it runs. In fact, these are the two only solutions I can think of, and that is if the industry standard keeps employing solutions that aim to delve increasingly deeper into end-users' private systems to secure their games. I actually would quite prefer having to buy an "Intrepid Deck" over the idea of having to purchase a new "throwaway" PC to install Ashes on (as not to download the Easy Anti-Cheat on my "main" PC). To be clear, I would not do that because I would not play a game that employed such a privileged level of anti-cheat software, but I like to think a substantial portion of players would feel forced into making that choice. Really, what is the difference in saving players the $1,000 to build a PC when they could buy a $400 Ashes Console? At this point, I'm speculating and ranting. I have a lot to say, but I will hop off my soapbox now and look forward to hearing what you think and researching some of the proffered alternatives, like the one below:
As a cybersecurity professional myself i fully support this.
A great example of non-intrusive software combined with innovation is https://anybrain.gg/.
It is run client-side and tracks movement on a pixel level. one of the features is that it builds a 'behavioral profile'. When you activate a bot, it will detect that the movement is different then that off your profile.
It will detect common bots based off the profiles off the bots. It can do a lot more.
I am excited about the engagement Dulcibel's post is receiving. Thanks for being a part of the conversation. Sorry about the late response; I have been busy with final exams. I will respond to a few points in this comment. I'm new to the forums, so please be patient if my formatting could be better. I apologize and will learn from my mistakes.
One small slip-up in code or a security flaw could expose players to a myriad of risks, ranging from data breaches to full-blown system compromises.
Presumably this would make Intrepid legally responsible, and liable for a multitude of compensation cases?
You are striking at the heart of an essential issue here: maybe it should. But it likely would not today because you would have consented to install the software.
I am sure that there are some readers of this thread who would appreciate a straightforward definition of "kernel-level anti-cheat system".
This is a great point and also strikes at the problem's heart. While this was already answered effectively, I'll dive deeper for anyone who cares to read into it. Anti-cheat is a technical topic and, hence, is not easy to understand if you are not a technical person. I think that the industry is probably (intentionally) obfuscating the invasion of end-user privacy under the guise of "something... something... eradicating cheaters to save you" and "something... something... that you have nothing to worry about if you aren't a cheater yourself!" In my opinion, it is akin to a police officer having no probable cause to search your home, but you nevertheless consent because "you have nothing to hide, right?" But I digress. To your question, I will do my best to provide a straightforward definition of "kernel-level anti-cheat," but first, let's break down the startup process.
The startup process of a computer involves a few steps:
1. Power on Self Test (POST): When you turn on your computer, the basic input/output system (BIOS) or the newer Unified Extensible Firmware Interface (UEFI) initiates the POST, a diagnostic test to ensure that the hardware components are functioning properly.
2. Boot Loader: After the POST, the BIOS or UEFI locates and loads the boot loader. The boot loader is responsible for loading the operating system into memory.
3. Operating System Kernel: Once the boot loader finishes its job, it transfers control to the operating system kernel. The kernel is the core component of the operating system and is responsible for managing system resources and providing essential services to user applications.
4. User Mode: After the kernel initializes, it launches user-mode processes and applications. In user mode, applications run with limited access to system resources and are isolated from each other for security reasons.
Now, let's discuss how different anti-cheat methods fit into this framework, from least privileged access to most privileged access as it pertains to end-user privacy:
A. User-Mode Anti-Cheat: User-mode anti-cheat software operates within the user space of the operating system. It monitors the behavior of applications and processes running in user mode to detect cheating activities, such as unauthorized modifications to game files or memory.
This type of anti-cheat software typically employs various techniques such as code injection, DLL (Dynamic Link Library) scanning, and heuristic analysis to detect cheating behavior. However, since it operates in user mode, it's inherently limited in preventing cheating at a deeper level.
B. Kernel-Level Anti-Cheat: Kernel-level anti-cheat software operates within the kernel space, giving it deeper access to system resources and processes. This allows it to monitor and intercept system calls, memory access, and other low-level operations to detect and prevent cheating more effectively.
Kernel-level anti-cheat solutions can implement techniques like driver-based hooks, system call interception, and kernel-mode code injection to detect and block cheating attempts that may bypass user-mode anti-cheat measures.
C. Secure Boot Anti-Cheat: Secure Boot is a feature provided by UEFI firmware to ensure that only trusted operating system components are loaded during the startup process. It verifies the digital signatures of bootloader and kernel files to prevent unauthorized or tampered code loading.
While not directly an anti-cheat mechanism, Secure Boot indirectly contributes to cheat prevention by ensuring the integrity of the operating system and its components. Requiring users to enable Secure Boot prevents unauthorized modifications to the boot process, making it more difficult for cheaters to inject malicious code or modify game files at the bootloader or kernel level.
Comparison:
(a) User-mode anti-cheat primarily focuses on monitoring and detecting cheating activities within user-space applications.
(b) Kernel-level anti-cheat operates at a deeper level within the operating system, allowing it to detect and prevent cheating attempts that may bypass user-mode anti-cheat measures.
(c) Secure Boot enhances system integrity by ensuring that only trusted components are loaded during the boot process, indirectly contributing to cheat prevention by preventing unauthorized modifications to the system.
Something worth noting here is while the industry standard used to be to implement anti-cheat at the user-mode level, over time, hackers have thwarted these defenses because the hackers learn how to run their "cheats" at a higher privilege level than the anti-cheat is running at. In reality, this is the nature of the cyber threat landscape. And it always will be. That is why the developers want to get consent from the end-user to place their defenses at a more privileged/deeper level of access to the system to run in spaces of the machine that are deeper/behind/more privileged than where the cheats would be running at. The problem becomes, by nature of cyber warfare, that the hackers eventually thwart the defense. With enough time, this is always the case, and no data is evincing otherwise. This is one reason the technologies you use every day regularly update: to patch the constant threats to its security. I digress... again.
To the point, why do we care? Well, that's because, one day, user-level anti-cheat became no longer effective at preventing cheaters. Some day after that, kernel-level anti-cheat, as explained here, will (has) become increasingly ineffective at preventing cheaters. So, now, the industry standard aims to make use of the Secure Boot setting, like Riot's Vanguard does on VALORANT (they elected not to require users be running their system in Secure Boot for League of Legends due to the older hardware that comprises its userbase and compatibility issues). To be clear, Secure Boot has even deeper access that sees past the kernel. To my knowledge, Easy Anti-Cheat has a Secure Boot requirement. This is at least what I have surmised from player discussions on Steam and whatnot for games that use EAC. If anyone has any information on this (maybe @Dulcibel can learn more insider knowledge from another conversation with support staff ), I would be interested to know. And contrary to what was said in this user's post...
As a cybersecurity professional and a passionate gamer,
...
, the idea of a kernel-level anti-cheat system sends shivers down my spine.
Sounds like risk vs reward
There are no UEFI level anti cheat solutions yet?
...this is a UEFI level solution. The question becomes, what would be the next secure step to take when the firmware level anti-cheat inevitably (by nature) fails? I imagine it'd be an "Ashes Box" of sorts, i.e., some console running an OS proprietary to Intrepid. Or maybe we could all play on Local Area Networks at Intrepid-sponsored Internet cafes. I'm not being sarcastic–these would be the next logical solutions Intrepid could take to secure their game by completely controlling the environment in which it runs. In fact, these are the two only solutions I can think of, and that is if the industry standard keeps employing solutions that aim to delve increasingly deeper into end-users' private systems to secure their games. I actually would quite prefer having to buy an "Intrepid Deck" over the idea of having to purchase a new "throwaway" PC to install Ashes on (as not to download the Easy Anti-Cheat on my "main" PC). To be clear, I would not do that because I would not play a game that employed such a privileged level of anti-cheat software, but I like to think a substantial portion of players would feel forced into making that choice. Really, what is the difference in saving players the $1,000 to build a PC when they could buy a $400 Ashes Console? At this point, I'm speculating and ranting. I have a lot to say, but I will hop off my soapbox now and look forward to hearing what you think and researching some of the proffered alternatives, like the one below:
As a cybersecurity professional myself i fully support this.
A great example of non-intrusive software combined with innovation is https://anybrain.gg/.
It is run client-side and tracks movement on a pixel level. one of the features is that it builds a 'behavioral profile'. When you activate a bot, it will detect that the movement is different then that off your profile.
It will detect common bots based off the profiles off the bots. It can do a lot more.
Definitely worth to check it out!
that's some serious long form copywriting to advertise that website. i wonder if that is lucibel's second account hmm.
anyways, imagine you use the solution provided by them, but on day one you start botting...so the behavioral profile will be of the bot since day one and the software will have no way of knowing since there wont even be switching from bot to human. gg
anyways, imagine you use the solution provided by them, but on day one you start botting...so the behavioral profile will be of the bot since day one and the software will have no way of knowing since there wont even be switching from bot to human. gg
This is a valid point - but you need to also factor in the notion that the bot you are using can't be readily available on the internet at all.
If a developer can get hold of a bot, they can work out how to detect it - if they care to do so.
I am excited about the engagement Dulcibel's post is receiving. Thanks for being a part of the conversation. Sorry about the late response; I have been busy with final exams. I will respond to a few points in this comment. I'm new to the forums, so please be patient if my formatting could be better. I apologize and will learn from my mistakes.
One small slip-up in code or a security flaw could expose players to a myriad of risks, ranging from data breaches to full-blown system compromises.
Presumably this would make Intrepid legally responsible, and liable for a multitude of compensation cases?
You are striking at the heart of an essential issue here: maybe it should. But it likely would not today because you would have consented to install the software.
I am sure that there are some readers of this thread who would appreciate a straightforward definition of "kernel-level anti-cheat system".
This is a great point and also strikes at the problem's heart. While this was already answered effectively, I'll dive deeper for anyone who cares to read into it. Anti-cheat is a technical topic and, hence, is not easy to understand if you are not a technical person. I think that the industry is probably (intentionally) obfuscating the invasion of end-user privacy under the guise of "something... something... eradicating cheaters to save you" and "something... something... that you have nothing to worry about if you aren't a cheater yourself!" In my opinion, it is akin to a police officer having no probable cause to search your home, but you nevertheless consent because "you have nothing to hide, right?" But I digress. To your question, I will do my best to provide a straightforward definition of "kernel-level anti-cheat," but first, let's break down the startup process.
The startup process of a computer involves a few steps:
1. Power on Self Test (POST): When you turn on your computer, the basic input/output system (BIOS) or the newer Unified Extensible Firmware Interface (UEFI) initiates the POST, a diagnostic test to ensure that the hardware components are functioning properly.
2. Boot Loader: After the POST, the BIOS or UEFI locates and loads the boot loader. The boot loader is responsible for loading the operating system into memory.
3. Operating System Kernel: Once the boot loader finishes its job, it transfers control to the operating system kernel. The kernel is the core component of the operating system and is responsible for managing system resources and providing essential services to user applications.
4. User Mode: After the kernel initializes, it launches user-mode processes and applications. In user mode, applications run with limited access to system resources and are isolated from each other for security reasons.
Now, let's discuss how different anti-cheat methods fit into this framework, from least privileged access to most privileged access as it pertains to end-user privacy:
A. User-Mode Anti-Cheat: User-mode anti-cheat software operates within the user space of the operating system. It monitors the behavior of applications and processes running in user mode to detect cheating activities, such as unauthorized modifications to game files or memory.
This type of anti-cheat software typically employs various techniques such as code injection, DLL (Dynamic Link Library) scanning, and heuristic analysis to detect cheating behavior. However, since it operates in user mode, it's inherently limited in preventing cheating at a deeper level.
B. Kernel-Level Anti-Cheat: Kernel-level anti-cheat software operates within the kernel space, giving it deeper access to system resources and processes. This allows it to monitor and intercept system calls, memory access, and other low-level operations to detect and prevent cheating more effectively.
Kernel-level anti-cheat solutions can implement techniques like driver-based hooks, system call interception, and kernel-mode code injection to detect and block cheating attempts that may bypass user-mode anti-cheat measures.
C. Secure Boot Anti-Cheat: Secure Boot is a feature provided by UEFI firmware to ensure that only trusted operating system components are loaded during the startup process. It verifies the digital signatures of bootloader and kernel files to prevent unauthorized or tampered code loading.
While not directly an anti-cheat mechanism, Secure Boot indirectly contributes to cheat prevention by ensuring the integrity of the operating system and its components. Requiring users to enable Secure Boot prevents unauthorized modifications to the boot process, making it more difficult for cheaters to inject malicious code or modify game files at the bootloader or kernel level.
Comparison:
(a) User-mode anti-cheat primarily focuses on monitoring and detecting cheating activities within user-space applications.
(b) Kernel-level anti-cheat operates at a deeper level within the operating system, allowing it to detect and prevent cheating attempts that may bypass user-mode anti-cheat measures.
(c) Secure Boot enhances system integrity by ensuring that only trusted components are loaded during the boot process, indirectly contributing to cheat prevention by preventing unauthorized modifications to the system.
Something worth noting here is while the industry standard used to be to implement anti-cheat at the user-mode level, over time, hackers have thwarted these defenses because the hackers learn how to run their "cheats" at a higher privilege level than the anti-cheat is running at. In reality, this is the nature of the cyber threat landscape. And it always will be. That is why the developers want to get consent from the end-user to place their defenses at a more privileged/deeper level of access to the system to run in spaces of the machine that are deeper/behind/more privileged than where the cheats would be running at. The problem becomes, by nature of cyber warfare, that the hackers eventually thwart the defense. With enough time, this is always the case, and no data is evincing otherwise. This is one reason the technologies you use every day regularly update: to patch the constant threats to its security. I digress... again.
To the point, why do we care? Well, that's because, one day, user-level anti-cheat became no longer effective at preventing cheaters. Some day after that, kernel-level anti-cheat, as explained here, will (has) become increasingly ineffective at preventing cheaters. So, now, the industry standard aims to make use of the Secure Boot setting, like Riot's Vanguard does on VALORANT (they elected not to require users be running their system in Secure Boot for League of Legends due to the older hardware that comprises its userbase and compatibility issues). To be clear, Secure Boot has even deeper access that sees past the kernel. To my knowledge, Easy Anti-Cheat has a Secure Boot requirement. This is at least what I have surmised from player discussions on Steam and whatnot for games that use EAC. If anyone has any information on this (maybe @Dulcibel can learn more insider knowledge from another conversation with support staff ), I would be interested to know. And contrary to what was said in this user's post...
As a cybersecurity professional and a passionate gamer,
...
, the idea of a kernel-level anti-cheat system sends shivers down my spine.
Sounds like risk vs reward
There are no UEFI level anti cheat solutions yet?
...this is a UEFI level solution. The question becomes, what would be the next secure step to take when the firmware level anti-cheat inevitably (by nature) fails? I imagine it'd be an "Ashes Box" of sorts, i.e., some console running an OS proprietary to Intrepid. Or maybe we could all play on Local Area Networks at Intrepid-sponsored Internet cafes. I'm not being sarcastic–these would be the next logical solutions Intrepid could take to secure their game by completely controlling the environment in which it runs. In fact, these are the two only solutions I can think of, and that is if the industry standard keeps employing solutions that aim to delve increasingly deeper into end-users' private systems to secure their games. I actually would quite prefer having to buy an "Intrepid Deck" over the idea of having to purchase a new "throwaway" PC to install Ashes on (as not to download the Easy Anti-Cheat on my "main" PC). To be clear, I would not do that because I would not play a game that employed such a privileged level of anti-cheat software, but I like to think a substantial portion of players would feel forced into making that choice. Really, what is the difference in saving players the $1,000 to build a PC when they could buy a $400 Ashes Console? At this point, I'm speculating and ranting. I have a lot to say, but I will hop off my soapbox now and look forward to hearing what you think and researching some of the proffered alternatives, like the one below:
As a cybersecurity professional myself i fully support this.
A great example of non-intrusive software combined with innovation is https://anybrain.gg/.
It is run client-side and tracks movement on a pixel level. one of the features is that it builds a 'behavioral profile'. When you activate a bot, it will detect that the movement is different then that off your profile.
It will detect common bots based off the profiles off the bots. It can do a lot more.
Definitely worth to check it out!
that's some serious long form copywriting to advertise that website. i wonder if that is lucibel's second account hmm.
anyways, imagine you use the solution provided by them, but on day one you start botting...so the behavioral profile will be of the bot since day one and the software will have no way of knowing since there wont even be switching from bot to human. gg
To be clear, I am not advertising that website, and @Dulcibel did not advertise that website either. To clear up any future confusion, we are merely acknowledging @leamese comment, bringing an alternative solution to our attention. While I can appreciate its concern, this thread's obsession with @Dulcibel "second account" is misplaced. I think it more productive to address the substance of the discussion rather than make arguments ad hominem.
My opinion is that MMO doesn't have any mechanic that supports the idea that you would want to use kernel level access to prevent cheating
Indeed.
The main reason I can see for an MMORPG to want to use EAC specifically is that it is reasonably effective at preventing people running two instances of the game client on one computer.
With Ashes already having had a community vote that said multi-boxing was something we were generally willing to accept though, I don't see a need for that at all in Ashes.
Given how much control the MMO server has over player input and response, I think that going even just for EAC is a crutch. I hope Intrepid can get an anti-cheat engineer via their job posting that understands this, as the ever-escalating war of KLAC is leading not just to breaches but even outright bricking people's machines as happened with Riot's latest iteration of their nonsense.
The question fundamentally is whether Intrepid is willing to take part in this crazy cat-and-mouse game. I think having good GM staffing and server-based detection would go a long way in comparison to what's become the industry standard for games where it's a lot more possible to be subtle due to their faster pace.
Grilled cheese always tastes better when you eat it together!
Given how much control the MMO server has over player input and response, I think that going even just for EAC is a crutch. I hope Intrepid can get an anti-cheat engineer via their job posting that understands this, as the ever-escalating war of KLAC is leading not just to breaches but even outright bricking people's machines as happened with Riot's latest iteration of their nonsense.
The question fundamentally is whether Intrepid is willing to take part in this crazy cat-and-mouse game. I think having good GM staffing and server-based detection would go a long way in comparison to what's become the industry standard for games where it's a lot more possible to be subtle due to their faster pace.
Bring back dedicated GM staffing that plays alongside the players!!!
Given how much control the MMO server has over player input and response, I think that going even just for EAC is a crutch. I hope Intrepid can get an anti-cheat engineer via their job posting that understands this, as the ever-escalating war of KLAC is leading not just to breaches but even outright bricking people's machines as happened with Riot's latest iteration of their nonsense.
The question fundamentally is whether Intrepid is willing to take part in this crazy cat-and-mouse game. I think having good GM staffing and server-based detection would go a long way in comparison to what's become the industry standard for games where it's a lot more possible to be subtle due to their faster pace.
Bring back dedicated GM staffing that plays alongside the players!!!
This was never effective as a means of anti-cheat, and in most games it wasn't their primary function.
Someone on the server as a character may see a player cheating and ban them. Someone working behind the scenes would be looking for signs of a given cheat, and then will sweep up and ban 10,000 players at once.
If given the choice, I'd rather all staff working on preventing cheating work behind the scenes.
I was just reading a bit about how blizzard does it. They have an anticheat called Warden, which is usermode.
This is probably part of the reason why it is hard for them to stop botting.
Keep in mind, a big part of the reason bits are so prolific in WoW is because there is no financial incentive to get rid of them.
The bot accounts generate more revenue than the people that leave the game due to bots. Blizzards stance is (and I don't actually fault them for this), if players don't care enough to leave the game, why should we spend money to reduce our subscription numbers?
Good point. And that is why I am here—to show Intrepid at least one player cares enough to leave the game.
Comments
Won't Ashes have the same incentive structure then? Just get big guilds with bots in their nodes and they can guard for them. Why would Intrepid want to come down hard on their big guilds?
So the only thing that kernel level anticheat stops is what, addons? Pretty steep price to pay to try and combat addons. I've always thought that rule was a lost cause TBH, practically unenforceable.
Potentially.
Realistically, it is up to us players to ensure developers work to keep bots out of their games - and the way we do that is by not playing games that have botters, making sure to tell developers that is the sole reason we are leaving.
Where Ashes "may" have a point of difference in this regard is in not being publically traded. It means the developers answer to Steven, not shareholders. Shareholders want money, and so want bots dealt with in the way that makes them the most money. If Steven wants a bot free game, then it is up to Intrepid to make a bot free game.
As to EAC only really being useful for stopping addons - I know it won't stop my combat tracker, but it also won't stop anything running on MSI's MEG 321URX.
The only real effect EAC has is that it makes some people feel as if they developer is trying. It's effectively a placebo in the eyes of anyone competent and also wanting to play the game in a way that isn't strictly within the TOS.
so if its client side, its even easier to crack...
nothing client side is secure.
So you will install EAC.
If I was using that computer for work or finances, there is no way in hell EAC would be installed on it.
Makes sense. All who plan to upgrade their PC should do the same and keep the old PC running, separated from gaming software and anything they do not trust.
Players who payed for Alpha 2 maybe can afford 2 computers.
At the official release subscribers will have to decide if they play AoC or not, and any of the other games using such protections.
https://levvvel.com/games-with-kernel-level-anti-cheat-software/
I see Intrepid is already on the EAC list there.
Seems like this is something that should be brought up in this month's Q&A. See if we can get an official answer on it.
I am excited about the engagement Dulcibel's post is receiving. Thanks for being a part of the conversation. Sorry about the late response; I have been busy with final exams. I will respond to a few points in this comment. I'm new to the forums, so please be patient if my formatting could be better. I apologize and will learn from my mistakes.
You are striking at the heart of an essential issue here: maybe it should. But it likely would not today because you would have consented to install the software.
This is a great point and also strikes at the problem's heart. While this was already answered effectively, I'll dive deeper for anyone who cares to read into it. Anti-cheat is a technical topic and, hence, is not easy to understand if you are not a technical person. I think that the industry is probably (intentionally) obfuscating the invasion of end-user privacy under the guise of "something... something... eradicating cheaters to save you" and "something... something... that you have nothing to worry about if you aren't a cheater yourself!" In my opinion, it is akin to a police officer having no probable cause to search your home, but you nevertheless consent because "you have nothing to hide, right?" But I digress. To your question, I will do my best to provide a straightforward definition of "kernel-level anti-cheat," but first, let's break down the startup process.
The startup process of a computer involves a few steps:
1. Power on Self Test (POST): When you turn on your computer, the basic input/output system (BIOS) or the newer Unified Extensible Firmware Interface (UEFI) initiates the POST, a diagnostic test to ensure that the hardware components are functioning properly.
2. Boot Loader: After the POST, the BIOS or UEFI locates and loads the boot loader. The boot loader is responsible for loading the operating system into memory.
3. Operating System Kernel: Once the boot loader finishes its job, it transfers control to the operating system kernel. The kernel is the core component of the operating system and is responsible for managing system resources and providing essential services to user applications.
4. User Mode: After the kernel initializes, it launches user-mode processes and applications. In user mode, applications run with limited access to system resources and are isolated from each other for security reasons.
Now, let's discuss how different anti-cheat methods fit into this framework, from least privileged access to most privileged access as it pertains to end-user privacy:
A. User-Mode Anti-Cheat: User-mode anti-cheat software operates within the user space of the operating system. It monitors the behavior of applications and processes running in user mode to detect cheating activities, such as unauthorized modifications to game files or memory.
This type of anti-cheat software typically employs various techniques such as code injection, DLL (Dynamic Link Library) scanning, and heuristic analysis to detect cheating behavior. However, since it operates in user mode, it's inherently limited in preventing cheating at a deeper level.
B. Kernel-Level Anti-Cheat: Kernel-level anti-cheat software operates within the kernel space, giving it deeper access to system resources and processes. This allows it to monitor and intercept system calls, memory access, and other low-level operations to detect and prevent cheating more effectively.
Kernel-level anti-cheat solutions can implement techniques like driver-based hooks, system call interception, and kernel-mode code injection to detect and block cheating attempts that may bypass user-mode anti-cheat measures.
C. Secure Boot Anti-Cheat: Secure Boot is a feature provided by UEFI firmware to ensure that only trusted operating system components are loaded during the startup process. It verifies the digital signatures of bootloader and kernel files to prevent unauthorized or tampered code loading.
While not directly an anti-cheat mechanism, Secure Boot indirectly contributes to cheat prevention by ensuring the integrity of the operating system and its components. Requiring users to enable Secure Boot prevents unauthorized modifications to the boot process, making it more difficult for cheaters to inject malicious code or modify game files at the bootloader or kernel level.
Comparison:
(a) User-mode anti-cheat primarily focuses on monitoring and detecting cheating activities within user-space applications.
(b) Kernel-level anti-cheat operates at a deeper level within the operating system, allowing it to detect and prevent cheating attempts that may bypass user-mode anti-cheat measures.
(c) Secure Boot enhances system integrity by ensuring that only trusted components are loaded during the boot process, indirectly contributing to cheat prevention by preventing unauthorized modifications to the system.
Something worth noting here is while the industry standard used to be to implement anti-cheat at the user-mode level, over time, hackers have thwarted these defenses because the hackers learn how to run their "cheats" at a higher privilege level than the anti-cheat is running at. In reality, this is the nature of the cyber threat landscape. And it always will be. That is why the developers want to get consent from the end-user to place their defenses at a more privileged/deeper level of access to the system to run in spaces of the machine that are deeper/behind/more privileged than where the cheats would be running at. The problem becomes, by nature of cyber warfare, that the hackers eventually thwart the defense. With enough time, this is always the case, and no data is evincing otherwise. This is one reason the technologies you use every day regularly update: to patch the constant threats to its security. I digress... again.
To the point, why do we care? Well, that's because, one day, user-level anti-cheat became no longer effective at preventing cheaters. Some day after that, kernel-level anti-cheat, as explained here, will (has) become increasingly ineffective at preventing cheaters. So, now, the industry standard aims to make use of the Secure Boot setting, like Riot's Vanguard does on VALORANT (they elected not to require users be running their system in Secure Boot for League of Legends due to the older hardware that comprises its userbase and compatibility issues). To be clear, Secure Boot has even deeper access that sees past the kernel. To my knowledge, Easy Anti-Cheat has a Secure Boot requirement. This is at least what I have surmised from player discussions on Steam and whatnot for games that use EAC. If anyone has any information on this (maybe @Dulcibel can learn more insider knowledge from another conversation with support staff
...this is a UEFI level solution. The question becomes, what would be the next secure step to take when the firmware level anti-cheat inevitably (by nature) fails? I imagine it'd be an "Ashes Box" of sorts, i.e., some console running an OS proprietary to Intrepid. Or maybe we could all play on Local Area Networks at Intrepid-sponsored Internet cafes. I'm not being sarcastic–these would be the next logical solutions Intrepid could take to secure their game by completely controlling the environment in which it runs. In fact, these are the two only solutions I can think of, and that is if the industry standard keeps employing solutions that aim to delve increasingly deeper into end-users' private systems to secure their games. I actually would quite prefer having to buy an "Intrepid Deck" over the idea of having to purchase a new "throwaway" PC to install Ashes on (as not to download the Easy Anti-Cheat on my "main" PC). To be clear, I would not do that because I would not play a game that employed such a privileged level of anti-cheat software, but I like to think a substantial portion of players would feel forced into making that choice. Really, what is the difference in saving players the $1,000 to build a PC when they could buy a $400 Ashes Console? At this point, I'm speculating and ranting. I have a lot to say, but I will hop off my soapbox now and look forward to hearing what you think and researching some of the proffered alternatives, like the one below:
that's some serious long form copywriting to advertise that website. i wonder if that is lucibel's second account hmm.
anyways, imagine you use the solution provided by them, but on day one you start botting...so the behavioral profile will be of the bot since day one and the software will have no way of knowing since there wont even be switching from bot to human. gg
This is a valid point - but you need to also factor in the notion that the bot you are using can't be readily available on the internet at all.
If a developer can get hold of a bot, they can work out how to detect it - if they care to do so.
To be clear, I am not advertising that website, and @Dulcibel did not advertise that website either. To clear up any future confusion, we are merely acknowledging @leamese comment, bringing an alternative solution to our attention. While I can appreciate its concern, this thread's obsession with @Dulcibel "second account" is misplaced. I think it more productive to address the substance of the discussion rather than make arguments ad hominem.
― Plato
Indeed.
The main reason I can see for an MMORPG to want to use EAC specifically is that it is reasonably effective at preventing people running two instances of the game client on one computer.
With Ashes already having had a community vote that said multi-boxing was something we were generally willing to accept though, I don't see a need for that at all in Ashes.
The question fundamentally is whether Intrepid is willing to take part in this crazy cat-and-mouse game. I think having good GM staffing and server-based detection would go a long way in comparison to what's become the industry standard for games where it's a lot more possible to be subtle due to their faster pace.
Bring back dedicated GM staffing that plays alongside the players!!!
This was never effective as a means of anti-cheat, and in most games it wasn't their primary function.
Someone on the server as a character may see a player cheating and ban them. Someone working behind the scenes would be looking for signs of a given cheat, and then will sweep up and ban 10,000 players at once.
If given the choice, I'd rather all staff working on preventing cheating work behind the scenes.
Good point. And that is why I am here—to show Intrepid at least one player cares enough to leave the game.