Convert VBA to DLL

Hi everyone,

Does anyone have any experience converting a vba project into a DLL? With the poor security associated with excel files, I have read that this is a better medium to house the vba code.

abousetta

Hi,

Try the below links, although I've never seen or heard of it being done.

http://social.msdn.microsoft.com/For...7-aaea3692305f

http://www.geeksengine.com/article/create-dll.html

Hi MarvinP. Happy holidays and thanks for the links. They are very helpful and hopefully some of the other members can shed some light on the day-to-day difficulties of making this happen. My fear is the simple steps shown by the articles I have seen so far are the 'standard' approach but that there may be hidden tricks or problems that plague this approach. As I have said, excel and vba passwords are ridiculously easy to get around and so I am searching for a higher level of security that I can eventually learn or that I can task others to do for me without having to sell a body organ.

abouseta

Hey abousetta,

There was a question a few months ago where an user wanted to use the built in Excel financial formulas in his own code. He wanted to know how to simply extract the formulas so his program could use them without his clients needing Excel on their machines. I thought this smelled like piracy, eventhough that wasn't the intent. In you think about it, converting Excel functions to a DLL that is useable by any non-Microsoft code would need a licence agreement and lots of dollars to legally use the Excel's algoirthms.

Doing a search finds
http://blogs.technet.com/b/office201...-security.aspx
http://www.excelsentry.com/information.php?info_id=13

Hi MarvinP,

My intent is not that cynical, nor am I knowledgeable enough in programming to want to have anything someone would pay money for. Having said that, over the years, I have seen people create applications in differnet language that use Excel and Access as their 'engines' and create the user interaction area using the MS product to do the calculations, create graphs, etc. The end user would still have to have the MS product installed on their computer for the set-up to work.

I have a pet project that I have been working on developing it when I have time and learn new techniques. Currently it is all in VBA. Now if I was to share it with colleagues, I don't want them to be able to easily see or modify the code. Until today, I have not seen a solution for securing vba without putting the code in another language that is more secure. Someone recently showed me how simple it is to get past all the layers of security I could think of (e.g. locking project, adding password, making project unviewable). I can't and won't go into details but suffice to say it shows that MS really needs to hire some major security people to provide a higher level of security for vba, but alas I don't think this is going to happen since it seems that VBA has just been turned into a cash cow with all the focus now going to other languages (e.g. .Net).

If you know of a better solution, I am definitely interested to hearing more.

abousetta

Have you considered doing all your code as an XLA?

See http://www.cpearson.com/excel/CreateAddIn.aspx

I have never done an XLA but have purchased a few that need passwords to view the code. See: http://spreadsheetpage.com/index.php/dataform/home where you need to "purchase the password" to view the code.

Sorry to say... but their security is not much better than the regular excel files.

Ok then,
How about http://msdn.microsoft.com/en-us/libr...ffice.10).aspx

Again, no dice. Can't go into details, but still not secure. That's the crazy thing, I am not proficient at Excel security issues and I have seen the pitfalls then what about true experts. As I said, I can't get into details, but you will have to trust me on this.

abousetta

Hi abousetta

Just a couple of points :
Microsoft have never used its "security" as a selling point, or claimed it to be as any kind of development vehicle. The macro (VBA) functionality is there purely to extend Excel's capabilities if the user wants to do something that Excel doesn't offer within its standard framework. Furthermore, if you were to sell your work, most of the users wouldn't want (or have the ability) to remove the layers of pretection in place. Yes, getting past the security is easy, but only if you know how.

A few years ago, some pompous git in the film industry stood up and made an announcement to the world that all the dollars thrown at the development of the DVD HD (competing successor to the DVD - lost out to BluRay) had meant that they had an answer to the piracy problem that had plagued the DVD : the security algorithm on the disc couldn't be extracted, or the disc copied.

It took a lone hacker 15 days using an unmodified X-Box to crack it.

My point is, whatever the platform, someone will always be able to steal your work. If the biggest software companies / film producers in the world are vulnerable, what chance does the rest of us stand? Decompilers can be used which, whilst don't get straight back to the source, can give an indication how the code flows and how the algorithms contained within work.

Lecture over, but what you probably actually want is a COM addin. It will be a long and winding road with plenty of weeping and gnashing of teeth along the way. The easiest bet is probably to download VB.Net (Microsoft will kindly let you have the 2010 Express version free of charge here, whcih should be enough to get you started).

Then digest these articles by Chip Pearson, who kindly gives lots of advice (unfortunately, they are a little out of date, as he is using VB6 in his examples, but you should get the gist).

http://www.cpearson.com/Excel/CreatingCOMAddIn.aspx
http://www.cpearson.com/Excel/Adding...sMenuItem.aspx
http://www.cpearson.com/Excel/COMAddIn2007.aspx
http://www.cpearson.com/Excel/COMAddInsSecurity.aspx
http://www.cpearson.com/Excel/DLLNameOfComAddin.htm
http://www.cpearson.com/Zips/ComAddInInstaller.zip

The order of these isn't the order they come on his menu page, but pretty much the order I think you should read them in.
The last one is a zip download.

The best of British to you ...

DominicB

Thanks DominicB. This is very helpful. I am not a programmer and have no intention on becoming one (else than a hobby) but at the same time don't want to feel '*****' when sharing the fruits of my hard work. As I have said (or think I have said) that my requirements for security are not for commercial purposes but for protecting (as much as possible) the intellectual property and hours spent putting these modules and forms together. Even so, I was surprised to see some Excel add-ins (some being sold for hundreds of dollars) with only the native Excel vba security being used. This probably means that the authors don't realize the weakness of this method rather than think that no one can do a google search to find out how to circumvent them.

abousetta

Bob, I disagree since the steps required (especially for professionals) might be worth their time. Here I am talking especially about programs that are being sold and not freelly distributed. It's like telling someone who owns a home not to get a security system and just locking their doors and windows is enough security when in fact amateur burglars can break in even when these simple procedures are followed stringently. In the end, it all comes down to how much we each value the intellectual property being saved in the workbook (and vba modules). If someone values it enough to be charging hundreds of dollars per copy of their program then they should probably feel something if they found out that it can be easily cracked without much effort.

You might disagree with Bob, but I can pretty much guarantee he is right. Anyone with the wherewithal to create and sell an Excel add-in is unlikely to be unaware of the ease with which the passwords can be cracked (they would have to have spent no time on any Excel forum), and I know many developers who adopt exactly the attitude Bob described. Also, given Bob's experience, I think it's safe to assume he knows more developers than you or I do.
Oh, and your analogy is somewhat flawed since the only loss incurred would be potential income, not money already in the developer's possession.

I'd be interested in both of your assessments. I've never heard anything great about similar programs.

I saw one interesting program to scrample formulas and only unscrambles them using an XLL. No protection was offered to opening files or vba and the price tag was pretty high for just scrambling formulas. I have yet to take a look at a working copy of LockXLS because their demo files are not locked and so I might be missing something.

RS, I don't disagree that I don't mingle regularly with developers, but from what I have seen, read, etc. intellectual property is the true value behind any new innovation. I guess most developers work for companies that then use or sell their products and so they are paid upfront, but it's the companies that then have everything to lose if they can't sell the product because there are knock-off versions floating around for free or little cost. This is the same problem in many industries (e.g. cinema, computer software and hardware, etc.). All I'm saying is that it surprises me that not more is done to secure individual works from theft, tampering, etc. in light of the fact that some are being sold for good profit.

Maybe I am wrong, and I will be the first to admit it, but the whole argument of moving ahead without securing what has already been accomplished doesn't sound very logical to me.

My 5cents.

abousetta

If you think about it logically, most Excel add-ins that would be sold are probably being used in corporate environments, and most corporate IT departments will not allow unlicensed products (due to the penalties they can incur). Additionally, the majority of other users I suspect will not install illicit copies of such programs, not least for fear of viruses/trojans and the like being buried within them. Also, you won't get any support if you have problems with it. For those, and probably other, reasons a fair number of developers don't feel the need to bother with protection - and clearly it's not hurting them too badly, or they would do something about it!

Fair enough. I guess in the vba world, IP theft is not that big of a problem as compared with more sophisticated products (like operating systems, advanced software, etc.). I work in academic research and in this field IP theft is too common and so trade secrets, experiemental designs, etc. are closely guarded until published, patents approved, or other means of protection is provided. Even if someone was to find a way into another person's files, steal their work, and plagarise it as their own, it is very difficult to prove foul play; much less get any credit back. Maybe that's why I am so keen on making sure everything is as secure as can be.