Hello there. I'm lurking this repo for some time now, and I use it to play GI from time to time, but decided to make an account just today, and create this ticket because of a new game that I'll possibly spend much more time on than GI. This game is Honkai Star Rail which is going to be publicly available in a month. Knowing H*yo, it's also going to have anti-cheat system, probably as "easy" to bypass as in GI case. I quote "easy" because with no doubt it wasn't that straightforward to figure it all out so it would work, so all the devs from here have my absolute respect (I'm a programmer myself but I'm not experienced in reverse engineering, one time Notabug was down and there was supposed to be new patch for GI I was trying to figure out how to make such patch myself, but failed miserably).
What I'm interested in is a way to figure out such anti-cheat bypassing patch myself, so I could start similar project for that incoming new game. Knowing how to create a patch for GI isn't exactly the goal, because now, as it's already figured out, it's just a matter of applying certain set of steps on new binaries to prepare a new patch, or at least that's how I see how preparing new patches looks like. So basically I'd be willing to learn how to figure out bypassing anti-cheat in a game such as GI or incoming Honkai (I bet they'll also use Unity for that so it should be at least somehow similar to GI in that matter). There is some technical data available at this repo, sure, but imo not enough to start other similar project for another game. So basically what I'm saying is I'd like to learn from you guys how to even make preparations for reverse engineering a game in such a way that would allow me to figure out how to bypass its anti-cheat, so I could run it on Linux also.
In the unlikely scenario this game turns out to be runnable on Linux out of the box this knowledge is probably not going to be useful to me, but I'm still willing to learn it as it most probably will come handy.
What do you guys think? Could you fill me in somehow? Or at least point me out to some valuable tutorials that could help me start?
Hello there. I'm lurking this repo for some time now, and I use it to play GI from time to time, but decided to make an account just today, and create this ticket because of a new game that I'll possibly spend much more time on than GI. This game is Honkai Star Rail which is going to be publicly available in a month. Knowing H*yo, it's also going to have anti-cheat system, probably as "easy" to bypass as in GI case. I quote "easy" because with no doubt it wasn't that straightforward to figure it all out so it would work, so all the devs from here have my absolute respect (I'm a programmer myself but I'm not experienced in reverse engineering, one time Notabug was down and there was supposed to be new patch for GI I was trying to figure out how to make such patch myself, but failed miserably).
What I'm interested in is a way to figure out such anti-cheat bypassing patch myself, so I could start similar project for that incoming new game. Knowing how to create a patch for GI isn't exactly the goal, because now, as it's already figured out, it's just a matter of applying certain set of steps on new binaries to prepare a new patch, or at least that's how I see how preparing new patches looks like. So basically I'd be willing to learn how to figure out bypassing anti-cheat in a game such as GI or incoming Honkai (I bet they'll also use Unity for that so it should be at least somehow similar to GI in that matter). There is some technical data available at this repo, sure, but imo not enough to start other similar project for another game. So basically what I'm saying is I'd like to learn from you guys how to even make preparations for reverse engineering a game in such a way that would allow me to figure out how to bypass its anti-cheat, so I could run it on Linux also.
In the unlikely scenario this game turns out to be runnable on Linux out of the box this knowledge is probably not going to be useful to me, but I'm still willing to learn it as it most probably will come handy.
What do you guys think? Could you fill me in somehow? Or at least point me out to some valuable tutorials that could help me start?
Thank you for your interest. I also started with zero reverse engineering knowledge. Over a period of 1.5 months I familiarized myself with the available tools until there was finally a breakthrough.
This repository contains the ingredients but not the recipe to "bake" your own patch. Those who actively follow the project for a longer time might already have an overall idea how it works but I will not disclose any instructions to prevent abuse by cheaters and countermeasures by the game developers.
However, if it happens that HSR uses the same protections, I could give you the necessary information to get started. But depending on the anti-cheat solution they are using (e.g. Anti-cheat Expert) a new approach might be needed in the first place.
I would say a good start is to get familiar with the existing reverse engineering and cheater tools (see TOOLS.md as an example). Interestingly our and the cheater's interests partially overlap, albeit different goals.
Which anti-cheat(s) they are using? Can you get the game to start?
EDIT: Like with Honkai, there is no personal interest from my side either to take care of this game, see #214 as reference.
Thank you for your interest. I also started with zero reverse engineering knowledge. Over a period of 1.5 months I familiarized myself with the available tools until there was finally a breakthrough.
This repository contains the ingredients but not the recipe to "bake" your own patch. Those who actively follow the project for a longer time might already have an overall idea how it works but I will not disclose any instructions to prevent abuse by cheaters and countermeasures by the game developers.
However, if it happens that HSR uses the same protections, I could give you the necessary information to get started. But depending on the anti-cheat solution they are using (e.g. Anti-cheat Expert) a new approach might be needed in the first place.
I would say a good start is to get familiar with the existing reverse engineering and cheater tools (see TOOLS.md as an example). Interestingly our and the cheater's interests partially overlap, albeit different goals.
Which anti-cheat(s) they are using? Can you get the game to start?
EDIT: Like with Honkai, there is no personal interest from my side either to take care of this game, see https://notabug.org/Krock/dawn/issues/214#issuecomment-28122 as reference.
It's in closed beta and I'm not taking part in it sadly, so I don't know. It's going to be publicly available on April 26th and pre-download is to be available on April 23rd or so.
Like with Honkai, there is no personal interest from my side either to take care of this game
It wouldn't be fair to make you take care of another game, besides I already stated that I'm willing to take care of it myself (or at least I could try, it might be a valuable experience to have, not to mention being able to play the game on Linux).
However, if it happens that HSR uses the same protections, I could give you the necessary information to get started
That would be great. Do you think there is enough information right now for you to judge it may be similar or not? Or is it better to wait for pre-download to be available before judging anything?
In the meantime, I'll look into TOOLS.md as you said. I already have used Ghidra, but I need to get familiar with other apps, too.
Thanks for your reply, Krock.
>Which anti-cheat(s) they are using?
According to this reddit thread https://www.reddit.com/r/HonkaiStarRail/comments/112bnnn/steam_deck_lnx_support_is_unlikely/ they are going to use (possibly modified) mhyprot and some 3rd party anti-cheat tool called AntiCheatExpert.
>Can you get the game to start?
It's in closed beta and I'm not taking part in it sadly, so I don't know. It's going to be publicly available on April 26th and pre-download is to be available on April 23rd or so.
>Like with Honkai, there is no personal interest from my side either to take care of this game
It wouldn't be fair to make you take care of another game, besides I already stated that I'm willing to take care of it myself (or at least I could try, it might be a valuable experience to have, not to mention being able to play the game on Linux).
>However, if it happens that HSR uses the same protections, I could give you the necessary information to get started
That would be great. Do you think there is enough information right now for you to judge it may be similar or not? Or is it better to wait for pre-download to be available before judging anything?
In the meantime, I'll look into TOOLS.md as you said. I already have used Ghidra, but I need to get familiar with other apps, too.
For the record, I'd also like to know the secret recipe. I want to learn, and if I can end up helping, even better.
As for the current state of things, I am sorry to report that Star Rail uses a mix of mhyprot / hoykprot4 (mhyprotrpg.sys) and Tencent's AntiCheatExpert; it is a solution not unlike the one used for Honkai Impact 3rd. Countermeasures to ACE may not be easy to build, but "countering" mhyprot/hoyokprot may be achievable.
As for the game starting: it doesn't. It does nigh exactly the same thing as HI3rd on startup - ballooning the RAM until there's nothing left to consume.
For the record, I'd also like to know the secret recipe. I want to learn, and if I can end up helping, even better.
As for the current state of things, I am sorry to report that Star Rail uses a mix of `mhyprot` / `hoykprot4` (`mhyprotrpg.sys`) and Tencent's AntiCheatExpert; it is a solution not unlike the one used for Honkai Impact 3rd. Countermeasures to ACE may not be easy to build, but "countering" mhyprot/hoyokprot may be achievable.
As for the game starting: it doesn't. It does nigh exactly the same thing as HI3rd on startup - ballooning the RAM until there's nothing left to consume.
@Fed0r Anti-cheat Expert is yet uncharted territory to me, hence the process would only apply partially. Like cybik indicated, overcoming that additional hurdle will take quite some time, especially when you're only getting started. I am not sure whether I could find a solution for that.
However, I first would like to wait for the official release to then figure out what's needed.
I already stated that I'm willing to take care of it myself
I primarily mentioned that because there is no generic recipe that works in all cases; the first (memory leak) issue is an example for that. When the time comes I can give you a general walkthrough but am no help to fix HSR-specific issues.
@Fed0r Anti-cheat Expert is yet uncharted territory to me, hence the process would only apply partially. Like cybik indicated, overcoming that additional hurdle will take quite some time, especially when you're only getting started. I am not sure whether I could find a solution for that.
However, I first would like to wait for the official release to then figure out what's needed.
> I already stated that I'm willing to take care of it myself
I primarily mentioned that because there is no generic recipe that works in all cases; the first (memory leak) issue is an example for that. When the time comes I can give you a general walkthrough but am no help to fix HSR-specific issues.
I know this tracker is more for GI and HI/HSR aren't really covered.
But.
For the record, there is an interesting, recent development: WINE 8 (since at least 8.4) now crashes on HI3rd and HSR (CBT), instead of developing a hard case of memory rampancy. This might help diagnosing a quirk of Windows' RtlAllocateHeap call, but I'm getting ahead of myself.
Backtrace:
=>0 0x0000017002a74f subheap_commit+0x2c(block_size=<internal error>, block=<internal error>, subheap=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:784] in ntdll (0x00000000041e18)
1 0x0000017002a74f find_free_block+0x419(block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:526] in ntdll (0x00000000041e18)
2 0x0000017002a74f heap_allocate_block+0x42f(heap=<register R12 not accessible in this frame>, flags=<register R13 not accessible in this frame>, block_size=<register RDI not accessible in this frame>, size=<register RBP not accessible in this frame>, ret=[<register RSP not accessible in this frame>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1110] in ntdll (0x00000000041e18)
3 0x0000017002e7ab group_allocate+0x6d3(block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1774] in ntdll (0x00000000002200)
4 0x0000017002e7ab heap_acquire_bin_group+0x822(bin=<internal error>, block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1841] in ntdll (0x00000000002200)
5 0x0000017002e7ab find_free_bin_block+0x83d(bin=<internal error>, block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1887] in ntdll (0x00000000002200)
6 0x0000017002e7ab heap_allocate_block_lfh+0x8ba(ret=<internal error>, size=<internal error>, block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1905] in ntdll (0x00000000002200)
7 0x0000017002e7ab RtlAllocateHeap+0x983(handle=<register RDI not accessible in this frame>, flags=<register RSI not accessible in this frame>, size=<register RBX not accessible in this frame>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:2035] in ntdll (0x00000000002200)
8 0x000001802658ac in starrailbase (+0x2658ac) (0x0000000010da40)
9 0x0000018022f81d in starrailbase (+0x22f81d) (0x0000000010da40)
10 0x00000180d7116c in starrailbase (+0xd7116c) (0x0000000010da40)
11 0x000001400a5924 in starrail (+0xa5924) (0000000000000000)
0x0000017002a74f heap_allocate_block+0x42f [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1110] in ntdll: mov 0x10(%r10), %rax
I know this tracker is more for GI and HI/HSR aren't really covered.
But.
For the record, there is an interesting, recent development: WINE 8 (since at least 8.4) now crashes on HI3rd and HSR (CBT), instead of developing a hard case of memory rampancy. This might help diagnosing a quirk of Windows' `RtlAllocateHeap` call, but I'm getting ahead of myself.
Backtrace:
```
=>0 0x0000017002a74f subheap_commit+0x2c(block_size=<internal error>, block=<internal error>, subheap=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:784] in ntdll (0x00000000041e18)
1 0x0000017002a74f find_free_block+0x419(block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:526] in ntdll (0x00000000041e18)
2 0x0000017002a74f heap_allocate_block+0x42f(heap=<register R12 not accessible in this frame>, flags=<register R13 not accessible in this frame>, block_size=<register RDI not accessible in this frame>, size=<register RBP not accessible in this frame>, ret=[<register RSP not accessible in this frame>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1110] in ntdll (0x00000000041e18)
3 0x0000017002e7ab group_allocate+0x6d3(block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1774] in ntdll (0x00000000002200)
4 0x0000017002e7ab heap_acquire_bin_group+0x822(bin=<internal error>, block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1841] in ntdll (0x00000000002200)
5 0x0000017002e7ab find_free_bin_block+0x83d(bin=<internal error>, block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1887] in ntdll (0x00000000002200)
6 0x0000017002e7ab heap_allocate_block_lfh+0x8ba(ret=<internal error>, size=<internal error>, block_size=<internal error>, flags=<internal error>, heap=<internal error>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1905] in ntdll (0x00000000002200)
7 0x0000017002e7ab RtlAllocateHeap+0x983(handle=<register RDI not accessible in this frame>, flags=<register RSI not accessible in this frame>, size=<register RBX not accessible in this frame>) [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:2035] in ntdll (0x00000000002200)
8 0x000001802658ac in starrailbase (+0x2658ac) (0x0000000010da40)
9 0x0000018022f81d in starrailbase (+0x22f81d) (0x0000000010da40)
10 0x00000180d7116c in starrailbase (+0xd7116c) (0x0000000010da40)
11 0x000001400a5924 in starrail (+0xa5924) (0000000000000000)
0x0000017002a74f heap_allocate_block+0x42f [Z:\usr\src\packages\BUILD\dlls\ntdll\heap.c:1110] in ntdll: mov 0x10(%r10), %rax
```
Reach out to me over on the AAGL discord if you want to talk about details further, I don't want to spam Krock's mailbox.
I'll only say that access to the binaries isn't hard. I can't play the game, but I can run it on a Windows install.
Reach out to me over on the AAGL discord if you want to talk about details further, I don't want to spam Krock's mailbox.
I'll only say that access to the binaries isn't hard. I can't *play* the game, but I can *run* it on a Windows install.
3rds memoryhogging issue seems to be reproducible on Windows. Launching BH3.exe with x64dbg+ScyllaHide causes it to invoke operator_new infinitely (without SH the game dies with an "abnormal environment" error). Haven't been able to launch the game normally with a debugger attached due to this exact issue. Also, one of the two kernel drivers created by the game seems to repeatadly sample the list of all running processes/drivers, and cause the game to die immediately with a "hacking tools" message if it finds a "bad" one. x86dbg and procmon are considered "bad", but the list is probably much longer. Doing anything to prevent the kernel modules from loading causes an "abnormal environment" message too.
3rds memoryhogging issue seems to be reproducible on Windows. Launching BH3.exe with x64dbg+ScyllaHide causes it to invoke operator_new infinitely (without SH the game dies with an "abnormal environment" error). Haven't been able to launch the game normally with a debugger attached due to this exact issue. Also, one of the two kernel drivers created by the game seems to repeatadly sample the list of all running processes/drivers, and cause the game to die immediately with a "hacking tools" message if it finds a "bad" one. x86dbg and procmon are considered "bad", but the list is probably much longer. Doing anything to prevent the kernel modules from loading causes an "abnormal environment" message too.
Hello there. I'm lurking this repo for some time now, and I use it to play GI from time to time, but decided to make an account just today, and create this ticket because of a new game that I'll possibly spend much more time on than GI. This game is Honkai Star Rail which is going to be publicly available in a month. Knowing H*yo, it's also going to have anti-cheat system, probably as "easy" to bypass as in GI case. I quote "easy" because with no doubt it wasn't that straightforward to figure it all out so it would work, so all the devs from here have my absolute respect (I'm a programmer myself but I'm not experienced in reverse engineering, one time Notabug was down and there was supposed to be new patch for GI I was trying to figure out how to make such patch myself, but failed miserably).
What I'm interested in is a way to figure out such anti-cheat bypassing patch myself, so I could start similar project for that incoming new game. Knowing how to create a patch for GI isn't exactly the goal, because now, as it's already figured out, it's just a matter of applying certain set of steps on new binaries to prepare a new patch, or at least that's how I see how preparing new patches looks like. So basically I'd be willing to learn how to figure out bypassing anti-cheat in a game such as GI or incoming Honkai (I bet they'll also use Unity for that so it should be at least somehow similar to GI in that matter). There is some technical data available at this repo, sure, but imo not enough to start other similar project for another game. So basically what I'm saying is I'd like to learn from you guys how to even make preparations for reverse engineering a game in such a way that would allow me to figure out how to bypass its anti-cheat, so I could run it on Linux also.
In the unlikely scenario this game turns out to be runnable on Linux out of the box this knowledge is probably not going to be useful to me, but I'm still willing to learn it as it most probably will come handy.
What do you guys think? Could you fill me in somehow? Or at least point me out to some valuable tutorials that could help me start?
Thank you for your interest. I also started with zero reverse engineering knowledge. Over a period of 1.5 months I familiarized myself with the available tools until there was finally a breakthrough.
This repository contains the ingredients but not the recipe to "bake" your own patch. Those who actively follow the project for a longer time might already have an overall idea how it works but I will not disclose any instructions to prevent abuse by cheaters and countermeasures by the game developers.
However, if it happens that HSR uses the same protections, I could give you the necessary information to get started. But depending on the anti-cheat solution they are using (e.g. Anti-cheat Expert) a new approach might be needed in the first place.
I would say a good start is to get familiar with the existing reverse engineering and cheater tools (see TOOLS.md as an example). Interestingly our and the cheater's interests partially overlap, albeit different goals.
Which anti-cheat(s) they are using? Can you get the game to start?
EDIT: Like with Honkai, there is no personal interest from my side either to take care of this game, see #214 as reference.
Thanks for your reply, Krock.
According to this reddit thread https://www.reddit.com/r/HonkaiStarRail/comments/112bnnn/steam_deck_lnx_support_is_unlikely/ they are going to use (possibly modified) mhyprot and some 3rd party anti-cheat tool called AntiCheatExpert.
It's in closed beta and I'm not taking part in it sadly, so I don't know. It's going to be publicly available on April 26th and pre-download is to be available on April 23rd or so.
It wouldn't be fair to make you take care of another game, besides I already stated that I'm willing to take care of it myself (or at least I could try, it might be a valuable experience to have, not to mention being able to play the game on Linux).
That would be great. Do you think there is enough information right now for you to judge it may be similar or not? Or is it better to wait for pre-download to be available before judging anything?
In the meantime, I'll look into TOOLS.md as you said. I already have used Ghidra, but I need to get familiar with other apps, too.
For the record, I'd also like to know the secret recipe. I want to learn, and if I can end up helping, even better.
As for the current state of things, I am sorry to report that Star Rail uses a mix of
mhyprot/hoykprot4(mhyprotrpg.sys) and Tencent's AntiCheatExpert; it is a solution not unlike the one used for Honkai Impact 3rd. Countermeasures to ACE may not be easy to build, but "countering" mhyprot/hoyokprot may be achievable.As for the game starting: it doesn't. It does nigh exactly the same thing as HI3rd on startup - ballooning the RAM until there's nothing left to consume.
@Fed0r Anti-cheat Expert is yet uncharted territory to me, hence the process would only apply partially. Like cybik indicated, overcoming that additional hurdle will take quite some time, especially when you're only getting started. I am not sure whether I could find a solution for that.
However, I first would like to wait for the official release to then figure out what's needed.
I primarily mentioned that because there is no generic recipe that works in all cases; the first (memory leak) issue is an example for that. When the time comes I can give you a general walkthrough but am no help to fix HSR-specific issues.
I understand that, thank you. So for now let's wait for pre-download and then we'll see how it goes from that point.
I know this tracker is more for GI and HI/HSR aren't really covered.
But.
For the record, there is an interesting, recent development: WINE 8 (since at least 8.4) now crashes on HI3rd and HSR (CBT), instead of developing a hard case of memory rampancy. This might help diagnosing a quirk of Windows'
RtlAllocateHeapcall, but I'm getting ahead of myself.Backtrace:
@cybik so you have access to beta and can run the game yourself (on Windows)?
Reach out to me over on the AAGL discord if you want to talk about details further, I don't want to spam Krock's mailbox.
I'll only say that access to the binaries isn't hard. I can't play the game, but I can run it on a Windows install.
3rds memoryhogging issue seems to be reproducible on Windows. Launching BH3.exe with x64dbg+ScyllaHide causes it to invoke operator_new infinitely (without SH the game dies with an "abnormal environment" error). Haven't been able to launch the game normally with a debugger attached due to this exact issue. Also, one of the two kernel drivers created by the game seems to repeatadly sample the list of all running processes/drivers, and cause the game to die immediately with a "hacking tools" message if it finds a "bad" one. x86dbg and procmon are considered "bad", but the list is probably much longer. Doing anything to prevent the kernel modules from loading causes an "abnormal environment" message too.
Experimental patches for HSR and HI3 are now linked in the README.