PDA

View Full Version : Intercepting the Interceptor



gator
06-17-2005, 04:49 PM
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.

N64Marin
06-17-2005, 05:04 PM
You may create a library that stores the MD5 checksum of the official OpenGL32.dll. But if the interceptor is an ICD(I haven't seen it yet), It doesn't work. So, library the ICDs(Not practical, as there are large numbers of ICDs).

gator
06-17-2005, 05:33 PM
If my program statically links to opengl32.lib and there's a opengl32.dll in my program's
directory, it is possible to delete that file on program startup, or will it be loaded
(access denied) before my program even gets a chance to run?

gator
06-17-2005, 05:37 PM
So, are you suggesting if I put opengl32.dll in my program's resource, and then extract
to my program's directory when it runs, that would work? Or as I mentioned above, if
I statically bound opengl32.lib to my program, I won't be able to do that?

sqrt[-1]
06-17-2005, 06:52 PM
If you manually load the opengl dll and specify the full path (ie c:\windows\system32\opengl32.dll) it should stop most people. (of course if the above dll is not found, just load "opengl32.dll" as you would not want this to prevent people from running your app)

You could also just check to see if there is a openGL32.dll in the apps exe directory on startup...

Of course all the above is adding extra complexity to your app and some computer configurations may not like you doing this. (some people run with a modified opengl32.dll for special hardwrae - like old cards or special displays)

If course my comments will only solve opengl32.dll replacement (like GLIntercept). Programs that do dll hooking (gDebugger?) will still work...

Brolingstanz
06-17-2005, 07:04 PM
sounds to me like you can't do anything about it...that you should just live with it.

regards,
bonehead

ZbuffeR
06-17-2005, 11:26 PM
specify the full path (ie c:\windows\system32\opengl32.dll) it should stop most people.1) seems pretty weak to me, my dll is on d:\winnt\system32\opengl32.dll


(of course if the above dll is not found, just load "opengl32.dll" as you would not want this to prevent people from running your app)2) so in cases this protection works, it is very easily bypassed by deleting/moving the real opengl32.dll ...

gator
06-18-2005, 08:18 AM
I've experienced problems in the past when dynamically loading opengl32.dll (memory leaks, crashing,
unable to find out why), so that's why I would prefer to statically link the library.

If I call LoadLibrary("opengl32.dll"), is it always guaranteed that it will load the opengl32.dll
that is statically bound to my program? Is there anyway I can use the handle returned by
LoadLibrary() to determine the full filepath to the opengl32.dll file?

Korval
06-18-2005, 10:06 AM
If you aren't willing to dynamically load opengl32.dll, there's nothing that can be done to guarentee that you're not getting the real opengl32.dll. Whether you want to hear that or not, it is the truth.

If you dynamically load it, you have the ability to create opengl32.dll by storing it in your executable as a resource and dumping it to the drive on execution.


If I call LoadLibrary("opengl32.dll"), is it always guaranteed that it will load the opengl32.dll
that is statically bound to my program?If you already linked to opengl32.lib, LoadLibrary calls to the .dll will probably not load anything off the disk; it'll just return a handle to the already loaded .dll.

V-man
06-18-2005, 12:30 PM
If you aren't willing to dynamically load opengl32.dll, there's nothing that can be done to guarentee that you're not getting the real opengl32.dll. Whether you want to hear that or not, it is the truth. I was researching about a topic that relates to this. There is a technique that can be used to intercept your calls to a dll even if you dynamically link.

Perhaps the foolproof method is to have a static lib, but in the case of GL, it needs to link up with the driver. If someone really wanted to, they could hack the IHV GL driver.

Overmind
06-19-2005, 03:24 AM
Even if it was possible to get around an interception library, there are much easier ways to get your data. It's not that hard to reverse engineer a custom file format, especially if you're only interested in reading...

tamlin
06-19-2005, 06:37 AM
Besides the obvious that Overmind pointed out, I'd like to draw peoples attention to what gator requested:

that would make an intercepting openg32.dll crash
and
it is possible to delete that file on program startup ("it is" => "is it" and that file being any opengl32.dll).

I have seen blatant request for viruses, but never seen such an expressed attempt at destroying users systems, or delete their files from their own systems.

Mod. please deal with gator as you see fit.

def
06-20-2005, 07:07 AM
Originally posted by tamlin:
I have seen blatant request for viruses, but never seen such an expressed attempt at destroying users systems, or delete their files from their own systems.

Mod. please deal with gator as you see fit.Please calm down here tamlin. I am sure the only intention by gator is to protect his source code (shaders etc.) by trying to block any "debugging" via the opengl32.dll.

Zengar
06-20-2005, 07:53 AM
I'm asking myself what is he programming if his code is so valuable :)

back to topic: the only way I can imagine of is to debug/trace your opengl library, you could for example check if your calls are linked to any other apps. But remember, any security measures always end in system crash as they are not flexible. Settlers 3 wouldn't start on XP because it was shure my system was infected by virus :)

dorbie
06-20-2005, 11:38 AM
Don't mess with system files, if you insist on doing this then ship a renamed local copy or load from the system dir explicitly, as has been suggested, perhaps with checksums (you risk creating a serious support problem in the process).

The entire system is inherently dynamic, all drivers implement a standard ABI (actually that's in the OpenGL32.dll so it's cast in stone by Microsoft) that is exported via the ICD mechanism and OpenGL32.dll, so you could ensure you call a dll you've shipped, that's not a guarantee you'll never be intercepted. The best you can do is to make this more difficult for the casual dll wrapping interceptor, but why spoil the fun, really your code ain't that special, if you think it is you need a reality check.

Do not touch the system files, you have no right to do that. If you need to ask the question you have no business screwing around in system32, and if you didn't need to ask you'd know you have no business screwing around in there.

So in summary, the best option is to ship a copy of the dll locally (it hasn't changed in years), rename it and load it explicitly after a checksum, and you risk compatability and support problems.

If anyone thinks there is a problem with this please chime in, because I'm by no means sure that this is generally going to be problem free without testing it.

P.S. In general this is bad practice, you create a dependency that wasn't there before. Basically legitimate changes to the Operating System and system drivers even if they maintain backwards compatability with correctly written software could break your code and is exactly the kind of bad engineering hack that holds systems back. Your crap code could break your application and people will blame the OS.

Zengar
06-20-2005, 03:09 PM
P.S. In general this is bad practice, you create a dependency that wasn't there before. Basically legitimate changes to the Operating System and system drivers even if they maintain backwards compatability with correctly written software could break your code and is exactly the kind of bad engineering hack that holds systems back. Your crap code could break your application and people will blame the OS.[/QB]Holy words! Really, Windows programmers tend to be less disciplined then Unix ones... maybe it's because they get it so easy... But dorbie is right, most of the legends "crappy windows" is caused by badly written software... Ok, this doen't excuse the missing security options of the OS :)

gator
06-21-2005, 12:12 PM
tamlin, you're way off base. Nobody mentioned deleting system files until you brought it up.
Mod tamlin down for being a pest. :)

Korval
06-21-2005, 03:13 PM
There is a technique that can be used to intercept your calls to a dll even if you dynamically link.Oh, you misunderstand. I didn't mean to suggest that dynamic loading made everything safe and secure either. God knows there's at least 2 ways to get around the mechanism I suggested: hack the executable, and install your driver as an ICD that calls the real driver.

There's pretty much nothing that can be done to guarentee security for your stuff, whether it is OpenGL or D3D. Professional developers willingly accept that there's going to be a lack of security about their shaders, rendering techniques, etc. If it's good enough for them, it should be good enough for you.

SirKnight
06-21-2005, 09:19 PM
Originally posted by gator:
tamlin, you're way off base. Nobody mentioned deleting system files until you brought it up. Huh? Tamlin pointed out that YOU asked if deleting files by your program was a good idea.

If your program & shaders & whatever is so valuable, then why release it to the public in the first place? I could understand if this was a part of a government's top secret project, otherwise who cares? If it's to protect shaders I really do not see what is so alarming in protecting them in the first place. If you say, "my program does tangent space bump mapping, pixel shaded water effects, etc etc" everyone (as in gfx programmers) already know how those shaders work and more then likely have shaders of their own that do the very same thing. Plus most, if not all, effects and algorithms that can run in shaders are already freely available all over the net, some come with tutorials or papers. Trying to protect shaders is kind of silly. You didn't see John Carmack getting his panties in a wad when people started to modify the interaction shader program (in doom 3) for better performance/quality or add new rendering techniques.

EDIT: Forgot to mention 'doom 3'. :)

-SirKnight

def
06-21-2005, 11:07 PM
Originally posted by SirKnight:
If your program & shaders & whatever is so valuable, then why release it to the public in the first place? That's the whole point! Maybe gator does not want to "release" his shader code but only the executable. Not everybody wants to publish the C++ code to their applications, this is basically the same thing. I think it's a reasonable thing to think about.


If you say, "my program does tangent space bump mapping, pixel shaded water effects, etc etc" everyone (as in gfx programmers) already know how those shaders work and more then likely have shaders of their own that do the very same thing.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" ?

Plus most, if not all, effects and algorithms that can run in shaders are already freely available all over the net, some come with tutorials or papers.But those are just the ones you know about! :)
I think there is still alot potential in hardware shader technology to be discovered and invented...

Zengar
06-22-2005, 01:36 AM
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 :)

brinck
06-22-2005, 09:04 AM
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.

Brolingstanz
06-22-2005, 01:26 PM
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.

mornifle
06-22-2005, 02:34 PM
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.

ScottManDeath
06-22-2005, 05:54 PM
Well, you could obfuscate you shader source code. Just write a tool that renames everything in a weird way. ;) Or google for obfuscaters;

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

fresh
06-22-2005, 07:18 PM
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 (http://www.sysinternals.com) do.

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

Rectless
06-23-2005, 06:19 AM
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.

Zengar
06-23-2005, 06:59 AM
You know, I visit some political forums and it's about that bad :)

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

Overmind
06-23-2005, 12:48 PM
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 :D

gator
06-23-2005, 11:26 PM
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. :)

Overmind
06-24-2005, 12:38 AM
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 ;) . 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 ;) ), 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...

Zengar
06-24-2005, 04:44 AM
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.

Won
06-24-2005, 12:36 PM
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

V-man
06-25-2005, 08:24 AM
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. :) 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.

tamlin
06-25-2005, 10:17 AM
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.

Korval
06-25-2005, 01:57 PM
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.

Elixer
06-27-2005, 08:50 AM
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::