Restrict Excel Add-in Distribution [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

I have an Excel Add-in that we want to deploy to clients. Currently it is an .xlam file. I know that Excel Add-ins are probably not the best way to distribute software, but that is what I've got. My question is how do I protect this Add-in from getting used on other computers than the intended client?

I considered the following:

1. The add-in checks for the existence of a file in some obscure location. If it exists go to step 6
2. If the file does not exist, generate the file with some random assortment of characters. And display this as registration info to the user.
3. The user then contacts us to get an activation code.
4. We create an activation code using some salted hash algorithm and send that back to the user.
5. The user enters this activation code into a prompt. The macro validates it and then stores the activation code in a protected sheet in the .xlam.
6. The macro then checks that the activation code in the protected sheet is valid for the code in the file. If not it prompts for activation.
7. If the file and activation match, allow access to the functionality in the add-in.

The problems I have with the above idea is the following:

1. Where should the file be stored and what about machines that do not allow the current user to create files in that location?
2. Would it be easy for the user to discover the existence of these files? If the file gets copied to another computer, the Add-in will validate it and work without any problems.
3. If we upgrade the Add-in, it will lose the activation code. This can actually easily be fixed if we use a second file instead of a protected sheet to store it.

Answer 1

Its fairly easy to create an XLA/XLAM installer that requires an installation password (Setup Factory, InstallShield etc). However they don't prevent casual copying of the XLA/XLAM itself.
But the major problem with an XLA/XLAM is that they are easy to hack, so any licensing code to control activation embedded in the XLA/XLAM itself is not secure. This may or may not matter depending on your target audience.
For stronger security the licensing system really needs to be coded in a more secure language, preferably a fully compiled DLL or possibly an obfuscated .NET assembly. There are a wide variety of pre-built solutions available on the net that do this.