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

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.

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.

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]