Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Protecting shader code?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
32 replies to this topic

#1 Andrew Lucas   Members   -  Reputation: 122

Like
0Likes
Like

Posted 15 September 2009 - 05:38 AM

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.

Sponsor:

#2 Rycross   Members   -  Reputation: 580

Like
0Likes
Like

Posted 15 September 2009 - 05:46 AM

A bit off topic, but why exactly are you concerned about other people seeing your shader code?

#3 Marko Dolenc   Members   -  Reputation: 122

Like
0Likes
Like

Posted 15 September 2009 - 05:46 AM

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.

#4 Andrew Lucas   Members   -  Reputation: 122

Like
0Likes
Like

Posted 15 September 2009 - 06:15 AM

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.

#5 V-man   Members   -  Reputation: 805

Like
0Likes
Like

Posted 15 September 2009 - 06:18 AM

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.

#6 Andrew Lucas   Members   -  Reputation: 122

Like
0Likes
Like

Posted 15 September 2009 - 06:36 AM

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.

#7 Drew_Benton   Crossbones+   -  Reputation: 1745

Like
0Likes
Like

Posted 15 September 2009 - 06:39 AM

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.

#8 idinev   Members   -  Reputation: 236

Like
0Likes
Like

Posted 15 September 2009 - 06:39 AM

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.

#9 swiftcoder   Senior Moderators   -  Reputation: 14695

Like
0Likes
Like

Posted 15 September 2009 - 06:46 AM

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.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#10 Trienco   Crossbones+   -  Reputation: 2508

Like
0Likes
Like

Posted 15 September 2009 - 06:06 PM

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.

#11 PlayfulPuppy   Members   -  Reputation: 419

Like
0Likes
Like

Posted 15 September 2009 - 06:27 PM

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'.

#12 Yann L   Moderators   -  Reputation: 1802

Like
0Likes
Like

Posted 15 September 2009 - 11:44 PM

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.

#13 Tomasz Dabrowski   Members   -  Reputation: 127

Like
0Likes
Like

Posted 16 September 2009 - 12:41 AM

Sure, and what next?

This?

glCompileShader(...)
glCompileShader(...)
glLinkProgram(...)
glConnectToDRMServer(...)
glAuthorizeShader(...)



#14 snoutmate   Members   -  Reputation: 343

Like
0Likes
Like

Posted 16 September 2009 - 01:22 AM

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


#15 swiftcoder   Senior Moderators   -  Reputation: 14695

Like
0Likes
Like

Posted 16 September 2009 - 02:12 AM

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.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#16 Yann L   Moderators   -  Reputation: 1802

Like
0Likes
Like

Posted 16 September 2009 - 03:16 AM

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.


#17 Tachikoma   Members   -  Reputation: 552

Like
0Likes
Like

Posted 16 September 2009 - 04:54 AM

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.

#18 zedz   Members   -  Reputation: 291

Like
0Likes
Like

Posted 16 September 2009 - 09:31 AM

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.

#19 swiftcoder   Senior Moderators   -  Reputation: 14695

Like
0Likes
Like

Posted 17 September 2009 - 03:27 AM

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.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#20 Yann L   Moderators   -  Reputation: 1802

Like
0Likes
Like

Posted 17 September 2009 - 05:25 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS