<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Hi,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I don't know what the OSG solution to this would be.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">You could obfuscate the shader code. Though to be honest this would only slow someone down not stop them from obtaining the shader source.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">In addition to obfusication put the shader source into the DLL/exe and potentially hide the strings by a simple rotation or masking of the data.<br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div style="font-family:trebuchet ms,sans-serif" class="gmail_default">You could add additional logic to detect OpenGL/GPU debuggers and/or check the OpenGL shared library is loaded from sensible locations.<br></div><div style="font-family:trebuchet ms,sans-serif" class="gmail_default"><br></div><div style="font-family:trebuchet ms,sans-serif" class="gmail_default">The other options would be to look at the following in OpenGL. I've not used either of them so they may not work particularly well.<br></div><ul><li><a href="https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt">https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt</a><span class="gmail_default" style="font-family:trebuchet ms,sans-serif"> (OpenGL 4.6)</span></li><li><span class="gmail_default" style="font-family:trebuchet ms,sans-serif"><a href="https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glShaderBinary.xhtml">https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glShaderBinary.xhtml</a> (OpenGL 4.1)</span><br></li></ul><span class="gmail_default" style="font-family:trebuchet ms,sans-serif">You may find that the SPIRV extension is not widely supported yet on all GPUs and drivers (mesa support is not yet there) that your customers are using. SPIRV modules are an intermediate compiled representation of the shaders so someone with a lot of time could reverse engineer. <br></span></div><div dir="ltr"><span class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:trebuchet ms,sans-serif">The shader binary I believe may be limited to the GPU/driver that it was compiled for.</span><br></div><div dir="ltr"><span class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:trebuchet ms,sans-serif"></span><span class="gmail_default" style="font-family:trebuchet ms,sans-serif">Also OSG would need to be modified to use SPIRV or shader binaries.</span></div><div><span class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:trebuchet ms,sans-serif">Most of this is a trade off between cost of implementation, additional test and support costs and lost revenue.<br></span></div><div><span class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></span></div><div><span class="gmail_default" style="font-family:trebuchet ms,sans-serif">Regards</span></div><div><span class="gmail_default" style="font-family:trebuchet ms,sans-serif">Damian</span><br></div><div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 30 Jan 2019 at 17:50, Werner Modenbach <<a href="mailto:texion@modenbach-ac.de">texion@modenbach-ac.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Robert, dear community,<br>
<br>
I use OSG since many years now with great success. But being honest I<br>
usually just use the osg api and direct gl calls are very rare in our code.<br>
That's the reason why I ask people with more gl experience here.<br>
I'm working in a commercial environment. Unfortunately we have very bad<br>
experience about the security of our developments<br>
especially with a famous Asian country. Cracking and copying is the<br>
normal case there.<br>
During the years we have established a quite secure environment for our<br>
executables by encrypting the them and by detecting<br>
debugging and sniffing tools running in parallel.<br>
There is mainly one really weak part, the shaders we develop.<br>
We spent years now in very complex and highly optimized shaders and I<br>
have sleepless nights knowing that the shader code is<br>
transferred to the driver as plain source code.<br>
My question: Is there any way solving this problem? Is there any driver<br>
api for that? I searched all over OSG but didn't find anything.<br>
Is this feature missing in general or is it just not in the OSG api?<br>
If all the questions are answered NO can anybody provide a contact to<br>
NVIDIA for discussing this problem?<br>
<br>
Many thanks in advance for any hints and help.<br>
<br>
- Werner -<br>
<br>
<br>
_______________________________________________<br>
osg-users mailing list<br>
<a href="mailto:osg-users@lists.openscenegraph.org" target="_blank">osg-users@lists.openscenegraph.org</a><br>
<a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" rel="noreferrer" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</blockquote></div>