Sign in to follow this  
SBD

Watermarking (development) builds

Recommended Posts

I've been doing some thinking and research into watermarking (development) game builds, and thought I'd survey folks to see what methods people are commonly using these days.

The intent here is not copy-protection, per-se (although there is overlap in techniques), but rather being able identify the source of a game build.  The common scenario being that builds are delivered to a testing group or other external partner, and then a build shows up in the wild somewhere, or perhaps more likely a youtube video pops up showcasing your dev build.

The obvious answer is simply embedding an ID into the executable...in the case of finding a build in the wild, you simply inspect it and extract the ID.  In the case of a youtube video, I think a gameplay or UI element that covertly presents that ID (non-obviously) would be the way to go.

However, I'd like to explore doing something that is perhaps not so trivially found/altered.  For instance, if someone got their hands on two differently watermarked builds, it would then be easy to identify and replace the watermark ID with an invalid one.  In this case I might consider preventing the game from running (stressing that this would be a development build only thing).  I'm not too worried about someone going hardcore and circumventing the watermark validation check with code injection or what have you, but rather the trivial poking/replacing values scenario.

I've seen lots of interesting tricks (using RTTI class names, various other encodings via generated instructions, etc.), curious what you guys have found useful.

Edited by SBD

Share this post


Link to post
Share on other sites

This might be of interest:
http://www.ownedcore.com/forums/world-of-warcraft/world-of-warcraft-general/375573-looking-inside-your-screenshots.html
http://ftr-wot.blogspot.com.au/2013/05/hidden-tags-in-wot-screenies.html

Personally, we just use Steam to solve the dev/preview build access problem via the same DRM mechanisms as used in retail builds.

Share this post


Link to post
Share on other sites

Yeah, those encoded-into-image techniques are fairly ingenious.  Obviously the flaw in those particular implementations is that they rely on the in-game screenshot, which is easily bypassed by using FRAPS or some other external screenshot program (or just Print Screen).  The answer to that is to actually always watermark your final presentation image as the last stage of your rendering.

However, it seems to me that those encoded-image techniques are somewhat vulnerable to re-encoding destroying the data.  i.e.; someone takes screenshot / video, then re-compresses / processes / encodes the image/video.  My thought has been to have an in-game element (perhaps a readout /  gauge or the like) that actually delivers the watermark by changing its own presentation (a sequence of techno symbols that innocuously appear as "cool computer FX stuff", perhaps an element that rotates, etc.).

The in-game "hidden" presentation of the watermark is interesting but fairly solvable.  Making it trivially undetectable/findable/alterable via build (binary) comparison is probably the slightly more tricky part.  Finding or realizing there's a watermark aside, I would like to make it difficult to semi-trivially invalidate / remove / replace (in the build itself).

Edited by SBD

Share this post


Link to post
Share on other sites
Can you use a piece of information that is external to the binary but tied to the player?

For example, maybe a username? If the watermark code just reads the account login name, you have no need to imprint every binary by hand, and you still get down-to-the-account specificity when reading watermarks.

Share this post


Link to post
Share on other sites
Yeah, those encoded-into-image techniques are fairly ingenious.  Obviously the flaw in those particular implementations is that they rely on the in-game screenshot, which is easily bypassed by using FRAPS or some other external screenshot program (or just Print Screen).

 

It doesn't have to be stopped by that. Steganography in software is nothing new. Adobe was caught with them in the late 1990s. Printer "yellow Dot" patterns have also been widespread for about 20 years.

It is slightly less common in games, but still rather prevalent.

I know at my last three companies we used various technologies for watermarking screens of reviewer builds and builds that went to trade shows. They ranged from blatant words in the corner like "Evaluation copy -- <Name>" to more subtle images or toning patterns. It isn't that hard to overlay a pattern of slightly visible masses over the screen for a subtle effect. We've even had reporters caught using pirated versions of our games which means no more releases for them.  

Share this post


Link to post
Share on other sites

I would like to make it difficult to semi-trivially invalidate / remove / replace (in the build itself).

There are two parts to DRM technology: DRM (including watermarks), and anti-crack protection. The DRM is used to protect the software.  The anti-crack technology is used to protect the DRM. DRM without anit-crack technology is like a bank with no safe and no locks on the doors or windows. its just waiting for someone to come in and mess up your day.

The way to learn anti-crack technology is by first learning game cracking techniques. Then you can begin to formulate solutions to slow down the crackers. you can only slow them down, never stop them. the idea is to make it more work than its worth, which depends on how badly they are going to want to crack your game.  by and large that seems to be a function of popularity.  the more popular the game, the more effort some folks will go to in order to crack it.

 

i posted some research notes on the subject in my dev info blog:

https://www.gamedev.net/blog/1729/entry-2258666-anti-crack-info/\

 

But the work to protect watermarking code will be the same as for protecting full blown DRM. it really comes down to who gets their hands on it and how badly they want to crack it,  as to how much anti-crack protection is enough.

Share this post


Link to post
Share on other sites

 

Can you use a piece of information that is external to the binary but tied to the player?

For example, maybe a username? If the watermark code just reads the account login name, you have no need to imprint every binary by hand, and you still get down-to-the-account specificity when reading watermarks.

That's an interesting thought.  Presuming you're referring to the windows login account name, I guess the danger there is relying on someone having a non-nonsense user name.  But while that does give you (limited) information about who currently has the build, in the case of a leaked build it doesn't give you information about who was originally entrusted with it.  Speaking of accounts, obviously if you have online registration/accounts for your game, then you've got lots of things at your disposal for IDing (and potentially preventing from running).  In my case, for the time being, I'm considering the case of a standalone build.

 

I know at my last three companies we used various technologies for watermarking screens of reviewer builds and builds that went to trade shows. They ranged from blatant words in the corner like "Evaluation copy -- <Name>" to more subtle images or toning patterns. It isn't that hard to overlay a pattern of slightly visible masses over the screen for a subtle effect. We've even had reporters caught using pirated versions of our games which means no more releases for them.

This is pretty much along the (scenario) lines of what I'm thinking about (throwing in external tester builds as well).  A blatant "eval only <name>" is sensible, but easy to simply blur/cover on a screenshot or video.  I'd lean more towards them not necessarily knowing there is a watermark/ID present.

 

But the work to protect watermarking code will be the same as for protecting full blown DRM. it really comes down to who gets their hands on it and how badly they want to crack it,  as to how much anti-crack protection is enough.

I completely recognize this is the usual slippery slope of "outsmarting the hackers"; in my case I'm just trying to prevent dumb stripping/replacement of the ID that simple binary inspection/comparison of two builds might easily reveal.  Along the lines of "can't just find the difference in an executable between two differently watermarked builds, then put garbage for the watermark ID".  I don't even care if they swap build IDs (that still gives me a leaked build ID), but rather preventing making the ID totally invalid.  So basically one level of obfuscation higher than just compiling with a different #define'd build ID, trying to make it just a little more difficult for someone to muck up the watermark if they become aware of it.  Worrying about real reverse-engineering/cracking is beyond what I am concerned with.

Good discussion...this stuff is sort of fun to think about, although not really something you really relish polluting your code/build with.

 

Share this post


Link to post
Share on other sites
although not really something you really relish polluting your code/build with.

judicious use of #ifdef can keep things pretty clean. I implement things like VMs, self editing code, encryption, file CRC checks, ram CRC checks, date checks, keydisk checks, etc with minimal impact on the code.

 

its seems that what you want is to be able to tell from a screenshot which copy of the software was used to create the screen shot. Even if its been altered. about all you can try is some sort of embedded watermark that uses error correction algos, such as hamming code. That way, even if the image has been altered, you may still be able to extract the watermark data. Combine that with multiple types of watermarks, and you may just have something. But it seems like a lot of work. You may want to just tighten your vetting of who you give the game to. In the long run, its safe to assume that anything you put out there will be abused somehow. Don't give away any more than you have to.

Edited by Norman Barrows

Share this post


Link to post
Share on other sites

its seems that what you want is to be able to tell from a screenshot which copy of the software was used to create the screen shot

Precisely.  In my thinking, I'm trying to consider two cases:

1)  An actual build (or part of a build) shows up out in the wild somewhere.  We want to have an ID/watermark in the data/exe that we can extract and use to identify the original trustee.

2)  Screenshots and/or video shows up in the wild.  We want to have the ID watermarked in the visual presentation so we can extract it and identify the original trustee.

For my purposes, I think embedding a (differently) fuzzed ID in a few spots (exe and compressed data) along with some general CRC checks will suffice for "protecting" the build ID from dumb simple replacement.  The presentation of the ID as a visual watermark is a solvable problem, it's just a matter of determining which method best suits my needs.

Thanks, everyone, for the input.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this