Did you plan to patch the future game Wuthering waves ? I heard that the anti-cheat is not simple to patch, just to know so we can prepare for it.
Hey,
first of all, thank for your work
Did you plan to patch the future game Wuthering waves ? I heard that the anti-cheat is not simple to patch, just to know so we can prepare for it.
@ALEZ-DEV WW looks interesting. The world is in a more modern setting but aside from that it does seem to be very similar to Genshin.
From what I have seen so far, its anti-cheat implementation is far from trivial to get around. They are using Tencent's Anti-Cheat Expert and the Unreal Engine 4, which is somewhat different compared to what Genshin uses.
As for now, I would like to spend my time on other topics, which also includes providing support for Genshin if needed. That is - at least as long the developers keep the game interesting interesting (as in: content).
On a side note - I assume that mkrsym1 would have more knowledge and skill than me to pull this off (see HSR/HI3rd, also using ACE). But at the end it also boils down to whether someone is willing to spend countless hours on debugging and try & error.
@ALEZ-DEV WW looks interesting. The world is in a more modern setting but aside from that it does seem to be very similar to Genshin.
From what I have seen so far, its anti-cheat implementation is far from trivial to get around. They are using Tencent's Anti-Cheat Expert and the Unreal Engine 4, which is somewhat different compared to what Genshin uses.
As for now, I would like to spend my time on other topics, which also includes providing support for Genshin if needed. That is - at least as long the developers keep the game interesting interesting (as in: content).
On a side note - I assume that mkrsym1 would have more knowledge and skill than me to pull this off (see HSR/HI3rd, also using ACE). But at the end it also boils down to whether someone is willing to spend countless hours on debugging and try & error.
I did, in fact, do some research on WuWa, in particular on the first beta back then.
ACE can be split into two main parts: TPShell (so called "client hardening") and the main anticheat component.
TPShell is basically the anticheat's "first line of defense" - it does not include any active "cheat" prevention features and does not report account-identifiable information to servers - it just contains general things for making the experience of reverse engineering the game (or other anticheat components) miserable.
The main anticheat component is modular and may include optional features. It is called by the game code and does operate with account-identifiable information.
Hoyo games (both HI3 and HSR) only include TPShell - with actual "anti-cheating" functionality being handled by Hoyo's own code (which causes no issues on Wine in HI3, and minimal, easily patchable issues in HSR).
TPShell includes what Tencent name "component binding" - a technique to prevent someone from just starting the game directly, bypassing the "client hardening". It is present in Hoyo games (bypassing it is what jadeite is for), but it appears to be optional (see PGR and R1999).
How it is implemented differs between engines:
In Unity games, the approach is "breaking" a part of game code and then recovering it in runtime, in a special way which makes primitive dumping useless. Jadeite exists specifically to bypass this kind of "component binding".
In Unreal games, the approach looks to be just packing the entire game executable, then unpacking it in runtime before starting the game. While the unpacking process seems to be much more difficult to replicate, I assume that just dumping the unpacked executable would be enough, however I did not test this yet. Another downside of this approach is that it would require the user to have a working Windows install.
Almost the entire TPShell binary (named <exe-name>Base.dll and located in the game directory) is put under unique proprietary virtualization, which slows down research a lot. Finding out which parts specifically break under Wine is not at all trivial (it is not only the kernel driver, and the kernel driver is optional too), so my current approach is just throwing basically the entire thing out the window.
The most concerning module of the main anticheat component in WuWa is the so called "SGuard" - a service that is installed globally on the system and runs in parallel with the game.
Hoyo games completely lack the main anticheat component, however we (me and Teapot) have accidentally stumbled upon it in a different Unity game, and decided to take a look. After bypassing TPShell, we have discovered that SGuard does not work on Wine. Fortunately, it turned out to be pretty easy to make the thing shut up by writing a dummy dll after a "reasonable" amount of debugging. However, there appears to be some kind of challenge response mechanism there, which also appears to be unused in this game specifically, so there might be surprises trying that on WuWa. Also, if you are wondering, a working TPShell will not let you just put the dummy dll in.
WuWa includes both TPShell (obviously, the Unreal Engine variant) and the main anticheat component, so it will need a lot of work. Maybe I/we will get to it one day.
Obviously I am leaving out a lot of details here. Contact me directly if you want more in-depth explanations.
Note: the first WuWa beta was extremely resource intensive - even the main menu barely ran (~4FPS) on my 3GB 1060. That does not add motivation. However, this might have gotten better with time. Another thing is that the in-game browser implementation uses some weird windowing things that will likely break on Wine.
I did, in fact, do some research on WuWa, in particular on the first beta back then.
ACE can be split into two main parts: TPShell (so called "client hardening") and the main anticheat component.
TPShell is basically the anticheat's "first line of defense" - it does not include any active "cheat" prevention features and does not report account-identifiable information to servers - it just contains general things for making the experience of reverse engineering the game (or other anticheat components) miserable.
The main anticheat component is modular and may include optional features. It is called by the game code and does operate with account-identifiable information.
Hoyo games (both HI3 and HSR) only include TPShell - with actual "anti-cheating" functionality being handled by Hoyo's own code (which causes no issues on Wine in HI3, and minimal, easily patchable issues in HSR).
TPShell includes what Tencent name "component binding" - a technique to prevent someone from just starting the game directly, bypassing the "client hardening". It is present in Hoyo games (bypassing it is what jadeite is for), but it appears to be optional (see PGR and R1999).
How it is implemented differs between engines:
- In Unity games, the approach is "breaking" a part of game code and then recovering it in runtime, in a special way which makes primitive dumping useless. Jadeite exists specifically to bypass this kind of "component binding".
- In Unreal games, the approach looks to be just packing the entire game executable, then unpacking it in runtime before starting the game. While the unpacking process seems to be much more difficult to replicate, I assume that just dumping the unpacked executable would be enough, however I did not test this yet. Another downside of this approach is that it would require the user to have a working Windows install.
Almost the entire TPShell binary (named `<exe-name>Base.dll` and located in the game directory) is put under unique proprietary virtualization, which slows down research a lot. Finding out which parts specifically break under Wine is not at all trivial (it is not only the kernel driver, and the kernel driver is optional too), so my current approach is just throwing basically the entire thing out the window.
The most concerning module of the main anticheat component in WuWa is the so called "SGuard" - a service that is installed globally on the system and runs in parallel with the game.
Hoyo games completely lack the main anticheat component, however we (me and Teapot) have accidentally stumbled upon it in a different Unity game, and decided to take a look. After bypassing TPShell, we have discovered that SGuard does not work on Wine. Fortunately, it turned out to be pretty easy to make the thing shut up by writing a dummy dll after a "reasonable" amount of debugging. However, there appears to be some kind of challenge response mechanism there, which also appears to be unused in this game specifically, so there might be surprises trying that on WuWa. Also, if you are wondering, a working TPShell will not let you just put the dummy dll in.
WuWa includes both TPShell (obviously, the Unreal Engine variant) and the main anticheat component, so it will need a lot of work. Maybe I/we will get to it one day.
Obviously I am leaving out a lot of details here. Contact me directly if you want more in-depth explanations.
Note: the first WuWa beta was extremely resource intensive - even the main menu barely ran (~4FPS) on my 3GB 1060. That does not add motivation. However, this might have gotten better with time. Another thing is that the in-game browser implementation uses some weird windowing things that will likely break on Wine.
Prototype WuWa workaround done (turned out to be a lot more work than just dump-recover). Currently will have to figure out organization issues (as I am not the only author).
This is an extension of the dump approach, so it does require you to have Windows, but after you dump it once, you should be able to play on Wine until the next version update.
Ban risk is extremely high, there are many "questionable elements" in the workaround.
Another issue is that apparently a huge part of the game is clientside, so the project might attract lots of unwanted attention. Would appreciate suggestions on how to combat that.
# Status update
**Prototype WuWa workaround done** (turned out to be a lot more work than just dump-recover). Currently will have to figure out organization issues (as I am not the only author).
This is an extension of the dump approach, so it does require you to have Windows, but after you dump it once, you should be able to play on Wine until the next version update.
Ban risk is extremely high, there are many "questionable elements" in the workaround.
Another issue is that apparently a huge part of the game is clientside, so the project might attract lots of unwanted attention. Would appreciate suggestions on how to combat that.
That is great to hear. Thank you (and your collaborators) for investing this much time into research. Depending on what needs to be dumped it might be possible in the future to write a custom function to parse, hook and load the necessary information directly from the game files.
Another issue is that apparently a huge part of the game is clientside
This would perfectly explain as for why the developers chose to use the whole bag of the available anticheat components. Regardless, cheaters will find a way to bypass the AC and uncover missing server checks.
Would appreciate suggestions on how to combat that.
The less information is provided, the less likely it is for such facts to spread into the wrong direction. A necessary step is to make any custom starter application (for loading the dump) incompatible with Windows. Even though it would not comply with the FLOSS philosophy, the dumping process/steps/instructions would not be opened to the public and instead provide a binary file. This means more effort but is in my opinion the safest approach.
> Prototype WuWa workaround done
That is great to hear. Thank you (and your collaborators) for investing this much time into research. Depending on what needs to be dumped it might be possible in the future to write a custom function to parse, hook and load the necessary information directly from the game files.
> Another issue is that apparently a huge part of the game is clientside
This would perfectly explain as for why the developers chose to use the whole bag of the available anticheat components. Regardless, cheaters will find a way to bypass the AC and uncover missing server checks.
> Would appreciate suggestions on how to combat that.
The less information is provided, the less likely it is for such facts to spread into the wrong direction. A necessary step is to make any custom starter application (for loading the dump) incompatible with Windows. Even though it would not comply with the FLOSS philosophy, the dumping process/steps/instructions would not be opened to the public and instead provide a binary file. This means more effort but is in my opinion the safest approach.
Warning: this is highly experimental and the ban risk is very high. Please only use testing accounts.
We are working on making dumping not required, but that will likely take a lot longer than it took to make this workaround.
Published here: https://codeberg.org/TeamHarmony/harmonic
Warning: this is highly experimental and the ban risk is very high. Please only use testing accounts.
We are working on making dumping not required, but that will likely take a lot longer than it took to make this workaround.
New discovery: apparently, the game runs far enough on recent GE-Proton to make the dump, and even to make dumping not necessary. It does however run far enough for the driver to try to load, fail, and complain, but that is extremely trivial to bypass. You can likely even run harmonic_dumper.exe on GE-Proton, then harmonic_loader.exe on a different version.
EDIT 3: It appears like that is extremely unstable and only works reasonably well on Steam Deck devices.
This does not implement any kind of a TPShell bypass, instead it relies on it loading normally under GE-Proton. However I have a multitude of problems with how the driver bypass is implemented:
Loading it is done by adding a d3d9.dll to the game directory, and then also a bypass.dll. Sure, what can go wrong replacing things devs check for the most? For comparision, you straight up cannot do that in a Hoyo game: it will remove the file
The bypass.dll in question looks to be taken from a known Windows cheat. Again, this is like asking for collateral damage
I will somehow try to reach the author to inform them of this again.
EDIT: I have reached the author. Currently resolving things.
EDIT 2: They have renamed the repository.
## Status update
New discovery: apparently, the game runs far enough on recent GE-Proton to make the dump, and even to make dumping not necessary. It does however run far enough for the driver to try to load, fail, and complain, but that is extremely trivial to bypass. You can likely even run harmonic_dumper.exe on GE-Proton, then harmonic_loader.exe on a different version.
EDIT 3: It appears like that is extremely unstable and only works reasonably well on Steam Deck devices.
Which brings me to this thing: https://github.com/t4bby/wuthering-waves-linux . The repo name is a problem, but I did not find any author contact information to inform them.
This does not implement any kind of a TPShell bypass, instead it relies on it loading normally under GE-Proton. However I have a multitude of problems with how the driver bypass is implemented:
- Loading it is done by adding a `d3d9.dll` to the game directory, and then also a `bypass.dll`. Sure, what can go wrong replacing things devs check for the most? For comparision, you straight up cannot do that in a Hoyo game: it will remove the file
- The `bypass.dll` in question looks to be taken from a **known Windows cheat**. Again, this is like asking for collateral damage
I will somehow try to reach the author to inform them of this again.
EDIT: I have reached the author. Currently resolving things.
EDIT 2: They have renamed the repository.
It appears like as of 1.1.0, the game now works out of the box, with no workarounds required. I cannot say anything about whether this is intentional, or an error that will be fixed. I will continue to monitor the situation.
EDIT: Unfortunately, they fixed it. Dumping is required again.
**It appears like as of 1.1.0, the game now works out of the box, with no workarounds required**. I cannot say anything about whether this is intentional, or an error that will be fixed. I will continue to monitor the situation.
**EDIT**: Unfortunately, they fixed it. Dumping is required again.
@Th1nkCh3ck I've seen similar news in the past month. Such headlines are based on misinterpretation and/or exaggeration of Microsoft's plans (assuming they can already be called plans at this point). I think this video explains it very well: https://www.youtube.com/watch?v=vVjhNjClHqI
Needless to say - please open a separate issue if you'd like to discuss this topic.
@Th1nkCh3ck I've seen similar news in the past month. Such headlines are based on misinterpretation and/or exaggeration of Microsoft's plans (assuming they can already be called plans at this point). I think this video explains it very well: https://www.youtube.com/watch?v=vVjhNjClHqI
Needless to say - please open a separate issue if you'd like to discuss this topic.
Hey,
first of all, thank for your work
Did you plan to patch the future game Wuthering waves ? I heard that the anti-cheat is not simple to patch, just to know so we can prepare for it.
@ALEZ-DEV WW looks interesting. The world is in a more modern setting but aside from that it does seem to be very similar to Genshin.
From what I have seen so far, its anti-cheat implementation is far from trivial to get around. They are using Tencent's Anti-Cheat Expert and the Unreal Engine 4, which is somewhat different compared to what Genshin uses.
As for now, I would like to spend my time on other topics, which also includes providing support for Genshin if needed. That is - at least as long the developers keep the game interesting interesting (as in: content).
On a side note - I assume that mkrsym1 would have more knowledge and skill than me to pull this off (see HSR/HI3rd, also using ACE). But at the end it also boils down to whether someone is willing to spend countless hours on debugging and try & error.
I did, in fact, do some research on WuWa, in particular on the first beta back then.
ACE can be split into two main parts: TPShell (so called "client hardening") and the main anticheat component.
TPShell is basically the anticheat's "first line of defense" - it does not include any active "cheat" prevention features and does not report account-identifiable information to servers - it just contains general things for making the experience of reverse engineering the game (or other anticheat components) miserable.
The main anticheat component is modular and may include optional features. It is called by the game code and does operate with account-identifiable information.
Hoyo games (both HI3 and HSR) only include TPShell - with actual "anti-cheating" functionality being handled by Hoyo's own code (which causes no issues on Wine in HI3, and minimal, easily patchable issues in HSR).
TPShell includes what Tencent name "component binding" - a technique to prevent someone from just starting the game directly, bypassing the "client hardening". It is present in Hoyo games (bypassing it is what jadeite is for), but it appears to be optional (see PGR and R1999).
How it is implemented differs between engines:
Almost the entire TPShell binary (named
<exe-name>Base.dlland located in the game directory) is put under unique proprietary virtualization, which slows down research a lot. Finding out which parts specifically break under Wine is not at all trivial (it is not only the kernel driver, and the kernel driver is optional too), so my current approach is just throwing basically the entire thing out the window.The most concerning module of the main anticheat component in WuWa is the so called "SGuard" - a service that is installed globally on the system and runs in parallel with the game.
Hoyo games completely lack the main anticheat component, however we (me and Teapot) have accidentally stumbled upon it in a different Unity game, and decided to take a look. After bypassing TPShell, we have discovered that SGuard does not work on Wine. Fortunately, it turned out to be pretty easy to make the thing shut up by writing a dummy dll after a "reasonable" amount of debugging. However, there appears to be some kind of challenge response mechanism there, which also appears to be unused in this game specifically, so there might be surprises trying that on WuWa. Also, if you are wondering, a working TPShell will not let you just put the dummy dll in.
WuWa includes both TPShell (obviously, the Unreal Engine variant) and the main anticheat component, so it will need a lot of work. Maybe I/we will get to it one day.
Obviously I am leaving out a lot of details here. Contact me directly if you want more in-depth explanations.
Note: the first WuWa beta was extremely resource intensive - even the main menu barely ran (~4FPS) on my 3GB 1060. That does not add motivation. However, this might have gotten better with time. Another thing is that the in-game browser implementation uses some weird windowing things that will likely break on Wine.
Status update
Prototype WuWa workaround done (turned out to be a lot more work than just dump-recover). Currently will have to figure out organization issues (as I am not the only author).
This is an extension of the dump approach, so it does require you to have Windows, but after you dump it once, you should be able to play on Wine until the next version update.
Ban risk is extremely high, there are many "questionable elements" in the workaround.
Another issue is that apparently a huge part of the game is clientside, so the project might attract lots of unwanted attention. Would appreciate suggestions on how to combat that.
That is great to hear. Thank you (and your collaborators) for investing this much time into research. Depending on what needs to be dumped it might be possible in the future to write a custom function to parse, hook and load the necessary information directly from the game files.
This would perfectly explain as for why the developers chose to use the whole bag of the available anticheat components. Regardless, cheaters will find a way to bypass the AC and uncover missing server checks.
The less information is provided, the less likely it is for such facts to spread into the wrong direction. A necessary step is to make any custom starter application (for loading the dump) incompatible with Windows. Even though it would not comply with the FLOSS philosophy, the dumping process/steps/instructions would not be opened to the public and instead provide a binary file. This means more effort but is in my opinion the safest approach.
Published here: https://codeberg.org/TeamHarmony/harmonic
Warning: this is highly experimental and the ban risk is very high. Please only use testing accounts.
We are working on making dumping not required, but that will likely take a lot longer than it took to make this workaround.
Status update
New discovery: apparently, the game runs far enough on recent GE-Proton to make the dump, and even to make dumping not necessary. It does however run far enough for the driver to try to load, fail, and complain, but that is extremely trivial to bypass. You can likely even run harmonic_dumper.exe on GE-Proton, then harmonic_loader.exe on a different version.
EDIT 3: It appears like that is extremely unstable and only works reasonably well on Steam Deck devices.
Which brings me to this thing: https://github.com/t4bby/wuthering-waves-linux . The repo name is a problem, but I did not find any author contact information to inform them.
This does not implement any kind of a TPShell bypass, instead it relies on it loading normally under GE-Proton. However I have a multitude of problems with how the driver bypass is implemented:
d3d9.dllto the game directory, and then also abypass.dll. Sure, what can go wrong replacing things devs check for the most? For comparision, you straight up cannot do that in a Hoyo game: it will remove the filebypass.dllin question looks to be taken from a known Windows cheat. Again, this is like asking for collateral damageI will somehow try to reach the author to inform them of this again.
EDIT: I have reached the author. Currently resolving things.
EDIT 2: They have renamed the repository.
It appears like as of 1.1.0, the game now works out of the box, with no workarounds required. I cannot say anything about whether this is intentional, or an error that will be fixed. I will continue to monitor the situation.
EDIT: Unfortunately, they fixed it. Dumping is required again.
Recent 1.3 has rolled out and a patch I currently have no longer worked.
Any update for WW 1.2?
I believe anti-cheats will die as time goes on https://steamdeckhq.com/news/we-may-see-end-of-kernel-level-anti-cheat/
@Th1nkCh3ck I've seen similar news in the past month. Such headlines are based on misinterpretation and/or exaggeration of Microsoft's plans (assuming they can already be called plans at this point). I think this video explains it very well: https://www.youtube.com/watch?v=vVjhNjClHqI
Needless to say - please open a separate issue if you'd like to discuss this topic.