Add support for Game Pass versions

[isanae]

This issue is for tracking the progress of Game Pass versions of Bethesda games.

Game Pass games are not currently supported by Mod Organizer because the game binaries ship with DRM that breaks the virtual filesystem and the location of various files have changed on the drive.

For now, there are no short term plans to add support for these games.

Some technical info here and here.

[barcharcraz]

fwiw hooking should still work if you take ownership of the game's install folder (by default there are only ACLs for NT AUTHORITY\SYSTEM and the game's appcontainer SID), as far as I can tell there's no additional DRM on the game itself aside from these permissions changes, it looks like the executable isn't even packed like it is with steam-drm.

[LostDragonist]

IIRC the primary issue is that LoadLibrary is not used / not present in the game executable therefore USVFS (and other things like SKSE) are not loaded. Until someone figures out how to get SKSE working on Microsoft store versions, I don't have high hopes for USVFS working.

Though if you know something we don't, feel free to make a pull request. /shrug.

[AnyOldName3]

I think ianpatt actually has a solution for SKSE, but didn't pursue it fully because no one was going to bother supporting a whole extra binary pre-AE. Now that's a thing, though, it might well be possible for DLL mods to support both via AddressLibrary, so I wouldn't be completely shocked if a store-friendly SKSE build materialises eventually.

[barcharcraz]

SKSE doesn't really need LoadLibrary to be present to inject itself anyway, and also, LoadLibrary is present, there's no way skyrim was rebuilt as a pure UWP app, it's using the store/appcontainer-isolations support for "normal" windows apps.

There may be a little bit of dll redirection going on, but that shouldn't be a problem for the more modern ways that the skse loader can inject skse into a process. I was able to attach a debugger if I remember correctly so worst comes to worst skse can inject itself in the same way.

I think the misconception that SKSE somehow can't work with the store version came from the skse folks not really understanding that "store" does not imply "UWP", and the fact that they don't have a huge amount of time to work on SKSE, so didn't want to support another version of the game when the steam (and other) versions were working fine. The store release was a new build of the game (although, unlike AE they didn't appear to upgrade their compiler), so the SKSE folks would have to find some offsets again.

ADDITIONALLY I don't think AddressLibrary is terribly good idea, certainly it's not needed for what SKSE does (and definately not for what usvfs does) and it relies on heuristics and methods of patching inlined functions that can be a bit flaky. (this is why people were so upset with AE, but like, you can't expect bethesda to maintain that level of compatibility, it would require them to never make any changes to their code and also never upgrade their compiler, they could release debug info I suppose).

Anyway usvfs shouldn't really need anything like AddressLibrary, since it's patching functions that are actually exported from system DLLs. At most it would have to hotpatch (instead of just getting itself loaded instead of the system libs and shimming other functions), since the crt and kernel32 both export a ton of functions it probably hotpatches anyway, but I haven't studied usvfs that extensively. I think the skse loader already has a method of creating the skyrim process suspended and then Read/Writing process memory and making a thread to load some arbitrary dll, but there may be ordering issues with the crt and kernel32 that make that harder for usvfs.

And yeah, I can absolutely understand the SKSE folks not wanting to support yet another game build for little real gain.

afaict the filesystem virtualization that the store version is using for redirection of it's install folder and such is all provided through the bindflt minifilter driver, so that's all in kernel mode. I don't think bindflt is configured to be very restrictive for skyrim, but if it is you might have to spend some time figuring out how to either launch the store version of skyrim "outside" the appcontainer (I recall being able to just launch it normally after messing with the ACLs), or change the bindflt configuration to allow extra paths (once you figure out how to do this you almost might as well not bother with usvfs at all and just tell bindflt to remap the mod paths).

[AnyOldName3]

The SKSE team knew exactly what was and wasn't possible with the initial Store release. The limitation was mainly that there was no straightforward way of hooking an isolated app that was simple enough to deploy to mod users and didn't involve creating security holes, and the same applies whether it's system libraries or the game executable itself being hooked.

Given that it was compiled with a different MSVC version, so a large chunk of the reverse engineering work (e.g. deducing which instruction sequences mapped to which functions, rather than just where the instruction sequences moved to) would need doing again, more-or-less from scratch specifically for the store version, and not enough of the RE people cared enough to actually do that work, it wasn't worth pursuing a solution to the hooking situation from SKSE's perspective. It wasn't worth pursuing from MO2's perspective, either, as none of us have much time at all, so we're waiting for someone else's work to materialise which we can adapt.

Now AE exists, the Steam and Store versions should be converging on a roughly-equivalent executable, and the RE interest is there, DLL mods will get ported to and made for Steam AE, and should work with Store AE with minimal extra effort (as Address Library can cover most of the difference) once SKSE supports it properly. That means it's more worthwhile to make SKSE support it properly.

As for what Address Library does, it was mostly devised to cope with a series of updates which made no difference to the binary except for inserting an array of Creation Club mod names into the middle, which meant some offsets were changed, and some weren't, but the sequences of instructions were identical. That's absolutely something an automated tool can deal with, and extra addresses can be added by hand once they're manually verified (and potentially be suggested in the first place by a fuzzy version of the tool so RE developers know where to look). It doesn't work well when moving from LE to AE as a different version of the compiler was used (also different to the version used by the original Store release), which emits different instructions for the same source code and inlines things differently. This means there are very few exact matches and most approximate matches still need different changes injecting if a mod uses them, so there're separate versions of Address Library for LE and AE to prevent developers making mistakes with false matches. The tool still does its job of safely identifying which bits are equivalent between different versions, it's just not a silver bullet when things aren't equivalent as it can only do the part of the work that's automatable and a subset of things someone else has done by hand.

[barcharcraz]

The SKSE team knew exactly what was and wasn't possible with the initial Store release. The limitation was mainly that there was no straightforward way of hooking an isolated app that was simple enough to deploy to mod users and didn't involve creating security holes, and the same applies whether it's system libraries or the game executable itself being hooked.

Yeah this is the impression I got, having users elevate to NT AUTHORITY\SYSTEM and change ACLs, combined with the need to re-acl stuff upon updates alone makes things very annoying form a support perspective, I don't blame them at all. I do wish they were more open about the technical realities, but given the size of the modding "community" and the penchant for reddit-instigated swarms of unhappy users I understand them keeping communications to a minimum.

The only difference between hooking game functions and hooking actual library functions is that for library functions you don't really need to hotpatch, you can just provide a shim library that exports the same functions as the system library (except for those you want to hook). This is mostly just more annoying than hotpatching (using trampolines and/or hotpatch regions at the beginning of functions) though.

In general usvfs and MO in general shouldn't need SKSE to function right? And usvfs itself doesn't even depend on any of the RE work since it patches library IO functions that are imported from DLLs and thus have their addresses available without any RE work. Am I missing something that usvfs needs?

[Silarn]

I know this issue is pretty old at this point but I'd be more than willing to just try to make a build for a MS version and just see if it will work. But the problem is I don't own one. And I know the directory mappings need to be adjusted.

But I already added 'variant' functionality to the game plugins so we could support the GOG / Epic Store SSE versions. So we'd just need to add the relevant variant changes for Windows Store.

If at some point I was able to get a copy of something that I could test I would be more than happy to make an attempt.

If USVFS is able to hook and work without significant changes then I see no reason not to.

[anthenorjr]

@Silarn Could u try to do it with a gamepass 15 days free trial? I could send you a link if so, I think anyone in gamepass can.

[Kobi-Blade]

I know this issue is pretty old at this point but I'd be more than willing to just try to make a build for a MS version and just see if it will work. But the problem is I don't own one. And I know the directory mappings need to be adjusted.

But I already added 'variant' functionality to the game plugins so we could support the GOG / Epic Store SSE versions. So we'd just need to add the relevant variant changes for Windows Store.

If at some point I was able to get a copy of something that I could test I would be more than happy to make an attempt.

If USVFS is able to hook and work without significant changes then I see no reason not to.

Any restrictions in place are made by the Mod Organizer team and not Microsoft, even Vortex been supporting mods on the Microsoft Store since 2021.

I only managed to test with Starfield so far, and I had full access to the files without any tampering or custom settings, plus contrary to the script extender team claims, we can totally hook into the Starfield executable, they simply don't wanna support it.

So it would be extremely easy for you to add support for it.

[AnyOldName3]

Having write access to the files doesn't guarantee you can hook things, e.g. if there are extra layers of security like marking the pages as read-only and blocking the process from calling the function that makes them writable. IIRC, the script extender people didn't think it was impossible, but was an unreasonable amount of work considering that they're a hobby project and only doing things because they find them interesting. If someone else wanted to volunteer to do it, and was competent enough to succeed, there isn't any reason to think that their changes wouldn't be incorporated.

[Al12rs]

If anybody wants to try contributing support for it, it would be very welcome. MO2 development depends on the free time of the developers contributing to it, which is hard to find these days.

[Kobi-Blade]

Having write access to the files doesn't guarantee you can hook things, e.g. if there are extra layers of security like marking the pages as read-only and blocking the process from calling the function that makes them writable. IIRC, the script extender people didn't think it was impossible, but was an unreasonable amount of work considering that they're a hobby project and only doing things because they find them interesting. If someone else wanted to volunteer to do it, and was competent enough to succeed, there isn't any reason to think that their changes wouldn't be incorporated.

I was pretty clear when I said I had full access, not only write access, would take as much effort to have script extender to work on Game Pass, as it did on GoG (they were reluctant to release GoG version as well).

I just don't like the lies being spread to justify not releasing it on Game Pass, I wish everyone was more honest and just say they don't have the time.

Plus you all jump to easily to the wagon of "anyone is free to jump in and do it" like it's easy, just cause we know how to code, doesn't mean we know how your code works out the bat.

If anybody wants to try contributing support for it, it would be very welcome. MO2 development depends on the free time of the developers contributing to it, which is hard to find these days.

Of course, I don't mean to be rude but Silarn already done it for Epic and GoG, so he knows where to go and how to do it already, don't expect me to delve on a code base I never touched just to figure out how it's working and how to do it.

Not to mention I have my fill with coding at work, I'm just saying is quite easy to do, especially for someone who already did it with other clients on the same code base.

I just making it clear all the fanfare about Bethesda games on Game Pass is pure lies, as Microsoft didn't put any restrictions in place for those games, wanna talk real restrictions look no further than Minecraft Bedrock (and we still were able to get past them in the end).

[AnyOldName3]

What's more likely, that the people who've looked into this and done it for other variants of the games, so know exactly what's involved, and all the gotchas a layperson might not even think to check, have decided to start a conspiracy about it being too much hassle for some reason, and you're the one person who's uncovered the truth, or that, as someone who's not worked on the script extender or anything else that hooks one of the BGS games, there might be something you don't know about that you've not checked?

Either way, no one's said it's impossible or that it'll never be done, just that it's too much hassle. We're having this discussion on an open feature request made by one of the developers of this project. You're not going to get a clearer sign that people think it would be a good idea and is actually possible. It's not done because, as a hobby project, things only get done because they'd be fun to do, the fact that they're not done is annoying, or someone thought they'd it'd be satisfying to finish them. If a task is mostly a load of tedious hoop-jumping with an uninteresting end goal, it's going to end up a lower priority for people to spend their free time on than things like playing a video game, going on a walk, or working on a more interesting feature, no matter how much time they've got. No one's getting paid, so no one has any duty to do anything that isn't fun.

If you do want someone to be duty-bound, you'll be able to find current or former MO2 devs who are available for contract work, and offer reasonable rates for open-source stuff.