>> The idea is to make it less trivial to reverse-engineer our code and
>> steal all our secrets.
>
> So, you are on the poor-side of companies. Richer companies have a
> full-time team with lawyers to track and sue such events.

You can't sue somebody unless you catch them.

Given that we can't even tell which (if any) of our *paying* customers 
are still using the product... you get the picture.

> Maybe interpreted language is not the right choice if you want to
> protect your code. That's where compiled language have an advantage: the
> compilation with full optimisation is already an obfuscation. There is
> decompiler... like there is deobfuscater. And they are pretty smart on
> small code.
>
> It's one of the three Java issues (Java is about sharing... keeping
> secret is not sharing, so the choice of the language for your project
> was an error), at least for secretive software. But that's another story.

It's not Java, it's C#. And it's not interpreted, it's a hybrid; compile 
a high-level language into a lower-level language, and then interpret 
(or rather JIT-compile) that. I gather that in early versions of C#, it 
was utterly trivial to recompile CIL back into valid C#, but in later 
version of C# it has become a lot less trivial.

But hey, you try explaining that to the PHB. All he wants to hear is "we 
spent 8 years developing this stuff, I don't want somebody to press one 
button, and be able to steal all our hard work". Not, of course, that an 
obfuscater necessarily does that; I hear there are 1-click deobfustation 
tools out there...

Post a reply to this message