OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

Question about security of shader developments


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message
Werner Modenbach
Guest





PostPosted: Wed Jan 30, 2019 5:50 pm    Post subject:
Question about security of shader developments
Reply with quote

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 -




------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12348

PostPosted: Wed Jan 30, 2019 5:59 pm    Post subject:
Question about security of shader developments
Reply with quote

Hi Werner,

You can compile shaders into source, the osgText, osgVolume and
osgParticle NodeKits all have local shaders directories i.e
src/osgText/shaders. The .cpp files found in these shaders directory
are generated from shaders found in OpenSceneGraph-Data/shaders, and
converted to ,cpp's using osg2cpp example i.e.

osg2cpp --shader myshader.vert

Beyond this you are a bit stick with OpenGL unless you've come across
an extension for using SPIR-V shaders, even these can be decompiled.

Cheers,
Robert.


------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Damian Dixon
Guest





PostPosted: Thu Jan 31, 2019 9:18 am    Post subject:
Question about security of shader developments
Reply with quote

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.

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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:

Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


------------------
Post generated by Mail2Forum
Back to top
kornerr
Appreciator


Joined: 01 Oct 2013
Posts: 309

PostPosted: Thu Jan 31, 2019 9:30 am    Post subject:
Question about security of shader developments
Reply with quote

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 <> wrote:
Quote:

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 <> wrote:
Quote:

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 -







------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Werner Modenbach
Guest





PostPosted: Thu Jan 31, 2019 10:44 am    Post subject:
Question about security of shader developments
Reply with quote

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:
Quote:
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 <> wrote:
Quote:
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 <> wrote:
Quote:
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 -









------------------
Post generated by Mail2Forum
Back to top
Chris Hanson
Guest





PostPosted: Thu Jan 31, 2019 11:37 am    Post subject:
Question about security of shader developments
Reply with quote

You could obfuscate and minify your shader:

https://github.com/laurentlb/Shader_Minifier 

Or hire a demoscene person to mangle it. Wink



On Thu, Jan 31, 2019 at 11:43 AM Werner Modenbach < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:

Quote:
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:
Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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 < (
Only registered users can see emails on this board!
Get registred or enter the forums!
)> wrote:
Quote:
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
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


_______________________________________________
osg-users mailing list
(
Only registered users can see emails on this board!
Get registred or enter the forums!
)
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



--
Chris 'Xenon' Hanson, omo sanza lettere. 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 facebook.com/alphapixel (775) 623-PIXL [7495]

------------------
Post generated by Mail2Forum
Back to top
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts I have a question about the shading p... newlife958 General 0 Thu Oct 10, 2019 7:12 am View latest post
No new posts Image from shader lucasamparo General 14 Thu Oct 03, 2019 5:46 pm View latest post
No new posts Question about idle event handling in... ollydbg General 0 Thu Oct 03, 2019 9:41 am View latest post
No new posts [OSG 3.6.3 Core Profile GL 3+] Weird ... johansson_gbg General 2 Thu Sep 12, 2019 1:17 pm View latest post
No new posts Layered rendering with a geometry shader AnyOldName3 General 8 Tue May 14, 2019 11:25 pm View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP