I figured that is the case. No matter what, you can always end up with a cracked exe and a leaked key. As I don't want to go for hardware validation, and online authentication is out of the scope of the project, I'm just going to live with this.
I figure that the two pirating methods mentioned are slightly less easy to users than just grabbing a keygen'd number and pasting it in the validation window. It is also something that may need to be done for every update patch (since I can always stop previous leaked keys or change the exe pattern), which again just increases the inconvenience that slight amount. That slight inconvenience is all I'm really aiming for, which is why I'm most concerned with having a proper strong key method.
So as far as I see it, the scheme is trivial to implement, slightly inconvenient for pirates, and is convenient for actual users. That seems good enough for me, unless of course there is some amazing anti-pirate method out there that I'm missing.
Geoff
Svante Karlsson wrote:
First - the problem with "well known" keyfiles will be a problem if there is no other way to crack your program.
Next - what I think will happen is that someone figures out how to make your program skip the keytest altogether. If that isn't possible for some reason then your embedded public key will be changed (by a small crack) thereby making it possible to generate a valid signed keyfile with a keygenerator
All the above only applies if there is a "great" interest in your software.
You have to figure out a better way of doing this...
Cheers Svante Karlsson
-----Original Message-----
From: Geoff Carlton [mailto:[EMAIL PROTECTED] Sent: den 19 maj 2005 02:49
To: [email protected]
Subject: Shareware authorisation
I'm developing a game for online indie distribution via the web. I'm going to use Cryptopp for the shareware/registration, I just want to run by the method I've chosen to make sure I'm not doing anything obviously stupid.
I'm using RSASSA_PKCS1v15_SHA signer and verifier with 2048 key length. When users register (with SWREG), I generate a struct of data. This contains some "magic number" constants, some info about the current time/date/version, and also some details of the user such as their name and email. This is then signed with an internal program (that contains a private key), and written out to a binary file.
The data file is then emailed to the user. The game uses the verifier with a public key embedded in it. If that data file exists in the root directory, and is signed properly, it examines the struct of data, checks the magic numbers, versions etc. If registered, it can display the user's information on screen and unlock the main game levels.
I want to ensure that no keygen is possible. As far as I understand it, it should be practically impossible to generate an arbitrary struct of data and sign it, unless of course I accidentally leak the generator program and thus give away the private key.
As such the main ways to get around the system are either to for users to copy their data file and pass it around, download a (previously leaked) data file, or download a cracked exe. I'm less concerned about these compared to the keygen, because if a single registered file starts becoming available, in the next game update I could always bar it.
Thanks, Geoff
