Recently we’ve had lots of interest in an internally developed product from external organisations. Obviously if they’ve got enough interest to want to pay for it… why not sell it to them?
There’s a few issues to consider when the software was developed without a clear goal to make it into a saleable product:
- The software was never developed to be a product for general sale – it is likely to have missing requirements as it was developed for a single purpose (i.e. not generic enough)
- Licensing (the software) was not a requirement during the development – the developers did not know it was a requirement, this could have altered the design stratagem
- Database objects not created ‘WITH ENCRYPTION’ – a simple to fix issue, but its a PITA!
- Web application not written with obfuscation in mind – is it possible to reverse engineer our DLLs/Web Services?
The software we need to protect is a web application (ASP.NET 3.5 C#) with a SQL Server 2005 back end
I had some experience with obfuscating .NET since 1.1, and it seems lots of the issues from back in 2001/2 have now gone since the .NET language has moved on and become more optimised. There’s an interesting thread of discussion on Stack Overflow that might interest you. It discusses tools, reasons for doing it, and the potential pitfalls.
I’m not too worried about our IP going missing, as we will put a non-disclosure agreement in place, and the potential buyer would loose significant reputation and business from my organisation if they were to attempt to get out our precious source code.
Having looked at a few obfuscators, I’m tending to go for Eazfuscator.NET. As this software package is under maintenance (internally) I didn’t want to make wholesale changes to the solution/project so it seemed the obvious choice. Simply use it on your web application DLL (outside of Visual Studio), and all is well.
In terms of licensing, we will need to think about a pricing model if orders do come through to door and then come up with a suitable licensing strategy.
Our main headache is going to be “… well, it kinda does what we want it to do but …” type questions. Our internal processes are almost certainly going to be different to those organisations wanting to use the package. Dealing with this, alongside the maintenance of an existing system is going to be challenging.