Remove requirement for Administration Rights on Launcher

[Omega1001]

Since the revival, the launcher requires admin rights in order to run.

This is a major security issue, as it opens the way for malware into the system, along with other issues.

As I'm sure that this decision was made to ease Development in the beginning, it is probably high time to remove that requirement.

[anonyme0273]

32 minutes ago, Omega1001 said:

Since the revival, the launcher requires admin rights in order to run.

This is a major security issue, as it opens the way for malware into the system, along with other issues.

As I'm sure that this decision was made to ease Development in the beginning, it is probably high time to remove that requirement.

Had the same issue, but you can easily scan the file for viruses (so far there ain't none). It's a trust thing, as far as I know the privilege is required to read and write .pak files
If you are still concerned, you can also ask a tech savy acquaintance to decompile the code (not a problem with free software like dotPeek) and have a look at what exactly is going on - you also get the images in the launcher as a bonus for your efforts. I've done that and can assure you that as of a few months back it really was not harmful.

Don't think the requirement will change, but maybe I don't know fully what it is for in the first place, so perhaps it's possible.

Edited August 13, 2021 by anonyme0273

[Dallarian]

38 minutes ago, anonyme0273 said:

Had the same issue, but you can easily scan the file for viruses (so far there ain't none). It's a trust thing, as far as I know the privilege is required to read and write .pak files
If you are still concerned, you can also ask a tech savy acquaintance to decompile the code (not a problem with free software like dotPeek) and have a look at what exactly is going on - you also get the images in the launcher as a bonus for your efforts. I've done that and can assure you that as of a few months back it really was not harmful.

Don't think the requirement will change, but maybe I don't know fully what it is for in the first place, so perhaps it's possible.

Weren't antiviruses pinging launcher file, though?

I believe I had to whitelist it for my AVG.

[Omega1001]

 

26 minutes ago, anonyme0273 said:

If you are still concerned, you can also ask a tech savy acquaintance to decompile the code

Shure, that way I can enshure that there are no bad stuff in there NOW, but you'd basically would have to do that every time an update comes in anew,

As I'm a Tech, i know for a fact, that there a no restrictions to read/Write FIles on Types.
Actually, the extension is only an indicator what this may be, but you don't actually know.
For instance a .jar file is actually a .zip file with different extension so the OP treats it different, but the content reamains the same.

Admin Rights may be required to Write (probably not Read) Files if these are stored somewhere in a System dir (like C:/Progam Files)
But you can fix that by using admin rights once to set these Access Right properly, and never need them again.

There are countless Programs for Windows out there that do similar things as the launcher, and they only need admin right at setup, or request them if they make an Update.
If they can do it, why shoudn't Skylords too?

38 minutes ago, anonyme0273 said:

It's a trust thing

 

That is putting it a little to simple.
You don't just trust the Skylords Team to not put bad stuff in there, you must also trust that there are no weakpoints that an Attacker could attach to without altering the code.
Processes that run under admin rights are always a Risk even if they come from Microsoft themselves.
The preferred way to deal with that is to run as few Processes as possible under admin rights.

In the end, it remains a massive Security Issue that is indeed avoidable.
And it should be too.

 

[anonyme0273]

Oh I agree, I'm very worried about every install and  admin right I grant, but from personal experience with some SR staff, I know that only the absolute best care is taken with every bit of published code and asset. The core is completely solid, so until I see an issue that would make me question the security of what I'm running here, I'm fine.

1 hour ago, Omega1001 said:

As I'm a Tech

Then you can check the code for vulnerabilities yourself. It's quite straightforward and to me (a noob of cybersecurity, full disclosure) seems fine. As the project grows, perhaps it would be a good idea to maybe sign and publish the updater signature on the website so any spoofed versions would be easier to notice at download... but that's a different topic.

If I were you, I'd honestly be more concerned about things not so easily checked, like the BattleForge.exe itself - after all, that's where you are actually sending and receiving any data packets at all with an 'unknown' server.

[Omega1001]

If it's really just "Need Read/Write access to files inside Gamedir", then it would suffice to do the C# equivalent of Unix Shell command "chmod -R u+rw <path/to/gamedir>" once.
The updater could do that after every update, so the User doesn't need to do anything.

People that installed the game in a non System dir, like on a different drive, don't even need to do anything.

At least, Admin Rights schuld not be a hard dependency like now, so that people can switch it off if they don't need it or switch it on if it is actually necessary.

50 minutes ago, anonyme0273 said:

If I were you, I'd honestly be more concerned about things not so easily checked, like the BattleForge.exe itself - after all, that's where you are actually sending and receiving any data packets at all with an 'unknown' server

That is part of the Problem: Because the launcher has admin rights, that unknown Server can copy and or download whatever it wants from anywhere in the System.
Without admin right, it can only do damage to files of the User, but the System stays off limits.
 

55 minutes ago, anonyme0273 said:

but from personal experience with some SR staff, I know that only the absolute best care is taken with every bit of published code and asset

SR staff can only vouch for there code, and as we are all humans that make errors, not even that is completely foolproof, no matter how skilled the staff is.
They know little to nothing about the underlaying libraries, that could be vulnerable just as much.
C# core libraries itself are not safe, because statistically they couldn't possibly be (because nobody is perfect).
Nobody can guaranty security, be we can make sure, that it's not that easy to use these weakpoints.

[Aviat0r]

I'm glad that you think about security aspects in our software. And you're indeed right with what you say. Admin privileges are actually a "No Go" for today's software.

The Updater itself doesn't need any administrative privileges in the system. The fact that it still forces the user to start it like that is a problem from the past where we were still in the development process of how the packets were sent to our server instead of the EA ones. Fun fact ... even the EA BattleForge Bootstrapper required admin rights. 🙂 

In the past, our little piece of extremely important software (let us call it Injector for now) was started along with the BattleForge executable and injected itself into the BattleForge process. The injector itself was invisible for the user and ran as a background process. The injection however was only possible with admin privileges since you have to call a method where you need those privileges. Otherwise the method call would fail. We decided to transfer those permissions over to the Updater since all processes called by it will also start with the same privileges (also called AsInvoker in manifest files). The reason for that was, that the user doesn't get a system popup for a software he can't see (the Injector) and maybe denies the execution of it. If he would, the game wouldn't start and connect to our servers at all. That's for the history of the injector.

Unfortunately at some point there were some pieces of information which got stored afterwards at some places on the user's PC which can only be accessed with write permissions when the software will be started with administrative privileges. This wasn't the intention in the beginning. And the information isn't stored by the Updater, but by the game. That information will need to be stored somewhere else before we can remove the admin rights request for the Updater. But we're of course in the process of doing so. I actually expect an update for the current Updater in the upcoming days/weeks to remove that whole thing.
Side note: I was always against an Updater which needs that high level of privileges. Some users (and I count myself to that group of users) don't like software, which require these permissions, at all. And maybe that's also a reason for them to not use that software.

When we remove those permissions, we need to make sure, that the Updater and the game can access all files with all needed permissions. That's also the reason why our installer doesn't accept directories as installation location which are protected by Windows. Those locations are however hardcoded.

I hope you can live with the fact that it requires those permissions for another few days or weeks. They will for sure be removed in the near future.

Sneak preview: The new Updater won't have that requirement at all.

[Xamos]

Oh that sounds good, I have been annoyed by that ever since too.

[Aviat0r]

You're lucky. I just rolled out a newer version of the still "old" Updater. No more admin privileges are needed with this one. 🥳

However if you installed the game into a directory which is write protected by Windows (e.g. Program Files), you still have to manually execute is as administrator.