majsoul-plus
majsoul-plus copied to clipboard
MajsoulPlus
Customizable useragent (workaround for #127)
PR is inteded to provide customizable useragent, in face of potential banwave of MJS+ users per #127
As well as vanilla mode, disabling all DOM changes within a webview.
For those unwilling to wait until this gets merged, temporary builds: https://public.eientei.org/mjsp/Majsoul_Plus-2.0.1-windows-x64-Setup.exe https://public.eientei.org/mjsp/Majsoul_Plus-2.0.1-windows-x64.zip https://public.eientei.org/mjsp/Majsoul_Plus-2.0.1-linux-x64.tar.gz
Added vanilla mode, builds are also updated. Maybe someone could help with chineese/korean translations.
@Yesterday17 thanks for the translations @Shaddox builds are updated to contain last translation change and windows zip build is also added to original comment at https://github.com/MajsoulPlus/majsoul-plus/pull/128#issuecomment-873089143
Rebased with upstream, removed excessive user-agent specifications, corrected i18n.
Additionally, removed start and use whatsoever of local server, when using vanilla mode, by which MJS+ vanilla should not differ from regular browser dedicated to majsoul now (which is exactly reasoning behind vanilla mode itself).
Security considerations for non-vanilla mode:
- electron-fetch is still susceptible to adding sec-fetch-* headers, by which modified MJS+ client may be identified, I don't see easy way to remove such, but maybe another http request library may provide better option.
- even if network layer will get to the level of transparent reverse proxy, being indistinguishable from regular client, this would not be measure enough to avoid detection, as at any time majsoul may return to portion of it's clients JS that would take snapshot of canvas bitmap and send it to their servers for subsequent review, as well as inspect DOM for any alterations -- and considering yostar hammering on users of purely browser mods, this is already their way of detection, while useragent and other headers probably playing little to no role in this.
To implement truly undetectable majsoul client with mods, customizing electron's V8 to have untracable (e.g. requiring secret password/key to change or inspect) object properties, wrapping entirety of DOM/canvas API, as well as having mods to work as overlay to webContents instead of working inside of it, may be required.
This is quite a big undertaking (compiling customized electron alone may be quite a challenge, requiring 50G of space to build and maybe several days for build to complete), not to say all the mods have to be reworked with overlay approach in mind.
--->3--- P.S, offtopic Amusingly enough, with overlay approach -- that has zero chance of being detected by any means when implemented correctly -- it is much easier to make cheats (e.g. hand analyzer), than purely visual changes, such as replacing every character with one from akagi, so yostar hammering on mod users could not be under pretense of weeding out cheaters, but plainly trying to force everyone to use their exploitative gacha mechanics, when it comes to visual niceties many crave for.
Probably yostar should consider providing user-side, local-only resource packs as official feature, to actually deter their users from cheating, while also not hurting their gacha business, as long as such packs would remain local-only. Instead of hammering mod users, they should fully embrace mods, probably providing ways to make them non-local via same gacha (or hopefully more reasonable monetization model). --->3---
hmm, I think we should validate how Yostar 'detects' modified clients first.
I used this tool to split majsoul code to smaller chunks and do some deobfuscations. It may work on EN server.
Most likely their detection is not present in regular JS versions being returned to most users most of the time, but rather being triggered to return to a percentage of the users whenever they feel like they want new banwave -- they could return to say 5,10,30,whatever percentage of version requests some new version, or simply return different contents for same version.
It is very easy to implement, so analyzing their day-to-day code would likely yield nothing, catching banwave-altered code is tricky, would require big network of involved clients and/or telemetry and even if we'd manage to catch such code and counter it's current implementation directly - they easily can alter it in a way that our current counter does not expect. We of course could try catching it again, but always end up lagging behind, having some of the users banned.
Even if we institute known registry of verified versions with their hashes, they can begin to consider not using new/altered or even personalized version as a bannable offense in itself.
So we will never be able to reliably counter unknown code in any other way than executing it in contained and pristine environment, while having everything else (mods) as overlay or modified copy to it, that is being presented to a user outside of their code reach.
That being said, vanilla mode of this PR while doing nothing for mod users, should already enable with unaltered pristine environment (which translates to "entirely without mods" right now) those MJS+ users that simply do not want to use their main browser for majsoul (e.g. for segregation and/or streaming purposes) to be out of harms way by emulating useragent of their preferred browser inside of MJS+ which is just a regular standalone chromium build otherwise.
Apparently I forgot to clarify that retaining useragent override in src/bin/main/mainLoader.ts#157 is required, as otherwise game's webview in mainWindowBox would inherit "MajsoulPlus" useragent.
Rebased with latest master; also made local builds using #151 changes, seems to resolve sound effects overlap.
https://public.eientei.org/mjsp/Majsoul_Plus-2.0.1-ua-1-windows-x64-Setup.exe https://public.eientei.org/mjsp/Majsoul_Plus-2.0.1-ua-1-windows-x64.zip https://public.eientei.org/mjsp/Majsoul_Plus-2.0.1-ua-1-linux-x64.tar.gz