DRM - Part 1

Download Alpha and Omega v2.
Binaries as Win32 Installer (493 kB)
Download Alpha and Omega v2.
Source as Visual Studio 2010 Solution (128 kB)

It was time to integrate DRM logic to my empty XNA project. We started by creating a little bit of Photoshop concept art of the GUI in which the player must choose the most awesome unicorn. This is what the player is forced to do (at least once a day) as long as he hasn't uploaded a unicorn-picture himself. These unicorn images below are randomly picked from the internet but when the system is fully functioning the images are from other players.

These images have to be downloaded from one of my servers but I don't want to aggravate people that have a bad internet connection. And what happens if my server goes down? The idea is to download a couple of images in the background when the user is playing the game, so the next time the program is started these images can be used for the nag-screen. So even when no internet-connection is currently available, it is still possible to nag. If no internet connection could be made at all (and hence no unicorn drawings could have been downloaded) we need to nag with a different screen.

The concept art is clearly too simplistic. We need to inform the user why we are nagging, how to prevent the nag screen, and what is expected of the user. There should also be some option to report images that are not of unicorns or are simply not appropriate. The 'unicorn' on the bottom right for example has wings and under no circumstances should we allow this blasphemy to exist.

Uploading A Drawing

By uploading a drawing the game should know that a payment has been made even when the computer is offline. Paying will result in the Local-account being linked to an Online-account which will be necessary for multiplayer games (if that is ever going to be implemented). Offline verification of payment will be done using RSA-signing. We'll just generate a private-public keypair and put the private key somewhere on the webserver and the public key in the game's data files. When uploading the image the following information will be sent to the server:

  • serial number
    The serial number can be uniquely identified to a certain installation of the game in combination with the Windows user playing the game. This serial number represents the identification of a local account. Serial numbers a automatically generated and do not need to be entered by the user. Notice that a serialnumber is not the proof of payment in itself (it is not a so called product key).
  • email address
    We need to link a local account to an online account. Possibly multiple local account can be linked to a single online account. So if the operating system is re-installed or the game is installed on another computer than instead of paying again it is also possible to verify a previous payment. By entering your email-address of a previous payment you will receive a verification e-mail to make sure you are indeed an existing proud owner of Alpha and Omega.
  • image
    The 800x600 image of a unicorn off course.

This information will be stored in a database and a verification e-mail is sent to the specified address. When the user opens his e-mail and clicks the verification link, the web server will sent the signed serial number to the game (the game will be polling to see if the web server is willing to send a signed serial number). A local installation is able to verify using the public key if the server has acknowledged the payment. It is also possible to verify the serial number to check if it is a serial that corresponds with this specific installation of the game (so no copy-pasting of signed serials will be possible). There is no reason to add a password for this system just yet. When the online account is used for more stuff than just payment verification we need to add passwords and session-keys to prevent a simple hijacks of accounts.

As reader it is important to notice that this DRM system is not hacker-proof. It does not matter how many fancy terms we use, it is still a DRM and hence crackable. This is not because we don't have the knowledge to build a hacker-proof system, it is because DRM is fundamentally flawed in principle. It's like saying: "I want people to listen to my music, but not able to record it". We can use all the encryption and all the CD-copy protection in the world, but that won't stop one guy with a simple microphone. Software is no different. If you want people to use your software, yet protect it against copying you're fighting a hopeless battle. Having the program rely on some online server (like an MMO) only delays it because it is still possible to reconstruct the protocol and emulate the server. The only possible solution I see for future development is thin-clients (web browsers for example). If almost all the computations are done on some online server (the 'cloud' for example) and the cliënt-application only does the bare essentials (like drawing on the screen) than cracking software involves recreating the complete application from scratch.

Server Serial Signing

When the serial and image is uploaded to the server than the server will verify the serial and if everything is okay it will be stored in a database. Because I'm a cheap-ass, I do not intend to create an actual 'application' that does this for me. Instead we'll just use PHP because this web-server is already able to do that. I though it would be easy to create a signed XML from a PHP script, but it turns out there is absolutely no support for that. There probably aren't many people interested in creating signed XML's with PHP, which somehow sounds very strange to me. I know it is not standard website-stuff, but signed XML's are vitally important to decent web-based communication channels (e.g. webservices). Maybe I should take this as a sign that PHP is not scaling well and that other server-side scripting languages are taking over the market. Java and ASP.Net are way more powerful, too bad that most providers only give us access to PHP. I'm probably just spoiled by using decent languages and frameworks. As I'm scripting in PHP I'm getting more and more annoyed. The function 'hex2bin' is only available from version 5.4.0 and up?!? Seriously? No one needed a function like that for all that time or everybody just made a function like that for themselves? Sigh. I suppose I should consider myself lucky that I remember most syntax and API-functions of PHP, it is not a language I would recommend to any starting software engineer.

I did manage to load my private RSA key with PHP and create a signature from a string. This is not the same as signed XML's and unfortunately not a solution that is equally beautiful, but it'll have to do. The signature I create with the .NET application is equal to the one created in PHP ensuring me that the code is working properly.

So this is what we've got:

  • MySQL database
    The database stores registration information. We store information about who have actually bought the game and where we can find the unicorn-image that he/she has sent us.
  • A PHP script
    When a payment is made in the game, the application will submit the picture to this script that will store the information in the database.
  • C# Classes and Functions (in Unicorn.dll)
    This code will handle most of the DRM stuff like creating per-user serial numbers and uploading a unicron image to the PHP page.

And this is what we still need:

  • More MySQL tables
    The nag screen is basically asking the user to pick the most beautiful unicorn. These ratings need to be stored somehow.
  • More PHP scripts
    We need another PHP script to receive the ratings and store them in the database. We also need a PHP script that handles the verification link that will be sent to the email address.
  • More C# Classes and Functions (in Unicorn.dll)
    We need a polling system to receive a payment signature from the web-server so we can see if a payment is verified through the link sent to the email address. When this payment signature is received we will disable the nag-screen.
  • GUI
    We need to create a GUI for both the nag-screen (see concept art above) and the screen for selecting an image and uploading it as payment.

What’s Next

This was probably a really boring post. Nothing we did can be shown in the binary releases and the majority of work (PHP) is not shown in the source distribution. I'm not sure how to handle source distributions of server-side scripts and databases. It will be a lot of work distributing the source every time, especially because I need to replace private RSA keys, passwords and other sensitive information before releasing it. When we have implemented the two GUI-screens it will become more interesting so that will be the focus of the next post.

My First OmegaMusic + DRM Part 2