Re: How do I remove MSIL from my native executable?
- From: Chris Dunaway <dunawayc@xxxxxxxxx>
- Date: Thu, 06 Sep 2007 13:15:13 -0000
On Sep 6, 6:38 am, "C-Services Holland b.v."
<cshNOSPAMPLE...@xxxxxxxx> wrote:
Number 11950 - GPEMC! Replace number with 11950 schreef:
"C-Services Holland b.v." <cshNOSPAMPLE...@xxxxxxxx> wrote in message
news:BeednQwx5qc9X0PbnZ2dnUVZ8qfinZ2d@xxxxxxxxxxxxxxxx
[SNIP]
AFAIK you can't remove it, but you could make it inaccessable by[SNIP]
wrapping it up in a security envelope like HASP. But that would require
more money.
Thank you for the suggestion. So far, what I've gleaned from my enquiries
are that:
a) Executables native to x86 & x64 architecture are all but an open book to
anyone with access to a bitpicker.
It's all about how hard you make it. Native code is pretty hard to
reverse engineer. You can decompile it to assembly and there are tools
that create some sort of readable code from it, but it's alot of work,
b) Obfuscation is weak in theory, but redundancy of features in MSIL
attachment to the native executable are what make the attached native code
friendlier to reverse engineers than properly obfuscated or rather corrupted
MSIL.
With obfuscation you get all the code, but it's 'unreadable' to various
degrees (depending whether you use encryption etc). But IMO it's easier
to get code from that than from native code. However, it does require
alot of work to get some readable code. It's good enough to protect
against the casual cracker, but a determined one will get it.
Unobfuscated code basically comes down to releasing your program as open
source. Anyone using reflector can look at your source and even review
the code in the language they prefer.
c) One of the unexpected but equally vital issues regarding "obfuscation"
concerns limitations to forwards compatibility and interoperability implicit
in one way obfuscation techniques that remove distinction between references
in MSIL not theoretically utilised by client operating system. The problem
here as with HTML, is that undocumented compatibility can change without
notice.
I don't really expect problems with that, since a new version of the
framework usually requires a recompile at the least. With that comes a
new obfuscation step which then is compatible with that new version. But
ofcourse I could be wrong.
So my conclusion at this stage of my IP security inquisition is that strong
obfuscation and IP security may well be achieved at the expense of long term
software reliabilty and compatibility, and this is an issue yet to be
addressed in the documentation of many products used to protect VS2005
source code.
I'd be very interested to hear any other thoughts on this...
Thanks in Advance....
I do agree that, out of the box, VS does little to really protect your IP.
Going back to the HASP solution I mentioned. That is what we're using
for protecting our IP and for licensing. Not only does it obfuscate and
crypt the MSIL, it also wraps up the whole executable into a security
envelope which can only be decrypted by the key (be it a hardlock or a
softlock). That envelope also uses various defense techiques against
decompiling/debugging tools so it's very hard to get at the IP inside it.
I won't say it's unbreakable, because nothing really is. But it's
probably your best bet if you're hardpressed to protect your IP. It's
just that much harder to break.
--
Rinze van Huizen
C-Services Holland b.v
Maybe this will be of interest:
http://www.softwarepotential.com/code-protection.html
I'm not exactly sure how it will work or if it will cost, but it's
worth a look.
Chris
.
- References:
- Re: How do I remove MSIL from my native executable?
- From: C-Services Holland b.v.
- Re: How do I remove MSIL from my native executable?
- From: C-Services Holland b.v.
- Re: How do I remove MSIL from my native executable?
- Prev by Date: Re: Sorting Arrays
- Next by Date: Re: can anybody suggest a grid control ??
- Previous by thread: Re: How do I remove MSIL from my native executable?
- Next by thread: Re: How do I remove MSIL from my native executable?
- Index(es):
Relevant Pages
|
