Updates

Started by
8 comments, last by hplus0603 12 years, 9 months ago
After reading about: http://windowsteambl...edirection.aspx

How is it supposed to make an update? I made some tests in a normal installation and the updated files went to the virtualstore :S.
It is really a mess.
Advertisement

Sorry for bringing this old post back.
I just readed about: http://windowsteambl...edirection.aspx

How is it supposed to update? I made some tests in a normal installation and the updated files went to the virtualstore :S.
It is really a mess.


The recommendation for modern Windows UAC MMOs is to store the updater/launcher part in the program files directory, then store the patched executable and data files in the AppData directory in the user's profile (or global AppData). The executables in the globally writable directories should be signed using a private key, and the public key used to verify the signature should be stored in the program files directory where it's not writable by regular users.
enum Bool { True, False, FileNotFound };
store the updater/launcher part in the program files directory[/quote]
Ok

then store the patched executable and data files in the AppData directory in the
user's profile (or global AppData)[/quote]
But in most cases an update means overwrite files, if files are in program files directory how do you update copying to appdata?

Thanks!

store the updater/launcher part in the program files directory

Ok

then store the patched executable and data files in the AppData directory in the
user's profile (or global AppData)[/quote]
But in most cases an update means overwrite files, if files are in program files directory how do you update copying to appdata?
[/quote]

You're saying you need to update the updater? No can do. Get it right! :-)
Or separately distribute an installer, chain to the installer (which will need UAC OK) and quit the patcher itself.

The only files that are in the program files directory (and thus not user-writable) is the patcher executable and the public key used to verify the exe and dll files in the writable AppData location. The patcher should patch exe and dll files before it starts the exe, so there's no concern about overwriting files that are currently in use.
enum Bool { True, False, FileNotFound };
I see coherent the recomendations for the UAC, but I see games like WOW which install everything at any location user specifies, updating the game and updater itself without a problem.

store the updater/launcher part in the program files directory, then store the
patched executable and data files in the AppData directory in the user's profile
(or global AppData).[/quote]
So having all these files which are your game:
updater.file, a.file, b.file

1. At projectfile folder\MyGame: updater.file
2. At appdata folder\MyGame: a.file, b.file

In a situation where you don't plan any file to be changed (but you could add new ones) may the entire application go to appdata? I don't see the sense for the program files directory but just security and problems in the case you need to make some not foreseen modifications?

-What about if you are already suffering data-redirection? May you keep doing things as if nothing happens? :)
-Any suggestion/link on how to proper fabricate the public key used to verify the exe?

Thanks.

In a situation where you don't plan any file to be changed (but you could add new ones) may the entire application go to appdata? I don't see the sense for the program files directory but just security and problems in the case you need to make some not foreseen modifications?

-What about if you are already suffering data-redirection? May you keep doing things as if nothing happens? :)
-Any suggestion/link on how to proper fabricate the public key used to verify the exe?


Redirection only happens for the program files directory, not the appdata directory.

The reason to have your updater and your public key for signature in the program files directory is so that no un-privileged user can attack the integrity of your software.
Specifically, the updater/launcher should verify the signature of each .exe and .dll in the appdata directory (which is globally writable) before it actually starts that exe.
Thus, you can't patch the exe or dll files in appdata without breaking the signature, and you can't hack the key for the signature because it's stored in the write protected program files directory.

Now, this protects against non-intended hacks, from things like trojans or illicit scripts. It does not protect against hacks that the user desires, because a wiling user can apply privilege elevation (or just turn off UAC) and patch the program files directory.

If you don't think your game needs protection against illicit scripts or trojans, you don't need to store any part in the program files folder, but then you are creating incentives for your players to try to cheat/fool each other into running downloaded hacking tools or trojans.
enum Bool { True, False, FileNotFound };
-What about if you are already suffering data-redirection? May you keep doing
things as if nothing happens? :)
-Any suggestion/link on how to proper fabricate the public key used to verify the exe?
[/quote]
So, any suggestion?

-What about if you are already suffering data-redirection? May you keep doing
things as if nothing happens? :)
-Any suggestion/link on how to proper fabricate the public key used to verify the exe?

So, any suggestion?
[/quote]

I would just come up with a new application name and "upgrade" to that with the new system.
For the public/private key cryptography, try using openssh, or the crypto++ library, or whatever comes built into your OS/framework.
enum Bool { True, False, FileNotFound };
For the public/private key cryptography, try using openssh, or the crypto++
library, or whatever comes built into your
OS/framework.[/quote]
What about OpenSSL? Maybe http://www.openssl.o...s/apps/rsa.html

For the public/private key cryptography, try using openssh, or the crypto++
library, or whatever comes built into your
OS/framework.

What about OpenSSL? Maybe http://www.openssl.o...s/apps/rsa.html
[/quote]


OpenSSL is provided under the Apache license, which may be less suitable than the BSD license of OpenSSH. If you're OK with Apache license, then OpenSSL is a fine choice, too.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement