Truly portable / use custom modding framework jar

[ffafe5]

Fabric offers this downloads page:

https://fabricmc.net/use/installer/

On it, it includes a link to a "universal jar":

https://maven.fabricmc.net/net/fabricmc/fabric-installer/1.1.1/fabric-installer-1.1.1.jar

My assumption is that when you give portablemc args asking to install a minecraft instance using a version of the fabric framework, portablemc does the following:

• downloads the "universal jar" and then performs.... some kind of mysterious process to:
• download the game files from microsoft, requiring OAuth authentication for portablemc to do so
• modifies the microsoft game files using the "universal jar" and registers this with the .minecraft metadata
• voila, there now exists a launchable modded version of minecraft (which portablemc can also invoke to launch the game)

My goal:

• I want to package a "future proof" version of singleplayer minecraft so much as is possible, relying on as few web services as possible. This rules out mod managers eg modrinth. I want to come back in 20 years and say "yeah let's boot up that highly customized instance of MC on this new computer" and it Just Work (tm).
• I've already created my own minecraft installer executable for private use, which packages portablemc and invokes the fabric version and whatnot and takes a pile of offline mod and config files and automatically merges them into the game directory. All of this is bundled into an exe file.

Issues / things that could enhance the portability:

• Low priority: can the java executables required to run the game and any portablemc dependencies be provided by the user over command line, from a packaged portable instance? This would eliminate the web dependency on acquiring what will eventually be considered ancient java versions.

• Medium priority: can the game files be provided in some legal way by the command line user of portablemc, such that the install can be completed first and then only have to authenticate with microsoft when first launching the installed instance? This would eliminate the web dependency on portablemc's OAuth details that you have registered with Microsoft. I understand the necessity to authenticate with Microsoft -- the goal is not to "crack" the game, but rather to not have it route through a PortableMC web page.

• High priority: can the fabric loader "universal jar" be provided by the portablemc user over command line? This would eliminate the web dependency on the Fabric website.

I'm open to suggestions for entirely alternative solutions for my goal. Maybe I'm overcomplicating this.

[Ristovski]

1. Please check the documentation:

      --jvm <PATH>
          The path to the JVM executable, 'java' (or 'javaw.exe' on Windows).
          
          This is used to launch the game, it has a special use-case with Forge and NeoForge
          loader versions where that JVM executable is also used to run the installer
          processors.
          
          Note that when this argument is specified, you cannot specify the '--jvm-policy'
          argument.

2. Once again:

      --mc-dir <PATH>
          Set the directory where the game is run from, the game will use this directory to put options,
          saves, screenshots and access texture or resource packs and any other user related stuff.
          
          When unspecified, this argument is equal to the '--main-dir' path.
          
          This argument might not always be used by a command, you can specify it through environment
          variables if more practical.
          
          [env: PMC_MC_DIR=]

With these two options, you are able to point portablemc to your own java and minecraft installation directories.

As for your last point, I don't think this is possible right now.

[ffafe5]

Point two, that's not really an answer to the issue, as my grievance is with the PortableMC OAuth instance. Point three is the main one I'd like to explore. Are the assumptions I wrote in the main post preamble correct? If so it sounds trivial to allow a custom jar

[mindstorm38]

Hello! The launcher is actually not using the universal installer Jar for installation, it is currently using the metadata file provided by some API endpoint, this metadata file is specifying what the launcher needs to download, like a regular version. And I don't think it will be much of a help to use the installer Jar since it does not embed any library, it is, much like portablemc, downloading the files via their API.

Regarding portability of a Minecraft instance, I could think that you should be able to embed in a single zip file, all of the .minecraft you installed, you also embed the JVM you wish to use, and portablemc executable. Then you can just make a wrapper bash/cmd script which launch the game accordingly. In my opinion it should be "portable" as you intend?

[ffafe5]

Thank you for your response. I've come to understand a lot of my misconceptions. I struggled for a bit trying to streamline my experience to avoid having to open the official minecraft launcher, because portablemc was not downloading the game files as I was requesting it to and it seemed to rely in some way on old .minecraft directory content, eg the assets directory.

I realized that you offer a "main-dir" arg, not just the "work-dir" arg, and pointing both to the same place provides a truly portable and independent minecraft install directory that can be moved about. That's great! I could package that up and run it in offline mode forever with a portable jvm.

I still don't love that the fabric framework cannot be provided by the client user, but given that this only needs to be run once at a time when those web resources are available, that's not so bad.

[ffafe5]

One more thing though: I noticed that the interface allows downloading the game files from the web (when work-dir == main-dir as a custom directory, a fresh/empty directory)... and also noticed that this works even in offline mode when not specifying the login argument.

This is basically, when used the "right" way, a cracked game installer. My portable install generator that wraps this is basically manufacturing a modded cracked game installer exe if I omit the login arg. I'm not pointing fingers, but I have to ask, how is it that this code is able to download all of the minecraft game jar files without having a user's OAuth login session token stuff set up? I assume you get it off of a mojang/microsoft server but I would think that those places would enforce a login session.

Put another way, I don't want them to come after me if they read that my IP is downloading the game off their server in some exploitative fashion.

[mindstorm38]

I realized that you offer a "main-dir" arg, not just the "work-dir" arg, and pointing both to the same place provides a truly portable and independent minecraft install directory that can be moved about. That's great! I could package that up and run it in offline mode forever with a portable jvm.

Yes exactly, it's how I would do it!

I still don't love that the fabric framework cannot be provided by the client user, but given that this only needs to be run once at a time when those web resources are available, that's not so bad.

Sadly it's really complicated and impossible to install a new version from scratch, without internet access. In fact, it would be possible if you were able to provide every library needed by a given version, but that what you are doing essentially by running portablemc ahead of time. Once installed, a game version no longer need internet access to be run.

One more thing though: I noticed that the interface allows downloading the game files from the web (when work-dir == main-dir as a custom directory, a fresh/empty directory)... and also noticed that this works even in offline mode when not specifying the login argument.

This is basically, when used the "right" way, a cracked game installer. My portable install generator that wraps this is basically manufacturing a modded cracked game installer exe if I omit the login arg. I'm not pointing fingers, but I have to ask, how is it that this code is able to download all of the minecraft game jar files without having a user's OAuth login session token stuff set up? I assume you get it off of a mojang/microsoft server but I would think that those places would enforce a login session.

In fact, I'm able to download all game assets without any sort of credentials, everything is public. First, the java libraries are inherently public because they can be found publicly on Maven central, on the other side the game Jar, its assets, and possibly the JVM, are Mojang assets that are also publicly available.

Put another way, I don't want them to come after me if they read that my IP is downloading the game off their server in some exploitative fashion.

The official launcher is doing exactly the same thing as portablemc, except for the user-agent in the HTTP requests which is specifying portablemc as the origin, so yes they could throttle you as they own the servers and know your IP, but I never observed any kind of significant and durable throttling on the numerous downloads I've done.

[ffafe5]

Thanks again for all the elaboration. I figure, to be most proper, I should perform the initial install with authentication. I was considering whether or not the login session is desirable during the subsequent game launches. I could query for internet access in my wrapper program that generates a one click launcher exe, and use that with error handling to then fall back upon the offline method of launching portablemc.

However, when launching online mode with no internet connection for a test, I noticed that it still relies upon the PortableMC microsoft OAuth application web entity. This is a risk to the long-term portability of the launcher.

Putting aside the OAuth app being an evil that you have no choice but to put up with and maintain for this to work, I wonder, can we remove the dependency upon your personal web domain (which I see in the Issues here has expired before and thus caused problems)? For example, can we not have the OAuth redirection point at a local html page that performs the local port signal back to the portablemc launcher application?

[mindstorm38]

Ah right, this should no longer be the case in the latest version 5 of the launcher. I already figured out in the last that it was very risky, so the launcher is now using another auth workflow (originally made for console platforms).

That said, do not rely on Mojang nor Microsoft for stability of the auth workflow.

[ffafe5]

I spent the day polishing up my stuff so that my generated game launcher exe automatically falls back to offline mode if there's issues with the internet or portableMC auth.

I'm interested in trying out the new v5 of portableMC, but I can't find any information about the changes made to the command line?

I'm guessing that work-dir moved under the start command as what is now mc-dir; that part is easy.

But what about the authentication? There's no --login anymore. I'm supposing that this option migrated from a start option to being a full command mutually exclusive with the start command. The description of this project however says "Install and launch a version in 1 command.", which is now no longer possible if the auth is managed in a separate command.

[ffafe5]

Furthermore, just experimenting with the new login such as it is, it seems it requires more invasive access to the Microsoft account? Previously it functioned through your PortableMC OAuth app and the login screen displayed clear notice of what permissions it was being granted. The Microsoft account even had a section just for this app so that its permissions list could be revoked at any time. The new screen, where a code is requested to be entered, just says:

"Once you enter the code displayed on your app or device, it will have access to your account.
Do not enter codes from sources you don't trust."

This seems unreasonably broad

[Ristovski]

Pretty sure the permissions are a limitation on Microsofts side and there is nothing that can be done to make the access scope narrower.

As for offline mode, you simply don't pass -a/--auth to the start command, and given you provide -u/--username or -i/--uuid it will use those instead of authenticating.

[ffafe5]

How about the URL method of authentication with the port signal (which is better for automation cases where the command line isn't being used), from before v5, but allow custom OAuth apps so it isn't relying on specifically "https://www.theorozier.fr/portablemc/auth" ?

There's not "nothing that can be done" -- that's still a working method at this moment. Granting full access to your whole Microsoft account for a game downloader is unreasonable.

[Ristovski]

You should check out https://minecraft.wiki/w/Microsoft_authentication

portablemc/portablemc/src/msa.rs

Lines 67 to 74 in 290fcbe

	// We request the 'XboxLive.signin' and 'offline_access' scopes that are
	// mandatory for the Minecraft authentication.
	// We could also request email with "openid email" scopes.
	let req = MsDeviceAuthRequest {
	client_id: &self.app_id,
	scope: "XboxLive.signin offline_access",
	mkt: self.language_code.as_deref(),
	};

[mindstorm38]

I'm interested in trying out the new v5 of portableMC, but I can't find any information about the changes made to the command line?

It's true that I didn't took time to make a real documentation about the major changes, note however that the manpage/help message is now way way way clearer than before, imo.

I'm guessing that work-dir moved under the start command as what is now mc-dir; that part is easy.

Yep!

But what about the authentication? There's no --login anymore. I'm supposing that this option migrated from a start option to being a full command mutually exclusive with the start command. The description of this project however says "Install and launch a version in 1 command.", which is now no longer possible if the auth is managed in a separate command.

Yes, with the new version it is no longer possible to authenticate in just one line, and it was kind-of arbitral decision because in v4 you had to specify the account to login with email address, which I no longer know (because I restricted the scopes, btw! regarding your post below, v5 is more restricted than before in v4).

This seems unreasonably broad

Regarding all of this, I don't know why Microsoft is not showing the scopes I'm requesting, but the scopes requested are the ones @Ristovski shared in this post, namely "XboxLive.signin" and "offline_access", which are the two scopes required to authenticate with Mojang. The Azure App being used for PortableMC behind the hood is the same since the beginning also.

PS: I think you should be able to see the scopes in the URL query string, not user friendly but with this you could ensure that the launcher is properly behaving.

[ffafe5]

Unfortunately I cannot find any documentation online about what level of access XboxLive.signin entails.

What URL query string, though? In v5 there is no longer an automated browser popup. It's only displaying the text:

• "To sign in, use a web browser to open the page https://www.microsoft.com/link and enter the code ###### to authenticate."

It's this webpage that contains the scary unscoped access warning.

Note this is without the "--no-browser" argument. Perhaps the default behavior (to use a browser) is unexpectedly broken?