Protection against employees

I am a software company owner and I need to know if there is a way of protecting my software against my own software developers (employees). I plan to hire some software developers to help me maintain my application. And especially considering that I will hire them and test them for 1-2 months... they will have access to my code. And if I am not carefull they could steal my work and sell it later as their own.

So I created a comercial product and my interest is to be able to protect it against internal piracy such as: being able to copy my code and change a few lines and selling it as another software.

My first thought was to write some dll (if I only knew how... :) ) and protect it somehow so that nobody could view it and clone the code from it... and the dll should somehow contain specific information that would allow to prove that it was created by me. Also the main application should depend on the dll, and will not work without it, so probabely it should contain some functions-procedures needed by the application.

This way, I think, I would have some protection against my own new employees, and I would prevent them from stealing from me.

If you consider that this is a good solution please give me some code on how to do this since I haven't written a dll in my life :). I only do simple code, my entire application is built this way.

If you have another idea that would be better please tell me (with code of course if you can).

Thank you.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

1. put them in a 'clean room' environment (no personal electronics and no internet access)
2. only give them access to your PCs in that room with no removable media capabilities.
3. record their keystrokes
4. require code check-out / comparison utilities
5. have one of your trusted employees on their team
6. don't allow the outsiders access to your 'sensitive' code
7. if you can refactor your code ahead of time, only allow the outsiders to see/change individual functions.
8. Unit testing
9. Get your lawyer to help you with the contract.  You might want to explore some Intellectual Property theft insurance or contractor bonding.
TheRealLokiSenior DeveloperCommented:
I'm sure you've seen how you can download code from etc, and all you get is a package (or .dcu) without the source. This is probably sufficient. I'll explain more.
Depending on your version of delphi, you could make a package (.bpl) which is "added" to the project, (or just a .dcu)
But the source (.pas) is NOT made available for it. Inside that BPL/DCU you could have anything you want, as long as you make sure the application has to use some method from that bpl, like a really important part that your employees need, but will not need to change. The BPL could contain a string/version info that you could read with a  hexeditor if need be, or the name could just be really obvious, like "DavesCodeLtdLibrary.bpl"
Simplfying what TheRealLoki said, just give them the dcu file.
Rowby Goren Makes an Impact on Screen and Online

Learn about longtime user Rowby Goren and his great contributions to the site. We explore his method for posing questions that are likely to yield a solution, and take a look at how his career transformed from a Hollywood writer to a website entrepreneur.

GhitzaAuthor Commented:
TheRealLoki : If I can read the bpl with a hex editor... can't they edit it too and replace the string that refers to me? Sounds too easy to "crack"
the dcu ideea sounds ok... but it seems easy to decompile a dcu...
(and if they de-compile it then they can replace it with their own. So I don't think so.)
By the way I used Delphi 7 Pro,
Anybody has any ideea on dll's? They are unknown for me but I have a feeling that they might be the answer. I wish I had more time to study :)

aikimark: nice ideeas but I already thought at them and they do not fit this profile. As for the the contract, it is almost ready to be signed.

I really think that having a compiled dll that will be used by the project (and that would contain among others, some function that will return my info for example) would be the great ideea... Or is it possible and easy to decompile dll's too?

Please give me something...

The first thing I would suggest is to go with aikimark's suggest first and also like to add some more
1. You can provide the internet access with controlled access and use net monitoring tools to keep an eye
2. You can place a lock on the PCs provided.
3. Restricted user policy; no access to install/configure/remove any peripherals, s/w, etc
my 2 cents:
split up the code so that stuff they don't need to modify (ANY stuff really, preferably ALL) will go into separate units. Esiest way: break up the unit ThisUnitHasSomeCodeToBeModified into ThisUnitHasSomeCodeToBeModifiedAvailable and ThisUnitHasSomeCodeToBeModifiedProtected. (You figure out correct names :P )
after all such units are split up, make the application use interfaces to access the functions that are available for the new coders to modify.

for example

applicaation uses unit named "testing.pas" with 2 functions: doTheTest and validateSomeData. validateSomeData needs to be modified

breake it inot testing.pas with doTheTest and sometesting.pas with validateSomeData.

if the validateSomeData funciton is needed in testing.pas, then simply do a uses doTheTest and call the function. if the validateSomeData function is needed somehwere else, then there do uses doTheTest and cal the function.

bottom line is that the new coders will make the function (fix whatever) and do a unit testing on it (suggested above) which will guarantee that the code works as expected. so you (yourself) can then put the new unit in teh project and everything compiles.

huh... that's a little complicated thing, but doable ;)
you should protect your executables (.exe and .dll) with sophisticated obfuscation.  Check out Themida from Oreans.
DLLs are actually pretty easy to make.  You can do quite a bit with DLLs once you get the hang of it.  First create a new project using the DLL Wizard.  Why they call it a wizard I'll never know - it doesn't do much - all it will do is create a new project with a single .dpr file - no other units or forms.  In a normal application, the first word in the dpr file is "program".  In a DLL, it's "library".  This library unit will have a big long comment in it, and it will have a uses clause for SysUtils and Classes, and that's it.  

Now you start adding in your units to the project.  You need to figure out the specific procedures and/or functions you want to use to communicate between the DLL and the main application.  You might have to create some new ones to accommodate this DLL / application communication.  Once you have that figured out, you need to add an exports statement to the DLL.  Often this is added to the main dpr file, but you can actually add it to any unit's interface section.

For example, if my functions are

procedure SendData(data: string);
function RequestData(dataType: integer): string;
function IsRunning: boolean;

All I need to do is add this statement

exports SendData, RequestData, IsRunning;

WARNING - the function names in the exports statement are CASE SENSITIVE!  This is a Windows thing - not a Delphi thing.

Obviously you will need to write the implementation of these procedures in the DLL.

Now, about that big long comment when the DLL was created.  READ IT.  If you are using strings as parameters or return types in these exported routines, or even nested in records passed as parameters, you have a little more work to do.  It's all explained in the comment.  It not a big deal though.

A couple of simple rules – put your DLL in the same directory as the application, or if you’re a purest, the Windows\System32 directory.  If you need to use the BORLNDMM.DLL for strings, you wont even notice it on your machine because it's already in the System32 directory, but you will need to export it to client machines.  If you can avoid it, don't pass objects between the DLL and the main application.  You can do it, but keep in mind that class definitions are defined in a separate place in memory for the DLL than they are in the main application, so you can get weird behavior.  For example - a TStringList is created in the DLL, and passed to the main application.  The main application does this:

If (obj is TStringList) then …

The if statement will fail because the class definition for TStringList in the main app is in a different memory location than the one where the object was created, even though they are identicle (assuming they were compiled with the same version of Delphi).  Also, if you are using your own class definitions, and the class structure is changed, and you forget to compile both the app and the DLL, you can have real problems, because the discrepancy won't automatically be detected.  Like I said before, if you can, just pass simple things like strings and integers and so on.  

Anyway, in the main application, to access the exported functions, you declare the function or procedure just like you would anything else you are about to implement, but instead of implementing it, you follow the declaration with an "external" keyword, followed by the location of the external implementation.  Like this:

  MyDLL = 'MyCoolStuff.dll';

procedure SendData(data: string); external MyDLL;
function RequestData(dataType: integer): string; external MyDLL;
function IsRunning: boolean; external MyDLL;

WARNING – again, these procedure/function names are case sensitive, because it must match up with the DLL names.  

If you don't want to place the DLL in the same directory, or the system32 directory, you can put it anywhere you want, and put a full path name in the external specification.  

You don't have to do anything else.  You can now start using these routines as needed.  

There's nothing in Windows that makes sure the parameters are the same in the exports section of the DLL, and the external section of the app – you have to do that manually.  If you get it wrong, be prepared for access violations and crashes.

In this particular case, if the app starts up, and the DLL isn't there, the application will error out with an error saying it can't find the DLL - it won't even get to the initialization sections of the units.  If this is a problem, you can use Window APIs LoadLibrary, GetProcAddress and FreeLibrary to load DLLs dynamically, so that you can run the app with or without the DLL.  There's code in the Demo apps that come with Delphi that show how this is done - just search the demos directory for LoadLibrary and you'll find it.

Hopefully that all made sense.  

DLLs can be cracked and hacked as easily as an exe, bpl, dcu and etc!

My 2 cents!


"as easily" is pretty relative when it comes to obfuscation.  Take a look at the Themida product I posted earlier.

I concur that "as easily" is relative. However, there are Themida cracks and guys are working on it. So, there is a crack and hack for everything. Google "themida crack".

It just seems that no matter what we do to protect our work, there is a crack or someone will find it a real challenge to defeat whatever protection we, as developers, have tried to use. Yes, this is a small group, but as soon as something is cracked, it is posted "out there" somewhere. I have several things that I protected, and I thought pretty cleverly, that were cracked and posted on several crackers sites. The only comfort in this was in the crackers comments in his readme file that at least my attempts to protect my work "took some thought" to crack it. So it at least took some time.

Just FYI and my 2 cents again.


The only cracks I found were to the Themida product itself, not to any particular application protected by Themida.  Do you have a more specific link for me to evaluate?
Wim ten BrinkSelf-employed developerCommented:
To be honest, everything you create can be stolen by anyone who has access to it. Those same programmers you hire to work on your code might also just reverse-engineer the final executable. Or worse, they might just rewrite what you have created from scratch without even the need for your code.
Also keep in mind that the likelyness of your code being stolen is related to how interesting your code is in the first place. If you have code for a high-security encryption mechanism then that is way more likely to be stolen than some code that allows you to maintain some simple database with statistics of the visitors of some website.

So the first question is: how interesting is your code that you might risk it being stolen? And don't overestimate it's value like so many others are doing. And be more protective about your customer dtabase than your code anyways. Even if they steal your work, they still need to find any customers for whatever they create based upon your code. They might be more interested in the list of customers than your actual code.

I happen to have sourcefiles of projects that I worked on for previous employers and while I still keep them as reference, they're not very valuable for me. I might try and modify one such project and try to sell it but my main problem would be finding customers who are interested in this product. Preferably customers who won't report to my previous employers that they have a new supplier for their software...

Code is as valuable as what your customers are willing to pay for it. Your customers are even more valuable. Don't give them access to your customers!
Now that you've succeeded in scaring the guy to death, the vast majority of people have no idea how to hack into DLLs or EXEs or DCUs, including 99% of programmers.
Wim ten BrinkSelf-employed developerCommented:
Yep, which actually isn't a bad thing. People are too worried about the wrong things, like putting several locks on your front door while keeping the back door open. Sure, code is valuable but other things are more valuable. He's afraid someone will steal his code. But is his code that valuable compared to the other information that might be in the network?

Anyway, I have collected lots of sourcefiles during my 20+ years working as a professional and those sources are valuable for educational purposes but to try to make a profit of them? Let's see what I would have to do to make a profit out of them...
First I need to find a reseller for my product. And I would need customers willing to buy it. I need to set a price that's competive with the original product but preferably a lot cheaper else everyone will still buy from their old software provider. And I have to make sure my old employer doesn't learn about my new commercial interests else I might end up in deep troubles for copyright infringement.

There is one simple way to protect your sourcecode, though. Make a print-out of ALL your own sourcecode including a copyright notice on top of every sourcefile. (A unit header.) Next, go to your local notary and let him mark these sourcefiles as proof that you're the rightful owner. It costs a small amount of $$$ but it will make it officially your sourcecode. Thus, if those programmers steal and misuse your sourcecode you can still prove you're the owner and have them arrested for theft of your intellectual property. Even if they change a few lines of code, if most of the code is similar to your code, it will be enough for them to be convicted.

And again, your sourcecode might be valuable but your customer database is priceless.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
GhitzaAuthor Commented:
Well to start with you Workshop_Alex , since you wrote me last, here is the thing. I am a programmer for some time now, and I worked also for an employer and recently started my own small business in software development, based on solely my own work, designing an application that refers to only a few companies in my country. My only competition comes from 2-3 software vendors that have a similar product but not as advanced as mine (I am not a show off... it's my clients opinion). So now since I want to have more customers I took the decision to hire a few people to train them to be able to bring small modifications to my application since all my clients have particular needs so the application must be altered for every customer. This part sucks because it's a lot of work involved in making and keeping track of all the updates made to each customer. So this is why I need an employee for, to give some clients to him to take care of their needs.

Now for the thing that I need code protection from my employees is that since I have hired the first guy (a pretty capable one) more than a month passed and he is still in training... since the field my application is in, is quite complex and quite rare. So a simple programmer that has NO knowledge about the field this program is about, needs a lot of training while I do pay him a pretty fair salary. Now... I do not want to keep training the guy (on my money) until he understands all the angles of the problems he might encounter in this particular area... and then watch him resign and start his own business in the same area that I am in, and using my readily made code and knowledge to compete with me. Is that too much to ask? So it is not about code snippets, or tricks in delphi , because I teach him all that stuff. It's about parts of code that I prefer to keep away from him (or any new employee) to try to protect my recently started business, that might die easily if someone would still my work and sell it for smokes.

So I do not need protection against crackers at the moment, since I can "protect myself" using licenses , copyright laws, and a few protections for the executables and dll's as stated above.

My conclusion is that I should talk to my legal adviser and do a contract for the employees and make them sign it.

Anyway thanks to all of you for your time. I shall split the points to Meldrachaun (for the dll help) and Workshop_Alex (for the notary idea that brought me to think about the contract for the employees).
And thanks to all for your comments.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.