#493 Wine Staging 10.5 can now run PGR, Reverse: 1999, and some others out of the box! (also ACE+Steam Deck info, HSR info, extra clarifications and announcements)

Open
opened 1 week ago by mkrsym1 · 1 comments
mkrsym1 commented 1 week ago

Thanks to the research tooling we developed for the WuWa project, we managed to figure out what exactly is preventing TPShell from working on Wine. Games using the ACE shell service without the kernel driver are now runnable out of the box on Wine Staging 10.5 (that is: PGR, R1999, more...), without patches like #451 or the custom exe from #454 .

Note that the updated syscall emulation patch in Staging is required. Non-staging Wine will not be able to run the games, unless the check is disabled serverside.

These modifications make all TPShell checks pass: the anticheat is running normally, as it would on Windows. This means that e.g. the anti-debug functionality is working even under Wine. Any games using the kernel driver (HI3, WuWa, Infinity Nikki, more...) will still not work out of the box.


Recently, there has been a lot of confusion about ACE games working on some Steam Deck devices. I want to clarify some of that with our research results.

There indeed is a Steam Deck specific check in TPShell/ACE. It is multi-factor, and verifies both the Deck hardware and that it's running on Wine and a Unix-like OS, and is not trivial to spoof. Contrary to lots of misinformation on the internet, it's not a "Wine disallow", instead it's more of a "Wine+Deck last resort allow".

How it works is if both Deck hardware and Wine are detected, it would skip a tremendous amount of checks. That is not only those which fail on Wine, but also the majority that work, and as a result this effectively amounts to the anticheat being disabled. Another interesting thing is that the skip is hardcoded, and cannot be disabled without modifying TPShell code.

The fact of there being no specific "anti-Wine" checks is also what allowed us to upstream the commits above: we just made all of the checks pass, so that they do not have to be skipped. We are not doing anything wrong, only bringing Wine behavior closer to that of Windows.

What this also means, is that with these patches, the only thing stopping ALL ACE games from working is the kernel driver, which the developers can disable.

Now, on the some part: in their infinite wisdom, the developers decided to hardcode only one Steam Deck hardware variant into the TPShell, of which there exist multiple (curiously, the specific variant is different between games). This leads to multiple interesting consequences:

  1. Whether the games you want will work on your specific Deck is dependent on how lucky you were with hardware when buying it (colloquially termed "the hardware gacha").
  2. If your Deck can run some ACE games, it means that it is guaranteed to be unable to run some other games.

Of course, the patches now in upstream can make any ACE game without a kernel driver run, even if you didn't win the hardware gacha for it.

Many on the internet have misinterpreted this as the devs blocking desktop Linux on purpose, while only allowing Steam Deck as a "trusted" platform. I don't believe that to be true: I'd speculate that they simply do not see desktop Linux as real. They have not done anything to block it specifically, merely "allowed" Wine on Steam Decks to enter even if failing checks. However, this is still quite unsettling.


You may have noticed how I still haven't mentioned HSR up to this point. That is because HSR recently decided to give up ACE entirely, and move to the same anticheat as Genshin/ZZZ! However, it is still not runnable out of the box. Jadeite supports HSR for legacy reasons, and only applies part of the workaround, without touching the new anticheat at all.

On the good side, there is now direct acknowledgement in code from miHoYo that Wine exists, and that they are deliberatly letting it pass. They are checking for the "wine_get_version" export being exposed, and if it is detected, they don't even try loading the kernel driver. This is different from Genshin/ZZZ behavior, which just allows the load to fail. This also means that enabling "Hide Wine version from applications" in staging settings will make the game not work. However, remember that there haven't been any official announcements from miHoYo on this topic, so don't be too vocal.

The reason why HSR still requires a workaround seems like an oversight. It has to do with another anti-cheat system of the game, which is also present in Genshin and ZZZ (but not in HI3).

In UnityPlayer.dll there is a function "WriteTextureStatisticUserData", the name is completely unrelated to what it actually does. The function is present in all miHoYo games except HI3, and performs a variety of checks, one of which happens to fail on Wine. The check in question verifies that the DirectX dlls are in the system's trust catalog (which is obviously not true on Wine), and I don't see a simple solution for this that can go upstream. Jadeite handles this by just stubbing the relevant functions to return success. The check in this function also fails in the other games.

The difference is in how the function acts on the result. In Genshin and ZZZ, it emits a command for the kernel driver to kill the game. That results in exactly nothing under Wine, as the driver failed to load. However, as HSR originally did not have the miHoYo kernel driver, the logic there was changed to just kill the game directly. Therefore, even though the check fails in all games, HSR is the only one where it actually results in something. I suspect that the developers just didn't think that this could happen when implementing the Wine allow, as the function "works" in all their other games.

Not sure about what can be done about it. I would strongly advice against spamming their support with this, as the Wine support was never mentioned or advertised anywhere, and they might end up just stopping to be so kind.


This was quite a write-up. If you have any comments or suggestions regarding something mentioned, or if you want to ask a question, you can do it in this thread.

Thanks to the research tooling we developed for the WuWa project, we managed to figure out what exactly is preventing TPShell from working on Wine. **Games using the ACE shell service without the kernel driver are now runnable out of the box on Wine Staging 10.5** (that is: PGR, R1999, more...), without patches like #451 or the custom exe from #454 . - https://gitlab.winehq.org/wine/wine/-/commit/2364128c56f58561f5204b445fa8abd8f9c56105 - https://gitlab.winehq.org/wine/wine-staging/-/commit/d88d44f1d9d94cb11aff9e2f0ce37d0d67fe1e95 **Note that the updated syscall emulation patch in Staging is required**. Non-staging Wine will not be able to run the games, unless the check is disabled serverside. These modifications make all TPShell checks pass: the anticheat is running normally, as it would on Windows. This means that e.g. the anti-debug functionality is working even under Wine. **Any games using the kernel driver (HI3, WuWa, Infinity Nikki, more...) will still not work out of the box**. --- **Recently, there has been a lot of confusion about ACE games working on *some* Steam Deck devices. I want to clarify some of that with our research results**. **There indeed is a Steam Deck specific check in TPShell/ACE**. It is multi-factor, and verifies both the Deck hardware and that it's running on Wine and a Unix-like OS, and is not trivial to spoof. **Contrary to lots of misinformation on the internet, it's not a "Wine disallow"**, instead it's more of a "Wine+Deck last resort allow". How it works is if both Deck hardware and Wine are detected, it would skip a tremendous amount of checks. That is not only those which fail on Wine, but also the majority that work, and as a result this effectively amounts to the anticheat being disabled. Another interesting thing is that the skip is hardcoded, and cannot be disabled without modifying TPShell code. The fact of there being no specific "anti-Wine" checks is also what allowed us to upstream the commits above: we just made all of the checks pass, so that they do not have to be skipped. We are not doing anything wrong, only bringing Wine behavior closer to that of Windows. **What this also means, is that with these patches, the only thing stopping *ALL* ACE games from working is the kernel driver, which the developers can disable**. Now, on the *some* part: in their infinite wisdom, the developers decided to hardcode only one Steam Deck hardware variant into the TPShell, of which there exist multiple (curiously, the specific variant is different between games). This leads to multiple interesting consequences: 1. Whether the games you want will work on your specific Deck is dependent on how lucky you were with hardware when buying it (colloquially termed "the hardware gacha"). 2. If your Deck can run some ACE games, it means that it is *guaranteed* to be unable to run some other games. Of course, the patches now in upstream can make any ACE game without a kernel driver run, even if you didn't win the hardware gacha for it. Many on the internet have misinterpreted this as the devs blocking desktop Linux on purpose, while only allowing Steam Deck as a "trusted" platform. I don't believe that to be true: I'd speculate that they simply do not see desktop Linux as real. They have not done anything to block it specifically, merely "allowed" Wine on Steam Decks to enter even if failing checks. However, this is still quite unsettling. --- You may have noticed how I still haven't mentioned HSR up to this point. That is because **HSR recently decided to give up ACE entirely, and move to the same anticheat as Genshin/ZZZ! However, it is still not runnable out of the box**. Jadeite supports HSR for legacy reasons, and only applies part of the workaround, without touching the new anticheat at all. On the good side, **there is now direct acknowledgement in code from miHoYo that Wine exists, and that they are deliberatly letting it pass**. They are checking for the "wine_get_version" export being exposed, and if it is detected, they don't even try loading the kernel driver. This is different from Genshin/ZZZ behavior, which just allows the load to fail. This also means that enabling "Hide Wine version from applications" in staging settings will make the game not work. **However, remember that there haven't been any official announcements from miHoYo on this topic, so don't be too vocal**. The reason why HSR still requires a workaround seems like an oversight. It has to do with another anti-cheat system of the game, which is also present in Genshin and ZZZ (but not in HI3). In UnityPlayer.dll there is a function "WriteTextureStatisticUserData", the name is completely unrelated to what it actually does. The function is present in all miHoYo games except HI3, and performs a variety of checks, one of which happens to fail on Wine. The check in question verifies that the DirectX dlls are in the system's trust catalog (which is obviously not true on Wine), and I don't see a simple solution for this that can go upstream. [Jadeite handles this by just stubbing the relevant functions to return success](https://codeberg.org/mkrsym1/jadeite/src/commit/d094a73cdf3e52f904fc98ab2c83d7c3c0a44df3/game_payload/src/hsr/hsr.c). The check in this function also fails in the other games. The difference is in how the function acts on the result. In Genshin and ZZZ, it emits a command for the kernel driver to kill the game. That results in exactly nothing under Wine, as the driver failed to load. However, as HSR originally did not have the miHoYo kernel driver, the logic there was changed to just kill the game directly. Therefore, even though the check fails in all games, HSR is the only one where it actually results in something. I suspect that the developers just didn't think that this could happen when implementing the Wine allow, as the function "works" in all their other games. Not sure about what can be done about it. **I would strongly advice against spamming their support with this, as the Wine support was never mentioned or advertised anywhere, and they might end up just stopping to be so kind**. --- This was quite a write-up. If you have any comments or suggestions regarding something mentioned, or if you want to ask a question, you can do it in this thread.
Krock commented 6 days ago
Owner

One step closer to Windows-levels of API buggy-ness is a great achievement. Thank you. False-information or erroneous interpretations should be corrected before they spread. I highly appreciate this detailed write-up and hope that NotABug is reliable enough in the future such that your clarification can be referred to when needed.

One step closer to Windows-levels of API buggy-ness is a great achievement. Thank you. False-information or erroneous interpretations should be corrected before they spread. I highly appreciate this detailed write-up and hope that NotABug is reliable enough in the future such that your clarification can be referred to when needed.
Sign in to join this conversation.
Loading...
Cancel
Save
There is no content yet.