UAC and all that

Ok, I've managed to get everything working and all is good, except for one little thing . . .

I've been told to implement a product key algorithm. So I did. Works great. Unhackable. Okay, so maybe "unhackable" only applies versus drunk monkeys and script kiddies, but it gives us some measure of protection. There's only one little thing.

Permissions. In the windows version, you type in the product key, and it fails. Period. Looking at the log, I find out that I don't have permission to write to the registry.

On the Mac side, as you all no doubt know, there's no registry, so I put it where Apple recommends: /Library/Application Support/YourAppName. Except if the user isn't running as an admin (which they shouldn't, even on the Mac), it fails, with insufficient privileges.

I've done a bunch of research on Google, searched the Unity forums, searched MSDN, searched Apple's documentation, and so forth (though it wouldn't surprise me if I missed something). I've found a way you can start a NEW process with elevated privileges, but this isn't a new process.

So here's the question: How can I force the OS to request an elevation of privileges long enough to write the product key? You know, throw up one of those annoying "Run As" windows for the user to type in an admin's username and password. Separate solutions for Windows and Mac is fine, because my code already has conditionals based on the platform. Oh, and I already looked at PlayerPrefs, which also writes to the registry, which we don't have permission to do yet.

Any recommendations? Thanks!

 

Ok, so I've talked to a guy I know from Microsoft who does a lot on the development side, so I'll pass on what he's told me, in case anyone else needs to know.

Apparently, there is no possible way to elevate privileges, UAC or otherwise, without starting a new process. This also seems to be by design (a very unattractive design, if you ask me). So I guess I'm going to have to bite the bullet and write a little external program that writes the key to the registry.

On the Mac side, I still don't have anything to work with, other than 1) asking the user to do the first run as an admin, or 2) install the key into the user's library folder instead of the system library folder.

Drawback for the first option: it's tacky.

Drawback for the second option: every time a different user of that computer runs the program for the first time, they will have to retype the product key, which is also tacky.

Any thoughts? How do you all do the product key thing? Besides letting the App store do it, I mean. I'd do that if I had the option, but I don't. I got overruled.

 

Well i dont know how it would work out but why not try store the keys in a encrypted file inside data folder
+Use as a password for encryption alghoritm the user HWID witch will make sure user dosent just Copy your game and send it by email......
cause of HWID is unique for each pc/hardware
and its pretty easy to access the file.....
other solution would be hosting online database witch would control the whole thing....

 

Thanks for the reply.

Ya, I've tried putting stuff in the data folder, and it doesn't work either. You know, like save games? Same problem as writing to the registry or to the /System/Library folder. On the Mac, you're supposed to put stuff like that in the user's Library folder. Windows, you put it in the Documents folder or Application Data folder. Product keys are a problem because we want all users to be able to use it, so we're a little stuck.

But thanks for trying, at least.

 

Yea, maybe reading Microsoft Guildlines for Windows Development would help

For Windows:
C:\ProgramData (XP equivalent of C:\Documents and Settings\All Users\Application Data on XP) is used to store Application specific files for _ALL_ users

C:\Users\USERNAME\AppData\Local Used to safe USER specific files locally which are NOT shared though the network (i.e. if users logs on to another PC with the same Login in his busines network, he won't have access to the files stored there. They are ONLY stored on the PC)

C:\Users\USERNAME\AppData\Remote: Used for user specific files which are saved REMOTELY on a domain server. When the user logs in into another PC, this data will be downloaded there on this PC and he has access to it

C:\Users\USERNAME\AppData\LocalLow: Mainly used for critical code, which runs with IL 2 (integrity Level2, that's one level below a normally logged in users and is the default IL used by Internet Explorer 7+), for example to store Java objects there. Because the folder is IL two, all of it's contents is saved and executed as IL 2 too, which means: If someone uses a nasty IE exploit it will be executed with IL 2 and IL doesn't have read/write access to IL 3 (normal user) IL 4 (Admin/privileged user), IL 5 (system) or IL 6 (Trusted User), hence he can't manipulate or hook into said process/memory (i.e. to install a key logger or bypass admin privileges).

Last but not least, there is
C:\Users\Public\Public Documents\

This folder is accessible to all users of the same PC. However, it is _NOT_ recommended to use this for storing license informations. It's actually more used to share document, music etc. or save games in worst case. Typically you want to save the save games in C:\Users\USERNAME\My Games\MyGameName\, alternatively C:\Users\USERNAME\Saved Games\

IT'S BAd behavior from even huge company to put save games in C:\Users\USERNAME\MyCompany\MyGameName\ or C:\Users\USERNAME\MyGameName\, thats very bad design and the user will have a very bad overall overview of this folders because they got full of his installed games folders where he'd expect his documents to be saved. Also he's annoyed, because some games save it here, some there, third do use a complete other place and it's a hell to backup the savegames.

Edit:
All of this above (with exception of AppData\LocalLow and Saved Games I think) was there for a very long time, since Windows 2000 was released and also since that time Microsoft advices to use the the environment variables for this files. It's hardly anything new. The absolute paths have changed since XP, that's true. But the environmental variable names renamed same. So applications who properly used the environmental variables had no problem with XP -> Vista/7 migration. Bad written software, from developers who failed to comply with that guidelines for 10 years, didn't and Microsoft even had to break the design and add visualizations for this failed developers...

As for UAC: Yes, it is by design to start the elevated stuff as extra process. This doesn't mean you have to start your, because when (with elevated privileges) logs into his machine, he gets a normal user token (which grants him only the normal rights a user needs). As a result, all files he execute (and that files execute) will run with Integrity Level (IL) 3, which applies to the whole process. However, privileged actions, like changing vital registry entries, requires IL 4 or higher and processes who run in IL3 can't write in IL4 areas. Hence, the process has run with the elevated privileges (admin, IL4) in order to write there.

Everything else is going to have security flaws and is not unattractive, but the only way they could made Vista and 7 more secure and less exploitable for malware (and they succeeded in doing this, 80%+ of XP exploits doesn't apply to Vista and 7 or their effect is very limited (i.e. until reboot))

 

Gonna necro this because I come from the future and this was the first link when I searched "unity where can I save user data without triggering UAC" on google.

As of 1/3/20 there's an article talking about storing application data here: "https://docs.microsoft.com/en-us/windows/uwp/design/app-settings/store-and-retrieve-app-data" which it only occurred to me to search for after reading the previous comment and thinking Microsoft probably already gives a way to get that file path without me having to hardcode it into my application, and getting it wrong if the person running the program has their computer configured to store these files in a place other than C: drive. HTH someone in 2030.