Can you password protect a dll?

Is it possible to password protect a dll at compiletime.

Please excuse my noobness, but let me explain what I mean.

You app an runtine makes a lot of calls to a function in a library so it opens it and keeps it open for the duration your app is running.

Is it possible to have the dll password protected upon opening, and then the subsiquent function calls are unhindered.

I have never compiled a dll before and Im aware that my question might be a silly one.

Thanks for reading.

Interesting question. I can think of a few answers, but they're probably workarounds. I'm not a security expert by any means or even competent at security. But what the hell. I'll throw them out and get rightfully tagged a "noob" myself. How secure are we talking? Are we talking Nation Security Agency or are we talking keeping your little brother from accessing your diary?

From an OPERATING SYSTEM/user level point of view, I can think of at least one way.

1. a.dll is the dll you need.
2. b is a daemon running in the background with authority to change permissions of a.dll or at least give you a copy that you can use.
3. c is the program you are running that needs a.dll. User running c doesn't have permissions to a.dll (yet).

c contacts daemon b and gives it a password. If the password is accepted, permissions of a.dll are changed by b or you are given a copy that you can use or whatever.

Or a.dll IS a dll you have access to, but it's encrypted. Password decrypts a.dll so it's usable. THEN you load it from c.

From a non-operating system permissions point of view, you either have an initialization password test in c that doesn't allow you to attempt to load a.dll until the password's been checked in the a program. Hence the check is in program c, not in a.dll.

From a password protection point of view on a.dll's side, some sort of initialization function on that end where there's some sort of authentification, either in a newly spawned process or a daemon or shared memory or flag written to a file or whatever. The functions in the dll check whatever they need to check when called and see if you've already authenticated and won't proceed if you haven't. Basically functions like a web cookie sort of

Finally, just have each public function in the dll require a password for every call. That's the easiest to implement, but you stated you didn't want that, so I left it for last.

VernonDozier

Thank you so much for your reply, I really appreciate it.
Its a lot to think about and I'll have to take some time to soak it up (Like I said Im really noob), all my attempts at entering the C++ world have ended in misery, mostly because I cant get my head around strings, and all the different types and structures needed at that level language, so its C# I've started to learn.

My problem is that my son and a few of his friends have made a little application in a scripting language that is no good to anyone except himself and his peers.
The problem starts when a few other kids from somewhere are downloading his app, decompiling it with a simple click of a button (literally one click) changing some simple strings in it to pass the app off as their own.

I know its just kids stuff, but i can tell its really getting to my boy and his friends, that each time they develop their ideas further and add features or improve upon them they are stolen and renamed.

Okay sob story over.

So I was thinking of ways to help him out and make a dll file with some data stored in it essential to the app, and have it called upon from the password protected dll, so local permissions are out I think.

Your other suggestions I'll have to wrap my head around.

Once again thanks for your reply.

EDIT

I know I cannot make a dll in C# but I'm sure I could get my head around a basic dll in C++ (after a while)

I'm not a security expert either, but here is a thought to add to the options already given.

Write a little program that generates a module definition file (.def) for your dll with all the aliases (symbols) of the functions encrypted, so a user app won't be able to load the functions without having some sort of table to translate from meaningful names to their encrypted aliases. Then write another application that can verify the password and decrypt the aliases. This will require you to use dynamic loading (LoadLibrary, GetProcAddress, and so on), but that's usually quite alright. A good hacker would probably break this in a few hours at most, but it's good enough for your typical average joe or lazy programmer.

For the second time today, I've started on a post, lost it, and have to start again. Bummer. Don't have time to recreate the whole thing, but the main points are:

"Script" versus "compiled program" is a big difference. Perl is a "scripting" language. Thus you don't "compile" a script. You execute it directly. Thus if you are writing "scripts" and you want to give someone the executable code, you have to give them the source code, since it's the same thing.

C++ is an entirely different animal. That gets compiled into zeroes and ones. I've never heard of anyone decompiling a C++ program with one click of a button into anything resembling the source code. It's EXTREMELY hard to do. There are some amazing decompilers, but they rarely get you back to the source code, so I'm a bit confused there.

However, I totally understand the desire to share your work and I totally get how annoying it is to have someone else claiming it's theirs.

One solution is to make it web based.

int Add2Numbers(int num1, int num2)
{
    return num1 + num2;
}


int main(int argc, char* argv[])
{
    // read in the arguments from the stdin stream and parse them
    // into num1 and num2

    int sum = Add2Numbers(num1, num2);
    // send back sum in HTML format
    return 0;
}

Have this as a CGI program. Your son would have to learn a little about HTML if he didn't already and he'd need to learn a little about setting up programs to run as CGI and accept arguments, but it's actually not that complicated once you get the hang of it. No one ever ever gets access to any of the C++ code, source or compiled, so they can't see it, but they can run it. No passwords necessary.

But again, decompiling executable C++ code into the source is not a "one click" operation. I've never seen a decompiler that's that good.

Sounds like plugin system?
If so, then make plugin loader/Manager.
All plugins will share interface file, let say plugins.h where variable holding the password is defined. then in all methods of the DLL, check password first and if doesn't match, return some garbage. Else do a process!

void checkPassword(std::string password){
    if(password==myPassword){
            return true;
   }else{
       return false;
   }
}

Sounds like plugin system?
If so, then make plugin loader/Manager.
All plugins will share interface file, let say plugins.h where variable holding the password is defined. then in all methods of the DLL, check password first and if doesn't match, return some garbage. Else do a process!

void checkPassword(std::string password){
    if(password==myPassword){
            return true;
   }else{
       return false;
   }
}

The problem with that is that even a guy like me who is not by any means a professional hacker (never done any hacking at all) could break this protection in a matter of minutes.

The problem with that is that even a guy like me who is not by any means a professional hacker (never done any hacking at all) could break this protection in a matter of minutes.

Break it without reverse engineering? How on earth Mike? :icon_eek:

You disassemble the code, look for the label "checkPassword", look for a comparison operation on the parameter "password", find the memory location of the other compared element "myPassword" and extract the value. Or, find token "checkPassword", replace the comparison operator by a comparison between password and password (always true), and you get that all passwords are valid (that is essentially how most "cracked" software are done, just by replacing the part that authenticates your CD or license by dummy operations that always yield a positive verification).

This is not reverse engineering, just requires very basic knowledge of assembly code and a decent disassembly tool.

You disassemble the code, look for the label "checkPassword", look for a comparison operation on the parameter "password", find the memory location of the other compared element "myPassword" and extract the value. Or, find token "checkPassword", replace the comparison operator by a comparison between password and password (always true), and you get that all passwords are valid (that is essentially how most "cracked" software are done, just by replacing the part that authenticates your CD or license by dummy operations that always yield a positive verification).

This is not reverse engineering, just requires very basic knowledge of assembly code and a decent disassembly tool.

But that is reverse engineering which we cannot avoid. If you need such tough security, then encrypt withh something like AES 128 et al and decrypt the file before using. But there you will have to add library for encryption

You disassemble the code, look for the label "checkPassword"

Provided you know to LOOK for "checkPassword".

look for a comparison operation on the parameter "password", find the memory location of the other compared element "myPassword" and extract the value. Or, find token "checkPassword", replace the comparison operator by a comparison between password and password (always true), and you get that all passwords are valid (that is essentially how most "cracked" software are done, just by replacing the part that authenticates your CD or license by dummy operations that always yield a positive verification).

This is not reverse engineering, just requires very basic knowledge of assembly code and a decent disassembly tool.

I see your point. You don't need to be a genius to do this, I guess. The disassembler does most of it for you. Maybe I was seriously over-stating the task. I've always found it incredibly difficult. Maybe it's just me and I'm really lousy at it or never found a good disassembler. But I still think it's beyond kids doing it with a single click of a button.

How about a nice code obfuscator? Gets all those obvious labels like "password" and "checkPassword" out of there. Under ideal circumstances, one can only disassemble to the obfuscated code. The REAL code can be controlled and released only to the group.

That's assuming that we are in fact dealing with C++ and not a scripting language.

Some superb offerings, and I'm very grateful for them.

I'll just try to clarify.

The scripting language they are using Autoit3 http://www.autoitscript.com/autoit3/index.shtml

It compiles to an interpeted executable (of course containing the source code) and that is what they are decompiling with the simple click.

However that language can call functions from a C++ compiled dll and the initial plan was to hold some of the executables vital data in that dll (passworded if it was possible).

The obfuscation the languge offers is also deobfuscated by the decompiler they have found (specifically for Autoit).

My son and his friends are all around 12/13 and I dont think any of them know C++ or would even think to or know how to get the info from a compiled dll, so perhaps the suggestion about having the dlls functions first check for a password in an argument is a good one, and maybe the easiest option.

I'd like to thank you all for your contributions and advice on this matter.

I'm now off to learn how to compile to dll in C++, maybe it will hook me and i'll give C++ another go.

If I do, my first project will be devising a way to password protect a dll, and I'll be right back here with my master plan :)

Many thanks
Suze.

>> I'm now off to learn how to compile to dll in C++, maybe it will hook me

Assuming you have some version of Visual Studio, you might go through MSDN's Walkthrough: Creating and Using a Dynamic Link Library. It's close to the simplest console app/dll configuration that one can have.

P.S. I think you should not underestimate the cheat team's capability/motivation to hack the protection (due to their young age) - there are lots of resources on internet to aid in just that - in other words, be sure to give this a good go ;)

>> I'm now off to learn how to compile to dll in C++, maybe it will hook me

Assuming you have some version of Visual Studio, you might go through MSDN's Walkthrough: Creating and Using a Dynamic Link Library. It's close to the simplest console app/dll configuration that one can have.

P.S. I think you should not underestimate the cheat team's capability/motivation to hack the protection (due to their young age) - there are lots of resources on internet to aid in just that - in other words, be sure to give this a good go ;)

I have found CodeLite to be easiest IDE I have ever used. Microsoft VS is a way too complex, at least for me but many out there loves its debugging capabilities. CL have projects for DLL for both Linux/Windows.

Long ago I tried learning disassembling. It is worst brain exhauster AFAICS. It is not for faint hearted especially in world of 0234x564AFE

Check this tutorial if it helps.

Thanks, I successfully created a sample dll last night, the walkthrough didnt help as much as I'd hoped (I am using visual studio).

I had to just write the functions like so..

extern "C" int __stdcall ...

and then make a .def file to export them.

But I cobbled one together in the end using a few different snippets found in various places.

Always willing to try a new IDE though, thanks.

Thanks, I successfully created a sample dll last night, the walkthrough didnt help as much as I'd hoped (I am using visual studio).

I had to just write the functions like so..

extern "C" int __stdcall ...

and then make a .def file to export them.

But I cobbled one together in the end using a few different snippets found in various places.

Always willing to try a new IDE though, thanks.

Poor __stdcall ;)
Check __declspec dllexport/dllimport

Also there is good tutorial in links below. Haven't looked through but name looks promising :)
Dlls are Simple. Part 1
Dlls are Simple. Part 2
Dlls are Simple. Part 3
Dlls are Simple. Part 4

But that is reverse engineering which we cannot avoid. If you need such tough security, then encrypt withh something like AES 128 et al and decrypt the file before using. But there you will have to add library for encryption

\

This won't be a issue at all.There are something called one way security architecture.
Just reverse engineering the decrypt/encrypt (encryption engine) algorithm does not
violate the confidentiality or integrity as long as you are using asymmetric encryption
engine.You can use a client library which is static or even use templates where you
need to reveal the source code of the engine.It doesn't matter.

But when the code is loaded into the memory and the encryption engine had successfully
ran over it, there no longer be confidentiality on the machine code level.

Poor __stdcall ;)
Check __declspec dllexport/dllimport

Also there is good tutorial in links below. Haven't looked through but name looks promising :)
Dlls are Simple. Part 1
Dlls are Simple. Part 2
Dlls are Simple. Part 3
Dlls are Simple. Part 4

:) I used __declspec first, and it worked just as well, it would just mean calling the functions in a different fashion (sort of) from within the script.

I'll look into the benefits, and thanks for the links.

\

This won't be a issue at all.There are something called one way security architecture.
Just reverse engineering the decrypt/encrypt (encryption engine) algorithm does not
violate the confidentiality or integrity as long as you are using asymmetric encryption
engine.You can use a client library which is static or even use templates where you
need to reveal the source code of the engine.It doesn't matter.

But when the code is loaded into the memory and the encryption engine had successfully
ran over it, there no longer be confidentiality on the machine code level.

The bottom line of my post was, you can try hard but if they try harder...

:) I used __declspec first, and it worked just as well, it would just mean calling the functions in a different fashion (sort of) from within the script.

I'll look into the benefits, and thanks for the links.

May be this post is useful!