#476 Future WW patch

Open
opened 3 weeks ago by ALEZ-DEV · 5 comments
ALEZ-DEV commented 3 weeks ago

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.

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.
Krock commented 3 weeks ago
Owner

@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.
mkrsym1 commented 3 weeks ago

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.
mkrsym1 commented 5 days ago

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.

# 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.
Krock commented 5 days ago
Owner

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.

> 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.
mkrsym1 commented 1 day ago

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.

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.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.