Sign in to follow this  
exorcist_bob

how to implement security to my engine

Recommended Posts

Hello, I'm just wondering how I can add security to my engine. In other words, I don't want someone just opening my engine and seeing all of the functions that are being exported. I believe that if I opened a commercial engine with a dissassembler (not saying that I did), there would be only a few exports, probably Create* methods. So, I'm wondering how they do it. My best guess is that they used COM objects, but since I want this to be cross platform, that is out of the question. Thanks for your help, exorcist_bob

Share this post


Link to post
Share on other sites
So, something like this:


Engine* __declspec(dllexport) CreateEngine()
{
return new Engine;
};


Will this work? If so, I didn't think it would be this simple, it never is [smile];

[Edited by - exorcist_bob on July 21, 2006 6:37:57 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by exorcist_bob
Hello,

I'm just wondering how I can add security to my engine. In other words, I don't want someone just opening my engine and seeing all of the functions that are being exported. I believe that if I opened a commercial engine with a dissassembler (not saying that I did), there would be only a few exports, probably Create* methods. So, I'm wondering how they do it. My best guess is that they used COM objects, but since I want this to be cross platform, that is out of the question.

Thanks for your help,
exorcist_bob


Use a packer. An exe packer focusses on re-arranging an exe such that it really doesn't make sense to the human eye. A very common test for a good packer is.
1) DOwnload a virus/trojan
2) Pack it using a packer
3) Test if it passes an antivirus

Share this post


Link to post
Share on other sites
Quote:
Original post by dawidjoubert
Use a packer. An exe packer focusses on re-arranging an exe such that it really doesn't make sense to the human eye. A very common test for a good packer is.
1) DOwnload a virus/trojan
2) Pack it using a packer
3) Test if it passes an antivirus


Wow, what a great idea, go download a virus! [rolleyes]

Trying to 'protect' your compiled code like this is literally impossible. The compiled code has to exist in memory in its 'normal' form at some point in order to be executed by the CPU, meaning that all the information required to access the code MUST already be there. At the very best you'll make getting to it slightly more annoying. Furthermore, if someone doesn't have the technical knowledge to copy it out of memory while it's being executed, they won't be able to make sense of the output of a disassembler either. So not only is what your wanting to do impossible, it's pointless.

Oh, and if you just want to prevent other people from calling into your DLL the same applies. *anything* you do to the DLL itself will be totally pointless, since other programs call into the DLL after it's been loaded (ie. it's already been decompressed/unencrypted/whatever). There are approaches you could take in your API (eg, every call requires a 'digital signature' as a parameter that is verified against the calling process within the DLL), but none of them would even be remotely worth the effort.

Share this post


Link to post
Share on other sites
Quote:
Original post by joanusdmentia
*anything* you do to the DLL itself will be totally pointless, since other programs call into the DLL after it's been loaded (ie. it's already been decompressed/unencrypted/whatever). There are approaches you could take in your API (eg, every call requires a 'digital signature' as a parameter that is verified against the calling process within the DLL), but none of them would even be remotely worth the effort.


Hmm....I disagree. There ARE security approaches that work/are worth the effort. At the very least, its a worthy exercise. But exorcist_bob, you have to stop thinking in such narrow terms. You talked about changing the exported functions, but in reality thats just a superficial change. If you are serious about protection, have a go at writing your own packer. It won't really help, but you'll learn a lot.

Share this post


Link to post
Share on other sites
Quote:
Original post by DaBookshah
Hmm....I disagree. There ARE security approaches that work/are worth the effort. At the very least, its a worthy exercise. But exorcist_bob, you have to stop thinking in such narrow terms. You talked about changing the exported functions, but in reality thats just a superficial change. If you are serious about protection, have a go at writing your own packer. It won't really help, but you'll learn a lot.


By 'not worth the effort' I mean't for exorcist_bob's engine, not in general.

Quote:
Original post by exorcist_bob
I believe that if I opened a commercial engine with a dissassembler (not saying that I did), there would be only a few exports, probably Create* methods.


I just took a look at engine.dll from UT2004 with the wonderful dependency walker tool, 8190 exported symbols.

Share this post


Link to post
Share on other sites
Quote:
Original post by joanusdmentia
Quote:
Original post by DaBookshah
Hmm....I disagree. There ARE security approaches that work/are worth the effort. At the very least, its a worthy exercise. But exorcist_bob, you have to stop thinking in such narrow terms. You talked about changing the exported functions, but in reality thats just a superficial change. If you are serious about protection, have a go at writing your own packer. It won't really help, but you'll learn a lot.


By 'not worth the effort' I mean't for exorcist_bob's engine, not in general.

Quote:
Original post by exorcist_bob
I believe that if I opened a commercial engine with a dissassembler (not saying that I did), there would be only a few exports, probably Create* methods.


I just took a look at engine.dll from UT2004 with the wonderful dependency walker tool, 8190 exported symbols.


Really? Well, if that's the case, then I won't bother. Thanks a lot!

Share this post


Link to post
Share on other sites
Quote:
Original post by DaBookshah
Quote:
Original post by joanusdmentia
*anything* you do to the DLL itself will be totally pointless, since other programs call into the DLL after it's been loaded (ie. it's already been decompressed/unencrypted/whatever). There are approaches you could take in your API (eg, every call requires a 'digital signature' as a parameter that is verified against the calling process within the DLL), but none of them would even be remotely worth the effort.


Hmm....I disagree. There ARE security approaches that work/are worth the effort. At the very least, its a worthy exercise. But exorcist_bob, you have to stop thinking in such narrow terms. You talked about changing the exported functions, but in reality thats just a superficial change. If you are serious about protection, have a go at writing your own packer. It won't really help, but you'll learn a lot.
The only protection mechanism that does anything significant (without specialized DRM hardware that isn't in widespread use) is machine code obfuscation. The effectiveness of such obfuscation is directly proportional to the speed reduction it is allowed to cause. For key-checking code and a little extra to make things difficult, that isn't so bad, but for a game engine, it's a terrible tradeoff since the engine is at the heart of just about every time-critical part of a game.

Anybody that takes the time to disassemble a complete game engine IMO deserves to know whatever they've managed to figure out. A game engine should have quite high levels of design that make a big difference, and figuring that kind of thing out of machine code isn't easy. "Engine.dll" in Unreal Tournament 2004 is ~4.55 MB, which (presuming most of that is code and not data) would basically take more time to reverse engineer than it would take to remake from scratch, and even after reversing that much, you'd be left with very little in the way of design, which is what is most important in 'engines'. You'd be better off to just get somebody hired by the company so they could steal the source code (if you're gonna go into illegal software development, might as well go all the way).

[Edited by - Extrarius on July 23, 2006 1:25:53 AM]

Share this post


Link to post
Share on other sites
You could try exporting by ordinal if your using dlls.

When using MS VC++ compiler you will need to specify a .def file which looks something like this....

mylibrary.def

LIBRARY mylibrary

EXPORTS
functionNameOne @1 NONAME
functionNameTwo @2 NONAME


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this