Pirulax
commented
3 years ago To me it seems like it's more like a warning (like 'Hey, close these programs before starting MTA'), not a direct AC measure.
Closed dmex closed 3 years ago
Pirulax
commented
3 years ago To me it seems like it's more like a warning (like 'Hey, close these programs before starting MTA'), not a direct AC measure.
LosFaul
commented
3 years ago looking at these i believe this has a fully different purpose something like: saying hello to 90% of newbies and tell them "better let it be"
Lpsd
commented
3 years ago As mentioned by @Pirulax , this is probably so we can have a friendly message for users to close these programs, before it's handled by the AC. This also allows us to add more soft-detections without needing updates to netc.
dmex
commented
3 years ago it's more like a warning
If there's a policy against X then it needs to equally indiscriminate against all programs and not just one specific application.
windbg -> allowed.
Task Explorer -> allowed.
Winast64 -> allowed.
WKE -> allowed.
bcdedit debug on -> patch kernel -> allowed?
PH -> banned?
Users can do all these things without generating a warning but the policy/messaging only targets the one specific application?
This also allows us to add more soft-detections without needing updates to netc.
Last I heard a few years ago MTA was using FairplayKD anticheat which does use ObRegisterCallbacks and so all functionality is otherwise disabled and limited by FairplayKD meaning it's 100% compatible with both FairplayKD and MTA - If this is still the case then these warnings are misleading and should be removed.
so we can have a friendly message for users to close these programs,
You'll get warnings for PH but won't get warnings with PH forks with a different UI skin and identical functionality? Task Explorer is literally PH yet won't show the same 'warning' you would otherwise get when using PH so you're telling users this specific tool is bad/banned while the exact same tool with a different skin is allowed which makes no sense.
I can link hundreds of other forks and tools here on github where MTA won't show these warnings. So from my point of view these warning dialogs nothing but a personal grudge against me or just a personal bias against our project in favour of competitors software... That's fine, you're welcome to your opinion and product choices but you shouldn't be using your position as developers to push your opinion/bias onto others and misleading them with FUD via nonsense warning dialogs.
If MTA is using FairplayKD and it's using ObRegisterCallbacks then both CE and PH handles are already being stripped and both tools are 100% compatible with MTA and can only show limited information/functionality identical to Windows Task Manager and Microsoft Process Explorer so there's literally no point even showing messages/warnings for either tool?
Lpsd
commented
3 years ago I can see where you're coming from, it seems a bit obsolete, since the AC will handle this stuff nowadays. Just old code (there's enough floating around).
I had to read your post a few times to decipher the word salad about grudges and FUD. No, this isn't some personal attack on you or your project, god knows whoever wrote that code and in what year?
How would an end-user possibly perceive that "warning" as some kind of slander to your project? It's complete fantasy - I could of swore I was reading a Roald Dahl novel.
If you're still adamant that we're somehow "out to get you" or slander your project based on some obsolete code floating around from a decade ago, head over to our Discord - we'll discuss it there. GitHub is for code, not conspiracies.
TLDR; old/obsolete code(?) - should be reviewed and possibly removed.
AlexTMjugador
commented
3 years ago In my opinion, this warning is probably just there to let people know that MTA has an AC, creating some kind of "chilling effect" that defers people from cheating, by telling them they should close programs that may modify the expected operation of other processes. It definitely is not there to stop someone who knows what is doing, be exhaustive, or be technically accurate and correct.
ccw808
commented
3 years ago personal bias against our project in favour of competitors software
PH is an excellent well written tool and we have no bias against it. It is detected for the simple reason that it is very popular. If you would like to add more tools to this warning, then please submit a pull request
Dutchman101
commented
3 years ago You're making quite a few assumptions in this issue, and have gotten it totally wrong at several ends throughout your posts.
I will combine some of the things you implied (those that are related to the same truth as to why it's incorrect) below:
- It's trivially bypassed by renaming the executables that are checked by this function.
- It's trivially bypassed by running these programs after MTA has already started running.
- It does not block software such as
windbgorx64dbgwhich have considerably more functionality. It does not block or prevent forks of these projects. In the case of Process Hacker there are more than 700 forks for example https://github.com/DavidXanatos/TaskExplorer and not even one of those are checked or blocked.None of these applications are targeting MTA so why single out and target these applications without targeting others like windbg?
If there's a policy against X then it needs to equally indiscriminate against all programs and not just one specific application.
windbg-> allowed.Task Explorer-> allowed.Winast64-> allowed.WKE-> allowed.PH-> banned?
All of the statements in the above quotes are incorrect. So, please let me enlighten you, so that we can avoid any further misunderstandings.
The truth here is that the ForbodenProgramsMessage is not anticheat (just old code, who knows if AC already detected it back then.. probably not) and that AC is responsible for detecting this software, which it does without using that function.
Like we have informed you of in the distant past, AC isn't a part of this repository - so we apologize if that being the case caused any confusion on exactly what in MTA is responsible for making players unable to join the game unless they close certain types of tools (such as Process Hacker). I also realize that old code (sometimes even being named with "AntiCheat", or even entire code files that claim to be the AC) in this repository fosters misconceptions as well.
It is advised to do your own research next time (not just based on hearsay or vague old code in our repository) which should probably include running MTA and watching how AC reacts on ProcessHacker and many similar tools, so there won't be so many misconceptions and you wouldn't have to write this thing without being aware that MTA treats similar software (with a potential for cheating / use as debugging tool by cheat developers) the same, and just like running Process Hacker running tools such as from your list will also result in such a kick by AC.
Relevant AC kicks happen when you launch MTA, the violating tool is running and you try to connect to a server to play the game. However, the amount of similar tools (and many others that pose a security risk to AC) already detected and kicked for by AC these days is much bigger than the list in "ForbodenProgramsMessage" because that list is old & outdated at the moment. Updating it (or removing - minus user experience) can be a good idea, see bottom of this reply for more on that.
Also, things you said (included in the above mention) like "Bypassing is trivial" are incorrect, as since the AC handles violating tools & software (with a potential for cheating / use as debugging tool) completely separately from the "ForbodenProgramsMessage" function, in its own more secure way that doesn't even use software filename / path at all.
In case next up is that you're frustrated about principles like anti-cheat is blocking tools that have a potential to help cheaters / be used as a debugging tool by cheat developers, then the answer is fairly simple: we block tools posing such risks, no matter which tool, as soon we discover about them and if at that moment, they are undetected by AC. So it's not discriminating or bias upon ProcessHacker, which is also evidenced by that other (and similar) programs you claimed to not be blocked are in fact blocked by AC. The AC blocks for security reasons, not for any sort of bias or grudge - MTA AC team takes great care in determining which tools are supposed to be detected with AC kicks and which therefore have to close before playing the game (from a security / AC perspective). Besides, when it comes to other AC's in the gaming industry, getting such tools detected is pretty much standard.
Trying to take on the AC industry when it comes to the capabilities tools need to have for them to be considered a security risk & detected, is probably a lost battle.. we have found that for example, you contacted VAC anti-cheat in the past and received the following reply:
I guess that if you're the developer of tools with the kind of capabilities that tools like ProcessHacker have, you gotta try to understand the ramifications on people that play games with advanced AC.
Anyways, you, let's assume accidentally - went completely off the road with your ideas of the "ForbodenProgramsMessage" function. Even if that function is removed, AC will continue kicking the players for a violation that is using tools like in the "ForbodenProgramsMessage" software list. So removing it won't help anything in practise, at most it will affect the user experience as like someone already said:
this is probably so we can have a friendly message for users to close these programs, before it's handled by the AC.
Then there won't be advise to the user to close it on time, before the AC gets to them. But AC will still do so (and for security reasons, not make the kick go away until MTA is restarted, even after closing the offending tool) so therefore removing the friendly warning message will only adversely affect user experience.
If you want to improve the user experience, instead of all this negativity we'd need to (and you can help us with that, through a PR) add more tools and software that are already in fact detected by MTA AC to that list, for warning & give users an opportunity to close it beforehand. Maybe the fact that it's old code and hasn't been kept updated to reflect similar tools that any AC has a reason to detect for security reasons, is what led to your impression of that "MTA was discriminating against / has bias" but I hope that changed now you can read how things really work.
dmex
commented
3 years ago How would an end-user possibly perceive that "warning" as some kind of slander to your project?
People are accustomed to only ever seeing these types of block messages for malicious software and they view these messages such we've doing something malicious otherwise MTA wouldn't force them to close the application.
Every year someone emails questions about MTA wanting information about what PH does to generate these messages, stop that behavior and make it compatible or they uninstall in favor of other products and the best solution I have is ignoring them because I don't have any reasonable answers to give them.
running MTA and watching how AC reacts on ProcessHacker and many similar tools
MTA is the only AC blocking PH these days.
the AC handles violating tools & software (with a potential for cheating / use as debugging tool) completely separately from the "ForbodenProgramsMessage" function, in its own more secure way that doesn't even use software filename / path at all.
It's using the \device\ string we pass into IoCreateDevice for the detection which is technically a GPL violation because that's 1:1 copied from our source code - It should be using the certificate information instead since that data is generated by third parties and not part of the source-code protected by the GPL.
then the answer is fairly simple: we block tools posing such risks, no matter which tool, as soon we discover about them and if at that moment, they are undetected by AC
What are these risks? What feature or function causes a problem?
You're already using ObRegisterCallbacks to correctly disable all functionality:
Why also block the entire application when these features are already disabled? What risks or issues or features are missed by ObRegisterCallbacks that are causing a problem for MTA?
Trying to take on the AC industry when it comes to the capabilities tools need to have for them to be considered a security risk & detected, is probably a lost battle.. we have found that for example, you contacted VAC anti-cheat in the past and received the following reply:
Thanks for copying my own emails on this subject... You wouldn't know from that forum thread because I never published the full discussion with Valve after going public with that email but things have changed for the better and we have direct contacts with the VAC team.
Valve has done a 180 and backtracked on those demands - none of those features they asked changed or removed were ever changed or removed and more importantly the messages/blocks Valve used to target PH were removed entirely instead as were all VAC bans for PH have also been removed.
How's that for "Trying to take on the AC industry"? 😂
Targeting Process Hacker was a terrible experiment that did nothing to help anti-cheat and yielded no results and zero benefit... So the block messages and other things targeting Process Hacker were completely removed back in 2018... It only served to benefit competitors and attackers whom used Valve as their justification/excuse for why they've targeted PH - Valve did this so we're doing it too, no discussion, case closed.
AC will continue kicking the players for a violation that is using tools like in the "ForbodenProgramsMessage" software list. So removing it won't help anything in practise, at most it will affect the user experience as like someone already said:
I'm having a hard time understanding the point of kicks/bans after you've already limited that same software via ObRegisterCallbacks? That callback has already disabled all functionality so what's the point of kick/banning when those tools can't do anything anyway?
For comparison:
Valve Anti-Cheat:
BattlEye:
Easy Anti-Cheat:
Rockstar:
These are the only games that I had available to test and I did not get kicked or banned for running PH and none of them forced me to close PH and yet these same anti-cheats also protect thousands of other games from AAA publishers... Rockstar doesn't use any AC whatsoever and also doesn't care about PH.
The single reason for why they don't block, kick or ban anyone for running Process Hacker is because they're using ObRegisterCallbacks and disable all functionality so you can safely use Process Hacker while ingame - having an extra kick/ban/forced shutdown is pointless and gross.
programs you claimed to not be blocked are in fact blocked by AC.
Every other game/anticheat uses ObRegisterCallbacks which limits Process Hacker and none of them show any warnings/block messages.
The AC blocks for security reasons
The precedence/domination order for security is generally seen to be viewed with this order:
1) Operating System 2) Security products (Antivirus) 3) System Tools (Task Managers/Process Hacker) 4) Web Browsers (Chrome/Firefox) 5) Entertainment products (Games)
How do you view the domination order for AC/games?
1) Operating System 2) Entertainment products (Games/Anticheat) 3) Security products (Antivirus) 4) System Tools (Task Managers/Process Hacker) 5) Web Browsers (Chrome/Firefox)
PH is an excellent well written tool and we have no bias against it. It is detected for the simple reason that it is very popular. If you would like to add more tools to this warning, then please submit a pull request
Can you give me an actual technical reason for blocking PH? What feature or functionality is a problem so that I can look into it. Stating that the block is because it's popular is FUD and doesn't help identify the underlying technical issue.
If you want to improve the user experience, instead of all this negativity we'd need to (and you can help us with that, through a PR) add more tools and software that are already in fact detected by MTA AC to that list, for warning & give users an opportunity to close it beforehand.
If you want an list of debuggers, task managers and exploited kernel drivers then there's a nice complete list available here: https://raw.githubusercontent.com/fireeye/sunburst_countermeasures/main/fnv1a_xor_hashes.txt
Are you sure you want to go this route? Have you not considered more effectively detecting cheats by server telemetry with some analytics for statistics/entity interaction?
Dutchman101
commented
3 years ago Can you give me an actual technical reason for blocking PH
then the answer is fairly simple: we block tools posing such risks, no matter which tool, as soon we discover about them and if at that moment, they are undetected by AC
What are these risks? What feature or function causes a problem?
We aren't willing to discuss technicalities about our AC in depth like that, we never do that. But from a security perspective, we have our reasons. They aren't limited to solvable with ObRegisterCallbacks.
MTA is the only AC blocking PH these days.
That's incorrect. But even if it wasn't, then the above answer (about security reasons) stands.
It's using the \device\ string we pass into IoCreateDevice for the detection which is technically a GPL violation because that's 1:1 copied from our source code - It should be using the certificate information instead since that data is generated by third parties and not part of the source-code protected by the GPL.
That is not true. It's not close to what AC uses for this detection. The detection doesn't use your source code. Also, as said before, our AC is closed-source. For the same security reasons as from first answer in this reply, we aren't willing to discuss any method detections or the trivially used type: to detect individual tools, or tools with certain capabilities.
Every year someone emails questions about MTA wanting information about what PH does to generate these messages
Well, then unfortunately.. so be it. MTA AC team solely decides what is blocked.
Thanks for copying my own emails on this subject
We have discovered that there's an attitude problem on your side (on the internet) as toxic and "I am special" kind of behavior can be found under your name all over places. Word soups, where you go into lenghts based on misconceptions or assumptions, eventually making accusations/attacking with stern terms (even when the service provider you're ranting against was actively helping you). It's unfortunate some people into those kind of things, are looking to stir opensource drama as well.
Eventually, now all of your reasonable questions have been answerred. But you don't seem to get the concept. You may disagree, but with all of your accusations/assumptions properly addressed until this point, we can just say this: it's up to MTA AC team to decide which capabilities on tools make it to be detected. We simply don't have the time required to address further invalid statements (that we can expect if we don't end it here), we did a decent bunch. I tried to keep it civil as much as possible (even though we realized some stuff).. but now it just gets annoying.
To hopefully meet you midway, we removed Ph from "ForbodenProgramsMessage" in commit ff93fec - again, this wasn't any sort of AC detection. It was obsolete old code, but purely to warn users.. to have the opportunity of closing a program before AC will cause them to get kicked (making them have to restart the game after closing).
Hey,
This ForbodenProgramsMessage function should be removed from MTA.
windbgorx64dbgwhich have considerably more functionality.It doesn't make any sense to have that type of function in MTA considering these issues. None of these applications are targeting MTA so why single out and target these applications without targeting others like windbg? This block by MTA also causes issues for people whom have enabled the "make default task manager" with PH since MTA is effectively blocking the user' default task manager/ctrl+alt+del and very malware-esque/illegal and not appropriate.
MTA should instead be using the ObRegisterCallbacks function which works by removing permissions such as VM_READ/VM_WRITE in highly reliable way for every application without needing to target specific individual applications. This would also be much more resilient to changes that might be introduced into Process Hacker in future preventing this type of abuse by MTA and malware targeting filenames.
Thanks, PH dev