You could obfuscate and minify your shader: https://github.com/laurentlb/Shader_Minifier
Or hire a demoscene person to mangle it. ;) On Thu, Jan 31, 2019 at 11:43 AM Werner Modenbach <tex...@modenbach-ac.de> wrote: > Hi Michael and all other people responding to my request, > > first of all thank you very much! > > @Michael: What you suggest is something like asking Zuckerberg to > publish his algorithms. > And belief me, Chinese don't care at all about patents > or other rules we usually accept here. > > I'm really surprised that there is no real solution for my problem. > Since OpenGL 4 all developers are advised to create their own shaders. > And once you get familiar > with that you quickly discover the potential of it. A good portion of > your know how gets transferred to shaders. > This should be a common problem in the commercial field. And no solution > from NVIDIA etc. ? > > @Robert: Thanks for pointing me to SPIR-V. I'll have a look at it. > Anyway better than pure source code. > Unfortunately not natively supported by OSG. > > Hiding shader source code inside an executable is not that problem > because all our executables are encrypted. > And memory spy during runtime is detected already. > The problem here is the driver api. > > @Damian: Do you have any links for detecting OpenGL/GPU debuggers? > > Many, many thanks to everybody. > > - Werner - > > Am 31.01.2019 um 10:29 schrieb michael kapelko: > > Hi. > > > > You may have a look at the problem from a different angle. If someone > > is stealing from you that means they need it. If you cannot stop it > > (or it costs much more than simply let them have it), then you should > > lead it. Instead of hiding your great shaders you can publish them > > yourself (don't forget to add some notes about your company in the > > comments)! This would be the marketing way of handling the problem. > > > > On Thu, 31 Jan 2019 at 12:17, Damian Dixon <damian.di...@gmail.com> > wrote: > >> Hi, > >> > >> I don't know what the OSG solution to this would be. > >> > >> You could obfuscate the shader code. Though to be honest this would > only slow someone down not stop them from obtaining the shader source. > >> > >> 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. > >> > >> You could add additional logic to detect OpenGL/GPU debuggers and/or > check the OpenGL shared library is loaded from sensible locations. > >> > >> 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. > >> > >> https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_gl_spirv.txt > (OpenGL 4.6) > >> > https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glShaderBinary.xhtml > (OpenGL 4.1) > >> > >> 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. > >> > >> The shader binary I believe may be limited to the GPU/driver that it > was compiled for. > >> > >> Also OSG would need to be modified to use SPIRV or shader binaries. > >> > >> Most of this is a trade off between cost of implementation, additional > test and support costs and lost revenue. > >> > >> Regards > >> Damian > >> > >> > >> > >> > >> On Wed, 30 Jan 2019 at 17:50, Werner Modenbach <tex...@modenbach-ac.de> > wrote: > >>> Dear Robert, dear community, > >>> > >>> I use OSG since many years now with great success. But being honest I > >>> usually just use the osg api and direct gl calls are very rare in our > code. > >>> That's the reason why I ask people with more gl experience here. > >>> I'm working in a commercial environment. Unfortunately we have very bad > >>> experience about the security of our developments > >>> especially with a famous Asian country. Cracking and copying is the > >>> normal case there. > >>> During the years we have established a quite secure environment for our > >>> executables by encrypting the them and by detecting > >>> debugging and sniffing tools running in parallel. > >>> There is mainly one really weak part, the shaders we develop. > >>> We spent years now in very complex and highly optimized shaders and I > >>> have sleepless nights knowing that the shader code is > >>> transferred to the driver as plain source code. > >>> My question: Is there any way solving this problem? Is there any driver > >>> api for that? I searched all over OSG but didn't find anything. > >>> Is this feature missing in general or is it just not in the OSG api? > >>> If all the questions are answered NO can anybody provide a contact to > >>> NVIDIA for discussing this problem? > >>> > >>> Many thanks in advance for any hints and help. > >>> > >>> - Werner - > >>> > >>> > >>> _______________________________________________ > >>> osg-users mailing list > >>> osg-users@lists.openscenegraph.org > >>> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >> _______________________________________________ > >> osg-users mailing list > >> osg-users@lists.openscenegraph.org > >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > _______________________________________________ > > osg-users mailing list > > osg-users@lists.openscenegraph.org > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775) 623-PIXL [7495]
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
