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.
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).
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?
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?
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…
sounds to me like you can’t do anything about it…that you should just live with it.
regards,
bonehead
specify the full path (ie c:\windows\system32\opengl32.dll) it should stop most people.
- 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)
- so in cases this protection works, it is very easily bypassed by deleting/moving the real opengl32.dll …
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?
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.
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.
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…
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.
Originally posted by tamlin:
[b]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.[/b]
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.
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
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.
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
tamlin, you’re way off base. Nobody mentioned deleting system files until you brought it up.
Mod tamlin down for being a pest.
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.
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
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…