PDA

View Full Version : Prevention of OpenGL pipeline stream hooking



SemiPr0
07-12-2009, 07:02 AM
OpenGL has been in industry use now for quite a long time and is a common cross platform standard for rendering.

But a problem I'm having with it is the rather easy ability for people to use debugging tools like GLIntercept to intercept the GL pipeline stream and inject or export project common resources.

I'm aware that DirectX does have the ability to block stream hooking at the programming level, basically not allowing stream injection of resources or exportation of resources from DX environment.

But I've been looking through the documentation available in OpenGL and I'm wondering if there is a way to do this, with OpenGL, in real time, to prevent unauthorized use of tools like GLIntercept.

Is anyone aware of any potential methods of prevention?

Ilian Dinev
07-12-2009, 07:29 AM
Yes, look at the first 5 bytes of every proc in OpenGL32.dll . They get modified to a relative jump. If the 5 bytes are not the expected ones, it's hooked.
That is, after you've verified the module's filename is in the expected system dir.

_NK47
07-14-2009, 01:53 AM
There are Direct3D tools to export anything as well not thats is OpenGL only. You could check the checksum (CRC32) of the system/OpenGL32.dll or the file size depending on the platform. GLintercept has afaik 888Kb whereas OpenGL32.dll (WinXP) has 600something. Beware your app can be cracked or disassembled anyways to remove the checks.

awhig
07-14-2009, 07:43 PM
That is very informative _NK47 and Ilian Dev.

@SemiPr0:
But if hooking is prevented then how a user is going to check where he is going wrong?

awhig
07-14-2009, 07:45 PM
Can you explain me what do you mean when you say:


They get modified to a relative jump


Does "jump" refer to the address provided by GLIntercept? If so when and how does this address come ?

Ilian Dinev
07-15-2009, 04:36 AM
glintercept was just providing a replacement dll in the local folder, iirc.
Windows dll-hooking is what overwrites the first 5 bytes of a 32-bit func.