Intercepting the Interceptor

Originally posted by def:
What about “my program does curved relief mapping with correct silhouettes and self occlusion and it does it real fast.” or “my program does a really cool effect nobody has seen before” ?

In this case:
1. Why don’t you patent the algorithm and secure your intellectual rights on it?
2. It is your primary duty to write a paper on it and give this agorithm to the masses.

EDIT: realy, we need a general discussion forum :slight_smile:

Originally posted by def:
What about “my program does curved relief mapping with correct silhouettes and self occlusion and it does it real fast.” or “my program does a really cool effect nobody has seen before” ?
In this case you have two options:

  1. Release the algorithm to a wide audience and perhaps get some credz for having invented it (or at least published it) first.

  2. Do nothing and wait a couple of weeks or days until everyone else has figured out how to do it themselves in which case it will soon be forgotten that you were first (assuming you came up with a way to protect your code).

I’d also like to quote John Carmack:

“Programming is not a zero-sum game. Teaching something to a fellow programmer doesn’t take it away from you. I’m happy to share what I can, because I’m in it for the love of programming.”

/A.B.

Programming is not a zero-sum game. Teaching something to a fellow programmer doesn’t take it away from you. I’m happy to share what I can, because I’m in it for the love of programming.
that’s beautiful. although i do believe that i said it first.

So many money are used by big compagny to protect their hardware and software. And all their protection are cracked few days or weeks after the release. It seems to be really a waste of time and money.

Well, you could obfuscate you shader source code. Just write a tool that renames everything in a weird way. :wink: Or google for obfuscaters;

Although it won’t help that much, because shaders are currently small and not very complex

Originally posted by gator:
What are some simple checks I can do to verify if openg32.dll is truly opengl32.dll,
so my calls to GL do not get intercepted? I don’t need to hear ‘you can’t do anything about it’
or ‘just live with it’ responses, just some answers. If there’s some function or
method I can call that would make an intercepting openg32.dll crash or choke, then
I would be interested in knowing about it.

To answer your question - there is no way you can stop it. Even if you delete rogue opengl32.dll, and you make sure that you load the right opengl32.dll with a checksum - it is still possible and very easy to inject another dll into your app after it has loaded the real opengl32.dll. That’s exactly what most api-spy tools on www.sysinternals.com do.

Since dll’s are dynamically loaded and bound to later, anybody can come along and intercept your calls.

I don’t really believe in deleting files on a user’s system, but I do not see why people are flaming this person for wanting to protect his code from prying eyes. Not everyone wants to open source their applications. And just because people think that the application will be hacked a couple of days/weeks after it is released or that it is nothing completely new and innovating is no reason NOT to try and protect it. If you bought a brand new 2006 corvete would you leave it unlocked with no security alarm just because it could be stolen even if it were locked and had an alarm? No, I don’t think you would. So don’t flame someone for trying to protect their code. If you are flaming someone for trying to protect their code, it makes me wonder if you are not the person who is trying to hack it.

You know, I visit some political forums and it’s about that bad :slight_smile:

Your comparision(Corvet to application) is inadequate. Protecting the code does have a reasonable limit :slight_smile:

If I wanted to steal an algorithm out of an application, I would use a debugger. This is a lot easier than digging through GLintercept logs because I get context information like calls, loops, variable contents and so on instead of just a random stream of commands… The output of a GL interceptor only really makes sense if you already know what the application is doing…

And for protecting data: I don’t even need a debugger to get your shaders. You have to store them somewhere, I just have to decode your file format… And if it’s encrypted, I just have to run your loading code in a debugger and look at the memory dump…

So it really doesn’t matter how hard you try to disable a GL interceptor, it doesn’t affect me at all, it doesn’t even make it harder for me to steal your code. And disabling a debugger is not possible, because I can always instruct the debugger to skip the code that checks for a running debugger…

That’s why the comparison with the corvette is not valid, locking it makes it at least harder to steal it :smiley:

I think the people who are flaming don’t want to discuss OpenGL security, whether good or bad.
Maybe they think the subject is taboo. Call the mods! Lock this thread down! Really, nothing
to see here. Just move along now. :slight_smile:

I’m sorry that you feel offended. I really didn’t intend to offend you or anyone else in this thread. I just stated some facts in support of my original argument that it’s not worth trying to protect your code. Like most of the posters here did.

Noone in here thinks the subject is taboo. Some people (myself included) just think it’s pointless. It doesn’t matter to me if protecting your data is morally bad, against the open source idea, supporting terrorism, causing the universe to collapse, whatever :wink: . I’m just telling you that stopping GL interceptors is not going to protect your data.

As for the single flame post (and I really find only one, except “flame the flamer” posts :wink: ), ok, that happens, everyone has a bad day sometimes… That doesn’t mean this whole thread is a single flame war, most of the posts in here are constructive answers, some directly related to the topic, some about protecting your data in general.

Anyway, back to topic: You got some answers how you can make it harder to intercept. IMHO your best chance is to dynamically load the DLL with full path. You were also told that there may be problems with these methods. And you were told that it is impossible to really protect your code/data against someone who really wants it, and you have to ‘just live with it’. I know it’s not what you wanted to hear, but it’s the truth…

gator, the problem is that OpenGL doesn’t have any security measures. The simplest way would be to use some sort of sertificates. Butt all security improvements must be supported at least from two sides: the opengl driver and the aplication. That makes your reges very complicated. If I may sum up everything said above: no, there semms to be no reasonable way of protecting your opengl application.

The Win32 call: GetSystemDirectory may help somewhat (assuming you’re manuall loading the DLL). At the very least it requires inconveniencing the interceptor somewhat since they have to play around in system directories rather than application directories. You may want to compute some hash/check the size of the OpenGL32.dll file against known MS versions that you chose to support. Obviously, there are not many of these so maybe it is enough. You could also obfuscate your shader code.

In the end, though, this is about as far as I would take. In fact, this method is already defeatable because someone eventually will probably make an ICD interceptor (heck, I might). If you think about the problem from a security perspective: it is hard (and probably impossible) to achieve security if the attacker and client are the same party, especially since the underlying OS is not a trusted third party between your app and shared library code.

Come to think of it, you could probably hook into the application address space and redirect all the function calls to be whatever implementation the attacker wanted. Or, you could just use a debugger, because your shader has to be plaintext eventually…

-Won

Originally posted by gator:
I think the people who are flaming don’t want to discuss OpenGL security, whether good or bad.
Maybe they think the subject is taboo. Call the mods! Lock this thread down! Really, nothing
to see here. Just move along now. :slight_smile:

GL security can be a pretty important issue. For example, there are countless hacks used in games like Counter-Strike. Valve has released their VAC system and soon, VAC2.

OK, I hereby officially withdraw “Mod. please deal with gator as you see fit.” from my previous post in this thread (so we can put that issue aside). Nothing else, though.

gator, you should probably have asked what you wanted to know - which seems to be “how can I protect e.g. my shaders from prying eyes”.

You can’t. It’s impossible. It’s the tradeoff made when designing the interface, and choosing between compiled and hard-coded per/vendor, or an open and vendor-neutral thing.

I suggest that if anyone is truly as worried about having their shaders illegally copied by someone else as gator seems to be, they shouldn’t be doing this in the first place. We (most of us on this board anyway, and even market leaders!) do this because we have a love for it. We like to share. It’s what makes us find new interesting approaches to stuff to do even more interesting stuff from. “Standing on the sholders of giants”, anyone?

I can also see it from your paranoid viewpoint, gator, but if you haven’t yet realized it’s futile you have to put some more years into your development history. Not ONE copy restriction system has worked for more than a few months. As such, it’s basically futile to try to make it so. If you really wanted to screw up OpenGL you could try asking ARB members for challenge/response encrypted uploads of shaders. But that wouldn’t do you any good either. Why not? MESA3D would STILL have to be able to read them.

Iff you consider MESA3D invalid, you could try to enumerate all MS opengl32.dll’s and store information about them. Checksums, VERSIONINFO, and $(DIETY) knows what. But in the end, if you don’t like the game - don’t play it!

I will however repeat what I pointed out, only this time more like I intended it: If you ever write software that somehow gets its way onto any of my systems and you intentionally crash or (heavens forbid you even try to) delete one of MY files, I think you too realize what the legal definitions will be of your crimes.

I suggest that if anyone is truly as worried about having their shaders illegally copied by someone else as gator seems to be, they shouldn’t be doing this in the first place.
I don’t buy that. I, for one, believe that if you come up with something, it is your choice whether to dissiminate it or horde it to profit from. And neither choice is right or wrong. However, I also believe that, once you release the algorithm or whatever on the world in some form (be it a white paper or a finished executable), it is fair game for others to figure out how it works and use it themselves. You’re not obligated to help them, but you’re not going to be able to stop them either.

If the person who thought up perspective bump mapping decided to keep the algorithm secret, that’s perfectly acceptable. But he would have no right to complain if someone decompiled it from a demo of the technique that he released.

If you want to protect shaders, then encrypt them, and then dynamically decrypt them on the fly. This will keep most users away.

Trying to hunt for intercept routines itself is a full time job. You can basically do what they do, and then point back to the original. They can still win out though, since there are many ways to fool your detection program.

As was mentioned, if you think the shaders are so valuable, then patent them. I am sure they will grant you a patent no matter what you submit…at least that is the trend these days it seems. ::sigh::