Official release date: 28 Sept (pre-download 26 Sept)
Patch completion/script unlock: 1 Oct ¹
Progress so far (updated incrementally):
DONE - Locate the "check functions"
DONE - Locate the service start function
DONE - Locate & patch the manufacturer string ("Wine", new method)
DONE - Write patch skeleton
DONE - Anti-abuse quirk
DONE - Check for new launcher key
Tasks after official launch:
DONE - Dump "correct" values from a Windows installation
DONE - Check for newly added logging servers
DONE - Publish patch for testing
TODO - Test that patch (crowdsourcing)
Note: The CN counterpart is done by @y0soro and will have the same changes.
Please only answer to this issue if you have questions or helpful inputs.
¹) Might also take longer. New code is an unknown time factor.
Official release date: 28 Sept (pre-download 26 Sept)
Patch completion/script unlock: 1 Oct ¹
**Progress so far (updated incrementally):**
* DONE - Locate the "check functions"
* DONE - Locate the service start function
* DONE - Locate & patch the manufacturer string ("Wine", new method)
* DONE - Write patch skeleton
* DONE - Anti-abuse quirk
* DONE - Check for new launcher key
**Tasks after official launch:**
* DONE - Dump "correct" values from a Windows installation
* DONE - Check for newly added logging servers
* DONE - Publish patch for testing
* TODO - Test that patch (crowdsourcing)
Note: The CN counterpart is done by @y0soro and will have the same changes.
Please only answer to this issue if you have questions or helpful inputs.
¹) Might also take longer. New code is an unknown time factor.
AFAIK, beta 3.0.5x moved completely to a new anti-cheat system. If this change will be propagated into a regular release, that'd mean following:
1) UnityPlayer patching will become harder. They introduced several new integrity checks and bumped up paranoia level of VMProtect.
2) However, removing anticheat now is as easy as just deleting mhypbase.dll. That's it. The game will start and run perfectly fine without it.
This DLL is heavily obfuscated and contains the code for starting and controlling the new kernel driver. So far game doesn't view it's absence as an error, but that may change in the future.
So, we have one of the three possibilities ahead:
a) Nothing changes in the release, patch continues as usual;
b) Release moves to the new AC system, we disable it by just deleting it. We won't be able to disguise ourselves as "To Be Filled By O.E.M." anymore, but that actually might be for the best.
c) Release moves to the new AC system, MHY fixes the "optional anti-cheat" behaviour. That's the worst case, and I dare to guess how long will it take to circumvent.
@Krock if you think I gave away too much of info, you're free to shorten my post removing sensitive parts.
AFAIK, beta 3.0.5x moved completely to a new anti-cheat system. If this change will be propagated into a regular release, that'd mean following:
1) UnityPlayer patching will become harder. They introduced several new integrity checks and bumped up paranoia level of VMProtect.
2) However, removing anticheat now is as easy as just deleting `mhypbase.dll`. That's it. The game will start and run perfectly fine without it.
This DLL is heavily obfuscated and contains the code for starting and controlling the new kernel driver. So far game doesn't view it's absence as an error, but that may change in the future.
So, we have one of the three possibilities ahead:
a) Nothing changes in the release, patch continues as usual;
b) Release moves to the new AC system, we disable it by just deleting it. We won't be able to disguise ourselves as "To Be Filled By O.E.M." anymore, but that actually might be for the best.
c) Release moves to the new AC system, MHY fixes the "optional anti-cheat" behaviour. That's the worst case, and I dare to guess how long will it take to circumvent.
@Krock if you think I gave away too much of info, you're free to shorten my post removing sensitive parts.
After analyzing the pre-download files on Monday I will be able to tell more, but based on your input the chances are high that there is no day 0 patch this time around.
Whereas this change is unfortunate, I believe it is to replace their existing, vulnerable kernel service. Deleting a file seems to be too easy to be true, but I will try my best to make the game playable through Wine.
@Alex72 Thank you for this information.
After analyzing the pre-download files on Monday I will be able to tell more, but based on your input the chances are high that there is no day 0 patch this time around.
Whereas this change is unfortunate, I believe it is to replace their existing, vulnerable kernel service. Deleting a file seems to be too easy to be true, but I will try my best to make the game playable through Wine.
My sources informed me that MKT 3.1 ("MediaKit", client build that is distributed to the press and bloggers, basically a pre-release) follows 3.0.5x beta.
Whereas this change is unfortunate, I believe it is to replace their existing, vulnerable kernel service.
Maybe my explanation was a bit off. They completely replaced the old kernel driver (mhyprot2.sys) with a new one (mhyprot3.sys). Before that, game was using mhyprot2.sys but occasionally switched to mhyprot3.sys, kinda like A/B testing thing. (BTW, I suspect this switch might have been responsible for some random crashes people experienced using Linux patch).
AFAIK new AC is not that much secure and robust. The only difference is that the code controlling the new kernel driver is placed into mhypbase.dll which is loaded dynamically at startup. Game also doesn't seem to perform any kind of checks on this DLL, so you can provide your own DLL with the same interface (only two functions there, for initializing stuff and for running stuff). You can also just remove it and then the game will start and run very fine (I don't know if it'll be possible to connect to the official servers or not tho, but gameplay on alternatives is OK).
The code for controlling mhyprot2.sys is still there in UnityPlayer.dll but it seems to be unused.
My sources informed me that MKT 3.1 ("MediaKit", client build that is distributed to the press and bloggers, basically a pre-release) follows 3.0.5x beta.
> Whereas this change is unfortunate, I believe it is to replace their existing, vulnerable kernel service.
Maybe my explanation was a bit off. They completely replaced the old kernel driver (`mhyprot2.sys`) with a new one (`mhyprot3.sys`). Before that, game was using `mhyprot2.sys` but occasionally switched to `mhyprot3.sys`, kinda like A/B testing thing. (BTW, I suspect this switch might have been responsible for some random crashes people experienced using Linux patch).
AFAIK new AC is not that much secure and robust. The only difference is that the code controlling the new kernel driver is placed into `mhypbase.dll` which is loaded dynamically at startup. Game also doesn't seem to perform any kind of checks on this DLL, so you can provide your own DLL with the same interface (only two functions there, for initializing stuff and for running stuff). You can also just remove it and then the game will start and run very fine (I don't know if it'll be possible to connect to the official servers or not tho, but gameplay on _alternatives_ is OK).
The code for controlling `mhyprot2.sys` is still there in UnityPlayer.dll but it seems to be unused.
b) Release moves to the new AC system, we disable it by just deleting it. We won't be able to disguise ourselves as "To Be Filled By O.E.M." anymore, but that actually might be for the best.
Specifically on this point, and forgive me if this is speaking out of place: after using AAGL/flat on my Steam Deck in recent days/weeks, the Hoyoverse account dashboard shows Jupiter (Valve) as the System "Family" for that specific system (easily identified by the hostname). As well, some recent runs did show System Product Name (System manufacturer) instead of the classic To Be Filled, and my main account hasn't suffered adverse effects.
Just putting this out there for the sake of information. If the future "fix" is as funny as renaming the DLL, it will be... Interesting, to say the least.
> b) Release moves to the new AC system, we disable it by just deleting it. We won't be able to disguise ourselves as "To Be Filled By O.E.M." anymore, but that actually might be for the best.
Specifically on this point, and forgive me if this is speaking out of place: after using AAGL/flat on my Steam Deck in recent days/weeks, the Hoyoverse account dashboard shows `Jupiter (Valve)` as the System "Family" for that specific system (easily identified by the hostname). As well, some recent runs did show `System Product Name (System manufacturer)` instead of the classic `To Be Filled`, and my main account hasn't suffered adverse effects.
Just putting this out there for the sake of information. If the future "fix" is as funny as renaming the DLL, it will be... Interesting, to say the least.
It's indeed as easy as by just deleting mhypbase.dll to disable anti-cheat service, but that would changes validation codes so a UnityPlayer patching is still needed. (Also, RET patch can still disable the anti-cheat service so this extra process is not required.)
Luckily, they are still using old Application_RecordUserData mechanism in login process so we can at least bypass this specific check with our old patching method. But there might be other newly added validation mechanisms though.
edit: removed address info
-----------
It's indeed as easy as by just deleting mhypbase.dll to disable anti-cheat service, but that would changes validation codes so a UnityPlayer patching is still needed. (Also, RET patch can still disable the anti-cheat service so this extra process is not required.)
Luckily, they are still using old Application_RecordUserData mechanism in login process so we can at least bypass this specific check with our old patching method. But there might be other newly added validation mechanisms though.
For the record, I did try to just yeet the dll (mv mhypbase.dll derp.dll) but the unpacked game kinda just didn't load. WINE was doing some dark magicks 'n stuff as per htop but no window ever showed up.
Clearly it's not as straightforward as a simple yeet, and so the validation patch looks like it's necessary here.Will update this with a further test based on @alex72's comment.
WELP. Moved the DLL away, on a 3.1-updated install, and wouldn't you know, it started and it's pulling the data files I wasn't able to hdiff. @alex72 you were right.
For the record, I did try to just yeet the dll (`mv mhypbase.dll derp.dll`) but the unpacked game kinda just didn't load. WINE was doing some dark magicks 'n stuff as per `htop` but no window ever showed up.
~~Clearly it's not as straightforward as a simple yeet, and so the validation patch looks like it's necessary here.~~ ~~Will update this with a further test based on @alex72's comment.~~
[Tinfoil/Theorycrafting](https://notabug.org/cybik/dawn-overly-detailed-issues/wiki/3.1+Theorycrafting).
WELP. Moved the DLL away, on a 3.1-updated install, and wouldn't you know, it started and it's pulling the data files I wasn't able to hdiff. @alex72 you were right.
@cybik: the Steam deck is probably a good target to support, so maybe linux support is indeed coming. Or maybe this is just fallout from the mhyprot2 driver failure and probably imminent certificate revocation (if it didn't already happen). Whatever caused them to not go with mhyprot3 in all cases before definitely needed to be solved NOW.
Anyway, as a general warning for people who usually grab the testing release here early and jump on their main account (like myself), this time WAIT.
Those are some pretty large changes to the anti-cheat system, and even if they internally condone our usage, they might accidentally ban us all if they can't tell honest usage from cheaters.
It's probably a good idea to add another week of testing to the patch before release as well. Anyone who has any way of playing on windows or mobile should focus on those until things have been proven, or risk a considerably larger chance to getting their main accounts banned otherwise.
@cybik: the Steam deck is probably a good target to support, so maybe linux support is indeed coming. Or maybe this is just fallout from the mhyprot2 driver failure and probably imminent certificate revocation (if it didn't already happen). Whatever caused them to not go with mhyprot3 in all cases before definitely needed to be solved NOW.
Anyway, as a general warning for people who usually grab the testing release here early and jump on their main account (like myself), this time **WAIT**.
Those are some pretty large changes to the anti-cheat system, and even if they internally condone our usage, they might accidentally ban us all if they can't tell honest usage from cheaters.
It's probably a good idea to add another week of testing to the patch before release as well. Anyone who has any way of playing on windows or mobile should focus on those until things have been proven, or risk a considerably larger chance to getting their main accounts banned otherwise.
Wild speculations are not helpful here and should be put into a separate issue if further discussions are desired. It is very difficult to tell what effectively changed, just like when mhypbase was initially introduced. The testing phase's purpose to catch such issues and it is described accordingly.
Depending on Wednesday's results on the official server, I might consider to extend the testing period by a day or two.
As of now, the patch process appears to be unchanged. If there are issues on the official server I will try to find a solution for them.
@cybik @r4m0n
Wild speculations are not helpful here and should be put into a separate issue if further discussions are desired. It is very difficult to tell what effectively changed, just like when `mhypbase` was initially introduced. The testing phase's purpose to catch such issues and it is described accordingly.
Depending on Wednesday's results on the official server, I might consider to extend the testing period by a day or two.
---
As of now, the patch process appears to be unchanged. If there are issues on the official server I will try to find a solution for them.
...okay somehow just removing the dll and I can start the game with a new trash account and it just... works?
I do have the hosts overrides.
The one critical flaw right now is, looking at the web account dashboard, the unpatched game reports the System Family as "The Wine Project" instead of sourcing it from the hardware.
...okay somehow just removing the dll and I can start the game with a new trash account and it just... works?
I do have the hosts overrides.
The one critical flaw right now is, looking at the web account dashboard, the unpatched game reports the System Family as "The Wine Project" instead of sourcing it from the hardware.
The one critical flaw right now is, looking at the web account dashboard, the unpatched game reports the System Family as "The Wine Project" instead of sourcing it from the hardware.
That's a flaw in Wine, because game just uses standard Windows API functions to retrieve that information. But I think it's OK actually; miHoYo have other means to guess that we're running on Wine, so even if we're not hiding it explicitly we should be in the clear (after all, we were playing like that for quite a while). In fact, it might even be beneficial: they know we disabled AC not to tinker with the game but just to play it.
> The one critical flaw right now is, looking at the web account dashboard, the unpatched game reports the System Family as "The Wine Project" instead of sourcing it from the hardware.
That's a flaw in Wine, because game just uses standard Windows API functions to retrieve that information. But I think it's OK actually; miHoYo have other means to guess that we're running on Wine, so even if we're not hiding it explicitly we should be in the clear (after all, we were playing like that for quite a while). In fact, it might even be beneficial: they know we disabled AC not to tinker with the game but just to play it.
@Alex72 that is a bit too speculative for my tastes, they 'might' be too busy to act, they might only be allowing it because some of us buy stuff in game. however, they also might just cut us all at any point. its a dangerous thing to assume
@Alex72 that is a bit too speculative for my tastes, they 'might' be too busy to act, they might only be allowing it because some of us buy stuff in game. however, they also might just cut us all at any point. its a dangerous thing to assume
EDIT: Updated the pastebin link to include example values.
#### Testing patch 3.1.0 (OS) is done
As usual, please **use only testing accounts** until the patch is confirmed working. If everything goes well, patch unlock will be on 1 October.
---
The HTTP(S) logging servers were blocked to avoid the most obvious "Wine" string leak. This is fixed now.
Poll: Would you like to send [this system information (summary)](https://pastebin.com/raw/9FsjfFnk) to 2 (two) logging servers?
* Answers until 1 Oct: https://smart-polls.net/p/349Z6JS
* Currently, both domains are blocked.
EDIT: Updated the pastebin link to include example values.
Played for 30m. Did dailies, pulled, used resin, and tried the new character. No issues so far other than some stuttering (as usual with every patch).
Arch Linux (kernel 5.19.11), NVIDIA 515.76, lutris-7.2-2
Thanks!
Played for 30m. Did dailies, pulled, used resin, and tried the new character. No issues so far other than some stuttering (as usual with every patch).
Arch Linux (kernel 5.19.11), NVIDIA 515.76, lutris-7.2-2
Thanks!
Gentoo, kernel 5.19.3, nvidia-drivers 515.65.01, wine 7.17 with dxvk 1.10.3.
Clicking on Special Event -> Go to Event crashes rundll.exe for me, and have to reopen the game. Apart from this, everything runs fine. Thank you so much for the patch!
Gentoo, kernel 5.19.3, nvidia-drivers 515.65.01, wine 7.17 with dxvk 1.10.3.
Clicking on Special Event -> Go to Event crashes rundll.exe for me, and have to reopen the game. Apart from this, everything runs fine. Thank you so much for the patch!
First two runs was ended with freezes on loading, third run looks ok on my test account. Played about a hour, looks like it works.
Gentoo (Kernel 5.15.63), AMDGPU, Lutris 0.5.11, Wine: Lutris-7.1
R7 3800X/Radeon RX 6600XT
Will continue testing!
Played for around 1 hour, no issues encountered (aside from the usual stutter caused by DXVK).
Observations:
In my case, It seems that they fixed the CPU usage issue with certain kernel configurations (#195 issuecomment-30030). esync and fsync with CONFIG_HZ=300 behaves the same now as 1000 variant one.
Thank you very much!
Played for around 1 hour, no issues encountered (aside from the usual stutter caused by DXVK).
Observations:
- ~~In my case, It seems that they fixed the CPU usage issue with certain kernel configurations (https://notabug.org/Krock/dawn/issues/195#issuecomment-30030 issuecomment-30030). esync and fsync with `CONFIG_HZ=300` behaves the same now as `1000` variant one.~~
Thank you very much!
Unpatched, the system family was whack as said previously. It played though, wtf.
Phase 1 (trashies)
Play session 1: teleporting around the map, daylies, wishing: functional, nothing to report.
The System Family nit from the unpatched / phase-0 stage is rectified and behaves as per usual Dawn behaviour.
Logged in hours later, no auto-ban in place.
Logged in a bit later, still no auto-ban. Started some Liyue quest lines, no crashes or otherwise exploding behaviour.
Phase 2 (main)
Caution to the wind. 2h45 session. no instaban.
#### Test Results
##### Setup
* Linux: Pop_OS, i7 8700k, RTX 3080, Kernel 5.19.0-76051900-generic
* Wine: ProtonGE 7-35 manual
* Game patched via AAGL
#### Phase 0 (trashies)
Unpatched, the system family was whack as said previously. It played though, wtf.
#### Phase 1 (trashies)
* Play session 1: teleporting around the map, daylies, wishing: functional, nothing to report.
* The System Family nit from the unpatched / phase-0 stage is rectified and behaves as per usual Dawn behaviour.
* Logged in hours later, no auto-ban in place.
* Logged in a bit later, still no auto-ban. Started some Liyue quest lines, no crashes or otherwise exploding behaviour.
#### Phase 2 (main)
* Caution to the wind. 2h45 session. no instaban.
Tested couple more hours. Game works ok, not banned. Issue with special event mentioned by kumik is exist, but game is not crashing. Just have a button, that is not working.
When tried to explore Sumerian desert, game freezed, continuing with restart. Looks like not so big issue.
Tried to open all statues of archon in desert - received black screen. Restarted and looks like works ok.
Tested couple more hours. Game works ok, not banned. Issue with special event mentioned by kumik is exist, but game is not crashing. Just have a button, that is not working.
Gentoo (Kernel 5.15.63), AMDGPU, Lutris 0.5.11, Wine: Lutris-7.1
R7 3800X/Radeon RX 6600XT
Looks like all is ok.
Switched to main account.
When tried to explore Sumerian desert, game freezed, continuing with restart. Looks like not so big issue.
Tried to open all statues of archon in desert - received black screen. Restarted and looks like works ok.
The HTTP(S) logging servers were blocked to avoid the most obvious "Wine" string leak. This is fixed now.
Two questions:
Is the information sent onlyever that system information summary and never anything else?
Could this be a choice available to the user/launcher?
This way, more nervous people could choose not to have that information sent out, while folks happy with the risk (and/or wanting to send a message about using the Deck, for example) could choose to indeed let the game report that information
On the subject of the following:
> The HTTP(S) logging servers were blocked to avoid the most obvious "Wine" string leak. This is fixed now.
Two questions:
1. Is the information sent ***only*** *ever* that system information summary and never anything else?
2. Could this be a **choice** available to the user/launcher?
* This way, more nervous people could choose not to have that information sent out, while folks happy with the risk (and/or wanting to send a message about using the Deck, for example) could choose to indeed let the game report that information
I currently do not dissect the UDP game traffic. It is possible that certain information (see also: #293) is sent there.
Yes, that would be feasible. I will come back with a proposal after thinking about an implementation that does not make the script too messy if that's wanted.
I advise against switching to your main. Please wait a few days to be sure. The events last long enough.
@cybik
1. I currently do not dissect the UDP game traffic. It is possible that certain information (see also: #293) is sent there.
2. Yes, that would be feasible. I will come back with a proposal after thinking about an implementation that does not make the script too messy if that's wanted.
@ekz48
I advise against switching to your main. Please wait a few days to be sure. The events last long enough.
@ZAGON@Alex72, while I generally agree that we should be careful about remaining undetected, there is at least some anecdotal evidence, that they don't care too much about OS information.
I requested a copy of my personal data (according to GDPR Art. 15 for the data itself and Art. 20 for getting it in some nice CSV files) and after a long (and still ongoing) e-mail exchange, I received among other things a list of all my logins and all (probably not all?) the information they collect about them.
And among the deviceModel (which is shown on the Login Devices) website, it also contained an operatingSystem column (not sure if that is visible anywhere else).
For me, my Linux device was registered as something like "Windows 2003 Server Service Pack 3 (3.1.2517) 64bit" (my Wine configuration is admittedly not ideal).
So it seems that (at least for that column) there is little to no manual review of suspicious entries, and there also doesn't seem to be any kind of whitelist.
It might also be interesting to specifically request the "Security-Related Information" (as mentioned here: https://genshin.hoyoverse.com/en/company/privacy), to see how much information they successfully collect and thereby see what we need to be careful about.
vi. Security-Related Information. For the Android version: [...] for the PC version: application information, memory, executable module, system driver module, new thread, new load module, proxy, network, CPU, disk, and graphics card, account information, and device name, specific file types for specific directory, names of process windows, and name signature of suspicious process module, game identification information, game version, hardware and operating system information, application program list, current running task information, security authentication machine code, game and non-game abnormal process information, game operation-related calling methods and information, whether there are other external programs on the game interface, the record and data of the game attempted/accessed by the external program, the plug-in and file information related to the operation of the game, the impact of the external program information on the game; for the iOS version: [...] in accordance with Article 2(9) on the legal basis that it is our legitimate interest to ensure the security of our services.
However, it might be better to use a testing account for that (for me, they did not look deeper into the account data yet it seems, but there is of course no guarantee).
I apologise if this doesn't fit here, I just thought it might be some interesting information.
EDIT by Krock: Removed HTTP referer
@ZAGON @Alex72, while I generally agree that we should be careful about remaining undetected, there is at least some anecdotal evidence, that they don't care too much about OS information.
I requested a copy of my personal data (according to GDPR Art. 15 for the data itself and Art. 20 for getting it in some nice CSV files) and after a long (and still ongoing) e-mail exchange, I received among other things a list of all my logins and all (probably not all?) the information they collect about them.
And among the `deviceModel` (which is shown on the Login Devices) website, it also contained an `operatingSystem` column (not sure if that is visible anywhere else).
For me, my Linux device was registered as something like "Windows 2003 Server Service Pack 3 (3.1.2517) 64bit" (my Wine configuration is admittedly not ideal).
So it seems that (at least for that column) there is little to no manual review of suspicious entries, and there also doesn't seem to be any kind of whitelist.
It might also be interesting to specifically request the "Security-Related Information" (as mentioned here: `https://genshin.hoyoverse.com/en/company/privacy`), to see how much information they successfully collect and thereby see what we need to be careful about.
> vi. Security-Related Information. For the Android version: [...] for the PC version: application information, memory, executable module, system driver module, new thread, new load module, proxy, network, CPU, disk, and graphics card, account information, and device name, specific file types for specific directory, names of process windows, and name signature of suspicious process module, game identification information, game version, hardware and operating system information, application program list, current running task information, security authentication machine code, game and non-game abnormal process information, game operation-related calling methods and information, whether there are other external programs on the game interface, the record and data of the game attempted/accessed by the external program, the plug-in and file information related to the operation of the game, the impact of the external program information on the game; for the iOS version: [...] in accordance with Article 2(9) on the legal basis that it is our legitimate interest to ensure the security of our services.
However, it might be better to use a testing account for that (for me, they did not look deeper into the account data yet it seems, but there is of course no guarantee).
I apologise if this doesn't fit here, I just thought it might be some interesting information.
EDIT by Krock: Removed HTTP referer
Played for an hour or two on a testing account. Did commissions, spent some resin, did some wishes, ran a quest. No issues at all.
Arch Linux with Zen kernel 5.18.16, wine version lutris-ge-proton7-16, nvidia gtx 1070.
Played for an hour or two on a testing account. Did commissions, spent some resin, did some wishes, ran a quest. No issues at all.
Arch Linux with Zen kernel 5.18.16, wine version lutris-ge-proton7-16, nvidia gtx 1070.
I think "The Wine Project" reporting is still present even in latest wine-ge builds, as they are based on proton 7.0 that is based on wine 7.0.
I did some testing of this patch with alt account, only issue i saw so far was that sometimes captcha didnt load, and clicking x on it froze the game. After starting game again it worked.
I think "The Wine Project" reporting is still present even in latest wine-ge builds, as they are based on proton 7.0 that is based on wine 7.0.
I did some testing of this patch with alt account, only issue i saw so far was that sometimes captcha didnt load, and clicking x on it froze the game. After starting game again it worked.
i played for several hours on few alt accounts, yesterday and today.
by few i mean one account but i tried all 4 regions.
no issues at all.
i went around, unlocked countless waypoints, pulled cyno, did some quests, etc.
i also want to take this opportunity to ask of you all, days before a new update comes, you always get a survery in game. fill it up and in the last part, put "I'd love to be able to play this wonderful game on my Steam Deck." or something similar.
i played for several hours on few alt accounts, yesterday and today.
by few i mean one account but i tried all 4 regions.
no issues at all.
i went around, unlocked countless waypoints, pulled cyno, did some quests, etc.
---
i also want to take this opportunity to ask of you all, days before a new update comes, you always get a survery in game. fill it up and in the last part, put "I'd love to be able to play this wonderful game on my Steam Deck." or something similar.
@Alex72 - I hope yall consider keeping patching it until 3.2 or 3.3 - people using Proton right now won't have this patch for a while, unless GE starts bringing that patch in.
@Alex72 - I hope yall consider keeping patching it until 3.2 or 3.3 - people using Proton right now won't have this patch for a while, unless GE starts bringing that patch in.
I realize it's probably not related to the patch, but is anyone else suddenly experiencing extreme stuttering since 3.1? I know there's always some stuttering after each patch, but typically it subsides after a bit. On 3.1, it doesn't appear to be going away after several hours of play.
I realize it's probably not related to the patch, but is anyone else suddenly experiencing extreme stuttering since 3.1? I know there's always some stuttering after each patch, but typically it subsides after a bit. On 3.1, it doesn't appear to be going away after several hours of play.
@jingai I have noticed a little bit of stuttering that went away, however when entering the desert, i seem to get mote stuttering than usual.
otherwise everything is working fine on Kubuntu 22.04.1 on wine-7.12
@jingai I have noticed a little bit of stuttering that went away, however when entering the desert, i seem to get mote stuttering than usual.
otherwise everything is working fine on Kubuntu 22.04.1 on wine-7.12
This morning I couldn't get into the game from my main rig on either main or trashies. I wasn't not outright banned seeing as I could log in and play using alternate devices (phone), but my Steam Deck was able to log in just fine.
The mhypbase.dll file was in another directory on my main rig, but my Deck had no such experiments. Restoring the file on my main rig allowed it to get in.
This leads me to believe the anticheat had an initialization part that was not active on the server side yet. It now is, and thus renaming/removing mhypbase.dll will likely break loading the game from now on.
Something changed on the server:
This morning I couldn't get into the game from my main rig on either main or trashies. I wasn't not outright banned seeing as I could log in and play using alternate devices (phone), but my Steam Deck was able to log in just fine.
The `mhypbase.dll` file was in another directory on my main rig, but my Deck had no such experiments. Restoring the file on my main rig allowed it to get in.
This leads me to believe the anticheat had an initialization part that was not active on the server side yet. It now is, and thus renaming/removing `mhypbase.dll` will likely break loading the game *from now on*.
@cybik I had the exact same problem today on my trash account!
the game was just crashing itself after the elements loading screen after the door.
but restoring the mhypbase.dll solved this problem!
@cybik I had the exact same problem today on my trash account!
the game was just crashing itself after the elements loading screen after the door.
but restoring the `mhypbase.dll` solved this problem!
@12101111 (and others) Thank you for the information. Yet, the workaround has to stay due to the supported Wine versions 5.3 to 7.12. In long-term this is definitely helpful.
@jingaipatch_revert.sh will (and DXVK changes might) require re-building the shader cache file from scratch. The stutters will reduce after a while. If you would like to experiment, create a dxvk.conf file (see TWEAKS.md) and use d3d11.cachedDynamicResources to use additional caching. If you have further questions or issues, please open a separate issue.
@cybik I take this as good news. It means that their DLL does in fact run on Linux without causing issues (so far).
@12101111 (and others) Thank you for the information. Yet, the workaround has to stay due to the supported Wine versions 5.3 to 7.12. In long-term this is definitely helpful.
@jingai `patch_revert.sh` will (and DXVK changes might) require re-building the shader cache file from scratch. The stutters will reduce after a while. If you would like to experiment, create a `dxvk.conf` file (see TWEAKS.md) and use [d3d11.cachedDynamicResources](https://github.com/doitsujin/dxvk/blob/b2ad25755a7085ea9eac5f120ba4aa7a587e2ed5/dxvk.conf#L224-L236) to use additional caching. If you have further questions or issues, please open a separate issue.
@cybik I take this as good news. It means that their DLL does in fact run on Linux without causing issues (so far).
@cybik@johnssh This is very interesting behaviour and it is totally different from that I can see in 3.0.5x beta builds - they won't even start with mhypbase present due to kernel service initialization failure on Wine.
Maybe they've changed something in the release build. This is likely the case. Before 3.0.5x I've used simple ret patch to disable AC in betas (no point in spoofing stuff sent to the server if you can't connect to the server anyway, right?), and with 3.0.5x I wasn't able to patch UnityPlayer.dll - any change to it was immediately detected either by VMProtect or some other protection function. But on 3.1.0 release Krock said
the patch process appears to be unchanged
Maybe they rolled back some changes or used some another method. (I haven't downloaded the release yet to investigate and confirm.)
@cybik @johnssh This is very interesting behaviour and it is totally different from that I can see in 3.0.5x beta builds - they won't even start with `mhypbase` present due to kernel service initialization failure on Wine.
Maybe they've changed something in the release build. This is likely the case. Before 3.0.5x I've used simple `ret` patch to disable AC in betas (no point in spoofing stuff sent to the server if you can't connect to the server anyway, right?), and with 3.0.5x I wasn't able to patch UnityPlayer.dll - any change to it was immediately detected either by VMProtect or some other protection function. But on 3.1.0 release Krock said
> the patch process appears to be unchanged
Maybe they rolled back some changes or used some another method. (I haven't downloaded the release yet to investigate and confirm.)
playing for a few hours now, no issues and everything runs fine. tho I did get some bad stutter for 4-7 seconds upon loading into the game(loaded in next to the 3.0 domain). I wanna highlight that because I have a rig that is very very powerful. so anyone that is running this on something that 'should' run it, might get a lot worse stuttering. seems to be especially bad in the 3.x updates. I know a windows users that has had it alot worse than I have (on a mid system) so its not just a WINE thing either.
playing for a few hours now, no issues and everything runs fine. tho I did get some bad stutter for 4-7 seconds upon loading into the game(loaded in next to the 3.0 domain). I wanna highlight that because I have a rig that is very very powerful. so anyone that is running this on something that 'should' run it, might get a lot worse stuttering. seems to be especially bad in the 3.x updates. I know a windows users that has had it alot worse than I have (on a mid system) so its not just a WINE thing either.
Thank you for all test reports. No further issues found. The patch script is now unlocked.
@Alex72 Hopefully this is beta-specific to avoid leaks or messing with the game prior to release. I will try to find a solution when the time comes.
Thank you for all test reports. No further issues found. The patch script is now unlocked.
---
@Alex72 Hopefully this is beta-specific to avoid leaks or messing with the game prior to release. I will try to find a solution when the time comes.
Official release date: 28 Sept (pre-download 26 Sept)
Patch completion/script unlock: 1 Oct ¹
Progress so far (updated incrementally):
Tasks after official launch:
Note: The CN counterpart is done by @y0soro and will have the same changes.
Please only answer to this issue if you have questions or helpful inputs.
¹) Might also take longer. New code is an unknown time factor.
AFAIK, beta 3.0.5x moved completely to a new anti-cheat system. If this change will be propagated into a regular release, that'd mean following:
1) UnityPlayer patching will become harder. They introduced several new integrity checks and bumped up paranoia level of VMProtect.
2) However, removing anticheat now is as easy as just deleting
mhypbase.dll. That's it. The game will start and run perfectly fine without it.This DLL is heavily obfuscated and contains the code for starting and controlling the new kernel driver. So far game doesn't view it's absence as an error, but that may change in the future.
So, we have one of the three possibilities ahead:
a) Nothing changes in the release, patch continues as usual;
b) Release moves to the new AC system, we disable it by just deleting it. We won't be able to disguise ourselves as "To Be Filled By O.E.M." anymore, but that actually might be for the best.
c) Release moves to the new AC system, MHY fixes the "optional anti-cheat" behaviour. That's the worst case, and I dare to guess how long will it take to circumvent.
@Krock if you think I gave away too much of info, you're free to shorten my post removing sensitive parts.
@Alex72 Thank you for this information.
After analyzing the pre-download files on Monday I will be able to tell more, but based on your input the chances are high that there is no day 0 patch this time around. Whereas this change is unfortunate, I believe it is to replace their existing, vulnerable kernel service. Deleting a file seems to be too easy to be true, but I will try my best to make the game playable through Wine.
My sources informed me that MKT 3.1 ("MediaKit", client build that is distributed to the press and bloggers, basically a pre-release) follows 3.0.5x beta.
Maybe my explanation was a bit off. They completely replaced the old kernel driver (
mhyprot2.sys) with a new one (mhyprot3.sys). Before that, game was usingmhyprot2.sysbut occasionally switched tomhyprot3.sys, kinda like A/B testing thing. (BTW, I suspect this switch might have been responsible for some random crashes people experienced using Linux patch).AFAIK new AC is not that much secure and robust. The only difference is that the code controlling the new kernel driver is placed into
mhypbase.dllwhich is loaded dynamically at startup. Game also doesn't seem to perform any kind of checks on this DLL, so you can provide your own DLL with the same interface (only two functions there, for initializing stuff and for running stuff). You can also just remove it and then the game will start and run very fine (I don't know if it'll be possible to connect to the official servers or not tho, but gameplay on alternatives is OK).The code for controlling
mhyprot2.sysis still there in UnityPlayer.dll but it seems to be unused.Specifically on this point, and forgive me if this is speaking out of place: after using AAGL/flat on my Steam Deck in recent days/weeks, the Hoyoverse account dashboard shows
Jupiter (Valve)as the System "Family" for that specific system (easily identified by the hostname). As well, some recent runs did showSystem Product Name (System manufacturer)instead of the classicTo Be Filled, and my main account hasn't suffered adverse effects.Just putting this out there for the sake of information. If the future "fix" is as funny as renaming the DLL, it will be... Interesting, to say the least.
edit: removed address info
It's indeed as easy as by just deleting mhypbase.dll to disable anti-cheat service, but that would changes validation codes so a UnityPlayer patching is still needed. (Also, RET patch can still disable the anti-cheat service so this extra process is not required.)
Luckily, they are still using old Application_RecordUserData mechanism in login process so we can at least bypass this specific check with our old patching method. But there might be other newly added validation mechanisms though.
For the record, I did try to just yeet the dll (
mv mhypbase.dll derp.dll) but the unpacked game kinda just didn't load. WINE was doing some dark magicks 'n stuff as perhtopbut no window ever showed up.Clearly it's not as straightforward as a simple yeet, and so the validation patch looks like it's necessary here.Will update this with a further test based on @alex72's comment.Tinfoil/Theorycrafting.
WELP. Moved the DLL away, on a 3.1-updated install, and wouldn't you know, it started and it's pulling the data files I wasn't able to hdiff. @alex72 you were right.
@cybik: the Steam deck is probably a good target to support, so maybe linux support is indeed coming. Or maybe this is just fallout from the mhyprot2 driver failure and probably imminent certificate revocation (if it didn't already happen). Whatever caused them to not go with mhyprot3 in all cases before definitely needed to be solved NOW.
Anyway, as a general warning for people who usually grab the testing release here early and jump on their main account (like myself), this time WAIT.
Those are some pretty large changes to the anti-cheat system, and even if they internally condone our usage, they might accidentally ban us all if they can't tell honest usage from cheaters.
It's probably a good idea to add another week of testing to the patch before release as well. Anyone who has any way of playing on windows or mobile should focus on those until things have been proven, or risk a considerably larger chance to getting their main accounts banned otherwise.
@cybik Try to move DLL away from the game directory. I deleted it completely and game was starting fine for me.
@cybik @r4m0n
Wild speculations are not helpful here and should be put into a separate issue if further discussions are desired. It is very difficult to tell what effectively changed, just like when
mhypbasewas initially introduced. The testing phase's purpose to catch such issues and it is described accordingly.Depending on Wednesday's results on the official server, I might consider to extend the testing period by a day or two.
As of now, the patch process appears to be unchanged. If there are issues on the official server I will try to find a solution for them.
...okay somehow just removing the dll and I can start the game with a new trash account and it just... works?
I do have the hosts overrides.
The one critical flaw right now is, looking at the web account dashboard, the unpatched game reports the System Family as "The Wine Project" instead of sourcing it from the hardware.
That's a flaw in Wine, because game just uses standard Windows API functions to retrieve that information. But I think it's OK actually; miHoYo have other means to guess that we're running on Wine, so even if we're not hiding it explicitly we should be in the clear (after all, we were playing like that for quite a while). In fact, it might even be beneficial: they know we disabled AC not to tinker with the game but just to play it.
@Alex72 that is a bit too speculative for my tastes, they 'might' be too busy to act, they might only be allowing it because some of us buy stuff in game. however, they also might just cut us all at any point. its a dangerous thing to assume
Testing patch 3.1.0 (OS) is done
As usual, please use only testing accounts until the patch is confirmed working. If everything goes well, patch unlock will be on 1 October.
The HTTP(S) logging servers were blocked to avoid the most obvious "Wine" string leak. This is fixed now.
Poll: Would you like to send this system information (summary) to 2 (two) logging servers?
EDIT: Updated the pastebin link to include example values.
@Krock I think it'd be a good idea to show the example of data being sent
Played for 30m. Did dailies, pulled, used resin, and tried the new character. No issues so far other than some stuttering (as usual with every patch).
Arch Linux (kernel 5.19.11), NVIDIA 515.76, lutris-7.2-2
Thanks!
Gentoo, kernel 5.19.3, nvidia-drivers 515.65.01, wine 7.17 with dxvk 1.10.3.
Clicking on Special Event -> Go to Event crashes rundll.exe for me, and have to reopen the game. Apart from this, everything runs fine. Thank you so much for the patch!
First two runs was ended with freezes on loading, third run looks ok on my test account. Played about a hour, looks like it works.
Gentoo (Kernel 5.15.63), AMDGPU, Lutris 0.5.11, Wine: Lutris-7.1
R7 3800X/Radeon RX 6600XT
Will continue testing!
Played for around 1 hour, no issues encountered (aside from the usual stutter caused by DXVK).
Observations:
In my case, It seems that they fixed the CPU usage issue with certain kernel configurations (#195 issuecomment-30030). esync and fsync withCONFIG_HZ=300behaves the same now as1000variant one.Thank you very much!
Test Results
Setup
Phase 0 (trashies)
Unpatched, the system family was whack as said previously. It played though, wtf.
Phase 1 (trashies)
Phase 2 (main)
Tested couple more hours. Game works ok, not banned. Issue with special event mentioned by kumik is exist, but game is not crashing. Just have a button, that is not working.
Gentoo (Kernel 5.15.63), AMDGPU, Lutris 0.5.11, Wine: Lutris-7.1
R7 3800X/Radeon RX 6600XT
Looks like all is ok.
Switched to main account.
When tried to explore Sumerian desert, game freezed, continuing with restart. Looks like not so big issue.
Tried to open all statues of archon in desert - received black screen. Restarted and looks like works ok.
On the subject of the following:
Two questions:
Tested for a couple hours, no issues with the patch, just minor stuttering. Arch 5.19.11-arch1-1 on lutris 6.10.5, R5 3500x + GTX 1070
@cybik
@ekz48
I advise against switching to your main. Please wait a few days to be sure. The events last long enough.
@ZAGON @Alex72, while I generally agree that we should be careful about remaining undetected, there is at least some anecdotal evidence, that they don't care too much about OS information.
I requested a copy of my personal data (according to GDPR Art. 15 for the data itself and Art. 20 for getting it in some nice CSV files) and after a long (and still ongoing) e-mail exchange, I received among other things a list of all my logins and all (probably not all?) the information they collect about them.
And among the
deviceModel(which is shown on the Login Devices) website, it also contained anoperatingSystemcolumn (not sure if that is visible anywhere else). For me, my Linux device was registered as something like "Windows 2003 Server Service Pack 3 (3.1.2517) 64bit" (my Wine configuration is admittedly not ideal).So it seems that (at least for that column) there is little to no manual review of suspicious entries, and there also doesn't seem to be any kind of whitelist.
It might also be interesting to specifically request the "Security-Related Information" (as mentioned here:
https://genshin.hoyoverse.com/en/company/privacy), to see how much information they successfully collect and thereby see what we need to be careful about.However, it might be better to use a testing account for that (for me, they did not look deeper into the account data yet it seems, but there is of course no guarantee).
I apologise if this doesn't fit here, I just thought it might be some interesting information.
EDIT by Krock: Removed HTTP referer
Played for an hour or two on a testing account. Did commissions, spent some resin, did some wishes, ran a quest. No issues at all.
Arch Linux with Zen kernel 5.18.16, wine version lutris-ge-proton7-16, nvidia gtx 1070.
The problem of "The Wine Project" is fixed in Wine 7.13: https://gitlab.winehq.org/wine/wine/-/commit/fefe108e2043d8a9d993b4e2cb129c851ca5e795
@12101111 That's really nice to know, thanks! That means we can skip patching this.
I think "The Wine Project" reporting is still present even in latest wine-ge builds, as they are based on proton 7.0 that is based on wine 7.0.
I did some testing of this patch with alt account, only issue i saw so far was that sometimes captcha didnt load, and clicking x on it froze the game. After starting game again it worked.
i played for several hours on few alt accounts, yesterday and today. by few i mean one account but i tried all 4 regions. no issues at all. i went around, unlocked countless waypoints, pulled cyno, did some quests, etc.
i also want to take this opportunity to ask of you all, days before a new update comes, you always get a survery in game. fill it up and in the last part, put "I'd love to be able to play this wonderful game on my Steam Deck." or something similar.
@Alex72 - I hope yall consider keeping patching it until 3.2 or 3.3 - people using Proton right now won't have this patch for a while, unless GE starts bringing that patch in.
I realize it's probably not related to the patch, but is anyone else suddenly experiencing extreme stuttering since 3.1? I know there's always some stuttering after each patch, but typically it subsides after a bit. On 3.1, it doesn't appear to be going away after several hours of play.
@jingai I have noticed a little bit of stuttering that went away, however when entering the desert, i seem to get mote stuttering than usual.
otherwise everything is working fine on Kubuntu 22.04.1 on wine-7.12
Something changed on the server:
This morning I couldn't get into the game from my main rig on either main or trashies. I wasn't not outright banned seeing as I could log in and play using alternate devices (phone), but my Steam Deck was able to log in just fine.
The
mhypbase.dllfile was in another directory on my main rig, but my Deck had no such experiments. Restoring the file on my main rig allowed it to get in.This leads me to believe the anticheat had an initialization part that was not active on the server side yet. It now is, and thus renaming/removing
mhypbase.dllwill likely break loading the game from now on.@cybik I had the exact same problem today on my trash account!
the game was just crashing itself after the elements loading screen after the door. but restoring the
mhypbase.dllsolved this problem!@12101111 (and others) Thank you for the information. Yet, the workaround has to stay due to the supported Wine versions 5.3 to 7.12. In long-term this is definitely helpful.
@jingai
patch_revert.shwill (and DXVK changes might) require re-building the shader cache file from scratch. The stutters will reduce after a while. If you would like to experiment, create adxvk.conffile (see TWEAKS.md) and use d3d11.cachedDynamicResources to use additional caching. If you have further questions or issues, please open a separate issue.@cybik I take this as good news. It means that their DLL does in fact run on Linux without causing issues (so far).
@cybik @johnssh This is very interesting behaviour and it is totally different from that I can see in 3.0.5x beta builds - they won't even start with
mhypbasepresent due to kernel service initialization failure on Wine.Maybe they've changed something in the release build. This is likely the case. Before 3.0.5x I've used simple
retpatch to disable AC in betas (no point in spoofing stuff sent to the server if you can't connect to the server anyway, right?), and with 3.0.5x I wasn't able to patch UnityPlayer.dll - any change to it was immediately detected either by VMProtect or some other protection function. But on 3.1.0 release Krock saidMaybe they rolled back some changes or used some another method. (I haven't downloaded the release yet to investigate and confirm.)
playing for a few hours now, no issues and everything runs fine. tho I did get some bad stutter for 4-7 seconds upon loading into the game(loaded in next to the 3.0 domain). I wanna highlight that because I have a rig that is very very powerful. so anyone that is running this on something that 'should' run it, might get a lot worse stuttering. seems to be especially bad in the 3.x updates. I know a windows users that has had it alot worse than I have (on a mid system) so its not just a WINE thing either.
Thank you for all test reports. No further issues found. The patch script is now unlocked.
@Alex72 Hopefully this is beta-specific to avoid leaks or messing with the game prior to release. I will try to find a solution when the time comes.