How to protect the use of my functions with a license file
Fonseca
I always end up stuck in the same (psychological) point: how to use
this tool and keep control on the access to my functions.
What I was thinking was:
a signed XML file is needed to use my functions
if this signed XML is in the same folder as the xll, then functions
are registered, if not, a message appears saying there's no license,
and automatically an unsigned XML is generated in the same folder as
the xll.
the generated xml file has some kind of unique ID specific to the user
machine (CPU, Motherboard, MAC, etc)
the user sends the XML to me to have it signed
I sign the XML with a private key
I send back the signed XML to the user
obviously, a signed xml that is OK is one that not only was signed by
me, but also that the registered machine ID matches the one from the
computer. This means a public key must be included in the XLL. But
since managed code is very easy to temper with, probably it would be
better to have this part of the signing check done on an unmanaged
library (so that the user can't easily change the public key).
Another thing is that although my functions are not registered they
obviously still can be stolen if someone access my dll directly. I'll
probably be linking the xll with an unmanaged dll containing my
functions (so that they remain correctly obscured). So what would I
need to add to each of my functions to check if it can proceed with
the calculation: a kind of variable that gets assigned when functions
are registered... (you can see that this kind of thing isn't my
strong...)
Although I have no problem programing my functions, I'm absolutely not
at ease doing what I just described (I think we all know that
programming a numerical method is not the same kind of stuff as
programming what I just described).
I started playing with:
http://jclement.ca/devel/dotnet/reallysimplelicensing.html
but I will never get what I want all alone.
So two questions:
Can someone help me (a lot...)?
Does someone has a different method for controlling access to the xll?
Thank you in advance,
Fonseca
Govert van Drimmelen
I like to distinguish between:
1. Protecting your code against decompilation, and
2. the licensing process and ensuring only licensed users can run your
add-in.
Most obfuscators will do a good job of 1. by stripping your .dll of
most of the metadata in method names and signatures. Once stripped or
useful names, even though the library can be opened in .NET Reflector
or ILSpy, and you can get usable C# code, the code is not likely to be
worth using. So I think obfuscation (with some care to make sure that
your public interface is a small as possible) is good enough to
protect your code and you need not implement in C++ just for that
reason.
However, issue 2. is much more tricky. In general you will have some
license check, but hacking a small change into your library can bypass
your checking routines. Native code probably gives some more
protection, though determined hackers can get past your checks here
too.
You might like to look at this thread:
http://groups.google.com/group/exceldna/browse_frm/thread/57eb5861db9310a9,
where Sergey was using a tool called .Net Reactor to protect his code,
and ran into a problem with Excel-DNA under the most aggressive
setting. So it looks like it worked for him under settings that are
not so aggressive. You might like to try to get in touch with Sergey
to learn more about his use of .Net Reactor with Excel-DNA.
Another Excel-DNA user who has implemented a licensing scheme is
andste - this thread is an example:
http://groups.google.com/group/exceldna/browse_frm/thread/92086ea65e3c1e69
(you can search for other thread by him in the Group).
As you'll see from both of the above discussions, adding licensing and
protection tends to be a source of headaches.
In an unrelated product, distributed to some hundreds of users, I'd
say 99% of my support has been on the licensing service we use, (and
I'm still happy with the licensing choice we made there).
My own suggestion (not knowing anything about your add-in or the code
or the importance of the licensing and IP for you): implement a very
simple licensing scheme - just write a registry key or your xml file
or something - and do some obfuscation of your calculation assembly
(even with one of the free tools), checking in ILSpy that enough gets
renamed. And just live with the fact that hackers will be able to make
a 'cracked' version of your add-in, which some unscrupulous users
might use.
Regards,
Govert
Govert van Drimmelen
I had a quick peek at Eziriz (http://www.eziriz.com/) who make
the .Net Reactor tool I mentioned, and I saw their other product -
IntelliLock (http://www.eziriz.com/intellilock.htm) which seems like a
good one to try for your licensing. (It's good that it's a 100%
managed code solution - that way it's less likely to interfere with
the Excel-DNA hosting.) It's also not too expensive compared to many
similar tools.
Maybe you'd like to try it and let us know?
Regards,
Govert
On Nov 27, 11:28 pm, Govert van Drimmelen <gov...@icon.co.za> wrote:
> Hi Fonseca,
>
> I like to distinguish between:
> 1. Protecting your code against decompilation, and
> 2. the licensing process and ensuring only licensed users can run your
> add-in.
>
> Most obfuscators will do a good job of 1. by stripping your .dll of
> most of the metadata in method names and signatures. Once stripped or
> useful names, even though the library can be opened in .NET Reflector
> or ILSpy, and you can get usable C# code, the code is not likely to be
> worth using. So I think obfuscation (with some care to make sure that
> your public interface is a small as possible) is good enough to
> protect your code and you need not implement in C++ just for that
> reason.
>
> However, issue 2. is much more tricky. In general you will have some
> license check, but hacking a small change into your library can bypass
> your checking routines. Native code probably gives some more
> protection, though determined hackers can get past your checks here
> too.
>
> You might like to look at this thread:http://groups.google.com/group/exceldna/browse_frm/thread/57eb5861db9...,
> where Sergey was using a tool called .Net Reactor to protect his code,
> and ran into a problem with Excel-DNA under the most aggressive
> setting. So it looks like it worked for him under settings that are
> not so aggressive. You might like to try to get in touch with Sergey
> to learn more about his use of .Net Reactor with Excel-DNA.
>
> Another Excel-DNA user who has implemented a licensing scheme is
> andste - this thread is an example:http://groups.google.com/group/exceldna/browse_frm/thread/92086ea65e3...
ajwillshire
I've implemented a licencing procedure on a library I've made which
works like this:
I have a class called Registration which contains most of the relevant
code. In it I've declared a variable:
Public Shared Licenced As Boolean = CheckLicence()
which is set by the function CheckLicence.
I've used an encryption routine (see here for ideas:
http://msdn.microsoft.com/en-us/library/hk8wx38z.aspx) to take the
processor serial and Windows Registration Code for a machine and
created a hashed character string which I keep in a textfile. The
CheckLicence function reads and decodes the text file and compares it
to values freshly requested.
The Licence variable is then checked in the AutoOpen routine:
Public Sub AutoOpen() Implements
ExcelDna.Integration.IExcelAddIn.AutoOpen
If Registration.Licenced = True Then
'MsgBox("Hello - This is Registered", vbYesNoCancel)
Else
MsgBox("This add-in is not correctly licenced - please
contact XXX for more information.", vbExclamation)
Dim Now As Double = XlCall.Excel(XlCall.xlfNow)
XlCall.Excel(XlCall.xlcOnTime, Now, "RemoveMe")
End If
End Sub
Which, in turn, calls Govert's RemoveMe routine, found elsewhere on
this site:
Public Shared Sub RemoveMe()
Dim myName As String = DirectCast(XlCall.Excel(XlCall.xlGetName),
String)
Dim removeId As Object = XlCall.Excel(XlCall.xlfRegister, myName,
"xlAutoRemove", "I", ExcelMissing.Value, _ ExcelMissing.Value,
2)
Dim removeResult As Object = XlCall.Excel(XlCall.xlfCall, removeId)
Dim removeUnregister As Object = XlCall.Excel(XlCall.xlfUnregister,
removeId)
End Sub
That seems to work for me, in combination with obfuscating the
original dll (I've used dotfuscator for a while which seems to work
quite well and is free).
Having said that, I'm don't know much about code security - but on the
whole I think it protects my code against the efforts of most people
who want it. It would probably be easier and cheaper for someone to
write a routine that does what my code does than to reverse engineer
it.
If I've missed something really obvious in my approach, then I would
appreciate it being pointed out.
Hope that helps - let me know if you need some more specifics.
Andrew
> > > Fonseca- Hide quoted text -
>
> - Show quoted text -
andste
mechanism.
You find a lot of bits and pieces in this forum here. Most missing
parts can
be found elsewhere.
I can also confirm Govert's 99% figure - expect to interact much more
with
your users as soon as licensing is involved... :-S
If you do a general search on google, you will be surprised how
fragmented
the available information is. This is explained by the fact that
people who have
successfully implemented licensing mechanisms prefer not to talk about
them
for security reasons. The elements that you develop yourself will
probably be the
most effective barriers.
Perfect protection is not possible. The better the protection,
the less user-friendly your system almost by definition. On the other
hand, already
very simple measures will have a major impact.
Good luck!
andste
