Protecting shader code?
Author
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.
A bit off topic, but why exactly are you concerned about other people seeing your shader code?
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.
Author
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.
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.
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.
ARB_vp and ARB_fp are ancient extensions and that is not going to protect your code.
Author
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.
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.
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.
Meanwhile, CryTek put their advanced shaders' sources and data in a .zip file with no protection whatsoever.
Quote:Original post by Andrew LucasYou 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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
