VSTO deployment scenario to avoid code decompilation

Question

Dear VSTO community,

I am a developer who has been crating a large Excel add-in (i.e. > 20,000 lines of code) over the past year.  So far, I have been distributing it to a small group of users using a local-local paradigm, with no issues.  As my group of users grows, however, I want to ensure that my code -- the intellectual property contained within, along with its authentication/licensing mechanisms -- remain safe.  I was surprised to discover how easily .NET code can be decompiled, and was wondering what other VSTO add-in developers are doing to safeguard their code.

It seems like the standard .NET technique to *somewhat* safeguard the code is to use Obfuscation.  With VSTO, however, the standard version of Dotfuscator does not work, it seems like it requires the Professional version, which seems to cost in the neighborhood of ~$1000.  Even if I were willing to shell out the $1000, security through obscurity seems like a rather so-so method to me; and, again, with VSTO, I think it's somewhat easier to trace the code, as it links to Office libraries in pretty obvious ways (i.e., I think you could easily tell apart the ThisWorkbook class).  (I stumbled across this interesting article for how to crack an obfuscated .NET assembly:  http://www.atrevido.net/blog/2004/11/26/Cracking+Code+3+Cracking+An+Obfuscated+NET+Assembly.aspx)  So, are there other methods?

I have read about deploying VSTO solutions to a SharePoint server -- does that protect the code at all?  My understanding with SharePoint is that it would be possible to keep only the document on my client's local computers, while keeping the .dll file with my code on the server.  On the other hand, it seems like if the document can get access to the server, so could a user, and so he/she could STILL get their hands on the code and run it through a decompilation (or even the Microsoft-provided IL DASM) utility.  Please forgive me if the above sounded a little naive:  though I have decent programming experience, I have never needed to learn about deployment until now, nor have I used SharePoint.

As a possible alternative:  does code using Office Web Apps remain secure (since, correct me if I'm wrong, my understanding was that it runs on the server, never visible to the client)?  I realize, of course, that its functionality is severely limited compared to "real" Office, but is that at least an alternative?  Also, does anyone know if VSTO will be supported in the upcoming web-based Office 365, and if *that* would make code secure?  (The question of whether VSTO will play with Office 365 has been asked before at http://social.technet.microsoft.com/Forums/en-US/bpostransition/thread/11dbef8e-8dc8-49a5-827e-92a6fcf4b63d/, but was not answered…)

Any thoughts & suggestions will be greatly appreciated.

Sincerely,

- Michael Zlatkovsky

Answer 1

Just to report back:  after a few weeks of trying out various obfuscators, I finally did manage to obfuscate my VSTO project, both cheaply (only $179) and (now that I've got everything configured properly) painlessly. 

The obfuscator that I settled on is called .NET Reactor (http://www.eziriz.com/dotnet_reactor.htm).  It is VERY well-engineered piece of software, and costs remarkably little, $179 (compared to, say, Preemptive's Dotfuscator, which even after I emailed them and explained that I'm a freelance developer with little money, the best they could do is drop the price from ~$2000 to a "mere" $995).  Unlike some of the other obfuscators, .NET Reactor works with VSTO solutions, and, also very importantly, it integrates with Visual Studio to make the obfuscation process just part of the build/publish one-click process.  The importance of this integration is something you'll only discover when you need to obfuscate and sign assemblies manually -- which is a very tedious, 10-minute process of copying a file, obfuscating it, copying it back, re-signing the .dll.deploy file with MAGE, re-signing the .vsto file with MAGE, etc.

.NET Reactor's chief developer, Denis Mierzwiak, was VERY helpful and available when I needed some help in configuring .NET Reactor for VSTO.  Initially my project was not lending itself to obfuscation, but Denis spent several hours with me on Skype to get things working, and kept sending me new releases by email as we continued to work out the kinks in the system.  The Obfuscation now works 100%, integrates beautifully into Visual Studio, and is completely painless -- I actually can't recall a time when I was more pleased with a software product or with the level of technical support!

For those who'll be using .NET Reactor for VSTO, just a few hints:
1) It might be that the latest changes to the .NET Reactor (introduced for better VSTO support and integration) are still not in the "official" release -- you might want to email [e-mail] to ask about obfuscating an Office solution and to get the latest version.
2) It IS possible to fully obfuscate a VSTO solution (including renaming public types); since you are obfuscating a .dll file, however, that option is disabled by default.  To enable it, go to the Settings tab, option #2 (Protection Settings), Obfuscation, and select "obfuscate public types".
3) Once you obfuscate public types, you will need to add a regular expression to EXCLUDE the several classes that VSTO expects (under .NET Reactor's settings -> Protections Settings -> Obfuscation -> Exclusions -> Regular Expressions).  In the case of an Excel spreadsheet, those would be ExcelSampleWorkbook\.Sheet1;ExcelSampleWorkbook\.Sheet2;ExcelSampleWorkbook\.Sheet3;ExcelSampleWorkbook\.ThisWorkbook
4) Finally, if you obfuscate public types but exclude the required VSTO objects from obfuscation, be aware that code in those files (Sheet1, ThisWorkbook, etc) will obviously NOT be obfuscated.  In my case, I created a "HelperDelegate" for each of those classes (i.e., ThisWorkbookDelegate) to hide the code behind the delegate.  All that my Excel objects carry are event handlers (things like BeforeDoubleClick) and a reference to the delegate (so I can call Globals.ThisWorkbook.helper.myFunctionName())

Hope my experience is useful!

- Michael Zlatkovsky

 

EDIT, 8 months later:  The solution continues to work great for me, including using it for Add-Ins, rather than just Document Level Customizations.  Note that as far as step 3 (both for add-ins and document level customizations), instead of using regular expressions -- which can get quite messy, and requires reaching into the external obfuscation file -- it is possible to "decorate" functions with a non-obfuscation attribute, e.g., 

<Reflection.Obfuscation(Exclude:=True, ApplyToMembers:=True)>
Public Class ThisAddIn
...
End Class

Answer 2

Hi Michael

Thank you very much for taking a moment to provide this very comprehensive description of the solution you found to a problem that's plagued VSTO developers for years!

---

Cindy Meister, VSTO/Word MVP

Answer 3

Michael

 

Been a long time VSTO Developer, and this is a fine piece of work you've done sir, my hat is off to you. They should give you a T-Shirt or something; or a plush Clippy (oh come on, everyone secretly wants a plush Clippy, mainly so we can stomp on him).

But seriously, Thank you for sharing this knowledge.

---

-dhtroy

Answer 4

My thanks to you too Michael!

I have a client who does not understand 'Intellectual Property' in my Excel VBA solution ('It's just VBA code, isn't it?'. I decided to put all the business logic in a DLL via Visual Studio 6.0. But now looking into VSTO, targeting Excel 2010 and I have VS2010.

Until I read your thread I wrongly thought my objective for code protection will be achieved simply by putting my classes into a VSTO Add-In. Thanks for the heads-up, and for the solution.

Having said that, 'protection through obscurity' would work in my present scenario, in 90% of the cases I get involved in I expect. But it's good to be doubly sure.

Thanks,

Hiran

 

Answer 5

Hi Hiran, good luck with the transition.  I think you'll find VB.NET to be a very powerful, convenient language, and VS2010 to be a much better programming environment!

Just so you know (e.g., to tide you over until you transition to .NET), it actually IS possible to obfuscate VBA/VB6 as well, sort of.  It is less convenient (it has to be done directly on the source code), and presumably less secure, but if you search for "obfuscate vba" you'll find some instructions for it.

Best of luck,

- Michael

Answer 6

Any idea how to make a clickonce installation where the dll.deploy file is obfuscated with .NET Reactor

Say the published clickonce project consists of the following files in the Application files directory

file.dll.deploy, file.dll.manifest, file.dll.vsto. These will all install running the setup.exe.

I have then obfuscated the file.dll.deploy and afterward replaced the original file.dll.deploy with the obfuscated file.dll.deploy.

Setup now complaines that file.dll has another hash-value than the manifest.
That would be clear, because the dll.deploy and manifest files are build before the obfuscation.

 

 

Answer 7

Good point, I forgot to mention it in my original reply back to the post.  Open up the .NET Reactor, and from the "Help" menu choose "Install Visual Studio ___ Add-In" (2005, 2008, and 2010 are supported; I'm using the 2010 version).  Restart Visual Studio, open your project/solution and now you should see a ".NET Reactor" as the first menu item under "Tools".  Open it, select your project, mark BOTH checkboxes (I do this only when I'm about to release; before that, for ease of debugging and speed of compilation, I skip obfuscation), and select your .NET reactor project file (it says its optional, but if I remember correctly you're really better off creating one).  Then click OK, and allow the Reactor to modify your project file (I'd make a backup of your entire project first, just in case).  Then if you do a clean and build/publish, your project should obfuscate right from within Visual Studio!

 

Hopefully this helps, and I didn't miss any steps (it's been over 1/2 a year since I last did the install).  If you have questions beyond this, email .NET Reactor's developer -- he'd been very helpful to me.  Best of luck,

 

- Michael

Answer 8

I have tried that and enabled .net reactor in VS 2010.
It builds the project and publish successfully, and the dll.deploy file is also obfuscated I can see afterwards with dotpeek.

But the setup still complains, that the dll has a different computed hash than specified in the manifest. 
.net reactor has not answered any email. Maybe because I have not bought the product. I am reluctant until I can see it work.

I am trying out different obfuscators. Crypto Obfusctor works, but is a bit expensive.

 

Answer 9

Hi,

I'm a paying customer to Eziriz and their support is crap. OK, cheap tool but no support. How much does that cost You?

I deciced to drop their tool and went with Crypto Obfuscator. As already been said, more expensive, works excellent for VSTO projects without any bizarre workarounds. Best of all, You get a great support.

That's my experinece and I doubt that any company who don't take support seriously is a dead fish in the long run...

---

Kind regards, Dennis (http://xldennis.wordpress.com/)

Answer 10

Hm, that's a shame.  10 months ago Eziriz's support was very helpful to me, even before I purchased the product, but maybe times change...  Sad if so. @hjpfyn, I'm not sure about your issue:  it computes the hash fine for me...  By the way, out of curiosity, I'm assuming that with Crypto you still have to declare the core Excel files not to obfuscate, correct?  And (again, more for the record than anything else), which of the three "flavors" of Crypto are you using/trying out?

Answer 11

The trial download is the 400 dollar Crypto Obfuscator For .Net (v2011 R3) Enterprise developer license, and that is also the one you have to buy for clickonce projects. For $560 you get 1 year upgrade subscription and support?(hopefully also support for the 400 dollar edition)

I had some difficulties at the beginning, but got good help from their support - (5-6 mails and answers). I had to make a search path in the obfuscator settings for  C:\Program Files\Reference Assemblies\Microsoft\VSTO40   both when obfuscating word and excel, and it build error free in both cases. I did not have to exclude anything from obfuscation. And running the deployed projects also worked right away.

As for .net reactor i all builds error free, but it is of no use, if the end product can't be installed. Maybe the problem is easily corrected, but no help no buy.

 

Answer 12

You can writer you key function or algorithem in C or C++，and then using .Net P/Invoke technology to call them,for example you can write your UDFs in xll using C++,and when the vsto startup and then register the .xll. General speaking , reflector or reverse engine the code writing in unmanaged environment such as C or C++ is difficult.