• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Andrew Lucas

Protecting shader code?

32 posts in this topic

I'd have a question. I'm very etchy on making sure my code can't fall into the wrong hands, and I was wondering, is it possible to make sure that nobody can extract shader code from the graphics application? I'm asking this, because I know that there are programs that allow people to fetch the shader contents when it's sent to the graphics card. I know, I could easily just convert my shader into assembly code and only keep that, but is there a fool-proof method? Thanks.
0

Share this post


Link to post
Share on other sites
You can ship your project with compiled shader code with striped comments. However other people will still be able to intercept your code when it's passed to the API and disassemble it.
0

Share this post


Link to post
Share on other sites
Thanks for clearing this for me. Hopefully, just compiling it into assembly will be enough to make it un-editable.

I'm concerned, because in the community that mods for this game, a lot of newbie developers would do anything to get their hands on more advanced code, and the last thing I want is others stealing my work.
0

Share this post


Link to post
Share on other sites
There is no assembly in GL. There is just GLSL.
ARB_vp and ARB_fp are ancient extensions and that is not going to protect your code.
0

Share this post


Link to post
Share on other sites
Yeah, I know it won't, but hopefully it'll make it harder for them to get anywhere. As far as I know, Cg can easily compile shaders even if put in as assembly code.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Andrew Lucas
Thanks for clearing this for me. Hopefully, just compiling it into assembly will be enough to make it un-editable.

I'm concerned, because in the community that mods for this game, a lot of newbie developers would do anything to get their hands on more advanced code, and the last thing I want is others stealing my work.


Run this program alongside your project, GLIntercept, to just see how easy it is to rip out stuff from your program. From there, you will know just what can be extracted and the format it will be dumped in so you can determine if you want to use your shaders or come up with alternatives. You should also note the program features of GLIntercept:
Quote:

# Run time shader edit. Display shader usage and edit the shaders at run time. Supports ARB VP/FP/GLSL and NV VP/FP

# Save and track shaders/programs. Current support in 0.41 includes ARB VP/FP/GLSL and NV VP/FP.


Trying to protect against such programs is really hard, so you should reevaluate the data content you are going to use rather than trying to prevent people from taking your assets.
0

Share this post


Link to post
Share on other sites
As ARB-asm shaders are ancient and NV-asm shaders are unusable on ati cards, you'll probably be stuck with the GLSL script. You can obscure code by doing the pre-processor's job in your own code and have each symbol mapped to some internal value, or garbled in a predictable way. You can't stop determined ones, but can cull the less skilled bunch by verifying the location of opengl32.dll, modules that have injected themselves in your process space, and the 5-byte "push ebp | mov ebp,esp" hooks, that Win32 allows. There's also NVEmulate to account for...

Meanwhile, CryTek put their advanced shaders' sources and data in a .zip file with no protection whatsoever.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Andrew Lucas
Yeah, I know it won't, but hopefully it'll make it harder for them to get anywhere. As far as I know, Cg can easily compile shaders even if put in as assembly code.
You seem to have misunderstood what V-Man said. To quote: "There is no assembly in OpenGL". That means just what it says - you cannot ship modern shaders in compiled assembly.

There is the ancient ARB assembly language, but that won't support modern shaders. There is also the more recent NVidia assembly language, but that won't work on non-NVidia cards (i.e. ATI, Intel, etc.).

As for protecting your shaders, the question is still "why?". Commercial companies don't bother protecting their shaders - they even publish academic papers on all the shader techniques they develop - and (no disrespect, but) I highly doubt you will be developing shader techniques that are much more valuable than commercially developed shaders.
0

Share this post


Link to post
Share on other sites
Without knowing the actual quality of the shader code in question, it _does_ remind me of frequent "how do I protect my HTML code" questions. Surprisingly, in 9 out of 10 cases the sheer awfulness of the code in question was all the copy protection they need.

Seriously, with books focusing on the latest shader techniques and cutting edge games basically "openly" displaying their code, why bother? Most people thinking they came up with something so utterly brilliant it's "never seen before" post about it or write a paper. In in my opinion that very fact allows techniques to be extended, refined and built upon, which results in games looking as good as they do today.
0

Share this post


Link to post
Share on other sites
Yeah, pretty much the best answer to the question of "How do I protect my code/art/sound" is going to be the same every time; there's absolutely no point in trying to protect it.

Not only is it possible to rip that stuff out anyway, you have absolutely nothing to gain by making it inaccessible. I mean, think of any big-name game on the PC; there's a way for you to get textures, models and shader code out of them.

If the big companies don't care, why should you? Don't confuse stuff like Id using .PK3 files as 'protecting' them, those are used for other reasons, including making modding easier.

So before you start asking 'how', ask yourself 'why'.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
As for protecting your shaders, the question is still "why?".

Protection of intellectual property. Obscuring something, so to delay the competition (even by a few months). The alternative are software patents. I prefer the former solution.

Quote:
Original post by swiftcoder
Commercial companies don't bother protecting their shaders

Not yet. But as technology advances, almost all of the innovative IP in graphics programming will be in the shaders. Everything else is just supporting framework. This IP needs to be protected.

Quote:
Original post by swiftcoder
- they even publish academic papers on all the shader techniques they develop -

It is getting increasingly common that such papers come attached to a SW patent, unfortunately. But that's the way things go if current graphics APIs essentially force you to open source your shader code, even though you possibly invested millions into the R&D behind those shaders. Publishing a paper about a technology is fine. But you don't want to supply your competition with a finished, ultra-optimized shader they can readily plug into their competing product (after the obligatory modify-it-a-little-to-avoid-copyright-violation). There is still a rather big distinction between theory and an actually working implementation. Publishing the former is good for innovation and evolution of graphics technology. But giving away for free the latter is just dumb.

I am a very big proponent of binary blobs. It is a major problem that OGL still doesn't have those. In fact, I would propose to go even further, by using encrypted shaders with GPU on-dye decryption. This will take out all these interceptors out there.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann LProtection of intellectual property. Obscuring something, so to delay the competition (even by a few months). The alternative are software patents. I prefer the former solution.

That's false dichotomy, even if there was 100% effective way how to obscure the code, software patents would still bloom as they are powerfull, generalized and get law enforcement on your side.
Quote:
It is getting increasingly common that such papers come attached to a SW patent, unfortunately. But that's the way things go if current graphics APIs essentially force you to open source your shader code, even though you possibly invested millions into the R&D behind those shaders.

That's the way things will go regardless. It was the same way when CPU programming shifted from assembler to higher languages. It too didn't prevent software patent explosion.
Quote:
I am a very big proponent of binary blobs. It is a major problem that OGL still doesn't have those. In fact, I would propose to go even further, by using encrypted shaders with GPU on-dye decryption. This will take out all these interceptors out there.

Like we haven't enough compatibility problems already
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
In fact, I would propose to go even further, by using encrypted shaders with GPU on-dye decryption. This will take out all these interceptors out there.
Meh - how long till the decryption is cracked? DRM has never worked, and will never work as long as content is present on the end-user's computer/physical media.

Even if nobody breaks the decryption expressly for the purpose of reverse engineering shaders, eventually the WINE guys will need to provide decryption in software, or, you know, the MESA guys, the Apple Software renderer, etc.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by snoutmate
That's false dichotomy, even if there was 100% effective way how to obscure the code, software patents would still bloom as they are powerfull, generalized and get law enforcement on your side.

You do realize that SW patents are very expensive, notoriously hard to enforce (and even unenforceable in many jurisdictions), and relatively easy to circumvent ? In fact, SW patents are far from being first choice for smaller companies. Many would rather not use them. However, if you don't have any other choice in order to protect your IP, then you just have to go that way. Certainly shader source is only a small part of this process, but it is getting more and more important, at least in the graphics sector.

Quote:

Like we haven't enough compatibility problems already

There is no reason why such a system would create compatibility problems. It's a question about vendors deciding on a standard. D3D has binary blobs (although no encryption). No compatibility issues.

Quote:

Meh - how long till the decryption is cracked? DRM has never worked, and will never work as long as content is present on the end-user's computer/physical media.

Not that easily. The decryption key pool is only present on the GPU dye, nowhere else. Each vendor registers a certificate with the GPU manufacturer, and receives a secret key to encrypt their shaders. The decryption is then done directly in the GPU core. Of course, this has some technical issues still unresolved (the shader would have to be precompiled in GPU-specific ASM before encryption, or the GPU would need to translate a standard intermediate ASM), but nothing impossible.

Quote:

Even if nobody breaks the decryption expressly for the purpose of reverse engineering shaders, eventually the WINE guys will need to provide decryption in software, or, you know, the MESA guys, the Apple Software renderer, etc.

Encryption would be entirely optional. 'Trusted' software with encryption would simply refuse to run on software renderers. It wouldn't even affect open source drivers, since it would be a hardware feature, without key-holding requirements for the driver.

But that's already going quite far. Utopia aside, I would already be very happy with simple precompiled shaders under OpenGL. Obfuscation for one, cutting down on compilation cost, etc.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
Not that easily. The decryption key pool is only present on the GPU dye, nowhere else. Each vendor registers a certificate with the GPU manufacturer, and receives a secret key to encrypt their shaders. The decryption is then done directly in the GPU core.

That almost sounds the methods used by the motion picture industry to "protect" their content. Not huge fan of this, to be honest.
0

Share this post


Link to post
Share on other sites
encryption aint gonna happen (within 10 years at least)

ATM even obfuscating the shader code is of little use. since there are programs that can save to disk all programs/textures etc on the GPU.

alos no offence Andrew Lucas but youre obviously a beginner, why would anyone want to 'steal' your code :) Perhaps if you were carmack (who has everything out in the open anyway) it would be perhaps an issue, youre better off spending your time on 'real' issues.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
The decryption key pool is only present on the GPU dye, nowhere else. Each vendor registers a certificate with the GPU manufacturer, and receives a secret key to encrypt their shaders. The decryption is then done directly in the GPU core. Of course, this has some technical issues still unresolved (the shader would have to be precompiled in GPU-specific ASM before encryption, or the GPU would need to translate a standard intermediate ASM), but nothing impossible.
To be honest, this doesn't sound that different to the various DRM approaches attempted for DVD and Blueray (and the game console equivalents) - and we all know how well those worked out...
Quote:
Encryption would be entirely optional. 'Trusted' software with encryption would simply refuse to run on software renderers. It wouldn't even affect open source drivers, since it would be a hardware feature, without key-holding requirements for the driver.
That sounds akin to those programs that reboot your computer when you try and attach a debugger - the intent may be to protect IP, but the end result is that you sell me a potentially broken program, which I have no way to debug or patch. And given the number of games that do ship broken (and I am not even counting DRM fiascos such as StarForce), I prefer that the manufacturers not have the option of *hiding* what is broken.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by zedz
encryption aint gonna happen (within 10 years at least)

Agreed. One can dream, though... ;)

Binary blobs, however, are probably going to happen in the nearer future. And they have advantages beyond the obfuscation.

Quote:
Original post by swiftcoder
To be honest, this doesn't sound that different to the various DRM approaches attempted for DVD and Blueray (and the game console equivalents) - and we all know how well those worked out...

There is a major difference here. Usually, DRM measures try to combat piracy. The system discussed above is only trying to combat reverse engineering. Another important difference is the key holding policy. Almost all DRM encoded media attacks were carried out on software players, which obviously had to hold the decryption keys. The system I propose would entirely function in HW. In order to extract the decryption keys, one would have to RE the GPU itself, which is insanely expensive and complicated (or you need an insider at the GPU manufacturer, or hack the central registry servers, etc). Certainly not uncrackable, but much better than sending plain text high level shader code to the driver, which is an invitation to copy'n'paste.

Quote:
Original post by swiftcoder
That sounds akin to those programs that reboot your computer when you try and attach a debugger - the intent may be to protect IP, but the end result is that you sell me a potentially broken program, which I have no way to debug or patch. And given the number of games that do ship broken (and I am not even counting DRM fiascos such as StarForce), I prefer that the manufacturers not have the option of *hiding* what is broken.

Well, there's quite a difference from encrypting shader sources to something like Starforce. The proposed system does in no way restrict any of your rights, or even gets in your way. It doesn't install any drivers, root kits, or whatever other crap. It's just a way to send encrypted data to a piece of hardware. It's really simple, actually: your IDE compiles the shaders and encrypts them with the secret key you got with your certificate. You ship these binary shaders. The client takes the shader, sends your certificate GUID to the GPU (which internally selects the corresponding asymmetrical decryption key from it's ROM-based pool), and you send the binary shaders. The GPU decrypts them, possibly translates them, and caches them in VRAM. Done.

Quote:
Original post by swiftcoder
but the end result is that you sell me a potentially broken program, which I have no way to debug or patch.

That's illegal anyway (at least in the US). And there's no reason such a system would 'break' in any other ways than those already well known - ie. simple software bugs. These happen with or without encryption. In fact, the encryption being transparent to the developer, it's very unlikely to be a point of failure.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
The system I propose would entirely function in HW. In order to extract the decryption keys, one would have to RE the GPU itself, which is insanely expensive and complicated (or you need an insider at the GPU manufacturer, or hack the central registry servers, etc). Certainly not uncrackable, but much better than sending plain text high level shader code to the driver, which is an invitation to copy'n'paste.

Indeed. This is a couple orders of magnitude harder than the current situation, but I can imagine a sufficiently motivated hacker writing a simple kernel module to dump the decrypted executable from VRAM. Executable formats are well-documented and relatively easy to disassemble, so your code is still exposed.

Now, there are ways to stop this attack vector but it's a tradeoff between performance and complexity. Plain binary shaders would get you the most of the benefits for the least hassle.

I find it rather interesting that no IHV has managed to create a "binary shader" extension for general use, even though this is one of the most-requested features since 2003! There must be significant technical hurdles blocking binary shaders - I distinctly recall Ati bashing the D3D shader compiler and actually *undoing* its optimizations before passing it through its own optimizer. On the Khronos' side, the most recent attempt was in OpenGL ES 2.0 and is basically dead in the water (no driver I know of implements this).

There seems to be more to this than typical ARB incompetence.
0

Share this post


Link to post
Share on other sites
The main problem for me is that its hard for me to think of any game that has gained a competitive advantage by simply copying graphical techniques. By the time someone "steals" your shader code, your game is already out, or is close to being out. They're automatically behind you. Furthermore, they may have to do additional work on the engine and assets to even be able to use your techniques.

In the end, my opinion as a game-player seems to be that the artistic assets are probably more important than shader code. Having a good-enough engine displaying an excellent artistic style is a better situation than having a technically advanced engine displaying a bland or unoriginal artistic style.

I'm just not sure that hiding shader techniques is much of a competitive advantage. I'm even more doubtful that its enough of a competitive advantage to warrant spending development time to protect them.
0

Share this post


Link to post
Share on other sites
I agree that it doesn't really make any sense for *games*, but graphics are used in more fields than games. Companies in those fields tend to be very competitive and extremely protective of their IP (you know, armies of lawyers, node licenses/DRM, tightly-controlled hardware - all kinds of fun stuff!)

Yann L's million-dollar R&D figure kinda hinted at this. :)
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Fiddler
Indeed. This is a couple orders of magnitude harder than the current situation, but I can imagine a sufficiently motivated hacker writing a simple kernel module to dump the decrypted executable from VRAM. Executable formats are well-documented and relatively easy to disassemble, so your code is still exposed.

That would be quite trivial to block. The GPUs memory manager would just have to make sure that the portion of the VRAM holding decrypted data will never be mapped into CPU accessible address space (a 'no external access' flag for the concerned memory pages would do the trick). It could even use dedicated, high speed VRAM for this purpose. If done right, then there would be no technical way to access this information by software, not even by accessing the GPU on per-register basis.

Quote:
Original post by Fiddler
There seems to be more to this than typical ARB incompetence.

Yeah, there are lots of technical issues. Specifically finding an appropriate intermediate format that would still allow all needed optimizations for different GPU architectures (eg. scalar vs. vector), and that doesn't give a performance advantage to one specific manufacturer.

Quote:

By the time someone "steals" your shader code, your game is already out, or is close to being out.

It's not about a single game. It's about engine sub-licensing. Your engine is much more valuable to potential licensees, if it has a totally unique selling point, that the competition cannot easily reproduce.

Quote:

In the end, my opinion as a game-player seems to be that the artistic assets are probably more important than shader code. Having a good-enough engine displaying an excellent artistic style is a better situation than having a technically advanced engine displaying a bland or unoriginal artistic style.

Certainly true for current generation engines. But with the advent of GPUs with more and more programmability (think Larabee), shaders will become more and more important. We're just at the beginning here. A few years back, most titles still used the fixed function pipeline. Imagine you somehow manage to code a fully realtime GI solver. That would definitely be something you'd like to keep to yourself as long as possible, because it will give you a tremendous competitive advantage.

And yeah, there's more to the graphics industry than games. But most of this also applies to future cutting-edge games.
0

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
Quote:
Original post by Fiddler
Indeed. This is a couple orders of magnitude harder than the current situation, but I can imagine a sufficiently motivated hacker writing a simple kernel module to dump the decrypted executable from VRAM. Executable formats are well-documented and relatively easy to disassemble, so your code is still exposed.

That would be quite trivial to block. The GPUs memory manager would just have to make sure that the portion of the VRAM holding decrypted data will never be mapped into CPU accessible address space (a 'no external access' flag for the concerned memory pages would do the trick). It could even use dedicated, high speed VRAM for this purpose. If done right, then there would be no technical way to access this information by software, not even by accessing the GPU on per-register basis.


Here is where the performance/complexity trade-off enters the picture. What if you overflow the dedicated VRAM (eviction strategies, re-decryption)? What about optimization? Would you really add a shader optimizer on the GPU instead of the drivers? (Optimization would have to come *after* decryption!) What if a key or a pool of keys is compromised?

Myself, I'd be happy with regular binary blobs and some fast VRAM dedicated to multisampled framebuffers.

Quote:
And yeah, there's more to the graphics industry than games. But most of this also applies to future cutting-edge games.


Yet cutting-edge games seem content to ship text-based shaders. Doom 3, Oblivion, Crysis...

I'd argue it's not such a big issue for games, simply because your competitor has already lost if he needs to copy your shaders (he will ship after you and fall behind the curve). If anything, moddable shaders add longevity - Doom and Oblivion have had their shaders modded to hell and back and the modders are still going strong.

Anyone knows how Unreal-based games ship their shaders (text or binaries)?

Edit: spelling dammit!

[Edited by - Fiddler on September 18, 2009 2:43:25 AM]
0

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  
Followers 0