VBA Code Security

In 3+ years we have developed quite an array of time-saving utilities (many with the help of the regular contributors of this board). These custom files represent quite an investment of time and money made by our company. It is no exaggeration to state that these utilities (among other things) give us a competitive advantage over our not-so-technically-savvy competitors.

We are now trying to add features into our AutoCAD VBA files that would prevent them from being run anywhere outside of our organization.

While we are aware that the standard VBA passwords can be broken, and the code then modified to suit, we would nevertheless like to implement code that would discourage any “casual” user of our utilities from just loading and running them somewhere they shouldn’t.

Any ideas on this subject are welcome.

Thanks,

NOTE:
In the future, we will be porting code to ARX, especially that code which is marketable and/or extra important to us. Nevertheless we will always have a need for this type of VBA code security – especially now.

 

Robert,

I may not have been clear enough. I apologize.

Even if our code is in ARX, we cannot fully prevent someone from just copying the ARX file and taking it out the door. And that's NOT what were trying to prevent, as this is impossible. Norare we concerned, for the time being with the limited password protection of VBA. We know ARX helps us there.

What we're looking for is ideas on how you can prevent a custom file (VBA, ARX, whatever) from running in an environment for which it was not intended. That is to say, our programs should work in our office but "blow-up" if run elsewhere.

Things we've considered but have not yet tried include checking for a specific IP address, network card ID, database login, etc.

We just don't want a casual user to simply copy it and run it without any problems. If anyone has done something like this, please feel free to respond.

Thanks,
spanqy

 

We copied this from the way many mainframe programs link to the computer their installed in.



But of course, we can't count on having an unique serial number for the CPU like they do, so:



We use disk serial number + nic ID + others (but don't over do it) to generate a unique code for each computer.



We then use home-made encryption to validate a unique password stored in the registry the first time around.



(Never repeats it's self in another computer.)



 



Everytime the software runs, it generates the same unique code and checks for the stored password. If password is not there, it will ask for one and not run until it gets one (you could add here a day counter to allow for a 30 day license). You then have to call the manufacturer for the password.



This also serves as a license count mechanism.



 



Nothing is fool proof but this takes care of must of the cases.



 



Don't waste your time doing this in VBA code. Use at least a VB DLL or ARX.



Don't make your software blow-up under any circumstance, cause it could backfire, in many ways, including legal problems.




--
Saludos,  Ing. Jorge Jimenez, SICAD S.A., Costa Rica



"spanqy" <> wrote in message news:...

Robert,

I may not have been clear enough. I apologize.

Even if our code is in ARX, we cannot fully prevent someone from just copying the ARX file and taking it out the door. And that's NOT what were trying to prevent, as this is impossible. Norare we concerned, for the time being with the limited password protection of VBA. We know ARX helps us there.

What we're looking for is ideas on how you can prevent a custom file (VBA, ARX, whatever) from running in an environment for which it was not intended. That is to say, our programs should work in our office but "blow-up" if run elsewhere.

Things we've considered but have not yet tried include checking for a specific IP address, network card ID, database login, etc.

We just don't want a casual user to simply copy it and run it without any problems. If anyone has done something like this, please feel free to respond.

Thanks,
spanqy

 

Because Autodesk's own security seems pretty robust, we tie our application's ability to run to their Registration codes etc in the registry. Anybody see any "loopholes" in this?
  
Regards
  
Wayne Ivory
IT Analyst Programmer
Wespine Industries Pty Ltd

 

Thanks for all your replies!

Jorge: When I said "blow-up" I did not mean it in the sense of causing damage to their machines. I just meant that the application itself would "gag" if run in this foreign environment. Gracias por su tiempo!

Wayne: Sounds like a bright idea and fairly simple to implement. Thanks mate!

 

I'm using two types of copy-protection both applied through ACAD VBA:



 



1) Software protection - a pair of keys (Request Code / Authorization Code) with known key length. When user installs application it works in "demo" mode for certain period of time. If user "registers" the application using Authorization Code (generated by me using Key Generator application and sent via e-mail or secure P2P channel) it becomes fully functional.



 



2) Hardware protection (USB dongle by Rainbow Tech.) - really GOOD protection offering many many "types" of protection (like memory cells for protecting separate app. modules, remotely programmable counter (demo mode based on the number of app. running ups), hashing tricks and hack-proof set of procedures...)



 



Software protection costs between 0$ and 100$ (various vendors)



Hardware protection costs abt 250$ for starter pack + 20$ per every USB dongle (at Rainbow Tech.)



 



"spanqy" <> wrote in message news:...

In 3+ years we have developed quite an array of time-saving utilities (many with the help of the regular contributors of this board). These custom files represent quite an investment of time and money made by our company. It is no exaggeration to state that these utilities (among other things) give us a competitive advantage over our not-so-technically-savvy competitors.

We are now trying to add features into our AutoCAD VBA files that would prevent them from being run anywhere outside of our organization.

While we are aware that the standard VBA passwords can be broken, and the code then modified to suit, we would nevertheless like to implement code that would discourage any “casual” user of our utilities from just loading and running them somewhere they shouldn’t.

Any ideas on this subject are welcome.

Thanks,

NOTE:
In the future, we will be porting code to ARX, especially that code which is marketable and/or extra important to us. Nevertheless we will always have a need for this type of VBA code security – especially now.