Its (too) easy to say if it needs protecting you shouldn’t use Excel/VBA. Although I have to confess that is my default view most of the time.

Someone just asked me how to protect a specific Excel/VBA tool of theirs, and ‘use something else’ is probably not overly helpful. The specific issue was how to stop a sensitive pricing model working if taken to a competitor? We are not talking national security at stake, just enough to make copying a not totally trivial exercise.

So here are some of my thoughts, please chip in with your own ideas and experiences. In all cases below there needs to be some separate way of checking the system is in the right place. eg checking the organisation name in the registry, or checking for a specific sentinal registry entry or a (perhaps hidden) file that gets there outside of the normal install. Doing this in something as trivial to crack as VBA is fairly pointless.

1. PED suggests a workbook open password (these are genuinely hard to bypass, in recent (non French) versions), and then a VB6 front loader exe that has the password compiled inside. The exe makes the checks before opening the workbook/add-in. Exes are self registering so this needs no install, VB runtimes are guaranteed to be there from Office 2k onwards. Functional code left in VBA so there is some weakness once the w/b is open.

2. Migrate most functional code to a VB6 dll, then secure that. Downside as with all COM, this will need an install and registry write access.

3. Put the security checks in an xll. Same benefits as the VB dll but needs no install/registry access, downside needs C/C++ skills. You need to put a fair chunk of stuff in the xll otherwise a cracker can just overwrite the validation call with an ok return value.

4. If your clients are in the .net minority then a .net version of one of the above. .net of course is not known for its native intellectual property protection.

Do you have any other/better suggestions, or see weaknesses with those above?

Cheers Simon


10 Responses to “Protection”

  1. Ross Says:

    This is not better, but if you want to stay in VBA then this may be an option –
    quite slow though. I’m not 100% convinced with the workbook open password method. when you have it open your back in the same boat – plus you can get to the worksheet data from another sheet.

  2. Harlan Grove Says:

    You could always try obfuscated code, but the cleverer script programmers can unobfuscate fairly readily.

    As to using an EXE front-end, it either (1) remains running while Excel is running and prevents other processes from gaining control of that Excel application instance, or (2) it exits leaving the sensitive workbook open in Excel. Problem with (1) is that users could use Task Manager to kill the EXE wrapper process, then use something else to make that Excel application instance interactive. Once the sensitive workbook is in an interactive Excel application instance, the user can save it under a different filename without the File-Open password.

    You’d need back & forth polling from Excel to the EXE and from the EXE to Excel to have a prayer of securing the overall system. And that would make the overall system S***L***O***W. Even so, it’s relatively simple to write a script that would kill the EXE process, immediately pick off the Excel application instance using GetObject, make it visible and interactive, disable events, and iterate through the VBA project changing all Sub names to effectively disable any OnTime polling macros.

    EXCEL LACKS RELIABLE IP PROTECTION. Granted it may take considerable understanding of how Windows and the Excel object model work to defeat best effort IP protection, but anyone with such understanding can defeat the EXE wrapper around the File-Open pasword-protected XLS file quickly and thoroughly.

    Re VB6: I thought you said using something other than Excel would be a non-starter? Ditto XLL and .Net. But you’re on the right track: DON’T USE EXCEL AS ANYTHING MORE THAN A PURELY VOLATILE (i.e., no storage persistence in Excel/XLS files whatsoever between sessions) GRID CONTROL. It has no other use in systems that MUST protect IP.

  3. Dermot Balson Says:

    The open workbook password is no protection, because many sites on the net offer affordable cracking. I understand VBA passwords are no stronger.

    In a pricing workbook, data may be crucial. I have experimented with encrypting sheet contents in place, and with storing encrypted data in places like cell notes (it’s actually a good way to store a lot of data more efficiently than Excel does in cells), but you are always subject to the problem that an insider can get everything unlocked and then steal it.

    I think a good solution is to write an external component such as an XLL which retrieves and decrypts the data from a file held securely elsewhere.

    If the code is crucial, I believe you have no choice but to compile and obfuscate it in something other than VBA.

  4. sam Says:

    I believe no software is secure ….it can only be protected….

    The time taken to crack open various excel passwords is as below
    a) The file open password – Directly proportional to length. 7 Characters and above could take years…. I dont think commercially available softwares use anything else other than brute force or dictionary attacks

    b) Worksheet password – 2 seconds – 2 lines of code

    c) Workbook password – 20 secons – looping code

    d) VBA password – 10 Secs

    Which leads to the conclusion that Data can be protected resonabaly well (file open password)

    However once the file is opened….the rest is as secure as a tissue paper…

    Another big probelm with Excel lies outside it …in Windows….As long as it is possible to create a copy of a file with identical attributes (same file creation date and time)…there is just no way to check which file is the original and which file is a copy….


  5. Dick Kusleika Says:

    Is ‘someone’ trying to protect against people copying the worksheet, copying the worksheet and selling it as their own, or having access to proprietary data and calculations?

  6. Dennis Wallentin Says:

    For known customers I use an written agreement and don’t spend the time to protect any solutions.

    For my commercial add-in I use the built-in VBA protection.

    Sometimes I use DLLs/EXE but the primarily purpose to use them is speed and to assure that the solutions run ‘bullet proof’ – not to protect any IP.

    The same is valid for the very few .NET solutions I have distributed.

    All in all, this is not an area with any priority for me.

    Kind regards,

  7. Simon Says:

    That pretty much sums up my view too – thats why I emailed him some initial thoughts and said I’d blog about it to see if anyone had better ideas.
    Thanks for your input everyone.
    As discussed Excel has no security and that is by design and a good thing in my opinion.
    Preventing copying really needs the activation approach via some cetralised authority which I personally detest in general. For a corporate client wanting to protect their IP though maybe its ok if they are happy with it.

  8. Charlie Hall Says:

    Hi all and thanks

    I was the one who asked Simon originally – and the discussion has been useful.

    In the work that I do my client’s workbooks have calculations that are unique to them (and output layout, but there is not much I can do with that) and they would like to ensure it remains with them after someone leaves for the competition.

    My current approach is to use a VB6 DLL to check with an outside source (corporate facility) to ensure the user is an authorized user and then I enable the functions that I have buried in the DLL. I look for functionality in the workbook that is not obvious or simple to reverse engineer and bury that in VB6 functions. And if there are any comprehensive VBA macros, I bury them as well. I also look for functions that when disabled make a lot of the workbook look broken – just for the visual effect on non-expert users.

    It seems to provide the right balance of cost vs benefit – with the client knowing that if someone really wanted to reverse engineer the buried functions, it would be possible, but not by decompiling the VB6 (at least I think so).

    I was looking for an alternative to the VB6 DLL approach because it requires the DLL to be registered – in some cases they just want to share internally the workbook(s) rather than build a installation setup every time they distribute a new version.

    I was curious about XLLs in that they do not need to be registered, but I think my clients would prefer the buried code to be in VB so that if they had to support it, it would be possible – they know VBA, but not C.

    Any suggestions or alternatives would be appreciated – thanks


  9. Ross Says:

    Just seen this – i think a hex edit of the VBA password might get round it though! – will try when i get home ;-)

  10. Tim Critchley Says:

    Ross, I think you’ll discover a simple key generator using the MAC address of the client.

    I suppose you could have the same thing wrapped up in a dll installed using the Package & Deployment Wizard, but I can’t thik of a way to prevent this being circumnavigated, and code which does reside in the Workbook from being “jump-started” once the VBA password has been cracked.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: